1# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 2%YAML 1.2 3--- 4$id: http://devicetree.org/schemas/cpu/idle-states.yaml# 5$schema: http://devicetree.org/meta-schemas/core.yaml# 6 7title: Idle states binding description 8 9maintainers: 10 - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 11 - Anup Patel <anup@brainfault.org> 12 13description: |+ 14 ========================================== 15 1 - Introduction 16 ========================================== 17 18 ARM and RISC-V systems contain HW capable of managing power consumption 19 dynamically, where cores can be put in different low-power states (ranging 20 from simple wfi to power gating) according to OS PM policies. The CPU states 21 representing the range of dynamic idle states that a processor can enter at 22 run-time, can be specified through device tree bindings representing the 23 parameters required to enter/exit specific idle states on a given processor. 24 25 ========================================== 26 2 - ARM idle states 27 ========================================== 28 29 According to the Server Base System Architecture document (SBSA, [3]), the 30 power states an ARM CPU can be put into are identified by the following list: 31 32 - Running 33 - Idle_standby 34 - Idle_retention 35 - Sleep 36 - Off 37 38 The power states described in the SBSA document define the basic CPU states on 39 top of which ARM platforms implement power management schemes that allow an OS 40 PM implementation to put the processor in different idle states (which include 41 states listed above; "off" state is not an idle state since it does not have 42 wake-up capabilities, hence it is not considered in this document). 43 44 Idle state parameters (e.g. entry latency) are platform specific and need to 45 be characterized with bindings that provide the required information to OS PM 46 code so that it can build the required tables and use them at runtime. 47 48 The device tree binding definition for ARM idle states is the subject of this 49 document. 50 51 ========================================== 52 3 - RISC-V idle states 53 ========================================== 54 55 On RISC-V systems, the HARTs (or CPUs) [6] can be put in platform specific 56 suspend (or idle) states (ranging from simple WFI, power gating, etc). The 57 RISC-V SBI v0.3 (or higher) [7] hart state management extension provides a 58 standard mechanism for OS to request HART state transitions. 59 60 The platform specific suspend (or idle) states of a hart can be either 61 retentive or non-rententive in nature. A retentive suspend state will 62 preserve HART registers and CSR values for all privilege modes whereas 63 a non-retentive suspend state will not preserve HART registers and CSR 64 values. 65 66 =========================================== 67 4 - idle-states definitions 68 =========================================== 69 70 Idle states are characterized for a specific system through a set of 71 timing and energy related properties, that underline the HW behaviour 72 triggered upon idle states entry and exit. 73 74 The following diagram depicts the CPU execution phases and related timing 75 properties required to enter and exit an idle state: 76 77 ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__.. 78 | | | | | 79 80 |<------ entry ------->| 81 | latency | 82 |<- exit ->| 83 | latency | 84 |<-------- min-residency -------->| 85 |<------- wakeup-latency ------->| 86 87 Diagram 1: CPU idle state execution phases 88 89 EXEC: Normal CPU execution. 90 91 PREP: Preparation phase before committing the hardware to idle mode 92 like cache flushing. This is abortable on pending wake-up 93 event conditions. The abort latency is assumed to be negligible 94 (i.e. less than the ENTRY + EXIT duration). If aborted, CPU 95 goes back to EXEC. This phase is optional. If not abortable, 96 this should be included in the ENTRY phase instead. 97 98 ENTRY: The hardware is committed to idle mode. This period must run 99 to completion up to IDLE before anything else can happen. 100 101 IDLE: This is the actual energy-saving idle period. This may last 102 between 0 and infinite time, until a wake-up event occurs. 103 104 EXIT: Period during which the CPU is brought back to operational 105 mode (EXEC). 106 107 entry-latency: Worst case latency required to enter the idle state. The 108 exit-latency may be guaranteed only after entry-latency has passed. 109 110 min-residency: Minimum period, including preparation and entry, for a given 111 idle state to be worthwhile energywise. 112 113 wakeup-latency: Maximum delay between the signaling of a wake-up event and the 114 CPU being able to execute normal code again. If not specified, this is assumed 115 to be entry-latency + exit-latency. 116 117 These timing parameters can be used by an OS in different circumstances. 118 119 An idle CPU requires the expected min-residency time to select the most 120 appropriate idle state based on the expected expiry time of the next IRQ 121 (i.e. wake-up) that causes the CPU to return to the EXEC phase. 122 123 An operating system scheduler may need to compute the shortest wake-up delay 124 for CPUs in the system by detecting how long will it take to get a CPU out 125 of an idle state, e.g.: 126 127 wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) 128 129 In other words, the scheduler can make its scheduling decision by selecting 130 (e.g. waking-up) the CPU with the shortest wake-up delay. 131 The wake-up delay must take into account the entry latency if that period 132 has not expired. The abortable nature of the PREP period can be ignored 133 if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than 134 the worst case since it depends on the CPU operating conditions, i.e. caches 135 state). 136 137 An OS has to reliably probe the wakeup-latency since some devices can enforce 138 latency constraint guarantees to work properly, so the OS has to detect the 139 worst case wake-up latency it can incur if a CPU is allowed to enter an 140 idle state, and possibly to prevent that to guarantee reliable device 141 functioning. 142 143 The min-residency time parameter deserves further explanation since it is 144 expressed in time units but must factor in energy consumption coefficients. 145 146 The energy consumption of a cpu when it enters a power state can be roughly 147 characterised by the following graph: 148 149 | 150 | 151 | 152 e | 153 n | /--- 154 e | /------ 155 r | /------ 156 g | /----- 157 y | /------ 158 | ---- 159 | /| 160 | / | 161 | / | 162 | / | 163 | / | 164 | / | 165 |/ | 166 -----|-------+---------------------------------- 167 0| 1 time(ms) 168 169 Graph 1: Energy vs time example 170 171 The graph is split in two parts delimited by time 1ms on the X-axis. 172 The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope 173 and denotes the energy costs incurred while entering and leaving the idle 174 state. 175 The graph curve in the area delimited by X-axis values = {x | x > 1ms } has 176 shallower slope and essentially represents the energy consumption of the idle 177 state. 178 179 min-residency is defined for a given idle state as the minimum expected 180 residency time for a state (inclusive of preparation and entry) after 181 which choosing that state become the most energy efficient option. A good 182 way to visualise this, is by taking the same graph above and comparing some 183 states energy consumptions plots. 184 185 For sake of simplicity, let's consider a system with two idle states IDLE1, 186 and IDLE2: 187 188 | 189 | 190 | 191 | /-- IDLE1 192 e | /--- 193 n | /---- 194 e | /--- 195 r | /-----/--------- IDLE2 196 g | /-------/--------- 197 y | ------------ /---| 198 | / /---- | 199 | / /--- | 200 | / /---- | 201 | / /--- | 202 | --- | 203 | / | 204 | / | 205 |/ | time 206 ---/----------------------------+------------------------ 207 |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy 208 | 209 IDLE2-min-residency 210 211 Graph 2: idle states min-residency example 212 213 In graph 2 above, that takes into account idle states entry/exit energy 214 costs, it is clear that if the idle state residency time (i.e. time till next 215 wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state 216 choice energywise. 217 218 This is mainly down to the fact that IDLE1 entry/exit energy costs are lower 219 than IDLE2. 220 221 However, the lower power consumption (i.e. shallower energy curve slope) of 222 idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy 223 efficient. 224 225 The time at which IDLE2 becomes more energy efficient than IDLE1 (and other 226 shallower states in a system with multiple idle states) is defined 227 IDLE2-min-residency and corresponds to the time when energy consumption of 228 IDLE1 and IDLE2 states breaks even. 229 230 The definitions provided in this section underpin the idle states 231 properties specification that is the subject of the following sections. 232 233 =========================================== 234 5 - idle-states node 235 =========================================== 236 237 The processor idle states are defined within the idle-states node, which is 238 a direct child of the cpus node [1] and provides a container where the 239 processor idle states, defined as device tree nodes, are listed. 240 241 On ARM systems, it is a container of processor idle states nodes. If the 242 system does not provide CPU power management capabilities, or the processor 243 just supports idle_standby, an idle-states node is not required. 244 245 =========================================== 246 6 - References 247 =========================================== 248 249 [1] ARM Linux Kernel documentation - CPUs bindings 250 Documentation/devicetree/bindings/arm/cpus.yaml 251 252 [2] ARM Linux Kernel documentation - PSCI bindings 253 Documentation/devicetree/bindings/arm/psci.yaml 254 255 [3] ARM Server Base System Architecture (SBSA) 256 http://infocenter.arm.com/help/index.jsp 257 258 [4] ARM Architecture Reference Manuals 259 http://infocenter.arm.com/help/index.jsp 260 261 [5] ARM Linux Kernel documentation - Booting AArch64 Linux 262 Documentation/arm64/booting.rst 263 264 [6] RISC-V Linux Kernel documentation - CPUs bindings 265 Documentation/devicetree/bindings/riscv/cpus.yaml 266 267 [7] RISC-V Supervisor Binary Interface (SBI) 268 http://github.com/riscv/riscv-sbi-doc/riscv-sbi.adoc 269 270properties: 271 $nodename: 272 const: idle-states 273 274 entry-method: 275 description: | 276 Usage and definition depend on ARM architecture version. 277 278 On ARM v8 64-bit this property is required. 279 On ARM 32-bit systems this property is optional 280 281 This assumes that the "enable-method" property is set to "psci" in the cpu 282 node[5] that is responsible for setting up CPU idle management in the OS 283 implementation. 284 const: psci 285 286patternProperties: 287 "^(cpu|cluster)-": 288 type: object 289 description: | 290 Each state node represents an idle state description and must be defined 291 as follows. 292 293 The idle state entered by executing the wfi instruction (idle_standby 294 SBSA,[3][4]) is considered standard on all ARM and RISC-V platforms and 295 therefore must not be listed. 296 297 In addition to the properties listed above, a state node may require 298 additional properties specific to the entry-method defined in the 299 idle-states node. Please refer to the entry-method bindings 300 documentation for properties definitions. 301 302 properties: 303 compatible: 304 enum: 305 - arm,idle-state 306 - riscv,idle-state 307 308 arm,psci-suspend-param: 309 $ref: /schemas/types.yaml#/definitions/uint32 310 description: | 311 power_state parameter to pass to the ARM PSCI suspend call. 312 313 Device tree nodes that require usage of PSCI CPU_SUSPEND function 314 (i.e. idle states node with entry-method property is set to "psci") 315 must specify this property. 316 317 riscv,sbi-suspend-param: 318 $ref: /schemas/types.yaml#/definitions/uint32 319 description: | 320 suspend_type parameter to pass to the RISC-V SBI HSM suspend call. 321 322 This property is required in idle state nodes of device tree meant 323 for RISC-V systems. For more details on the suspend_type parameter 324 refer the SBI specifiation v0.3 (or higher) [7]. 325 326 local-timer-stop: 327 description: 328 If present the CPU local timer control logic is 329 lost on state entry, otherwise it is retained. 330 type: boolean 331 332 entry-latency-us: 333 description: 334 Worst case latency in microseconds required to enter the idle state. 335 336 exit-latency-us: 337 description: 338 Worst case latency in microseconds required to exit the idle state. 339 The exit-latency-us duration may be guaranteed only after 340 entry-latency-us has passed. 341 342 min-residency-us: 343 description: 344 Minimum residency duration in microseconds, inclusive of preparation 345 and entry, for this idle state to be considered worthwhile energy wise 346 (refer to section 2 of this document for a complete description). 347 348 wakeup-latency-us: 349 description: | 350 Maximum delay between the signaling of a wake-up event and the CPU 351 being able to execute normal code again. If omitted, this is assumed 352 to be equal to: 353 354 entry-latency-us + exit-latency-us 355 356 It is important to supply this value on systems where the duration of 357 PREP phase (see diagram 1, section 2) is non-neglibigle. In such 358 systems entry-latency-us + exit-latency-us will exceed 359 wakeup-latency-us by this duration. 360 361 idle-state-name: 362 $ref: /schemas/types.yaml#/definitions/string 363 description: 364 A string used as a descriptive name for the idle state. 365 366 additionalProperties: false 367 368 required: 369 - compatible 370 - entry-latency-us 371 - exit-latency-us 372 - min-residency-us 373 374additionalProperties: false 375 376examples: 377 - | 378 379 cpus { 380 #size-cells = <0>; 381 #address-cells = <2>; 382 383 cpu@0 { 384 device_type = "cpu"; 385 compatible = "arm,cortex-a57"; 386 reg = <0x0 0x0>; 387 enable-method = "psci"; 388 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 389 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 390 }; 391 392 cpu@1 { 393 device_type = "cpu"; 394 compatible = "arm,cortex-a57"; 395 reg = <0x0 0x1>; 396 enable-method = "psci"; 397 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 398 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 399 }; 400 401 cpu@100 { 402 device_type = "cpu"; 403 compatible = "arm,cortex-a57"; 404 reg = <0x0 0x100>; 405 enable-method = "psci"; 406 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 407 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 408 }; 409 410 cpu@101 { 411 device_type = "cpu"; 412 compatible = "arm,cortex-a57"; 413 reg = <0x0 0x101>; 414 enable-method = "psci"; 415 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 416 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 417 }; 418 419 cpu@10000 { 420 device_type = "cpu"; 421 compatible = "arm,cortex-a57"; 422 reg = <0x0 0x10000>; 423 enable-method = "psci"; 424 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 425 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 426 }; 427 428 cpu@10001 { 429 device_type = "cpu"; 430 compatible = "arm,cortex-a57"; 431 reg = <0x0 0x10001>; 432 enable-method = "psci"; 433 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 434 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 435 }; 436 437 cpu@10100 { 438 device_type = "cpu"; 439 compatible = "arm,cortex-a57"; 440 reg = <0x0 0x10100>; 441 enable-method = "psci"; 442 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 443 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 444 }; 445 446 cpu@10101 { 447 device_type = "cpu"; 448 compatible = "arm,cortex-a57"; 449 reg = <0x0 0x10101>; 450 enable-method = "psci"; 451 cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, 452 <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; 453 }; 454 455 cpu@100000000 { 456 device_type = "cpu"; 457 compatible = "arm,cortex-a53"; 458 reg = <0x1 0x0>; 459 enable-method = "psci"; 460 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 461 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 462 }; 463 464 cpu@100000001 { 465 device_type = "cpu"; 466 compatible = "arm,cortex-a53"; 467 reg = <0x1 0x1>; 468 enable-method = "psci"; 469 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 470 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 471 }; 472 473 cpu@100000100 { 474 device_type = "cpu"; 475 compatible = "arm,cortex-a53"; 476 reg = <0x1 0x100>; 477 enable-method = "psci"; 478 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 479 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 480 }; 481 482 cpu@100000101 { 483 device_type = "cpu"; 484 compatible = "arm,cortex-a53"; 485 reg = <0x1 0x101>; 486 enable-method = "psci"; 487 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 488 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 489 }; 490 491 cpu@100010000 { 492 device_type = "cpu"; 493 compatible = "arm,cortex-a53"; 494 reg = <0x1 0x10000>; 495 enable-method = "psci"; 496 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 497 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 498 }; 499 500 cpu@100010001 { 501 device_type = "cpu"; 502 compatible = "arm,cortex-a53"; 503 reg = <0x1 0x10001>; 504 enable-method = "psci"; 505 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 506 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 507 }; 508 509 cpu@100010100 { 510 device_type = "cpu"; 511 compatible = "arm,cortex-a53"; 512 reg = <0x1 0x10100>; 513 enable-method = "psci"; 514 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 515 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 516 }; 517 518 cpu@100010101 { 519 device_type = "cpu"; 520 compatible = "arm,cortex-a53"; 521 reg = <0x1 0x10101>; 522 enable-method = "psci"; 523 cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, 524 <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; 525 }; 526 527 idle-states { 528 entry-method = "psci"; 529 530 CPU_RETENTION_0_0: cpu-retention-0-0 { 531 compatible = "arm,idle-state"; 532 arm,psci-suspend-param = <0x0010000>; 533 entry-latency-us = <20>; 534 exit-latency-us = <40>; 535 min-residency-us = <80>; 536 }; 537 538 CLUSTER_RETENTION_0: cluster-retention-0 { 539 compatible = "arm,idle-state"; 540 local-timer-stop; 541 arm,psci-suspend-param = <0x1010000>; 542 entry-latency-us = <50>; 543 exit-latency-us = <100>; 544 min-residency-us = <250>; 545 wakeup-latency-us = <130>; 546 }; 547 548 CPU_SLEEP_0_0: cpu-sleep-0-0 { 549 compatible = "arm,idle-state"; 550 local-timer-stop; 551 arm,psci-suspend-param = <0x0010000>; 552 entry-latency-us = <250>; 553 exit-latency-us = <500>; 554 min-residency-us = <950>; 555 }; 556 557 CLUSTER_SLEEP_0: cluster-sleep-0 { 558 compatible = "arm,idle-state"; 559 local-timer-stop; 560 arm,psci-suspend-param = <0x1010000>; 561 entry-latency-us = <600>; 562 exit-latency-us = <1100>; 563 min-residency-us = <2700>; 564 wakeup-latency-us = <1500>; 565 }; 566 567 CPU_RETENTION_1_0: cpu-retention-1-0 { 568 compatible = "arm,idle-state"; 569 arm,psci-suspend-param = <0x0010000>; 570 entry-latency-us = <20>; 571 exit-latency-us = <40>; 572 min-residency-us = <90>; 573 }; 574 575 CLUSTER_RETENTION_1: cluster-retention-1 { 576 compatible = "arm,idle-state"; 577 local-timer-stop; 578 arm,psci-suspend-param = <0x1010000>; 579 entry-latency-us = <50>; 580 exit-latency-us = <100>; 581 min-residency-us = <270>; 582 wakeup-latency-us = <100>; 583 }; 584 585 CPU_SLEEP_1_0: cpu-sleep-1-0 { 586 compatible = "arm,idle-state"; 587 local-timer-stop; 588 arm,psci-suspend-param = <0x0010000>; 589 entry-latency-us = <70>; 590 exit-latency-us = <100>; 591 min-residency-us = <300>; 592 wakeup-latency-us = <150>; 593 }; 594 595 CLUSTER_SLEEP_1: cluster-sleep-1 { 596 compatible = "arm,idle-state"; 597 local-timer-stop; 598 arm,psci-suspend-param = <0x1010000>; 599 entry-latency-us = <500>; 600 exit-latency-us = <1200>; 601 min-residency-us = <3500>; 602 wakeup-latency-us = <1300>; 603 }; 604 }; 605 }; 606 607 - | 608 // Example 2 (ARM 32-bit, 8-cpu system, two clusters): 609 610 cpus { 611 #size-cells = <0>; 612 #address-cells = <1>; 613 614 cpu@0 { 615 device_type = "cpu"; 616 compatible = "arm,cortex-a15"; 617 reg = <0x0>; 618 cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; 619 }; 620 621 cpu@1 { 622 device_type = "cpu"; 623 compatible = "arm,cortex-a15"; 624 reg = <0x1>; 625 cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; 626 }; 627 628 cpu@2 { 629 device_type = "cpu"; 630 compatible = "arm,cortex-a15"; 631 reg = <0x2>; 632 cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; 633 }; 634 635 cpu@3 { 636 device_type = "cpu"; 637 compatible = "arm,cortex-a15"; 638 reg = <0x3>; 639 cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; 640 }; 641 642 cpu@100 { 643 device_type = "cpu"; 644 compatible = "arm,cortex-a7"; 645 reg = <0x100>; 646 cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; 647 }; 648 649 cpu@101 { 650 device_type = "cpu"; 651 compatible = "arm,cortex-a7"; 652 reg = <0x101>; 653 cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; 654 }; 655 656 cpu@102 { 657 device_type = "cpu"; 658 compatible = "arm,cortex-a7"; 659 reg = <0x102>; 660 cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; 661 }; 662 663 cpu@103 { 664 device_type = "cpu"; 665 compatible = "arm,cortex-a7"; 666 reg = <0x103>; 667 cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; 668 }; 669 670 idle-states { 671 cpu_sleep_0_0: cpu-sleep-0-0 { 672 compatible = "arm,idle-state"; 673 local-timer-stop; 674 entry-latency-us = <200>; 675 exit-latency-us = <100>; 676 min-residency-us = <400>; 677 wakeup-latency-us = <250>; 678 }; 679 680 cluster_sleep_0: cluster-sleep-0 { 681 compatible = "arm,idle-state"; 682 local-timer-stop; 683 entry-latency-us = <500>; 684 exit-latency-us = <1500>; 685 min-residency-us = <2500>; 686 wakeup-latency-us = <1700>; 687 }; 688 689 cpu_sleep_1_0: cpu-sleep-1-0 { 690 compatible = "arm,idle-state"; 691 local-timer-stop; 692 entry-latency-us = <300>; 693 exit-latency-us = <500>; 694 min-residency-us = <900>; 695 wakeup-latency-us = <600>; 696 }; 697 698 cluster_sleep_1: cluster-sleep-1 { 699 compatible = "arm,idle-state"; 700 local-timer-stop; 701 entry-latency-us = <800>; 702 exit-latency-us = <2000>; 703 min-residency-us = <6500>; 704 wakeup-latency-us = <2300>; 705 }; 706 }; 707 }; 708 709 - | 710 // Example 3 (RISC-V 64-bit, 4-cpu systems, two clusters): 711 712 cpus { 713 #size-cells = <0>; 714 #address-cells = <1>; 715 716 cpu@0 { 717 device_type = "cpu"; 718 compatible = "riscv"; 719 reg = <0x0>; 720 riscv,isa = "rv64imafdc"; 721 mmu-type = "riscv,sv48"; 722 cpu-idle-states = <&CPU_RET_0_0>, <&CPU_NONRET_0_0>, 723 <&CLUSTER_RET_0>, <&CLUSTER_NONRET_0>; 724 725 cpu_intc0: interrupt-controller { 726 #interrupt-cells = <1>; 727 compatible = "riscv,cpu-intc"; 728 interrupt-controller; 729 }; 730 }; 731 732 cpu@1 { 733 device_type = "cpu"; 734 compatible = "riscv"; 735 reg = <0x1>; 736 riscv,isa = "rv64imafdc"; 737 mmu-type = "riscv,sv48"; 738 cpu-idle-states = <&CPU_RET_0_0>, <&CPU_NONRET_0_0>, 739 <&CLUSTER_RET_0>, <&CLUSTER_NONRET_0>; 740 741 cpu_intc1: interrupt-controller { 742 #interrupt-cells = <1>; 743 compatible = "riscv,cpu-intc"; 744 interrupt-controller; 745 }; 746 }; 747 748 cpu@10 { 749 device_type = "cpu"; 750 compatible = "riscv"; 751 reg = <0x10>; 752 riscv,isa = "rv64imafdc"; 753 mmu-type = "riscv,sv48"; 754 cpu-idle-states = <&CPU_RET_1_0>, <&CPU_NONRET_1_0>, 755 <&CLUSTER_RET_1>, <&CLUSTER_NONRET_1>; 756 757 cpu_intc10: interrupt-controller { 758 #interrupt-cells = <1>; 759 compatible = "riscv,cpu-intc"; 760 interrupt-controller; 761 }; 762 }; 763 764 cpu@11 { 765 device_type = "cpu"; 766 compatible = "riscv"; 767 reg = <0x11>; 768 riscv,isa = "rv64imafdc"; 769 mmu-type = "riscv,sv48"; 770 cpu-idle-states = <&CPU_RET_1_0>, <&CPU_NONRET_1_0>, 771 <&CLUSTER_RET_1>, <&CLUSTER_NONRET_1>; 772 773 cpu_intc11: interrupt-controller { 774 #interrupt-cells = <1>; 775 compatible = "riscv,cpu-intc"; 776 interrupt-controller; 777 }; 778 }; 779 780 idle-states { 781 CPU_RET_0_0: cpu-retentive-0-0 { 782 compatible = "riscv,idle-state"; 783 riscv,sbi-suspend-param = <0x10000000>; 784 entry-latency-us = <20>; 785 exit-latency-us = <40>; 786 min-residency-us = <80>; 787 }; 788 789 CPU_NONRET_0_0: cpu-nonretentive-0-0 { 790 compatible = "riscv,idle-state"; 791 riscv,sbi-suspend-param = <0x90000000>; 792 entry-latency-us = <250>; 793 exit-latency-us = <500>; 794 min-residency-us = <950>; 795 }; 796 797 CLUSTER_RET_0: cluster-retentive-0 { 798 compatible = "riscv,idle-state"; 799 riscv,sbi-suspend-param = <0x11000000>; 800 local-timer-stop; 801 entry-latency-us = <50>; 802 exit-latency-us = <100>; 803 min-residency-us = <250>; 804 wakeup-latency-us = <130>; 805 }; 806 807 CLUSTER_NONRET_0: cluster-nonretentive-0 { 808 compatible = "riscv,idle-state"; 809 riscv,sbi-suspend-param = <0x91000000>; 810 local-timer-stop; 811 entry-latency-us = <600>; 812 exit-latency-us = <1100>; 813 min-residency-us = <2700>; 814 wakeup-latency-us = <1500>; 815 }; 816 817 CPU_RET_1_0: cpu-retentive-1-0 { 818 compatible = "riscv,idle-state"; 819 riscv,sbi-suspend-param = <0x10000010>; 820 entry-latency-us = <20>; 821 exit-latency-us = <40>; 822 min-residency-us = <80>; 823 }; 824 825 CPU_NONRET_1_0: cpu-nonretentive-1-0 { 826 compatible = "riscv,idle-state"; 827 riscv,sbi-suspend-param = <0x90000010>; 828 entry-latency-us = <250>; 829 exit-latency-us = <500>; 830 min-residency-us = <950>; 831 }; 832 833 CLUSTER_RET_1: cluster-retentive-1 { 834 compatible = "riscv,idle-state"; 835 riscv,sbi-suspend-param = <0x11000010>; 836 local-timer-stop; 837 entry-latency-us = <50>; 838 exit-latency-us = <100>; 839 min-residency-us = <250>; 840 wakeup-latency-us = <130>; 841 }; 842 843 CLUSTER_NONRET_1: cluster-nonretentive-1 { 844 compatible = "riscv,idle-state"; 845 riscv,sbi-suspend-param = <0x91000010>; 846 local-timer-stop; 847 entry-latency-us = <600>; 848 exit-latency-us = <1100>; 849 min-residency-us = <2700>; 850 wakeup-latency-us = <1500>; 851 }; 852 }; 853 }; 854 855... 856