Lines Matching full:suspend
37 low-power states like "suspend" (also known as "suspend-to-RAM"), or
39 "suspend-to-disk").
42 by implementing various role-specific suspend and resume methods to
63 transitions (suspend or hibernation).
69 various role-specific suspend and resume methods, so that the hardware
119 The core methods to suspend and resume devices reside in
227 suspend the device by putting it into a state compatible with the target
233 resume it by returning it to full power. The suspend and resume operations
236 For simple drivers, suspend might quiesce the device using class code
250 walked in a bottom-up order to suspend devices. A top-down order is
261 device to suspend) or has already suspended, as well as after all of the other
270 are used for suspend-to-idle, shallow (standby), and deep ("suspend-to-RAM")
271 sleep states and the hibernation state ("suspend-to-disk"). Each phase involves
312 Entering System Suspend
316 the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``.
323 suspend-related phases, during the ``prepare`` phase the device
332 from runtime suspend later on.
336 safely leave the device in runtime suspend (if runtime-suspended
338 runtime suspend. Namely, if the prepare callback returns a positive
341 PM core will skip the ``suspend``, ``suspend_late`` and
369 2. The ``->suspend`` methods should quiesce the device to stop it from
375 ``->suspend`` methods provided by subsystems (bus types and PM domains
377 to the devices before their drivers' ``->suspend`` methods are called.
378 Namely, they may resume the devices from runtime suspend by
382 suspend in their ``->suspend`` methods). In fact, the PM core prevents
383 subsystems or drivers from putting devices into runtime suspend at
388 3. For a number of devices it is convenient to split suspend into the
402 an error during the suspend phase by fielding a shared interrupt
424 Leaving System Suspend
450 undoing the actions of the ``suspend`` phase.
461 number, the device may have been left in runtime suspend throughout the
462 whole system suspend and resume (its ``->suspend``, ``->suspend_late``,
467 suspend if necessary. [For example, it may need to queue up a runtime
486 suspend methods were called, for example by complete reinitialization.
489 the suspend was carried out, but that can only be guaranteed if the target
490 system sleep entered was suspend-to-idle. For the other system sleep states
522 1. The ``prepare`` phase is discussed in the "Entering System Suspend"
556 8. The ``complete`` phase is discussed in the "Leaving System Suspend"
561 before putting the system into the suspend-to-idle, shallow or deep sleep state,
566 10. The ``poweroff`` phase is analogous to the ``suspend`` phase.
573 should do essentially the same things as the ``->suspend``, ``->suspend_late``
661 Device Low-Power (suspend) States
669 Some buses define rules about what different suspend states mean. PCI
670 gives one example: after the suspend sequence completes, a non-legacy
713 device's :c:member:`pm_domain` pointer is not NULL, the ``->suspend()`` callback
715 (e.g. bus type's) ``->suspend()`` callback and analogously for all of the
763 If it is necessary to resume a device from runtime suspend during a system-wide
765 :c:func:`pm_runtime_resume` from the ``->suspend`` callback (or the ``->freeze``
769 from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before*
770 invoking device drivers' ``->suspend`` callbacks (or equivalent).
778 suspend upfront in their ``->suspend`` callbacks, but that may not be really
787 runtime suspend throughout those phases of the system-wide suspend (and
799 in runtime suspend throughout the preceding "freeze" transition. Again, if the
811 general.] However, it often is desirable to leave devices in suspend after
813 runtime suspend before the preceding system-wide suspend (or analogous)
818 "early" resume callbacks to be skipped if the device can be left in suspend
821 suspend-resume cycle and on the type of the system transition under way.
828 In addition, a device is not allowed to remain in runtime suspend if any of its
833 "suspend" phase of suspend-type transitions. If the driver or the middle layer
836 clear :c:member:`power.may_skip_resume` in its ``->suspend``, ``->suspend_late``
839 their ``->suspend`` callback in case the other two are skipped.]
850 during the preceding system-wide suspend transition and its
858 ``DPM_FLAG_SMART_SUSPEND`` is set and the driver's "late" and "noirq" suspend
864 intervening ``->runtime_resume`` and system-wide suspend callbacks) and the
870 system-wide suspend-resume callbacks of the driver are present, for example.]
874 and "noirq" suspend callbacks may have been executed (in principle, regardless
877 callback back-to-back with its "late" and "noirq" suspend ones. [For instance,
879 ``DPM_FLAG_MAY_SKIP_RESUME`` and uses the same pair of suspend/resume callback
880 functions for runtime PM and system-wide suspend/resume.]