^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) .. include:: <isonum.txt>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) System Suspend Code Flows
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) :Copyright: |copy| 2020 Intel Corporation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) :Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) At least one global system-wide transition needs to be carried out for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) system to get from the working state into one of the supported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) :doc:`sleep states <sleep-states>`. Hibernation requires more than one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) transition to occur for this purpose, but the other sleep states, commonly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) referred to as *system-wide suspend* (or simply *system suspend*) states, need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) only one.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) For those sleep states, the transition from the working state of the system into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) the target sleep state is referred to as *system suspend* too (in the majority
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) of cases, whether this means a transition or a sleep state of the system should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) be clear from the context) and the transition back from the sleep state into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) working state is referred to as *system resume*.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) The kernel code flows associated with the suspend and resume transitions for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) different sleep states of the system are quite similar, but there are some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) significant differences between the :ref:`suspend-to-idle <s2idle>` code flows
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) :ref:`standby <standby>` sleep states.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) cannot be implemented without platform support and the difference between them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) boils down to the platform-specific actions carried out by the suspend and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) resume hooks that need to be provided by the platform driver to make them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) available. Apart from that, the suspend and resume code flows for these sleep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) states are mostly identical, so they both together will be referred to as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) *platform-dependent suspend* states in what follows.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) .. _s2idle_suspend:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) Suspend-to-idle Suspend Code Flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) The following steps are taken in order to transition the system from the working
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) state to the :ref:`suspend-to-idle <s2idle>` sleep state:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) 1. Invoking system-wide suspend notifiers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) Kernel subsystems can register callbacks to be invoked when the suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) transition is about to occur and when the resume transition has finished.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) That allows them to prepare for the change of the system state and to clean
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) up after getting back to the working state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) 2. Freezing tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) Tasks are frozen primarily in order to avoid unchecked hardware accesses
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) from user space through MMIO regions or I/O registers exposed directly to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) it and to prevent user space from entering the kernel while the next step
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) of the transition is in progress (which might have been problematic for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) various reasons).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) All user space tasks are intercepted as though they were sent a signal and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) put into uninterruptible sleep until the end of the subsequent system resume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) transition.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) The kernel threads that choose to be frozen during system suspend for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) specific reasons are frozen subsequently, but they are not intercepted.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) Instead, they are expected to periodically check whether or not they need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) to be frozen and to put themselves into uninterruptible sleep if so. [Note,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) however, that kernel threads can use locking and other concurrency controls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) available in kernel space to synchronize themselves with system suspend and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) resume, which can be much more precise than the freezing, so the latter is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) not a recommended option for kernel threads.]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) 3. Suspending devices and reconfiguring IRQs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) Devices are suspended in four phases called *prepare*, *suspend*,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) *late suspend* and *noirq suspend* (see :ref:`driverapi_pm_devices` for more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) information on what exactly happens in each phase).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Every device is visited in each phase, but typically it is not physically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) accessed in more than two of them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) The runtime PM API is disabled for every device during the *late* suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) phase and high-level ("action") interrupt handlers are prevented from being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) invoked before the *noirq* suspend phase.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) Interrupts are still handled after that, but they are only acknowledged to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) interrupt controllers without performing any device-specific actions that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) would be triggered in the working state of the system (those actions are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) deferred till the subsequent system resume transition as described
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) `below <s2idle_resume_>`_).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) IRQs associated with system wakeup devices are "armed" so that the resume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) transition of the system is started when one of them signals an event.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) 4. Freezing the scheduler tick and suspending timekeeping.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) When all devices have been suspended, CPUs enter the idle loop and are put
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) into the deepest available idle state. While doing that, each of them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) "freezes" its own scheduler tick so that the timer events associated with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) the tick do not occur until the CPU is woken up by another interrupt source.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) The last CPU to enter the idle state also stops the timekeeping which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) (among other things) prevents high resolution timers from triggering going
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) forward until the first CPU that is woken up restarts the timekeeping.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) That allows the CPUs to stay in the deep idle state relatively long in one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) go.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) From this point on, the CPUs can only be woken up by non-timer hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) interrupts. If that happens, they go back to the idle state unless the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) interrupt that woke up one of them comes from an IRQ that has been armed for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) system wakeup, in which case the system resume transition is started.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) .. _s2idle_resume:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) Suspend-to-idle Resume Code Flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) The following steps are taken in order to transition the system from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) :ref:`suspend-to-idle <s2idle>` sleep state into the working state:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) 1. Resuming timekeeping and unfreezing the scheduler tick.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) When one of the CPUs is woken up (by a non-timer hardware interrupt), it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) leaves the idle state entered in the last step of the preceding suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) transition, restarts the timekeeping (unless it has been restarted already
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) by another CPU that woke up earlier) and the scheduler tick on that CPU is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) unfrozen.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) If the interrupt that has woken up the CPU was armed for system wakeup,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) the system resume transition begins.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) 2. Resuming devices and restoring the working-state configuration of IRQs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) Devices are resumed in four phases called *noirq resume*, *early resume*,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) *resume* and *complete* (see :ref:`driverapi_pm_devices` for more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) information on what exactly happens in each phase).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) Every device is visited in each phase, but typically it is not physically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) accessed in more than two of them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) The working-state configuration of IRQs is restored after the *noirq* resume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) phase and the runtime PM API is re-enabled for every device whose driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) supports it during the *early* resume phase.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) 3. Thawing tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) Tasks frozen in step 2 of the preceding `suspend <s2idle_suspend_>`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) transition are "thawed", which means that they are woken up from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) uninterruptible sleep that they went into at that time and user space tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) are allowed to exit the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) 4. Invoking system-wide resume notifiers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) This is analogous to step 1 of the `suspend <s2idle_suspend_>`_ transition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) and the same set of callbacks is invoked at this point, but a different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) "notification type" parameter value is passed to them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) Platform-dependent Suspend Code Flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) ====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) The following steps are taken in order to transition the system from the working
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) state to platform-dependent suspend state:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) 1. Invoking system-wide suspend notifiers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) This step is the same as step 1 of the suspend-to-idle suspend transition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) described `above <s2idle_suspend_>`_.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) 2. Freezing tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) This step is the same as step 2 of the suspend-to-idle suspend transition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) described `above <s2idle_suspend_>`_.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) 3. Suspending devices and reconfiguring IRQs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) This step is analogous to step 3 of the suspend-to-idle suspend transition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) described `above <s2idle_suspend_>`_, but the arming of IRQs for system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) wakeup generally does not have any effect on the platform.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) There are platforms that can go into a very deep low-power state internally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) when all CPUs in them are in sufficiently deep idle states and all I/O
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) devices have been put into low-power states. On those platforms,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) suspend-to-idle can reduce system power very effectively.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) On the other platforms, however, low-level components (like interrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) controllers) need to be turned off in a platform-specific way (implemented
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) in the hooks provided by the platform driver) to achieve comparable power
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) reduction.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) That usually prevents in-band hardware interrupts from waking up the system,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) which must be done in a special platform-dependent way. Then, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) configuration of system wakeup sources usually starts when system wakeup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) devices are suspended and is finalized by the platform suspend hooks later
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) on.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) 4. Disabling non-boot CPUs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) On some platforms the suspend hooks mentioned above must run in a one-CPU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) configuration of the system (in particular, the hardware cannot be accessed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) by any code running in parallel with the platform suspend hooks that may,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) and often do, trap into the platform firmware in order to finalize the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) suspend transition).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) For this reason, the CPU offline/online (CPU hotplug) framework is used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) to take all of the CPUs in the system, except for one (the boot CPU),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) offline (typically, the CPUs that have been taken offline go into deep idle
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) states).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) This means that all tasks are migrated away from those CPUs and all IRQs are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) rerouted to the only CPU that remains online.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) 5. Suspending core system components.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) This prepares the core system components for (possibly) losing power going
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) forward and suspends the timekeeping.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) 6. Platform-specific power removal.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) This is expected to remove power from all of the system components except
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) for the memory controller and RAM (in order to preserve the contents of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) latter) and some devices designated for system wakeup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) In many cases control is passed to the platform firmware which is expected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) to finalize the suspend transition as needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) Platform-dependent Resume Code Flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) ===================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) The following steps are taken in order to transition the system from a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) platform-dependent suspend state into the working state:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) 1. Platform-specific system wakeup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) The platform is woken up by a signal from one of the designated system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) wakeup devices (which need not be an in-band hardware interrupt) and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) control is passed back to the kernel (the working configuration of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) platform may need to be restored by the platform firmware before the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) kernel gets control again).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) 2. Resuming core system components.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) The suspend-time configuration of the core system components is restored and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) the timekeeping is resumed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) 3. Re-enabling non-boot CPUs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) The CPUs disabled in step 4 of the preceding suspend transition are taken
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) back online and their suspend-time configuration is restored.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) 4. Resuming devices and restoring the working-state configuration of IRQs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) This step is the same as step 2 of the suspend-to-idle suspend transition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) described `above <s2idle_resume_>`_.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) 5. Thawing tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) This step is the same as step 3 of the suspend-to-idle suspend transition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) described `above <s2idle_resume_>`_.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) 6. Invoking system-wide resume notifiers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) This step is the same as step 4 of the suspend-to-idle suspend transition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) described `above <s2idle_resume_>`_.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags