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
539 parent won't be able to suspend at run time, using the PM core's helper
561 It may be desirable to suspend the device once ->probe() has finished.
597 Runtime PM and system sleep (i.e., system suspend and hibernation, also known
598 as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
603 For example, remote wake-up may be enabled for runtime suspend but disallowed
605 the subsystem-level system suspend callback is responsible for changing the
607 suspend routine).  It may be necessary to resume the device and suspend it again
609 or other settings for runtime suspend and system sleep.
612 power, even if they had been suspended before the system suspend began.  There
630 If the device had been suspended before the system suspend began and it's
640 ->suspend() callback and decrements it after calling the ->resume() callback.
642 suspend attempts to be permanently lost.  If the usage count goes to zero
656 suspend began in the suspended state.
659 different levels of device hierarchy.  Namely, if a system suspend .prepare()
662 may be left in runtime suspend provided that all of its descendants are also
663 left in runtime suspend.  If that happens, the PM core will not execute any
664 system suspend and resume callbacks for all of those devices, except for the
666 as appropriate.  This only applies to system suspend transitions that are not
671 the runtime PM and system suspend/resume (and hibernation) callbacks by carrying
674   * During system suspend pm_runtime_get_noresume() is called for every device
677     subsystem-level .suspend() callback for it.  In addition to that the PM core
702     - if the device has not been suspended at run time, invoke the ->suspend()
757 ->runtime_resume(), ->suspend(), ->suspend_noirq(), ->resume(),
762 Device drivers that wish to use the same function as a system suspend, freeze,
763 poweroff and runtime suspend callback, and similarly for system resume, thaw,
840 itself because no suspend requests of any kind are accepted while the device is
882 			/* ... suspend the device ... */
906 requests (while holding the private lock) before allowing the suspend to