lkml.org 
[lkml]   [2014]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH 1/3] PM / sleep: Flag to speed up suspend-resume of runtime-suspended devices
    Date
    On Thursday, May 08, 2014 10:17:50 PM Rafael J. Wysocki wrote:
    > On Thursday, May 08, 2014 10:57:36 AM Alan Stern wrote:
    > > On Thu, 8 May 2014, Rafael J. Wysocki wrote:
    > >
    > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    > > >
    > > > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
    > > > resume all runtime-suspended devices during system suspend, mostly
    > > > because those devices may need to be reprogrammed due to different
    > > > wakeup settings for system sleep and for runtime PM.
    > > >
    > > > For some devices, though, it's OK to remain in runtime suspend
    > > > throughout a complete system suspend/resume cycle (if the device was in
    > > > runtime suspend at the start of the cycle). We would like to do this
    > > > whenever possible, to avoid the overhead of extra power-up and power-down
    > > > events.
    > > >
    > > > However, problems may arise because the device's descendants may require
    > > > it to be at full power at various points during the cycle. Therefore the
    > > > most straightforward way to do this safely is if the device and all its
    > > > descendants can remain runtime suspended until the resume stage of system
    > > > resume.
    > > >
    > > > To this end, introduce dev->power.leave_runtime_suspended.
    > > > If a subsystem or driver sets this flag during the ->prepare() callback,
    > > > and if the flag is set in all of the device's descendants, and if the
    > > > device is still in runtime suspend at the beginning of the ->suspend()
    > > > callback, that callback is allowed to return 0 without clearing
    > > > power.leave_runtime_suspended and without changing the state of the
    > > > device, unless the current state of the device is not appropriate for
    > > > the upcoming system sleep state (for example, the device is supposed to
    > > > wake up the system from that state and its current wakeup settings are
    > > > not suitable for that). Then, the PM core will not invoke the device's
    > > > ->suspend_late(), ->suspend_irq(), ->resume_irq(), ->resume_early(), or
    > > > ->resume() callbacks. Instead, it will invoke ->runtime_resume() during
    > > > the device resume stage of system resume.
    > >
    > > Wait a minute. Following ->runtime_suspend(), you are going to call
    > > ->suspend() and then ->runtime_resume()? That doesn't seem like what
    > > you really want; a ->suspend() call should always have a matching
    > > ->resume().
    >
    > Yes, it should, but I didn't see any other way to do that.

    Actually, that's kind of easy to resolve. :-)

    When ->suspend() leaves power.leave_runtime_suspended set, the PM core can
    simply skip the early/late and noirq callbacks and then call ->resume()
    that will be responsible for using whatever is necessary to resume the
    device.

    And perhaps the flag should be called something different then, like
    direct_resume (meaning go directly for ->resume() without executing
    the intermediate callbacks)?

    Rafael



    \
     
     \ /
      Last update: 2014-05-09 00:21    [W:9.066 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site