Advanced Configuration and Power Interface Specification

Advanced Configuration and Power Interface Specification
Device BAH can only wake the system if it is in the D0 state. To be in D0 it requires PWRA, PWRB
and PWRC to be on. Therefore device BAH could only wake the system from LPI 1. If this device is
enabled for wake, then the platform must not enter LPI 2 or deeper.
Device BAR can wake the system in whilst it is in any device state other than D3Cold. However, to
do so, it requires PWRC to be on. Therefore it can only wake the system from LPI 1 or LPI 2. If this
device is enabled for wake, then the platform must not enter LPI 3 or deeper.
Device FOO can wake the system whilst it is in any device state. However to do so, it requires
PWRD to be on. Therefore it can only wake the system from LPI 1 or LPI 2 or LPI 3. If this device
is enabled for wake, then the platform must not enter LPI 4.
8.4.4.3.8 Default Idle State
The shallowest idle state for each leaf node in the hierarchy is the “default” idle state for that
processor and is assumed to always be enterable. The worst case wakeup latency and minimum
residency for this state must be low enough that OSPM need not consider them when deciding
whether to use it. Aside from putting the processor in a power state, this state has no other softwarevisible
effects. For example, it does not lose any context that OSPM must save/restore or have any
device dependencies.
8.4.4.4 _RDI (Resource Dependencies for Idle)
Some platforms may have power resources that are shared between devices and processors.
Abstractly, these resources are managed in two stages. First, the OS does normal power resource
reference counting to detect when all device dependencies have been satisfied and the resource may
be power managed from the device perspective. Then, when the processors also go idle, the OS
requests entry into specific LPI states and the platform physically power manages the resources as
part of the transition. The dependency between the power resources and the LPI state is described in
_RDI.
_RDI objects may only be present at the root processor container that describes the processor
hierarchy of the system. _RDI is not supported in a system that has more than one root node. _RDI is
valid only in a singular top level container which encompasses all processors in the system.
The OSPM will ignore _RDI objects that are present at any node other than the root node. This
simplification avoids complicated races between processors in one part of the hierarchy choosing
idle states with resource dependencies while another processor is changing device states/power
resources.
Arguments:
None
Return Value:
A variable-length Package containing the resource dependencies with the following format:
Return Value Information
458 April, 2015 Version 6.0