aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/power
diff options
context:
space:
mode:
authorDan Murphy <dmurphy@ti.com>2012-02-02 14:16:57 -0600
committerDan Murphy <dmurphy@ti.com>2012-02-02 14:19:13 -0600
commit04cc23436ebc4f0caf088a97ef9404ea71acfdd1 (patch)
tree9994f9a05d68e47e51368017288c157936e9e1cd /Documentation/power
parent50725abe80c6893a7134977c8b576a0ec4eef5a5 (diff)
parent235eae6e5e402f5f723203e4444f10c16c7c3be3 (diff)
downloadkernel_samsung_espresso10-04cc23436ebc4f0caf088a97ef9404ea71acfdd1.zip
kernel_samsung_espresso10-04cc23436ebc4f0caf088a97ef9404ea71acfdd1.tar.gz
kernel_samsung_espresso10-04cc23436ebc4f0caf088a97ef9404ea71acfdd1.tar.bz2
Merge branch 'linux-3.0.18' into p-android-omap-3.0
Conflicts: arch/arm/mach-omap2/smartreflex.c drivers/i2c/busses/i2c-omap.c drivers/usb/host/ehci.h drivers/usb/musb/musb_core.c fs/proc/base.c Signed-off-by: Dan Murphy <dmurphy@ti.com>
Diffstat (limited to 'Documentation/power')
-rw-r--r--Documentation/power/runtime_pm.txt10
1 files changed, 10 insertions, 0 deletions
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 22852b3..a6b3430 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -709,6 +709,16 @@ will behave normally, not taking the autosuspend delay into account.
Similarly, if the power.use_autosuspend field isn't set then the autosuspend
helper functions will behave just like the non-autosuspend counterparts.
+Under some circumstances a driver or subsystem may want to prevent a device
+from autosuspending immediately, even though the usage counter is zero and the
+autosuspend delay time has expired. If the ->runtime_suspend() callback
+returns -EAGAIN or -EBUSY, and if the next autosuspend delay expiration time is
+in the future (as it normally would be if the callback invoked
+pm_runtime_mark_last_busy()), the PM core will automatically reschedule the
+autosuspend. The ->runtime_suspend() callback can't do this rescheduling
+itself because no suspend requests of any kind are accepted while the device is
+suspending (i.e., while the callback is running).
+
The implementation is well suited for asynchronous use in interrupt contexts.
However such use inevitably involves races, because the PM core can't
synchronize ->runtime_suspend() callbacks with the arrival of I/O requests.