[lkml]   [2009]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] [RFC][PATCH] PM: Introduce core framework for run-time PM of I/O devices (rev. 8)
    On Fri, Jul 10, 2009 at 6:56 AM, Mahalingam,
    Nithish<> wrote:
    > On Thu, Jul 9, 2009 at 10:48 PM, Alan Stern<> wrote:
    >>> On Thu, 9 Jul 2009, Magnus Damm wrote:
    >>>> Clocks should be stopped as soon as possible without any delay. The
    >>>> clock stopping is very cheap performance wise. Also, the clock
    >>> stopping is done on bus level without invoking any driver callbacks.
    >>>> Delaying the clock stopping does not make any sense to me.
    >>> In that case the device driver or bus subsystem should manage the
    >>> device's clock directly.  There's no need to tie it in with the runtime
    >>> PM framework.  Simply start the clock before each I/O operation and
    >>> stop it afterward.
    >> It's not that easy. The clock needs to be enabled to let the hardware
    >> device perform device specific stuff. For instance, the clock for the
    >> LCD controller needs to be on to redraw the screen. When the driver
    >> knows that it's done with the clock it can notify the bus using
    >> Runtime PM.
    > Is there any plan to look into the "Clock Framework" that was developed as part of OMAP and extending this to make it generic for all platforms?

    Do you mean vendor specific extensions to the clock framework? I'm
    quite sure a bunch of architectures already support the clock
    framework. Some architectures probably have extensions that would be
    nice if they could be made more generic. Do you have any special
    extensions in mind? =)

    As for Runtime PM, clock stopping is only one part of the problem. On
    SuperH we manage clock stopping through the clock framework and I'm
    pretty sure other embedded architectures do that as well. That problem
    is more or less already solved in my opinion.

    For efficient power management on embedded systems we need more than
    just clock stopping. We also want to save and restore device context
    so we can turn off power to power domains during runtime. This is
    somewhat tied together with clock stopping because we want to disable
    clocks as soon as possible when the device gets idle but in the case
    of domain power off we also need to start the clock before we can call
    the ->runtime_suspend() callback provided by the driver. All this can
    of course be handled by the device driver, but that would just be
    duplicating too much code - I'd rather let the Runtime PM bus code
    manage that.

    Many runtime power management aware device drivers use clk_enable()
    and clk_disable() stop and start clocks. But the clk_disable()
    function is actually often used to signal that the device is idle.
    Allowing device drivers to replace clk_enable()/clk_disable() with
    Runtime PM callbacks to add support for context save and restore is a
    logical next step from my point of view.

    For SuperH we will most likely allow clock stopping through the clock
    framework _or_ using Runtime PM in parallel, at least until all
    drivers are converted to make use of Runtime PM.


    / magnus
    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: 2009-07-13 03:53    [W:0.023 / U:8.556 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site