include/linux/pm.h

2  *  pm.h - Power management interface
18  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
39  * Device power management
45 extern const char power_group_name[];		/* = "power" */
55  * struct dev_pm_ops - device PM callbacks
57  * Several device power state transitions are externally visible, affecting
60  * internal transitions to various low-power modes which are transparent
66  * involved.  First, the PM core executes callbacks provided by PM domains,
67  * device types, classes and bus types.  They are the subsystem-level callbacks
70  * collaborate with the subsystem-level callbacks to achieve the goals
79  *	registration of a child already in progress), it may return -EAGAIN, so
84  *	@poweroff().  The PM core executes subsystem-level @prepare() for all
102  *	The PM core executes subsystem-level @complete() after it has executed
108  *	type), but generally the device must be quiescent after subsystem-level
110  *	Subsystem-level @suspend() is executed for all devices after invoking
111  *	subsystem-level @prepare() for all of them.
117  *	requests (the device itself may be left in a low-power state, waiting
122  *	Subsystem-level @resume() is executed for all devices after invoking
123  *	subsystem-level @resume_noirq() for all of them.
125  * @freeze: Hibernation-specific, executed before creating a hibernation image.
127  *	wakeup events or change its power state.  The majority of subsystems
128  *	(with the notable exception of the PCI bus type) expect the driver-level
131  *	Subsystem-level @freeze() is executed for all devices after invoking
132  *	subsystem-level @prepare() for all of them.
134  * @thaw: Hibernation-specific, executed after creating a hibernation image OR
139  *	Subsystem-level @thaw() is executed for all devices after invoking
140  *	subsystem-level @thaw_noirq() for all of them.  It also may be executed
143  * @poweroff: Hibernation-specific, executed after saving a hibernation image.
146  *	Subsystem-level @poweroff() is executed for all devices after invoking
147  *	subsystem-level @prepare() for all of them.
149  * @restore: Hibernation-specific, executed after restoring the contents of main
156  *	It generally is expected that the device will be in a low-power state
157  *	(appropriate for the target system sleep state) after subsystem-level
162  *	the low-power state and configure it to generate wakeup signals, in
174  *	The power state of the device should not be changed by either @freeze()
209  * Refer to Documentation/power/devices.txt for more information about the role
212  * There also are callbacks related to runtime power management of devices.
214  * (PM domains, device types, classes and bus types) and the subsystem-level
220  *	able to communicate with the CPU(s) and RAM due to power management.
221  *	This need not mean that the device should be put into a low-power state.
223  *	off, the device may remain at full power.  If the device does go to low
224  *	power and is capable of generating runtime wakeup events, remote wakeup
226  *	its power state via an interrupt) should be enabled for it.
230  *	necessary, put the device into the full-power state and restore its
234  *	low-power state if all of the necessary conditions are satisfied.  Check
238  * Refer to Documentation/power/runtime_pm.txt for more information about the
239  * role of the above callbacks in device runtime power management.
313  * FREEZE 	System is going to hibernate, call ->prepare() and ->freeze()
316  * SUSPEND	System is going to suspend, call ->prepare() and ->suspend()
319  * HIBERNATE	Hibernation image has been saved, call ->prepare() and
320  *		->poweroff() for all devices.
323  *		hibernation image, call ->prepare() and ->freeze() for all
326  * RESUME	System is resuming, call ->resume() and ->complete() for all
329  * THAW		Hibernation image has been created, call ->thaw() and
330  *		->complete() for all devices.
333  *		image, call ->restore() and ->complete() for all devices.
337  *		->thaw() and ->complete() for all devices.
346  * REMOTE_WAKEUP	Remote-wakeup request was received from the device.
355 #define PM_EVENT_INVALID	(-1)
400  * Device run-time power management status.
404  * not reflect the actual power state of the device or its status as seen by the
408  *			bus type's ->runtime_resume() callback has completed
411  * RPM_SUSPENDED	Device bus type's ->runtime_suspend() callback has
415  * RPM_RESUMING		Device bus type's ->runtime_resume() callback is being
418  * RPM_SUSPENDING	Device bus type's ->runtime_suspend() callback is being
430  * Device run-time power management request types.
434  * RPM_REQ_IDLE		Run the device bus type's ->runtime_idle() callback
436  * RPM_REQ_SUSPEND	Run the device bus type's ->runtime_suspend() callback
439  *			been inactive for as long as power.autosuspend_delay
441  * RPM_REQ_RESUME	Run the device bus type's ->runtime_resume() callback
523  * Power domains provide callbacks that are executed during system suspend,
525  * subsystem-level and driver-level callbacks.
533  * suspend framework, based on the ->suspend() and ->resume() callbacks common
546  * 		a power-off reset, or it may have maintained state from the
558  * SUSPEND	Quiesce, enter a low power device state appropriate for
562  * HIBERNATE	Enter a low power device state appropriate for the hibernation
566  * 		but do NOT otherwise enter a low power device state, and do
575  * A minimally power-aware driver treats all messages as SUSPEND, fully
576  * reinitializes its device during resume() -- whether or not it was reset
577  * during the suspend/resume cycle -- and can't issue wakeup events.
579  * More power-aware drivers may also use low power states at runtime as
581  * be able to use wakeup events to exit from runtime low-power states,
582  * or from system low-power states such as standby or suspend-to-RAM.