Advanced Configuration and Power Interface Specification

Advanced Configuration and Power Interface Specification
System Level Processor
Container
Cluster level Processor
Container
Processor
Running Clock Gated Retention
Running Clock Gated Power Down
Running Retention Retention
Running Retention Power Down
Running Power Down Power Down
Power Down Power Down Power Down
8.4.4.2 Idle State Coordination
With hierarchical idle states, multiple processors affect the idle state for any non-leaf hierarchy
node. Taking our example system in Figure 8-46, for cluster 0 to enter a low power state, both Core
0 and Core 1 must be idle. In addition, the power state selection done for Core 0 and Core 1 as they
go idle has bearing on the state that can be used for Cluster 0. This requires coordination of idle state
requests between the two processors. ACPI supports two different coordination schemes (detailed in
subsections following):
• Platform coordinated
• OS initiated.
The OS and the platform can handshake on support for OS Initiated Idle or Platform Coordinated
Idle using the _OSC method as described in Section 6.2.11.2. Note that an Architecture specific
command may be required to enter OS Initiated mode, in which case please refer to architecture
specific documentation. (For PSCI documentation see http://uefi.org/acpi under the heading “PCSI
Specification”; for ARM FFH documentation, see http://uefi.org/acpi under the heading “ARM FFH
Specification”.)
8.4.4.2.1 Platform Coordinated
With the Platform Coordinated scheme, the platform is responsible for coordination of idle states
across processors. OSPM makes a request for all levels of hierarchy from each processor meaning
that each processor makes a vote by requesting a local power state for itself, its parent, its parent’s
parent, etc. (In some cases, the vote for a particular hierarchy level may be implicit – see the
autopromotion discussion below for more details). When choosing idle states at higher levels, the
OSPM on a processor may opt to keep a higher level node in a running state – this is still a vote for
that node which the platform must respect. The vote expressed by the OSPM sets out the constraints
on the local power state that the platform may choose for processor, and any parent nodes affected
by the vote. In particular the vote expresses that the platform must not enter:
1. A deeper (lower power) local state than the requested one.
2. A local power state with a higher wake up latency than the requested one.
3. A local power state with power resource dependencies that the requested state does not have.
The platform looks across the votes for each hierarchy node from all underlying cores and chooses
the deepest local state which satisfies all of the constraints associated with all of the votes. Normally,
this just means taking the shallowest state that one of the cores voted for, since shallower states have
lower wakeup latencies, lower minimum residencies, and fewer power resource dependencies.
However, this may not always be the true, as state depth and latencies do not always increase
438 April, 2015 Version 6.0