Lines Matching refs:devices
21 Drivers will use one or both of these models to put devices into low-power
37 using the relevant /sys/devices/.../power/wakeup file (for Ethernet
45 However, devices are not generally independent of each other (for
47 devices have been suspended). Moreover, depending on the bus type the
61 very system-specific, and often device-specific. Also, that if enough devices
67 Most suspended devices will have quiesced all I/O: no more DMA or IRQs (except
81 management of devices they are concerned with. These interfaces cover both
132 The core methods to suspend and resume devices reside in struct dev_pm_ops
150 /sys/devices/.../power/wakeup files
164 devices (i.e. devices whose "can_wakeup" flags are set) and is created (or
179 for the majority of devices; the major exceptions are power buttons, keyboards,
181 ethtool. It should also default to "enabled" for devices that don't generate
188 whether or not to enable the devices' wakeup mechanisms. If device wakeup
196 same physical mechanism. Remote wakeup is a feature allowing devices in
202 all devices and drivers that support it.
204 /sys/devices/.../power/control files
233 system-specific. Also, wakeup-enabled devices will usually stay partly
245 More power-aware drivers might prepare the devices for triggering system wakeup
253 walked in a bottom-up order to suspend devices. A top-down order is
254 used to resume those devices.
256 The ordering of the device tree is defined by the order in which devices
261 (Or at least the control bus, for devices which use multiple busses.)
265 devices have been suspended. Device drivers must be prepared to cope with such
318 1. The prepare phase is meant to prevent races by preventing new devices
321 registered at will. (By contrast, devices may be unregistered at any
330 For devices supporting runtime power management, the return value of the
339 the following system resume for all of these devices. In that case,
348 is because all devices are initially set to runtime-suspended with
356 3 For a number of devices it is convenient to split suspend into the
359 runtime power management has been disabled for all devices.
368 callback. However, bus types allowing devices to share interrupt
389 the devices that were suspended.
401 permits devices to share interrupt vectors, like PCI, the method should
412 2. The resume_early methods should prepare devices for the execution of
476 The general procedure for hibernation is to quiesce all devices (freeze), create
478 devices (thaw), write the image to permanent storage, and finally shut down the
501 At this point the system image is created. All devices should be inactive and
520 At this point the system image is saved, and the devices then need to be
563 devices managed by the boot kernel need to be prepared for passing control back
566 freeze, and freeze_noirq phases. However the devices affected by these phases
567 are only those having drivers in the boot kernel; other devices will still be in
577 To achieve this, the image kernel must restore the devices' pre-hibernation
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
609 together, by turning the shared power resource on. A set of devices with this
651 Some details here may be platform-specific. Systems may have devices that
680 Many devices are able to dynamically power down while the system is still
681 running. This feature is useful for devices that are not being used, and
682 can offer significant power savings on a running system. These devices
688 A system-wide power transition can be started while some devices are in low
701 During system-wide resume from a sleep state it's easiest to put devices into