Lines Matching refs:power
8 Most of the code in Linux is device drivers, so most of the Linux power
14 power management goals, emphasizing the models and interfaces that are
21 Drivers will use one or both of these models to put devices into low-power
25 Drivers can enter low-power states as part of entering system-wide
26 low-power states like "suspend" (also known as "suspend-to-RAM"), or
32 cleanly power down hardware and software subsystems, then reactivate
36 leave the low-power state. This feature may be enabled or disabled
37 using the relevant /sys/devices/.../power/wakeup file (for Ethernet
39 purpose); enabling it may cost some power usage, but let the whole
40 system enter low-power states more often.
43 Devices may also be put into low-power states while the system is
44 running, independently of other power management activity in principle.
49 operations on the device for this purpose. Devices put into low power
50 states at run time may require special handling during system-wide power
55 the PM core are involved in runtime power management. As in the system
56 sleep power management case, they need to collaborate by implementing
60 There's not a lot to be said about those low-power states except that they are
62 have been put into low-power states (at runtime), the effect may be very similar
63 to entering some system-wide low-power state (system sleep) ... and that
65 into a state where even deeper power saving options are available.
80 device class) and device drivers to allow them to participate in the power
82 system sleep and runtime power management.
87 Device power management operations, at the subsystem level as well as at the
120 specific to runtime power management while the remaining ones are used during
121 system-wide power transitions.
123 There also is a deprecated "old" or "legacy" interface for power management
126 power management methods. Therefore it is not described in this document, so
138 classes and bus types) don't provide all power management methods.
150 /sys/devices/.../power/wakeup files
158 The "power.can_wakeup" flag just records whether the device (and its driver) can
160 affects this flag. The "power.wakeup" field is a pointer to an object of type
171 "power/wakeup" file. User space can write the strings "enabled" or "disabled"
173 system wakeup. This file is only present if the "power.wakeup" object exists
178 The "power/wakeup" file is supposed to contain the "disabled" string initially
179 for the majority of devices; the major exceptions are power buttons, keyboards,
185 The device_may_wakeup() routine returns true only if the "power.wakeup" object
186 exists and the corresponding "power/wakeup" file contains the string "enabled".
195 wakeup" used by runtime power management, although it may be supported by the
197 low-power states to trigger specific interrupts to signal conditions in which
198 they should be put into the full-power state. Those interrupts may or may not
201 case, remote wakeup should always be enabled for runtime power management for
204 /sys/devices/.../power/control files
207 runtime power management. This flag, called runtime_auto, is initialized by the
209 pm_runtime_forbid(); the default is to allow runtime power management.
212 the device's power/control sysfs file. Writing "auto" calls pm_runtime_allow(),
213 setting the flag and allowing the device to be runtime power-managed by its
215 the device to full power if it was in a low-power state, and preventing the
216 device from being runtime power-managed. User space can check the current value
220 power transitions. In particular, the device can (and in the majority of cases
221 should and will) be put into a low-power state during a system-wide transition
224 For more information about the runtime power management framework, refer to
225 Documentation/power/runtime_pm.txt.
236 When the system leaves that low-power state, the device's driver is asked to
237 resume it by returning it to full power. The suspend and resume operations
245 More power-aware drivers might prepare the devices for triggering system wakeup
327 driver in some way for the upcoming system power transition, but it
328 should not put the device into a low-power state.
330 For devices supporting runtime power management, the return value of the
353 appropriate low-power state, depending on the bus type the device is on,
359 runtime power management has been disabled for all devices.
365 device into the appropriate low-power state.
372 power.
376 state (as needed by the hardware), and placed the device into a low-power state.
378 will also switch off power supplies or reduce voltages. (Drivers supporting
388 low-power state. Instead the PM core will unwind its actions by resuming all
407 the full-power state (D0 in the PCI terminology) and restores the
434 can consult the device's power.direct_complete flag. Namely, if that
446 That means availability of certain clocks or power supplies changed,
489 However the device does not have to be put in a low-power state, and to
494 above, except that the device should not be put in a low-power state and
498 above, except again that the device should not be put in a low-power
604 Sometimes devices share reference clocks or other power resources. In those
605 cases it generally is not possible to put devices into low-power states
606 individually. Instead, a set of devices sharing a power resource can be put
607 into a low-power state together at the same time by turning off the shared
608 power resource. Of course, they also need to be put into the full-power state
609 together, by turning the shared power resource on. A set of devices with this
610 property is often referred to as a power domain.
612 Support for power domains is provided through the pm_domain field of struct
614 defined in include/linux/pm.h, providing a set of power management callbacks
616 for the given device during all power transitions, instead of the respective
620 analogously for all of the remaining callbacks. In other words, power
625 The support for device power management domains is only relevant to platforms
626 needing to use the same device driver power management callbacks in many
627 different power domain configurations and wanting to avoid incorporating the
628 support for power domains into subsystem-level callbacks, for example by
635 Device low-power states aren't standard. One device might only handle
667 There are some operations that cannot be carried out by the power management
669 To handle these cases, subsystems and device drivers may register power
675 For details refer to Documentation/power/notifiers.txt.
680 Many devices are able to dynamically power down while the system is still
682 can offer significant power savings on a running system. These devices
683 often support a range of runtime power states, which might use names such
688 A system-wide power transition can be started while some devices are in low
689 power states due to runtime power management. The system sleep PM callbacks
695 desirable to leave a suspended device in that state during a system-wide power
696 transition, but in other cases the device must be put back into the full-power
702 the full-power state, as explained in Documentation/power/runtime_pm.txt. Refer
704 for information on the device runtime power management framework in general.