Based on kernel version 4.16.1. Page generated on 2018-04-09 11:52 EST.
1 ========================================== 2 ARM idle states binding description 3 ========================================== 4 5 ========================================== 6 1 - Introduction 7 ========================================== 8 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. 15 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: 18 19 - Running 20 - Idle_standby 21 - Idle_retention 22 - Sleep 23 - Off 24 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). 30 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. 34 35 The device tree binding definition for ARM idle states is the subject of this 36 document. 37 38 =========================================== 39 2 - idle-states definitions 40 =========================================== 41 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. 45 46 The following diagram depicts the CPU execution phases and related timing 47 properties required to enter and exit an idle state: 48 49 ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__.. 50 | | | | | 51 52 |<------ entry ------->| 53 | latency | 54 |<- exit ->| 55 | latency | 56 |<-------- min-residency -------->| 57 |<------- wakeup-latency ------->| 58 59 Diagram 1: CPU idle state execution phases 60 61 EXEC: Normal CPU execution. 62 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. 69 70 ENTRY: The hardware is committed to idle mode. This period must run 71 to completion up to IDLE before anything else can happen. 72 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. 75 76 EXIT: Period during which the CPU is brought back to operational 77 mode (EXEC). 78 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. 81 82 min-residency: Minimum period, including preparation and entry, for a given 83 idle state to be worthwhile energywise. 84 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. 88 89 These timing parameters can be used by an OS in different circumstances. 90 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. 94 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 97 of an idle state, eg: 98 99 wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) 100 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 107 state). 108 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 113 functioning. 114 115 The min-residency time parameter deserves further explanation since it is 116 expressed in time units but must factor in energy consumption coefficients. 117 118 The energy consumption of a cpu when it enters a power state can be roughly 119 characterised by the following graph: 120 121 | 122 | 123 | 124 e | 125 n | /--- 126 e | /------ 127 r | /------ 128 g | /----- 129 y | /------ 130 | ---- 131 | /| 132 | / | 133 | / | 134 | / | 135 | / | 136 | / | 137 |/ | 138 -----|-------+---------------------------------- 139 0| 1 time(ms) 140 141 Graph 1: Energy vs time example 142 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 whilst entering and leaving the idle 146 state. 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 149 state. 150 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. 156 157 For sake of simplicity, let's consider a system with two idle states IDLE1, 158 and IDLE2: 159 160 | 161 | 162 | 163 | /-- IDLE1 164 e | /--- 165 n | /---- 166 e | /--- 167 r | /-----/--------- IDLE2 168 g | /-------/--------- 169 y | ------------ /---| 170 | / /---- | 171 | / /--- | 172 | / /---- | 173 | / /--- | 174 | --- | 175 | / | 176 | / | 177 |/ | time 178 ---/----------------------------+------------------------ 179 |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy 180 | 181 IDLE2-min-residency 182 183 Graph 2: idle states min-residency example 184 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 188 choice energywise. 189 190 This is mainly down to the fact that IDLE1 entry/exit energy costs are lower 191 than IDLE2. 192 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 195 efficient. 196 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. 201 202 The definitions provided in this section underpin the idle states 203 properties specification that is the subject of the following sections. 204 205 =========================================== 206 3 - idle-states node 207 =========================================== 208 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. 212 213 - idle-states node 214 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 219 required. 220 221 Description: idle-states node is a container node, where its 222 subnodes describe the CPU idle states. 223 224 Node name must be "idle-states". 225 226 The idle-states node's parent node must be the cpus node. 227 228 The idle-states node's child nodes can be: 229 230 - one or more state nodes 231 232 Any other configuration is considered invalid. 233 234 An idle-states node defines the following properties: 235 236 - entry-method 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 240 be one of: 241 - "psci" (see bindings in [2]) 242 # On ARM 32-bit systems this property is optional 243 244 The nodes describing the idle states (state) can only be defined within the 245 idle-states node, any other configuration is considered invalid and therefore 246 must be ignored. 247 248 =========================================== 249 4 - state node 250 =========================================== 251 252 A state node represents an idle state description and must be defined as 253 follows: 254 255 - state node 256 257 Description: must be child of the idle-states node 258 259 The state node name shall follow standard device tree naming 260 rules ([5], 2.2.1 "Node names"), in particular state nodes which 261 are siblings within a single common parent must be given a unique name. 262 263 The idle state entered by executing the wfi instruction (idle_standby 264 SBSA,[3][4]) is considered standard on all ARM platforms and therefore 265 must not be listed. 266 267 With the definitions provided above, the following list represents 268 the valid properties for a state node: 269 270 - compatible 271 Usage: Required 272 Value type: <stringlist> 273 Definition: Must be "arm,idle-state". 274 275 - local-timer-stop 276 Usage: See definition 277 Value type: <none> 278 Definition: if present the CPU local timer control logic is 279 lost on state entry, otherwise it is retained. 280 281 - entry-latency-us 282 Usage: Required 283 Value type: <prop-encoded-array> 284 Definition: u32 value representing worst case latency in 285 microseconds required to enter the idle state. 286 The exit-latency-us duration may be guaranteed 287 only after entry-latency-us has passed. 288 289 - exit-latency-us 290 Usage: Required 291 Value type: <prop-encoded-array> 292 Definition: u32 value representing worst case latency 293 in microseconds required to exit the idle state. 294 295 - min-residency-us 296 Usage: Required 297 Value type: <prop-encoded-array> 298 Definition: u32 value representing minimum residency duration 299 in microseconds, inclusive of preparation and 300 entry, for this idle state to be considered 301 worthwhile energy wise (refer to section 2 of 302 this document for a complete description). 303 304 - wakeup-latency-us: 305 Usage: Optional 306 Value type: <prop-encoded-array> 307 Definition: u32 value representing maximum delay between the 308 signaling of a wake-up event and the CPU being 309 able to execute normal code again. If omitted, 310 this is assumed to be equal to: 311 312 entry-latency-us + exit-latency-us 313 314 It is important to supply this value on systems 315 where the duration of PREP phase (see diagram 1, 316 section 2) is non-neglibigle. 317 In such systems entry-latency-us + exit-latency-us 318 will exceed wakeup-latency-us by this duration. 319 320 - status: 321 Usage: Optional 322 Value type: <string> 323 Definition: A standard device tree property [5] that indicates 324 the operational status of an idle-state. 325 If present, it shall be: 326 "okay": to indicate that the idle state is 327 operational. 328 "disabled": to indicate that the idle state has 329 been disabled in firmware so it is not 330 operational. 331 If the property is not present the idle-state must 332 be considered operational. 333 334 - idle-state-name: 335 Usage: Optional 336 Value type: <string> 337 Definition: A string used as a descriptive name for the idle 338 state. 339 340 In addition to the properties listed above, a state node may require 341 additional properties specifics to the entry-method defined in the 342 idle-states node, please refer to the entry-method bindings 343 documentation for properties definitions. 344 345 =========================================== 346 4 - Examples 347 =========================================== 348 349 Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method): 350 351 cpus { 352 #size-cells = <0>; 353 #address-cells = <2>; 354 355 CPU0: cpu@0 { 356 device_type = "cpu"; 357 compatible = "arm,cortex-a57"; 358 reg = <0x0 0x0>; 359 enable-method = "psci"; 360 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 361 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 362 }; 363 364 CPU1: cpu@1 { 365 device_type = "cpu"; 366 compatible = "arm,cortex-a57"; 367 reg = <0x0 0x1>; 368 enable-method = "psci"; 369 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 370 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 371 }; 372 373 CPU2: cpu@100 { 374 device_type = "cpu"; 375 compatible = "arm,cortex-a57"; 376 reg = <0x0 0x100>; 377 enable-method = "psci"; 378 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 379 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 380 }; 381 382 CPU3: cpu@101 { 383 device_type = "cpu"; 384 compatible = "arm,cortex-a57"; 385 reg = <0x0 0x101>; 386 enable-method = "psci"; 387 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 388 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 389 }; 390 391 CPU4: cpu@10000 { 392 device_type = "cpu"; 393 compatible = "arm,cortex-a57"; 394 reg = <0x0 0x10000>; 395 enable-method = "psci"; 396 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 397 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 398 }; 399 400 CPU5: cpu@10001 { 401 device_type = "cpu"; 402 compatible = "arm,cortex-a57"; 403 reg = <0x0 0x10001>; 404 enable-method = "psci"; 405 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 406 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 407 }; 408 409 CPU6: cpu@10100 { 410 device_type = "cpu"; 411 compatible = "arm,cortex-a57"; 412 reg = <0x0 0x10100>; 413 enable-method = "psci"; 414 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 415 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 416 }; 417 418 CPU7: cpu@10101 { 419 device_type = "cpu"; 420 compatible = "arm,cortex-a57"; 421 reg = <0x0 0x10101>; 422 enable-method = "psci"; 423 cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 424 &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; 425 }; 426 427 CPU8: cpu@100000000 { 428 device_type = "cpu"; 429 compatible = "arm,cortex-a53"; 430 reg = <0x1 0x0>; 431 enable-method = "psci"; 432 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 433 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 434 }; 435 436 CPU9: cpu@100000001 { 437 device_type = "cpu"; 438 compatible = "arm,cortex-a53"; 439 reg = <0x1 0x1>; 440 enable-method = "psci"; 441 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 442 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 443 }; 444 445 CPU10: cpu@100000100 { 446 device_type = "cpu"; 447 compatible = "arm,cortex-a53"; 448 reg = <0x1 0x100>; 449 enable-method = "psci"; 450 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 451 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 452 }; 453 454 CPU11: cpu@100000101 { 455 device_type = "cpu"; 456 compatible = "arm,cortex-a53"; 457 reg = <0x1 0x101>; 458 enable-method = "psci"; 459 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 460 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 461 }; 462 463 CPU12: cpu@100010000 { 464 device_type = "cpu"; 465 compatible = "arm,cortex-a53"; 466 reg = <0x1 0x10000>; 467 enable-method = "psci"; 468 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 469 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 470 }; 471 472 CPU13: cpu@100010001 { 473 device_type = "cpu"; 474 compatible = "arm,cortex-a53"; 475 reg = <0x1 0x10001>; 476 enable-method = "psci"; 477 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 478 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 479 }; 480 481 CPU14: cpu@100010100 { 482 device_type = "cpu"; 483 compatible = "arm,cortex-a53"; 484 reg = <0x1 0x10100>; 485 enable-method = "psci"; 486 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 487 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 488 }; 489 490 CPU15: cpu@100010101 { 491 device_type = "cpu"; 492 compatible = "arm,cortex-a53"; 493 reg = <0x1 0x10101>; 494 enable-method = "psci"; 495 cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 496 &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; 497 }; 498 499 idle-states { 500 entry-method = "psci"; 501 502 CPU_RETENTION_0_0: cpu-retention-0-0 { 503 compatible = "arm,idle-state"; 504 arm,psci-suspend-param = <0x0010000>; 505 entry-latency-us = <20>; 506 exit-latency-us = <40>; 507 min-residency-us = <80>; 508 }; 509 510 CLUSTER_RETENTION_0: cluster-retention-0 { 511 compatible = "arm,idle-state"; 512 local-timer-stop; 513 arm,psci-suspend-param = <0x1010000>; 514 entry-latency-us = <50>; 515 exit-latency-us = <100>; 516 min-residency-us = <250>; 517 wakeup-latency-us = <130>; 518 }; 519 520 CPU_SLEEP_0_0: cpu-sleep-0-0 { 521 compatible = "arm,idle-state"; 522 local-timer-stop; 523 arm,psci-suspend-param = <0x0010000>; 524 entry-latency-us = <250>; 525 exit-latency-us = <500>; 526 min-residency-us = <950>; 527 }; 528 529 CLUSTER_SLEEP_0: cluster-sleep-0 { 530 compatible = "arm,idle-state"; 531 local-timer-stop; 532 arm,psci-suspend-param = <0x1010000>; 533 entry-latency-us = <600>; 534 exit-latency-us = <1100>; 535 min-residency-us = <2700>; 536 wakeup-latency-us = <1500>; 537 }; 538 539 CPU_RETENTION_1_0: cpu-retention-1-0 { 540 compatible = "arm,idle-state"; 541 arm,psci-suspend-param = <0x0010000>; 542 entry-latency-us = <20>; 543 exit-latency-us = <40>; 544 min-residency-us = <90>; 545 }; 546 547 CLUSTER_RETENTION_1: cluster-retention-1 { 548 compatible = "arm,idle-state"; 549 local-timer-stop; 550 arm,psci-suspend-param = <0x1010000>; 551 entry-latency-us = <50>; 552 exit-latency-us = <100>; 553 min-residency-us = <270>; 554 wakeup-latency-us = <100>; 555 }; 556 557 CPU_SLEEP_1_0: cpu-sleep-1-0 { 558 compatible = "arm,idle-state"; 559 local-timer-stop; 560 arm,psci-suspend-param = <0x0010000>; 561 entry-latency-us = <70>; 562 exit-latency-us = <100>; 563 min-residency-us = <300>; 564 wakeup-latency-us = <150>; 565 }; 566 567 CLUSTER_SLEEP_1: cluster-sleep-1 { 568 compatible = "arm,idle-state"; 569 local-timer-stop; 570 arm,psci-suspend-param = <0x1010000>; 571 entry-latency-us = <500>; 572 exit-latency-us = <1200>; 573 min-residency-us = <3500>; 574 wakeup-latency-us = <1300>; 575 }; 576 }; 577 578 }; 579 580 Example 2 (ARM 32-bit, 8-cpu system, two clusters): 581 582 cpus { 583 #size-cells = <0>; 584 #address-cells = <1>; 585 586 CPU0: cpu@0 { 587 device_type = "cpu"; 588 compatible = "arm,cortex-a15"; 589 reg = <0x0>; 590 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; 591 }; 592 593 CPU1: cpu@1 { 594 device_type = "cpu"; 595 compatible = "arm,cortex-a15"; 596 reg = <0x1>; 597 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; 598 }; 599 600 CPU2: cpu@2 { 601 device_type = "cpu"; 602 compatible = "arm,cortex-a15"; 603 reg = <0x2>; 604 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; 605 }; 606 607 CPU3: cpu@3 { 608 device_type = "cpu"; 609 compatible = "arm,cortex-a15"; 610 reg = <0x3>; 611 cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; 612 }; 613 614 CPU4: cpu@100 { 615 device_type = "cpu"; 616 compatible = "arm,cortex-a7"; 617 reg = <0x100>; 618 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; 619 }; 620 621 CPU5: cpu@101 { 622 device_type = "cpu"; 623 compatible = "arm,cortex-a7"; 624 reg = <0x101>; 625 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; 626 }; 627 628 CPU6: cpu@102 { 629 device_type = "cpu"; 630 compatible = "arm,cortex-a7"; 631 reg = <0x102>; 632 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; 633 }; 634 635 CPU7: cpu@103 { 636 device_type = "cpu"; 637 compatible = "arm,cortex-a7"; 638 reg = <0x103>; 639 cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; 640 }; 641 642 idle-states { 643 CPU_SLEEP_0_0: cpu-sleep-0-0 { 644 compatible = "arm,idle-state"; 645 local-timer-stop; 646 entry-latency-us = <200>; 647 exit-latency-us = <100>; 648 min-residency-us = <400>; 649 wakeup-latency-us = <250>; 650 }; 651 652 CLUSTER_SLEEP_0: cluster-sleep-0 { 653 compatible = "arm,idle-state"; 654 local-timer-stop; 655 entry-latency-us = <500>; 656 exit-latency-us = <1500>; 657 min-residency-us = <2500>; 658 wakeup-latency-us = <1700>; 659 }; 660 661 CPU_SLEEP_1_0: cpu-sleep-1-0 { 662 compatible = "arm,idle-state"; 663 local-timer-stop; 664 entry-latency-us = <300>; 665 exit-latency-us = <500>; 666 min-residency-us = <900>; 667 wakeup-latency-us = <600>; 668 }; 669 670 CLUSTER_SLEEP_1: cluster-sleep-1 { 671 compatible = "arm,idle-state"; 672 local-timer-stop; 673 entry-latency-us = <800>; 674 exit-latency-us = <2000>; 675 min-residency-us = <6500>; 676 wakeup-latency-us = <2300>; 677 }; 678 }; 679 680 }; 681 682 =========================================== 683 5 - References 684 =========================================== 685 686 [1] ARM Linux Kernel documentation - CPUs bindings 687 Documentation/devicetree/bindings/arm/cpus.txt 688 689 [2] ARM Linux Kernel documentation - PSCI bindings 690 Documentation/devicetree/bindings/arm/psci.txt 691 692 [3] ARM Server Base System Architecture (SBSA) 693 http://infocenter.arm.com/help/index.jsp 694 695 [4] ARM Architecture Reference Manuals 696 http://infocenter.arm.com/help/index.jsp 697 698 [5] Devicetree Specification 699 https://www.devicetree.org/specifications/