GitHub-Mirror/Star64_linux
2
0
Fork 0
mirror of https://github.com/Fishwaldo/Star64_linux.git synced 2025-06-07 15:18:15 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

PM / Runtime: Update documentation regarding driver removal

Browse source 
Commit e1866b33b1 (PM / Runtime: Rework
runtime PM handling during driver removal) forgot to update the
documentation in Documentation/power/runtime_pm.txt to match the new
code in drivers/base/dd.c.  Update that documentation to match the
code it describes.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: Kevin Hilman <khilman@ti.com>
This commit is contained in:
Rafael J. Wysocki 2011-07-02 14:27:11 +02:00
parent 5efb54cc3f
commit f5da24dbed
1 changed files with 21 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
Documentation/power/runtime_pm.txt
View file

@ -501,13 +501,29 @@ helper functions described in Section 4. In that case, pm_runtime_resume()
should be used. Of course, for this purpose the device's run-time PM has to be should be used. Of course, for this purpose the device's run-time 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() or ->remove() callback runs If the device bus type's or driver's ->probe() callback runs
pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts, pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts,
they will fail returning -EAGAIN, because the device's usage counter is they will fail returning -EAGAIN, because the device's usage counter is
incremented by the core before executing ->probe() and ->remove(). Still, it incremented by the driver core before executing ->probe(). Still, it may be
may be desirable to suspend the device as soon as ->probe() or ->remove() has desirable to suspend the device as soon as ->probe() has finished, so the driver
finished, so the PM core uses pm_runtime_put_sync() to invoke the core uses pm_runtime_put_sync() to invoke the subsystem-level idle callback for
subsystem-level idle callback for the device at that time. the device at that time.
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 is used by some subsystems to carry out operations affecting the
runtime PM functionality. It does so by calling pm_runtime_get_sync() before
driver_sysfs_remove() and the BUS_NOTIFY_UNBIND_DRIVER notifications. This
resumes the device if it's in the suspended state and prevents it from
being suspended again while those routines are being executed.
To allow bus types and drivers to put devices into the suspended state by
calling pm_runtime_suspend() from their ->remove() routines, the driver core
executes pm_runtime_put_sync() after running the BUS_NOTIFY_UNBIND_DRIVER
notifications in __device_release_driver(). This requires bus types and
drivers to make their ->remove() callbacks avoid races with runtime PM directly,
but also it allows of more flexibility in the handling of devices during the
removal of their drivers.
The user space can effectively disallow the driver of the device to power manage The user space can effectively disallow the driver of the device to power manage
it at run time by changing the value of its /sys/devices/.../power/control it at run time by changing the value of its /sys/devices/.../power/control