[lkml]   [2011]   [Jan]   [12]   [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 06:56:10PM -0800, Saravana Kannan wrote:
    > On 01/11/2011 01:16 AM, 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.
    > Since dev_pm_ops.suspend is not atomic anymore (am I wrong?), what is

    That never has been, and that is called for the _system_ going into
    suspend. That's not what I'm talking about. I'm talking about drivers
    doing their own power management in response to (a) their knowledge of
    how the device behaves and (b) in response to the user state they know.

    In the case of a UART, that means enabling the clock when the user opens
    the device and turning it off when the user closes the device - and in
    the case of the UART being used as the system console, enabled when
    printk calls it, disabled when finished outputting the message.

    The latter is a case where you're called in atomic context.

    Another case - a storage device. While you may receive open/close calls,
    these are meaningless for power management - you'll receive an open call
    when you mount a filesystem, and a close call when you finally unmount it.
    That doesn't mean it's going to be used. Your request handler will
    generally run in an atomic context, so in order to do dynamic power
    saving you need to be able to enable/disable clocks in that context.

    A touchscreen controller which you communicate with over a dedicated bus.
    The touchscreen controller doesn't require the host to be constantly
    clocked - it only needs to be clocked when communicating with the
    touchscreen. The touchscreen controller raises an interrupt for service.
    You'd want to enable the clock in the interrupt handler to communicate
    with the device and turn it off afterwards.

    Shall I continue?

     \ /
      Last update: 2011-01-12 10:07    [W:0.044 / U:111.428 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site