ARM PSCI接口手册：Power State Coordination Interface规范

需积分: 9 156 浏览量更新于2024-07-16 收藏 1.4MB PDF 举报

DEN0022C_Power_State_Coordination_Interface (PSCI) 是ARM系统中的一个关键接口，它专注于系统的电源管理协调。这份文档，ARM DEN0022C，专门针对ARM架构的系统软件，提供了关于PSCI的详细规范和指南。PSCI版本0.2在2013年6月发布了第二个非保密版本，随后在2015年1月进行了升级，发布了PSCI 1.0版本，并对0.2版本进行了修正。 PSCI的作用在于帮助操作系统（OS）和其他系统软件组件协调处理器的不同电源状态，如低功耗模式（如S0、S1、S2、S3等），以实现更高效的能效管理。这个接口定义了硬件和软件之间通信的标准，使得它们能够协调执行电源状态转换，例如在休眠或唤醒时，确保数据的保存和恢复。这份文档详细列出了PSCI的各种功能特性，包括如何通知处理器进入不同的电源状态，以及在状态转换过程中可能涉及的中断处理和同步机制。它还包含了错误处理和兼容性信息，确保不同厂商的硬件设计在遵循标准的同时，能够无缝协作。值得注意的是，PSCI文档强调了版权和保密性的保护。未经ARM的明确书面许可，任何形式的复制或实施文档中的信息都必须得到许可，且该技术可能受到专利保护，这表明PSCI是ARM知识产权的重要组成部分。 PSCI的使用对于开发能在低功耗设备上运行的高效应用程序至关重要，特别是在移动设备、物联网设备和嵌入式系统中，电源管理和节能性能是设计者关注的核心要素。通过理解和遵循PSCI规范，开发者可以优化他们的系统设计，减少能耗，延长电池寿命，并满足日益严格的能源效率要求。 DEN0022C_Power_State_Coordination_Interface.pdf是一份深入介绍ARM平台上的电源管理协调接口的重要参考资料，涵盖了接口设计、使用方法、版本更新及版权政策，是开发人员和系统工程师在设计低功耗、高性能系统时不可或缺的参考资料。

Assumptions and recommendations

14 Copyright



Non-Confidential

Virtual OSPM: This is an OSPM present in a guest OS running a virtual machine, which

selects virtual, rather than physical power states.

With type 2 hypervisors, the physical OSPM resides in the host. Actual power policy is

controlled from a Rich OS typically running at EL1. The physical OSPM is contained in this

Rich OS. This layer has a physical view of the cores. An example of this is shown below in

Figure 2 on the left hand side.

Figure 2 Typical Power management models in virtualization

For the power management functions covered in this document, type 2 hypervisor behavior

depends on the calling OS.

If the caller is the host, the hypervisor complies with the power request or allows the call to

pass straight through to the secure platform firmware. The hypervisor typically only

performs any necessary operations resulting from the call, for example, saving state on a

powerdown if needed. From this point onwards, the hypervisor calls through to the secure

platform firmware using the parameters supplied by the caller. If no special operations are

required, the hypervisor does not even trap calls from the host, and instead routes them

directly to the secure platform firmware.

When a type 2 hypervisor is implemented, guests use a virtual OSPM. They can also issue

power requests through the PSCI APIs, but the requests are issued in relation to virtual

cores and virtual power states. These requests are trapped by the hypervisor which issues

them back to the physical OSPM. This component can then determine whether physical

power management is required. For these guests, the power calls effectively terminate at

the hypervisor.

With a type 1 hypervisor, power policy is typically owned entirely by the hypervisor. This is

shown on the right hand side in Figure 2. The physical OSPM is implemented in the

hypervisor. In this case all guests have a virtualized view of the cores. The hypervisor

determines from the virtual power states of the guests whether physical power control is

required, and if so uses the PSCI API to coordinate with the secure platform firmware.

Guests can also use this API to communicate virtual power requirements to the hypervisor.

For these guests the calls effectively terminate at the hypervisor.

In some cases, type 1 hypervisors delegate power management to a privileged guest. In

these cases, the physical OSPM is implemented in that privileged guest. This power

management approach is equivalent to the model described above for type 2 hypervisors,

shown in Figure 2.

PSCI Use Cases and Use Case Requirements



Non-Confidential

4 PSCI Use Cases and Use Case Requirements

4.1 Idle management

When a core is idle the OSPM transitions it into a low-power state. Typically, a choice of

