Diffstat (limited to 'Documentation/power')
1 files changed, 50 insertions, 0 deletions
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 7b5ab270124..356fd86f4ea 100644
@@ -381,3 +381,53 @@ incremented by the core before executing ->probe() and ->remove(). Still, it
may be desirable to suspend the device as soon as ->probe() or ->remove() has
finished, so the PM core uses pm_runtime_idle_sync() to invoke the
subsystem-level idle callback for the device at that time.
+6. Run-time PM and System Sleep
+Run-time PM and system sleep (i.e., system suspend and hibernation, also known
+as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
+ways. If a device is active when a system sleep starts, everything is
+straightforward. But what should happen if the device is already suspended?
+The device may have different wake-up settings for run-time PM and system sleep.
+For example, remote wake-up may be enabled for run-time suspend but disallowed
+for system sleep (device_may_wakeup(dev) returns 'false'). When this happens,
+the subsystem-level system suspend callback is responsible for changing the
+device's wake-up setting (it may leave that to the device driver's system
+suspend routine). It may be necessary to resume the device and suspend it again
+in order to do so. The same is true if the driver uses different power levels
+or other settings for run-time suspend and system sleep.
+During system resume, devices generally should be brought back to full power,
+even if they were suspended before the system sleep began. There are several
+reasons for this, including:
+ * The device might need to switch power levels, wake-up settings, etc.
+ * Remote wake-up events might have been lost by the firmware.
+ * The device's children may need the device to be at full power in order
+ to resume themselves.
+ * The driver's idea of the device state may not agree with the device's
+ physical state. This can happen during resume from hibernation.
+ * The device might need to be reset.
+ * Even though the device was suspended, if its usage counter was > 0 then most
+ likely it would need a run-time resume in the near future anyway.
+ * Always going back to full power is simplest.
+If the device was suspended before the sleep began, then its run-time PM status
+will have to be updated to reflect the actual post-system sleep status. The way
+to do this is:
+The PM core always increments the run-time usage counter before calling the
+->prepare() callback and decrements it after calling the ->complete() callback.
+Hence disabling run-time PM temporarily like this will not cause any run-time
+suspend callbacks to be lost.