aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2009-12-22 14:43:40 -0500
committerRafael J. Wysocki <rjw@sisk.pl>2009-12-22 14:43:40 -0500
commitf1212ae1332b95fe3bafa7b5c063dd8e473247cf (patch)
tree4c7f6d947d6df27c1ec1be70fe5e1af556976096 /Documentation
parenta6ab7aa9f432f722808c6fea5a8b7f5f229de031 (diff)
PM: Runtime PM documentation update
This patch (as1318) updates the runtime PM documentation, adding a section discussing the interaction between runtime PM and system sleep. [rjw: Rebased and made it agree with the other updates better.] Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/power/runtime_pm.txt50
1 files changed, 50 insertions, 0 deletions
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 7b5ab2701247..356fd86f4ea8 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -381,3 +381,53 @@ incremented by the core before executing ->probe() and ->remove(). Still, it
381may be desirable to suspend the device as soon as ->probe() or ->remove() has 381may be desirable to suspend the device as soon as ->probe() or ->remove() has
382finished, so the PM core uses pm_runtime_idle_sync() to invoke the 382finished, so the PM core uses pm_runtime_idle_sync() to invoke the
383subsystem-level idle callback for the device at that time. 383subsystem-level idle callback for the device at that time.
384
3856. Run-time PM and System Sleep
386
387Run-time PM and system sleep (i.e., system suspend and hibernation, also known
388as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
389ways. If a device is active when a system sleep starts, everything is
390straightforward. But what should happen if the device is already suspended?
391
392The device may have different wake-up settings for run-time PM and system sleep.
393For example, remote wake-up may be enabled for run-time suspend but disallowed
394for system sleep (device_may_wakeup(dev) returns 'false'). When this happens,
395the subsystem-level system suspend callback is responsible for changing the
396device's wake-up setting (it may leave that to the device driver's system
397suspend routine). It may be necessary to resume the device and suspend it again
398in order to do so. The same is true if the driver uses different power levels
399or other settings for run-time suspend and system sleep.
400
401During system resume, devices generally should be brought back to full power,
402even if they were suspended before the system sleep began. There are several
403reasons for this, including:
404
405 * The device might need to switch power levels, wake-up settings, etc.
406
407 * Remote wake-up events might have been lost by the firmware.
408
409 * The device's children may need the device to be at full power in order
410 to resume themselves.
411
412 * The driver's idea of the device state may not agree with the device's
413 physical state. This can happen during resume from hibernation.
414
415 * The device might need to be reset.
416
417 * Even though the device was suspended, if its usage counter was > 0 then most
418 likely it would need a run-time resume in the near future anyway.
419
420 * Always going back to full power is simplest.
421
422If the device was suspended before the sleep began, then its run-time PM status
423will have to be updated to reflect the actual post-system sleep status. The way
424to do this is:
425
426 pm_runtime_disable(dev);
427 pm_runtime_set_active(dev);
428 pm_runtime_enable(dev);
429
430The PM core always increments the run-time usage counter before calling the
431->prepare() callback and decrements it after calling the ->complete() callback.
432Hence disabling run-time PM temporarily like this will not cause any run-time
433suspend callbacks to be lost.