Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit ea309944 authored by Ulf Hansson's avatar Ulf Hansson Committed by Rafael J. Wysocki
Browse files

PM / Runtime: Update documentation around probe|remove|suspend 



PM core and driver core has changed some behavior regarding use of
runtime PM. Update the documentation accordingly.

Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
parent baab52de

Documentation/power/runtime_pm.txt

+6 −8
Original line number Original line Diff line number Diff line
@@ -547,13 +547,11 @@ helper functions described in Section 4. In that case, pm_runtime_resume() 
should be used.  Of course, for this purpose the device's runtime PM has to be

should be used.  Of course, for this purpose the device's runtime PM has to be

enabled earlier by calling pm_runtime_enable().

enabled earlier by calling pm_runtime_enable().





If the device bus type's or driver's ->probe() callback runs

It may be desirable to suspend the device once ->probe() has finished.

pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts,

Therefore the driver core uses the asyncronous pm_request_idle() to submit a

they will fail returning -EAGAIN, because the device's usage counter is

request to execute the subsystem-level idle callback for the device at that

incremented by the driver core before executing ->probe().  Still, it may be

time.  A driver that makes use of the runtime autosuspend feature, may want to

desirable to suspend the device as soon as ->probe() has finished, so the driver

update the last busy mark before returning from ->probe().

core uses pm_runtime_put_sync() to invoke the subsystem-level idle callback for

the device at that time.





Moreover, the driver core prevents runtime PM callbacks from racing with the bus

Moreover, the driver core prevents runtime PM callbacks from racing with the bus

notifier callback in __device_release_driver(), which is necessary, because the

notifier callback in __device_release_driver(), which is necessary, because the
@@ -656,7 +654,7 @@ out the following operations: 
    __pm_runtime_disable() with 'false' as the second argument for every device

    __pm_runtime_disable() with 'false' as the second argument for every device

    right before executing the subsystem-level .suspend_late() callback for it.

    right before executing the subsystem-level .suspend_late() callback for it.





  * During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()

  * During system resume it calls pm_runtime_enable() and pm_runtime_put()

    for every device right after executing the subsystem-level .resume_early()

    for every device right after executing the subsystem-level .resume_early()

    callback and right after executing the subsystem-level .resume() callback

    callback and right after executing the subsystem-level .resume() callback

    for it, respectively.

    for it, respectively.