Global system states (Gx states) apply to the entire system and are visible to the user.
A computer state that is entered and left by a mechanical means (for example, turning
off the system’s power through the movement of a large red switch). It is implied by
the entry of this off state through a mechanical means that no electrical current is
running through the circuitry and that it can be worked on without damaging the
hardware or endangering service personnel. The OS must be restarted to return to the
Working state. No hardware context is retained. Except for the real-time clock, power
consumption is zero.
A computer state where the computer consumes a minimal amount of power. No user
mode or system mode code is run. This state requires a large latency in order to return
to the Working state. The system’s context will not be preserved by the hardware. The
system must be restarted to return to the Working state. It is not safe to disassemble
the machine in this state.
A computer state where the computer consumes a small amount of power, user mode
threads are not being executed, and the system “appears” to be off (from an end user’s
perspective, the display is off, and so on). Latency for returning to the Working statevaries
on the wake environment selected prior to entry of this state (for example,
whether the system should answer phone calls). Work can be resumed without
rebooting the OS because large elements of system context are saved by the hardware
and the rest by system software. It is not safe to disassemble the machine in this state.
A computer state where the system dispatches user mode (application) threads and
they execute. In this state, peripheral devices (peripherals) are having their power state
changed dynamically. The user can select, through some UI, various performance/
power characteristics of the system to have the software optimize for performance or
battery life. The system responds to external events in real time. It is not safe to
disassemble the machine in this state.
A special global system state that allows system context to be saved and restored
(relatively slowly) when power is lost to the motherboard. If the system has been
commanded to enter S4, the OS will write all system context to a file on non-volatile
storage media and leave appropriate context markers. The machine will then enter the
S4 state. When the system leaves the Soft Off or Mechanical Off state, transitioning to
Working (G0) and restarting the OS, a restore from a NVS file can occur. This will
only happen if a valid non-volatile sleep data set is found, certain aspects of the
configuration of the machine have not changed, and the user has not manually aborted
the restore. If all these conditions are met, as part of the OS restarting, it will reload
the system context and activate it. The net effect for the user is what looks like a
resume from a Sleeping (G1) state (albeit slower). The aspects of the machine
configuration that must not change include, but are not limited to, disk layout and
memory size. It might be possible for the user to swap a PC Card or a Device Bay
device, however.
Device power states are states of particular devices; as such, they are generally not visible to the user.
For example, some devices may be in the Off state even though the system as a whole is in the Working state.
Device states apply to any device on any bus.
Power has been fully removed from the device. The device context is lost when this
state is entered, so the OS software will reinitialize the device when powering it back
on. Since device context and power are lost, devices in this state do not decode their
address lines. Devices in this state have the longest restore times. All classes of
devices define this state.
The meaning of the D3hot State is defined by each device class. Devices in the D3hot
State are required to be software enumerable. In general, D3hot is expected to save
more power and optionally preserve device context. If device context is lost when this
state is entered, the OS software will reinitialize the device when transitioning to D0.
Devices in this state can have long restore times. All classes of devices define this
state.
Note: The D3hot state differs from the D3 state in two distinct parameters; the main power rail is present
and software can access a device in D3hot. For devices that support both D3hot and D3 exposed
to OSPM via _PR3, device software/drivers must always assume OSPM will target D3and must
assume device context will be lost.
The meaning of the D2 Device State is defined by each device class. Many device
classes may not define D2. In general, D2 is expected to save more power and
preserve less device context than D1 or D0. Buses in D2 may cause the device to lose
some context (for example, by reducing power on the bus, thus forcing the device to
turn off some of its functions).
The meaning of the D1 Device State is defined by each device class. Many device
classes may not define D1. In general, D1 is expected to save less power and preserve
more device context than D2.
This state is assumed to be the highest level of power consumption. The device is
completely active and responsive, and is expected to remember all relevant context
continuously.
Sleeping states (Sx states) are types of sleeping states within the global sleeping state, G1.
The S1 sleeping state is a low wake latency sleeping state. In this state, no system
context is lost (CPU or chip set) and hardware maintains all system context.
S2 Sleeping State
The S2 sleeping state is a low wake latency sleeping state. This state is similar to the
S1 sleeping state except that the CPU and system cache context is lost (the OS is
responsible for maintaining the caches and CPU context). Control starts from the
processor’s reset vector after the wake event.
The S3 sleeping state is a low wake latency sleeping state where all system context is
lost except system memory. CPU, cache, and chip set context are lost in this state.
Hardware maintains memory context and restores some CPU and L2 configuration
context. Control starts from the processor’s reset vector after the wake event.
The S4 sleeping state is the lowest power, longest wake latency sleeping state
supported by ACPI. In order to reduce power to a minimum, it is assumed that the
hardware platform has powered off all devices. Platform context is maintained.
The S5 state is similar to the S4 state except that the OS does not save any context.
The system is in the “soft” off state and requires a complete boot when it wakes.
Software uses a different state value to distinguish between the S5 state and the S4
state to allow for initial boot operations within the BIOS to distinguish whether or not
the boot is going to wake from a saved memory image.
Processor power states (Cx states) are processor power consumption and thermal management states within the global working state, G0.
While the processor is in this state, it executes instructions.
This processor power state has the lowest latency. The hardware latency in this state
must be low enough that the operating software does not consider the latency aspect of
the state when deciding whether to use it. Aside from putting the processor in a nonexecuting
power state, this state has no other software-visible effects.
The C2 state offers improved power savings over the C1 state. The worst-case
hardware latency for this state is provided via the ACPI system firmware and the
operating software can use this information to determine when the C1 state should
be used instead of the C2 state. Aside from putting the processor in a non-executing
power state, this state has no other software-visible effects.
The C3 state offers improved power savings over the C1 and C2 states. The worstcase
hardware latency for this state is provided via the ACPI system firmware and the
operating software can use this information to determine when the C2 state should be
used instead of the C3 state. While in the C3 state, the processor’s caches maintain
state but ignore any snoops. The operating software is responsible for ensuring that the
caches maintain coherency.
Device and Processor performance states (Px states) are power consumption and capability states within the active/executing states, C0 for processors and D0 for devices.
While a device or processor is in this state, it uses its maximum performance
capability and may consume maximum power.
In this performance power state, the performance capability of a device or processor is
limited below its maximum and consumes less than maximum power.
In this performance state, the performance capability of a device or processor is at its
minimum level and consumes minimal power while remaining in an active state. State
n is a maximum number and is processor or device dependent. Processors and devices
may define support for an arbitrary number of performance states not to exceed 16.