[PATCH 0/5] arm64: Juno DT updates and new DT for Juno R1

[PATCH 0/5] arm64: Juno DT updates and new DT for Juno R1

[Liviu Dudau]

This series restructures the Juno DT files and introduces the DT
for the new Juno R1. The board is an update of the Juno R0 with
support for PCIe, but the current series only brings the board to
parity with Juno R0. The series that enable the PCIe Generic Host
Bridge to be used on Juno R1 will be posted separately.

Liviu Dudau (5):
  arm64: Juno: Fix the GIC node address label and the frequency of FAXI clock.
  arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.
  arm64: Juno: Add memory mapped timer node
  arm64: Juno: Add GICv2m support in device tree.
  arm64: Add DT support for Juno r1 board.

 arch/arm64/boot/dts/arm/Makefile         |   2 +-
 arch/arm64/boot/dts/arm/juno-base.dtsi   | 147 +++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/arm/juno-clocks.dtsi |   4 +-
 arch/arm64/boot/dts/arm/juno-r1.dts      | 123 ++++++++++++++++++++++++++
 arch/arm64/boot/dts/arm/juno.dts         | 122 +------------------------
 5 files changed, 274 insertions(+), 124 deletions(-)
 create mode 100644 arch/arm64/boot/dts/arm/juno-base.dtsi
 create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts

-- 
2.3.6

[PATCH 0/5] arm64: Juno DT updates and new DT for Juno R1

[Liviu Dudau]

This series restructures the Juno DT files and introduces the DT
for the new Juno R1. The board is an update of the Juno R0 with
support for PCIe, but the current series only brings the board to
parity with Juno R0. The series that enable the PCIe Generic Host
Bridge to be used on Juno R1 will be posted separately.

Liviu Dudau (5):
  arm64: Juno: Fix the GIC node address label and the frequency of FAXI clock.
  arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.
  arm64: Juno: Add memory mapped timer node
  arm64: Juno: Add GICv2m support in device tree.
  arm64: Add DT support for Juno r1 board.

 arch/arm64/boot/dts/arm/Makefile         |   2 +-
 arch/arm64/boot/dts/arm/juno-base.dtsi   | 147 +++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/arm/juno-clocks.dtsi |   4 +-
 arch/arm64/boot/dts/arm/juno-r1.dts      | 123 ++++++++++++++++++++++++++
 arch/arm64/boot/dts/arm/juno.dts         | 122 +------------------------
 5 files changed, 274 insertions(+), 124 deletions(-)
 create mode 100644 arch/arm64/boot/dts/arm/juno-base.dtsi
 create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts

-- 
2.3.6

[PATCH 1/5] arm64: Juno: Fix the GIC node address label and the frequency of FAXI clock.

[Liviu Dudau]

During the review of the Juno DT files I've noticed that the GIC
node label had two digits swapped leading to a different address
being shown in the /sys/devices fs.

Sudeep also pointed that public revisions of the Juno documentation
list a different frequency for the FAXI system than what the one
I've been using when creating the DT file. Verified with the firmware
people to be the correct value in the shipped systems.

Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-clocks.dtsi | 4 ++--
 arch/arm64/boot/dts/arm/juno.dts         | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/arm/juno-clocks.dtsi b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
index c9b89ef..25352ed 100644
--- a/arch/arm64/boot/dts/arm/juno-clocks.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
@@ -36,9 +36,9 @@
 		clock-output-names = "apb_pclk";
 	};
 
-	soc_faxiclk: refclk533mhz {
+	soc_faxiclk: refclk400mhz {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
-		clock-frequency = <533000000>;
+		clock-frequency = <400000000>;
 		clock-output-names = "faxi_clk";
 	};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 5e9110a..7ab0713 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -98,7 +98,7 @@
 		      <0x00000008 0x80000000 0x1 0x80000000>;
 	};
 
-	gic: interrupt-controller@2c001000 {
+	gic: interrupt-controller@2c010000 {
 		compatible = "arm,gic-400", "arm,cortex-a15-gic";
 		reg = <0x0 0x2c010000 0 0x1000>,
 		      <0x0 0x2c02f000 0 0x2000>,
-- 
2.3.6

[PATCH 1/5] arm64: Juno: Fix the GIC node address label and the frequency of FAXI clock.

[Liviu Dudau]

During the review of the Juno DT files I've noticed that the GIC
node label had two digits swapped leading to a different address
being shown in the /sys/devices fs.

Sudeep also pointed that public revisions of the Juno documentation
list a different frequency for the FAXI system than what the one
I've been using when creating the DT file. Verified with the firmware
people to be the correct value in the shipped systems.

Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-clocks.dtsi | 4 ++--
 arch/arm64/boot/dts/arm/juno.dts         | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/arm/juno-clocks.dtsi b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
index c9b89ef..25352ed 100644
--- a/arch/arm64/boot/dts/arm/juno-clocks.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-clocks.dtsi
@@ -36,9 +36,9 @@
 		clock-output-names = "apb_pclk";
 	};
 
-	soc_faxiclk: refclk533mhz {
+	soc_faxiclk: refclk400mhz {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
-		clock-frequency = <533000000>;
+		clock-frequency = <400000000>;
 		clock-output-names = "faxi_clk";
 	};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 5e9110a..7ab0713 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -98,7 +98,7 @@
 		      <0x00000008 0x80000000 0x1 0x80000000>;
 	};
 
-	gic: interrupt-controller at 2c001000 {
+	gic: interrupt-controller at 2c010000 {
 		compatible = "arm,gic-400", "arm,cortex-a15-gic";
 		reg = <0x0 0x2c010000 0 0x1000>,
 		      <0x0 0x2c02f000 0 0x2000>,
-- 
2.3.6

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Liviu Dudau]

Prepare the device tree for adding more boards based on Juno r0.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/arm/juno.dts       | 122 +-------------------------------
 2 files changed, 126 insertions(+), 121 deletions(-)
 create mode 100644 arch/arm64/boot/dts/arm/juno-base.dtsi

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
new file mode 100644
index 0000000..2faa68a
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -0,0 +1,125 @@
+	/*
+	 *  Devices shared by all Juno boards
+	 */
+
+	gic: interrupt-controller@2c010000 {
+		compatible = "arm,gic-400", "arm,cortex-a15-gic";
+		reg = <0x0 0x2c010000 0 0x1000>,
+		      <0x0 0x2c02f000 0 0x2000>,
+		      <0x0 0x2c04f000 0 0x2000>,
+		      <0x0 0x2c06f000 0 0x2000>;
+		#address-cells = <0>;
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	/include/ "juno-clocks.dtsi"
+
+	dma@7ff00000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0x7ff00000 0 0x1000>;
+		#dma-cells = <1>;
+		#dma-channels = <8>;
+		#dma-requests = <32>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_faxiclk>;
+		clock-names = "apb_pclk";
+	};
+
+	soc_uart0: uart@7ff80000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x0 0x7ff80000 0x0 0x1000>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_uartclk>, <&soc_refclk100mhz>;
+		clock-names = "uartclk", "apb_pclk";
+	};
+
+	i2c@7ffa0000 {
+		compatible = "snps,designware-i2c";
+		reg = <0x0 0x7ffa0000 0x0 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <400000>;
+		i2c-sda-hold-time-ns = <500>;
+		clocks = <&soc_smc50mhz>;
+
+		dvi0: dvi-transmitter@70 {
+			compatible = "nxp,tda998x";
+			reg = <0x70>;
+		};
+
+		dvi1: dvi-transmitter@71 {
+			compatible = "nxp,tda998x";
+			reg = <0x71>;
+		};
+	};
+
+	ohci@7ffb0000 {
+		compatible = "generic-ohci";
+		reg = <0x0 0x7ffb0000 0x0 0x10000>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_usb48mhz>;
+	};
+
+	ehci@7ffc0000 {
+		compatible = "generic-ehci";
+		reg = <0x0 0x7ffc0000 0x0 0x10000>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_usb48mhz>;
+	};
+
+	memory-controller@7ffd0000 {
+		compatible = "arm,pl354", "arm,primecell";
+		reg = <0 0x7ffd0000 0 0x1000>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_smc50mhz>;
+		clock-names = "apb_pclk";
+	};
+
+	smb {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0 0 0 0x08000000 0x04000000>,
+			 <1 0 0 0x14000000 0x04000000>,
+			 <2 0 0 0x18000000 0x04000000>,
+			 <3 0 0 0x1c000000 0x04000000>,
+			 <4 0 0 0x0c000000 0x04000000>,
+			 <5 0 0 0x10000000 0x04000000>;
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 15>;
+		interrupt-map = <0 0  0 &gic 0  68 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  1 &gic 0  69 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  2 &gic 0  70 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
+
+		/include/ "juno-motherboard.dtsi"
+	};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 7ab0713..60e8928 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -98,26 +98,6 @@
 		      <0x00000008 0x80000000 0x1 0x80000000>;
 	};
 
