About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / devicetree / bindings / arm / idle-states.txt


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/
Hide Line Numbers


About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog