OMAP2/3 clock: implement clock rate change notifiers

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.

(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(-)