-	gic: interrupt-controller@2c010000 {
-		compatible = "arm,gic-400", "arm,cortex-a15-gic";
-		reg = <0x0 0x2c010000 0 0x1000>,
-		      <0x0 0x2c02f000 0 0x2000>,
-		      <0x0 0x2c04f000 0 0x2000>,
-		      <0x0 0x2c06f000 0 0x2000>;
-		#address-cells = <0>;
-		#interrupt-cells = <3>;
-		interrupt-controller;
-		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
-	};
-
-	timer {
-		compatible = "arm,armv8-timer";
-		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
-	};
-
 	pmu {
 		compatible = "arm,armv8-pmuv3";
 		interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
@@ -134,105 +114,5 @@
 				     <&A53_3>;
 	};
 
-	/include/ "juno-clocks.dtsi"
-
-	dma@7ff00000 {
-		compatible = "arm,pl330", "arm,primecell";
-		reg = <0x0 0x7ff00000 0 0x1000>;
-		#dma-cells = <1>;
-		#dma-channels = <8>;
-		#dma-requests = <32>;
-		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_faxiclk>;
-		clock-names = "apb_pclk";
-	};
-
-	soc_uart0: uart@7ff80000 {
-		compatible = "arm,pl011", "arm,primecell";
-		reg = <0x0 0x7ff80000 0x0 0x1000>;
-		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_uartclk>, <&soc_refclk100mhz>;
-		clock-names = "uartclk", "apb_pclk";
-	};
-
-	i2c@7ffa0000 {
-		compatible = "snps,designware-i2c";
-		reg = <0x0 0x7ffa0000 0x0 0x1000>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
-		clock-frequency = <400000>;
-		i2c-sda-hold-time-ns = <500>;
-		clocks = <&soc_smc50mhz>;
-
-		dvi0: dvi-transmitter@70 {
-			compatible = "nxp,tda998x";
-			reg = <0x70>;
-		};
-
-		dvi1: dvi-transmitter@71 {
-			compatible = "nxp,tda998x";
-			reg = <0x71>;
-		};
-	};
-
-	ohci@7ffb0000 {
-		compatible = "generic-ohci";
-		reg = <0x0 0x7ffb0000 0x0 0x10000>;
-		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_usb48mhz>;
-	};
-
-	ehci@7ffc0000 {
-		compatible = "generic-ehci";
-		reg = <0x0 0x7ffc0000 0x0 0x10000>;
-		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_usb48mhz>;
-	};
-
-	memory-controller@7ffd0000 {
-		compatible = "arm,pl354", "arm,primecell";
-		reg = <0 0x7ffd0000 0 0x1000>;
-		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_smc50mhz>;
-		clock-names = "apb_pclk";
-	};
-
-	smb {
-		compatible = "simple-bus";
-		#address-cells = <2>;
-		#size-cells = <1>;
-		ranges = <0 0 0 0x08000000 0x04000000>,
-			 <1 0 0 0x14000000 0x04000000>,
-			 <2 0 0 0x18000000 0x04000000>,
-			 <3 0 0 0x1c000000 0x04000000>,
-			 <4 0 0 0x0c000000 0x04000000>,
-			 <5 0 0 0x10000000 0x04000000>;
-
-		#interrupt-cells = <1>;
-		interrupt-map-mask = <0 0 15>;
-		interrupt-map = <0 0  0 &gic 0  68 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  1 &gic 0  69 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  2 &gic 0  70 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
-
-		/include/ "juno-motherboard.dtsi"
-	};
+	#include "juno-base.dtsi"
 };
-- 
2.3.6

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Liviu Dudau]

Prepare the device tree for adding more boards based on Juno r0.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/arm/juno.dts       | 122 +-------------------------------
 2 files changed, 126 insertions(+), 121 deletions(-)
 create mode 100644 arch/arm64/boot/dts/arm/juno-base.dtsi

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
new file mode 100644
index 0000000..2faa68a
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -0,0 +1,125 @@
+	/*
+	 *  Devices shared by all Juno boards
+	 */
+
+	gic: interrupt-controller at 2c010000 {
+		compatible = "arm,gic-400", "arm,cortex-a15-gic";
+		reg = <0x0 0x2c010000 0 0x1000>,
+		      <0x0 0x2c02f000 0 0x2000>,
+		      <0x0 0x2c04f000 0 0x2000>,
+		      <0x0 0x2c06f000 0 0x2000>;
+		#address-cells = <0>;
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	/include/ "juno-clocks.dtsi"
+
+	dma at 7ff00000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0x7ff00000 0 0x1000>;
+		#dma-cells = <1>;
+		#dma-channels = <8>;
+		#dma-requests = <32>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_faxiclk>;
+		clock-names = "apb_pclk";
+	};
+
+	soc_uart0: uart at 7ff80000 {
+		compatible = "arm,pl011", "arm,primecell";
+		reg = <0x0 0x7ff80000 0x0 0x1000>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_uartclk>, <&soc_refclk100mhz>;
+		clock-names = "uartclk", "apb_pclk";
+	};
+
+	i2c at 7ffa0000 {
+		compatible = "snps,designware-i2c";
+		reg = <0x0 0x7ffa0000 0x0 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <400000>;
+		i2c-sda-hold-time-ns = <500>;
+		clocks = <&soc_smc50mhz>;
+
+		dvi0: dvi-transmitter at 70 {
+			compatible = "nxp,tda998x";
+			reg = <0x70>;
+		};
+
+		dvi1: dvi-transmitter at 71 {
+			compatible = "nxp,tda998x";
+			reg = <0x71>;
+		};
+	};
+
+	ohci at 7ffb0000 {
+		compatible = "generic-ohci";
+		reg = <0x0 0x7ffb0000 0x0 0x10000>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_usb48mhz>;
+	};
+
+	ehci at 7ffc0000 {
+		compatible = "generic-ehci";
+		reg = <0x0 0x7ffc0000 0x0 0x10000>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_usb48mhz>;
+	};
+
+	memory-controller at 7ffd0000 {
+		compatible = "arm,pl354", "arm,primecell";
+		reg = <0 0x7ffd0000 0 0x1000>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&soc_smc50mhz>;
+		clock-names = "apb_pclk";
+	};
+
+	smb {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0 0 0 0x08000000 0x04000000>,
+			 <1 0 0 0x14000000 0x04000000>,
+			 <2 0 0 0x18000000 0x04000000>,
+			 <3 0 0 0x1c000000 0x04000000>,
+			 <4 0 0 0x0c000000 0x04000000>,
+			 <5 0 0 0x10000000 0x04000000>;
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 15>;
+		interrupt-map = <0 0  0 &gic 0  68 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  1 &gic 0  69 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  2 &gic 0  70 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
+
+		/include/ "juno-motherboard.dtsi"
+	};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 7ab0713..60e8928 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -98,26 +98,6 @@
 		      <0x00000008 0x80000000 0x1 0x80000000>;
 	};
 
