[lkml]   [2011]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Locking in the clk API
    On Tue, Jan 11, 2011 at 2:46 PM, Russell King - ARM Linux
    <> wrote:
    > On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
    >> At present, we can satisfy these with:
    >> * clk_enable: may sleep
    > I object to this as one of the purposes behind the clk API is to allow
    > power savings to be made, and unless we can perform clk enable/disable
    > from atomic contexts, the best you can do is enable the clock when the
    > device is probed and disable it when it's released.
    > For a lot of systems, modules are loaded at boot, and devices are probed
    > at boot time.  They're never unloaded.
    > This means that clocks will be enabled at boot time and never turned off.
    > If you're lucky, there may be open/release methods which can be used to
    > enable/disable the clock, which reduces the 'clock on' period down to
    > the point where userspace opens/closes the device.  That's still
    > insufficient and in some cases there aren't calls for this.
    > Sometimes the only point that you know you need the clock enabled is when
    > your driver has already been called in an atomic context.
    > If such a requirement is imposed, it means that a driver would either have
    > to leave the clock always on, or would have to drop such calls if the
    > clock wasn't already enabled.

    Perhaps we should factor the conventional clk_enable into two parts (say) :-
    a) clk_setup : Which does exactly what can't be done in atomic context.
    Like setting PLLs i.e, if that needs to sleep.
    b) clk_enable : Everything else that gets the clock signals running.

    The drivers could do clk_setup in probe/open and clk_enable right before the
    the actual need of the clock. That way, drivers don't have to bother
    with platform/clock
    peculiarities while trying their best to save power.
    Of course, power that can't be saved now, won't be saved then.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-01-11 13:15    [W:0.021 / U:7.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site