Commit 10d0c970 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'devicetree-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 

Pull devicetree updates from Rob Herring:
 "DeviceTree updates for 3.13.  This is a bit larger pull request than
  usual for this cycle with lots of clean-up.

   - Cross arch clean-up and consolidation of early DT scanning code.
   - Clean-up and removal of arch prom.h headers.  Makes arch specific
     prom.h optional on all but Sparc.
   - Addition of interrupts-extended property for devices connected to
     multiple interrupt controllers.
   - Refactoring of DT interrupt parsing code in preparation for
     deferred probe of interrupts.
   - ARM cpu and cpu topology bindings documentation.
   - Various DT vendor binding documentation updates"

* tag 'devicetree-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (82 commits)
  powerpc: add missing explicit OF includes for ppc
  dt/irq: add empty of_irq_count for !OF_IRQ
  dt: disable self-tests for !OF_IRQ
  of: irq: Fix interrupt-map entry matching
  MIPS: Netlogic: replace early_init_devtree() call
  of: Add Panasonic Corporation vendor prefix
  of: Add Chunghwa Picture Tubes Ltd. vendor prefix
  of: Add AU Optronics Corporation vendor prefix
  of/irq: Fix potential buffer overflow
  of/irq: Fix bug in interrupt parsing refactor.
  of: set dma_mask to point to coherent_dma_mask
  of: add vendor prefix for PHYTEC Messtechnik GmbH
  DT: sort vendor-prefixes.txt
  of: Add vendor prefix for Cadence
  of: Add empty for_each_available_child_of_node() macro definition
  arm/versatile: Fix versatile irq specifications.
  of/irq: create interrupts-extended property
  microblaze/pci: Drop PowerPC-ism from irq parsing
  of/irq: Create of_irq_parse_and_map_pci() to consolidate arch code.
  of/irq: Use irq_of_parse_and_map()
  ...
parents 85b656cf c11eede6

Documentation/devicetree/bindings/arm/cpus.txt

+354 −47
Original line number Diff line number Diff line 
* ARM CPUs binding description

=================

ARM CPUs bindings

=================



The device tree allows to describe the layout of CPUs in a system through

the "cpus" node, which in turn contains a number of subnodes (ie "cpu")

defining properties for every cpu.



Bindings for CPU nodes follow the ePAPR standard, available from:

Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:



http://devicetree.org

https://www.power.org/documentation/epapr-version-1-1/



For the ARM architecture every CPU node must contain the following properties:

with updates for 32-bit and 64-bit ARM systems provided in this document.



- device_type:	must be "cpu"

- reg:		property matching the CPU MPIDR[23:0] register bits

		reg[31:24] bits must be set to 0

- compatible:	should be one of:

		"arm,arm1020"

		"arm,arm1020e"

		"arm,arm1022"

		"arm,arm1026"

		"arm,arm720"

		"arm,arm740"

================================

Convention used in this document

================================



This document follows the conventions described in the ePAPR v1.1, with

the addition:



- square brackets define bitfields, eg reg[7:0] value of the bitfield in

  the reg property contained in bits 7 down to 0



=====================================

cpus and cpu node bindings definition

=====================================



The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu

nodes to be present and contain the properties described below.



- cpus node



	Description: Container of cpu nodes



	The node name must be "cpus".



	A cpus node must define the following properties:



	- #address-cells

		Usage: required

		Value type: <u32>



		Definition depends on ARM architecture version and

		configuration:



			# On uniprocessor ARM architectures previous to v7

			  value must be 1, to enable a simple enumeration

			  scheme for processors that do not have a HW CPU

			  identification register.

			# On 32-bit ARM 11 MPcore, ARM v7 or later systems

			  value must be 1, that corresponds to CPUID/MPIDR

			  registers sizes.

			# On ARM v8 64-bit systems value should be set to 2,

			  that corresponds to the MPIDR_EL1 register size.

			  If MPIDR_EL1[63:32] value is equal to 0 on all CPUs

			  in the system, #address-cells can be set to 1, since

			  MPIDR_EL1[63:32] bits are not used for CPUs

			  identification.

	- #size-cells

		Usage: required

		Value type: <u32>

		Definition: must be set to 0



