admin-guide/pm/suspend-flows.rst

1 .. SPDX-License-Identifier: GPL-2.0
5 System Suspend Code Flows
12 At least one global system-wide transition needs to be carried out for the
13 system to get from the working state into one of the supported
14 :doc:`sleep states <sleep-states>`.  Hibernation requires more than one
16 referred to as *system-wide suspend* (or simply *system suspend*) states, need
19 For those sleep states, the transition from the working state of the system into
20 the target sleep state is referred to as *system suspend* too (in the majority
21 of cases, whether this means a transition or a sleep state of the system should
23 working state is referred to as *system resume*.
26 different sleep states of the system are quite similar, but there are some
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
33 boils down to the platform-specific actions carried out by the suspend and
37 *platform-dependent suspend* states in what follows.
42 Suspend-to-idle Suspend Code Flow
45 The following steps are taken in order to transition the system from the working
46 state to the :ref:`suspend-to-idle <s2idle>` sleep state:
48  1. Invoking system-wide suspend notifiers.
53     That allows them to prepare for the change of the system state and to clean
65     put into uninterruptible sleep until the end of the subsequent system resume
68     The kernel threads that choose to be frozen during system suspend for
73     available in kernel space to synchronize themselves with system suspend and
87     phase and high-level ("action") interrupt handlers are prevented from being
91     interrupt controllers without performing any device-specific actions that
92     would be triggered in the working state of the system (those actions are
93     deferred till the subsequent system resume transition as described
96     IRQs associated with system wakeup devices are "armed" so that the resume
97     transition of the system is started when one of them signals an event.
112     From this point on, the CPUs can only be woken up by non-timer hardware
115     system wakeup, in which case the system resume transition is started.
120 Suspend-to-idle Resume Code Flow
123 The following steps are taken in order to transition the system from the
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
134     If the interrupt that has woken up the CPU was armed for system wakeup,
135     the system resume transition begins.
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
167 The following steps are taken in order to transition the system from the working
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
183     described `above <s2idle_suspend_>`_, but the arming of IRQs for system
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
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
198     configuration of system wakeup sources usually starts when system wakeup
202  4. Disabling non-boot CPUs.
204     On some platforms the suspend hooks mentioned above must run in a one-CPU
205     configuration of the system (in particular, the hardware cannot be accessed
211     to take all of the CPUs in the system, except for one (the boot CPU),
218  5. Suspending core system components.
220     This prepares the core system components for (possibly) losing power going
223  6. Platform-specific power removal.
225     This is expected to remove power from all of the system components except
227     latter) and some devices designated for system wakeup.
233 Platform-dependent Resume Code Flow
236 The following steps are taken in order to transition the system from a
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
247  2. Resuming core system components.
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