Commit | Line | Data |
---|---|---|
3f8161b2 LP |
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 | ||
97735da0 LP |
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 | ||
c00bc5df LP |
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 | ||
3f8161b2 LP |
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 { | |
a13f18f5 | 500 | entry-method = "psci"; |
3f8161b2 LP |
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] ePAPR standard | |
699 | https://www.power.org/documentation/epapr-version-1-1/ |