]> git.kernelconcepts.de Git - karo-tx-linux.git/blob - Documentation/devicetree/bindings/arm/idle-states.txt
Merge remote-tracking branch 'omap_dss2/for-next'
[karo-tx-linux.git] / Documentation / devicetree / bindings / arm / idle-states.txt
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] ePAPR standard
699     https://www.power.org/documentation/epapr-version-1-1/