Lines Matching refs:system
13 This writeup gives an overview of how drivers interact with system-wide
25 Drivers can enter low-power states as part of entering system-wide
35 Some drivers can manage hardware wakeup events, which make the system
40 system enter low-power states more often.
43 Devices may also be put into low-power states while the system is
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
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
64 synergies exist, so that several drivers using runtime PM might put the system
82 system sleep and runtime power management.
121 system-wide power transitions.
125 struct dev_pm_ops objects and it is suitable only for implementing system sleep
153 of system wakeup events (hardware signals that can force the system out of a
162 its system wakeup mechanism and for notifying the PM core of system wakeup
173 system wakeup. This file is only present if the "power.wakeup" object exists
190 device_may_wakeup() to decide what to do during a system sleep transition.
194 It ought to be noted that system wakeup is conceptually different from "remote
199 be used to signal system wakeup events, depending on the hardware design. On
200 some systems it is impossible to trigger them from system sleep states. In any
219 The device's runtime_auto flag has no effect on the handling of system-wide
221 should and will) be put into a low-power state during a system-wide transition
230 When the system goes into a sleep state, each device's driver is asked to
232 system state. That's usually some version of "off", but the details are
233 system-specific. Also, wakeup-enabled devices will usually stay partly
234 functional in order to wake the system.
236 When the system leaves that low-power state, the device's driver is asked to
245 More power-aware drivers might prepare the devices for triggering system wakeup
271 Suspending or resuming the system is done in several phases. Different phases
313 When the system goes into the freeze, standby or memory sleep state,
327 driver in some way for the upcoming system power transition, but it
339 the following system resume for all of these devices. In that case,
375 generating hardware wakeup signals to trigger a system wakeup event when the
376 system is in the sleep state. For example, enable_irq_wake() might identify
380 If any of these callbacks returns an error, the system won't enter the desired
420 system suspend and resume (the suspend, suspend_late, suspend_noirq
421 phases of system suspend and the resume_noirq, resume_early, resume
422 phases of system resume may have been skipped for it). In that case,
424 back to the functional state after system suspend if necessary. [For
450 while the system was powered down, whenever that's physically possible.
458 the system log.
463 Hibernating the system is more complicated than putting it into the other
464 sleep states, because it involves creating and saving a system image.
470 an image of the system memory while everything is stable, reactivate all
472 system (poweroff). The phases used to accomplish this are:
494 At this point the system image is created. All devices should be inactive and
496 image forms an atomic snapshot of the system state.
513 At this point the system image is saved, and the devices then need to be
514 prepared for the upcoming system shutdown. This is much like suspending them
515 before putting the system into the freeze, standby or memory sleep state,
537 a system image to be loaded into memory and the pre-hibernation memory contents
546 the system image, restores the pre-hibernation memory contents, and passes
552 To be able to load the system image into memory, the boot kernel needs to
558 creating a system image, and it is accomplished in the same way, using prepare,
568 becomes responsible for bringing the system back to the working state.
639 In contrast, integrated system-on-chip processors often use IRQs as the
646 refreshed using DMA while most of the system is sleeping lightly ... and
650 Moreover, the specific actions taken may depend on the target system state.
651 One target system state might allow a given device to be very operational;
673 Many devices are able to dynamically power down while the system is still
675 can offer significant power savings on a running system. These devices
679 usually include hardware states that are also used in system sleep states.
681 A system-wide power transition can be started while some devices are in low
682 power states due to runtime power management. The system sleep PM callbacks
688 desirable to leave a suspended device in that state during a system-wide power
690 state temporarily, for example so that its system wakeup capability can be
694 During system-wide resume from a sleep state it's easiest to put devices into