[PATCH RFC 2/2] Documentation: arm: define DT C-states bindings

Kumar Gala galak at codeaurora.org
Mon Dec 2 13:08:16 EST 2013


On Dec 2, 2013, at 10:20 AM, Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:

> ARM based platforms implement a variety of power management schemes that
> allow processors to enter at run-time low-power states, aka C-states
> in ACPI jargon. The parameters defining these C-states vary on a per-platform
> basis forcing the OS to hardcode the state parameters in platform
> specific static tables whose size grows as the number of platforms supported
> in the kernel increases and hampers device drivers standardization.
> 
> Therefore, this patch aims at standardizing C-state device tree bindings for
> ARM platforms. Bindings define C-state parameters inclusive of entry methods
> and state latencies, to allow operating systems to retrieve the
> configuration entries from the device tree and initialize the related
> power management drivers, paving the way for common code in the kernel
> to deal with power states and removing the need for static data in current
> and previous kernel versions.

Where is this spec’d today in the kernel?

> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
> Documentation/devicetree/bindings/arm/c-states.txt | 830 +++++++++++++++++++++
> 1 file changed, 830 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/c-states.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/c-states.txt b/Documentation/devicetree/bindings/arm/c-states.txt
> new file mode 100644
> index 0000000..f568417
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/c-states.txt
> @@ -0,0 +1,830 @@
> +==========================================
> +ARM C-states binding description
> +==========================================
> +
> +==========================================
> +1 - Introduction
> +==========================================
> +
> +ARM systems contain HW capable of managing power consumption dynamically,
> +where cores can be put in different low-power states (ranging from simple
> +wfi to power gating) according to OSPM policies. Borrowing concepts
> +from the ACPI specification[1], the CPU states representing the range of
> +dynamic states that a processor can enter at run-time, aka C-state, can be
> +specified through device tree bindings representing the parameters required to
> +enter/exit specific C-states on a given processor.
> +
> +The state an ARM CPU can be put into is loosely identified by one of the
> +following operating modes:
> +
> +- Running:
> +	 # Processor core is executing instructions
> +
> +- Wait for Interrupt:
> +	# An ARM processor enters wait for interrupt (WFI) low power
> +	  state by executing a wfi instruction. When a processor enters
> +	  wfi state it disables most of the clocks while keeping the processor
> +	  powered up. This state is standard on all ARM processors and it is
> +	  defined as C1 in the remainder of this document.
> +
> +- Dormant:
> +	# Dormant mode is entered by executing wfi instructions and by sending
> +	  platform specific commands to the platform power controller (coupled
> +	  with processor specific SW/HW control sequences).
> +	  In dormant mode, most of the processor control and debug logic is
> +	  powered up but cache RAM can be put in retention state, providing
> +	  additional power savings.
> +
> +- Sleep:
> +	# Sleep mode is entered by executing the wfi instruction and by sending
> +	  platform specific commands to the platform power controller (coupled
> +	  with processor specific SW/HW control sequences). In sleep mode, a
> +	  processor and its caches are shutdown, the entire processor state is
> +	  lost.
> +
> +Building on top of the previous processor modes, ARM platforms implement power
> +management schemes that allow an OS PM implementation to put the processor in
> +different CPU states (C-states). C-states parameters (eg latency) are
> +platform specific and need to be characterized with bindings that provide the
> +required information to OSPM code so that it can build the required tables and
> +use them at runtime.
> +
> +The device tree binding definition for ARM C-states is the subject of this
> +document.
> +
> +===========================================
> +2 - cpu-power-states node
> +===========================================
> +
> +ARM processor C-states are defined within the cpu-power-states node, which is
> +a direct child of the cpus node and provides a container where the processor
> +states, defined as device tree nodes, are listed.
> +
> +- cpu-power-states node
> +
> +	Usage: Optional - On ARM systems, is a container of processor C-state
> +			  nodes. If the system does not provide CPU power
> +			  management capabilities or the processor just
> +			  supports WFI (C1 state) a cpu-power-states node is
> +			  not required.
> +
> +	Description: cpu-power-states node is a container node, where its
> +		     subnodes describe the CPU low-power C-states.
> +
> +	Node name must be "cpu-power-states".
> +
> +	The cpu-power-states node's parent node must be cpus node.
> +
> +	The cpu-power-states node's child nodes can be:
> +
> +	- one or more state nodes
> +
> +	The cpu-power-states node must contain the following properties:
> +
> +	- compatible
> +		Value type: <stringlist>
> +		Usage: Required
> +		Definition: Must be "arm,cpu-power-states".
> +
> +	- #address-cells
> +		Usage: Required
> +		Value type: <u32>
> +		Definition: must be set to 1.
> +
> +	- #size-cells
> +		Usage: Required
> +		Value type: <u32>
> +		Definition: must be set to 0.
> +
> +	Any other configuration is considered invalid.
> +
> +The nodes describing the C-states (state) can only be defined within the
> +cpu-power-states node.
> +
> +Any other configuration is consider invalid and therefore must be ignored.
> +
> +===========================================
> +2 - state node
> +===========================================
> +
> +A state node represents a C-state description and must be defined as follows:
> +
> +- state node
> +
> +	Description: must be child of the cpu-power-states node.
> +
> +	The state node name must be "state", with unit address provided by the
> +	"reg" property following standard DT requirements[4].
> +
> +	A state node defines the following properties:
> +
> +	- reg
> +		Usage: Required
> +		Value type: <u32>
> +		Definition: Standard device tree property [4] used for
> +			    enumeration purposes.

