aboutsummaryrefslogtreecommitdiff
path: root/Documentation/power/runtime_pm.txt
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2011-11-23 21:20:07 +0100
committerRafael J. Wysocki <rjw@sisk.pl>2011-11-28 22:14:34 +0100
commit907565921966260921e4c4581ed8985ef4cf9a67 (patch)
treed7e48912c3ab88eec1766158cc17eb2b693a85d6 /Documentation/power/runtime_pm.txt
parentfa8ce723936460fcf7e49f508fd5dbd5125e39c4 (diff)
PM / Runtime: Make documentation follow the new behavior of irq_safe
The runtime PM core code behavior related to the power.irq_safe device flag has changed recently and the documentation should be modified to reflect it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Diffstat (limited to 'Documentation/power/runtime_pm.txt')
-rw-r--r--Documentation/power/runtime_pm.txt11
1 files changed, 6 insertions, 5 deletions
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 79b10a090c9..c2ae8bf77d4 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -65,11 +65,12 @@ are referred to as subsystem-level callbacks in what follows.
By default, the callbacks are always invoked in process context with interrupts
enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
-to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
-callbacks should be invoked in atomic context with interrupts disabled.
-This implies that these callback routines must not block or sleep, but it also
-means that the synchronous helper functions listed at the end of Section 4 can
-be used within an interrupt handler or in an atomic context.
+to tell the PM core that their ->runtime_suspend(), ->runtime_resume() and
+->runtime_idle() callbacks may be invoked in atomic context with interrupts
+disabled for a given device. This implies that the callback routines in
+question must not block or sleep, but it also means that the synchronous helper
+functions listed at the end of Section 4 may be used for that device within an
+interrupt handler or generally in an atomic context.
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
the suspend of the device as appropriate, which may, but need not include