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

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

[Suravee Suthikulpanit]

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
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

-- 
2.5.0

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

[Suravee Suthikulpanit]

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
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

-- 
2.5.0

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

[Suravee Suthikulpanit]

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
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

-- 
2.5.0

[PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree

[Suravee Suthikulpanit]

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

Adding maintainers for AMD Seattle device tree.

Signed-off-by: Brijesh Singh <brijeshkumar.singh@amd.com>
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@vger.kernel.org
-- 
2.5.0

[PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree

[Suravee Suthikulpanit]

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

Adding maintainers for AMD Seattle device tree.

Signed-off-by: Brijesh Singh <brijeshkumar.singh@amd.com>
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

[PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree

[Suravee Suthikulpanit]

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

Adding maintainers for AMD Seattle device tree.

Signed-off-by: Brijesh Singh <brijeshkumar.singh@amd.com>
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@vger.kernel.org
-- 
2.5.0

Re: [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree

[Martin Michlmayr]

* Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> [2016-01-27 15:11]:
> +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

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

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

[PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree

[Martin Michlmayr]

* Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> [2016-01-27 15:11]:
> +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

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

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

Re: [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree

[Martin Michlmayr]

* Suravee Suthikulpanit <Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org> [2016-01-27 15:11]:
> +AMD SEATTLE DEVICE TREE SUPPORT
> +M:	Brijesh Singh <brijeshkumar.singh-5C7GfCeVMHo@public.gmane.org>
> +M:	Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
> +S:	Supported
> +M:	Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org>
> +S:	Supported

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

-- 
Martin Michlmayr
http://www.cyrius.com/
--
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 02/13] dtb: amd: Fix GICv2 hypervisor and virtual interface sizes

[Suravee Suthikulpanit]

From: Brijesh Singh <brijeshkumar.singh@amd.com>

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 <brijeshkumar.singh@amd.com>
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@e0080000 {
-- 
2.5.0

[PATCH 02/13] dtb: amd: Fix GICv2 hypervisor and virtual interface sizes

[Suravee Suthikulpanit]

From: Brijesh Singh <brijeshkumar.singh@amd.com>

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 <brijeshkumar.singh@amd.com>
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

[PATCH 02/13] dtb: amd: Fix GICv2 hypervisor and virtual interface sizes

[Suravee Suthikulpanit]

From: Brijesh Singh <brijeshkumar.singh@amd.com>

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 <brijeshkumar.singh@amd.com>
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@e0080000 {
-- 
2.5.0

[PATCH 03/13] dtb: amd: Fix DMA ranges in device tree

[Suravee Suthikulpanit]

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

[PATCH 03/13] dtb: amd: Fix DMA ranges in device tree

[Suravee Suthikulpanit]

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

[PATCH 03/13] dtb: amd: Fix DMA ranges in device tree

[Suravee Suthikulpanit]

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

[PATCH 04/13] dtb: amd: Fix typo in SPI device nodes

[Suravee Suthikulpanit]

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

[PATCH 04/13] dtb: amd: Fix typo in SPI device nodes

[Suravee Suthikulpanit]

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

[PATCH 04/13] dtb: amd: Fix typo in SPI device nodes

[Suravee Suthikulpanit]

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

[PATCH 05/13] dtb: amd: Misc changes for I2C device nodes

[Suravee Suthikulpanit]

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@e0050000 {
+			status = "disabled";
+			compatible = "snps,designware-i2c";
+			reg = <0 0xe0050000 0 0x1000>;
+			interrupts = <0 340 4>;
+			clocks = <&miscclk_250mhz>;
 		};
 
 		serial0: serial@e1010000 {
-- 
2.5.0

[PATCH 05/13] dtb: amd: Misc changes for I2C device nodes

[Suravee Suthikulpanit]

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

[PATCH 05/13] dtb: amd: Misc changes for I2C device nodes

[Suravee Suthikulpanit]

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@e0050000 {
+			status = "disabled";
+			compatible = "snps,designware-i2c";
+			reg = <0 0xe0050000 0 0x1000>;
+			interrupts = <0 340 4>;
+			clocks = <&miscclk_250mhz>;
 		};
 
 		serial0: serial@e1010000 {
-- 
2.5.0

[PATCH 06/13] dtb: amd: Misc changes for SATA device tree nodes

[Suravee Suthikulpanit]

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@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@e0d00000 {
+			status = "disabled";
+			compatible = "snps,dwc-ahci";
+			reg = <0 0xe0d00000 0 0xf0000>;
+			interrupts = <0 354 4>;
+			clocks = <&sataclk_333mhz>;
+			dma-coherent;
+		};
+
 		i2c0: i2c@e1000000 {
 			status = "disabled";
 			compatible = "snps,designware-i2c";
-- 
2.5.0

[PATCH 06/13] dtb: amd: Misc changes for SATA device tree nodes

[Suravee Suthikulpanit]

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

[PATCH 06/13] dtb: amd: Misc changes for SATA device tree nodes

[Suravee Suthikulpanit]

From: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>

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

Signed-off-by: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
---
 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@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@e0d00000 {
+			status = "disabled";
+			compatible = "snps,dwc-ahci";
+			reg = <0 0xe0d00000 0 0xf0000>;
+			interrupts = <0 354 4>;
+			clocks = <&sataclk_333mhz>;
+			dma-coherent;
+		};
+
 		i2c0: i2c@e1000000 {
 			status = "disabled";
 			compatible = "snps,designware-i2c";
-- 
2.5.0

--
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 07/13] dtb: amd: Misc changes for GPIO devices

[Suravee Suthikulpanit]

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@e1040000 {
+		gpio0: gpio@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@e1050000 {
+		gpio1: gpio@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@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@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@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

[PATCH 07/13] dtb: amd: Misc changes for GPIO devices

[Suravee Suthikulpanit]

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

[PATCH 07/13] dtb: amd: Misc changes for GPIO devices

[Suravee Suthikulpanit]

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@e1040000 {
+		gpio0: gpio@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@e1050000 {
+		gpio1: gpio@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@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@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@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

[PATCH 08/13] dtb: amd: Add PERF CCN-504 device tree node

[Suravee Suthikulpanit]

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@0xe8000000 {
+			compatible = "arm,ccn-504";
+			reg = <0x0 0xe8000000 0 0x1000000>;
+			interrupts = <0 380 4>;
+		};
 	};
 };
-- 
2.5.0

[PATCH 08/13] dtb: amd: Add PERF CCN-504 device tree node

[Suravee Suthikulpanit]

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

[PATCH 08/13] dtb: amd: Add PERF CCN-504 device tree node

[Suravee Suthikulpanit]

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@0xe8000000 {
+			compatible = "arm,ccn-504";
+			reg = <0x0 0xe8000000 0 0x1000000>;
+			interrupts = <0 380 4>;
+		};
 	};
 };
-- 
2.5.0

[PATCH 09/13] dtb: amd: Add KCS device tree node

[Suravee Suthikulpanit]

From: Brijesh Singh <brijeshkumar.singh@amd.com>

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

Signed-off-by: Brijesh Singh <brijeshkumar.singh@amd.com>
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@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

[PATCH 09/13] dtb: amd: Add KCS device tree node

[Suravee Suthikulpanit]

From: Brijesh Singh <brijeshkumar.singh@amd.com>

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

Signed-off-by: Brijesh Singh <brijeshkumar.singh@amd.com>
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

[PATCH 09/13] dtb: amd: Add KCS device tree node

[Suravee Suthikulpanit]

From: Brijesh Singh <brijeshkumar.singh@amd.com>

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

Signed-off-by: Brijesh Singh <brijeshkumar.singh@amd.com>
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@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

[PATCH 10/13] dtb: amd: Add AMD XGBE device tree file

[Suravee Suthikulpanit]

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

[PATCH 10/13] dtb: amd: Add AMD XGBE device tree file

[Suravee Suthikulpanit]

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

[PATCH 10/13] dtb: amd: Add AMD XGBE device tree file

[Suravee Suthikulpanit]

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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Suravee Suthikulpanit]

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@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@0xe8000000 {
 			compatible = "arm,ccn-504";
-- 
2.5.0

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Suravee Suthikulpanit]

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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Suravee Suthikulpanit]

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@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@0xe8000000 {
 			compatible = "arm,ccn-504";
-- 
2.5.0

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Mark Rutland]

On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
> 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@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
> +			 >;
> +		 };

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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Mark Rutland]

On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
> 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
> +			 >;
> +		 };

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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > 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@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
> > +			 >;
> > +		 };
> 
> 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?

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

Will

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > 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
> > +			 >;
> > +		 };
> 
> 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?

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

Will

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > From: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
> > 
> > Add PCIe SMMU device tree node for AMD Seattle SOC.
> > 
> > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
> > ---
> >  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@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
> > +			 >;
> > +		 };
> 
> 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?

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

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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Mark Rutland]

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:
> > On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
> > > 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@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
> > > +			 >;
> > > +		 };
> > 
> > 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?
> 
> The driver currently assumes a 1:1 RID:SID mapping when it sees a PCI
> device, so those numbers should be ignored.

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

