lkml.org 
[lkml]   [2014]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 2/3] PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
    On Tue, 13 May 2014, Rafael J. Wysocki wrote:

    > > Maybe the call to __pm_runtime_disable() should be moved from
    > > __device_suspend_late() to __device_suspend(), after the callback has
    > > been invoked (or skipped, as the case may be). Then after runtime PM
    > > has been disabled, you can check the device's status has changed and go
    > > back to invoke the callback if necessary.
    >
    > We moved __pm_runtime_disable() to __device_suspend_late() to be able to
    > use pm_runtime_resume() in __device_suspend() (and we actually do that in
    > some places now).
    >
    > But, in principle, we can do __pm_runtime_disable() temporarily in some place
    > between ->prepare() and ->suspend(), it doesn't matter if that's in
    > device_prepare() in __device_suspend() really.

    It should be as late as possible, to allow for detecting wakeup
    requests.

    > Then, we can check the device's
    > runtime PM status (that'd need to be done carefully to take the disabling into
    > account) and
    > (1) if the device is runtime-suspended, set direct_complete for it without
    > enabling runtime PM, or
    > (2) if the device is not runtime-suspended, clear direct_complete for it
    > and re-enable runtime PM.
    > and in case of (1) we would re-enable runtime PM in device_complete().
    >
    > That should work I suppose?

    Yes; it's similar to what I proposed. Note that this can be skipped if
    direct_complete is already clear.

    > Of course, question is what ->prepare() is supposed to do then if it needs
    > to check the state of the device before deciding whether or not to return 1.
    > I guess it would need to disable runtime PM around that check too.

    It would be surprising if ->prepare() needed to make any difficult
    checks. This would imply that the device could have multiple
    runtime-suspend states, some of which are appropriate for system
    suspend while others aren't. Not impossible, but I wouldn't expect it
    to come up often.

    Besides, as I mentioned before, we never have to worry about status
    changes. If one occurs while ->prepare() is running or afterward, it
    means the device is runtime-resumed and therefore the setting of
    direct_complete doesn't matter.

    Alan Stern



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