admin-guide/pm/suspend-flows.rst

1 .. SPDX-License-Identifier: GPL-2.0
12 At least one global system-wide transition needs to be carried out for the
14 :doc:`sleep states <sleep-states>`.  Hibernation requires more than one
16 referred to as *system-wide suspend* (or simply *system suspend*) states, need
27 significant differences between the :ref:`suspend-to-idle <s2idle>` code flows
28 and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and
31 The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states
32 cannot be implemented without platform support and the difference between them
33 boils down to the platform-specific actions carried out by the suspend and
34 resume hooks that need to be provided by the platform driver to make them
37 *platform-dependent suspend* states in what follows.
42 Suspend-to-idle Suspend Code Flow
46 state to the :ref:`suspend-to-idle <s2idle>` sleep state:
48  1. Invoking system-wide suspend notifiers.
69     specific reasons are frozen subsequently, but they are not intercepted.
87     phase and high-level ("action") interrupt handlers are prevented from being
91     interrupt controllers without performing any device-specific actions that
112     From this point on, the CPUs can only be woken up by non-timer hardware
120 Suspend-to-idle Resume Code Flow
124 :ref:`suspend-to-idle <s2idle>` sleep state into the working state:
128     When one of the CPUs is woken up (by a non-timer hardware interrupt), it
137  2. Resuming devices and restoring the working-state configuration of IRQs.
146     The working-state configuration of IRQs is restored after the *noirq* resume
147     phase and the runtime PM API is re-enabled for every device whose driver
157  4. Invoking system-wide resume notifiers.
164 Platform-dependent Suspend Code Flow
168 state to platform-dependent suspend state:
170  1. Invoking system-wide suspend notifiers.
172     This step is the same as step 1 of the suspend-to-idle suspend transition
177     This step is the same as step 2 of the suspend-to-idle suspend transition
182     This step is analogous to step 3 of the suspend-to-idle suspend transition
184     wakeup generally does not have any effect on the platform.
186     There are platforms that can go into a very deep low-power state internally
188     devices have been put into low-power states.  On those platforms,
189     suspend-to-idle can reduce system power very effectively.
191     On the other platforms, however, low-level components (like interrupt
192     controllers) need to be turned off in a platform-specific way (implemented
193     in the hooks provided by the platform driver) to achieve comparable power
196     That usually prevents in-band hardware interrupts from waking up the system,
197     which must be done in a special platform-dependent way.  Then, the
199     devices are suspended and is finalized by the platform suspend hooks later
202  4. Disabling non-boot CPUs.
204     On some platforms the suspend hooks mentioned above must run in a one-CPU
206     by any code running in parallel with the platform suspend hooks that may,
207     and often do, trap into the platform firmware in order to finalize the
223  6. Platform-specific power removal.
229     In many cases control is passed to the platform firmware which is expected
233 Platform-dependent Resume Code Flow
237 platform-dependent suspend state into the working state:
239  1. Platform-specific system wakeup.
241     The platform is woken up by a signal from one of the designated system
242     wakeup devices (which need not be an in-band hardware interrupt)  and
244     platform may need to be restored by the platform firmware before the
249     The suspend-time configuration of the core system components is restored and
252  3. Re-enabling non-boot CPUs.
255     back online and their suspend-time configuration is restored.
257  4. Resuming devices and restoring the working-state configuration of IRQs.
259     This step is the same as step 2 of the suspend-to-idle suspend transition
264     This step is the same as step 3 of the suspend-to-idle suspend transition
267  6. Invoking system-wide resume notifiers.
269     This step is the same as step 4 of the suspend-to-idle suspend transition