-	gic: interrupt-controller at 2c010000 {
-		compatible = "arm,gic-400", "arm,cortex-a15-gic";
-		reg = <0x0 0x2c010000 0 0x1000>,
-		      <0x0 0x2c02f000 0 0x2000>,
-		      <0x0 0x2c04f000 0 0x2000>,
-		      <0x0 0x2c06f000 0 0x2000>;
-		#address-cells = <0>;
-		#interrupt-cells = <3>;
-		interrupt-controller;
-		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
-	};
-
-	timer {
-		compatible = "arm,armv8-timer";
-		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
-	};
-
 	pmu {
 		compatible = "arm,armv8-pmuv3";
 		interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
@@ -134,105 +114,5 @@
 				     <&A53_3>;
 	};
 
-	/include/ "juno-clocks.dtsi"
-
-	dma at 7ff00000 {
-		compatible = "arm,pl330", "arm,primecell";
-		reg = <0x0 0x7ff00000 0 0x1000>;
-		#dma-cells = <1>;
-		#dma-channels = <8>;
-		#dma-requests = <32>;
-		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_faxiclk>;
-		clock-names = "apb_pclk";
-	};
-
-	soc_uart0: uart at 7ff80000 {
-		compatible = "arm,pl011", "arm,primecell";
-		reg = <0x0 0x7ff80000 0x0 0x1000>;
-		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_uartclk>, <&soc_refclk100mhz>;
-		clock-names = "uartclk", "apb_pclk";
-	};
-
-	i2c at 7ffa0000 {
-		compatible = "snps,designware-i2c";
-		reg = <0x0 0x7ffa0000 0x0 0x1000>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
-		clock-frequency = <400000>;
-		i2c-sda-hold-time-ns = <500>;
-		clocks = <&soc_smc50mhz>;
-
-		dvi0: dvi-transmitter at 70 {
-			compatible = "nxp,tda998x";
-			reg = <0x70>;
-		};
-
-		dvi1: dvi-transmitter at 71 {
-			compatible = "nxp,tda998x";
-			reg = <0x71>;
-		};
-	};
-
-	ohci at 7ffb0000 {
-		compatible = "generic-ohci";
-		reg = <0x0 0x7ffb0000 0x0 0x10000>;
-		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_usb48mhz>;
-	};
-
-	ehci at 7ffc0000 {
-		compatible = "generic-ehci";
-		reg = <0x0 0x7ffc0000 0x0 0x10000>;
-		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_usb48mhz>;
-	};
-
-	memory-controller at 7ffd0000 {
-		compatible = "arm,pl354", "arm,primecell";
-		reg = <0 0x7ffd0000 0 0x1000>;
-		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&soc_smc50mhz>;
-		clock-names = "apb_pclk";
-	};
-
-	smb {
-		compatible = "simple-bus";
-		#address-cells = <2>;
-		#size-cells = <1>;
-		ranges = <0 0 0 0x08000000 0x04000000>,
-			 <1 0 0 0x14000000 0x04000000>,
-			 <2 0 0 0x18000000 0x04000000>,
-			 <3 0 0 0x1c000000 0x04000000>,
-			 <4 0 0 0x0c000000 0x04000000>,
-			 <5 0 0 0x10000000 0x04000000>;
-
-		#interrupt-cells = <1>;
-		interrupt-map-mask = <0 0 15>;
-		interrupt-map = <0 0  0 &gic 0  68 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  1 &gic 0  69 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  2 &gic 0  70 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
-
-		/include/ "juno-motherboard.dtsi"
-	};
+	#include "juno-base.dtsi"
 };
-- 
2.3.6

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Jon Medhurst (Tixy)]

On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> Prepare the device tree for adding more boards based on Juno r0.
> 
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
>  arch/arm64/boot/dts/arm/juno.dts       | 122 +-------------------------------


What criteria were used to select the contents of juno-base.dtsi?
>From what I can see, the stuff left out of base is still the same for r0
and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be

-------------------------------------------------------------------------
#include "juno.dts"

/ {
	model = "ARM Juno development board (r1)";

};

&memtimer {
	status = "okay";
};
-------------------------------------------------------------------------

Yes, it's a bit hacky, but avoids duplication of source code.

I can only assume there are come non-public differences between r0 and
r1?

-- 
Tixy

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Jon Medhurst (Tixy)]

On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> Prepare the device tree for adding more boards based on Juno r0.
> 
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
>  arch/arm64/boot/dts/arm/juno.dts       | 122 +-------------------------------


What criteria were used to select the contents of juno-base.dtsi?
>From what I can see, the stuff left out of base is still the same for r0
and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be

-------------------------------------------------------------------------
#include "juno.dts"

/ {
	model = "ARM Juno development board (r1)";

};

&memtimer {
	status = "okay";
};
-------------------------------------------------------------------------

Yes, it's a bit hacky, but avoids duplication of source code.

I can only assume there are come non-public differences between r0 and
r1?

-- 
Tixy

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Liviu Dudau]

On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > Prepare the device tree for adding more boards based on Juno r0.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
> >  arch/arm64/boot/dts/arm/juno.dts       | 122 +-------------------------------
> 
> 
> What criteria were used to select the contents of juno-base.dtsi?
> From what I can see, the stuff left out of base is still the same for r0
> and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be
> 
> -------------------------------------------------------------------------
> #include "juno.dts"
> 
> / {
> 	model = "ARM Juno development board (r1)";
> 
> };
> 
> &memtimer {
> 	status = "okay";
> };
> -------------------------------------------------------------------------
> 
> Yes, it's a bit hacky, but avoids duplication of source code.
> 
> I can only assume there are come non-public differences between r0 and
> r1?

Hi Tixy,

There are potential differences. Cortex-A53 cluster in r1 has limited
CPUfreq functionality due to a chip errata and there were talks internally
to actually disable it, hence the reason for keeping CPUs outside the
juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
is preparing for the future as well.

PMU are linked to the CPUs, hence the reason they stayed. As for the
memory and psci nodes the thinking behind it was mostly to allow for
ACPI to make changes there, but it does look now like retrofitting an
explanation to something that I did not give too much thought at that
moment.

Best regards,
Liviu

> 
> -- 
> Tixy
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Liviu Dudau]

On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > Prepare the device tree for adding more boards based on Juno r0.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  arch/arm64/boot/dts/arm/juno-base.dtsi | 125 +++++++++++++++++++++++++++++++++
> >  arch/arm64/boot/dts/arm/juno.dts       | 122 +-------------------------------
> 
> 
> What criteria were used to select the contents of juno-base.dtsi?
> From what I can see, the stuff left out of base is still the same for r0
> and r1 (cpu, pmu, memory, psci!). And so juno-r1.dts could just be
> 
> -------------------------------------------------------------------------
> #include "juno.dts"
> 
> / {
> 	model = "ARM Juno development board (r1)";
> 
> };
> 
> &memtimer {
> 	status = "okay";
> };
> -------------------------------------------------------------------------
> 
> Yes, it's a bit hacky, but avoids duplication of source code.
> 
> I can only assume there are come non-public differences between r0 and
> r1?

Hi Tixy,

There are potential differences. Cortex-A53 cluster in r1 has limited
CPUfreq functionality due to a chip errata and there were talks internally
to actually disable it, hence the reason for keeping CPUs outside the
juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
is preparing for the future as well.

PMU are linked to the CPUs, hence the reason they stayed. As for the
memory and psci nodes the thinking behind it was mostly to allow for
ACPI to make changes there, but it does look now like retrofitting an
explanation to something that I did not give too much thought at that
moment.

Best regards,
Liviu

> 
> -- 
> Tixy
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Jon Medhurst (Tixy)]

On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
[...]
> > 
> > What criteria were used to select the contents of juno-base.dtsi?
> > From what I can see, the stuff left out of base is still the same for r0
> > and r1 (cpu, pmu, memory, psci!).
[...]
> 
> There are potential differences. Cortex-A53 cluster in r1 has limited
> CPUfreq functionality due to a chip errata and there were talks internally
> to actually disable it, hence the reason for keeping CPUs outside the
> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> is preparing for the future as well.
> 
> PMU are linked to the CPUs, hence the reason they stayed. As for the
> memory and psci nodes the thinking behind it was mostly to allow for
> ACPI to make changes there, but it does look now like retrofitting an
> explanation to something that I did not give too much thought at that
> moment.

I guess my concern was motivated by the selfish aspect of having to
maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
related DT updates) and having to duplicate those in more than one DT,
and also having backport DT reorgs like this patch. Of course, none of
that should be a consideration in deciding what goes into mainline, I
just wanted to make sure there was a reason for the patch.

-- 
Tixy

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Jon Medhurst (Tixy)]

On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
[...]
> > 
> > What criteria were used to select the contents of juno-base.dtsi?
> > From what I can see, the stuff left out of base is still the same for r0
> > and r1 (cpu, pmu, memory, psci!).
[...]
> 
> There are potential differences. Cortex-A53 cluster in r1 has limited
> CPUfreq functionality due to a chip errata and there were talks internally
> to actually disable it, hence the reason for keeping CPUs outside the
> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> is preparing for the future as well.
> 
> PMU are linked to the CPUs, hence the reason they stayed. As for the
> memory and psci nodes the thinking behind it was mostly to allow for
> ACPI to make changes there, but it does look now like retrofitting an
> explanation to something that I did not give too much thought at that
> moment.

I guess my concern was motivated by the selfish aspect of having to
maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
related DT updates) and having to duplicate those in more than one DT,
and also having backport DT reorgs like this patch. Of course, none of
that should be a consideration in deciding what goes into mainline, I
just wanted to make sure there was a reason for the patch.

-- 
Tixy

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Liviu Dudau]

On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
> > > 
> > > What criteria were used to select the contents of juno-base.dtsi?
> > > From what I can see, the stuff left out of base is still the same for r0
> > > and r1 (cpu, pmu, memory, psci!).
> [...]
> > 
> > There are potential differences. Cortex-A53 cluster in r1 has limited
> > CPUfreq functionality due to a chip errata and there were talks internally
> > to actually disable it, hence the reason for keeping CPUs outside the
> > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> > is preparing for the future as well.
> > 
> > PMU are linked to the CPUs, hence the reason they stayed. As for the
> > memory and psci nodes the thinking behind it was mostly to allow for
> > ACPI to make changes there, but it does look now like retrofitting an
> > explanation to something that I did not give too much thought at that
> > moment.
> 
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.

You are probably the best placed engineer to offer feedback on these patches,
as it will affect you in the downstream.

Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and
that HMP/EAS will not be working optimally on R1, do you still want to see
the CPUs nodes moved into juno-base.dtsi?

Best regards,
Liviu

> 
> -- 
> Tixy
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Liviu Dudau]

On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
> > > 
> > > What criteria were used to select the contents of juno-base.dtsi?
> > > From what I can see, the stuff left out of base is still the same for r0
> > > and r1 (cpu, pmu, memory, psci!).
> [...]
> > 
> > There are potential differences. Cortex-A53 cluster in r1 has limited
> > CPUfreq functionality due to a chip errata and there were talks internally
> > to actually disable it, hence the reason for keeping CPUs outside the
> > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> > is preparing for the future as well.
> > 
> > PMU are linked to the CPUs, hence the reason they stayed. As for the
> > memory and psci nodes the thinking behind it was mostly to allow for
> > ACPI to make changes there, but it does look now like retrofitting an
> > explanation to something that I did not give too much thought at that
> > moment.
> 
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.

You are probably the best placed engineer to offer feedback on these patches,
as it will affect you in the downstream.

Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and
that HMP/EAS will not be working optimally on R1, do you still want to see
the CPUs nodes moved into juno-base.dtsi?

Best regards,
Liviu

> 
> -- 
> Tixy
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Liviu Dudau]

On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
> > > 
> > > What criteria were used to select the contents of juno-base.dtsi?
> > > From what I can see, the stuff left out of base is still the same for r0
> > > and r1 (cpu, pmu, memory, psci!).
> [...]
> > 
> > There are potential differences. Cortex-A53 cluster in r1 has limited
> > CPUfreq functionality due to a chip errata and there were talks internally
> > to actually disable it, hence the reason for keeping CPUs outside the
> > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> > is preparing for the future as well.
> > 
> > PMU are linked to the CPUs, hence the reason they stayed. As for the
> > memory and psci nodes the thinking behind it was mostly to allow for
> > ACPI to make changes there, but it does look now like retrofitting an
> > explanation to something that I did not give too much thought at that
> > moment.
> 
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.

You are probably the best placed engineer to offer feedback on these patches,
as it will affect you in the downstream.

Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and
that HMP/EAS will not be working optimally on R1, do you still want to see
the CPUs nodes moved into juno-base.dtsi?

Best regards,
Liviu

> 
> -- 
> Tixy
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

--
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

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Jon Medhurst (Tixy)]

On Thu, 2015-05-14 at 14:11 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> > [...]
> > > > 
> > > > What criteria were used to select the contents of juno-base.dtsi?
> > > > From what I can see, the stuff left out of base is still the same for r0
> > > > and r1 (cpu, pmu, memory, psci!).
> > [...]
> > > 
> > > There are potential differences. Cortex-A53 cluster in r1 has limited
> > > CPUfreq functionality due to a chip errata and there were talks internally
> > > to actually disable it, hence the reason for keeping CPUs outside the
> > > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> > > is preparing for the future as well.
> > > 
> > > PMU are linked to the CPUs, hence the reason they stayed. As for the
> > > memory and psci nodes the thinking behind it was mostly to allow for
> > > ACPI to make changes there, but it does look now like retrofitting an
> > > explanation to something that I did not give too much thought at that
> > > moment.
> > 
> > I guess my concern was motivated by the selfish aspect of having to
> > maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
> > related DT updates) and having to duplicate those in more than one DT,
> > and also having backport DT reorgs like this patch. Of course, none of
> > that should be a consideration in deciding what goes into mainline, I
> > just wanted to make sure there was a reason for the patch.
> 
> You are probably the best placed engineer to offer feedback on these patches,
> as it will affect you in the downstream.
> 
> Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and
> that HMP/EAS will not be working optimally on R1, do you still want to see
> the CPUs nodes moved into juno-base.dtsi?

Well, I can only answer that if I knew what the requirements were for
the kernels I maintain, and as I'm unlikely to get any sensible answer,
or one that doesn't change depending on the day of the week or the
person I ask, then I think it probably best that we have the greatest
flexibility and have the cpu-nodes in separate files as you plan. I can
always carry a patch to make juno-r1.dts #include juno.dts if that makes
my life easier ;-) Hopefully the cpufreq and cpuidle stuff will find it
way into mainline in a kernel version or two anyway.

-- 
Tixy

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Jon Medhurst (Tixy)]

On Thu, 2015-05-14 at 14:11 +0100, Liviu Dudau wrote:
> On Thu, May 14, 2015 at 12:04:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
> > > On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> > [...]
> > > > 
> > > > What criteria were used to select the contents of juno-base.dtsi?
> > > > From what I can see, the stuff left out of base is still the same for r0
> > > > and r1 (cpu, pmu, memory, psci!).
> > [...]
> > > 
> > > There are potential differences. Cortex-A53 cluster in r1 has limited
> > > CPUfreq functionality due to a chip errata and there were talks internally
> > > to actually disable it, hence the reason for keeping CPUs outside the
> > > juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
> > > is preparing for the future as well.
> > > 
> > > PMU are linked to the CPUs, hence the reason they stayed. As for the
> > > memory and psci nodes the thinking behind it was mostly to allow for
> > > ACPI to make changes there, but it does look now like retrofitting an
> > > explanation to something that I did not give too much thought at that
> > > moment.
> > 
> > I guess my concern was motivated by the selfish aspect of having to
> > maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq
> > related DT updates) and having to duplicate those in more than one DT,
> > and also having backport DT reorgs like this patch. Of course, none of
> > that should be a consideration in deciding what goes into mainline, I
> > just wanted to make sure there was a reason for the patch.
> 
> You are probably the best placed engineer to offer feedback on these patches,
> as it will affect you in the downstream.
> 
> Given that cpufreq will have limited ranges for Juno r1 (~200MHz spread) and
> that HMP/EAS will not be working optimally on R1, do you still want to see
> the CPUs nodes moved into juno-base.dtsi?