Mark.

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Mark Rutland]

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:
> > On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
> > > 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
> > > +			 >;
> > > +		 };
> > 
> > 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?
> 
> The driver currently assumes a 1:1 RID:SID mapping when it sees a PCI
> device, so those numbers should be ignored.

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

Mark.

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Mark Rutland]

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:
> > On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
> > > From: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
> > > 
> > > Add PCIe SMMU device tree node for AMD Seattle SOC.
> > > 
> > > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
> > > ---
> > >  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@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
> > > +			 >;
> > > +		 };
> > 
> > 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?
> 
> The driver currently assumes a 1:1 RID:SID mapping when it sees a PCI
> device, so those numbers should be ignored.

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

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 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > 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:
> > > > 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@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
> > > > +			 >;
> > > > +		 };
> > > 
> > > 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?
> > 
> > The driver currently assumes a 1:1 RID:SID mapping when it sees a PCI
> > device, so those numbers should be ignored.
> 
> Given that, they shouldn't be in the DT, then?

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

Will

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > 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:
> > > > 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
> > > > +			 >;
> > > > +		 };
> > > 
> > > 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?
> > 
> > The driver currently assumes a 1:1 RID:SID mapping when it sees a PCI
> > device, so those numbers should be ignored.
> 
> Given that, they shouldn't be in the DT, then?

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

