[PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS files.
It also adds new board files for newer Overdrive and Linaro 96boards (Husky)
platforms.

Thanks,
Suravee

Brijesh Singh (2):
  dtb: amd: Fix GICv2 hypervisor and virtual interface sizes
  dtb: amd: Add KCS device tree node

Suravee Suthikulpanit (10):
  MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
  dtb: amd: Fix DMA ranges in device tree
  dtb: amd: Fix typo in SPI device nodes
  dtb: amd: Misc changes for I2C device nodes
  dtb: amd: Misc changes for SATA device tree nodes
  dtb: amd: Misc changes for GPIO devices
  dtb: amd: Add PERF CCN-504 device tree node
  dtb: amd: Add PCIe SMMU device tree node
  dtb: amd: Add support for new AMD Overdrive boards
  dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition
    Server board

Tom Lendacky (1):
  dtb: amd: Add AMD XGBE device tree file

 MAINTAINERS                                      |   9 ++
 arch/arm64/boot/dts/amd/Makefile                 |   4 +-
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts |  87 +++++++++++++++
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts |  91 ++++++++++++++++
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi     | 128 ++++++++++++++++++++---
 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi  | 117 +++++++++++++++++++++
 arch/arm64/boot/dts/amd/husky.dts                |  83 +++++++++++++++
 7 files changed, 505 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi

4 more lines

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Adding maintainers for AMD Seattle device tree.

Signed-off-by: Brijesh Singh <redacted>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a2956eb..8179121 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

@@ -669,6 +669,14 @@ F:	drivers/gpu/drm/radeon/radeon_kfd.c
 F:	drivers/gpu/drm/radeon/radeon_kfd.h
 F:	include/uapi/linux/kfd_ioctl.h
 
+AMD SEATTLE DEVICE TREE SUPPORT
+M:	Brijesh Singh <brijeshkumar.singh@amd.com>
+M:	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+S:	Supported
+M:	Tom Lendacky <thomas.lendacky@amd.com>
+S:	Supported
+F:	arch/arm64/boot/dts/amd/
+
 AMD XGBE DRIVER
 M:	Tom Lendacky <thomas.lendacky@amd.com>
 L:	netdev at vger.kernel.org

-- 
2.5.0

From: Brijesh Singh <redacted>

This patch fixes incorrect sizes of the GICv2 device tree node.
This has triggered error message when booting Xen hypervisor.

Signed-off-by: Brijesh Singh <redacted>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..fdd0c96 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -18,8 +18,8 @@
 		#size-cells = <2>;
 		reg = <0x0 0xe1110000 0 0x1000>,
 		      <0x0 0xe112f000 0 0x2000>,
-		      <0x0 0xe1140000 0 0x10000>,
-		      <0x0 0xe1160000 0 0x10000>;
+		      <0x0 0xe1140000 0 0x2000>,
+		      <0x0 0xe1160000 0 0x2000>;
 		interrupts = <1 9 0xf04>;
 		ranges = <0 0 0 0xe1100000 0 0x100000>;
 		v2m0: v2m at e0080000 {

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add new GPIO device nodes and fix clock on gpio0.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 49 +++++++++++++++++++++++++---
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 9f59381..ba455d1 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -129,7 +129,7 @@
 			#size-cells = <0>;
 		};
 
-		gpio0: gpio at e1040000 {
+		gpio0: gpio at e1040000 { /* Not available to OS for B0 */
 			status = "disabled";
 			compatible = "arm,pl061", "arm,primecell";
 			#gpio-cells = <2>;

@@ -138,18 +138,59 @@
 			interrupts = <0 359 4>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
 			clock-names = "apb_pclk";
 		};
 
-		gpio1: gpio at e1050000 {
+		gpio1: gpio at e1050000 { /* [0:7] */
 			status = "disabled";
 			compatible = "arm,pl061", "arm,primecell";
 			#gpio-cells = <2>;
 			reg = <0 0xe1050000 0 0x1000>;
 			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
 			interrupts = <0 358 4>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio2: gpio at e0020000 { /* [8:15] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0020000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 366 4>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio3: gpio at e0030000 { /* [16:23] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0030000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 365 4>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio4: gpio at e0080000 { /* [24] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0080000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 361 4>;
+			clocks = <&miscclk_250mhz>;
 			clock-names = "apb_pclk";
 		};
 

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add new SATA1 device node, and fix the register range size of SATA0.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 4be36fd..9f59381 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -66,12 +66,22 @@
 
 		sata0: sata at e0300000 {
 			compatible = "snps,dwc-ahci";
-			reg = <0 0xe0300000 0 0x800>;
+			reg = <0 0xe0300000 0 0xf0000>;
 			interrupts = <0 355 4>;
 			clocks = <&sataclk_333mhz>;
 			dma-coherent;
 		};
 
+		/* This is for Rev B only */
+		sata1: sata at e0d00000 {
+			status = "disabled";
+			compatible = "snps,dwc-ahci";
+			reg = <0 0xe0d00000 0 0xf0000>;
+			interrupts = <0 354 4>;
+			clocks = <&sataclk_333mhz>;
+			dma-coherent;
+		};
+
 		i2c0: i2c at e1000000 {
 			status = "disabled";
 			compatible = "snps,designware-i2c";

-- 
2.5.0

From: Brijesh Singh <redacted>

Add KCS device node to support IPMI solution on Overdrive
system.

Signed-off-by: Brijesh Singh <redacted>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index c5461b2..a7fc059 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -236,5 +236,16 @@
 			reg = <0x0 0xe8000000 0 0x1000000>;
 			interrupts = <0 380 4>;
 		};
+
+		ipmi_kcs: kcs at e0010000 {
+			status = "disabled";
+			compatible = "ipmi-kcs";
+			device_type = "ipmi";
+			reg = <0x0 0xe0010000 0 0x8>;
+			interrupts = <0 389 4>;
+			interrupt-names = "ipmi_kcs";
+			reg-size = <1>;
+			reg-spacing = <4>;
+		};
 	};
 };

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add PERF CCN-504 device tree node.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index ba455d1..c5461b2 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -229,5 +229,12 @@
 				/* 64-bit MMIO (size= 124G) */
 				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
 		};
+
+		/* Perf CCN504 PMU */
+		ccn: ccn at 0xe8000000 {
+			compatible = "arm,ccn-504";
+			reg = <0x0 0xe8000000 0 0x1000000>;
+			interrupts = <0 380 4>;
+		};
 	};
 };

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add device tree file for AMD/Linaro 96Boards Enterprise Edition Server
(Husky) Board. This is based on the AMD Seattle Rev.B0 system

Signed-off-by: Leo Duran <redacted>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/Makefile  |  3 +-
 arch/arm64/boot/dts/amd/husky.dts | 83 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 85 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
index db03293..ba84770 100644
--- a/arch/arm64/boot/dts/amd/Makefile
+++ b/arch/arm64/boot/dts/amd/Makefile

@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb \
-			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
+			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb \
+			husky.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)

diff --git a/arch/arm64/boot/dts/amd/husky.dts b/arch/arm64/boot/dts/amd/husky.dts
new file mode 100644
index 0000000..1381d4b
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/husky.dts

@@ -0,0 +1,83 @@
+/*
+ * DTS file for AMD/Linaro 96Boards Enterprise Edition Server (Husky) Board
+ * Note: Based-on AMD Seattle Rev.B0
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "Linaro 96Boards Enterprise Edition Server (Husky) Board";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add PCIe SMMU device tree node for AMD Seattle SOC.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a7fc059..bfccfea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -210,6 +210,7 @@
 			device_type = "pci";
 			bus-range = <0 0x7f>;
 			msi-parent = <&v2m0>;
+			#stream-id-cells = <16>;
 			reg = <0 0xf0000000 0 0x10000000>;
 
 			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;

@@ -230,6 +231,28 @@
 				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
 		};
 
+		pcie0_smmu: smmu at e0a00000 {
+			 compatible = "arm,mmu-401";
+			 reg = <0 0xe0a00000 0 0x10000>;
+			 #global-interrupts = <1>;
+			 interrupts = /* Uses combined intr for both
+				       * global and context
+				       */
+				      <0 333 4>,
+				      <0 333 4>;
+			/* Note:
+			 * SID[2:0]  = PCIe function number
+			 * SID[7:3]  = PCIe device number
+			 * SID[14:8] = PCIe bus number
+			 */
+			 mmu-masters = <&pcie0
+				/* 1:00:[0,3] */ 256 257 258 259
+				/* 2:00:[0,3] */ 512 513 514 515
+				/* 3:00:[0,3] */ 768 769 770 771
+				/* 4:00:[0,3] */ 1024 1025 1026 1027
+			 >;
+		 };
+
 		/* Perf CCN504 PMU */
 		ccn: ccn at 0xe8000000 {
 			compatible = "arm,ccn-504";

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add device tree files for AMD Overdrive boards which comes with
AMD Seattle Revision B0 and B1 SOCs.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/Makefile                 |  3 +-
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts | 87 ++++++++++++++++++++++
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts | 91 ++++++++++++++++++++++++
 3 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts

diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
index cfdf701..db03293 100644
--- a/arch/arm64/boot/dts/amd/Makefile
+++ b/arch/arm64/boot/dts/amd/Makefile

@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb
+dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb \
+			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)

diff --git a/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
new file mode 100644
index 0000000..8e3074a
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts

