Lines Matching full:system
22 This writeup gives an overview of how drivers interact with system-wide
34 System Sleep model:
36 Drivers can enter low-power states as part of entering system-wide
46 Some drivers can manage hardware wakeup events, which make the system
51 whole system enter low-power states more often.
55 Devices may also be put into low-power states while the system is
62 states at run time may require special handling during system-wide power
67 the PM core are involved in runtime power management. As in the system
73 very system-specific, and often device-specific. Also, that if enough devices
75 to entering some system-wide low-power state (system sleep) ... and that
76 synergies exist, so that several drivers using runtime PM might put the system
88 Interfaces for Entering System Sleep States
94 system sleep and runtime power management.
105 management while the remaining ones are used during system-wide power
110 struct dev_pm_ops objects and it is suitable only for implementing system
142 of system wakeup events (hardware signals that can force the system out of a
152 its system wakeup mechanism and for notifying the PM core of system wakeup
163 to signal system wakeup. This file is only present if the
181 during a system sleep transition. Device drivers, however, are not expected to
184 It ought to be noted that system wakeup is conceptually different from "remote
189 be used to signal system wakeup events, depending on the hardware design. On
190 some systems it is impossible to trigger them from system sleep states. In any
214 system-wide power transitions. In particular, the device can (and in the
216 system-wide transition to a sleep state even though its :c:member:`runtime_auto`
223 Calling Drivers to Enter and Leave System Sleep States
226 When the system goes into a sleep state, each device's driver is asked to
228 system state. That's usually some version of "off", but the details are
229 system-specific. Also, wakeup-enabled devices will usually stay partly
230 functional in order to wake the system.
232 When the system leaves that low-power state, the device's driver is asked to
241 More power-aware drivers might prepare the devices for triggering system wakeup
266 System Power Management Phases
269 Suspending or resuming the system is done in several phases. Different phases
312 Entering System Suspend
315 When the system goes into the freeze, standby or memory sleep state,
328 driver in some way for the upcoming system power transition, but it
350 that if a device has system-sleep callbacks but does not support runtime
414 prepared for generating hardware wakeup signals to trigger a system wakeup event
415 when the system is in the sleep state. For example, :c:func:`enable_irq_wake()`
419 If any of these callbacks returns an error, the system won't enter the desired
424 Leaving System Suspend
462 whole system suspend and resume (its ``->suspend``, ``->suspend_late``,
466 responsible for putting the device into a consistent state after system
490 system sleep entered was suspend-to-idle. For the other system sleep states
491 that may not be the case (and usually isn't for ACPI-defined system sleep
495 while the system was powered down, whenever that's physically possible.
503 the system log.
509 Hibernating the system is more complicated than putting it into sleep states,
510 because it involves creating and saving a system image. Therefore there are
515 create an image of the system memory while everything is stable, reactivate all
517 the system ("power off"). The phases used to accomplish this are: ``prepare``,
522 1. The ``prepare`` phase is discussed in the "Entering System Suspend"
539 At this point the system image is created. All devices should be inactive and
541 image forms an atomic snapshot of the system state.
556 8. The ``complete`` phase is discussed in the "Leaving System Suspend"
559 At this point the system image is saved, and the devices then need to be
560 prepared for the upcoming system shutdown. This is much like suspending them
561 before putting the system into the suspend-to-idle, shallow or deep sleep state,
578 the entire system, so it is not necessary for the callback to put the device in
587 a system image to be loaded into memory and the pre-hibernation memory contents
596 reads the system image, restores the pre-hibernation memory contents, and passes
603 To be able to load the system image into memory, the restore kernel needs to
609 creating a system image, and it is accomplished in the same way, using
619 to the image kernel, which then becomes responsible for bringing the system back
675 In contrast, integrated system-on-chip processors often use IRQs as the
682 refreshed using DMA while most of the system is sleeping lightly ... and
686 Moreover, the specific actions taken may depend on the target system state.
687 One target system state might allow a given device to be very operational;
742 Many devices are able to dynamically power down while the system is still
744 can offer significant power savings on a running system. These devices
748 usually include hardware states that are also used in system sleep states.
750 A system-wide power transition can be started while some devices are in low
751 power states due to runtime power management. The system sleep PM callbacks
757 desirable to leave a suspended device in that state during a system-wide power
759 state temporarily, for example so that its system wakeup capability can be
763 If it is necessary to resume a device from runtime suspend during a system-wide
787 runtime suspend throughout those phases of the system-wide suspend (and
788 similarly for the "freeze" and "poweroff" parts of system hibernation).
791 be valid in general.] If the middle-layer system-wide PM callbacks are present
807 During system-wide resume from a sleep state it's easiest to put devices into
812 system transitions to the working state, especially if those devices had been in
813 runtime suspend before the preceding system-wide suspend (or analogous)
819 after system-wide PM transitions to the working state. Whether or not that is
820 the case generally depends on the state of the device before the given system
821 suspend-resume cycle and on the type of the system transition under way.
835 being skipped during the subsequent system resume transition, it should
850 during the preceding system-wide suspend transition and its
855 system-wide resume-type transitions.]
859 callbacks are skipped, its system-wide "noirq" and "early" resume callbacks, if
862 driver must be prepared to cope with the invocation of its system-wide resume
864 intervening ``->runtime_resume`` and system-wide suspend callbacks) and the
870 system-wide suspend-resume callbacks of the driver are present, for example.]
873 system-wide "noirq" and "early" resume callbacks may be skipped while its "late"
880 functions for runtime PM and system-wide suspend/resume.]