- cpu node



	Description: Describes a CPU in an ARM based system



	PROPERTIES



	- device_type

		Usage: required

		Value type: <string>

		Definition: must be "cpu"

	- reg

		Usage and definition depend on ARM architecture version and

		configuration:



			# On uniprocessor ARM architectures previous to v7

			  this property is required and must be set to 0.



			# On ARM 11 MPcore based systems this property is

			  required and matches the CPUID[11:0] register bits.



			  Bits [11:0] in the reg cell must be set to

			  bits [11:0] in CPU ID register.



			  All other bits in the reg cell must be set to 0.



			# On 32-bit ARM v7 or later systems this property is

			  required and matches the CPU MPIDR[23:0] register

			  bits.



			  Bits [23:0] in the reg cell must be set to

			  bits [23:0] in MPIDR.



			  All other bits in the reg cell must be set to 0.



			# On ARM v8 64-bit systems this property is required

			  and matches the MPIDR_EL1 register affinity bits.



			  * If cpus node's #address-cells property is set to 2



			    The first reg cell bits [7:0] must be set to

			    bits [39:32] of MPIDR_EL1.



			    The second reg cell bits [23:0] must be set to

			    bits [23:0] of MPIDR_EL1.



			  * If cpus node's #address-cells property is set to 1



			    The reg cell bits [23:0] must be set to bits [23:0]

			    of MPIDR_EL1.



			  All other bits in the reg cells must be set to 0.



	- compatible:

		Usage: required

		Value type: <string>

		Definition: should be one of:

			    "arm,arm710t"

			    "arm,arm720t"

			    "arm,arm740t"

			    "arm,arm7ej-s"

			    "arm,arm7tdmi"

		"arm,arm920"

		"arm,arm922"

			    "arm,arm7tdmi-s"

			    "arm,arm9es"

			    "arm,arm9ej-s"

			    "arm,arm920t"

			    "arm,arm922t"

			    "arm,arm925"

		"arm,arm926"

		"arm,arm940"

		"arm,arm946"

			    "arm,arm926e-s"

			    "arm,arm926ej-s"

			    "arm,arm940t"

			    "arm,arm946e-s"

			    "arm,arm966e-s"

			    "arm,arm968e-s"

			    "arm,arm9tdmi"

			    "arm,arm1020e"

			    "arm,arm1020t"

			    "arm,arm1022e"

			    "arm,arm1026ej-s"

			    "arm,arm1136j-s"

			    "arm,arm1136jf-s"

			    "arm,arm1156t2-s"

			    "arm,arm1156t2f-s"

			    "arm,arm1176jzf"

			    "arm,arm1176jz-s"

			    "arm,arm1176jzf-s"

			    "arm,arm11mpcore"

			    "arm,cortex-a5"

			    "arm,cortex-a7"

			    "arm,cortex-a8"

			    "arm,cortex-a9"

			    "arm,cortex-a15"

		"arm,arm1136"

		"arm,arm1156"

		"arm,arm1176"

		"arm,arm11mpcore"

			    "arm,cortex-a53"

			    "arm,cortex-a57"

			    "arm,cortex-m0"

			    "arm,cortex-m0+"

			    "arm,cortex-m1"

			    "arm,cortex-m3"

			    "arm,cortex-m4"

			    "arm,cortex-r4"

			    "arm,cortex-r5"

			    "arm,cortex-r7"

			    "faraday,fa526"

			    "intel,sa110"

			    "intel,sa1100"

			    "marvell,feroceon"

			    "marvell,mohawk"

		"marvell,xsc3"

		"marvell,xscale"

			    "marvell,pj4a"

			    "marvell,pj4b"

			    "marvell,sheeva-v5"

			    "qcom,krait"

			    "qcom,scorpion"

	- enable-method

		Value type: <stringlist>

		Usage and definition depend on ARM architecture version.

			# On ARM v8 64-bit this property is required and must

			  be one of:

			     "spin-table"

			     "psci"

			# On ARM 32-bit systems this property is optional.



