[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

DT bindings for numa mapping of memory, cores and IOs.

Reviewed-by: Robert Richter <rrichter@cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
---
 Documentation/devicetree/bindings/arm/numa.txt | 273 +++++++++++++++++++++++++
 1 file changed, 273 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/numa.txt

diff --git a/Documentation/devicetree/bindings/arm/numa.txt b/Documentation/devicetree/bindings/arm/numa.txt
new file mode 100644
index 0000000..5bd893e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/numa.txt
@@ -0,0 +1,273 @@
+==============================================================================
+NUMA binding description.
+==============================================================================
+
+==============================================================================
+1 - Introduction
+==============================================================================
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==============================================================================
+2 - numa-node-id
+==============================================================================
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+	/* numa node 0 */
+	numa-node-id = <0>;
+
+	/* numa node 1 */
+	numa-node-id = <1>;
+
+==============================================================================
+3 - distance-map
+==============================================================================
+
+The device tree node distance-map describes the relative
+distance(memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+  This property defines a matrix to describe the relative distances
+  between all numa nodes.
+  It is represented as a list of node pairs and their relative distance.
+
+  Note:
+	1. Each entry represents distance from first node to second node.
+	The distance are equal in either direction.
+	2. The distance from a node to self(local distance) is represented
+	with value 10 and all inter node distance should be represented with
+	value greater than 10.
+	3. distance-matrix shold have entries in lexicographical ascending
+	order of nodes.
+	4. There must be only one Device node distance-map and must reside in the root node.
+
+Example:
+	4 nodes connected in mesh/ring topology as below,
+
+		0_______20______1
+		|               |
+		|               |
+		20             20
+		|               |
+		|               |
+		|_______________|
+		3       20      2
+
+	if relative distance for each hop is 20,
+	then inter node distance would be,
+	      0 -> 1 = 20
+	      1 -> 2 = 20
+	      2 -> 3 = 20
+	      3 -> 0 = 20
+	      0 -> 2 = 40
+	      1 -> 3 = 40
+
+     and dt presentation for this distance matrix is,
+
+		distance-map {
+			 compatible = "numa-distance-map-v1";
+			 distance-matrix = <0 0  10>,
+					   <0 1  20>,
+					   <0 2  40>,
+					   <0 3  20>,
+					   <1 0  20>,
+					   <1 1  10>,
+					   <1 2  20>,
+					   <1 3  40>,
+					   <2 0  40>,
+					   <2 1  20>,
+					   <2 2  10>,
+					   <2 3  20>,
+					   <3 0  20>,
+					   <3 1  40>,
+					   <3 2  20>,
+					   <3 3  10>;
+		};
+
+
+==============================================================================
+4 - Example dts
+==============================================================================
+
+2 sockets system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+	memory@00c00000 {
+		device_type = "memory";
+		reg = <0x0 0x00c00000 0x0 0x80000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+	};
+
+	memory@10000000000 {
+		device_type = "memory";
+		reg = <0x100 0x00000000 0x0 0x80000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu@000 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x000>;
+			enable-method = "psci";
+			/* node 0 */
+			numa-node-id = <0>;
+		};
+		cpu@001 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x001>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@002 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x002>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@003 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x003>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@004 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x004>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@005 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x005>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@006 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x006>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@007 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x007>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@008 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x008>;
+			enable-method = "psci";
+			/* node 1 */
+			numa-node-id = <1>;
+		};
+		cpu@009 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x009>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00a {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00a>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00b {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00b>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00c {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00c>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00d {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00d>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00e {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00e>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00f {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00f>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+	};
+
+	pcie0: pcie0@0x8480,00000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+        };
+
+	pcie1: pcie1@0x9480,00000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x9480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x9010 0x00000000 0x9010 0x00000000 0x70 0x00000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+        };
+
+	distance-map {
+		compatible = "numa-distance-map-v1";
+		distance-matrix = <0 0 10>,
+				  <0 1 20>,
+				  <1 1 10>;
+	};
-- 
1.8.1.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

DT bindings for numa mapping of memory, cores and IOs.

Reviewed-by: Robert Richter <rrichter@cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
---
 Documentation/devicetree/bindings/arm/numa.txt | 273 +++++++++++++++++++++++++
 1 file changed, 273 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/numa.txt

diff --git a/Documentation/devicetree/bindings/arm/numa.txt b/Documentation/devicetree/bindings/arm/numa.txt
new file mode 100644
index 0000000..5bd893e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/numa.txt
@@ -0,0 +1,273 @@
+==============================================================================
+NUMA binding description.
+==============================================================================
+
+==============================================================================
+1 - Introduction
+==============================================================================
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==============================================================================
+2 - numa-node-id
+==============================================================================
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+	/* numa node 0 */
+	numa-node-id = <0>;
+
+	/* numa node 1 */
+	numa-node-id = <1>;
+
+==============================================================================
+3 - distance-map
+==============================================================================
+
+The device tree node distance-map describes the relative
+distance(memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+  This property defines a matrix to describe the relative distances
+  between all numa nodes.
+  It is represented as a list of node pairs and their relative distance.
+
+  Note:
+	1. Each entry represents distance from first node to second node.
+	The distance are equal in either direction.
+	2. The distance from a node to self(local distance) is represented
+	with value 10 and all inter node distance should be represented with
+	value greater than 10.
+	3. distance-matrix shold have entries in lexicographical ascending
+	order of nodes.
+	4. There must be only one Device node distance-map and must reside in the root node.
+
+Example:
+	4 nodes connected in mesh/ring topology as below,
+
+		0_______20______1
+		|               |
+		|               |
+		20             20
+		|               |
+		|               |
+		|_______________|
+		3       20      2
+
+	if relative distance for each hop is 20,
+	then inter node distance would be,
+	      0 -> 1 = 20
+	      1 -> 2 = 20
+	      2 -> 3 = 20
+	      3 -> 0 = 20
+	      0 -> 2 = 40
+	      1 -> 3 = 40
+
+     and dt presentation for this distance matrix is,
+
+		distance-map {
+			 compatible = "numa-distance-map-v1";
+			 distance-matrix = <0 0  10>,
+					   <0 1  20>,
+					   <0 2  40>,
+					   <0 3  20>,
+					   <1 0  20>,
+					   <1 1  10>,
+					   <1 2  20>,
+					   <1 3  40>,
+					   <2 0  40>,
+					   <2 1  20>,
+					   <2 2  10>,
+					   <2 3  20>,
+					   <3 0  20>,
+					   <3 1  40>,
+					   <3 2  20>,
+					   <3 3  10>;
+		};
+
+
+==============================================================================
+4 - Example dts
+==============================================================================
+
+2 sockets system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+	memory at 00c00000 {
+		device_type = "memory";
+		reg = <0x0 0x00c00000 0x0 0x80000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+	};
+
+	memory at 10000000000 {
+		device_type = "memory";
+		reg = <0x100 0x00000000 0x0 0x80000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x000>;
+			enable-method = "psci";
+			/* node 0 */
+			numa-node-id = <0>;
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x001>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 002 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x002>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 003 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x003>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 004 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x004>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 005 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x005>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 006 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x006>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 007 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x007>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 008 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x008>;
+			enable-method = "psci";
+			/* node 1 */
+			numa-node-id = <1>;
+		};
+		cpu at 009 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x009>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 00a {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00a>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 00b {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00b>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 00c {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00c>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 00d {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00d>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 00e {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00e>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 00f {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00f>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+	};
+
+	pcie0: pcie0 at 0x8480,00000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+        };
+
+	pcie1: pcie1 at 0x9480,00000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x9480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x9010 0x00000000 0x9010 0x00000000 0x70 0x00000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+        };
+
+	distance-map {
+		compatible = "numa-distance-map-v1";
+		distance-matrix = <0 0 10>,
+				  <0 1 20>,
+				  <1 1 10>;
+	};
-- 
1.8.1.4

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Mark Rutland]

Hi,

> +==============================================================================
> +2 - numa-node-id
> +==============================================================================
> +
> +For the purpose of identification, each NUMA node is associated with a unique
> +token known as a node id. For the purpose of this binding
> +a node id is a 32-bit integer.
> +
> +A device node is associated with a NUMA node by the presence of a
> +numa-node-id property which contains the node id of the device.
> +
> +Example:
> +	/* numa node 0 */
> +	numa-node-id = <0>;
> +
> +	/* numa node 1 */
> +	numa-node-id = <1>;
> +
> +==============================================================================
> +3 - distance-map
> +==============================================================================
> +
> +The device tree node distance-map describes the relative
> +distance(memory latency) between all numa nodes.
> +
> +- compatible : Should at least contain "numa-distance-map-v1".

Thank you for updating these per my request.

The fact that these have changed since the late posting [1] means that
this is a new version of the patch rather than a resend. Please update
the PATCHvX number when changes are made.

You also need to update the driver for the new compatible string, so a
new version of that is required.

> +- distance-matrix
> +  This property defines a matrix to describe the relative distances
> +  between all numa nodes.
> +  It is represented as a list of node pairs and their relative distance.
> +
> +  Note:
> +	1. Each entry represents distance from first node to second node.
> +	The distance are equal in either direction.
> +	2. The distance from a node to self(local distance) is represented
> +	with value 10 and all inter node distance should be represented with
> +	value greater than 10.
> +	3. distance-matrix shold have entries in lexicographical ascending
> +	order of nodes.
> +	4. There must be only one Device node distance-map and must reside in the root node.

I am still concerned that the local distance of 10 is completely
arbitrary.

Please:

* Add a new local-distance property to the distance-map node allowing a
  uniform local distance to be described, and require this property to
  be present.

* Update the driver to account for that and the compatible string
  change.

* Send a complete PATCHv8 (or PATCHv$X where X > 7) series with a proper
  changelog.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/385826.html

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Mark Rutland]

Hi,

> +==============================================================================
> +2 - numa-node-id
> +==============================================================================
> +
> +For the purpose of identification, each NUMA node is associated with a unique
> +token known as a node id. For the purpose of this binding
> +a node id is a 32-bit integer.
> +
> +A device node is associated with a NUMA node by the presence of a
> +numa-node-id property which contains the node id of the device.
> +
> +Example:
> +	/* numa node 0 */
> +	numa-node-id = <0>;
> +
> +	/* numa node 1 */
> +	numa-node-id = <1>;
> +
> +==============================================================================
> +3 - distance-map
> +==============================================================================
> +
> +The device tree node distance-map describes the relative
> +distance(memory latency) between all numa nodes.
> +
> +- compatible : Should at least contain "numa-distance-map-v1".

Thank you for updating these per my request.

The fact that these have changed since the late posting [1] means that
this is a new version of the patch rather than a resend. Please update
the PATCHvX number when changes are made.

You also need to update the driver for the new compatible string, so a
new version of that is required.

> +- distance-matrix
> +  This property defines a matrix to describe the relative distances
> +  between all numa nodes.
> +  It is represented as a list of node pairs and their relative distance.
> +
> +  Note:
> +	1. Each entry represents distance from first node to second node.
> +	The distance are equal in either direction.
> +	2. The distance from a node to self(local distance) is represented
> +	with value 10 and all inter node distance should be represented with
> +	value greater than 10.
> +	3. distance-matrix shold have entries in lexicographical ascending
> +	order of nodes.
> +	4. There must be only one Device node distance-map and must reside in the root node.

I am still concerned that the local distance of 10 is completely
arbitrary.

Please:

* Add a new local-distance property to the distance-map node allowing a
  uniform local distance to be described, and require this property to
  be present.

* Update the driver to account for that and the compatible string
  change.

* Send a complete PATCHv8 (or PATCHv$X where X > 7) series with a proper
  changelog.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/385826.html

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

Hi Mark,


On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi,
>
>> +==============================================================================
>> +2 - numa-node-id
>> +==============================================================================
>> +
>> +For the purpose of identification, each NUMA node is associated with a unique
>> +token known as a node id. For the purpose of this binding
>> +a node id is a 32-bit integer.
>> +
>> +A device node is associated with a NUMA node by the presence of a
>> +numa-node-id property which contains the node id of the device.
>> +
>> +Example:
>> +     /* numa node 0 */
>> +     numa-node-id = <0>;
>> +
>> +     /* numa node 1 */
>> +     numa-node-id = <1>;
>> +
>> +==============================================================================
>> +3 - distance-map
>> +==============================================================================
>> +
>> +The device tree node distance-map describes the relative
>> +distance(memory latency) between all numa nodes.
>> +
>> +- compatible : Should at least contain "numa-distance-map-v1".
>
> Thank you for updating these per my request.
>
> The fact that these have changed since the late posting [1] means that
> this is a new version of the patch rather than a resend. Please update
> the PATCHvX number when changes are made.
>
> You also need to update the driver for the new compatible string, so a
> new version of that is required.
>
>> +- distance-matrix
>> +  This property defines a matrix to describe the relative distances
>> +  between all numa nodes.
>> +  It is represented as a list of node pairs and their relative distance.
>> +
>> +  Note:
>> +     1. Each entry represents distance from first node to second node.
>> +     The distance are equal in either direction.
>> +     2. The distance from a node to self(local distance) is represented
>> +     with value 10 and all inter node distance should be represented with
>> +     value greater than 10.
>> +     3. distance-matrix shold have entries in lexicographical ascending
>> +     order of nodes.
>> +     4. There must be only one Device node distance-map and must reside in the root node.
>
> I am still concerned that the local distance of 10 is completely
> arbitrary.
IMHO, i do not see any issue in having defined local distance to
arbitrary number(10).
inter node numa distance is relative number with respect to local distance
we have to fix local distance to some value, having it in dt to make
generic will not add
any additional value as compared to having the fixed local distance to 10.

 #define LOCAL_DISTANCE          10
this macro which is defined in common code and used in many places in
common code as well in other arch specific codes.
If we add property to define local distance and it imply that local
distance can be changed to any value other than 10.
having this change demands common code changes wherever LOCAL_DISTANCE is used!.
I am not finding any reasoning to make local distance generic.

please correct me, if i misunderstood your suggestion
>
> Please:
>
> * Add a new local-distance property to the distance-map node allowing a
>   uniform local distance to be described, and require this property to
>   be present.
>
> * Update the driver to account for that and the compatible string
>   change.
>
> * Send a complete PATCHv8 (or PATCHv$X where X > 7) series with a proper
>   changelog.
>
> Thanks,
> Mark.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/385826.html

thanks
Ganapat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

Hi Mark,


On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
>> +==============================================================================
>> +2 - numa-node-id
>> +==============================================================================
>> +
>> +For the purpose of identification, each NUMA node is associated with a unique
>> +token known as a node id. For the purpose of this binding
>> +a node id is a 32-bit integer.
>> +
>> +A device node is associated with a NUMA node by the presence of a
>> +numa-node-id property which contains the node id of the device.
>> +
>> +Example:
>> +     /* numa node 0 */
>> +     numa-node-id = <0>;
>> +
>> +     /* numa node 1 */
>> +     numa-node-id = <1>;
>> +
>> +==============================================================================
>> +3 - distance-map
>> +==============================================================================
>> +
>> +The device tree node distance-map describes the relative
>> +distance(memory latency) between all numa nodes.
>> +
>> +- compatible : Should at least contain "numa-distance-map-v1".
>
> Thank you for updating these per my request.
>
> The fact that these have changed since the late posting [1] means that
> this is a new version of the patch rather than a resend. Please update
> the PATCHvX number when changes are made.
>
> You also need to update the driver for the new compatible string, so a
> new version of that is required.
>
>> +- distance-matrix
>> +  This property defines a matrix to describe the relative distances
>> +  between all numa nodes.
>> +  It is represented as a list of node pairs and their relative distance.
>> +
>> +  Note:
>> +     1. Each entry represents distance from first node to second node.
>> +     The distance are equal in either direction.
>> +     2. The distance from a node to self(local distance) is represented
>> +     with value 10 and all inter node distance should be represented with
>> +     value greater than 10.
>> +     3. distance-matrix shold have entries in lexicographical ascending
>> +     order of nodes.
>> +     4. There must be only one Device node distance-map and must reside in the root node.
>
> I am still concerned that the local distance of 10 is completely
> arbitrary.
IMHO, i do not see any issue in having defined local distance to
arbitrary number(10).
inter node numa distance is relative number with respect to local distance
we have to fix local distance to some value, having it in dt to make
generic will not add
any additional value as compared to having the fixed local distance to 10.

 #define LOCAL_DISTANCE          10
this macro which is defined in common code and used in many places in
common code as well in other arch specific codes.
If we add property to define local distance and it imply that local
distance can be changed to any value other than 10.
having this change demands common code changes wherever LOCAL_DISTANCE is used!.
I am not finding any reasoning to make local distance generic.

please correct me, if i misunderstood your suggestion
>
> Please:
>
> * Add a new local-distance property to the distance-map node allowing a
>   uniform local distance to be described, and require this property to
>   be present.
>
> * Update the driver to account for that and the compatible string
>   change.
>
> * Send a complete PATCHv8 (or PATCHv$X where X > 7) series with a proper
>   changelog.
>
> Thanks,
> Mark.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/385826.html

thanks
Ganapat

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Mark Rutland]

On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
> Hi Mark,
> 
> On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> >> +- distance-matrix
> >> +  This property defines a matrix to describe the relative distances
> >> +  between all numa nodes.
> >> +  It is represented as a list of node pairs and their relative distance.
> >> +
> >> +  Note:
> >> +     1. Each entry represents distance from first node to second node.
> >> +     The distance are equal in either direction.
> >> +     2. The distance from a node to self(local distance) is represented
> >> +     with value 10 and all inter node distance should be represented with
> >> +     value greater than 10.
> >> +     3. distance-matrix shold have entries in lexicographical ascending
> >> +     order of nodes.
> >> +     4. There must be only one Device node distance-map and must reside in the root node.
> >
> > I am still concerned that the local distance of 10 is completely
> > arbitrary.
> IMHO, i do not see any issue in having defined local distance to
> arbitrary number(10).
> inter node numa distance is relative number with respect to local distance
> we have to fix local distance to some value, having it in dt to make
> generic will not add
> any additional value as compared to having the fixed local distance to 10.

That's not quite true. The figure chosen for the local distance affects
the granularity with which you can describe all distances.

By using a local distance of 10 we can only encode distances in 10%
chunks of that. Using a local distance of 100 we could encode in 1%
chunks of that.

I believe that for some systems we may need a granularity better than
10%. Certainly for others we may not. Having an explicit property allows
for the description of either, and should be sufficient for a reasonable
period of time to come.

>  #define LOCAL_DISTANCE          10
> this macro which is defined in common code and used in many places in
> common code as well in other arch specific codes.
> If we add property to define local distance and it imply that local
> distance can be changed to any value other than 10.
> having this change demands common code changes wherever LOCAL_DISTANCE is used!.

While certainly painful, occasionally such changes are necessary.

Another option is to scale the input to the kernel's idea of a local
distance (at the possible loss of some granularity).

> I am not finding any reasoning to make local distance generic.

I hope the above has answered some of that.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Mark Rutland]

On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
> Hi Mark,
> 
> On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> +- distance-matrix
> >> +  This property defines a matrix to describe the relative distances
> >> +  between all numa nodes.
> >> +  It is represented as a list of node pairs and their relative distance.
> >> +
> >> +  Note:
> >> +     1. Each entry represents distance from first node to second node.
> >> +     The distance are equal in either direction.
> >> +     2. The distance from a node to self(local distance) is represented
> >> +     with value 10 and all inter node distance should be represented with
> >> +     value greater than 10.
> >> +     3. distance-matrix shold have entries in lexicographical ascending
> >> +     order of nodes.
> >> +     4. There must be only one Device node distance-map and must reside in the root node.
> >
> > I am still concerned that the local distance of 10 is completely
> > arbitrary.
> IMHO, i do not see any issue in having defined local distance to
> arbitrary number(10).
> inter node numa distance is relative number with respect to local distance
> we have to fix local distance to some value, having it in dt to make
> generic will not add
> any additional value as compared to having the fixed local distance to 10.

That's not quite true. The figure chosen for the local distance affects
the granularity with which you can describe all distances.

By using a local distance of 10 we can only encode distances in 10%
chunks of that. Using a local distance of 100 we could encode in 1%
chunks of that.

I believe that for some systems we may need a granularity better than
10%. Certainly for others we may not. Having an explicit property allows
for the description of either, and should be sufficient for a reasonable
period of time to come.

>  #define LOCAL_DISTANCE          10
> this macro which is defined in common code and used in many places in
> common code as well in other arch specific codes.
> If we add property to define local distance and it imply that local
> distance can be changed to any value other than 10.
> having this change demands common code changes wherever LOCAL_DISTANCE is used!.

While certainly painful, occasionally such changes are necessary.

Another option is to scale the input to the kernel's idea of a local
distance (at the possible loss of some granularity).

> I am not finding any reasoning to make local distance generic.

I hope the above has answered some of that.

Thanks,
Mark.

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

On Fri, Dec 18, 2015 at 11:33 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
>> Hi Mark,
>>
>> On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
>> >> +- distance-matrix
>> >> +  This property defines a matrix to describe the relative distances
>> >> +  between all numa nodes.
>> >> +  It is represented as a list of node pairs and their relative distance.
>> >> +
>> >> +  Note:
>> >> +     1. Each entry represents distance from first node to second node.
>> >> +     The distance are equal in either direction.
>> >> +     2. The distance from a node to self(local distance) is represented
>> >> +     with value 10 and all inter node distance should be represented with
>> >> +     value greater than 10.
>> >> +     3. distance-matrix shold have entries in lexicographical ascending
>> >> +     order of nodes.
>> >> +     4. There must be only one Device node distance-map and must reside in the root node.
>> >
>> > I am still concerned that the local distance of 10 is completely
>> > arbitrary.
>> IMHO, i do not see any issue in having defined local distance to
>> arbitrary number(10).
>> inter node numa distance is relative number with respect to local distance
>> we have to fix local distance to some value, having it in dt to make
>> generic will not add
>> any additional value as compared to having the fixed local distance to 10.
>
> That's not quite true. The figure chosen for the local distance affects
> the granularity with which you can describe all distances.
>
> By using a local distance of 10 we can only encode distances in 10%
> chunks of that. Using a local distance of 100 we could encode in 1%
> chunks of that.
>
> I believe that for some systems we may need a granularity better than
> 10%. Certainly for others we may not. Having an explicit property allows
> for the description of either, and should be sufficient for a reasonable
> period of time to come.
can we keep support for 1% granularity to numa-distance-map-v2
when * some system * which needs this becomes a reality.
>
>>  #define LOCAL_DISTANCE          10
>> this macro which is defined in common code and used in many places in
>> common code as well in other arch specific codes.
>> If we add property to define local distance and it imply that local
>> distance can be changed to any value other than 10.
>> having this change demands common code changes wherever LOCAL_DISTANCE is used!.
>
> While certainly painful, occasionally such changes are necessary.
i have no confidence that the maintainers of acpi, x86 and other common code
will agree to modify LOCAL_DISTANCE unless there is platform exist
which needs such granularity.
AFAIK, i dont see any existing platforms needs this.
IMO, Lets not deprive support for existing platforms for some not
known/future systems.
AFAIK, distance is just a relative number and in no way it is used to
infer granularity.


>
> Another option is to scale the input to the kernel's idea of a local
> distance (at the possible loss of some granularity).
>
>> I am not finding any reasoning to make local distance generic.
>
> I hope the above has answered some of that.
>
> Thanks,
> Mark.
thanks
Ganapat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

On Fri, Dec 18, 2015 at 11:33 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
>> Hi Mark,
>>
>> On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> >> +- distance-matrix
>> >> +  This property defines a matrix to describe the relative distances
>> >> +  between all numa nodes.
>> >> +  It is represented as a list of node pairs and their relative distance.
>> >> +
>> >> +  Note:
>> >> +     1. Each entry represents distance from first node to second node.
>> >> +     The distance are equal in either direction.
>> >> +     2. The distance from a node to self(local distance) is represented
>> >> +     with value 10 and all inter node distance should be represented with
>> >> +     value greater than 10.
>> >> +     3. distance-matrix shold have entries in lexicographical ascending
>> >> +     order of nodes.
>> >> +     4. There must be only one Device node distance-map and must reside in the root node.
>> >
>> > I am still concerned that the local distance of 10 is completely
>> > arbitrary.
>> IMHO, i do not see any issue in having defined local distance to
>> arbitrary number(10).
>> inter node numa distance is relative number with respect to local distance
>> we have to fix local distance to some value, having it in dt to make
>> generic will not add
>> any additional value as compared to having the fixed local distance to 10.
>
> That's not quite true. The figure chosen for the local distance affects
> the granularity with which you can describe all distances.
>
> By using a local distance of 10 we can only encode distances in 10%
> chunks of that. Using a local distance of 100 we could encode in 1%
> chunks of that.
>
> I believe that for some systems we may need a granularity better than
> 10%. Certainly for others we may not. Having an explicit property allows
> for the description of either, and should be sufficient for a reasonable
> period of time to come.
can we keep support for 1% granularity to numa-distance-map-v2
when * some system * which needs this becomes a reality.
>
>>  #define LOCAL_DISTANCE          10
>> this macro which is defined in common code and used in many places in
>> common code as well in other arch specific codes.
>> If we add property to define local distance and it imply that local
>> distance can be changed to any value other than 10.
>> having this change demands common code changes wherever LOCAL_DISTANCE is used!.
>
> While certainly painful, occasionally such changes are necessary.
i have no confidence that the maintainers of acpi, x86 and other common code
will agree to modify LOCAL_DISTANCE unless there is platform exist
which needs such granularity.
AFAIK, i dont see any existing platforms needs this.
IMO, Lets not deprive support for existing platforms for some not
known/future systems.
AFAIK, distance is just a relative number and in no way it is used to
infer granularity.


>
> Another option is to scale the input to the kernel's idea of a local
> distance (at the possible loss of some granularity).
>
>> I am not finding any reasoning to make local distance generic.
>
> I hope the above has answered some of that.
>
> Thanks,
> Mark.
thanks
Ganapat

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Will Deacon]

Mark,

On Fri, Dec 18, 2015 at 06:03:47PM +0000, Mark Rutland wrote:
> On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
> > Hi Mark,
> > 
> > On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > >> +- distance-matrix
> > >> +  This property defines a matrix to describe the relative distances
> > >> +  between all numa nodes.
> > >> +  It is represented as a list of node pairs and their relative distance.
> > >> +
> > >> +  Note:
> > >> +     1. Each entry represents distance from first node to second node.
> > >> +     The distance are equal in either direction.
> > >> +     2. The distance from a node to self(local distance) is represented
> > >> +     with value 10 and all inter node distance should be represented with
> > >> +     value greater than 10.
> > >> +     3. distance-matrix shold have entries in lexicographical ascending
> > >> +     order of nodes.
> > >> +     4. There must be only one Device node distance-map and must reside in the root node.
> > >
> > > I am still concerned that the local distance of 10 is completely
> > > arbitrary.
> > IMHO, i do not see any issue in having defined local distance to
> > arbitrary number(10).
> > inter node numa distance is relative number with respect to local distance
> > we have to fix local distance to some value, having it in dt to make
> > generic will not add
> > any additional value as compared to having the fixed local distance to 10.
> 
> That's not quite true. The figure chosen for the local distance affects
> the granularity with which you can describe all distances.
> 
> By using a local distance of 10 we can only encode distances in 10%
> chunks of that. Using a local distance of 100 we could encode in 1%
> chunks of that.

Whilst I see what you're saying, the local distance of 10 seems to be
part of the ACPI spec, and is the reason why the core code defines it
that way.

Now, we can of course do our own thing for device-tree, but I really
don't think it's worth our while to change this without a compelling
use-case.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Will Deacon]

Mark,

On Fri, Dec 18, 2015 at 06:03:47PM +0000, Mark Rutland wrote:
> On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
> > Hi Mark,
> > 
> > On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > >> +- distance-matrix
> > >> +  This property defines a matrix to describe the relative distances
> > >> +  between all numa nodes.
> > >> +  It is represented as a list of node pairs and their relative distance.
> > >> +
> > >> +  Note:
> > >> +     1. Each entry represents distance from first node to second node.
> > >> +     The distance are equal in either direction.
> > >> +     2. The distance from a node to self(local distance) is represented
> > >> +     with value 10 and all inter node distance should be represented with
> > >> +     value greater than 10.
> > >> +     3. distance-matrix shold have entries in lexicographical ascending
> > >> +     order of nodes.
> > >> +     4. There must be only one Device node distance-map and must reside in the root node.
> > >
> > > I am still concerned that the local distance of 10 is completely
> > > arbitrary.
> > IMHO, i do not see any issue in having defined local distance to
> > arbitrary number(10).
> > inter node numa distance is relative number with respect to local distance
> > we have to fix local distance to some value, having it in dt to make
> > generic will not add
> > any additional value as compared to having the fixed local distance to 10.
> 
> That's not quite true. The figure chosen for the local distance affects
> the granularity with which you can describe all distances.
> 
> By using a local distance of 10 we can only encode distances in 10%
> chunks of that. Using a local distance of 100 we could encode in 1%
> chunks of that.

Whilst I see what you're saying, the local distance of 10 seems to be
part of the ACPI spec, and is the reason why the core code defines it
that way.

Now, we can of course do our own thing for device-tree, but I really
don't think it's worth our while to change this without a compelling
use-case.

Will

Re: [RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Hanjun Guo]

On 2015/12/21 22:27, Will Deacon wrote:
> Mark,
>
> On Fri, Dec 18, 2015 at 06:03:47PM +0000, Mark Rutland wrote:
>> On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
>>> Hi Mark,
>>>
>>> On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
>>>>> +- distance-matrix
>>>>> +  This property defines a matrix to describe the relative distances
>>>>> +  between all numa nodes.
>>>>> +  It is represented as a list of node pairs and their relative distance.
>>>>> +
>>>>> +  Note:
>>>>> +     1. Each entry represents distance from first node to second node.
>>>>> +     The distance are equal in either direction.
>>>>> +     2. The distance from a node to self(local distance) is represented
>>>>> +     with value 10 and all inter node distance should be represented with
>>>>> +     value greater than 10.
>>>>> +     3. distance-matrix shold have entries in lexicographical ascending
>>>>> +     order of nodes.
>>>>> +     4. There must be only one Device node distance-map and must reside in the root node.
>>>>
>>>> I am still concerned that the local distance of 10 is completely
>>>> arbitrary.
>>> IMHO, i do not see any issue in having defined local distance to
>>> arbitrary number(10).
>>> inter node numa distance is relative number with respect to local distance
>>> we have to fix local distance to some value, having it in dt to make
>>> generic will not add
>>> any additional value as compared to having the fixed local distance to 10.
>>
>> That's not quite true. The figure chosen for the local distance affects
>> the granularity with which you can describe all distances.
>>
>> By using a local distance of 10 we can only encode distances in 10%
>> chunks of that. Using a local distance of 100 we could encode in 1%
>> chunks of that.
>
> Whilst I see what you're saying, the local distance of 10 seems to be
> part of the ACPI spec, and is the reason why the core code defines it
> that way.
>
> Now, we can of course do our own thing for device-tree, but I really
> don't think it's worth our while to change this without a compelling
> use-case.

I agree, that would simplify the kernel code as well.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Hanjun Guo]

On 2015/12/21 22:27, Will Deacon wrote:
> Mark,
>
> On Fri, Dec 18, 2015 at 06:03:47PM +0000, Mark Rutland wrote:
>> On Fri, Dec 18, 2015 at 09:00:18PM +0530, Ganapatrao Kulkarni wrote:
>>> Hi Mark,
>>>
>>> On Fri, Dec 18, 2015 at 7:48 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>> +- distance-matrix
>>>>> +  This property defines a matrix to describe the relative distances
>>>>> +  between all numa nodes.
>>>>> +  It is represented as a list of node pairs and their relative distance.
>>>>> +
>>>>> +  Note:
>>>>> +     1. Each entry represents distance from first node to second node.
>>>>> +     The distance are equal in either direction.
>>>>> +     2. The distance from a node to self(local distance) is represented
>>>>> +     with value 10 and all inter node distance should be represented with
>>>>> +     value greater than 10.
>>>>> +     3. distance-matrix shold have entries in lexicographical ascending
>>>>> +     order of nodes.
>>>>> +     4. There must be only one Device node distance-map and must reside in the root node.
>>>>
>>>> I am still concerned that the local distance of 10 is completely
>>>> arbitrary.
>>> IMHO, i do not see any issue in having defined local distance to
>>> arbitrary number(10).
>>> inter node numa distance is relative number with respect to local distance
>>> we have to fix local distance to some value, having it in dt to make
>>> generic will not add
>>> any additional value as compared to having the fixed local distance to 10.
>>
>> That's not quite true. The figure chosen for the local distance affects
>> the granularity with which you can describe all distances.
>>
>> By using a local distance of 10 we can only encode distances in 10%
>> chunks of that. Using a local distance of 100 we could encode in 1%
>> chunks of that.
>
> Whilst I see what you're saying, the local distance of 10 seems to be
> part of the ACPI spec, and is the reason why the core code defines it
> that way.
>
> Now, we can of course do our own thing for device-tree, but I really
> don't think it's worth our while to change this without a compelling
> use-case.

I agree, that would simplify the kernel code as well.

Thanks
Hanjun

[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.

[Ganapatrao Kulkarni]

DT bindings for numa mapping of memory, cores and IOs.

Reviewed-by: Robert Richter <rrichter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
---
 Documentation/devicetree/bindings/arm/numa.txt | 273 +++++++++++++++++++++++++
 1 file changed, 273 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/numa.txt

diff --git a/Documentation/devicetree/bindings/arm/numa.txt b/Documentation/devicetree/bindings/arm/numa.txt
new file mode 100644
index 0000000..5bd893e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/numa.txt
@@ -0,0 +1,273 @@
+==============================================================================
+NUMA binding description.
+==============================================================================
+
+==============================================================================
+1 - Introduction
+==============================================================================
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==============================================================================
+2 - numa-node-id
+==============================================================================
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+	/* numa node 0 */
+	numa-node-id = <0>;
+
+	/* numa node 1 */
+	numa-node-id = <1>;
+
+==============================================================================
+3 - distance-map
+==============================================================================
+
+The device tree node distance-map describes the relative
+distance(memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+  This property defines a matrix to describe the relative distances
+  between all numa nodes.
+  It is represented as a list of node pairs and their relative distance.
+
+  Note:
+	1. Each entry represents distance from first node to second node.
+	The distance are equal in either direction.
+	2. The distance from a node to self(local distance) is represented
+	with value 10 and all inter node distance should be represented with
+	value greater than 10.
+	3. distance-matrix shold have entries in lexicographical ascending
+	order of nodes.
+	4. There must be only one Device node distance-map and must reside in the root node.
+
+Example:
+	4 nodes connected in mesh/ring topology as below,
+
+		0_______20______1
+		|               |
+		|               |
+		20             20
+		|               |
+		|               |
+		|_______________|
+		3       20      2
+
+	if relative distance for each hop is 20,
+	then inter node distance would be,
+	      0 -> 1 = 20
+	      1 -> 2 = 20
+	      2 -> 3 = 20
+	      3 -> 0 = 20
+	      0 -> 2 = 40
+	      1 -> 3 = 40
+
+     and dt presentation for this distance matrix is,
+
+		distance-map {
+			 compatible = "numa-distance-map-v1";
+			 distance-matrix = <0 0  10>,
+					   <0 1  20>,
+					   <0 2  40>,
+					   <0 3  20>,
+					   <1 0  20>,
+					   <1 1  10>,
+					   <1 2  20>,
+					   <1 3  40>,
+					   <2 0  40>,
+					   <2 1  20>,
+					   <2 2  10>,
+					   <2 3  20>,
+					   <3 0  20>,
+					   <3 1  40>,
+					   <3 2  20>,
+					   <3 3  10>;
+		};
+
+
+==============================================================================
+4 - Example dts
+==============================================================================
+
+2 sockets system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+	memory@00c00000 {
+		device_type = "memory";
+		reg = <0x0 0x00c00000 0x0 0x80000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+	};
+
+	memory@10000000000 {
+		device_type = "memory";
+		reg = <0x100 0x00000000 0x0 0x80000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu@000 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x000>;
+			enable-method = "psci";
+			/* node 0 */
+			numa-node-id = <0>;
+		};
+		cpu@001 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x001>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@002 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x002>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@003 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x003>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@004 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x004>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@005 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x005>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@006 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x006>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@007 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x007>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu@008 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x008>;
+			enable-method = "psci";
+			/* node 1 */
+			numa-node-id = <1>;
+		};
+		cpu@009 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x009>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00a {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00a>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00b {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00b>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00c {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00c>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00d {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00d>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00e {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00e>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu@00f {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x00f>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+	};
+
+	pcie0: pcie0@0x8480,00000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+        };
+
+	pcie1: pcie1@0x9480,00000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x9480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x9010 0x00000000 0x9010 0x00000000 0x70 0x00000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+        };
+
+	distance-map {
+		compatible = "numa-distance-map-v1";
+		distance-matrix = <0 0 10>,
+				  <0 1 20>,
+				  <1 1 10>;
+	};
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html