Lines Matching +full:power +full:- +full:off +full:- +full:time +full:- +full:sec
1 /* SPDX-License-Identifier: GPL-2.0-or-later */
3 * pm.h - Power management interface
48 * Device power management
53 extern const char power_group_name[]; /* = "power" */
63 * struct dev_pm_ops - device PM callbacks.
70 * registration of a child already in progress), it may return -EAGAIN, so
80 * runtime-suspended and it may be left in that state during the entire
85 * The PM core executes subsystem-level @prepare() for all devices before
90 * time and it is NOT valid to request firmware from within @prepare()
103 * The PM core executes subsystem-level @complete() after it has executed
111 * @complete() can check the power.direct_complete flag of the device to
118 * type), but generally the device must be quiescent after subsystem-level
120 * Subsystem-level @suspend() is executed for all devices after invoking
121 * subsystem-level @prepare() for all of them.
131 * requests (the device itself may be left in a low-power state, waiting
132 * for a runtime resume to occur). The state of the device at the time its
136 * Subsystem-level @resume() is executed for all devices after invoking
137 * subsystem-level @resume_noirq() for all of them.
143 * @freeze: Hibernation-specific, executed before creating a hibernation image.
145 * wakeup events or change its power state. The majority of subsystems
146 * (with the notable exception of the PCI bus type) expect the driver-level
149 * Subsystem-level @freeze() is executed for all devices after invoking
150 * subsystem-level @prepare() for all of them.
154 * events or change its power state.
156 * @thaw: Hibernation-specific, executed after creating a hibernation image OR
161 * Subsystem-level @thaw() is executed for all devices after invoking
162 * subsystem-level @thaw_noirq() for all of them. It also may be executed
168 * @poweroff: Hibernation-specific, executed after saving a hibernation image.
171 * Subsystem-level @poweroff() is executed for all devices after invoking
172 * subsystem-level @prepare() for all of them.
177 * @restore: Hibernation-specific, executed after restoring the contents of main
186 * It generally is expected that the device will be in a low-power state
187 * (appropriate for the target system sleep state) after subsystem-level
190 * configured to do so at that time. However, depending on the platform
192 * put the device into the low-power state and configure it to generate
205 * The power state of the device should not be changed by either @freeze(),
223 * able to communicate with the CPU(s) and RAM due to power management.
224 * This need not mean that the device should be put into a low-power state.
226 * off, the device may remain at full power. If the device does go to low
227 * power and is capable of generating runtime wakeup events, remote wakeup
229 * its power state via an interrupt) should be enabled for it.
233 * necessary, put the device into the full-power state and restore its
237 * low-power state if all of the necessary conditions are satisfied.
241 * Several device power state transitions are externally visible, affecting
244 * internal transitions to various low-power modes which are transparent
245 * to the rest of the driver stack (such as a driver that's ON gating off
251 * domains, device types, classes and bus types. They are the subsystem-level
254 * have to collaborate with the subsystem-level callbacks to achieve the goals
275 * There also are callbacks related to runtime power management of devices.
277 * (PM domains, device types, classes and bus types) and the subsystem-level
282 * Refer to Documentation/power/runtime_pm.rst for more information about the
284 * callbacks in device runtime power management.
378 #define _EXPORT_DEV_PM_OPS(name, sec, ns) \ argument
380 __EXPORT_SYMBOL(name, sec, ns); \
383 #define _EXPORT_DEV_PM_OPS(name, sec, ns) \ argument
460 * FREEZE System is going to hibernate, call ->prepare() and ->freeze()
463 * SUSPEND System is going to suspend, call ->prepare() and ->suspend()
466 * HIBERNATE Hibernation image has been saved, call ->prepare() and
467 * ->poweroff() for all devices.
470 * hibernation image, call ->prepare() and ->freeze() for all
473 * RESUME System is resuming, call ->resume() and ->complete() for all
476 * THAW Hibernation image has been created, call ->thaw() and
477 * ->complete() for all devices.
480 * image, call ->restore() and ->complete() for all devices.
484 * ->thaw() and ->complete() for all devices.
493 * REMOTE_WAKEUP Remote-wakeup request was received from the device.
502 #define PM_EVENT_INVALID (-1)
547 * Device run-time power management status.
551 * not reflect the actual power state of the device or its status as seen by the
555 * bus type's ->runtime_resume() callback has completed
558 * RPM_SUSPENDED Device bus type's ->runtime_suspend() callback has
562 * RPM_RESUMING Device bus type's ->runtime_resume() callback is being
565 * RPM_SUSPENDING Device bus type's ->runtime_suspend() callback is being
570 RPM_INVALID = -1,
578 * Device run-time power management request types.
582 * RPM_REQ_IDLE Run the device bus type's ->runtime_idle() callback
584 * RPM_REQ_SUSPEND Run the device bus type's ->runtime_suspend() callback
587 * been inactive for as long as power.autosuspend_delay
589 * RPM_REQ_RESUME Run the device bus type's ->runtime_resume() callback
620 * These flags can be set by device drivers at the probe time. They need not be
623 * NO_DIRECT_COMPLETE: Do not apply direct-complete optimization to the device.
624 * SMART_PREPARE: Take the driver ->prepare callback return value into account.
628 * See Documentation/driver-api/pm/devices.rst for details.
701 * struct dev_pm_domain - power management domain representation.
703 * @ops: Power management operations associated with this domain.
710 * Power domains provide callbacks that are executed during system suspend,
712 * subsystem-level and driver-level callbacks.
725 * suspend framework, based on the ->suspend() and ->resume() callbacks common
738 * a power-off reset, or it may have maintained state from the
745 * That commonly entails turning off IRQs and DMA; there may be rules
750 * SUSPEND Quiesce, enter a low power device state appropriate for
754 * HIBERNATE Enter a low power device state appropriate for the hibernation
758 * but do NOT otherwise enter a low power device state, and do
767 * A minimally power-aware driver treats all messages as SUSPEND, fully
768 * reinitializes its device during resume() -- whether or not it was reset
769 * during the suspend/resume cycle -- and can't issue wakeup events.
771 * More power-aware drivers may also use low power states at runtime as
773 * be able to use wakeup events to exit from runtime low-power states,
774 * or from system low-power states such as standby or suspend-to-RAM.