Will

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > 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:
> > > > From: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
> > > > 
> > > > Add PCIe SMMU device tree node for AMD Seattle SOC.
> > > > 
> > > > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
> > > > ---
> > > >  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@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
> > > > +			 >;
> > > > +		 };
> > > 
> > > 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?
> > 
> > The driver currently assumes a 1:1 RID:SID mapping when it sees a PCI
> > device, so those numbers should be ignored.
> 
> Given that, they shouldn't be in the DT, then?

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

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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Robin Murphy]

On 28/01/16 11:14, Mark Rutland wrote:
> On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
>> 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@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
>> +			 >;
>> +		 };
>
> 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?

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
>

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Robin Murphy]

On 28/01/16 11:14, Mark Rutland wrote:
> On Wed, Jan 27, 2016 at 03:11:59PM -0600, Suravee Suthikulpanit wrote:
>> 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
>> +			 >;
>> +		 };
>
> 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?

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
>

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Arnd Bergmann]

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >
> > 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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Arnd Bergmann]

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >
> > 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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Arnd Bergmann]

On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >
> > 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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> > >
> > > 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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> > >
> > > 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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> > >
> > > 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
--
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 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

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:
>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>
>>>> 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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

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:
>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>
>>>> 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
> 

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> >> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >>>>
> >>> 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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> >> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >>>>
> >>> 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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

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:
> > On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> >> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >>>>
> >>> 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
--
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 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

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:
>> On 01/28/2016 03:27 PM, Will Deacon wrote:
>>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
>>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>>>
>>>>> 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?
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
> 

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

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:
>> On 01/28/2016 03:27 PM, Will Deacon wrote:
>>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
>>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>>>
>>>>> 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?
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
> 

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

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:
>> On 01/28/2016 03:27 PM, Will Deacon wrote:
>>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
>>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>>>
>>>>> 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?
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
> 

--
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 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:
> On 03/30/2016 05:45 PM, Will Deacon wrote:
> > On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
> >> On 01/28/2016 03:27 PM, Will Deacon wrote:
> >>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> >>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >>>>>>
> >>>>> 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?
> Yes this fixes the issue for me, thanks! I guess you will send that patch?

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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:
> On 03/30/2016 05:45 PM, Will Deacon wrote:
> > On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
> >> On 01/28/2016 03:27 PM, Will Deacon wrote:
> >>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> >>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >>>>>>
> >>>>> 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?
> Yes this fixes the issue for me, thanks! I guess you will send that patch?

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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

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:
>> On 03/30/2016 05:45 PM, Will Deacon wrote:
>>> On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
>>>> On 01/28/2016 03:27 PM, Will Deacon wrote:
>>>>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
>>>>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>>>>>
>>>>>>> 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?
>> Yes this fixes the issue for me, thanks! I guess you will send that patch?
> 
> I need to check that it doesn't break rebinding to the host after VFIO
> has been used for passthrough, first.

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

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

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:
>> On 03/30/2016 05:45 PM, Will Deacon wrote:
>>> On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
>>>> On 01/28/2016 03:27 PM, Will Deacon wrote:
>>>>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
>>>>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
>>>>>>>>
>>>>>>> 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?
>> Yes this fixes the issue for me, thanks! I guess you will send that patch?
> 
> I need to check that it doesn't break rebinding to the host after VFIO
> has been used for passthrough, first.

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

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

On Thu, Mar 31, 2016 at 09:39:38AM +0200, Eric Auger wrote:
> On 03/30/2016 07:24 PM, Will Deacon wrote:
> > On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:
> >> On 03/30/2016 05:45 PM, Will Deacon wrote:
> >>> On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
> >>>> On 01/28/2016 03:27 PM, Will Deacon wrote:
> >>>>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> >>>>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >>>>>>>>
> >>>>>>> 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?
> >> Yes this fixes the issue for me, thanks! I guess you will send that patch?
> > 
> > I need to check that it doesn't break rebinding to the host after VFIO
> > has been used for passthrough, first.
> 
> OK. I can help testing too since I am currently working on PCIe
> passthrough respin.

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

