Lines Matching +full:suspend +full:- +full:to +full:- +full:ram
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
15 transition to occur for this purpose, but the other sleep states, commonly
16 referred to as *system-wide suspend* (or simply *system suspend*) states, need
20 the target sleep state is referred to as *system suspend* too (in the majority
23 working state is referred to as *system resume*.
25 The kernel code flows associated with the suspend and resume transitions for
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
34 resume hooks that need to be provided by the platform driver to make them
35 available. Apart from that, the suspend and resume code flows for these sleep
36 states are mostly identical, so they both together will be referred to as
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.
50 Kernel subsystems can register callbacks to be invoked when the suspend
51 transition is about to occur and when the resume transition has finished.
53 That allows them to prepare for the change of the system state and to clean
54 up after getting back to the working state.
58 Tasks are frozen primarily in order to avoid unchecked hardware accesses
59 from user space through MMIO regions or I/O registers exposed directly to
60 it and to prevent user space from entering the kernel while the next step
68 The kernel threads that choose to be frozen during system suspend for
70 Instead, they are expected to periodically check whether or not they need
71 to be frozen and to put themselves into uninterruptible sleep if so. [Note,
73 available in kernel space to synchronize themselves with system suspend and
79 Devices are suspended in four phases called *prepare*, *suspend*,
80 *late suspend* and *noirq suspend* (see :ref:`driverapi_pm_devices` for more
86 The runtime PM API is disabled for every device during the *late* suspend
87 phase and high-level ("action") interrupt handlers are prevented from being
88 invoked before the *noirq* suspend phase.
90 Interrupts are still handled after that, but they are only acknowledged to
91 interrupt controllers without performing any device-specific actions that
106 The last CPU to enter the idle state also stops the timekeeping which
109 That allows the CPUs to stay in the deep idle state relatively long in one
112 From this point on, the CPUs can only be woken up by non-timer hardware
113 interrupts. If that happens, they go back to the idle state unless the
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
129 leaves the idle state entered in the last step of the preceding suspend
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
152 Tasks frozen in step 2 of the preceding `suspend <s2idle_suspend_>`_
155 are allowed to exit the kernel.
157 4. Invoking system-wide resume notifiers.
159 This is analogous to step 1 of the `suspend <s2idle_suspend_>`_ transition
161 "notification type" parameter value is passed to them.
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
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
208 suspend transition).
211 to take all of the CPUs in the system, except for one (the boot CPU),
216 rerouted to the only CPU that remains online.
223 6. Platform-specific power removal.
225 This is expected to remove power from all of the system components except
226 for the memory controller and RAM (in order to preserve the contents of the
229 In many cases control is passed to the platform firmware which is expected
230 to finalize the suspend transition as needed.
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.
242 wakeup devices (which need not be an in-band hardware interrupt) and
243 control is passed back to the kernel (the working configuration of the
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.
254 The CPUs disabled in step 4 of the preceding suspend transition are taken
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