Lines Matching full:system
30 This writeup gives an overview of how drivers interact with system-wide
42 System Sleep model:
44 Drivers can enter low-power states as part of entering system-wide
54 Some drivers can manage hardware wakeup events, which make the system
59 whole system enter low-power states more often.
63 Devices may also be put into low-power states while the system is
70 states at run time may require special handling during system-wide power
75 the PM core are involved in runtime power management. As in the system
81 very system-specific, and often device-specific. Also, that if enough devices
83 to entering some system-wide low-power state (system sleep) ... and that
84 synergies exist, so that several drivers using runtime PM might put the system
96 Interfaces for Entering System Sleep States
102 system sleep and runtime power management.
113 management while the remaining ones are used during system-wide power
118 |struct dev_pm_ops| objects and it is suitable only for implementing system
150 of system wakeup events (hardware signals that can force the system out of a
160 its system wakeup mechanism and for notifying the PM core of system wakeup
171 to signal system wakeup. This file is only present if the
189 during a system sleep transition. Device drivers, however, are not expected to
192 It ought to be noted that system wakeup is conceptually different from "remote
197 be used to signal system wakeup events, depending on the hardware design. On
198 some systems it is impossible to trigger them from system sleep states. In any
222 system-wide power transitions. In particular, the device can (and in the
224 system-wide transition to a sleep state even though its :c:member:`runtime_auto`
231 Calling Drivers to Enter and Leave System Sleep States
234 When the system goes into a sleep state, each device's driver is asked to
236 system state. That's usually some version of "off", but the details are
237 system-specific. Also, wakeup-enabled devices will usually stay partly
238 functional in order to wake the system.
240 When the system leaves that low-power state, the device's driver is asked to
249 More power-aware drivers might prepare the devices for triggering system wakeup
274 System Power Management Phases
277 Suspending or resuming the system is done in several phases. Different phases
320 Entering System Suspend
323 When the system goes into the freeze, standby or memory sleep state,
336 driver in some way for the upcoming system power transition, but it
358 that if a device has system-sleep callbacks but does not support runtime
418 prepared for generating hardware wakeup signals to trigger a system wakeup event
419 when the system is in the sleep state. For example, :c:func:`enable_irq_wake()`
423 If any of these callbacks returns an error, the system won't enter the desired
428 Leaving System Suspend
466 whole system suspend and resume (the ``suspend``, ``suspend_late``,
467 ``suspend_noirq`` phases of system suspend and the ``resume_noirq``,
468 ``resume_early``, ``resume`` phases of system resume may have been
470 responsible for putting the device into a consistent state after system
494 system sleep entered was suspend-to-idle. For the other system sleep states
495 that may not be the case (and usually isn't for ACPI-defined system sleep
499 while the system was powered down, whenever that's physically possible.
507 the system log.
513 Hibernating the system is more complicated than putting it into sleep states,
514 because it involves creating and saving a system image. Therefore there are
519 create an image of the system memory while everything is stable, reactivate all
521 the system ("power off"). The phases used to accomplish this are: ``prepare``,
526 1. The ``prepare`` phase is discussed in the "Entering System Suspend"
543 At this point the system image is created. All devices should be inactive and
545 image forms an atomic snapshot of the system state.
560 8. The ``complete`` phase is discussed in the "Leaving System Suspend"
563 At this point the system image is saved, and the devices then need to be
564 prepared for the upcoming system shutdown. This is much like suspending them
565 before putting the system into the suspend-to-idle, shallow or deep sleep state,
589 a system image to be loaded into memory and the pre-hibernation memory contents
598 reads the system image, restores the pre-hibernation memory contents, and passes
605 To be able to load the system image into memory, the restore kernel needs to
611 creating a system image, and it is accomplished in the same way, using
621 to the image kernel, which then becomes responsible for bringing the system back
677 In contrast, integrated system-on-chip processors often use IRQs as the
684 refreshed using DMA while most of the system is sleeping lightly ... and
688 Moreover, the specific actions taken may depend on the target system state.
689 One target system state might allow a given device to be very operational;
744 Many devices are able to dynamically power down while the system is still
746 can offer significant power savings on a running system. These devices
750 usually include hardware states that are also used in system sleep states.
752 A system-wide power transition can be started while some devices are in low
753 power states due to runtime power management. The system sleep PM callbacks
759 desirable to leave a suspended device in that state during a system-wide power
761 state temporarily, for example so that its system wakeup capability can be
765 If it is necessary to resume a device from runtime suspend during a system-wide
783 runtime suspend at the beginning of the ``suspend_late`` phase of system-wide
786 after that point until the system-wide transition is over (the PM core itself
787 does that for devices whose "noirq", "late" and "early" system-wide PM callbacks
788 are executed directly by it). If that happens, the driver's system-wide resume
789 callbacks, if present, may still be invoked during the subsequent system-wide
792 cope with the invocation of its system-wide resume callbacks back-to-back with
797 During system-wide resume from a sleep state it's easiest to put devices into
803 However, it often is desirable to leave devices in suspend after system
805 runtime suspend before the preceding system-wide suspend (or analogous)
809 skipping their system-wide resume callbacks for this reason. Whether or not the
811 given system suspend-resume cycle and on the type of the system transition under
819 during the "noirq" phase of the preceding system-wide suspend (or analogous)
827 directly by the PM core, all of the system-wide resume callbacks are skipped if
830 proper system suspend (rather than anything related to hibernation) and the
832 generate wakeup signals at all or it is allowed to wake up the system from