1 ==========================================
2 ARM idle states binding description
3 ==========================================
5 ==========================================
7 ==========================================
9 ARM systems contain HW capable of managing power consumption dynamically,
10 where cores can be put in different low-power states (ranging from simple
11 wfi to power gating) according to OS PM policies. The CPU states representing
12 the range of dynamic idle states that a processor can enter at run-time, can be
13 specified through device tree bindings representing the parameters required
14 to enter/exit specific idle states on a given processor.
16 According to the Server Base System Architecture document (SBSA, [3]), the
17 power states an ARM CPU can be put into are identified by the following list:
25 The power states described in the SBSA document define the basic CPU states on
26 top of which ARM platforms implement power management schemes that allow an OS
27 PM implementation to put the processor in different idle states (which include
28 states listed above; "off" state is not an idle state since it does not have
29 wake-up capabilities, hence it is not considered in this document).
31 Idle state parameters (eg entry latency) are platform specific and need to be
32 characterized with bindings that provide the required information to OS PM
33 code so that it can build the required tables and use them at runtime.
35 The device tree binding definition for ARM idle states is the subject of this
38 ===========================================
39 2 - idle-states definitions
40 ===========================================
42 Idle states are characterized for a specific system through a set of
43 timing and energy related properties, that underline the HW behaviour
44 triggered upon idle states entry and exit.
46 The following diagram depicts the CPU execution phases and related timing
47 properties required to enter and exit an idle state:
49 ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__..
52 |<------ entry ------->|
56 |<-------- min-residency -------->|
57 |<------- wakeup-latency ------->|
59 Diagram 1: CPU idle state execution phases
61 EXEC: Normal CPU execution.
63 PREP: Preparation phase before committing the hardware to idle mode
64 like cache flushing. This is abortable on pending wake-up
65 event conditions. The abort latency is assumed to be negligible
66 (i.e. less than the ENTRY + EXIT duration). If aborted, CPU
67 goes back to EXEC. This phase is optional. If not abortable,
68 this should be included in the ENTRY phase instead.
70 ENTRY: The hardware is committed to idle mode. This period must run
71 to completion up to IDLE before anything else can happen.
73 IDLE: This is the actual energy-saving idle period. This may last
74 between 0 and infinite time, until a wake-up event occurs.
76 EXIT: Period during which the CPU is brought back to operational
79 entry-latency: Worst case latency required to enter the idle state. The
80 exit-latency may be guaranteed only after entry-latency has passed.
82 min-residency: Minimum period, including preparation and entry, for a given
83 idle state to be worthwhile energywise.
85 wakeup-latency: Maximum delay between the signaling of a wake-up event and the
86 CPU being able to execute normal code again. If not specified, this is assumed
87 to be entry-latency + exit-latency.
89 These timing parameters can be used by an OS in different circumstances.
91 An idle CPU requires the expected min-residency time to select the most
92 appropriate idle state based on the expected expiry time of the next IRQ
93 (ie wake-up) that causes the CPU to return to the EXEC phase.
95 An operating system scheduler may need to compute the shortest wake-up delay
96 for CPUs in the system by detecting how long will it take to get a CPU out
99 wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
101 In other words, the scheduler can make its scheduling decision by selecting
102 (eg waking-up) the CPU with the shortest wake-up latency.
103 The wake-up latency must take into account the entry latency if that period
104 has not expired. The abortable nature of the PREP period can be ignored
105 if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
106 the worst case since it depends on the CPU operating conditions, ie caches
109 An OS has to reliably probe the wakeup-latency since some devices can enforce
110 latency constraints guarantees to work properly, so the OS has to detect the
111 worst case wake-up latency it can incur if a CPU is allowed to enter an
112 idle state, and possibly to prevent that to guarantee reliable device
115 The min-residency time parameter deserves further explanation since it is
116 expressed in time units but must factor in energy consumption coefficients.
118 The energy consumption of a cpu when it enters a power state can be roughly
119 characterised by the following graph:
138 -----|-------+----------------------------------
141 Graph 1: Energy vs time example
143 The graph is split in two parts delimited by time 1ms on the X-axis.
144 The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
145 and denotes the energy costs incurred while entering and leaving the idle
147 The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
148 shallower slope and essentially represents the energy consumption of the idle
151 min-residency is defined for a given idle state as the minimum expected
152 residency time for a state (inclusive of preparation and entry) after
153 which choosing that state become the most energy efficient option. A good
154 way to visualise this, is by taking the same graph above and comparing some
155 states energy consumptions plots.
157 For sake of simplicity, let's consider a system with two idle states IDLE1,
167 r | /-----/--------- IDLE2
168 g | /-------/---------
169 y | ------------ /---|
178 ---/----------------------------+------------------------
179 |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy
183 Graph 2: idle states min-residency example
185 In graph 2 above, that takes into account idle states entry/exit energy
186 costs, it is clear that if the idle state residency time (ie time till next
187 wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
190 This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
193 However, the lower power consumption (ie shallower energy curve slope) of idle
194 state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
197 The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
198 shallower states in a system with multiple idle states) is defined
199 IDLE2-min-residency and corresponds to the time when energy consumption of
200 IDLE1 and IDLE2 states breaks even.
202 The definitions provided in this section underpin the idle states
203 properties specification that is the subject of the following sections.
205 ===========================================
207 ===========================================
209 ARM processor idle states are defined within the idle-states node, which is
210 a direct child of the cpus node [1] and provides a container where the
211 processor idle states, defined as device tree nodes, are listed.
215 Usage: Optional - On ARM systems, it is a container of processor idle
216 states nodes. If the system does not provide CPU
217 power management capabilities or the processor just
218 supports idle_standby an idle-states node is not
221 Description: idle-states node is a container node, where its
222 subnodes describe the CPU idle states.
224 Node name must be "idle-states".
226 The idle-states node's parent node must be the cpus node.
228 The idle-states node's child nodes can be:
230 - one or more state nodes
232 Any other configuration is considered invalid.
234 An idle-states node defines the following properties:
237 Value type: <stringlist>
238 Usage and definition depend on ARM architecture version.
239 # On ARM v8 64-bit this property is required and must
242 # On ARM 32-bit systems this property is optional
244 This assumes that the "enable-method" property is set to "psci" in the cpu
245 node[6] that is responsible for setting up CPU idle management in the OS
248 The nodes describing the idle states (state) can only be defined
249 within the idle-states node, any other configuration is considered invalid
250 and therefore must be ignored.
252 ===========================================
254 ===========================================
256 A state node represents an idle state description and must be defined as
261 Description: must be child of the idle-states node
263 The state node name shall follow standard device tree naming
264 rules ([5], 2.2.1 "Node names"), in particular state nodes which
265 are siblings within a single common parent must be given a unique name.
267 The idle state entered by executing the wfi instruction (idle_standby
268 SBSA,[3][4]) is considered standard on all ARM platforms and therefore
271 With the definitions provided above, the following list represents
272 the valid properties for a state node:
276 Value type: <stringlist>
277 Definition: Must be "arm,idle-state".
280 Usage: See definition
282 Definition: if present the CPU local timer control logic is
283 lost on state entry, otherwise it is retained.
287 Value type: <prop-encoded-array>
288 Definition: u32 value representing worst case latency in
289 microseconds required to enter the idle state.
290 The exit-latency-us duration may be guaranteed
291 only after entry-latency-us has passed.
295 Value type: <prop-encoded-array>
296 Definition: u32 value representing worst case latency
297 in microseconds required to exit the idle state.
301 Value type: <prop-encoded-array>
302 Definition: u32 value representing minimum residency duration
303 in microseconds, inclusive of preparation and
304 entry, for this idle state to be considered
305 worthwhile energy wise (refer to section 2 of
306 this document for a complete description).
310 Value type: <prop-encoded-array>
311 Definition: u32 value representing maximum delay between the
312 signaling of a wake-up event and the CPU being
313 able to execute normal code again. If omitted,
314 this is assumed to be equal to:
316 entry-latency-us + exit-latency-us
318 It is important to supply this value on systems
319 where the duration of PREP phase (see diagram 1,
320 section 2) is non-neglibigle.
321 In such systems entry-latency-us + exit-latency-us
322 will exceed wakeup-latency-us by this duration.
327 Definition: A standard device tree property [5] that indicates
328 the operational status of an idle-state.
329 If present, it shall be:
330 "okay": to indicate that the idle state is
332 "disabled": to indicate that the idle state has
333 been disabled in firmware so it is not
335 If the property is not present the idle-state must
336 be considered operational.
341 Definition: A string used as a descriptive name for the idle
344 In addition to the properties listed above, a state node may require
345 additional properties specifics to the entry-method defined in the
346 idle-states node, please refer to the entry-method bindings
347 documentation for properties definitions.
349 ===========================================
351 ===========================================
353 Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
357 #address-cells = <2>;
361 compatible = "arm,cortex-a57";
363 enable-method = "psci";
364 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
365 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
370 compatible = "arm,cortex-a57";
372 enable-method = "psci";
373 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
374 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
379 compatible = "arm,cortex-a57";
381 enable-method = "psci";
382 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
383 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
388 compatible = "arm,cortex-a57";
390 enable-method = "psci";
391 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
392 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
397 compatible = "arm,cortex-a57";
399 enable-method = "psci";
400 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
401 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
406 compatible = "arm,cortex-a57";
408 enable-method = "psci";
409 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
410 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
415 compatible = "arm,cortex-a57";
417 enable-method = "psci";
418 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
419 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
424 compatible = "arm,cortex-a57";
426 enable-method = "psci";
427 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
428 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
431 CPU8: cpu@100000000 {
433 compatible = "arm,cortex-a53";
435 enable-method = "psci";
436 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
437 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
440 CPU9: cpu@100000001 {
442 compatible = "arm,cortex-a53";
444 enable-method = "psci";
445 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
446 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
449 CPU10: cpu@100000100 {
451 compatible = "arm,cortex-a53";
453 enable-method = "psci";
454 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
455 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
458 CPU11: cpu@100000101 {
460 compatible = "arm,cortex-a53";
462 enable-method = "psci";
463 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
464 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
467 CPU12: cpu@100010000 {
469 compatible = "arm,cortex-a53";
471 enable-method = "psci";
472 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
473 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
476 CPU13: cpu@100010001 {
478 compatible = "arm,cortex-a53";
480 enable-method = "psci";
481 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
482 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
485 CPU14: cpu@100010100 {
487 compatible = "arm,cortex-a53";
489 enable-method = "psci";
490 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
491 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
494 CPU15: cpu@100010101 {
496 compatible = "arm,cortex-a53";
498 enable-method = "psci";
499 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
500 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
504 entry-method = "psci";
506 CPU_RETENTION_0_0: cpu-retention-0-0 {
507 compatible = "arm,idle-state";
508 arm,psci-suspend-param = <0x0010000>;
509 entry-latency-us = <20>;
510 exit-latency-us = <40>;
511 min-residency-us = <80>;
514 CLUSTER_RETENTION_0: cluster-retention-0 {
515 compatible = "arm,idle-state";
517 arm,psci-suspend-param = <0x1010000>;
518 entry-latency-us = <50>;
519 exit-latency-us = <100>;
520 min-residency-us = <250>;
521 wakeup-latency-us = <130>;
524 CPU_SLEEP_0_0: cpu-sleep-0-0 {
525 compatible = "arm,idle-state";
527 arm,psci-suspend-param = <0x0010000>;
528 entry-latency-us = <250>;
529 exit-latency-us = <500>;
530 min-residency-us = <950>;
533 CLUSTER_SLEEP_0: cluster-sleep-0 {
534 compatible = "arm,idle-state";
536 arm,psci-suspend-param = <0x1010000>;
537 entry-latency-us = <600>;
538 exit-latency-us = <1100>;
539 min-residency-us = <2700>;
540 wakeup-latency-us = <1500>;
543 CPU_RETENTION_1_0: cpu-retention-1-0 {
544 compatible = "arm,idle-state";
545 arm,psci-suspend-param = <0x0010000>;
546 entry-latency-us = <20>;
547 exit-latency-us = <40>;
548 min-residency-us = <90>;
551 CLUSTER_RETENTION_1: cluster-retention-1 {
552 compatible = "arm,idle-state";
554 arm,psci-suspend-param = <0x1010000>;
555 entry-latency-us = <50>;
556 exit-latency-us = <100>;
557 min-residency-us = <270>;
558 wakeup-latency-us = <100>;
561 CPU_SLEEP_1_0: cpu-sleep-1-0 {
562 compatible = "arm,idle-state";
564 arm,psci-suspend-param = <0x0010000>;
565 entry-latency-us = <70>;
566 exit-latency-us = <100>;
567 min-residency-us = <300>;
568 wakeup-latency-us = <150>;
571 CLUSTER_SLEEP_1: cluster-sleep-1 {
572 compatible = "arm,idle-state";
574 arm,psci-suspend-param = <0x1010000>;
575 entry-latency-us = <500>;
576 exit-latency-us = <1200>;
577 min-residency-us = <3500>;
578 wakeup-latency-us = <1300>;
584 Example 2 (ARM 32-bit, 8-cpu system, two clusters):
588 #address-cells = <1>;
592 compatible = "arm,cortex-a15";
594 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
599 compatible = "arm,cortex-a15";
601 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
606 compatible = "arm,cortex-a15";
608 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
613 compatible = "arm,cortex-a15";
615 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
620 compatible = "arm,cortex-a7";
622 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
627 compatible = "arm,cortex-a7";
629 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
634 compatible = "arm,cortex-a7";
636 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
641 compatible = "arm,cortex-a7";
643 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
647 CPU_SLEEP_0_0: cpu-sleep-0-0 {
648 compatible = "arm,idle-state";
650 entry-latency-us = <200>;
651 exit-latency-us = <100>;
652 min-residency-us = <400>;
653 wakeup-latency-us = <250>;
656 CLUSTER_SLEEP_0: cluster-sleep-0 {
657 compatible = "arm,idle-state";
659 entry-latency-us = <500>;
660 exit-latency-us = <1500>;
661 min-residency-us = <2500>;
662 wakeup-latency-us = <1700>;
665 CPU_SLEEP_1_0: cpu-sleep-1-0 {
666 compatible = "arm,idle-state";
668 entry-latency-us = <300>;
669 exit-latency-us = <500>;
670 min-residency-us = <900>;
671 wakeup-latency-us = <600>;
674 CLUSTER_SLEEP_1: cluster-sleep-1 {
675 compatible = "arm,idle-state";
677 entry-latency-us = <800>;
678 exit-latency-us = <2000>;
679 min-residency-us = <6500>;
680 wakeup-latency-us = <2300>;
686 ===========================================
688 ===========================================
690 [1] ARM Linux Kernel documentation - CPUs bindings
691 Documentation/devicetree/bindings/arm/cpus.yaml
693 [2] ARM Linux Kernel documentation - PSCI bindings
694 Documentation/devicetree/bindings/arm/psci.yaml
696 [3] ARM Server Base System Architecture (SBSA)
697 http://infocenter.arm.com/help/index.jsp
699 [4] ARM Architecture Reference Manuals
700 http://infocenter.arm.com/help/index.jsp
702 [5] Devicetree Specification
703 https://www.devicetree.org/specifications/
705 [6] ARM Linux Kernel documentation - Booting AArch64 Linux
706 Documentation/arm64/booting.txt