Will

[PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Will Deacon]

On Thu, Mar 31, 2016 at 09:39:38AM +0200, Eric Auger wrote:
> On 03/30/2016 07:24 PM, Will Deacon wrote:
> > On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:
> >> On 03/30/2016 05:45 PM, Will Deacon wrote:
> >>> On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
> >>>> On 01/28/2016 03:27 PM, Will Deacon wrote:
> >>>>> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
> >>>>>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:
> >>>>>>>>
> >>>>>>> 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?
> >> Yes this fixes the issue for me, thanks! I guess you will send that patch?
> > 
> > I need to check that it doesn't break rebinding to the host after VFIO
> > has been used for passthrough, first.
> 
> OK. I can help testing too since I am currently working on PCIe
> passthrough respin.

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

Will

[PATCH 12/13] dtb: amd: Add support for new AMD Overdrive boards

[Suravee Suthikulpanit]

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

[PATCH 12/13] dtb: amd: Add support for new AMD Overdrive boards

[Suravee Suthikulpanit]

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

[PATCH 12/13] dtb: amd: Add support for new AMD Overdrive boards

[Suravee Suthikulpanit]

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

[PATCH 13/13] dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board

[Suravee Suthikulpanit]

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 <leo.duran@amd.com>
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@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

[PATCH 13/13] dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board

[Suravee Suthikulpanit]

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 <leo.duran@amd.com>
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

[PATCH 13/13] dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board

[Suravee Suthikulpanit]

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 <leo.duran@amd.com>
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@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

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

[Olof Johansson]

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
<Suravee.Suthikulpanit@amd.com> 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

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

[Olof Johansson]

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
<Suravee.Suthikulpanit@amd.com> 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

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

[Olof Johansson]

Hi Suravee,

On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit
<Suravee.Suthikulpanit@amd.com> 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

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

[Suravee Suthikulanit]

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
> <Suravee.Suthikulpanit@amd.com> 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.

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
>

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

[Suravee Suthikulanit]

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
> <Suravee.Suthikulpanit@amd.com> 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.

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
>

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

[Suravee Suthikulanit]

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
> <Suravee.Suthikulpanit@amd.com> 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.

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
>

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

[Olof Johansson]

On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
<suravee.suthikulpanit@amd.com> wrote:
> 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
>> <Suravee.Suthikulpanit@amd.com> 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.
>
>
> 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.

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

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

[Olof Johansson]

On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
<suravee.suthikulpanit@amd.com> wrote:
> 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
>> <Suravee.Suthikulpanit@amd.com> 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.
>
>
> 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.

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

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

[Olof Johansson]

On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
<suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org> wrote:
> 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
>> <Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org> wrote:
>>>
>>> From: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
>>>
>>> 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.

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
--
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 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

[Suravee Suthikulanit]

On 1/28/2016 8:43 PM, Olof Johansson wrote:
> On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
> <suravee.suthikulpanit@amd.com> wrote:
>> 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
>>> <Suravee.Suthikulpanit@amd.com> 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.
>>
>>
>> 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.
>
> 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).

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

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

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

[Suravee Suthikulanit]

On 1/28/2016 8:43 PM, Olof Johansson wrote:
> On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
> <suravee.suthikulpanit@amd.com> wrote:
>> 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
>>> <Suravee.Suthikulpanit@amd.com> 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.
>>
>>
>> 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.
>
> 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).

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

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

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

[Suravee Suthikulanit]

On 1/28/2016 8:43 PM, Olof Johansson wrote:
> On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
> <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org> wrote:
>> 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
>>> <Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org> wrote:
>>>>
>>>> From: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
>>>>
>>>> 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.
>
> 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).

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

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

--
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 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS

[Frank Rowand]

On 1/28/2016 6:43 PM, Olof Johansson wrote:
> On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
> <suravee.suthikulpanit@amd.com> wrote:
>> 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
>>> <Suravee.Suthikulpanit@amd.com> 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.
>>
>>
>> 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.
> 
> 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

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

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

[Frank Rowand]

On 1/28/2016 6:43 PM, Olof Johansson wrote:
> On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
> <suravee.suthikulpanit@amd.com> wrote:
>> 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
>>> <Suravee.Suthikulpanit@amd.com> 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.
>>
>>
>> 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.
> 
> 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

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

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

[Frank Rowand]

On 1/28/2016 6:43 PM, Olof Johansson wrote:
> On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit
> <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org> wrote:
>> 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
>>> <Suravee.Suthikulpanit-5C7GfCeVMHo@public.gmane.org> wrote:
>>>>
>>>> From: Suravee Suthikulpanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
>>>>
>>>> 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.
> 
> 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

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

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