states is available, with different entry and exit latencies, and different levels of power

consumption associated with each state. The state that is used typically depends on how

quickly the core will be needed again. The power states that can be used at any one time

might also depend on the activity of other components in an SoC, in addition to the cores.

Each state is defined by the set of components that are clock-gated or power-gated when

the state is entered. States are sometimes described as being shallow or deep. Typically, a

state X is said to be deeper than a state Y if:

 The set of components that are powered down in state X subsumes and is larger

than the corresponding set for state Y.

 The set of components is the same, but various power modes are supported, and

the modes used in state X save more power than those used in state Y.

The time required to move from a low-power state to a running state is known as the

wakeup latency. Generally, deeper power states have longer wakeup latencies, but this is

not necessarily always the case.

Although idle power management is driven by thread behavior on a core, the OSPM can

place the platform into states that affect many other components beyond the core itself. For

example, if the last core in a SoC goes idle, the OSPM can target power states that affect

the whole SoC. The choice is also driven by the use of other components in the system,

and therefore might require coordination among multiple agents. A typical example is

placing the system into a state where memory is in self-refresh when all cores, and any

other bus masters, are idle. The OSPM has to provide the necessary power management

software infrastructure to determine the correct choice of state.

In idle management, once a core has been placed into a low-power state, it can be

reactivated at any time by a wakeup event. That is, an event that may wake up a core from

a low-power state, such as an interrupt. No explicit command is required by the OSPM to

bring the core or cluster back into operation. The OSPM considers the affected core or

cores to be available at all times even if they are currently in a low-power state.

An ARM core can be in any of the following power states:

Run: The core is powered up and operational.

Standby: The core is powered up, but measures are employed to reduce energy

consumption. In a typical implementation, the core enters standby by executing a

WFI or WFE instruction and exits on a corresponding wakeup event. The core

preserves all core state. Changing from standby to running operation does not

require a reset of the core. In standby, all core context is maintained, and can be

directly accessed on wakeup. No special actions are required by the OS to ensure

context is maintained. An external debugger can access debug registers in the

core power domain [1,5].

Retention: The core state, including the debug settings, is preserved in low-power

structures, allowing the core to be at least partially turned off. Changing from low-

power retention to running operation does not require a reset of the core. The

saved core state is restored on changing from low-power retention state to running

operation. From an OS point of view there is no difference between a retention

state and standby state, other than method of entry, latency, and usage-related

constraints. However, from an external debugger point of view the states differ as

External Debug Request debug events stay pending and debug registers in the

core power domain cannot be accessed [1,5].

PSCI Use Cases and Use Case Requirements

16 Copyright



Non-Confidential

Power-down: In this state the core is powered off. Software on the device needs to save

all core state, so that it can be preserved over the powerdown. Changing from

powerdown to running operation must include:

 A reset of the core, after the power has been restored.

 Restoring the saved core state.

The defining characteristic of powerdown states is that they are destructive of context. This

affects all the components that are switched off in a given state, including the core, and in

deeper states other components of the system such as the GIC or platform-specific IP.

Depending on how debug and trace power domains are organized, in some power-down

states one or both of debug and trace context might be lost. Mechanisms must be provided

to enable the OS to perform the relevant context saving and restoring for each given state.

Resumption of execution starts at the reset vector, after which each OS must restore its

context.

To an OS that is managing power, a standby state is mostly indistinguishable from a

retention state. The difference is evident to an external debugger, and in hardware

implementation, but not evident to the idle management subsystem of an OS.

Consequently, unless otherwise stated, this document uses the term standby to refer to

both standby and retention states.

An interface is required so that the OSPM can place a core into a low-power state when it

has no work for it. The messages sent through this interface must be received by all

relevant levels of execution. That is, if EL2 and EL3 are implemented, a message sent by a

Rich OS should be received by a hypervisor and the Secure world. Within the Secure world

the message needs to be seen by a Trusted OS, if present, and by any secure platform

firmware. This means that each level of supervisory software can determine whether it

must perform context saving.

ARM expects that the Exception level with the highest privilege, as defined in section 3.2,

to be the component that can program the power controller to enter an idle state. Typically,

this is the secure platform firmware. PSCI provides a mechanism for the OSPM to pass the

desired idle state to the next Exception level.

For standby states that do not require any explicit programming of the power controller, no

specific interface is required. The OSPM can use WFI or WFE instructions directly.