Well, I can only answer that if I knew what the requirements were for
the kernels I maintain, and as I'm unlikely to get any sensible answer,
or one that doesn't change depending on the day of the week or the
person I ask, then I think it probably best that we have the greatest
flexibility and have the cpu-nodes in separate files as you plan. I can
always carry a patch to make juno-r1.dts #include juno.dts if that makes
my life easier ;-) Hopefully the cpufreq and cpuidle stuff will find it
way into mainline in a kernel version or two anyway.

-- 
Tixy

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Sudeep Holla]

On 14/05/15 12:04, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
>> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
>>>
>>> What criteria were used to select the contents of juno-base.dtsi?
>>>  From what I can see, the stuff left out of base is still the same for r0
>>> and r1 (cpu, pmu, memory, psci!).
> [...]
>>
>> There are potential differences. Cortex-A53 cluster in r1 has limited
>> CPUfreq functionality due to a chip errata and there were talks internally
>> to actually disable it, hence the reason for keeping CPUs outside the
>> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
>> is preparing for the future as well.
>>
>> PMU are linked to the CPUs, hence the reason they stayed. As for the
>> memory and psci nodes the thinking behind it was mostly to allow for
>> ACPI to make changes there, but it does look now like retrofitting an
>> explanation to something that I did not give too much thought at that
>> moment.
>
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq

Hopefully not too long :)

> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.
>

But I agree with you to remove duplicates as much as possible. Since
it's not possible to speculate how things will be in future platform,
IMO we can have all the device nodes that are common to both r0 and r1
in juno-base.dtsi for now and move them out as and when required.

Regards,
Sudeep

[PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Sudeep Holla]

On 14/05/15 12:04, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
>> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
>>>
>>> What criteria were used to select the contents of juno-base.dtsi?
>>>  From what I can see, the stuff left out of base is still the same for r0
>>> and r1 (cpu, pmu, memory, psci!).
> [...]
>>
>> There are potential differences. Cortex-A53 cluster in r1 has limited
>> CPUfreq functionality due to a chip errata and there were talks internally
>> to actually disable it, hence the reason for keeping CPUs outside the
>> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
>> is preparing for the future as well.
>>
>> PMU are linked to the CPUs, hence the reason they stayed. As for the
>> memory and psci nodes the thinking behind it was mostly to allow for
>> ACPI to make changes there, but it does look now like retrofitting an
>> explanation to something that I did not give too much thought at that
>> moment.
>
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq

Hopefully not too long :)

> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.
>

But I agree with you to remove duplicates as much as possible. Since
it's not possible to speculate how things will be in future platform,
IMO we can have all the device nodes that are common to both r0 and r1
in juno-base.dtsi for now and move them out as and when required.

Regards,
Sudeep

Re: [PATCH 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts.

[Sudeep Holla]

On 14/05/15 12:04, Jon Medhurst (Tixy) wrote:
> On Thu, 2015-05-14 at 11:30 +0100, Liviu Dudau wrote:
>> On Thu, May 14, 2015 at 10:35:42AM +0100, Jon Medhurst (Tixy) wrote:
> [...]
>>>
>>> What criteria were used to select the contents of juno-base.dtsi?
>>>  From what I can see, the stuff left out of base is still the same for r0
>>> and r1 (cpu, pmu, memory, psci!).
> [...]
>>
>> There are potential differences. Cortex-A53 cluster in r1 has limited
>> CPUfreq functionality due to a chip errata and there were talks internally
>> to actually disable it, hence the reason for keeping CPUs outside the
>> juno-base.dtsi. r2 will have a different set of big CPUs as well, so this
>> is preparing for the future as well.
>>
>> PMU are linked to the CPUs, hence the reason they stayed. As for the
>> memory and psci nodes the thinking behind it was mostly to allow for
>> ACPI to make changes there, but it does look now like retrofitting an
>> explanation to something that I did not give too much thought at that
>> moment.
>
> I guess my concern was motivated by the selfish aspect of having to
> maintain a bunch of out-of-tree Juno patches (like cpuidle and cpufreq

Hopefully not too long :)

> related DT updates) and having to duplicate those in more than one DT,
> and also having backport DT reorgs like this patch. Of course, none of
> that should be a consideration in deciding what goes into mainline, I
> just wanted to make sure there was a reason for the patch.
>

But I agree with you to remove duplicates as much as possible. Since
it's not possible to speculate how things will be in future platform,
IMO we can have all the device nodes that are common to both r0 and r1
in juno-base.dtsi for now and move them out as and when required.

Regards,
Sudeep
--
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

[PATCH 3/5] arm64: Juno: Add memory mapped timer node

[Liviu Dudau]

Juno based boards have a memory mapped timer @ 0x2a810000. This
is disabled on r0 version of the board due to an SoC errata.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 2faa68a..78f8a07 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -2,6 +2,21 @@
 	 *  Devices shared by all Juno boards
 	 */
 
+	memtimer: timer@2a810000 {
+		compatible = "arm,armv7-timer-mem";
+		reg = <0x0 0x2a810000 0x0 0x10000>;
+		clock-frequency = <50000000>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		status = "disabled";
+		frame@2a830000 {
+			frame-number = <1>;
+			interrupts = <0 60 4>;
+			reg = <0x0 0x2a830000 0x0 0x10000>;
+		};
+	};
+
 	gic: interrupt-controller@2c010000 {
 		compatible = "arm,gic-400", "arm,cortex-a15-gic";
 		reg = <0x0 0x2c010000 0 0x1000>,
-- 
2.3.6

[PATCH 3/5] arm64: Juno: Add memory mapped timer node

[Liviu Dudau]

Juno based boards have a memory mapped timer @ 0x2a810000. This
is disabled on r0 version of the board due to an SoC errata.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 2faa68a..78f8a07 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -2,6 +2,21 @@
 	 *  Devices shared by all Juno boards
 	 */
 
+	memtimer: timer at 2a810000 {
+		compatible = "arm,armv7-timer-mem";
+		reg = <0x0 0x2a810000 0x0 0x10000>;
+		clock-frequency = <50000000>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		status = "disabled";
+		frame at 2a830000 {
+			frame-number = <1>;
+			interrupts = <0 60 4>;
+			reg = <0x0 0x2a830000 0x0 0x10000>;
+		};
+	};
+
 	gic: interrupt-controller at 2c010000 {
 		compatible = "arm,gic-400", "arm,cortex-a15-gic";
 		reg = <0x0 0x2c010000 0 0x1000>,
-- 
2.3.6

[PATCH 4/5] arm64: Juno: Add GICv2m support in device tree.

[Liviu Dudau]

Juno contains a GICv2m extension for handling PCIe MSI messages.
Add a node declaring the first frame of the extension.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 35 ++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 78f8a07..e6a4e99 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -23,10 +23,17 @@
 		      <0x0 0x2c02f000 0 0x2000>,
 		      <0x0 0x2c04f000 0 0x2000>,
 		      <0x0 0x2c06f000 0 0x2000>;
-		#address-cells = <0>;
+		#address-cells = <2>;
 		#interrupt-cells = <3>;
+		#size-cells = <2>;
 		interrupt-controller;
 		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
+		ranges = <0 0 0 0x2c1c0000 0 0x40000>;
+		v2m_0: v2m@0 {
+			compatible = "arm,gic-v2m-frame";
+			msi-controller;
+			reg = <0 0 0 0x1000>;
+		};
 	};
 
 	timer {
@@ -122,19 +129,19 @@
 
 		#interrupt-cells = <1>;
 		interrupt-map-mask = <0 0 15>;
-		interrupt-map = <0 0  0 &gic 0  68 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  1 &gic 0  69 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  2 &gic 0  70 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0 0  0 &gic 0 0 0  68 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  1 &gic 0 0 0  69 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  2 &gic 0 0 0  70 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  3 &gic 0 0 0 160 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  4 &gic 0 0 0 161 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  5 &gic 0 0 0 162 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  6 &gic 0 0 0 163 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  7 &gic 0 0 0 164 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  8 &gic 0 0 0 165 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  9 &gic 0 0 0 166 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 10 &gic 0 0 0 167 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 11 &gic 0 0 0 168 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 12 &gic 0 0 0 169 IRQ_TYPE_LEVEL_HIGH>;
 
 		/include/ "juno-motherboard.dtsi"
 	};
-- 
2.3.6

[PATCH 4/5] arm64: Juno: Add GICv2m support in device tree.

[Liviu Dudau]

Juno contains a GICv2m extension for handling PCIe MSI messages.
Add a node declaring the first frame of the extension.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 35 ++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 78f8a07..e6a4e99 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -23,10 +23,17 @@
 		      <0x0 0x2c02f000 0 0x2000>,
 		      <0x0 0x2c04f000 0 0x2000>,
 		      <0x0 0x2c06f000 0 0x2000>;
-		#address-cells = <0>;
+		#address-cells = <2>;
 		#interrupt-cells = <3>;
+		#size-cells = <2>;
 		interrupt-controller;
 		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
+		ranges = <0 0 0 0x2c1c0000 0 0x40000>;
+		v2m_0: v2m at 0 {
+			compatible = "arm,gic-v2m-frame";
+			msi-controller;
+			reg = <0 0 0 0x1000>;
+		};
 	};
 
 	timer {
@@ -122,19 +129,19 @@
 
 		#interrupt-cells = <1>;
 		interrupt-map-mask = <0 0 15>;
-		interrupt-map = <0 0  0 &gic 0  68 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  1 &gic 0  69 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  2 &gic 0  70 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  3 &gic 0 160 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  4 &gic 0 161 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  5 &gic 0 162 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  6 &gic 0 163 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  7 &gic 0 164 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  8 &gic 0 165 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0  9 &gic 0 166 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 10 &gic 0 167 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 11 &gic 0 168 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 12 &gic 0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0 0  0 &gic 0 0 0  68 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  1 &gic 0 0 0  69 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  2 &gic 0 0 0  70 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  3 &gic 0 0 0 160 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  4 &gic 0 0 0 161 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  5 &gic 0 0 0 162 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  6 &gic 0 0 0 163 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  7 &gic 0 0 0 164 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  8 &gic 0 0 0 165 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0  9 &gic 0 0 0 166 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 10 &gic 0 0 0 167 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 11 &gic 0 0 0 168 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 12 &gic 0 0 0 169 IRQ_TYPE_LEVEL_HIGH>;
 
 		/include/ "juno-motherboard.dtsi"
 	};
-- 
2.3.6

[PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Liviu Dudau]

This board is based on Juno r0 with updated Cortex A5x revisions
and board errata fixes. It also contains coherent ThinLinks ports
on the expansion slot that allow for an AXI master on the daughter
card to participate in a coherency domain.

Support for SoC PCIe host bridge will be added as a separate series.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/Makefile    |   2 +-
 arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
 2 files changed, 124 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts

diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
index 301a0da..c5c98b9 100644
--- a/arch/arm64/boot/dts/arm/Makefile
+++ b/arch/arm64/boot/dts/arm/Makefile
@@ -1,5 +1,5 @@
 dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
-dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
 
 always		:= $(dtb-y)
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
new file mode 100644
index 0000000..f6bc073
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -0,0 +1,123 @@
+/*
+ * ARM Ltd. Juno Platform
+ *
+ * Copyright (c) 2015 ARM Ltd.
+ *
+ * This file is licensed under a dual GPLv2 or BSD license.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "ARM Juno development board (r1)";
+	compatible = "arm,juno", "arm,vexpress";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &soc_uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		A57_0: cpu@0 {
+			compatible = "arm,cortex-a57","arm,armv8";
+			reg = <0x0 0x0>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
+		};
+
+		A57_1: cpu@1 {
+			compatible = "arm,cortex-a57","arm,armv8";
+			reg = <0x0 0x1>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
+		};
+
+		A53_0: cpu@100 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x100>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A53_1: cpu@101 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x101>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A53_2: cpu@102 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x102>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A53_3: cpu@103 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x103>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A57_L2: l2-cache0 {
+			compatible = "cache";
+		};
+
+		A53_L2: l2-cache1 {
+			compatible = "cache";
+		};
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		/* last 16MB of the first memory area is reserved for secure world use by firmware */
+		reg = <0x00000000 0x80000000 0x0 0x7f000000>,
+		      <0x00000008 0x80000000 0x1 0x80000000>;
+	};
+
+	pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&A57_0>,
+				     <&A57_1>,
+				     <&A53_0>,
+				     <&A53_1>,
+				     <&A53_2>,
+				     <&A53_3>;
+	};
+
+	#include "juno-base.dtsi"
+
+};
+
+&memtimer {
+	status = "okay";
+};
-- 
2.3.6

[PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Liviu Dudau]

This board is based on Juno r0 with updated Cortex A5x revisions
and board errata fixes. It also contains coherent ThinLinks ports
on the expansion slot that allow for an AXI master on the daughter
card to participate in a coherency domain.

Support for SoC PCIe host bridge will be added as a separate series.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/boot/dts/arm/Makefile    |   2 +-
 arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
 2 files changed, 124 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts

diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
index 301a0da..c5c98b9 100644
--- a/arch/arm64/boot/dts/arm/Makefile
+++ b/arch/arm64/boot/dts/arm/Makefile
@@ -1,5 +1,5 @@
 dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
-dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
+dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
 
 always		:= $(dtb-y)
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
new file mode 100644
index 0000000..f6bc073
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -0,0 +1,123 @@
+/*
+ * ARM Ltd. Juno Platform
+ *
+ * Copyright (c) 2015 ARM Ltd.
+ *
+ * This file is licensed under a dual GPLv2 or BSD license.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "ARM Juno development board (r1)";
+	compatible = "arm,juno", "arm,vexpress";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &soc_uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		A57_0: cpu at 0 {
+			compatible = "arm,cortex-a57","arm,armv8";
+			reg = <0x0 0x0>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
+		};
+
+		A57_1: cpu at 1 {
+			compatible = "arm,cortex-a57","arm,armv8";
+			reg = <0x0 0x1>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A57_L2>;
+		};
+
+		A53_0: cpu at 100 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x100>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A53_1: cpu at 101 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x101>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A53_2: cpu at 102 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x102>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A53_3: cpu at 103 {
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x0 0x103>;
+			device_type = "cpu";
+			enable-method = "psci";
+			next-level-cache = <&A53_L2>;
+		};
+
+		A57_L2: l2-cache0 {
+			compatible = "cache";
+		};
+
+		A53_L2: l2-cache1 {
+			compatible = "cache";
+		};
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		/* last 16MB of the first memory area is reserved for secure world use by firmware */
+		reg = <0x00000000 0x80000000 0x0 0x7f000000>,
+		      <0x00000008 0x80000000 0x1 0x80000000>;
+	};
+
+	pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&A57_0>,
+				     <&A57_1>,
+				     <&A53_0>,
+				     <&A53_1>,
+				     <&A53_2>,
+				     <&A53_3>;
+	};
+
+	#include "juno-base.dtsi"
+
+};
+
+&memtimer {
+	status = "okay";
+};
-- 
2.3.6

Re: [PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Jon Medhurst (Tixy)]

