[PATCH 0/7] OMAP2/3 clock: implement clock rate change notifiers

[Paul Walmsley <paul@pwsan.com>]

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