diff options
author | Rafael J. Wysocki <rjw@sisk.pl> | 2011-11-23 21:20:07 +0100 |
---|---|---|
committer | Rafael J. Wysocki <rjw@sisk.pl> | 2011-11-28 22:14:34 +0100 |
commit | 907565921966260921e4c4581ed8985ef4cf9a67 (patch) | |
tree | d7e48912c3ab88eec1766158cc17eb2b693a85d6 /Documentation/power | |
parent | fa8ce723936460fcf7e49f508fd5dbd5125e39c4 (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')
-rw-r--r-- | Documentation/power/runtime_pm.txt | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 79b10a090c9f..c2ae8bf77d46 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 |