@@ -0,0 +1,87 @@
+/*
+ * DTS file for AMD Seattle Overdrive Development Board
+ * Note: For Seattle Rev.B0
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "AMD Seattle (Rev.B0) Development Board (Overdrive)";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&ipmi_kcs {
+	status = "ok";
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};

diff --git a/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
new file mode 100644
index 0000000..ed5e043
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts

@@ -0,0 +1,91 @@
+/*
+ * DTS file for AMD Seattle Overdrive Development Board
+ * Note: For Seattle Rev.B1
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "AMD Seattle (Rev.B1) Development Board (Overdrive)";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&sata1 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&ipmi_kcs {
+	status = "ok";
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};

-- 
2.5.0

From: Tom Lendacky <thomas.lendacky@amd.com>

Add AMD XGBE device tree file, which is available in AMD Seattle RevB.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 MAINTAINERS                                     |   1 +
 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi | 117 ++++++++++++++++++++++++
 2 files changed, 118 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 8179121..d525585 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

@@ -682,6 +682,7 @@ M:	Tom Lendacky <thomas.lendacky@amd.com>
 L:	netdev at vger.kernel.org
 S:	Supported
 F:	drivers/net/ethernet/amd/xgbe/
+F:	arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
 
 AMS (Apple Motion Sensor) DRIVER
 M:	Michael Hanselmann <linux-kernel@hansmi.ch>

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi
new file mode 100644
index 0000000..8e86319
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi

@@ -0,0 +1,117 @@
+/*
+ * DTS file for AMD Seattle XGBE (RevB)
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+	xgmacclk0_dma_250mhz: clk250mhz_0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk0_dma_250mhz";
+	};
+
+	xgmacclk0_ptp_250mhz: clk250mhz_1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk0_ptp_250mhz";
+	};
+
+	xgmacclk1_dma_250mhz: clk250mhz_2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk1_dma_250mhz";
+	};
+
+	xgmacclk1_ptp_250mhz: clk250mhz_3 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk1_ptp_250mhz";
+	};
+
+	xgmac0: xgmac at e0700000 {
+		compatible = "amd,xgbe-seattle-v1a";
+		reg = <0 0xe0700000 0 0x80000>,
+		      <0 0xe0780000 0 0x80000>,
+		      <0 0xe1240800 0 0x00400>, /* SERDES RX/TX0 */
+		      <0 0xe1250000 0 0x00060>, /* SERDES IR 1/2 */
+		      <0 0xe12500f8 0 0x00004>; /* SERDES IR 2/2 */
+		interrupts = <0 325 4>,
+			     <0 346 1>, <0 347 1>, <0 348 1>, <0 349 1>,
+			     <0 323 4>;
+		amd,per-channel-interrupt;
+		amd,speed-set = <0>;
+		amd,serdes-blwc = <1>, <1>, <0>;
+		amd,serdes-cdr-rate = <2>, <2>, <7>;
+		amd,serdes-pq-skew = <10>, <10>, <18>;
+		amd,serdes-tx-amp = <0>, <0>, <0>;
+		amd,serdes-dfe-tap-config = <3>, <3>, <3>;
+		amd,serdes-dfe-tap-enable = <0>, <0>, <7>;
+		mac-address = [ 02 A1 A2 A3 A4 A5 ];
+		clocks = <&xgmacclk0_dma_250mhz>, <&xgmacclk0_ptp_250mhz>;
+		clock-names = "dma_clk", "ptp_clk";
+		phy-mode = "xgmii";
+		#stream-id-cells = <16>;
+		dma-coherent;
+	};
+
+	xgmac1: xgmac at e0900000 {
+		compatible = "amd,xgbe-seattle-v1a";
+		reg = <0 0xe0900000 0 0x80000>,
+		      <0 0xe0980000 0 0x80000>,
+		      <0 0xe1240c00 0 0x00400>, /* SERDES RX/TX1 */
+		      <0 0xe1250080 0 0x00060>, /* SERDES IR 1/2 */
+		      <0 0xe12500fc 0 0x00004>; /* SERDES IR 2/2 */
+		interrupts = <0 324 4>,
+			     <0 341 1>, <0 342 1>, <0 343 1>, <0 344 1>,
+			     <0 322 4>;
+		amd,per-channel-interrupt;
+		amd,speed-set = <0>;
+		amd,serdes-blwc = <1>, <1>, <0>;
+		amd,serdes-cdr-rate = <2>, <2>, <7>;
+		amd,serdes-pq-skew = <10>, <10>, <18>;
+		amd,serdes-tx-amp = <0>, <0>, <0>;
+		amd,serdes-dfe-tap-config = <3>, <3>, <3>;
+		amd,serdes-dfe-tap-enable = <0>, <0>, <7>;
+		mac-address = [ 02 B1 B2 B3 B4 B5 ];
+		clocks = <&xgmacclk1_dma_250mhz>, <&xgmacclk1_ptp_250mhz>;
+		clock-names = "dma_clk", "ptp_clk";
+		phy-mode = "xgmii";
+		#stream-id-cells = <16>;
+		dma-coherent;
+	};
+
+	xgmac0_smmu: smmu at e0600000 {
+		 compatible = "arm,mmu-401";
+		 reg = <0 0xe0600000 0 0x10000>;
+		 #global-interrupts = <1>;
+		 interrupts = /* Uses combined intr for both
+			       * global and context
+			       */
+			      <0 336 4>,
+			      <0 336 4>;
+
+		 mmu-masters = <&xgmac0
+			  0  1  2  3  4  5  6  7
+			 16 17 18 19 20 21 22 23
+		 >;
+	 };
+
+	 xgmac1_smmu: smmu at e0800000 {
+		 compatible = "arm,mmu-401";
+		 reg = <0 0xe0800000 0 0x10000>;
+		 #global-interrupts = <1>;
+		 interrupts = /* Uses combined intr for both
+			       * global and context
+			       */
+			      <0 335 4>,
+			      <0 335 4>;
+
+		 mmu-masters = <&xgmac1
+			  0  1  2  3  4  5  6  7
+			 16 17 18 19 20 21 22 23
+		 >;
+	 };

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add new i2c1 device node, and fix the incorrect clock frequency.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index c7c759a..4be36fd 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -77,7 +77,15 @@
 			compatible = "snps,designware-i2c";
 			reg = <0 0xe1000000 0 0x1000>;
 			interrupts = <0 357 4>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
