|System Power Management States
|The kernel supports four power management states generically, though
|one is generic and the other three are dependent on platform support
|code to implement the low-level details for each state.
|This file describes each state, what they are
|commonly called, what ACPI state they map to, and what string to write
|to /sys/power/state to enter that state
|state: Freeze / Low-Power Idle
|ACPI state: S0
|This state is a generic, pure software, light-weight, low-power state.
|It allows more energy to be saved relative to 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 Standby/Suspend-to-RAM
|support, or it can be used in addition to Suspend-to-RAM (memory sleep)
|to provide reduced resume latency.
|State: Standby / Power-On Suspend
|ACPI State: S1
|This state offers minimal, though real, power savings, while providing
|a very 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.
|We try to put devices in a low-power state equivalent to D1, which
|also offers low power savings, but low resume latency. Not all devices
|support D1, and those that don't are left on.
|ACPI State: S3
|This state offers significant power savings as everything in the
|system is put into a low-power state, except for memory, which is
|placed in self-refresh mode to retain its contents.
|System and device state is saved and kept in memory. All devices are
|suspended and put into D3. 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 STR. This may be true on other platforms.
|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).