![](https://csdnimg.cn/release/download_crawler_static/12646257/bg11.jpg)
PSCI Use Cases and Use Case Requirements
Copyright
2012, 2013, 2015, 2017 ARM Limited or its affiliates. All rights reserved.
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.