+		};
+
+		i2c1: i2c at e0050000 {
+			status = "disabled";
+			compatible = "snps,designware-i2c";
+			reg = <0 0xe0050000 0 0x1000>;
+			interrupts = <0 340 4>;
+			clocks = <&miscclk_250mhz>;
 		};
 
 		serial0: serial at e1010000 {

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Remove invalid entry in the SPI device nodes.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 5c73117..c7c759a 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -91,7 +91,6 @@
 		spi0: ssp at e1020000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-			#gpio-cells = <2>;
 			reg = <0 0xe1020000 0 0x1000>;
 			spi-controller;
 			interrupts = <0 330 4>;

@@ -102,7 +101,6 @@
 		spi1: ssp at e1030000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-			#gpio-cells = <2>;
 			reg = <0 0xe1030000 0 0x1000>;
 			spi-controller;
 			interrupts = <0 329 4>;

-- 
2.5.0

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Fix DMA ranges of smb0 and pcie0 nodes in AMD Seattle SOC.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index fdd0c96..5c73117 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -55,8 +55,12 @@
 		#size-cells = <2>;
 		ranges;
 
-		/* DDR range is 40-bit addressing */
-		dma-ranges = <0x80 0x0 0x80 0x0 0x7f 0xffffffff>;
+		/*
+		 * dma-ranges is 40-bit address space containing:
+		 * - GICv2m MSI register is at 0xe0080000
+		 * - DRAM range [0x8000000000 to 0xffffffffff]
+		 */
+		dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x0>;
 
 		/include/ "amd-seattle-clks.dtsi"
 

@@ -159,7 +163,7 @@
 				<0x1000 0x0 0x0 0x4 &gic0 0x0 0x0 0x0 0x123 0x1>;
 
 			dma-coherent;
-			dma-ranges = <0x43000000 0x80 0x0 0x80 0x0 0x7f 0xffffffff>;
+			dma-ranges = <0x43000000 0x0 0x0 0x0 0x0 0x100 0x0>;
 			ranges =
 				/* I/O Memory (size=64K) */
 				<0x01000000 0x00 0x00000000 0x00 0xefff0000 0x00 0x00010000>,

-- 
2.5.0

* Suravee Suthikulpanit [off-list ref] [2016-01-27 15:11]:

Just a minor comment, but you have a duplicate "S: Supported" line.

-- 
Martin Michlmayr
http://www.cyrius.com/

On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:

6 more quoted lines

This doesn't look right to me.

I didn't think that RID->SID mapping was actually defined by any
binding, so (how) are these numbers used?

I'm uncomfortable with this, given we should be moving towards the
generic IOMMU binding (and then we'd use the iommu-map binding [1] for
this).

Will, Robin, thoughts?

Mark.

[1] https://lkml.org/lkml/2015/7/23/561

On Thu, Jan 28, 2016 at 11:14:53AM +0000, Mark Rutland wrote:

On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add PCIe SMMU device tree node for AMD Seattle SOC.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a7fc059..bfccfea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -210,6 +210,7 @@
 			device_type = "pci";
 			bus-range = <0 0x7f>;
 			msi-parent = <&v2m0>;
+			#stream-id-cells = <16>;
 			reg = <0 0xf0000000 0 0x10000000>;
 
 			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;

@@ -230,6 +231,28 @@
 				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
 		};
 