Example:

	- cpu-release-addr

		Usage: required for systems that have an "enable-method"

		       property value of "spin-table".

		Value type: <prop-encoded-array>

		Definition:

			# On ARM v8 64-bit systems must be a two cell

			  property identifying a 64-bit zero-initialised

			  memory location.



Example 1 (dual-cluster big.LITTLE system 32-bit):



	cpus {

		#size-cells = <0>;

		#address-cells = <1>;



		CPU0: cpu@0 {

		cpu@0 {

			device_type = "cpu";

			compatible = "arm,cortex-a15";

			reg = <0x0>;

		};



		CPU1: cpu@1 {

		cpu@1 {

			device_type = "cpu";

			compatible = "arm,cortex-a15";

			reg = <0x1>;

		};



		CPU2: cpu@100 {

		cpu@100 {

			device_type = "cpu";

			compatible = "arm,cortex-a7";

			reg = <0x100>;

		};



		CPU3: cpu@101 {

		cpu@101 {

			device_type = "cpu";

			compatible = "arm,cortex-a7";

			reg = <0x101>;

		};

	};



Example 2 (Cortex-A8 uniprocessor 32-bit system):



	cpus {

		#size-cells = <0>;

		#address-cells = <1>;



		cpu@0 {

			device_type = "cpu";

			compatible = "arm,cortex-a8";

			reg = <0x0>;

		};

	};



Example 3 (ARM 926EJ-S uniprocessor 32-bit system):



	cpus {

		#size-cells = <0>;

		#address-cells = <1>;



		cpu@0 {

			device_type = "cpu";

			compatible = "arm,arm926ej-s";

			reg = <0x0>;

		};

	};



Example 4 (ARM Cortex-A57 64-bit system):



cpus {

	#size-cells = <0>;

	#address-cells = <2>;



	cpu@0 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x0>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@1 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x1>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@10000 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10000>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@10001 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10001>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@10100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@10101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100000000 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x0>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100000001 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x1>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100000100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100000101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100010000 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10000>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100010001 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10001>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100010100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	cpu@100010101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};

};

Documentation/devicetree/bindings/arm/topology.txt

0 → 100644
+474 −0
Original line number Diff line number Diff line 
===========================================

ARM topology binding description

===========================================



===========================================

1 - Introduction

===========================================



In an ARM system, the hierarchy of CPUs is defined through three entities that

are used to describe the layout of physical CPUs in the system:



- cluster

- core

- thread



The cpu nodes (bindings defined in [1]) represent the devices that

correspond to physical CPUs and are to be mapped to the hierarchy levels.



The bottom hierarchy level sits at core or thread level depending on whether

symmetric multi-threading (SMT) is supported or not.



For instance in a system where CPUs support SMT, "cpu" nodes represent all

threads existing in the system and map to the hierarchy level "thread" above.

In systems where SMT is not supported "cpu" nodes represent all cores present

in the system and map to the hierarchy level "core" above.



ARM topology bindings allow one to associate cpu nodes with hierarchical groups

corresponding to the system hierarchy; syntactically they are defined as device

tree nodes.



The remainder of this document provides the topology bindings for ARM, based

on the ePAPR standard, available from:



http://www.power.org/documentation/epapr-version-1-1/



If not stated otherwise, whenever a reference to a cpu node phandle is made its

value must point to a cpu node compliant with the cpu node bindings as

documented in [1].

A topology description containing phandles to cpu nodes that are not compliant

with bindings standardized in [1] is therefore considered invalid.



===========================================

2 - cpu-map node

===========================================



The ARM CPU topology is defined within the cpu-map node, which is a direct

child of the cpus node and provides a container where the actual topology

nodes are listed.



- cpu-map node



	Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.

			  ARM uniprocessor systems do not require a topology

			  description and therefore should not define a

			  cpu-map node.



	Description: The cpu-map node is just a container node where its

		     subnodes describe the CPU topology.



	Node name must be "cpu-map".



	The cpu-map node's parent node must be the cpus node.



	The cpu-map node's child nodes can be:



	- one or more cluster nodes



	Any other configuration is considered invalid.



The cpu-map node can only contain three types of child nodes:



- cluster node

- core node

- thread node



whose bindings are described in paragraph 3.



The nodes describing the CPU topology (cluster/core/thread) can only be

defined within the cpu-map node.

Any other configuration is consider invalid and therefore must be ignored.



===========================================

2.1 - cpu-map child nodes naming convention

===========================================



cpu-map child nodes must follow a naming convention where the node name

must be "clusterN", "coreN", "threadN" depending on the node type (ie

cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which

are siblings within a single common parent node must be given a unique and

sequential N value, starting from 0).

cpu-map child nodes which do not share a common parent node can have the same

name (ie same number N as other cpu-map child nodes at different device tree

levels) since name uniqueness will be guaranteed by the device tree hierarchy.



===========================================

3 - cluster/core/thread node bindings

===========================================



Bindings for cluster/cpu/thread nodes are defined as follows:



- cluster node



	 Description: must be declared within a cpu-map node, one node

		      per cluster. A system can contain several layers of

		      clustering and cluster nodes can be contained in parent

		      cluster nodes.



	The cluster node name must be "clusterN" as described in 2.1 above.

	A cluster node can not be a leaf node.



	A cluster node's child nodes must be:



	- one or more cluster nodes; or

	- one or more core nodes



	Any other configuration is considered invalid.



- core node



	Description: must be declared in a cluster node, one node per core in

		     the cluster. If the system does not support SMT, core

		     nodes are leaf nodes, otherwise they become containers of

		     thread nodes.



	The core node name must be "coreN" as described in 2.1 above.



	A core node must be a leaf node if SMT is not supported.



	Properties for core nodes that are leaf nodes:



	- cpu

		Usage: required

		Value type: <phandle>

		Definition: a phandle to the cpu node that corresponds to the

			    core node.



	If a core node is not a leaf node (CPUs supporting SMT) a core node's

	child nodes can be:



	- one or more thread nodes



	Any other configuration is considered invalid.



- thread node



	Description: must be declared in a core node, one node per thread

		     in the core if the system supports SMT. Thread nodes are

		     always leaf nodes in the device tree.



	The thread node name must be "threadN" as described in 2.1 above.



	A thread node must be a leaf node.



	A thread node must contain the following property:



	- cpu

		Usage: required

		Value type: <phandle>

		Definition: a phandle to the cpu node that corresponds to

			    the thread node.



===========================================

4 - Example dts

===========================================



Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):



cpus {

	#size-cells = <0>;

	#address-cells = <2>;



	cpu-map {

		cluster0 {

			cluster0 {

				core0 {

					thread0 {

						cpu = <&CPU0>;

					};

					thread1 {

						cpu = <&CPU1>;

					};

				};



				core1 {

					thread0 {

						cpu = <&CPU2>;

					};

					thread1 {

						cpu = <&CPU3>;

					};

				};

			};



			cluster1 {

				core0 {

					thread0 {

						cpu = <&CPU4>;

					};

					thread1 {

						cpu = <&CPU5>;

					};

				};



				core1 {

					thread0 {

						cpu = <&CPU6>;

					};

					thread1 {

						cpu = <&CPU7>;

					};

				};

			};

		};



		cluster1 {

			cluster0 {

				core0 {

					thread0 {

						cpu = <&CPU8>;

					};

					thread1 {

						cpu = <&CPU9>;

					};

				};

				core1 {

					thread0 {

						cpu = <&CPU10>;

					};

					thread1 {

						cpu = <&CPU11>;

					};

				};

			};



			cluster1 {

				core0 {

					thread0 {

						cpu = <&CPU12>;

					};

					thread1 {

						cpu = <&CPU13>;

					};

				};

				core1 {

					thread0 {

						cpu = <&CPU14>;

					};

					thread1 {

						cpu = <&CPU15>;

					};

				};

			};

		};

	};



	CPU0: cpu@0 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x0>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU1: cpu@1 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x1>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU2: cpu@100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU3: cpu@101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU4: cpu@10000 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10000>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU5: cpu@10001 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10001>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU6: cpu@10100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU7: cpu@10101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x0 0x10101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU8: cpu@100000000 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x0>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU9: cpu@100000001 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x1>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU10: cpu@100000100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU11: cpu@100000101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU12: cpu@100010000 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10000>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU13: cpu@100010001 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10001>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU14: cpu@100010100 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10100>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};



	CPU15: cpu@100010101 {

		device_type = "cpu";

		compatible = "arm,cortex-a57";

		reg = <0x1 0x10101>;

		enable-method = "spin-table";

		cpu-release-addr = <0 0x20000000>;

	};

};



Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):