I’m not sure what purpose reg is really serving here.

> +
> +	- index
> +		Usage: Required
> +		Value type: <u32>
> +		Definition: It represents C-state index, starting from 2 (index
> +			    0 represents the processor state "running" and
> +			    index 1 represents processor mode "WFI"; indexes 0
> +			    and 1 are standard ARM states that need not be
> +			    described).

any reason not to call it c-state-index"

> +
> +	- entry-method
> +		Value type: <stringlist>
> +		Usage: Required
> +		Definition: Describes the method by which a CPU enters the
> +			    C-state. This property is required and must be one
> +			    of:
> +
> +			    - "psci"
> +			      ARM Standard firmware interface
> +
> +			    - "[vendor],[method]"
> +			      An implementation dependent string with
> +			      format "vendor,method", where vendor is a string
> +			      denoting the name of the manufacturer and
> +			      method is a string specifying the mechanism
> +			      used to enter the C-state.
> +
> +	- psci-power-state
> +		Usage: Required if entry-method property value is set to
> +		       "psci".
> +		Value type: <u32>
> +		Definition: power_state parameter to pass to the PSCI
> +			    suspend call to enter the C-state.
> +
> +	- latency
> +		Usage: Required
> +		Value type: <u32>
> +		Definition: Worst case latency in microseconds required to
> +			    enter and exit the C-state.
> +
> +	- min-residency
> +		Usage: Required
> +		Value type: <u32>
> +		Definition: Time in microseconds required for the CPU to be in
> +			    the C-state to make up for the dynamic power
> +			    consumed to enter/exit the C-state in order to
> +			    break even in terms of power consumption compared
> +			    to C1 state (wfi).
> +			    This parameter depends on the operating conditions
> +			    (operating point, cache state) and must assume
> +			    worst case scenario.
> +
> +	- cpus
> +		Usage: Optional
> +		Value type: <phandle>
> +		Definition: If defined, the phandle points to a node in the
> +			    cpu-map[2] representing all CPUs on which C-state
> +			    is valid. If not present or system is UP, the
> +			    C-state has to be considered valid for all CPUs in
> +			    the system.
> +
> +	- affinity
> +		Usage: Optional
> +		Value type: <phandle>
> +		Definition: If defined, phandle points to a node in the
> +			    cpu-map[2] that represents all CPUs that are
> +			    affected (ie share) by the C-state and have to
> +			    be coordinated on C-state entry/exit. If not
> +			    present or system is UP, the C-state is local to
> +			    a CPU and need no coordination (ie it is a CPU
> +			    state, that does not require coordination with
> +			    other CPUs). If present, the affinity property
> +			    must contain a phandle to a cpu-map node that
> +			    represents a subset, possibly inclusive of the
> +			    CPUs described through the cpus property.
> +
> +	- power-depth
> +		Usage: Required
> +		Value type: <u32>
> +		Definition: Integer value, starting from 2 (value 0 meaning
> +			    running and value 1 representing power depth of
> +			    wfi (C1)), that defines the level of depth of a
> +			    power state.
> +			    The system denotes power states with different
> +			    depths, an increasing value meaning less power
> +			    consumption and might involve powering down more
> +			    components.  Devices that are affected by
> +			    C-states entry must define the maximum power
> +			    depth supported in their respective device tree
> +			    bindings so that OSPM can take decision on how
> +			    to handle the device in question when the C-state
> +			    is entered. All devices (per-CPU or external) with
> +			    a power depth lower than the one defined in the
> +			    C-state entry stop operating when the C-state
> +			    is entered and action is required by OSPM to
> +			    guarantee their logic and memory content is saved
> +			    restored to guarantee proper functioning.