+		pcie0_smmu: smmu at e0a00000 {
+			 compatible = "arm,mmu-401";
+			 reg = <0 0xe0a00000 0 0x10000>;
+			 #global-interrupts = <1>;
+			 interrupts = /* Uses combined intr for both
+				       * global and context
+				       */
+				      <0 333 4>,
+				      <0 333 4>;
+			/* Note:
+			 * SID[2:0]  = PCIe function number
+			 * SID[7:3]  = PCIe device number
+			 * SID[14:8] = PCIe bus number
+			 */

18 more quoted lines

The driver currently assumes a 1:1 RID:SID mapping when it sees a PCI
device, so those numbers should be ignored.

Will

On Thu, Jan 28, 2016 at 11:17:39AM +0000, Will Deacon wrote:

On Thu, Jan 28, 2016 at 11:14:53AM +0000, Mark Rutland wrote:

quoted

On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add PCIe SMMU device tree node for AMD Seattle SOC.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a7fc059..bfccfea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -210,6 +210,7 @@
 			device_type = "pci";
 			bus-range = <0 0x7f>;
 			msi-parent = <&v2m0>;
+			#stream-id-cells = <16>;
 			reg = <0 0xf0000000 0 0x10000000>;
 
 			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;

@@ -230,6 +231,28 @@
 				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
 		};
 
