* Paul Walmsley <paul@xxxxxxxxx> [080621 02:16]: > > This series adds a clock rate change notifier to the OMAP clock > framework. Currently only post-rate-change notification is > implemented, although pre-rate-change notification is in the works. > > Clock post-rate-change notifiers are intended for drivers that need to > be notified when other code (such as power management code) changes > their clock's rate. DSPBridge is apparently one such user, but > drivers for UART, MCSPI, etc. are also candidates for these notifiers. > > Drivers should use these notifiers by adding function pointers for > clk_notifier_register() and clk_notifier_unregister() to their > platform_data structure. Ensure that the function pointers are not > NULL before calling, since non-OMAP platforms may not support this > notifier: > > if (pdata->clk_notifier_register) > (*pdata->clk_notifier_register)(clk, &test_nb); > > The callback code must not call back into the clock framework nor > sleep, as the clock framework spinlock is held for the duration of the > callbacks. Callback functions should be short and lightweight. > > ... > > A few implementation notes. Upon request, an alternate design was > also investigated based on the existing CPUFreq notifiers. That > design was set aside, due to the following problems: > > - CPUFreq notifier callbacks can sleep. This will break the clock > framework, since it calls the notifier inside a spinlock. > > - Identifying the changed clock from the callback would require a new > platform_data-based function in the clock framework, since struct > cpufreq_freqs has no good way to pass it. > > - CPUFreq notifiers depend on CPUFreq, which not everyone uses. > > There was also some concern expressed that separate CPUFreq notifiers > and clk rate notifiers could race. (That would only apply to the > clocks that are changed by CPUFreq, and any clocks downstream from > it.) This doesn't appear to be a problem in practice, since CPUFreq > post-rate notifiers can only start after the clk post-rate notifiers > have completed and exited the clock framework. > > The current implementation has been moderately tested with multiple > clock notifiers on both DPLLs and a downstream clock on 3430SDP. Also > compile-tested for N800. Let's run these by linux-arm-kernel and linux-pm lists before we apply. Tony > > > - Paul > > > text data bss dec hex filename > 3404721 158888 108176 3671785 3806e9 vmlinux.3430sdp.orig > 3405361 158896 108176 3672433 380971 vmlinux.3430sdp.patched > > arch/arm/mach-omap2/clock.c | 37 ++++++++-- > arch/arm/mach-omap2/clock24xx.c | 42 ++++++++++- > arch/arm/mach-omap2/clock34xx.c | 10 +++ > arch/arm/plat-omap/clock.c | 144 +++++++++++++++++++++++++++++++++++++ > include/asm-arm/arch-omap/clock.h | 21 +++++ > 5 files changed, 246 insertions(+), 8 deletions(-) > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
