Lines Matching refs:suspend

15   them to be synchronized with system-wide power transitions (suspend to RAM,
80 The subsystem-level suspend callback, if present, is _entirely_ _responsible_
81 for handling the suspend of the device as appropriate, which may, but need not
84 callback in a device driver as long as the subsystem-level suspend callback
87   * Once the subsystem-level suspend callback (or the driver suspend callback,
93     PM status of a device after successful execution of the suspend callback is
96   * If the suspend callback returns -EBUSY or -EAGAIN, the device's runtime PM
100   * If the suspend callback returns an error code different from -EBUSY and
111 low-power state during the execution of the suspend callback, it is expected
147 suspending the device are satisfied) and to queue up a suspend request for the
149 0, then the PM core will attempt to carry out a runtime suspend of the device,
154 started a delayed suspend), the routine must return a non-zero value.  Negative
205     - timer used for scheduling (delayed) suspend and autosuspend requests
254       suspend to complete; means "start a resume as soon as you've suspended"
286       when the timer expires rather than a normal suspend
317     - execute the subsystem-level suspend callback for the device; returns 0 on
320       to suspend the device again in future and -EACCES means that
343     - schedule the execution of the subsystem-level suspend callback for the
348     - schedule the execution of the subsystem-level suspend callback for the
350       suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work
543 parent won't be able to suspend at run time, using the PM core's helper
559 It may be desirable to suspend the device once ->probe() has finished.
595 Runtime PM and system sleep (i.e., system suspend and hibernation, also known
596 as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
601 For example, remote wake-up may be enabled for runtime suspend but disallowed
603 the subsystem-level system suspend callback is responsible for changing the
605 suspend routine).  It may be necessary to resume the device and suspend it again
607 or other settings for runtime suspend and system sleep.
610 power, even if they had been suspended before the system suspend began.  There
628 If the device had been suspended before the system suspend began and it's
638 ->suspend() callback and decrements it after calling the ->resume() callback.
640 suspend attempts to be permanently lost.  If the usage count goes to zero
654 suspend began in the suspended state.
657 different levels of device hierarchy.  Namely, if a system suspend .prepare()
660 may be left in runtime suspend provided that all of its descendants are also
661 left in runtime suspend.  If that happens, the PM core will not execute any
662 system suspend and resume callbacks for all of those devices, except for the
664 as appropriate.  This only applies to system suspend transitions that are not
669 the runtime PM and system suspend/resume (and hibernation) callbacks by carrying
672   * During system suspend pm_runtime_get_noresume() is called for every device
675     subsystem-level .suspend() callback for it.  In addition to that the PM core
700     - if the device has not been suspended at run time, invoke the ->suspend()
755 ->runtime_resume(), ->suspend(), ->suspend_noirq(), ->resume(),
760 Device drivers that wish to use the same function as a system suspend, freeze,
761 poweroff and runtime suspend callback, and similarly for system resume, thaw,
838 itself because no suspend requests of any kind are accepted while the device is
880 			/* ... suspend the device ... */
904 requests (while holding the private lock) before allowing the suspend to