ARM平台电源状态协调接口规范

需积分: 47 12 浏览量更新于2024-07-15 收藏 1.93MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"ARM Power State Coordination Interface (PSCI) Platform Design Document v1.1 (DEN0022D)" 本文档定义了ARM设备上操作系统供应商用于管理电源的标准接口，适用于在不同特权级别运行的监督软件，如Linux、Windows、hypervisors（虚拟机监控程序）、安全固件和Trusted OS实现。该标准的目标是简化来自不同供应商的在不同特权层工作的监督软件之间的集成，确保在电源管理方面能够顺利交互和协同工作。 ARM的Power State Coordination Interface (PSCI)是一个关键的系统软件规范，它提供了一种方法来管理和协调处理器及平台组件的电源状态。PSCI允许操作系统和固件之间进行通信，以便高效地控制硬件的电源状态，从而实现电源管理和能效优化。这在嵌入式和移动设备中尤其重要，因为这些设备通常需要在性能和电池寿命之间取得平衡。 PSCI的主要功能包括： 1. **处理器状态转换**：PSCI提供了API（应用程序编程接口）来使处理器在不同电源模式间切换，如休眠、待机和关闭状态。这有助于减少功耗，同时确保快速响应。 2. **系统级电源管理**：PSCI允许对整个系统的电源状态进行协调，包括CPU集群和GPU的休眠或唤醒，以及内存的电源优化。 3. **热管理**：PSCI可以与温度传感器和热管理策略配合，防止过热并确保设备在安全的温度范围内运行。 4. **安全特性**：在安全固件和Trusted OS环境中，PSCI支持安全启动和安全关机过程，确保在电源状态转换时系统的完整性。 5. **版本控制和兼容性**：PSCI的不同版本（如1.0和1.1）引入了错误修复和新功能，保证了跨不同平台和软件栈的兼容性。 6. **异构计算支持**：对于具有多个CPU核心和/或其他处理单元（如GPU）的多核系统，PSCI允许有效管理这些组件的电源状态，优化多任务处理和负载平衡。 7. **错误报告和故障恢复**：PSCI提供了一种机制，用于报告电源管理操作期间的错误，并帮助系统从异常状态恢复。通过实施PSCI，开发人员能够创建更高效、更可靠的系统，这些系统能够在保持高性能的同时，延长电池寿命，并且在不同操作系统和固件之间提供一致的电源管理体验。PSCI已成为基于ARM架构的设备电源管理的事实标准，广泛应用于智能手机、平板电脑、物联网设备和服务器等场景。

资源详情

资源推荐

PSCI Use Cases and Use Case Requirements

16 Copyright



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 a 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 a superset of the corresponding set for state Y.

 The set of components that is powered down in state X is the same

as the corresponding set for state Y, 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, when a core has been placed into a low-power state, it

can be reactivated at any time by a wakeup event, which is an event that

might 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

PSCI Use Cases and Use Case Requirements



Non-Confidential

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 that 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 the 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].

Powerdown: 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 powerdown states one or

both of debug and trace contexts 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 must 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.

PSCI Use Cases and Use Case Requirements

18 Copyright



Non-Confidential

ARM expects 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.

Powerdown states require an interface so that each level of execution can

save and restore its context appropriately. For powerdown 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 powerdown interface, at the

required return address. PSCI provides 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,

coprocessors, or GPUs), memories (caches, DRAMs), and fabric (for

example inter-cluster and intra-cluster coherency fabric). PSCA [1]

provides detailed descriptions of how power domains can be constructed in

systems that use ARM components.

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 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, to guarantee correct operation.

PSCI Use Cases and Use Case Requirements



Non-Confidential

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 shows 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 two 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 powerdown in a higher-level node can only be combined with

powerdown states in lower-level children.

剩余104页未读，继续阅读

wyqt_1

粉丝: 1
资源: 11

ARM平台电源状态协调接口规范

DEN0022C_Power_State_Coordination_Interface.pdf

DEN0021D Trusted_Base_System_Architecture_Client.pdf

DEN0024A_v8_architecture_PG.rar

make menuconfig 中的 [ ] Support for the ARM Power State Coordination Interface (PSCI) 介绍

cannot get resource leases in API group coordination.k8s.io in the namespace kube-system

Caused by: org.elasticsearch.cluster.coordination.CoordinationStateRejectedException: incoming last accepted version 49943 of join higher than current last accepted version 49942 in term 826

TypeError: Couldn't build proto file into descriptor pool! Invalid proto descriptor for file "tensorflow/tsl/protobuf/coordination_config.proto":

python利用ASE获得POSCAR或者cif结构文件中C原子在2A范围内的配位数

virtual bool db::ddlworker::initializemainthread(): code: 999. coordination:

x_y = re.findall(r'\(\s*([0-9]+\.?[0-9]*),\s*([0-9]+\.?[0-9]*)\s*\)',coordination_source)

DRL matlab

Code: 999, e.displayText() = Coordination::Exception: Not authenticated, path: /clickhouse (version 20.8.3.18)

i.mx8qxp scu psci 介绍

distributed coordination of multi-agent networks pdf

帮我检索20篇有关语义协同的外文文献

zookeeper在linux自启动

Linux移植之PSCI

linux psci

zookeeper设置开机自启

有关业余运动爱好者穿着运动紧身装备下的肌电特征研究创新创业计划项目的申报书的研究方法写1000字 并且有参考文献

最新资源

x_y = re.findall(r'\(\s([0-9]+\.?[0-9]),\s([0-9]+\.?[0-9])\s*\)',coordination_source)

有关业余运动爱好者穿着运动紧身装备下的肌电特征研究创新创业计划项目的申报书的研究方法写1000字并且有参考文献