Lines Matching +full:controller +full:- +full:dependent

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
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
46 state to the :ref:`suspend-to-idle <s2idle>` sleep state:
48  1. Invoking system-wide suspend notifiers.
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
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
202  4. Disabling non-boot CPUs.
204     On some platforms the suspend hooks mentioned above must run in a one-CPU
223  6. Platform-specific power removal.
226     for the memory controller and RAM (in order to preserve the contents of the
233 Platform-dependent Resume Code Flow
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
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