+		pcie0_smmu: smmu at e0a00000 {
+			 compatible = "arm,mmu-401";
+			 reg = <0 0xe0a00000 0 0x10000>;
+			 #global-interrupts = <1>;
+			 interrupts = /* Uses combined intr for both
+				       * global and context
+				       */
+				      <0 333 4>,
+				      <0 333 4>;
+			/* Note:
+			 * SID[2:0]  = PCIe function number
+			 * SID[7:3]  = PCIe device number
+			 * SID[14:8] = PCIe bus number

22 more quoted lines

Given that, they shouldn't be in the DT, then?

Mark.

On Thu, Jan 28, 2016 at 11:18:19AM +0000, Mark Rutland wrote:

On Thu, Jan 28, 2016 at 11:17:39AM +0000, Will Deacon wrote:

quoted

On Thu, Jan 28, 2016 at 11:14:53AM +0000, Mark Rutland wrote:

quoted

On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add PCIe SMMU device tree node for AMD Seattle SOC.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a7fc059..bfccfea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -210,6 +210,7 @@
 			device_type = "pci";
 			bus-range = <0 0x7f>;
 			msi-parent = <&v2m0>;
+			#stream-id-cells = <16>;
 			reg = <0 0xf0000000 0 0x10000000>;
 
 			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;

@@ -230,6 +231,28 @@
 				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
 		};
 
+		pcie0_smmu: smmu at e0a00000 {
+			 compatible = "arm,mmu-401";
+			 reg = <0 0xe0a00000 0 0x10000>;
+			 #global-interrupts = <1>;
+			 interrupts = /* Uses combined intr for both
+				       * global and context
+				       */
+				      <0 333 4>,
+				      <0 333 4>;
+			/* Note:
+			 * SID[2:0]  = PCIe function number
+			 * SID[7:3]  = PCIe device number

25 more quoted lines

Not unless there's a patch extending the driver/binding so that they do
something useful, no.

Will

On 28/01/16 11:14, Mark Rutland wrote:

On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

Add PCIe SMMU device tree node for AMD Seattle SOC.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
  arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 23 +++++++++++++++++++++++
  1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a7fc059..bfccfea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi

@@ -210,6 +210,7 @@
  			device_type = "pci";
  			bus-range = <0 0x7f>;
  			msi-parent = <&v2m0>;
+			#stream-id-cells = <16>;
  			reg = <0 0xf0000000 0 0x10000000>;

  			interrupt-map-mask = <0xf800 0x0 0x0 0x7>;

@@ -230,6 +231,28 @@
  				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
  		};

+		pcie0_smmu: smmu at e0a00000 {
+			 compatible = "arm,mmu-401";
+			 reg = <0 0xe0a00000 0 0x10000>;
+			 #global-interrupts = <1>;
+			 interrupts = /* Uses combined intr for both
+				       * global and context
+				       */
+				      <0 333 4>,
+				      <0 333 4>;
+			/* Note:
+			 * SID[2:0]  = PCIe function number
+			 * SID[7:3]  = PCIe device number
+			 * SID[14:8] = PCIe bus number
+			 */

18 more quoted lines

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

Really, the only binding that's going to make sense for that context is 
"iommu-map". I think that should be pretty straightforward to implement 
entirely in core OF/IOMMU code - we can already figure out a device's 
DMA alias as the host controller sees it, we just need the IOMMU drivers 
to be able to then run that through an additional downstream translation 
(which would be identity-mapped by default).

Robin.

Mark.

[1] https://lkml.org/lkml/2015/7/23/561

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

Will, Robin, thoughts?

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

	Arnd

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

quoted

Will, Robin, thoughts?

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Will

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
[off-list ref] wrote:

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS files.
It also adds new board files for newer Overdrive and Linaro 96boards (Husky)
platforms.

My Overdrive comes with DT provided by firmware, so there's no need to
have a in-kernel-tree DT source.

Are you aware of other reasons to have it here? I just foresee
divergence and conflicts between the two. It was quite obvious before
this update when the FW-provided DT was a lot more complete than what
we had in the kernel tree.


-Olof

Hi Olof,

On 1/28/2016 3:39 PM, Olof Johansson wrote:

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
[off-list ref] wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS files.
It also adds new board files for newer Overdrive and Linaro 96boards (Husky)
platforms.

My Overdrive comes with DT provided by firmware, so there's no need to
have a in-kernel-tree DT source.

You are correct that the FW comes with DT, and in typical case, you 
wouldn't need this.

Are you aware of other reasons to have it here? I just foresee
divergence and conflicts between the two. It was quite obvious before
this update when the FW-provided DT was a lot more complete than what
we had in the kernel tree.

However, there are still new/updated drivers being developed, and 
sometimes requires new/changes in DT binding. So, the DT that comes with 
the FW can get out of date, and will lack the support for new drivers.

Certain version of the FW allows overriding the DT that comes with the 
FW. So, we are providing the in-kernel DT to allow developers to provide 
the updated device tree for newer kernels. This patch series is bringing 
the in-kernel DT closer to what the latest FW is providing to avoid 
potential conflicts.

Regards,
Suravee

-Olof

On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
[off-list ref] wrote:

Hi Olof,

On 1/28/2016 3:39 PM, Olof Johansson wrote:

quoted

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
[off-list ref] wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS
files.
It also adds new board files for newer Overdrive and Linaro 96boards
(Husky)
platforms.

My Overdrive comes with DT provided by firmware, so there's no need to
have a in-kernel-tree DT source.

You are correct that the FW comes with DT, and in typical case, you wouldn't
need this.

quoted

Are you aware of other reasons to have it here? I just foresee
divergence and conflicts between the two. It was quite obvious before
this update when the FW-provided DT was a lot more complete than what
we had in the kernel tree.

However, there are still new/updated drivers being developed, and sometimes
requires new/changes in DT binding. So, the DT that comes with the FW can
get out of date, and will lack the support for new drivers.

Note that it's expected that the driver will cope with the old DT
contents, i.e. it needs to go with defaults that made sense before the
binding was updated.

It, however, doesn't have to enable new features. In other words,
booting with an old DT needs to continue working. You can't require a
user to update DT to avoid getting driver breakage.

(The opposite is not enforced: Booting with a DT that is newer than
the kernel isn't guaranteed to always work).

Certain version of the FW allows overriding the DT that comes with the FW.
So, we are providing the in-kernel DT to allow developers to provide the
updated device tree for newer kernels. This patch series is bringing the
in-kernel DT closer to what the latest FW is providing to avoid potential
conflicts.

I do appreciate keeping the kernel one up to date with what firmware
provides if it's truly needed, but I'd even more prefer that it
wasn't. After all, it's how the ACPI-based booting works (no
overriding table provided with the kernel), so it's a model you should
already be somewhat familiar with. :)

I'm not doing a hard NAK on this, but I would like to get a bit more
understanding of why it's considered needed.


-Olof

On 1/28/2016 8:43 PM, Olof Johansson wrote:

On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
[off-list ref] wrote:

quoted

Hi Olof,

On 1/28/2016 3:39 PM, Olof Johansson wrote:

quoted

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
[off-list ref] wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS
files.
It also adds new board files for newer Overdrive and Linaro 96boards
(Husky)
platforms.

My Overdrive comes with DT provided by firmware, so there's no need to
have a in-kernel-tree DT source.

You are correct that the FW comes with DT, and in typical case, you wouldn't
need this.

quoted

Are you aware of other reasons to have it here? I just foresee
divergence and conflicts between the two. It was quite obvious before
this update when the FW-provided DT was a lot more complete than what
we had in the kernel tree.

However, there are still new/updated drivers being developed, and sometimes
requires new/changes in DT binding. So, the DT that comes with the FW can
get out of date, and will lack the support for new drivers.

Note that it's expected that the driver will cope with the old DT
contents, i.e. it needs to go with defaults that made sense before the
binding was updated.

7 more quoted lines

Ok. I understand your point that driver will not break the existing DT. :)

quoted

Certain version of the FW allows overriding the DT that comes with the FW.
So, we are providing the in-kernel DT to allow developers to provide the
updated device tree for newer kernels. This patch series is bringing the
in-kernel DT closer to what the latest FW is providing to avoid potential
conflicts.

I do appreciate keeping the kernel one up to date with what firmware
provides if it's truly needed, but I'd even more prefer that it
wasn't. After all, it's how the ACPI-based booting works (no
overriding table provided with the kernel), so it's a model you should
already be somewhat familiar with. :)

Agree. This is true in the x86 world where things are mostly stable.

However, in the ARM64 cases, there are still newer supports being added. 
Often that I have been asked by folks to provide a base DT that they can 
extend (e.g. to add support for platform device pass-through, PCI 
pass-through, SBSA GWDT, etc). Eventually, this in-kernel DT would not 
be needed as the more stable DT would have already been in the later 
version of the FW. But in the meantime, it seems useful to have this in 
one accessible place.

