| System Power Management Sleep States | |
| (C) 2014 Intel Corp., Rafael J. Wysocki <[email protected]> | |
| 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 | |
| line argument. | |
| 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 | |
| apply. | |
| state: Suspend-To-Idle | |
| ACPI state: S0 | |
| Label: "freeze" | |
| 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 | |
| Label: "standby" | |
| 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 | |
| state. | |
| State: Suspend-to-RAM | |
| ACPI State: S3 | |
| Label: "mem" | |
| 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 | |
| the kernel. | |
| 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 | |
| "on" state. | |
| 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. | |
| State: Suspend-to-disk | |
| ACPI State: S4 | |
| Label: "disk" | |
| 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, | |
| see userland-swsusp.txt. | |
| 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). |