Lines Matching +full:suspend +full:- +full:to +full:- +full:disk
1 .. SPDX-License-Identifier: GPL-2.0
13 Sleep states are global low-power states of the entire system in which user
22 the Linux kernel can support up to four system sleep states, including
23 hibernation and up to three variants of system suspend. The sleep states that
28 Suspend-to-Idle
29 ---------------
31 This is a generic, pure software, light-weight variant of system suspend (also
32 referred to as S2I or S2Idle). It allows more energy to be saved relative to
34 I/O devices into low-power states (possibly lower-power than available in the
38 The system is woken up from this state by in-band interrupts, so theoretically
39 any devices that can cause interrupts to be generated in the working state can
43 or :ref:`suspend-to-RAM <s2ram>`, or it can be used in addition to any of the
44 deeper system suspend variants to provide reduced resume latency. It is always
50 -------
53 providing a relatively straightforward transition back to the working state. No
55 go back to where it left off easily enough.
57 In addition to freezing user space, suspending the timekeeping and putting all
58 I/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
61 allow more energy to be saved relative to :ref:`suspend-to-idle <s2idle>`, but
65 reduced relative to :ref:`suspend-to-idle <s2idle>` and it may be necessary to
70 core system suspend subsystem. On ACPI-based systems this state is mapped to
75 Suspend-to-RAM
76 --------------
78 This state (also referred to as STR or S2RAM), if supported, offers significant
79 energy savings as everything in the system is put into a low-power state, except
80 for memory, which should be placed into the self-refresh mode to retain its
82 are also carried out during transitions to S2RAM. Additional operations may
83 take place depending on the platform capabilities. In particular, on ACPI-based
84 systems the kernel passes control to the platform firmware (BIOS) as the last
86 more low-level components that are not directly controlled by the kernel.
89 suspended and put into low-power states. In many cases, all peripheral buses
90 lose power when entering S2RAM, so devices must be able to handle the transition
91 back to the "on" state.
93 On ACPI-based systems S2RAM requires some minimal boot-strapping code in the
94 platform firmware to resume the system from it. This may be the case on other
98 relative to :ref:`suspend-to-idle <s2idle>` and :ref:`standby <standby>` and it
99 may be necessary to rely on the platform for setting up the wakeup functionality
104 suspend subsystem. On ACPI-based systems it is mapped to the S3 system state
110 -----------
112 This state (also referred to as Suspend-to-Disk or STD) offers the greatest
113 energy savings and can be used even in the absence of low-level platform support
114 for system suspend. However, it requires some low-level code for resuming the
115 system to be present for the underlying CPU architecture.
117 Hibernation is significantly different from any of the system suspend variants.
118 It takes three system state changes to put it into hibernation and two system
119 state changes to resume it.
122 creates a snapshot image of memory to be written into persistent storage. Next,
124 is written out and finally the system goes into the target low-power state in
129 special low-power state (like ACPI S4), or it may simply power down itself.
130 Powering down means minimum power draw and it allows this mechanism to work on
131 any system. However, entering a special low-power state may allow additional
132 means of system wakeup to be used (e.g. pressing a key on the keyboard or
135 After wakeup, control goes to the platform firmware that runs a boot loader
136 which boots a fresh instance of the kernel (control may also go directly to
138 a 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
143 kernel stored in the image (referred to as the ``image kernel``), which is where
144 the special architecture-specific low-level code is needed. Finally, the
145 image kernel restores the system to the pre-hibernation state and allows user
146 space to run again.
150 for the given CPU architecture includes the low-level code for system resume.
153 Basic ``sysfs`` Interfaces for System Suspend and Hibernation
165 to start a transition of the system into the sleep state represented by
168 In particular, the "disk", "freeze" and "standby" strings represent the
169 :ref:`hibernation <hibernation>`, :ref:`suspend-to-idle <s2idle>` and
179 suspend variants and allows user space to select the variant to be
183 and "deep". The "s2idle" string always represents :ref:`suspend-to-idle
185 :ref:`standby <standby>` and :ref:`suspend-to-RAM <s2ram>`,
189 suspend variant represented by it to be associated with the "mem" string
190 in the ``state`` file. The string representing the suspend variant
194 If the kernel does not support system suspend, this file is not present.
196 ``disk``
197 This file controls the operating mode of hibernation (Suspend-to-Disk).
198 Specifically, it tells the kernel what to do after creating a
204 Put the system into a special low-power state (e.g. ACPI S4) to
206 platform firmware to take a simplified initialization path after
210 mechanism to put the system to sleep after creating a
220 ``suspend``
221 Hybrid system suspend. Put the system into the suspend sleep
225 to restore the previous state of the system.
227 It is available if system suspend is supported.
236 represented by it to be selected.
240 and saving the image when hibernation is triggered by writing ``disk``
241 to :file:`/sys/power/state`.
248 It can be written a string representing a non-negative integer that will
249 be used as a best-effort upper limit of the image size, in bytes. The
250 hibernation core will do its best to ensure that the image size will not
251 exceed that number, but if that turns out to be impossible to achieve, a
253 possible. In particular, writing '0' to this file causes the size of
254 hibernation images to be minimum.
256 Reading from it returns the current image size limit, which is set to
260 This file controls the "PM trace" mechanism saving the last suspend
261 or resume event point in the RTC memory across reboots. It helps to
262 debug hard lockups or reboots due to device driver failures that occur
263 during system suspend or resume (which is more common) more effectively.
265 If it contains "1", the fingerprint of each suspend/resume event point
268 after storing it and it can be used later to identify the driver that
269 caused the crash to happen.
271 It contains "0" by default, which may be changed to "1" by writing a
274 According to the above, there are two ways to make the system go into the
275 :ref:`suspend-to-idle <s2idle>` state. The first one is to write "freeze"
276 directly to :file:`/sys/power/state`. The second one is to write "s2idle" to
277 :file:`/sys/power/mem_sleep` and then to write "mem" to
278 :file:`/sys/power/state`. Likewise, there are two ways to make the system go
279 into the :ref:`standby <standby>` state (the strings to write to the control
281 state is supported by the platform. However, there is only one way to make the
282 system go into the :ref:`suspend-to-RAM <s2ram>` state (write "deep" into
285 The default suspend variant (ie. the one to be used without writing anything
287 supporting :ref:`suspend-to-RAM <s2ram>`) or "s2idle", but it can be overridden
290 default may be "s2idle" even if :ref:`suspend-to-RAM <s2ram>` is supported in