Advanced Configuration and Power Interface Specification

Power and Performance Management
• Devices that are enabled to wake the system and that can do so from their current device state
can initiate a hardware event that transitions the system state to S0. This transition causes the
processor to begin execution at its boot location. The BIOS performs initialization of core
functions as necessary to exit an S3 state and passes control to the firmware resume vector. See
Section 16.3.2, “BIOS Initialization of Memory,” for more details on BIOS initialization.
From the software viewpoint, this state is functionally the same as the S2 state. The operational
difference can be that some Power Resources that could be left ON to be in the S2 state might not be
available to the S3 state. As such, additional devices may need to be in a deeper state for S3 than S2.
Similarly, some device wake events can function in S2 but not S3.
Because the processor context can be lost while in the S3 state, the transition to the S3 state requires
that the operating software flush all dirty cache to DRAM.
7.4.2.5 System \_S4 State
While the system is in this state, it is in the system S4 sleeping state. The state is logically deeper
than the S3 state and is assumed to conserve more power. The behavior of this state is defined as
follows:
• The processors are not executing instructions. The processor-complex context is not maintained.
• DRAM context is not maintained.
• Power Resources are in a state compatible with the system S4 state. All Power Resources that
supply a System-Level reference of S0, S1, S2, or S3 are in the OFF state.
• Devices states are compatible with the current Power Resource states. In other words, all devices
are in the D3 state when the system state is S4.
• Devices that are enabled to wake the system and that can do so from their device state in S4 can
initiate a hardware event that transitions the system state to S0. This transition causes the
processor to begin execution at its boot location.
After OSPM has executed the _PTS control method and has put the entire system state into main
memory, there are two ways that OSPM may handle the next phase of the S4 state transition; saving
and restoring main memory. The first way is to use the operating system's drivers to access the disks
and file system structures to save a copy of memory to disk and then initiate the hardware S4
sequence by setting the SLP_EN register bit. When the system wakes, the firmware performs a
normal boot process and transfers control to the OS via the firmware_waking_vector loader. The OS
then restores the system's memory and resumes execution.
The alternate method for entering the S4 state is to utilize the BIOS via the S4BIOS transition. The
BIOS uses firmware to save a copy of memory to disk and then initiates the hardware S4 sequence.
When the system wakes, the firmware restores memory from disk and wakes OSPM by transferring
control to the FACS waking vector.
The S4BIOS transition is optional, but any system that supports this mechanism must support
entering the S4 state via the direct OS mechanism. Thus the preferred mechanism for S4 support is
the direct OS mechanism as it provides broader platform support. The alternate S4BIOS transition
provides a way to achieve S4 support on operating systems that do not have support for the direct
method.
Version 6.0 413