However, for deeper standby or retention states that require programming a power

controller, PSCI provides an interface that can hide the platform-specific code that

accesses the power controller.

Power-down states require an interface so that each level of execution can save and

restore its context appropriately. For power-down states, the interface requires a return

address. This is the address at which the calling OS expects resumption of execution on

wakeup at its Exception level. From a powered-down state, the core restarts at the reset

vector, in Secure state if the implementation includes EL3. After initializing, the Secure

world must re-start execution of the OS that called the power down interface, at the

required return address. PSCI provide a method of specifying return addresses, and

cookies that can be used for pointers to saved context.

4.2 Power state system topologies and coordination

Multiprocessor systems can have a number of different power domains to power different

elements of the system. Each power domain might contain a combination of one or more

processing elements (such as cores, co-processors, or GPUs), memories (caches,

DRAMs), and fabric (for example inter and intra cluster coherency fabric).

Each component in a power domain has a set of power states that affect the components

in the domain. Although physically the power domains are not necessarily built in a

hierarchical fashion, from a software control point of view, they are arranged in a logical

hierarchy. The hierarchy arises out of ordering dependencies that are required when

PSCI Use Cases and Use Case Requirements



Non-Confidential

placing the power domains into different power states. For example, consider a power

domain that encompasses a shared cache, and power domains for the cores that use it. In

such a system the core power domains must be powered down before the shared cache

domain, in order to guarantee correct operation.

System Level

Power States:

 Retention

 Power-Down

Cluster Level

Cluster 1

Power States:

 Retention

 Power-Down

Cluster Level

Cluster 0

Power States:

 Retention

 Power-Down

Core Level

Core 0

Power States:

 Standby (clock gate)

 Retention

 Power-Down

Core Level

Core 1

Power States:

 Standby (clock gate)

 Retention

 Power-Down

Core Level

Core 2

Power States:

 Standby (clock gate)

 Retention

 Power-Down

Core Level

Core 3

Power States:

 Standby (clock gate)

 Retention

 Power-Down

Figure 3 Example power domain topology

The diagram above provides the power domain topology of an example system. The

example shows a system level power domain that supports two power states. This power

domain has two children power domains, each of which includes a cluster and supports a

set of cluster power states. Each cluster power domain has a couple of children core level

power domains. Each of the core level power domains includes a core and supports

additional power states.

From a hardware perspective, a system is divided into multiple exclusive or shared power

domains. Each power domain can be represented as a node in a power domain topology

tree. Sibling power domains are mutually exclusive. Parent power domains are shared by

the children. The various levels in the tree (core, cluster, and system in the example) are

referred to as power levels. Higher levels are closer to the root of the tree (system) and

lower levels are closer to the leaves (the cores).

4.2.1 Local power states and composite power states

Individual nodes in a topology have their own specific power states, which are referred to

here as local power states. When an OS, running on an idle core, requests a power state,

it might need to express not just a local power state for the core, but also for any parent

nodes. For instance taking our example system from Figure 3, if Core 1 was the last to go

idle in Cluster 0 it would make sense for the OS to request a local power state for the

cluster as well as the core. We refer to the combined power state that an OS might request

as a composite power state. Not every combination of local states is possible. When a

node at a power level is in a certain local power state, parent nodes at higher power levels

cannot be in a deeper local state. In other words:

1. A power-down in a higher-level node can only be combined with power-down states in

lower level children.

2. A retention state in a higher level node might only be combined with retention or power-

down states in lower level children.

3. A standby (clock gated) state in a higher level node allows lower level children to be in

standby, retention, or power-down states.

剩余83页未读，继续阅读

sanyanamao

粉丝: 2
资源: 3

ARM PSCI接口手册：Power State Coordination Interface规范

Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

DEN0022D_b_Power_State_Coordination_Interface.pdf

DEN0022E-Power-State-Coordination-Interface-BETA

ns2.1b8_802.11_mac_pcf.rar_802.11_802.11 pcf_c++ 802.11

LTE-power-control.rar_LTE功率_lte power control_lte功率控制_power cont

interference_coordination.rar_LTE matlab_LTE-A MATLAB_LTE-Advanc

of_pci.rar_coordination

Operation_for_the_Next_Generation_WLAN_IEEE_802.11be_EHT.pdf

DCF.zip_802.11_802.11 dcf_DCF改进_dcf_dcf tcl

WS-Coordination.pdf

最新资源