cpus {

	#size-cells = <0>;

	#address-cells = <1>;



	cpu-map {

		cluster0 {

			core0 {

				cpu = <&CPU0>;

			};

			core1 {

				cpu = <&CPU1>;

			};

			core2 {

				cpu = <&CPU2>;

			};

			core3 {

				cpu = <&CPU3>;

			};

		};



		cluster1 {

			core0 {

				cpu = <&CPU4>;

			};

			core1 {

				cpu = <&CPU5>;

			};

			core2 {

				cpu = <&CPU6>;

			};

			core3 {

				cpu = <&CPU7>;

			};

		};

	};



	CPU0: cpu@0 {

		device_type = "cpu";

		compatible = "arm,cortex-a15";

		reg = <0x0>;

	};



	CPU1: cpu@1 {

		device_type = "cpu";

		compatible = "arm,cortex-a15";

		reg = <0x1>;

	};



	CPU2: cpu@2 {

		device_type = "cpu";

		compatible = "arm,cortex-a15";

		reg = <0x2>;

	};



	CPU3: cpu@3 {

		device_type = "cpu";

		compatible = "arm,cortex-a15";

		reg = <0x3>;

	};



	CPU4: cpu@100 {

		device_type = "cpu";

		compatible = "arm,cortex-a7";

		reg = <0x100>;

	};



	CPU5: cpu@101 {

		device_type = "cpu";

		compatible = "arm,cortex-a7";

		reg = <0x101>;

	};



	CPU6: cpu@102 {

		device_type = "cpu";

		compatible = "arm,cortex-a7";

		reg = <0x102>;

	};



	CPU7: cpu@103 {

		device_type = "cpu";

		compatible = "arm,cortex-a7";

		reg = <0x103>;

	};

};



