Lines Matching refs:and
14 power management goals, emphasizing the models and interfaces that are
30 This is something that device, bus, and class drivers collaborate on
31 by implementing various role-specific suspend and resume methods to
32 cleanly power down hardware and software subsystems, then reactivate
54 appropriate subsystem (bus type, device type or device class) driver and
57 various role-specific suspend and resume methods, so that the hardware
58 is cleanly powered down and reactivated without data or service loss.
61 very system-specific, and often device-specific. Also, that if enough devices
63 to entering some system-wide low-power state (system sleep) ... and that
68 for wakeup events), no more data read or written, and requests from upstream
73 network wake-on-LAN packets, keyboard or mouse activity, and media insertion
74 or removal (for PCMCIA, MMC/SD, USB, and so on).
80 device class) and device drivers to allow them to participate in the power
82 system sleep and runtime power management.
88 device driver level, are implemented by defining and populating objects of type
117 This structure is defined in include/linux/pm.h and the methods included in it
125 struct dev_pm_ops objects and it is suitable only for implementing system sleep
132 The core methods to suspend and resume devices reside in struct dev_pm_ops
134 struct bus_type, struct device_type and struct class. They are mostly of
135 interest to the people writing infrastructure for platforms and buses, like PCI
136 or USB, or device type and device class drivers. They also are relevant to the
138 classes and bus types) don't provide all power management methods.
140 Bus drivers implement these methods as appropriate for the hardware and the
141 drivers using it; PCI works differently from USB, and so on. Not many people
155 device_set_wakeup_capable() and device_set_wakeup_enable(), defined in
158 The "power.can_wakeup" flag just records whether the device (and its driver) can
162 its system wakeup mechanism and for notifying the PM core of system wakeup
164 devices (i.e. devices whose "can_wakeup" flags are set) and is created (or
168 matter, and the kernel is responsible for keeping track of it. By contrast,
170 decision, and it is managed by user space through a sysfs attribute: the
174 for the given device and is created (or removed) along with that object, by
180 and Ethernet adapters whose WoL (wake-on-LAN) feature has been set up with
186 exists and the corresponding "power/wakeup" file contains the string "enabled".
202 all devices and drivers that support it.
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
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
228 Calling Drivers to Enter and Leave System Sleep States
237 resume it by returning it to full power. The suspend and resume operations
238 always go together, and both are multi-phase operations.
241 and then turn its hardware as "off" as possible during suspend_noirq. The
251 To ensure that bridges and similar links needing to talk to a device are
258 its parent; and can't be removed or suspended after that parent.
272 are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the
275 support all these callbacks and not all drivers use all the callbacks. The
276 various phases always run after tasks have been frozen and before they are
284 other callbacks and, for example, type callbacks take precedence over bus, class
285 and driver callbacks. To be precise, the following rules are used to determine
291 2. Otherwise, if both dev->type and dev->type->pm are present, the callback
294 3. Otherwise, if both dev->class and dev->class->pm are present, the
297 4. Otherwise, if both dev->bus and dev->bus->pm are present, the callback
300 This allows PM domains and device types to override callbacks provided by bus
303 The PM domain, type, class and bus callbacks may in turn invoke device- or
335 number and that happens for all of the descendants of the device too,
336 and all of them (including the device itself) are runtime-suspended, the
337 PM core will skip the suspend, suspend_late and suspend_noirq suspend
338 phases as well as the resume_noirq, resume_early and resume phases of
341 and is entirely responsible for bringing the device back to the
345 I/O. They also may save the device registers and put it into the
347 and they may enable wakeup events.
350 "quiesce device" and "save device state" phases, in which cases
357 the device's registers that weren't saved previously and finally put the
360 The majority of subsystems and device drivers need not implement this
369 state (as needed by the hardware), and placed the device into a low-power state.
377 GPIO signals hooked up to a switch or other external hardware, and
395 bring the device and its driver into a state in which the driver can
397 and handle them correctly.
400 the full-power state (D0 in the PCI terminology) and restores the
420 system suspend and resume (the suspend, suspend_late, suspend_noirq
421 phases of system suspend and the resume_noirq, resume_early, resume
429 directly after the preceding prepare and special action may be required
433 suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are
437 some systems support multiple "run" states, and the mode in effect at
444 This may be the hardest part, and the one most protected by NDA'd documents
445 and chip errata. It's simplest if the hardware state hasn't changed since
451 PCMCIA, MMC, USB, Firewire, SCSI, and even IDE are common examples of busses
453 will notice and handle such removals are currently bus-specific, and often
464 sleep states, because it involves creating and saving a system image.
466 callbacks. These phases always run after tasks have been frozen and memory has
471 devices (thaw), write the image to permanent storage, and finally shut down the
481 IRQs or DMA, and they may need to save the values of device registers.
482 However the device does not have to be put in a low-power state, and to
487 above, except that the device should not be put in a low-power state and
492 state and should not be allowed to generate wakeup events.
494 At this point the system image is created. All devices should be inactive and
513 At this point the system image is saved, and the devices then need to be
516 and the phases are similar.
526 The poweroff, poweroff_late and poweroff_noirq callbacks should do essentially
527 the same things as the suspend, suspend_late and suspend_noirq callbacks,
537 a system image to be loaded into memory and the pre-hibernation memory contents
540 Although in principle, the image might be loaded into memory and the
542 can't be done because boot loaders aren't smart enough and there is no
545 memory and passes control to it in the usual way. Then the boot kernel reads
546 the system image, restores the pre-hibernation memory contents, and passes
549 from the image kernel: a different configuration and even a different version.
550 This has important consequences for device drivers and their subsystems.
558 creating a system image, and it is accomplished in the same way, using prepare,
559 freeze, and freeze_noirq phases. However the devices affected by these phases
565 thaw_noirq, thaw, and complete phases, and then continue running normally. This
567 restored successfully and control is passed to the image kernel, which then
585 must assume the device has been accessed and reconfigured by the boot loader or
587 state remembered from the freeze, freeze_late and freeze_noirq phases. The
588 device may even need to be reset and completely re-initialized. In many cases
589 this difference doesn't matter, so the resume[_early|_noirq] and
608 analogous to the subsystem-level and device driver callbacks that are executed
612 executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and
620 different power domain configurations and wanting to avoid incorporating the
629 "on" and "off", while another might support a dozen different versions of
635 PCI device may not perform DMA or issue IRQs, and any wakeup events it
640 wakeup event sources (so drivers would call enable_irq_wake) and might
642 active too, it'd only be the CPU and some peripherals that sleep).
646 refreshed using DMA while most of the system is sleeping lightly ... and
662 To handle these cases, subsystems and device drivers may register power
663 management notifiers that are called before tasks are frozen and after they have
674 running. This feature is useful for devices that are not being used, and
677 as "off", "sleep", "idle", "active", and so on. Those states will in some
678 cases (like PCI) be partially constrained by the bus the device uses, and will
683 should recognize such situations and react to them appropriately, but the
691 disabled. This all depends on the hardware and the design of the subsystem and