Thanks,
Suravee

I'm not doing a hard NAK on this, but I would like to get a bit more
understanding of why it's considered needed.


-Olof

On 1/28/2016 6:43 PM, Olof Johansson wrote:

On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
[off-list ref] wrote:

quoted

Hi Olof,

On 1/28/2016 3:39 PM, Olof Johansson wrote:

quoted

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
[off-list ref] wrote:

quoted

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS
files.
It also adds new board files for newer Overdrive and Linaro 96boards
(Husky)
platforms.

My Overdrive comes with DT provided by firmware, so there's no need to
have a in-kernel-tree DT source.

You are correct that the FW comes with DT, and in typical case, you wouldn't
need this.

quoted

Are you aware of other reasons to have it here? I just foresee
divergence and conflicts between the two. It was quite obvious before
this update when the FW-provided DT was a lot more complete than what
we had in the kernel tree.

However, there are still new/updated drivers being developed, and sometimes
requires new/changes in DT binding. So, the DT that comes with the FW can
get out of date, and will lack the support for new drivers.

Note that it's expected that the driver will cope with the old DT
contents, i.e. it needs to go with defaults that made sense before the
binding was updated.

25 more quoted lines

I would strongly encourage the inclusion of the dts file in the kernel
source tree, even if the dtb is delivered with the firmware for several
reasons.

The dts provides a reference for other developers who are supporting new
boards that are similar.

The dts might be reviewed.

We hope to have tools that will validate the dts against the documented
bindings.  (Yes, this effort has stalled, but I am optimistic that it
is not dead.)

If someone has the board (any board, not just this one) that the kernel
does not boot on, then it might not be possible to retrieve the dtb
from the board (which can then be de-compiled to a dts) for the
purpose of debugging or properly configuring the kernel.  (The boot
loader may provide the ability to get the dtb or it might not.)

-Frank

Dear all,
On 01/28/2016 03:27 PM, Will Deacon wrote:

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:

quoted

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

quoted

Will, Robin, thoughts?

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Will

Up to now I have used the PCI smmu description as described in Suravee's
patch and this does not work anymore with 4.6-rc1 since the default
domain was introduced. So now I see 2 SMRs matching a single streamid
(in my case 256, one steming from the "platform device" side of the host
controller and one steming from the PCI device) and this causes SMCF
(stream match conflict fault). So PCIe PF does not work.

I observe the fault only when I override the PCIe ACS property in my
case which was pretty confusing (each PF/VF is put in a separate group).

What is the correct syntax then: mmu-masters = <&pcie0>?

instead of

+			 mmu-masters = <&pcie0
+				/* 1:00:[0,3] */ 256 257 258 259
+				/* 2:00:[0,3] */ 512 513 514 515
+				/* 3:00:[0,3] */ 768 769 770 771
+				/* 4:00:[0,3] */ 1024 1025 1026 1027>

Is there a plan to update/upstream the dt description for PCIe smmu.

Thank you in advance

Best Regards

Eric

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

Hi Eric,

On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:

On 01/28/2016 03:27 PM, Will Deacon wrote:

quoted

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:

quoted

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

quoted

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Up to now I have used the PCI smmu description as described in Suravee's
patch and this does not work anymore with 4.6-rc1 since the default
domain was introduced. So now I see 2 SMRs matching a single streamid
(in my case 256, one steming from the "platform device" side of the host
controller and one steming from the PCI device) and this causes SMCF
(stream match conflict fault). So PCIe PF does not work.

Sorry about that, it wasn't intentional. In fact, I wrote commit
cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now")
specifically to avoid this breakage, after seeing it myself with VFIO
and an S2CR-based configuration. It looks like the check just needs moving
higher up (i.e. before we initialise the SMRs).

Does that fix it for you?

Will

Hi Will,
On 03/30/2016 05:45 PM, Will Deacon wrote:

Hi Eric,

On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:

quoted

On 01/28/2016 03:27 PM, Will Deacon wrote:

quoted

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:

quoted

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

quoted

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Up to now I have used the PCI smmu description as described in Suravee's
patch and this does not work anymore with 4.6-rc1 since the default
domain was introduced. So now I see 2 SMRs matching a single streamid
(in my case 256, one steming from the "platform device" side of the host
controller and one steming from the PCI device) and this causes SMCF
(stream match conflict fault). So PCIe PF does not work.

Sorry about that, it wasn't intentional. In fact, I wrote commit
cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now")
specifically to avoid this breakage, after seeing it myself with VFIO
and an S2CR-based configuration. It looks like the check just needs moving
higher up (i.e. before we initialise the SMRs).

1 more quoted lines

Yes this fixes the issue for me, thanks! I guess you will send that patch?

So eventually what is the right way to describe the smmu-masters (~
future of that patch)?

Best Regards

Eric

Will

On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:

On 03/30/2016 05:45 PM, Will Deacon wrote:

quoted

On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:

quoted

On 01/28/2016 03:27 PM, Will Deacon wrote:

quoted

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:

quoted

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

quoted

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Up to now I have used the PCI smmu description as described in Suravee's
patch and this does not work anymore with 4.6-rc1 since the default
domain was introduced. So now I see 2 SMRs matching a single streamid
(in my case 256, one steming from the "platform device" side of the host
controller and one steming from the PCI device) and this causes SMCF
(stream match conflict fault). So PCIe PF does not work.

Sorry about that, it wasn't intentional. In fact, I wrote commit
cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now")
specifically to avoid this breakage, after seeing it myself with VFIO
and an S2CR-based configuration. It looks like the check just needs moving
higher up (i.e. before we initialise the SMRs).

Does that fix it for you?

1 more quoted lines

I need to check that it doesn't break rebinding to the host after VFIO
has been used for passthrough, first.

Does your devicetree explicitly assign a StreamID to the platform device
for the host controller? We should probably be handling this, since it
will crop us as an issue again once we decide to enable the default
domain properly.

So eventually what is the right way to describe the smmu-masters (~
future of that patch)?

Using the generic iommu binding
(Documentation/devicetree/bindings/iommu/iommu.txt), which will be required
for of_xlate-based probing. The old binding should still continue to
function as it always has, though.

Will

Hi Will,
On 03/30/2016 07:24 PM, Will Deacon wrote:

On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:

quoted

On 03/30/2016 05:45 PM, Will Deacon wrote:

quoted

On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:

quoted

On 01/28/2016 03:27 PM, Will Deacon wrote:

quoted

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:

quoted

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

quoted

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Up to now I have used the PCI smmu description as described in Suravee's
patch and this does not work anymore with 4.6-rc1 since the default
domain was introduced. So now I see 2 SMRs matching a single streamid
(in my case 256, one steming from the "platform device" side of the host
controller and one steming from the PCI device) and this causes SMCF
(stream match conflict fault). So PCIe PF does not work.

Sorry about that, it wasn't intentional. In fact, I wrote commit
cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now")
specifically to avoid this breakage, after seeing it myself with VFIO
and an S2CR-based configuration. It looks like the check just needs moving
higher up (i.e. before we initialise the SMRs).

5 more quoted lines

OK. I can help testing too since I am currently working on PCIe
passthrough respin.

Does your devicetree explicitly assign a StreamID to the platform device
for the host controller? We should probably be handling this, since it
will crop us as an issue again once we decide to enable the default
domain properly.

Yes it does. My dt description currently matches the one found in this
patch from Suravee (old binding style). Hence my question. Shall I
remove this and let PCIe register their RID=SID automatically?

quoted

So eventually what is the right way to describe the smmu-masters (~
future of that patch)?

Using the generic iommu binding
(Documentation/devicetree/bindings/iommu/iommu.txt), which will be required
for of_xlate-based probing. The old binding should still continue to
function as it always has, though.

OK thanks

Eric

Will

On Thu, Mar 31, 2016 at 09:39:38AM +0200, Eric Auger wrote:

On 03/30/2016 07:24 PM, Will Deacon wrote:

quoted

On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:

quoted

On 03/30/2016 05:45 PM, Will Deacon wrote:

quoted

On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:

quoted

On 01/28/2016 03:27 PM, Will Deacon wrote:

quoted

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:

quoted

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

quoted

quoted

Any IDs specified here would only apply to DMA by the "platform device" 
side of the host controller itself (as would an equivalent "iommus" 
property on pcie0 once I finish the SMMUv2 generic binding support I'm 
working on). In terms of PCI devices, the "mmu-masters" property is 
overloaded such that only its existence matters, to identify that there 
_is_ a relationship between the SMMU and the PCI bus(es) behind that 
host controller.

I wasn't aware that this was actually still specified. I had hoped
we were getting rid of mmu-masters before anyone actually started
using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.

Does anyone know what happened to the plan to use the iommu DT binding
for the ARM SMMU instead? Do we now have to support both ways indefinitely?

We always did -- Seattle used the mmu-masters binding before the generic
binding even existed. Robin has been working on patches to get of_xlate
up and running, but it got held up by Laurent's series which didn't end
up going anywhere.

Up to now I have used the PCI smmu description as described in Suravee's
patch and this does not work anymore with 4.6-rc1 since the default
domain was introduced. So now I see 2 SMRs matching a single streamid
(in my case 256, one steming from the "platform device" side of the host
controller and one steming from the PCI device) and this causes SMCF
(stream match conflict fault). So PCIe PF does not work.

Sorry about that, it wasn't intentional. In fact, I wrote commit
cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now")
specifically to avoid this breakage, after seeing it myself with VFIO
and an S2CR-based configuration. It looks like the check just needs moving
higher up (i.e. before we initialise the SMRs).

9 more quoted lines

Thanks, that would be really helpful if you have the time.

Will