===============================================================================

[1] ARM Linux kernel documentation

    Documentation/devicetree/bindings/arm/cpus.txt

Documentation/devicetree/bindings/interrupt-controller/interrupts.txt

+23 −6
Original line number Diff line number Diff line
@@ -4,16 +4,33 @@ Specifying interrupt information for devices 
1) Interrupt client nodes

-------------------------



Nodes that describe devices which generate interrupts must contain an

"interrupts" property. This property must contain a list of interrupt

specifiers, one per output interrupt. The format of the interrupt specifier is

determined by the interrupt controller to which the interrupts are routed; see

section 2 below for details.

Nodes that describe devices which generate interrupts must contain an either an

"interrupts" property or an "interrupts-extended" property. These properties

contain a list of interrupt specifiers, one per output interrupt. The format of

the interrupt specifier is determined by the interrupt controller to which the

interrupts are routed; see section 2 below for details.



  Example:

	interrupt-parent = <&intc1>;

	interrupts = <5 0>, <6 0>;



The "interrupt-parent" property is used to specify the controller to which

interrupts are routed and contains a single phandle referring to the interrupt

controller node. This property is inherited, so it may be specified in an

interrupt client node or in any of its parent nodes.

interrupt client node or in any of its parent nodes. Interrupts listed in the