On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> This board is based on Juno r0 with updated Cortex A5x revisions
> and board errata fixes. It also contains coherent ThinLinks ports
> on the expansion slot that allow for an AXI master on the daughter
> card to participate in a coherency domain.
> 
> Support for SoC PCIe host bridge will be added as a separate series.
> 
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  arch/arm64/boot/dts/arm/Makefile    |   2 +-
>  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 124 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> 
> diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> index 301a0da..c5c98b9 100644
> --- a/arch/arm64/boot/dts/arm/Makefile
> +++ b/arch/arm64/boot/dts/arm/Makefile
> @@ -1,5 +1,5 @@
>  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
>  
>  always		:= $(dtb-y)
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> new file mode 100644
> index 0000000..f6bc073
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -0,0 +1,123 @@
> +/*
> + * ARM Ltd. Juno Platform
> + *
> + * Copyright (c) 2015 ARM Ltd.
> + *
> + * This file is licensed under a dual GPLv2 or BSD license.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "ARM Juno development board (r1)";
> +	compatible = "arm,juno", "arm,vexpress";

Is there scope for adding "arm,juno-r1" to the front of that list?
Reason I ask, is that I can't help but think [1] that userside code
(like Android) which wants to select device-specific configuration,
should use something like the devices compatible string rather than what
they currently propose [2].
 
[1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
[2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html

-- 
Tixy

[PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Jon Medhurst (Tixy)]

On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> This board is based on Juno r0 with updated Cortex A5x revisions
> and board errata fixes. It also contains coherent ThinLinks ports
> on the expansion slot that allow for an AXI master on the daughter
> card to participate in a coherency domain.
> 
> Support for SoC PCIe host bridge will be added as a separate series.
> 
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  arch/arm64/boot/dts/arm/Makefile    |   2 +-
>  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 124 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> 
> diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> index 301a0da..c5c98b9 100644
> --- a/arch/arm64/boot/dts/arm/Makefile
> +++ b/arch/arm64/boot/dts/arm/Makefile
> @@ -1,5 +1,5 @@
>  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
>  
>  always		:= $(dtb-y)
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> new file mode 100644
> index 0000000..f6bc073
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -0,0 +1,123 @@
> +/*
> + * ARM Ltd. Juno Platform
> + *
> + * Copyright (c) 2015 ARM Ltd.
> + *
> + * This file is licensed under a dual GPLv2 or BSD license.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "ARM Juno development board (r1)";
> +	compatible = "arm,juno", "arm,vexpress";

Is there scope for adding "arm,juno-r1" to the front of that list?
Reason I ask, is that I can't help but think [1] that userside code
(like Android) which wants to select device-specific configuration,
should use something like the devices compatible string rather than what
they currently propose [2].
 
[1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
[2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html

-- 
Tixy

Re: [PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Liviu Dudau]

On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > This board is based on Juno r0 with updated Cortex A5x revisions
> > and board errata fixes. It also contains coherent ThinLinks ports
> > on the expansion slot that allow for an AXI master on the daughter
> > card to participate in a coherency domain.
> > 
> > Support for SoC PCIe host bridge will be added as a separate series.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  arch/arm64/boot/dts/arm/Makefile    |   2 +-
> >  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> >  2 files changed, 124 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > 
> > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > index 301a0da..c5c98b9 100644
> > --- a/arch/arm64/boot/dts/arm/Makefile
> > +++ b/arch/arm64/boot/dts/arm/Makefile
> > @@ -1,5 +1,5 @@
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> >  
> >  always		:= $(dtb-y)
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > new file mode 100644
> > index 0000000..f6bc073
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -0,0 +1,123 @@
> > +/*
> > + * ARM Ltd. Juno Platform
> > + *
> > + * Copyright (c) 2015 ARM Ltd.
> > + *
> > + * This file is licensed under a dual GPLv2 or BSD license.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	model = "ARM Juno development board (r1)";
> > +	compatible = "arm,juno", "arm,vexpress";
> 
> Is there scope for adding "arm,juno-r1" to the front of that list?
> Reason I ask, is that I can't help but think [1] that userside code
> (like Android) which wants to select device-specific configuration,
> should use something like the devices compatible string rather than what
> they currently propose [2].

Sure, I can do that for the next revision of the patch.

Best regards,
Liviu

>  
> [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
> 
> -- 
> Tixy
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Liviu Dudau]

On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > This board is based on Juno r0 with updated Cortex A5x revisions
> > and board errata fixes. It also contains coherent ThinLinks ports
> > on the expansion slot that allow for an AXI master on the daughter
> > card to participate in a coherency domain.
> > 
> > Support for SoC PCIe host bridge will be added as a separate series.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  arch/arm64/boot/dts/arm/Makefile    |   2 +-
> >  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> >  2 files changed, 124 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > 
> > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > index 301a0da..c5c98b9 100644
> > --- a/arch/arm64/boot/dts/arm/Makefile
> > +++ b/arch/arm64/boot/dts/arm/Makefile
> > @@ -1,5 +1,5 @@
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> >  
> >  always		:= $(dtb-y)
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > new file mode 100644
> > index 0000000..f6bc073
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -0,0 +1,123 @@
> > +/*
> > + * ARM Ltd. Juno Platform
> > + *
> > + * Copyright (c) 2015 ARM Ltd.
> > + *
> > + * This file is licensed under a dual GPLv2 or BSD license.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	model = "ARM Juno development board (r1)";
> > +	compatible = "arm,juno", "arm,vexpress";
> 
> Is there scope for adding "arm,juno-r1" to the front of that list?
> Reason I ask, is that I can't help but think [1] that userside code
> (like Android) which wants to select device-specific configuration,
> should use something like the devices compatible string rather than what
> they currently propose [2].

Sure, I can do that for the next revision of the patch.

Best regards,
Liviu

>  
> [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
> 
> -- 
> Tixy
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Mark Rutland]

On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > This board is based on Juno r0 with updated Cortex A5x revisions
> > and board errata fixes. It also contains coherent ThinLinks ports
> > on the expansion slot that allow for an AXI master on the daughter
> > card to participate in a coherency domain.
> > 
> > Support for SoC PCIe host bridge will be added as a separate series.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  arch/arm64/boot/dts/arm/Makefile    |   2 +-
> >  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> >  2 files changed, 124 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > 
> > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > index 301a0da..c5c98b9 100644
> > --- a/arch/arm64/boot/dts/arm/Makefile
> > +++ b/arch/arm64/boot/dts/arm/Makefile
> > @@ -1,5 +1,5 @@
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> >  
> >  always		:= $(dtb-y)
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > new file mode 100644
> > index 0000000..f6bc073
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -0,0 +1,123 @@
> > +/*
> > + * ARM Ltd. Juno Platform
> > + *
> > + * Copyright (c) 2015 ARM Ltd.
> > + *
> > + * This file is licensed under a dual GPLv2 or BSD license.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	model = "ARM Juno development board (r1)";
> > +	compatible = "arm,juno", "arm,vexpress";
> 
> Is there scope for adding "arm,juno-r1" to the front of that list?
> Reason I ask, is that I can't help but think [1] that userside code
> (like Android) which wants to select device-specific configuration,
> should use something like the devices compatible string rather than what
> they currently propose [2].

> [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html

Ideally, userspace shouldn't need to know what specific device they're
running on (though obviously there will always be cases...). To that
end, it would be interesting to know what this data would be used for.
If it's just a string for some "About device" menu, the model string
should be ok.

I'm a bit lost with the suggestion in [2]. It doesn't seem to have
anything to do with firmware, though perhaps I'm missing something? What
information are they trying to get at?

Thanks,
Mark.

[PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Mark Rutland]

On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > This board is based on Juno r0 with updated Cortex A5x revisions
> > and board errata fixes. It also contains coherent ThinLinks ports
> > on the expansion slot that allow for an AXI master on the daughter
> > card to participate in a coherency domain.
> > 
> > Support for SoC PCIe host bridge will be added as a separate series.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  arch/arm64/boot/dts/arm/Makefile    |   2 +-
> >  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> >  2 files changed, 124 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > 
> > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > index 301a0da..c5c98b9 100644
> > --- a/arch/arm64/boot/dts/arm/Makefile
> > +++ b/arch/arm64/boot/dts/arm/Makefile
> > @@ -1,5 +1,5 @@
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> >  
> >  always		:= $(dtb-y)
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > new file mode 100644
> > index 0000000..f6bc073
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -0,0 +1,123 @@
> > +/*
> > + * ARM Ltd. Juno Platform
> > + *
> > + * Copyright (c) 2015 ARM Ltd.
> > + *
> > + * This file is licensed under a dual GPLv2 or BSD license.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	model = "ARM Juno development board (r1)";
> > +	compatible = "arm,juno", "arm,vexpress";
> 
> Is there scope for adding "arm,juno-r1" to the front of that list?
> Reason I ask, is that I can't help but think [1] that userside code
> (like Android) which wants to select device-specific configuration,
> should use something like the devices compatible string rather than what
> they currently propose [2].

> [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html

Ideally, userspace shouldn't need to know what specific device they're
running on (though obviously there will always be cases...). To that
end, it would be interesting to know what this data would be used for.
If it's just a string for some "About device" menu, the model string
should be ok.

I'm a bit lost with the suggestion in [2]. It doesn't seem to have
anything to do with firmware, though perhaps I'm missing something? What
information are they trying to get at?

Thanks,
Mark.

Re: [PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Mark Rutland]

On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > This board is based on Juno r0 with updated Cortex A5x revisions
> > and board errata fixes. It also contains coherent ThinLinks ports
> > on the expansion slot that allow for an AXI master on the daughter
> > card to participate in a coherency domain.
> > 
> > Support for SoC PCIe host bridge will be added as a separate series.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
> > ---
> >  arch/arm64/boot/dts/arm/Makefile    |   2 +-
> >  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> >  2 files changed, 124 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > 
> > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > index 301a0da..c5c98b9 100644
> > --- a/arch/arm64/boot/dts/arm/Makefile
> > +++ b/arch/arm64/boot/dts/arm/Makefile
> > @@ -1,5 +1,5 @@
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> >  
> >  always		:= $(dtb-y)
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > new file mode 100644
> > index 0000000..f6bc073
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -0,0 +1,123 @@
> > +/*
> > + * ARM Ltd. Juno Platform
> > + *
> > + * Copyright (c) 2015 ARM Ltd.
> > + *
> > + * This file is licensed under a dual GPLv2 or BSD license.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	model = "ARM Juno development board (r1)";
> > +	compatible = "arm,juno", "arm,vexpress";
> 
> Is there scope for adding "arm,juno-r1" to the front of that list?
> Reason I ask, is that I can't help but think [1] that userside code
> (like Android) which wants to select device-specific configuration,
> should use something like the devices compatible string rather than what
> they currently propose [2].

> [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html

Ideally, userspace shouldn't need to know what specific device they're
running on (though obviously there will always be cases...). To that
end, it would be interesting to know what this data would be used for.
If it's just a string for some "About device" menu, the model string
should be ok.

I'm a bit lost with the suggestion in [2]. It doesn't seem to have
anything to do with firmware, though perhaps I'm missing something? What
information are they trying to get at?

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

Re: [PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Jon Medhurst (Tixy)]

On Thu, 2015-05-14 at 15:18 +0100, Mark Rutland wrote:
> On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > > This board is based on Juno r0 with updated Cortex A5x revisions
> > > and board errata fixes. It also contains coherent ThinLinks ports
> > > on the expansion slot that allow for an AXI master on the daughter
> > > card to participate in a coherency domain.
> > > 
> > > Support for SoC PCIe host bridge will be added as a separate series.
> > > 
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > > ---
> > >  arch/arm64/boot/dts/arm/Makefile    |   2 +-
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 124 insertions(+), 1 deletion(-)
> > >  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > > 
> > > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > > index 301a0da..c5c98b9 100644
> > > --- a/arch/arm64/boot/dts/arm/Makefile
> > > +++ b/arch/arm64/boot/dts/arm/Makefile
> > > @@ -1,5 +1,5 @@
> > >  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> > >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> > >  
> > >  always		:= $(dtb-y)
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > new file mode 100644
> > > index 0000000..f6bc073
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -0,0 +1,123 @@
> > > +/*
> > > + * ARM Ltd. Juno Platform
> > > + *
> > > + * Copyright (c) 2015 ARM Ltd.
> > > + *
> > > + * This file is licensed under a dual GPLv2 or BSD license.
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +
> > > +/ {
> > > +	model = "ARM Juno development board (r1)";
> > > +	compatible = "arm,juno", "arm,vexpress";
> > 
> > Is there scope for adding "arm,juno-r1" to the front of that list?
> > Reason I ask, is that I can't help but think [1] that userside code
> > (like Android) which wants to select device-specific configuration,
> > should use something like the devices compatible string rather than what
> > they currently propose [2].
> 
> > [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> > [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
> 
> Ideally, userspace shouldn't need to know what specific device they're
> running on (though obviously there will always be cases...). To that
> end, it would be interesting to know what this data would be used for.
> If it's just a string for some "About device" menu, the model string
> should be ok.

The 'hardware name' is used to selected the correct init scripts, fstab,
userside graphics/audio drivers for the device.

> I'm a bit lost with the suggestion in [2]. It doesn't seem to have
> anything to do with firmware, though perhaps I'm missing something?

That was my reaction. Before they were parsing /proc/cpuinfo to get the
device name. But that information got removed.

-- 
Tixy

[PATCH 5/5] arm64: Add DT support for Juno r1 board.

[Jon Medhurst (Tixy)]

On Thu, 2015-05-14 at 15:18 +0100, Mark Rutland wrote:
> On Thu, May 14, 2015 at 03:07:31PM +0100, Jon Medhurst (Tixy) wrote:
> > On Wed, 2015-05-13 at 18:11 +0100, Liviu Dudau wrote:
> > > This board is based on Juno r0 with updated Cortex A5x revisions
> > > and board errata fixes. It also contains coherent ThinLinks ports
> > > on the expansion slot that allow for an AXI master on the daughter
> > > card to participate in a coherency domain.
> > > 
> > > Support for SoC PCIe host bridge will be added as a separate series.
> > > 
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > > ---
> > >  arch/arm64/boot/dts/arm/Makefile    |   2 +-
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 123 ++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 124 insertions(+), 1 deletion(-)
> > >  create mode 100644 arch/arm64/boot/dts/arm/juno-r1.dts
> > > 
> > > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile
> > > index 301a0da..c5c98b9 100644
> > > --- a/arch/arm64/boot/dts/arm/Makefile
> > > +++ b/arch/arm64/boot/dts/arm/Makefile
> > > @@ -1,5 +1,5 @@
> > >  dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> > > -dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb
> > > +dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
> > >  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
> > >  
> > >  always		:= $(dtb-y)
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > new file mode 100644
> > > index 0000000..f6bc073
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -0,0 +1,123 @@
> > > +/*
> > > + * ARM Ltd. Juno Platform
> > > + *
> > > + * Copyright (c) 2015 ARM Ltd.
> > > + *
> > > + * This file is licensed under a dual GPLv2 or BSD license.
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +
> > > +/ {
> > > +	model = "ARM Juno development board (r1)";
> > > +	compatible = "arm,juno", "arm,vexpress";
> > 
> > Is there scope for adding "arm,juno-r1" to the front of that list?
> > Reason I ask, is that I can't help but think [1] that userside code
> > (like Android) which wants to select device-specific configuration,
> > should use something like the devices compatible string rather than what
> > they currently propose [2].
> 
> > [1] https://lists.linaro.org/pipermail/linaro-android/2015-April/002743.html
> > [2] https://lists.linaro.org/pipermail/linaro-android/2015-April/002742.html
> 
> Ideally, userspace shouldn't need to know what specific device they're
> running on (though obviously there will always be cases...). To that
> end, it would be interesting to know what this data would be used for.
> If it's just a string for some "About device" menu, the model string
> should be ok.

The 'hardware name' is used to selected the correct init scripts, fstab,
userside graphics/audio drivers for the device.

> I'm a bit lost with the suggestion in [2]. It doesn't seem to have
> anything to do with firmware, though perhaps I'm missing something?

That was my reaction. Before they were parsing /proc/cpuinfo to get the
device name. But that information got removed.

-- 
Tixy