[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201111271305.35811.rjw@sisk.pl>
Date: Sun, 27 Nov 2011 13:05:35 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Linux PM list <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Randy Dunlap <rdunlap@...otime.net>,
Alan Stern <stern@...land.harvard.edu>
Subject: [PATCH 3/5] PM / Runtime: Make documentation follow the new behavior of irq_safe
From: Rafael J. Wysocki <rjw@...k.pl>
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@...k.pl>
---
Documentation/power/runtime_pm.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux/Documentation/power/runtime_pm.txt
===================================================================
--- linux.orig/Documentation/power/runtime_pm.txt
+++ linux/Documentation/power/runtime_pm.txt
@@ -65,11 +65,12 @@ are referred to as subsystem-level callb
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists