Common Clock Framework: How To Use It
summary
Common Clock Framework shipped in Linux 3.4 (early 2012) and is now mandatory for new ARM SoCs, moving clock code into a reusable subsystem that drastically cuts duplicated drivers. It exposes clock.h ops like clk_prepare/clk_enable and rate APIs, integrates with device tree via of_clk_init and clock_add_provider, and offers base types (fixed, gate, mux, fixed-factor, divider) plus a composite clock to merge gate/mux/divider. Shipping debugfs JSON and reentrancy for DVFS, migration of most ARM SoCs is largely complete.
AI-written summary · about
chapters (15)
- 0:00Intro
- 2:23The clock framework
- 4:48Diagram overview of the common clock framework
- 5:46Interface of the CCF
- 8:31Implementation of the CCF core
- 10:24Implementation of the hardware clock
- 10:55Operations to implement depending on clk capabilities
- 12:14Hardware clock operations, making clocks available
- 14:05Hardware clock operations making clocks available
- 15:11Hardware clock operations managing the rates
- 17:00Hardware clock operations managing the parents
- 17:57Hardware clock operations more callbacks
- 25:31Hardware clock operations device tree
- 36:27How device drivers use the CCF
- 37:38Devices referencing their clock in the Device Tree
related talks
24mFixing Clock Tree Propagation in the Common Clk Framework
47mUpdates To Clock Management Within Zephyr RTOS
26mA Primer to Clocks and Power Management Through ARM SCMI- 26mA Primer to Clocks and Power Management Through ARM SCMI
35mTimekeeping in the Linux Kernel
46mEarly Platform Drivers in Linux Kernel
47mRTC Subsystem, Recent Changes and Where it is Heading
34mA new Linux kernel subsystem for JESD204 RF Transceiver Systems