• Rafael J. Wysocki's avatar
    PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily · aae4518b
    Rafael J. Wysocki authored
    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 complete stage of
    system resume.
    
    To this end, introduce a new device PM flag, power.direct_complete
    and modify the PM core to use that flag as follows.
    
    If the ->prepare() callback of a device returns a positive number,
    the PM core will regard that as an indication that it may leave the
    device runtime-suspended.  It will then check if the system power
    transition in progress is a suspend (and not hibernation in particular)
    and if the device is, indeed, runtime-suspended.  In that case, the PM
    core will set the device's power.direct_complete flag.  Otherwise it
    will clear power.direct_complete for the device and it also will later
    clear it for the device's parent (if there's one).
    
    Next, the PM core will not invoke the ->suspend() ->suspend_late(),
    ->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
    callbacks for all devices having power.direct_complete set.  It
    will invoke their ->complete() callbacks, however, and those
    callbacks are then responsible for resuming the devices as
    appropriate, if necessary.  For example, in some cases they may
    need to queue up runtime resume requests for the devices using
    pm_request_resume().
    
    Changelog partly based on an Alan Stern's description of the idea
    (http://marc.info/?l=linux-pm&m=139940466625569&w=2).
    Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
    aae4518b
pm.h 31.3 KB