...
| Table of Contents | ||||
|---|---|---|---|---|
|
ACPI 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 entry/exit latency and power savings. ACPI also provides a mechanism to specify devices that can wake up the system and related control methods and bindings.
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) 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 saved.
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
...
Required Sleep Object and Control Methods
Define Sleep Control and status register to FADT
Define _S1, _S2, _S3, _S4 and _S5 states to DSDT as appropriate.
Define _PTS, _TTS, _WAK, _SWS control methods
_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.
These methods tell OSPM for S-state “x”, the shallowest D-state supported by the device is “y.” OSPM is allowed to pick a deeper D-state for a given S-state, but OSPM is not allowed to go shallower than the given D-state.
\_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)
}
}
}
|
Surface 3
| Code Block |
|---|
Method (_WAK, 1, NotSerialized) // _WAK: Wake
{
PWAK (Arg0)
Return (WAKP) /* \WAKP */
}
Method (_PTS, 1, NotSerialized) // _PTS: Prepare To Sleep
{
If (Arg0)
{
PPTS (Arg0)
}
}
|
Sleep Control and Status Register
The optional ACPI sleep registers (SLEEP_CONTROL_REG and SLEEP_STATUS_REG) specify a standard mechanism for system sleep state entry on HW-Reduced ACPI systems.
Use of these registers is at the discretion of OSPM. OSPM can decide whether to enter sleep states on the platform based on the LOW_POWER_S0_IDLE_CAPABLE flag. Even when implemented, OSPM may use other provided options for hibernate and shutdown (e.g. UEFI ResetSystem()).
The HW-reduced Sleep mechanism is implemented via two 8-bit registers described by SLEEP_CONTROL_REG and SLEEP_STATUS_REG in the FADT (always accessed via the natural alignment and size described in SLEEP_*_REG). To put the system into a sleep state, software will write the HW-reduced Sleep Type value (obtained from the \_Sx object in the DSDT) and the SLP_EN bit to the sleep control register. The OSPM then polls the WAK_STS bit of the SLEEP_STATUS_REG waiting for it to be one (1), indicating that the system has been transitioned back to the Working state.
...
5.2.9 Fixed ACPI Description Table (FADT)
| Code Block |
|---|
[0F4h 0244 12] Sleep Control Register : [Generic Address Structure]
[0F4h 0244 1] Space ID : 01 [SystemIO]
[0F5h 0245 1] Bit Width : 08
[0F6h 0246 1] Bit Offset : 00
[0F7h 0247 1] Encoded Access Width : 01 [Byte Access:8]
[0F8h 0248 8] Address : 0000000000000405
[100h 0256 12] Sleep Status Register : [Generic Address Structure]
[100h 0256 1] Space ID : 01 [SystemIO]
[101h 0257 1] Bit Width : 08
[102h 0258 1] Bit Offset : 00
[103h 0259 1] Encoded Access Width : 01 [Byte Access:8]
[104h 0260 8] Address : 0000000000000401
|
TODO
Add Sleep Control and status register to FADT
Define _S1, _S2, _S3, _S4 and _S5 states to DSDT
Define _PTS, _TTS, _WAK
For Devices with wake-up capabilities:
Define _SxD (S-state to D-State Mapping)
Define _SxW
_PRW or _PSW
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
Questions
Check how we can flush the cache on Arm platforms - WBINVD
No
16.1.6 Transitioning from the Working to the Sleeping State
On a transition of the system from the working to the sleeping state, the following occurs: 1. OSPM decides (through a policy scheme) to place the system into the sleeping state. 2. OSPM invokes the _TTS method to indicate the deepest possible system state the system will transition to (1, 2, 3, or 4 representing S1, S2, S3, and S4). 3. OSPM examines all devices enabled to wake the system and determines the deepest possible sleeping state the system can enter to support the enabled wake functions. The _PRW named object under each device is examined, as well as the power resource object it points to. 4. OSPM places all device drivers into their respective Dx state. If the device is enabled for wake, it enters the Dx state associated with the wake capability. If the device is not enabled to wake the system, it enters the D3 state. 5. OSPM executes the _PTS control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). 6. OSPM saves any other processor’s context (other than the local processor) to memory. 7. OSPM writes the waking vector into the FACS table in memory.
Flushing the Caches
OSPM is responsible for flushing the system caches before entering sleep states.
The manual cache-flushing mechanism relies on the two FADT fields:
FLUSH_SIZE. Indicates twice the size of the largest cache in bytes.
•FLUSH_STRIDE. Indicates the smallest line size of the caches in bytes. The cache flush size value is typically twice the size of the largest cache size, and the cache flush stride value is typically the size of the smallest cache line size in the platform. OSPM will flush the system caches by reading a contiguous block of memory indicated by the cache flush size.
As mentioned previously, waking from an S4 state is treated the same as a cold boot: the platform boot firmware runs POST and then initializes memory to contain the ACPI system description tables. After it has finished this, it can call OSPM loader, and control is passed to OSPM. When waking from S4 (either S4OS or S4BIOS), the platform boot firmware may optionally set SCI_EN bit before passing control to OSPM. In this case, interrupts must be disabled (for IA-32 processors, disabled CLI instruction) until the control is passed to OSPM and the chipset must be configured in ACPI mode
Linux possible known gaps
ACPI System Low Power States
This work as is since it's directly PSCI linked. However, this is not
connected remotely to existing ACPI methods (7.4.2 _Sx (System
States)). It could be problematic without that as wakeup events need
to be linked to appropriate states as per specification.
Wake Events/Sources
When controlling power to devices that must wake the system
during a system sleeping state, ACPI defines system wake sources
under 7.4.3 _SWS (System Wake Source) and other related sections
_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.
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.”
Sleep Control and Status Register
The optional ACPI sleep registers (SLEEP_CONTROL_REG and SLEEP_STATUS_REG) specify a standard mechanism for system sleep state entry on HW-Reduced ACPI systems.
Use of these registers is at the discretion of OSPM. OSPM can decide whether to enter sleep states on the platform based on the LOW_POWER_S0_IDLE_CAPABLE flag. Even when implemented, OSPM may use other provided options for hibernate and shutdown (e.g. UEFI ResetSystem()).
The HW-reduced Sleep mechanism is implemented via two 8-bit registers described by SLEEP_CONTROL_REG and SLEEP_STATUS_REG in the FADT (always accessed via the natural alignment and size described in SLEEP_*_REG). To put the system into a sleep state, software will write the HW-reduced Sleep Type value (obtained from the \_Sx object in the DSDT) and the SLP_EN bit to the sleep control register. The OSPM then polls the WAK_STS bit of the SLEEP_STATUS_REG waiting for it to be one (1), indicating that the system has been transitioned back to the Working state.
...
Flushing the Caches
OSPM is responsible for flushing the system caches before entering sleep states.
The manual cache-flushing mechanism relies on the two FADT fields:
FLUSH_SIZE. Indicates twice the size of the largest cache in bytes.
FLUSH_STRIDE. Indicates the smallest line size of the caches in bytes.
Low Power Idle (LPI)
ACPI v6.0 introduced Low Power Idle mode in S0. S0 Idle could achieve savings similar to or better than those typically achieved in S3. OSPM can keep the system in S0 idle for its low-latency response rather than transitioning to a system sleep state.
Linux ACPI Suspend Flow
acpi_enter_sleep_state uses hardware sleep control and status register to put the system to sleep and wake up.
PSCI-based suspend for Arm platforms
Arm platforms implement PSCI standards (mandated by BSA spec) and rather than introducing the sleep control and status register could make use of the PSCI standard for putting CPU and platform to suspend state.
...
PSCI_CPU_SUSPEND API has a power_state parameter and some of the bits are vendor-specific and this is typically defined in the DT. How do we derive this for ACPI?
Linux commands to test ACPI suspend states
Disable console suspend to get full suspend traces
| Code Block |
|---|
echo N > /sys/module/printk/parameters/console_suspend |
S1
| Code Block |
|---|
echo standby > /sys/power/state |
S3
| Code Block |
|---|
echo deep > /sys/power/mem_sleep
echo mem > /sys/power/state |
S4
| Code Block |
|---|
echo disk > /sys/power/state |
S2Idle
| Code Block |
|---|
echo freeze > /sys/power/state |
Linux testing status for ACPI suspend using PSCI
Suspend State | Wake Up event | Status | Notes |
|---|---|---|---|
S2Idle | Lid | OK | |
S2Idle | RTC Alarm | OK | Linux kernel uses few ACPI GPE functions to determine if the device can wake up. They return wrong values for Arm64 implementation and had to be disabled during the testing. |
S1 | Lid | OK | |
S1 | RTC Alarm | OK | |
S3 | TF-A hack to wake up immediately after suspend | OK | This works only with single processor suspend, for SMP the wake up sequence crashes. The same behaviour is observed for DT as well. |
Gaps in existing Linux implementation
Linux kernel uses a few ACPI GPE functions to determine if the device can wake up and set appropriate flags. GPE is not present in HW-reduced platforms.
Linux ACPI suspend does not have PSCI bindings