Lines Matching full:suspend
45 low-power states like "suspend" (also known as "suspend-to-RAM"), or
47 "suspend-to-disk").
50 by implementing various role-specific suspend and resume methods to
71 transitions (suspend or hibernation).
77 various role-specific suspend and resume methods, so that the hardware
127 The core methods to suspend and resume devices reside in
235 suspend the device by putting it into a state compatible with the target
241 resume it by returning it to full power. The suspend and resume operations
244 For simple drivers, suspend might quiesce the device using class code
258 walked in a bottom-up order to suspend devices. A top-down order is
269 device to suspend) or has already suspended, as well as after all of the other
278 are used for suspend-to-idle, shallow (standby), and deep ("suspend-to-RAM")
279 sleep states and the hibernation state ("suspend-to-disk"). Each phase involves
320 Entering System Suspend
324 the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``.
331 suspend-related phases, during the ``prepare`` phase the device
340 from runtime suspend later on.
344 safely leave the device in runtime suspend (if runtime-suspended
346 runtime suspend. Namely, if the prepare callback returns a positive
349 PM core will skip the ``suspend``, ``suspend_late`` and
377 2. The ``->suspend`` methods should quiesce the device to stop it from
383 ``->suspend`` methods provided by subsystems (bus types and PM domains
385 to the devices before their drivers' ``->suspend`` methods are called.
386 Namely, they can only resume the devices from runtime suspend by
390 suspend in their ``->suspend`` methods).
392 3. For a number of devices it is convenient to split suspend into the
406 an error during the suspend phase by fielding a shared interrupt
428 Leaving System Suspend
454 undoing the actions of the ``suspend`` phase.
465 number, the device may have been left in runtime suspend throughout the
466 whole system suspend and resume (the ``suspend``, ``suspend_late``,
467 ``suspend_noirq`` phases of system suspend and the ``resume_noirq``,
471 suspend if necessary. [For example, it may need to queue up a runtime
490 suspend methods were called, for example by complete reinitialization.
493 the suspend was carried out, but that can only be guaranteed if the target
494 system sleep entered was suspend-to-idle. For the other system sleep states
526 1. The ``prepare`` phase is discussed in the "Entering System Suspend"
560 8. The ``complete`` phase is discussed in the "Leaving System Suspend"
565 before putting the system into the suspend-to-idle, shallow or deep sleep state,
570 10. The ``poweroff`` phase is analogous to the ``suspend`` phase.
577 should do essentially the same things as the ``->suspend``, ``->suspend_late``
663 Device Low-Power (suspend) States
671 Some buses define rules about what different suspend states mean. PCI
672 gives one example: after the suspend sequence completes, a non-legacy
715 device's :c:member:`pm_domain` pointer is not NULL, the ``->suspend()`` callback
717 (e.g. bus type's) ``->suspend()`` callback and analogously for all of the
765 If it is necessary to resume a device from runtime suspend during a system-wide
767 :c:func:`pm_runtime_resume` for it from the ``->suspend`` callback (or its
771 the state of devices (possibly except for resuming them from runtime suspend)
772 from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before*
773 invoking device drivers' ``->suspend`` callbacks (or equivalent).
776 suspend upfront in their ``->suspend`` callbacks, but that may not be really
783 runtime suspend at the beginning of the ``suspend_late`` phase of system-wide
784 suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM
803 However, it often is desirable to leave devices in suspend after system
805 runtime suspend before the preceding system-wide suspend (or analogous)
810 devices will actually be left in suspend may depend on their state before the
811 given system suspend-resume cycle and on the type of the system transition under
817 indicate to the PM core if the device may be left in suspend by setting its
819 during the "noirq" phase of the preceding system-wide suspend (or analogous)
824 device really can be left in suspend.
828 ``DPM_FLAG_LEAVE_SUSPENDED`` is set and the device is in runtime suspend during
830 proper system suspend (rather than anything related to hibernation) and the