Lines Matching full:suspend

65  *	This method is executed for all kinds of suspend transitions and is
66  *	followed by one of the suspend callbacks: @suspend(), @freeze(), or
67  *	@poweroff().  If the transition is a suspend to memory or standby (that
69  *	used to indicate to the PM core to leave the device in runtime suspend
74  *	are left in runtime suspend too.  If that happens, @complete() will be
78  *	starting to invoke suspend callbacks for any of them, so generally
85  *	[To work around these limitations, drivers may register suspend and
91  *	fails before the driver's suspend callback: @suspend(), @freeze() or
92  *	@poweroff(), can be executed (e.g. if the suspend callback fails for one
94  *	suspend earlier).
97  *	@prepare() at the beginning of the suspend transition returned a
98  *	positive number and the device was left in runtime suspend (without
99  *	executing any suspend and resume callbacks for it), @complete() will be
104  *	learn whether (unset) or not (set) the previous suspend and resume
107  * @suspend: Executed before putting the system into a sleep state in which the
111  *	@suspend() has returned, so that it doesn't do any I/O or DMA.
112  *	Subsystem-level @suspend() is executed for all devices after invoking
115  * @suspend_late: Continue operations started by @suspend().  For a number of
117  *	runtime suspend callback.
136  *	Analogous to @suspend(), but it should not enable the device to signal
161  *	Analogous to @suspend(), but it need not save the device's settings in
174  * @suspend_noirq: Complete the actions started by @suspend().  Carry out any
183  *	and device's subsystem, @suspend() or @suspend_late() may be allowed to
231  *	core queue a suspend request for the device.
281 	int (*suspend)(struct device *dev);  member
306 	.suspend = suspend_fn, \
350  * Use this if you want to use the same suspend and resume callbacks for suspend
360  * (system suspend, hibernation or runtime PM).
361  * NOTE: In general, system suspend callbacks, .suspend() and .resume(), should
364  * quiescent device, while .suspend() should assume that the device may be doing
367  * suspend and "early" resume callback pointers, .suspend_late() and
381  * core, in order to provide a mechanism allowing the high level suspend and
390  * SUSPEND	System is going to suspend, call ->prepare() and ->suspend()
416  * USER_SUSPEND		Manual selective suspend was issued by userspace.
422  * AUTO_SUSPEND		Automatic (device idle) runtime suspend was
542  * Driver flags to control system suspend/resume behavior.
547  * NEVER_SKIP: Do not skip all system suspend/resume callbacks for the device.
549  * SMART_SUSPEND: No need to resume the device from runtime suspend.
553  * system suspend/resume callbacks to be skipped for the device to return 0 from
555  * other words, the system suspend/resume callbacks can only be skipped for the
560  * runtime resume the device upfront during system suspend that doing so is not
563  * the driver if they decide to leave the device in runtime suspend.
566  * driver prefers the device to be left in suspend after system resume.
645  * Power domains provide callbacks that are executed during system suspend,
659  * suspend framework, based on the ->suspend() and ->resume() callbacks common
660  * for suspend and hibernation transitions, according to the rules below.
667  * One transition is triggered by resume(), after a suspend() call; the
673  *		previous suspend() which the driver will rely on while
677  * Other transitions are triggered by messages sent using suspend().  All
684  * SUSPEND	Quiesce, enter a low power device state appropriate for
701  * A minimally power-aware driver treats all messages as SUSPEND, fully
703  * during the suspend/resume cycle -- and can't issue wakeup events.
708  * or from system low-power states such as standby or suspend-to-RAM.