"interrupts" property are always in reference to the node's interrupt parent.



The "interrupts-extended" property is a special form for use when a node needs

to reference multiple interrupt parents. Each entry in this property contains

both the parent phandle and the interrupt specifier. "interrupts-extended"

should only be used when a device has multiple interrupt parents.



  Example:

	interrupts-extended = <&intc1 5 1>, <&intc2 1 0>;



A device node may contain either "interrupts" or "interrupts-extended", but not

both. If both properties are present, then the operating system should log an

error and use only the data in "interrupts".



2) Interrupt controller nodes

-----------------------------

Documentation/devicetree/bindings/vendor-prefixes.txt

+7 −2
Original line number Diff line number Diff line
@@ -12,12 +12,15 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) 
apm	Applied Micro Circuits Corporation (APM)

arm	ARM Ltd.

atmel	Atmel Corporation

auo	AU Optronics Corporation

avago	Avago Technologies

bosch	Bosch Sensortec GmbH

brcm	Broadcom Corporation

capella	Capella Microsystems, Inc

cavium	Cavium, Inc.

cdns	Cadence Design Systems Inc.

chrp	Common Hardware Reference Platform

chunghwa	Chunghwa Picture Tubes Ltd.

cirrus	Cirrus Logic, Inc.

cortina	Cortina Systems, Inc.

dallas	Maxim Integrated Products (formerly Dallas Semiconductor)
@@ -46,6 +49,8 @@ nintendo Nintendo 
nvidia	NVIDIA

nxp	NXP Semiconductors

onnn	ON Semiconductor Corp.

panasonic	Panasonic Corporation

phytec	PHYTEC Messtechnik GmbH

picochip	Picochip Ltd

powervr	PowerVR (deprecated, use img)

qca	Qualcomm Atheros, Inc.
@@ -65,12 +70,12 @@ snps Synopsys, Inc. 
st	STMicroelectronics

ste	ST-Ericsson

stericsson	ST-Ericsson

toumaz	Toumaz

ti	Texas Instruments

toshiba	Toshiba Corporation

toumaz	Toumaz

v3	V3 Semiconductor

via	VIA Technologies, Inc.

winbond Winbond Electronics corp.

wlf	Wolfson Microelectronics

wm	Wondermedia Technologies, Inc.

winbond Winbond Electronics corp.

xlnx	Xilinx

arch/arc/include/asm/mach_desc.h

+3 −14
Original line number Diff line number Diff line
@@ -51,22 +51,12 @@ struct machine_desc { 
/*

 * Current machine - only accessible during boot.

 */

extern struct machine_desc *machine_desc;

extern const struct machine_desc *machine_desc;



/*

 * Machine type table - also only accessible during boot

 */

extern struct machine_desc __arch_info_begin[], __arch_info_end[];

#define for_each_machine_desc(p)			\

	for (p = __arch_info_begin; p < __arch_info_end; p++)



static inline struct machine_desc *default_machine_desc(void)

{

	/* the default machine is the last one linked in */

	if (__arch_info_end - 1 < __arch_info_begin)

		return NULL;

	return __arch_info_end - 1;

}

extern const struct machine_desc __arch_info_begin[], __arch_info_end[];



/*

 * Set of macros to define architecture features.
@@ -81,7 +71,6 @@ __attribute__((__section__(".arch.info.init"))) = { \ 
#define MACHINE_END				\

};



extern struct machine_desc *setup_machine_fdt(void *dt);

extern void __init copy_devtree(void);

extern const struct machine_desc *setup_machine_fdt(void *dt);



#endif

CRA Git | Maintained and supported by SUSTech CRA and CCSE