ACPI Methods to define defines system sleep states and wake events– System sleeping states (S-states S1-S4)– Global system power states States, S1 to S5) within the global system power state (G-statesStates, S0, S5)
– System sleeping states (At least one system sleeping state, S1-S4, must be implemented)
System power management ACPI defines mechanisms for putting the computer as a whole in and out of system sleeping states. It also provides a general mechanism for any device to wake the computer.
The platform can only enter a single sleeping state at a time (referred to as the global G1 state); however, the hardware can provide up to four system sleeping G0 to G1). S0 is the working state in which actual work is being done and S1 to S5 are different sleep states with varying latency to enter sleep states and power savings. ACPI also provides a mechanism to specify devices that can wake up the system from sleep states and related control methods and bindings to specify how the transition to sleep and wake up are performed.
Hardware can provide multiple system states that have different power and exit latencies represented by the S1, S2, S3, or S4 states. When OSPM decides to enter and OSPM picks a sleeping state it picks the most appropriate sleeping state supported by the hardware (OS policy examines what devices have enabled wake events and what sleeping states these support). OSPM initiates the sleeping transition by enabling the appropriate wake events and then programming the SLP_TYPx field with the desired sleeping state and then setting the SLP_ENx bit. The system will then enter a sleeping state; when one of the enabled wake events occurs, it will transition the system back to the working state (for more information, see Waking and Sleeping).
PowerResource
PowerResource (resourcename, systemlevel, resourceorder) {TermList}
Systemlevel is the deepest system sleep level OSPM must maintain to keep this power resource on (0 equates to S0, 1 equates to S1, and so on).
When controlling power to devices which must wake the system during a system sleeping state: • The device must declare its ability to wake the system by declaring either the _PRW or _PSW object. • After OSPM has called _PTS, it must call the device’s _PSW to enable wake. • OSPM must transition a device into a D-state which is deeper than or equal to that specified by the device’s _SxD object (if present) to enable entry into Sx, but shallower than or equal to that specified by the device’s _SxW object so that it can still wake the system. • OSPM may transition the system to the specified sleep state.
Check page 450 for details on device methods for wake up
_PRW Object that evaluates to the device’s power requirements in order to wake the system from a system sleeping state.
_PSW Control method that enables or disables the device’s wake function.
_DSW (Device Sleep Wake) In addition to _PRW, this control method can be used to enable or disable the device’s ability to wake a sleeping system.
7.3.20 _S0W (S0 Device Wake State) This object evaluates to an integer that conveys to OSPM the deepest D-state supported by this device in the S0 system sleeping state where the device can wake itself.
7.4.1 \_PTS (Prepare To Sleep) The _PTS control method is executed by the OS during the sleep transition process for S1, S2, S3, S4, and for orderly S5 shutdown. The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5 soft-off state) is passed to the _PTS control method. This method is called after OSPM has notified native device drivers of the sleep state transition and before the OSPM has had a chance to fully prepare the system for a sleep state transition. Thus, this control method can be executed a relatively long time before actually entering the desired sleeping state. If OSPM aborts the sleep state transition, OSPM should run the _WAK method to indicate this condition to the platform
After ensuring that any desired wake-capable interrupts are enabled, OSPM writes the HW-reduced Sleep Type value to the Sleep Control Register and spins waiting for the WAK_STS bit of the Sleep Status Register to be set, indicating a platform transition to the Working state.
ACPI Sleeping States
7.4.2.1 System \_S0 State (Working) While the system is in the S0 state, it is in the system working state. The behavior of this state is defined as: • The processors are either running, or in a C-state, or in an LPI state. The processor-complex context is maintained and instructions are executed as defined by any of these processor states. • Dynamic RAM context is maintained and is read/write by the processors. • Devices states are individually managed by the operating software and can be in any device state (D0, D1, D2, D3hot, or D3). • Power Resources are in a state compatible with the current device states. Transition into the S0 state from some system sleeping state is automatic, and by virtue that instructions are being executed OSPM, assumes the system to be in the S0 state.
7.4.2.2 System \_S1 State (Sleeping with Processor Context Maintained) While the system is in the S1 sleeping state, its behavior is the following: • The processors are not executing instructions. The processor-complex context is maintained. • Dynamic RAM context is maintained. • Power Resources are in a state compatible with the system S1 state. All Power Resources that supply a SystemLevel reference of S0 are in the OFF state. • Devices states are compatible with the current Power Resource states. Only devices that solely reference Power Resources that are in the ON state for a given device state can be in that device state. In all other cases, the device is in the D3 (off) state. (Or it is at least assumed to be in the D3 state by its device driver. For example, if the device doesn’t explicitly describe how it can stay in some non-off state while the system is in a sleeping state, the operating software must assume that the device can lose its power and state.) • 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 continue execution where it left off. To transition into the S1 state, the OSPM must flush all processor caches.
7.4.2.3 System \_S2 State The S2 sleeping state is logically deeper than the S1 state and is assumed to conserve more power. The behavior of this state is defined as: • The processors are not executing instructions. The processor-complex context is not maintained. • Dynamic RAM context is maintained. • Power Resources are in a state compatible with the system S2 state. All Power Resources that supply a SystemLevel reference of S0 or S1 are in the OFF state. • Devices states are compatible with the current Power Resource states. Only devices that solely reference Power Resources that are in the ON state for a given device state can be in that device state. In all other cases, the device is in the D3 (off) state. • 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 platform runtime firmware performs initialization of core functions as needed to exit an S2 state and passes control to the firmware resume vector. See Platform Boot Firmware Initialization of Memory for more details on platform firmware initialization.
Because the processor context can be lost while in the S2 state, the transition to the S2 state requires that the operating software flush all dirty cache to dynamic RAM (DRAM).
7.4.2.4 System \_S3 State
The S3 state is logically deeper than the S2 state and is assumed to conserve more power. The behavior of this state is
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.
7.4.2.5 System \_S4 State
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 SystemLevel 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.
7.4.2.6 System \_S5 State (Soft Off) The S5 state is similar to the S4 state except that OSPM does not save any context. The system is in the soft off state and requires a complete boot when awakened (platform boot firmware and OS). Software uses a different state value to distinguish between this state and the S4 state to allow for initial boot operations within the platform boot firmware to distinguish whether or not the boot is going to wake from a saved memory image. OSPM does not disable wake events before setting the SLP_EN bit when entering the S5 system state. This provides support for remote management initiatives by enabling Remote Start capability. An ACPI-compliant OS must provide an end user accessible mechanism for disabling all wake devices, with the exception of the system power button, from a single point in the user interface.
7.4.3 \_SWS (System Wake Source) This object provides a means for OSPM to definitively determine the source of an event that caused the system to enter the S0 state. General-purpose event and fixed-feature hardware registers containing wake event sources information are insufficient for this purpose as the source event information may not be available after transitions to the S0 state from all other system states (S1-S5). To determine the source event that caused the system to transition to the S0 state, OSPM will evaluate the _SWS object, when it exists, under the \_GPE scope (for all fixed-feature general-purpose events from the GPE Blocks), under the \_SB scope (for fixed-feature hardware events), and within the scope of a GPE Block device (for GPE events from this device). _SWS objects may exist in any or all of these locations as necessary for the platform to determine the source event that caused the system to transition to the S0 state.
7.4.4 \_TTS (Transition To State) The _TTS control method is executed by the OSPM at the beginning of the sleep transition process for S1, S2, S3, S4, and orderly S5 shutdown. OSPM will invoke _TTS before it has notified any native mode device drivers of the sleep state transition. The sleeping state value (For example, 1, 2, 3, 4 or 5 for the S5 soft-off state) is passed to the _TTS control method.
7.4.5 \_WAK (System Wake) After the system wakes from a sleeping state, it will invoke the \_WAK method and pass the sleeping state value that has ended. This operation occurs asynchronously with other driver notifications in the system and is not the first action to be taken when the system wakes. The AML code for this control method issues device, thermal, and other notifications to ensure that OSPM checks the state of devices, thermal zones, and so on, that could not be maintained during the system sleeping state. For example, if the system cannot determine whether a device was inserted or removed from a bus while in the S2 state, the _WAK method would issue a devicecheck type of notification for that bus when issued with the sleeping state value of 2 (for more information about types of notifications, see Device Object Notifications.
...
OSPM will invoke _PTS, _TTS,and _WAK in the following order: 1. OSPM decides (through a policy scheme) to place the system into a sleeping state StepNumList-1 OSPM decides (through a policy scheme) to place the system into a sleeping state 2. _TTS(Sx) is run, where Sx is the desired sleep state to enter 3. OSPM notifies all native device drivers of the sleep state transition 4. _PTS is run 5. OSPM readies system for the sleep state transition 6. OSPM writes the sleep vector and the system enters the specified Sx sleep state 7. System Wakes up 8. OSPM readies system for the return from the sleep state transition 9. _WAK is run 10. OSPM notifies all native device drivers of the return from the sleep state transition 11. _TTS(0) is run to indicate the return to the S0 state
OSPM uses the RTC wakeup feature or the Time and Alarm Namespace device to program in the time transition delay. Prior to sleeping, OSPM will program the alarm to the closest (in time) wakeup event: either a transition to a lower power sleeping state, or a calendar event (to run some application).
On HW-reduced ACPI systems, the register described by the SLEEP_CONTROL_REG field in the FADT is used instead of the fixed SLP_TYPx and SLP_EN register bit fields
In the G1 state, the system is assumed to be doing no work. Prior to entering the G1 state, OSPM will place devices in a device power state compatible with the system sleeping state to be entered; if a device is enabled to wake the system, then OSPM will place these devices into the lowest Dx state from which the device supports wake. This is defined in the power resource description of that device object. This definition of the G1 state implies:
Pick the deepest sleeping state supported by the platform and enabled waking devices. 2. Execute the _PTS control method (which passes the type of intended sleep state to OEM AML code). 3. If OS policy decides to enter the S4 state and chooses to use the S4BIOS mechanism and S4BIOS is supported by the platform, OSPM will pass control to the platform runtime firmware software by writing the S4BIOS_REQ value to the SMI_CMD port. 4. If not using the S4BIOS mechanism, OSPM gets the SLP_TYPx value from the associated sleeping object (\_S1, \_S2, \_S3, \_S4 or \_S5). 5. Program the SLP_TYPx fields with the values contained in the selected sleeping object.
If entering S1, S2, or S3, flush the processor caches. 7. If not entering S4BIOS, set the SLP_EN bit to start the sleeping sequence. (This actually occurs on the same write operation that programs the SLP_TYPx field in the PM1_CNT register.) If entering S4BIOS, write the S4BIOS_REQ value into the SMI_CMD port. 8. If HW-reduced, program the register indicated by the SLEEP_CONTROL_REG FADT field with the HWreduced ACPI Sleep Type value (retrieved from the sleep state object in step 4 above) and with the SLP_EN bit set to one. 9. On systems containing processors without a hardware mechanism to place the processor in a low-power state, execute appropriate native instructions to place the processor in a low-power state.
_SxD
S-state to D-state mapping for the device.
based on the OS policies and device capabilities to wake up the system etc.
...
ACPI System States
S0: The processors are either running, or in a C-state, or in an LPI state. Processor context, Cache, Memory, etc are retained. Devices can be in any of the power states.
S1: Processor context is maintained, memory context is maintained. Devices are in a compatible state. Devices enabled for wake from S1 can wake up the system.
S2: Processor context is not maintained and memory context is maintained.
S3: Similar to S2, but deeper sleeping state and better power saving.
S4: Processor context and memory context are not maintained. Processor state and memory is saved to disk and restored on wakeup.
S5: Soft off, similar to S4 but no context is stored.
System Control Methods
Add Sleep Control and status register to FADT
Define _S1, _S2, _S3, _S4 and _S5 states to DSDT
Define _PTS, _TTS, _WAK
Define _SWS (System Wake Source)
_PTS (Prepare To Sleep): The _PTS control method is executed by the OS during the sleep transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
_SWS (System Wake Source) This object provides a means for OSPM to definitively determine the source of an event that caused the system to enter the S0 state
_TTS (Transition To State) The _TTS control method is executed by the OSPM at the beginning of the sleep transition process for S1, S2, S3, S4, and orderly S5 shutdown
_WAK (System Wake) After the system wakes from a sleeping state, it will invoke the \_WAK method and pass the sleeping state value that has ended.
Sleep / Wake up Flow
OSPM will invoke _PTS, _TTS, and _WAK in the following order:
OSPM decides (through a policy scheme) to place the system into a sleeping state
_TTS(Sx) is run, where Sx is the desired sleep state to enter
OSPM notifies all native device drivers of the sleep state transition
_PTS is run
OSPM readies system for the sleep state transition
OSPM writes the HW-reduced Sleep Type value to the Sleep Control Register and spins waiting for the WAK_STS bit of the Sleep Status Register to be set, indicating a platform transition to the Working state.
System Wakes up
OSPM readies system for the return from the sleep state transition
_WAK is run
OSPM notifies all native device drivers of the return from the sleep state transition
_TTS(0) is run to indicate the return to the S0 state
...
Device Wake-Up Capabilities
When controlling power to devices that must wake the system during a system sleeping state:
The device must declare its ability to wake the system by declaring either the _PRW or _PSW object.
After OSPM has called _PTS, it must call the device’s _PSW to enable wake.
OSPM must transition a device into a D-state that is deeper than or equal to that specified by the device’s _SxD object (if present) to enable entry into Sx, but shallower than or equal to that specified by the device’s _SxW object so that it can still wake the system.
OSPM may transition the system to the specified sleep state.
_DSW (Device Sleep Wake) In addition to _PRW, this control method can be used to enable or disable the device’s ability to wake a sleeping system.
_SxW (Sx Device Wake State) This object evaluates to an integer that conveys to OSPM the deepest D-state supported by this device in the Sx system sleeping state where the device can wake itself.
_SxD: These methods tell OSPM for S-state “x”, the shallowest D-state supported by the device is “y.”
...
\_Sx (System States)
| Code Block |
|---|
Name (_S0, Package (0x04) // _S0_: S0 System State
{
Zero,
Zero,
Zero,
Zero
})
If (SS3)
{
Name (_S3, Package (0x04) // _S3_: S3 System State
{
0x05,
Zero,
Zero,
Zero
})
}
If (SS4)
{
Name (_S4, Package (0x04) // _S4_: S4 System State
{
0x06,
Zero,
Zero,
Zero
})
}
Name (_S5, Package (0x04) // _S5_: S5 System State
{
0x07,
Zero,
Zero,
Zero
})
Method (PTS, 1, NotSerialized)
{
If (Arg0)
{
\_SB.PCI0.LPCB.EC0.ECPS (Arg0)
\_SB.PCI0.LPCB.SPTS (Arg0)
\_SB.PCI0.NPTS (Arg0)
}
}
Method (WAK, 1, NotSerialized)
{
\_SB.PCI0.LPCB.SWAK (Arg0)
\_SB.PCI0.NWAK (Arg0)
}
}
Method (SWAK, 1, NotSerialized)
{
SLPE = Zero
If (RTCX){}
Else
{
Notify (PWRB, 0x02) // Device Wake
}
}
Scope (_SB)
{
Device (PWRB)
{
Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x1E,
0x04
})
Method (_STA, 0, NotSerialized) // _STA: Status
{
If ((ECON == One))
{
Return (0x0F)
}
Return (Zero)
}
}
}
|
...