1.. SPDX-License-Identifier: GPL-2.0 2.. include:: <isonum.txt> 3 4=================== 5System Sleep States 6=================== 7 8:Copyright: |copy| 2017 Intel Corporation 9 10:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 11 12 13Sleep states are global low-power states of the entire system in which user 14space code cannot be executed and the overall system activity is significantly 15reduced. 16 17 18Sleep States That Can Be Supported 19================================== 20 21Depending on its configuration and the capabilities of the platform it runs on, 22the Linux kernel can support up to four system sleep states, including 23hibernation and up to three variants of system suspend. The sleep states that 24can be supported by the kernel are listed below. 25 26.. _s2idle: 27 28Suspend-to-Idle 29--------------- 30 31This is a generic, pure software, light-weight variant of system suspend (also 32referred to as S2I or S2Idle). It allows more energy to be saved relative to 33runtime idle by freezing user space, suspending the timekeeping and putting all 34I/O devices into low-power states (possibly lower-power than available in the 35working state), such that the processors can spend time in their deepest idle 36states while the system is suspended. 37 38The system is woken up from this state by in-band interrupts, so theoretically 39any devices that can cause interrupts to be generated in the working state can 40also be set up as wakeup devices for S2Idle. 41 42This state can be used on platforms without support for :ref:`standby <standby>` 43or :ref:`suspend-to-RAM <s2ram>`, or it can be used in addition to any of the 44deeper system suspend variants to provide reduced resume latency. It is always 45supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set. 46 47.. _standby: 48 49Standby 50------- 51 52This state, if supported, offers moderate, but real, energy savings, while 53providing a relatively straightforward transition back to the working state. No 54operating state is lost (the system core logic retains power), so the system can 55go back to where it left off easily enough. 56 57In addition to freezing user space, suspending the timekeeping and putting all 58I/O devices into low-power states, which is done for :ref:`suspend-to-idle 59<s2idle>` too, nonboot CPUs are taken offline and all low-level system functions 60are suspended during transitions into this state. For this reason, it should 61allow more energy to be saved relative to :ref:`suspend-to-idle <s2idle>`, but 62the resume latency will generally be greater than for that state. 63 64The set of devices that can wake up the system from this state usually is 65reduced relative to :ref:`suspend-to-idle <s2idle>` and it may be necessary to 66rely on the platform for setting up the wakeup functionality as appropriate. 67 68This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration 69option is set and the support for it is registered by the platform with the 70core system suspend subsystem. On ACPI-based systems this state is mapped to 71the S1 system state defined by ACPI. 72 73.. _s2ram: 74 75Suspend-to-RAM 76-------------- 77 78This state (also referred to as STR or S2RAM), if supported, offers significant 79energy savings as everything in the system is put into a low-power state, except 80for memory, which should be placed into the self-refresh mode to retain its 81contents. All of the steps carried out when entering :ref:`standby <standby>` 82are also carried out during transitions to S2RAM. Additional operations may 83take place depending on the platform capabilities. In particular, on ACPI-based 84systems the kernel passes control to the platform firmware (BIOS) as the last 85step during S2RAM transitions and that usually results in powering down some 86more low-level components that are not directly controlled by the kernel. 87 88The state of devices and CPUs is saved and held in memory. All devices are 89suspended and put into low-power states. In many cases, all peripheral buses 90lose power when entering S2RAM, so devices must be able to handle the transition 91back to the "on" state. 92 93On ACPI-based systems S2RAM requires some minimal boot-strapping code in the 94platform firmware to resume the system from it. This may be the case on other 95platforms too. 96 97The set of devices that can wake up the system from S2RAM usually is reduced 98relative to :ref:`suspend-to-idle <s2idle>` and :ref:`standby <standby>` and it 99may be necessary to rely on the platform for setting up the wakeup functionality 100as appropriate. 101 102S2RAM is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option 103is set and the support for it is registered by the platform with the core system 104suspend subsystem. On ACPI-based systems it is mapped to the S3 system state 105defined by ACPI. 106 107.. _hibernation: 108 109Hibernation 110----------- 111 112This state (also referred to as Suspend-to-Disk or STD) offers the greatest 113energy savings and can be used even in the absence of low-level platform support 114for system suspend. However, it requires some low-level code for resuming the 115system to be present for the underlying CPU architecture. 116 117Hibernation is significantly different from any of the system suspend variants. 118It takes three system state changes to put it into hibernation and two system 119state changes to resume it. 120 121First, when hibernation is triggered, the kernel stops all system activity and 122creates a snapshot image of memory to be written into persistent storage. Next, 123the system goes into a state in which the snapshot image can be saved, the image 124is written out and finally the system goes into the target low-power state in 125which power is cut from almost all of its hardware components, including memory, 126except for a limited set of wakeup devices. 127 128Once the snapshot image has been written out, the system may either enter a 129special low-power state (like ACPI S4), or it may simply power down itself. 130Powering down means minimum power draw and it allows this mechanism to work on 131any system. However, entering a special low-power state may allow additional 132means of system wakeup to be used (e.g. pressing a key on the keyboard or 133opening a laptop lid). 134 135After wakeup, control goes to the platform firmware that runs a boot loader 136which boots a fresh instance of the kernel (control may also go directly to 137the boot loader, depending on the system configuration, but anyway it causes 138a fresh instance of the kernel to be booted). That new instance of the kernel 139(referred to as the ``restore kernel``) looks for a hibernation image in 140persistent storage and if one is found, it is loaded into memory. Next, all 141activity in the system is stopped and the restore kernel overwrites itself with 142the image contents and jumps into a special trampoline area in the original 143kernel stored in the image (referred to as the ``image kernel``), which is where 144the special architecture-specific low-level code is needed. Finally, the 145image kernel restores the system to the pre-hibernation state and allows user 146space to run again. 147 148Hibernation is supported if the :c:macro:`CONFIG_HIBERNATION` kernel 149configuration option is set. However, this option can only be set if support 150for the given CPU architecture includes the low-level code for system resume. 151 152 153Basic ``sysfs`` Interfaces for System Suspend and Hibernation 154============================================================= 155 156The following files located in the :file:`/sys/power/` directory can be used by 157user space for sleep states control. 158 159``state`` 160 This file contains a list of strings representing sleep states supported 161 by the kernel. Writing one of these strings into it causes the kernel 162 to start a transition of the system into the sleep state represented by 163 that string. 164 165 In particular, the strings "disk", "freeze" and "standby" represent the 166 :ref:`hibernation <hibernation>`, :ref:`suspend-to-idle <s2idle>` and 167 :ref:`standby <standby>` sleep states, respectively. The string "mem" 168 is interpreted in accordance with the contents of the ``mem_sleep`` file 169 described below. 170 171 If the kernel does not support any system sleep states, this file is 172 not present. 173 174``mem_sleep`` 175 This file contains a list of strings representing supported system 176 suspend variants and allows user space to select the variant to be 177 associated with the "mem" string in the ``state`` file described above. 178 179 The strings that may be present in this file are "s2idle", "shallow" 180 and "deep". The string "s2idle" always represents :ref:`suspend-to-idle 181 <s2idle>` and, by convention, "shallow" and "deep" represent 182 :ref:`standby <standby>` and :ref:`suspend-to-RAM <s2ram>`, 183 respectively. 184 185 Writing one of the listed strings into this file causes the system 186 suspend variant represented by it to be associated with the "mem" string 187 in the ``state`` file. The string representing the suspend variant 188 currently associated with the "mem" string in the ``state`` file 189 is listed in square brackets. 190 191 If the kernel does not support system suspend, this file is not present. 192 193``disk`` 194 This file contains a list of strings representing different operations 195 that can be carried out after the hibernation image has been saved. The 196 possible options are as follows: 197 198 ``platform`` 199 Put the system into a special low-power state (e.g. ACPI S4) to 200 make additional wakeup options available and possibly allow the 201 platform firmware to take a simplified initialization path after 202 wakeup. 203 204 ``shutdown`` 205 Power off the system. 206 207 ``reboot`` 208 Reboot the system (useful for diagnostics mostly). 209 210 ``suspend`` 211 Hybrid system suspend. Put the system into the suspend sleep 212 state selected through the ``mem_sleep`` file described above. 213 If the system is successfully woken up from that state, discard 214 the hibernation image and continue. Otherwise, use the image 215 to restore the previous state of the system. 216 217 ``test_resume`` 218 Diagnostic operation. Load the image as though the system had 219 just woken up from hibernation and the currently running kernel 220 instance was a restore kernel and follow up with full system 221 resume. 222 223 Writing one of the listed strings into this file causes the option 224 represented by it to be selected. 225 226 The currently selected option is shown in square brackets which means 227 that the operation represented by it will be carried out after creating 228 and saving the image next time hibernation is triggered by writing 229 ``disk`` to :file:`/sys/power/state`. 230 231 If the kernel does not support hibernation, this file is not present. 232 233According to the above, there are two ways to make the system go into the 234:ref:`suspend-to-idle <s2idle>` state. The first one is to write "freeze" 235directly to :file:`/sys/power/state`. The second one is to write "s2idle" to 236:file:`/sys/power/mem_sleep` and then to write "mem" to 237:file:`/sys/power/state`. Likewise, there are two ways to make the system go 238into the :ref:`standby <standby>` state (the strings to write to the control 239files in that case are "standby" or "shallow" and "mem", respectively) if that 240state is supported by the platform. However, there is only one way to make the 241system go into the :ref:`suspend-to-RAM <s2ram>` state (write "deep" into 242:file:`/sys/power/mem_sleep` and "mem" into :file:`/sys/power/state`). 243 244The default suspend variant (ie. the one to be used without writing anything 245into :file:`/sys/power/mem_sleep`) is either "deep" (on the majority of systems 246supporting :ref:`suspend-to-RAM <s2ram>`) or "s2idle", but it can be overridden 247by the value of the "mem_sleep_default" parameter in the kernel command line. 248On some ACPI-based systems, depending on the information in the ACPI tables, the 249default may be "s2idle" even if :ref:`suspend-to-RAM <s2ram>` is supported. 250