|System Power Management Sleep States
|(C) 2014 Intel Corp., Rafael J. Wysocki <email@example.com>
|The kernel supports up to four system sleep states generically, although three
|of them depend on the platform support code to implement the low-level details
|for each state.
|The states are represented by strings that can be read or written to the
|/sys/power/state file. Those strings may be "mem", "standby", "freeze" and
|"disk", where the last one always represents hibernation (Suspend-To-Disk) and
|the meaning of the remaining ones depends on the relative_sleep_states command
|For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the
|available non-hibernation sleep states from the deepest to the shallowest,
|respectively. In that case, "mem" is always present in /sys/power/state,
|because there is at least one non-hibernation sleep state in every system. If
|the given system supports two non-hibernation sleep states, "standby" is present
|in /sys/power/state in addition to "mem". If the system supports three
|non-hibernation sleep states, "freeze" will be present in /sys/power/state in
|addition to "mem" and "standby".
|For relative_sleep_states=0, which is the default, the following descriptions
|ACPI state: S0
|This state is a generic, pure software, light-weight, system sleep state.
|It allows more energy to be saved relative to runtime idle by freezing user
|space and putting all I/O devices into low-power states (possibly
|lower-power than available at run time), such that the processors can
|spend more time in their idle states.
|This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
|support, or it can be used in addition to Suspend-to-RAM (memory sleep)
|to provide reduced resume latency. It is always supported.
|State: Standby / Power-On Suspend
|ACPI State: S1
|This state, if supported, offers moderate, though real, power savings, while
|providing a relatively low-latency transition back to a working system. No
|operating state is lost (the CPU retains power), so the system easily starts up
|again where it left off.
|In addition to freezing user space and putting all I/O devices into low-power
|states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline
|and all low-level system functions are suspended during transitions into this
|state. For this reason, it should allow more energy to be saved relative to
|Suspend-To-Idle, but the resume latency will generally be greater than for that
|ACPI State: S3
|This state, if supported, offers significant power savings as everything in the
|system is put into a low-power state, except for memory, which should be placed
|into the self-refresh mode to retain its contents. All of the steps carried out
|when entering Power-On Suspend are also carried out during transitions to STR.
|Additional operations may take place depending on the platform capabilities. In
|particular, on ACPI systems the kernel passes control to the BIOS (platform
|firmware) as the last step during STR transitions and that usually results in
|powering down some more low-level components that aren't directly controlled by
|System and device state is saved and kept in memory. All devices are suspended
|and put into low-power states. In many cases, all peripheral buses lose power
|when entering STR, so devices must be able to handle the transition back to the
|For at least ACPI, STR requires some minimal boot-strapping code to resume the
|system from it. This may be the case on other platforms too.
|ACPI State: S4
|This state offers the greatest power savings, and can be used even in
|the absence of low-level platform support for power management. This
|state operates similarly to Suspend-to-RAM, but includes a final step
|of writing memory contents to disk. On resume, this is read and memory
|is restored to its pre-suspend state.
|STD can be handled by the firmware or the kernel. If it is handled by
|the firmware, it usually requires a dedicated partition that must be
|setup via another operating system for it to use. Despite the
|inconvenience, this method requires minimal work by the kernel, since
|the firmware will also handle restoring memory contents on resume.
|For suspend-to-disk, a mechanism called 'swsusp' (Swap Suspend) is used
|to write memory contents to free swap space. swsusp has some restrictive
|requirements, but should work in most cases. Some, albeit outdated,
|documentation can be found in Documentation/power/swsusp.txt.
|Alternatively, userspace can do most of the actual suspend to disk work,
|Once memory state is written to disk, the system may either enter a
|low-power state (like ACPI S4), or it may simply power down. Powering
|down offers greater savings, and allows this mechanism to work on any
|system. However, entering a real low-power state allows the user to
|trigger wake up events (e.g. pressing a key or opening a laptop lid).