Paul Walmsley <paul@xxxxxxxxx> writes: > Hello, > > This series implements a clock rate change notifier for OMAP2/3 [1]. > It applies on top of the "OMAP clock: bug fixes, cleanup, > optimization" series posted to linux-omap on Mon, 22 Dec 2008. Now that the 'buf fixes, cleanup' series is now in linux-omap, I'll pull this series into the PM branch for more testing. Kevin > (The notes below assume that the notifiers are used by device drivers; > however, they are also usable by core code.) > > The clock notifier is called for both rate and parent changes, and > is called even when the current rate is the same as the future rate, > in the event that the reprogramming causes a glitch. > > A single notifier is defined, with four types of messages: > > CLK_PREPARE_RATE_CHANGE: Used to ask the driver whether a rate > change is OK to complete. When drivers receive this message, > they should start any actions that must complete before a > rate change can succeed. > > CLK_ABORT_RATE_CHANGE: Indicates that a notifier callback > has aborted the rate change, or that the clock rate/parent > change function has failed. Upon receipt of this message, > drivers can > > CLK_PRE_RATE_CHANGE: Indicates that the rate/parent change is about > to take place. The callback must not return until the driver > is ready for the change. > > CLK_POST_RATE_CHANGE: Indicates that the rate/parent change has > successfully completed. > > ... > > There are three possible sequences of notifier messages that a driver > can receive: > > PREPARE -> PRE -> POST: > Successful rate/parent change. > > PREPARE -> ABORT: > Rate/parent change aborted by one of the callbacks. > > PREPARE -> PRE -> ABORT > Rate/parent change aborted by the clock's set_rate()/set_parent() > functions. > > ... > > If clock notifier callbacks are expected to abort clock changes, they > probably should not be used as the only method for aborting changes. > The clk_set_rate() or clk_set_parent() functions will return -EAGAIN > if a driver aborts the change. Higher-level code such as CPUFreq may > attempt to call the function repeatedly, pointlessly burning CPU > cycles. In these situations, application code or system daemons > must also be used to prevent the frequency change from reaching the > clock code when it is expected to fail for long durations. > > Callbacks are called with the clock framework spinlock held. Callback > code should be extremely fast and lightweight and must not call back > into the clock framework. > > Since support for clock notifiers currently does not exist in > include/linux/clk.h, drivers that wish to use them should pass > function pointers for clk_notifier_register() and > clk_notifier_unregister() via their platform_data structs. > > Please note that these patches have only been lightly tested. Further > testing is ongoing; help always appreciated. > > Compile-tested on OMAP1. Boot-tested on N800. Notifier callback > tested on 3430SDP GP ES2.1. > > - Paul > > -- > > 1, There's no technical reason why these can't also be implemented for > OMAP1. I just don't have a convenient way to test OMAP1 builds at the > moment. > > > size: > text data bss dec hex filename > 3582501 190928 108824 3882253 3b3d0d vmlinux.3430sdp.orig > 3583605 191824 108824 3884253 3b44dd vmlinux.3430sdp.patched > > diffstat: > arch/arm/mach-omap2/clock.c | 69 +++++++++-- > arch/arm/plat-omap/clock.c | 203 +++++++++++++++++++++++++++++++ > arch/arm/plat-omap/include/mach/clock.h | 83 +++++++++++++ > 3 files changed, 346 insertions(+), 9 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
