Linaro Developers Summit: ARM struct clk consolidation

The second day of the Linaro Developers Summit went as well as did the first. There was excellent progress on the “struct clk” issue, which had been a source of serious contention on the mailing lists. This data structure deals with the clock trees that are common on a number of embedded SoCs, including ARM SoCs. Individual devices are driven by particular clocks, and those clocks can have parents and children. Frequencies of individual clocks may be changed (for example, for dynamic voltage/frequency scaling, also known as DVFS), but these changes often need to be coordinated with other clocks in the tree and with the devices that use the affected clocks. These clock trees are important for embedded energy efficiency, as they are one of the things that allow different blocks of circuitry to be operated at lower power levels or to be shut down entirely.

There were clear decisions on a number of items that had previously been rather contentious:

1. Parent-clock handling will be moved to the core clock code.
2. The driver/clock interface will need to change (though perhaps not immediately).
3. DVFS and QoS (quality of service) should be separate components. The struct clk structure should only deal with clocks.
4. The struct clk should be opaque.
5. Clock-related locking needs to be implemented in the core clock code (and not in the drivers), and locking should be isolated to allow it to be changed easily.
6. A per-clock-tree spinlock/mutex combination should be used as the initial locking design.
   1. Clock enable/disable operations acquire only the spinlock.
   2. Clock prepare/unprepare operations acquire only the mutex.
   3. Clock setrate/setparent operations acquire the mutex first, then acquire the spinlock following successful validation or preparation.

Jeremy Kerr and Thomas Gleixner will work on a new version of the struct clk patch, which will be applied to various SoCs and simulator environments by Shawn Guo, Sascha Hauer, Paul Walmsley, Linus Walleij, Thomas Abraham, Magnus Damm, and Mark Brown. We are also hoping for a few other people to join in, including some non-ARM maintainers.

That is right: this is intended to be core kernel code, not ARM-specific code!