How is this different from the c-state index?

> +
> +	- cache-level-lost:
> +		Usage: Required if "entry-method" differs from "psci".
> +		Value type: <u32>
> +		Definition: An integer value representing the uppermost cache
> +			    level (inclusive) that is lost upon state entry.
> +			    This property requires the definition of cache
> +			    nodes as specified in [3]. Cache levels that are
> +			    shared between processors, according to [3], should
> +			    coordinate cache cleaning and invalidation to
> +			    maximize performance (ie a shared cache level
> +			    must be cleaned only if all CPUs sharing the
> +			    cache entered the state). If missing, cache
> +			    state has to be considered retained.
> +
> +	- processor-state-retained:
> +		Usage: See definition
> +		Value type: <none>
> +		Definition: if present CPU processor logic is retained on
> +			    power down, otherwise it is lost.
> +
> +
> +===========================================
> +3 - Examples
> +===========================================
> +
> +Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
> +
> +cpus {
> +	#size-cells = <0>;
> +	#address-cells = <2>;
> +
> +	cpu-map {
> +		CLUSTER0: cluster0 {
> +			CLUSTER2: cluster0 {
> +				core0 {
> +					thread0 {
> +						cpu = <&CPU0>;
> +					};
> +					thread1 {
> +						cpu = <&CPU1>;
> +					};
> +				};
> +
> +				core1 {
> +					thread0 {
> +						cpu = <&CPU2>;
> +					};
> +					thread1 {
> +						cpu = <&CPU3>;
> +					};
> +				};
> +			};
> +
> +			CLUSTER3: cluster1 {
> +				core0 {
> +					thread0 {
> +						cpu = <&CPU4>;
> +					};
> +					thread1 {
> +						cpu = <&CPU5>;
> +					};
> +				};
> +
> +				core1 {
> +					thread0 {
> +						cpu = <&CPU6>;
> +					};
> +					thread1 {
> +						cpu = <&CPU7>;
> +					};
> +				};
> +			};
> +		};
> +
> +		CLUSTER1: cluster1 {
> +			CLUSTER4: cluster0 {
> +				core0 {
> +					thread0 {
> +						cpu = <&CPU8>;
> +					};
> +					thread1 {
> +						cpu = <&CPU9>;
> +					};
> +				};
> +				core1 {
> +					thread0 {
> +						cpu = <&CPU10>;
> +					};
> +					thread1 {
> +						cpu = <&CPU11>;
> +					};
> +				};
> +			};
> +
> +			CLUSTER5: cluster1 {
> +				core0 {
> +					thread0 {
> +						cpu = <&CPU12>;
> +					};
> +					thread1 {
> +						cpu = <&CPU13>;
> +					};
> +				};
> +				core1 {
> +					thread0 {
> +						cpu = <&CPU14>;
> +					};
> +					thread1 {
> +						cpu = <&CPU15>;
> +					};
> +				};
> +			};
> +		};
> +	};
> +
> +	cpu-power-states {
> +		compatible = "arm,cpu-power-states";
> +		#size-cells = <0>;
> +		#address-cells = <1>;
> +
> +		state at 0 {
> +			reg = <0>;
> +			index = <2>;
> +			entry-method = "psci";
> +			psci-power-state = <0x1010000>;
> +			latency = <400>;
> +			min-residency = <300>;
> +			power-depth = <2>;
> +			cache-level-lost = <1>;
> +			cpus = <&CLUSTER0>;
> +		};
> +
> +		state at 1 {
> +			reg = <1>;
> +			index = <2>;
> +			entry-method = "psci";
> +			psci-power-state = <0x1010000>;
> +			latency = <400>;
> +			min-residency = <500>;
> +			power-depth = <2>;
> +			cache-level-lost = <1>;
> +			cpus = <&CLUSTER1>;
> +		};
> +
> +		state at 2 {
> +			reg = <2>;
> +			index = <3>;
> +			entry-method = "psci";
> +			psci-power-state = <0x3010000>;
> +			latency = <1000>;
> +			power-depth = <4>;
> +			cache-level-lost = <2>;
> +			cpus = <&CLUSTER0>;
> +			affinity = <&CLUSTER0>;
> +		};
> +
> +		state at 3 {
> +			reg = <3>;
> +			index = <3>;
> +			entry-method = "psci";
> +			latency = <4500>;
> +			min-residency = <6500>;
> +			psci-power-state = <0x3010000>;
> +			power-depth = <4>;
> +			cache-level-lost = <2>;
> +			cpus = <&CLUSTER1>;
> +			affinity = <&CLUSTER1>;
> +		};
> +	};
> +
> +	CPU0: cpu at 0 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x0>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_0>;
> +		L1_0: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +		L2_0: l2-cache {
> +			compatible = "cache";
> +			cache-level = <2>;
> +		};
> +	};
> +
> +	CPU1: cpu at 1 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x1>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_1>;
> +		L1_1: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU2: cpu at 100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x100>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_2>;
> +		L1_2: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU3: cpu at 101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x101>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_3>;
> +		L1_3: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU4: cpu at 10000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10000>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_4>;
> +		L1_4: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU5: cpu at 10001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10001>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_5>;
> +		L1_5: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU6: cpu at 10100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10100>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_6>;
> +		L1_6: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU7: cpu at 10101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a57";
> +		reg = <0x0 0x10101>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_7>;
> +		L1_7: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU8: cpu at 100000000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x0>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_8>;
> +		L1_8: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +		L2_1: l2-cache {
> +			compatible = "cache";
> +			cache-level = <2>;
> +		};
> +	};
> +
> +	CPU9: cpu at 100000001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x1>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_9>;
> +		L1_9: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU10: cpu at 100000100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x100>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_10>;
> +		L1_10: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU11: cpu at 100000101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x101>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_11>;
> +		L1_11: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU12: cpu at 100010000 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x10000>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_12>;
> +		L1_12: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU13: cpu at 100010001 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x10001>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_13>;
> +		L1_13: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU14: cpu at 100010100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x10100>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_14>;
> +		L1_14: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU15: cpu at 100010101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a53";
> +		reg = <0x1 0x10101>;
> +		enable-method = "psci";
> +		next-cache-level = <&L1_15>;
> +		L1_15: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +};
> +
> +Example 2 (ARM 32-bit, 8-cpu system, two clusters):
> +
> +cpus {
> +	#size-cells = <0>;
> +	#address-cells = <1>;
> +
> +	cpu-map {
> +		CLUSTER0: cluster0 {
> +			core0 {
> +				thread0 {
> +					cpu = <&CPU0>;
> +				};
> +				thread1 {
> +					cpu = <&CPU1>;
> +				};
> +			};
> +
> +			core1 {
> +				thread0 {
> +					cpu = <&CPU2>;
> +				};
> +				thread1 {
> +					cpu = <&CPU3>;
> +				};
> +			};
> +		};
> +
> +		CLUSTER1: cluster1 {
> +			core0 {
> +				thread0 {
> +					cpu = <&CPU4>;
> +				};
> +				thread1 {
> +					cpu = <&CPU5>;
> +				};
> +			};
> +
> +			core1 {
> +				thread0 {
> +					cpu = <&CPU6>;
> +				};
> +				thread1 {
> +					cpu = <&CPU7>;
> +				};
> +			};
> +		};
> +	};
> +
> +	cpu-power-states {
> +		compatible = "arm,cpu-power-states";
> +		#size-cells = <0>;
> +		#address-cells = <1>;
> +
> +		state at 0 {
> +			reg = <0>;
> +			index = <2>;
> +			entry-method = "psci";
> +			psci-power-state = <0x1010000>;
> +			latency = <400>;
> +			min-residency = <300>;
> +			power-depth = <2>;
> +			cpus = <&CLUSTER0>;
> +		};
> +
> +		state at 1 {
> +			reg = <1>;
> +			index = <2>;
> +			entry-method = "psci";
> +			psci-power-state = <0x1010000>;
> +			latency = <400>;
> +			min-residency = <500>;
> +			power-depth = <2>;
> +			cpus = <&CLUSTER1>;
> +		};
> +
> +		state at 2 {
> +			reg = <2>;
> +			index = <3>;
> +			entry-method = "psci";
> +			psci-power-state = <0x2010000>;
> +			latency = <3000>;
> +			min-residency = <3000>;
> +			cache-level-lost = <2>;
> +			power-depth = <3>;
> +			cpus = <&CLUSTER0>;
> +			affinity = <&CLUSTER0>;
> +		};
> +
> +		state at 3 {
> +			reg = <3>;
> +			index = <3>;
> +			entry-method = "psci";
> +			psci-power-state = <0x2010000>;
> +			latency = <4000>;
> +			min-residency = <5000>;
> +			cache-level-lost = <2>;
> +			power-depth = <3>;
> +			cpus = <&CLUSTER1>;
> +			affinity = <&CLUSTER1>;
> +		};
> +	};
> +
> +	CPU0: cpu at 0 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a15";
> +		reg = <0x0>;
> +		next-cache-level = <&L1_0>;
> +		L1_0: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +		};
> +		L2_0: l2-cache {
> +			compatible = "cache";
> +			cache-level = <2>;
> +		};
> +	};
> +
> +	CPU1: cpu at 1 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a15";
> +		reg = <0x1>;
> +		next-cache-level = <&L1_1>;
> +		L1_1: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU2: cpu at 2 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a15";
> +		reg = <0x2>;
> +		next-cache-level = <&L1_2>;
> +		L1_2: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU3: cpu at 3 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a15";
> +		reg = <0x3>;
> +		next-cache-level = <&L1_3>;
> +		L1_3: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_0>;
> +		};
> +	};
> +
> +	CPU4: cpu at 100 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a7";
> +		reg = <0x100>;
> +		next-cache-level = <&L1_4>;
> +		L1_4: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +		};
> +		L2_1: l2-cache {
> +			compatible = "cache";
> +			cache-level = <2>;
> +		};
> +	};
> +
> +	CPU5: cpu at 101 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a7";
> +		reg = <0x101>;
> +		next-cache-level = <&L1_5>;
> +		L1_5: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU6: cpu at 102 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a7";
> +		reg = <0x102>;
> +		next-cache-level = <&L1_6>;
> +		L1_6: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +
> +	CPU7: cpu at 103 {
> +		device_type = "cpu";
> +		compatible = "arm,cortex-a7";
> +		reg = <0x103>;
> +		next-cache-level = <&L1_7>;
> +		L1_7: l1-cache {
> +			compatible = "cache";
> +			cache-level = <1>;
> +			next-cache-level = <&L2_1>;
> +		};
> +	};
> +};
> +
> +===========================================
> +4 - References
> +===========================================
> +
> +[1] ACPI v5.0 specification
> +    http://www.acpi.info/spec50.htm
> +
> +[2] ARM Linux kernel documentation - topology bindings
> +    Documentation/devicetree/bindings/arm/topology.txt
> +
> +[3] ARM Linux kernel documentation - cache bindings
> +    Documentation/devicetree/bindings/arm/cache.txt
> +
> +[4] ePAPR standard
> +    https://www.power.org/documentation/epapr-version-1-1/
> -- 
> 1.8.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation




More information about the linux-arm-kernel mailing list