* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 02/13] dtb: amd: Fix GICv2 hypervisor and virtual interface sizes
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 02/13] dtb: amd: Fix GICv2 hypervisor and virtual interface sizes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 02/13] dtb: amd: Fix GICv2 hypervisor and virtual interface sizes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 03/13] dtb: amd: Fix DMA ranges in device tree
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 03/13] dtb: amd: Fix DMA ranges in device tree
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, brijeshkumar.singh, thomas.lendacky, linux-kernel,
arm, leo.duran, Suravee Suthikulpanit, linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 03/13] dtb: amd: Fix DMA ranges in device tree
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 04/13] dtb: amd: Fix typo in SPI device nodes
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 04/13] dtb: amd: Fix typo in SPI device nodes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 04/13] dtb: amd: Fix typo in SPI device nodes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 05/13] dtb: amd: Misc changes for I2C device nodes
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 05/13] dtb: amd: Misc changes for I2C device nodes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 05/13] dtb: amd: Misc changes for I2C device nodes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 06/13] dtb: amd: Misc changes for SATA device tree nodes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 06/13] dtb: amd: Misc changes for SATA device tree nodes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, arnd-r2nGTMty4D4
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, brijeshkumar.singh-5C7GfCeVMHo,
thomas.lendacky-5C7GfCeVMHo, leo.duran-5C7GfCeVMHo,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 06/13] dtb: amd: Misc changes for SATA device tree nodes
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 07/13] dtb: amd: Misc changes for GPIO devices
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 07/13] dtb: amd: Misc changes for GPIO devices
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 07/13] dtb: amd: Misc changes for GPIO devices
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 08/13] dtb: amd: Add PERF CCN-504 device tree node
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 08/13] dtb: amd: Add PERF CCN-504 device tree node
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 08/13] dtb: amd: Add PERF CCN-504 device tree node
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 09/13] dtb: amd: Add KCS device tree node
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 09/13] dtb: amd: Add KCS device tree node
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 09/13] dtb: amd: Add KCS device tree node
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 10/13] dtb: amd: Add AMD XGBE device tree file
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 10/13] dtb: amd: Add AMD XGBE device tree file
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, brijeshkumar.singh, thomas.lendacky, linux-kernel,
arm, leo.duran, linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 10/13] dtb: amd: Add AMD XGBE device tree file
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-27 21:11 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 12/13] dtb: amd: Add support for new AMD Overdrive boards
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:12 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:12 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 12/13] dtb: amd: Add support for new AMD Overdrive boards
@ 2016-01-27 21:12 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:12 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 12/13] dtb: amd: Add support for new AMD Overdrive boards
@ 2016-01-27 21:12 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 13/13] dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-27 21:12 ` Suravee Suthikulpanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:12 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 13/13] dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board
@ 2016-01-27 21:12 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:12 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd
Cc: devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, thomas.lendacky, leo.duran,
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH 13/13] dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board
@ 2016-01-27 21:12 ` Suravee Suthikulpanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulpanit @ 2016-01-27 21:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
@ 2016-01-28 4:49 ` Martin Michlmayr
0 siblings, 0 replies; 93+ messages in thread
From: Martin Michlmayr @ 2016-01-28 4:49 UTC (permalink / raw)
To: Suravee Suthikulpanit
Cc: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, arnd,
devicetree, brijeshkumar.singh, thomas.lendacky, linux-kernel,
arm, leo.duran, linux-arm-kernel
* 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/
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
@ 2016-01-28 4:49 ` Martin Michlmayr
0 siblings, 0 replies; 93+ messages in thread
From: Martin Michlmayr @ 2016-01-28 4:49 UTC (permalink / raw)
To: Suravee Suthikulpanit
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, arnd-r2nGTMty4D4,
devicetree-u79uwXL29TY76Z2rM5mHXA,
brijeshkumar.singh-5C7GfCeVMHo, thomas.lendacky-5C7GfCeVMHo,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arm-DgEjT+Ai2ygdnm+yROfE0A,
leo.duran-5C7GfCeVMHo,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
* 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
@ 2016-01-28 4:49 ` Martin Michlmayr
0 siblings, 0 replies; 93+ messages in thread
From: Martin Michlmayr @ 2016-01-28 4:49 UTC (permalink / raw)
To: linux-arm-kernel
* 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/
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-27 21:11 ` Suravee Suthikulpanit
@ 2016-01-28 11:14 ` Mark Rutland
-1 siblings, 0 replies; 93+ messages in thread
From: Mark Rutland @ 2016-01-28 11:14 UTC (permalink / raw)
To: Suravee Suthikulpanit, will.deacon, robin.murphy
Cc: robh+dt, pawel.moll, ijc+devicetree, galak, arnd, devicetree,
linux-kernel, linux-arm-kernel, arm, brijeshkumar.singh,
thomas.lendacky, leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:14 ` Mark Rutland
0 siblings, 0 replies; 93+ messages in thread
From: Mark Rutland @ 2016-01-28 11:14 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-28 11:14 ` Mark Rutland
(?)
@ 2016-01-28 11:17 ` Will Deacon
-1 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 11:17 UTC (permalink / raw)
To: Mark Rutland
Cc: Suravee Suthikulpanit, robin.murphy, robh+dt, pawel.moll,
ijc+devicetree, galak, arnd, devicetree, linux-kernel,
linux-arm-kernel, arm, brijeshkumar.singh, thomas.lendacky,
leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:17 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 11:17 UTC (permalink / raw)
To: Mark Rutland
Cc: Suravee Suthikulpanit, robin.murphy-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, arnd-r2nGTMty4D4,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, brijeshkumar.singh-5C7GfCeVMHo,
thomas.lendacky-5C7GfCeVMHo, leo.duran-5C7GfCeVMHo
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:17 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 11:17 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:18 ` Mark Rutland
0 siblings, 0 replies; 93+ messages in thread
From: Mark Rutland @ 2016-01-28 11:18 UTC (permalink / raw)
To: Will Deacon
Cc: Suravee Suthikulpanit, robin.murphy, robh+dt, pawel.moll,
ijc+devicetree, galak, arnd, devicetree, linux-kernel,
linux-arm-kernel, arm, brijeshkumar.singh, thomas.lendacky,
leo.duran
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.
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:18 ` Mark Rutland
0 siblings, 0 replies; 93+ messages in thread
From: Mark Rutland @ 2016-01-28 11:18 UTC (permalink / raw)
To: Will Deacon
Cc: Suravee Suthikulpanit, robin.murphy-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, arnd-r2nGTMty4D4,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, brijeshkumar.singh-5C7GfCeVMHo,
thomas.lendacky-5C7GfCeVMHo, leo.duran-5C7GfCeVMHo
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:18 ` Mark Rutland
0 siblings, 0 replies; 93+ messages in thread
From: Mark Rutland @ 2016-01-28 11:18 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-28 11:18 ` Mark Rutland
(?)
@ 2016-01-28 11:19 ` Will Deacon
-1 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 11:19 UTC (permalink / raw)
To: Mark Rutland
Cc: Suravee Suthikulpanit, robin.murphy, robh+dt, pawel.moll,
ijc+devicetree, galak, arnd, devicetree, linux-kernel,
linux-arm-kernel, arm, brijeshkumar.singh, thomas.lendacky,
leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:19 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 11:19 UTC (permalink / raw)
To: Mark Rutland
Cc: Suravee Suthikulpanit, robin.murphy-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, arnd-r2nGTMty4D4,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, brijeshkumar.singh-5C7GfCeVMHo,
thomas.lendacky-5C7GfCeVMHo, leo.duran-5C7GfCeVMHo
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 11:19 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 11:19 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-28 11:14 ` Mark Rutland
@ 2016-01-28 12:20 ` Robin Murphy
-1 siblings, 0 replies; 93+ messages in thread
From: Robin Murphy @ 2016-01-28 12:20 UTC (permalink / raw)
To: Mark Rutland, Suravee Suthikulpanit, will.deacon
Cc: robh+dt, pawel.moll, ijc+devicetree, galak, arnd, devicetree,
linux-kernel, linux-arm-kernel, arm, brijeshkumar.singh,
thomas.lendacky, leo.duran
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 12:20 ` Robin Murphy
0 siblings, 0 replies; 93+ messages in thread
From: Robin Murphy @ 2016-01-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-28 12:20 ` Robin Murphy
(?)
@ 2016-01-28 14:17 ` Arnd Bergmann
-1 siblings, 0 replies; 93+ messages in thread
From: Arnd Bergmann @ 2016-01-28 14:17 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, Suravee Suthikulpanit, will.deacon, robh+dt,
pawel.moll, ijc+devicetree, galak, devicetree, linux-kernel,
linux-arm-kernel, arm, brijeshkumar.singh, thomas.lendacky,
leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 14:17 ` Arnd Bergmann
0 siblings, 0 replies; 93+ messages in thread
From: Arnd Bergmann @ 2016-01-28 14:17 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, devicetree, arm, pawel.moll, ijc+devicetree,
will.deacon, linux-kernel, robh+dt, leo.duran,
Suravee Suthikulpanit, galak, thomas.lendacky, linux-arm-kernel,
brijeshkumar.singh
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 14:17 ` Arnd Bergmann
0 siblings, 0 replies; 93+ messages in thread
From: Arnd Bergmann @ 2016-01-28 14:17 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-28 14:17 ` Arnd Bergmann
(?)
@ 2016-01-28 14:27 ` Will Deacon
-1 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 14:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Robin Murphy, Mark Rutland, Suravee Suthikulpanit, robh+dt,
pawel.moll, ijc+devicetree, galak, devicetree, linux-kernel,
linux-arm-kernel, arm, brijeshkumar.singh, thomas.lendacky,
leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 14:27 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 14:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Robin Murphy, Mark Rutland, Suravee Suthikulpanit,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, brijeshkumar.singh-5C7GfCeVMHo,
thomas.lendacky-5C7GfCeVMHo, leo.duran-5C7GfCeVMHo
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-01-28 14:27 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-01-28 14:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
2016-01-27 21:11 ` Suravee Suthikulpanit
(?)
@ 2016-01-28 21:39 ` Olof Johansson
-1 siblings, 0 replies; 93+ messages in thread
From: Olof Johansson @ 2016-01-28 21:39 UTC (permalink / raw)
To: Suravee Suthikulpanit
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, Thomas Lendacky, leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-28 21:39 ` Olof Johansson
0 siblings, 0 replies; 93+ messages in thread
From: Olof Johansson @ 2016-01-28 21:39 UTC (permalink / raw)
To: Suravee Suthikulpanit
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, Thomas Lendacky, leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-28 21:39 ` Olof Johansson
0 siblings, 0 replies; 93+ messages in thread
From: Olof Johansson @ 2016-01-28 21:39 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
2016-01-28 21:39 ` Olof Johansson
(?)
@ 2016-01-28 22:20 ` Suravee Suthikulanit
-1 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulanit @ 2016-01-28 22:20 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, Thomas Lendacky, leo.duran
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-28 22:20 ` Suravee Suthikulanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulanit @ 2016-01-28 22:20 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, Thomas Lendacky, leo.duran
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-28 22:20 ` Suravee Suthikulanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulanit @ 2016-01-28 22:20 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-29 2:43 ` Olof Johansson
0 siblings, 0 replies; 93+ messages in thread
From: Olof Johansson @ 2016-01-29 2:43 UTC (permalink / raw)
To: Suravee Suthikulanit
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, Thomas Lendacky, leo.duran
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-29 2:43 ` Olof Johansson
0 siblings, 0 replies; 93+ messages in thread
From: Olof Johansson @ 2016-01-29 2:43 UTC (permalink / raw)
To: Suravee Suthikulanit
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, brijeshkumar.singh-5C7GfCeVMHo,
Thomas Lendacky, leo.duran-5C7GfCeVMHo
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-29 2:43 ` Olof Johansson
0 siblings, 0 replies; 93+ messages in thread
From: Olof Johansson @ 2016-01-29 2:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-30 0:02 ` Suravee Suthikulanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulanit @ 2016-01-30 0:02 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree, linux-kernel, linux-arm-kernel, arm,
brijeshkumar.singh, Thomas Lendacky, leo.duran
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-30 0:02 ` Suravee Suthikulanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulanit @ 2016-01-30 0:02 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arm-DgEjT+Ai2ygdnm+yROfE0A, brijeshkumar.singh-5C7GfCeVMHo,
Thomas Lendacky, leo.duran-5C7GfCeVMHo
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-30 0:02 ` Suravee Suthikulanit
0 siblings, 0 replies; 93+ messages in thread
From: Suravee Suthikulanit @ 2016-01-30 0:02 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-30 1:02 ` Frank Rowand
0 siblings, 0 replies; 93+ messages in thread
From: Frank Rowand @ 2016-01-30 1:02 UTC (permalink / raw)
To: Olof Johansson
Cc: Suravee Suthikulanit, Mark Rutland, devicetree, Pawel Moll,
Arnd Bergmann, Ian Campbell, linux-kernel, arm, Rob Herring,
leo.duran, Kumar Gala, Thomas Lendacky, linux-arm-kernel,
brijeshkumar.singh
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-30 1:02 ` Frank Rowand
0 siblings, 0 replies; 93+ messages in thread
From: Frank Rowand @ 2016-01-30 1:02 UTC (permalink / raw)
To: Olof Johansson
Cc: Suravee Suthikulanit, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Arnd Bergmann,
Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
arm-DgEjT+Ai2ygdnm+yROfE0A, Rob Herring, leo.duran-5C7GfCeVMHo,
Kumar Gala, Thomas Lendacky,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
brijeshkumar.singh-5C7GfCeVMHo
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
@ 2016-01-30 1:02 ` Frank Rowand
0 siblings, 0 replies; 93+ messages in thread
From: Frank Rowand @ 2016-01-30 1:02 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-01-28 14:27 ` Will Deacon
@ 2016-03-30 15:37 ` Eric Auger
-1 siblings, 0 replies; 93+ messages in thread
From: Eric Auger @ 2016-03-30 15:37 UTC (permalink / raw)
To: Will Deacon, Arnd Bergmann
Cc: Mark Rutland, devicetree, arm, pawel.moll, ijc+devicetree,
linux-kernel, robh+dt, leo.duran, Suravee Suthikulpanit, galak,
thomas.lendacky, Robin Murphy, linux-arm-kernel,
brijeshkumar.singh, Christoffer Dall, 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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 15:37 ` Eric Auger
0 siblings, 0 replies; 93+ messages in thread
From: Eric Auger @ 2016-03-30 15:37 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 15:45 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-03-30 15:45 UTC (permalink / raw)
To: Eric Auger
Cc: Arnd Bergmann, Mark Rutland, devicetree, arm, pawel.moll,
ijc+devicetree, linux-kernel, robh+dt, leo.duran,
Suravee Suthikulpanit, galak, thomas.lendacky, Robin Murphy,
linux-arm-kernel, brijeshkumar.singh, Christoffer Dall,
eric.auger
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 15:45 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-03-30 15:45 UTC (permalink / raw)
To: Eric Auger
Cc: Arnd Bergmann, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
arm-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, leo.duran-5C7GfCeVMHo,
Suravee Suthikulpanit, galak-sgV2jX0FEOL9JmXXK+q4OQ,
thomas.lendacky-5C7GfCeVMHo, Robin Murphy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
brijeshkumar.singh-5C7GfCeVMHo, Christoffer Dall,
eric.auger-qxv4g6HH51o
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 15:45 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-03-30 15:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi Eric,
On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
> On 01/28/2016 03:27 PM, Will Deacon wrote:
> > 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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 15:57 ` Eric Auger
0 siblings, 0 replies; 93+ messages in thread
From: Eric Auger @ 2016-03-30 15:57 UTC (permalink / raw)
To: Will Deacon
Cc: Arnd Bergmann, Mark Rutland, devicetree, arm, pawel.moll,
ijc+devicetree, linux-kernel, robh+dt, leo.duran,
Suravee Suthikulpanit, galak, thomas.lendacky, Robin Murphy,
linux-arm-kernel, brijeshkumar.singh, Christoffer Dall,
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 15:57 ` Eric Auger
0 siblings, 0 replies; 93+ messages in thread
From: Eric Auger @ 2016-03-30 15:57 UTC (permalink / raw)
To: Will Deacon
Cc: Arnd Bergmann, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
arm-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, leo.duran-5C7GfCeVMHo,
Suravee Suthikulpanit, galak-sgV2jX0FEOL9JmXXK+q4OQ,
thomas.lendacky-5C7GfCeVMHo, Robin Murphy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
brijeshkumar.singh-5C7GfCeVMHo, Christoffer Dall,
eric.auger-qxv4g6HH51o
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 15:57 ` Eric Auger
0 siblings, 0 replies; 93+ messages in thread
From: Eric Auger @ 2016-03-30 15:57 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-03-30 15:57 ` Eric Auger
@ 2016-03-30 17:24 ` Will Deacon
-1 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-03-30 17:24 UTC (permalink / raw)
To: Eric Auger
Cc: Arnd Bergmann, Mark Rutland, devicetree, arm, pawel.moll,
ijc+devicetree, linux-kernel, robh+dt, leo.duran,
Suravee Suthikulpanit, galak, thomas.lendacky, Robin Murphy,
linux-arm-kernel, brijeshkumar.singh, Christoffer Dall,
eric.auger
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-30 17:24 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-03-30 17:24 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-03-30 17:24 ` Will Deacon
@ 2016-03-31 7:39 ` Eric Auger
-1 siblings, 0 replies; 93+ messages in thread
From: Eric Auger @ 2016-03-31 7:39 UTC (permalink / raw)
To: Will Deacon
Cc: Arnd Bergmann, Mark Rutland, devicetree, arm, pawel.moll,
ijc+devicetree, linux-kernel, robh+dt, leo.duran,
Suravee Suthikulpanit, galak, thomas.lendacky, Robin Murphy,
linux-arm-kernel, brijeshkumar.singh, Christoffer Dall,
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-31 7:39 ` Eric Auger
0 siblings, 0 replies; 93+ messages in thread
From: Eric Auger @ 2016-03-31 7:39 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
2016-03-31 7:39 ` Eric Auger
@ 2016-03-31 17:34 ` Will Deacon
-1 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-03-31 17:34 UTC (permalink / raw)
To: Eric Auger
Cc: Arnd Bergmann, Mark Rutland, devicetree, arm, pawel.moll,
ijc+devicetree, linux-kernel, robh+dt, leo.duran,
Suravee Suthikulpanit, galak, thomas.lendacky, Robin Murphy,
linux-arm-kernel, brijeshkumar.singh, Christoffer Dall,
eric.auger
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
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node
@ 2016-03-31 17:34 ` Will Deacon
0 siblings, 0 replies; 93+ messages in thread
From: Will Deacon @ 2016-03-31 17:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 93+ messages in thread
end of thread, other threads:[~2016-03-31 17:34 UTC | newest]
Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-27 21:11 [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-28 4:49 ` Martin Michlmayr
2016-01-28 4:49 ` Martin Michlmayr
2016-01-28 4:49 ` Martin Michlmayr
2016-01-27 21:11 ` [PATCH 02/13] dtb: amd: Fix GICv2 hypervisor and virtual interface sizes Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 03/13] dtb: amd: Fix DMA ranges in device tree Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 04/13] dtb: amd: Fix typo in SPI device nodes Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 05/13] dtb: amd: Misc changes for I2C " Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 06/13] dtb: amd: Misc changes for SATA device tree nodes Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 07/13] dtb: amd: Misc changes for GPIO devices Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 08/13] dtb: amd: Add PERF CCN-504 device tree node Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 09/13] dtb: amd: Add KCS " Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 10/13] dtb: amd: Add AMD XGBE device tree file Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-27 21:11 ` Suravee Suthikulpanit
2016-01-28 11:14 ` Mark Rutland
2016-01-28 11:14 ` Mark Rutland
2016-01-28 11:17 ` Will Deacon
2016-01-28 11:17 ` Will Deacon
2016-01-28 11:17 ` Will Deacon
2016-01-28 11:18 ` Mark Rutland
2016-01-28 11:18 ` Mark Rutland
2016-01-28 11:18 ` Mark Rutland
2016-01-28 11:19 ` Will Deacon
2016-01-28 11:19 ` Will Deacon
2016-01-28 11:19 ` Will Deacon
2016-01-28 12:20 ` Robin Murphy
2016-01-28 12:20 ` Robin Murphy
2016-01-28 14:17 ` Arnd Bergmann
2016-01-28 14:17 ` Arnd Bergmann
2016-01-28 14:17 ` Arnd Bergmann
2016-01-28 14:27 ` Will Deacon
2016-01-28 14:27 ` Will Deacon
2016-01-28 14:27 ` Will Deacon
2016-03-30 15:37 ` Eric Auger
2016-03-30 15:37 ` Eric Auger
2016-03-30 15:45 ` Will Deacon
2016-03-30 15:45 ` Will Deacon
2016-03-30 15:45 ` Will Deacon
2016-03-30 15:57 ` Eric Auger
2016-03-30 15:57 ` Eric Auger
2016-03-30 15:57 ` Eric Auger
2016-03-30 17:24 ` Will Deacon
2016-03-30 17:24 ` Will Deacon
2016-03-31 7:39 ` Eric Auger
2016-03-31 7:39 ` Eric Auger
2016-03-31 17:34 ` Will Deacon
2016-03-31 17:34 ` Will Deacon
2016-01-27 21:12 ` [PATCH 12/13] dtb: amd: Add support for new AMD Overdrive boards Suravee Suthikulpanit
2016-01-27 21:12 ` Suravee Suthikulpanit
2016-01-27 21:12 ` Suravee Suthikulpanit
2016-01-27 21:12 ` [PATCH 13/13] dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board Suravee Suthikulpanit
2016-01-27 21:12 ` Suravee Suthikulpanit
2016-01-27 21:12 ` Suravee Suthikulpanit
2016-01-28 21:39 ` [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS Olof Johansson
2016-01-28 21:39 ` Olof Johansson
2016-01-28 21:39 ` Olof Johansson
2016-01-28 22:20 ` Suravee Suthikulanit
2016-01-28 22:20 ` Suravee Suthikulanit
2016-01-28 22:20 ` Suravee Suthikulanit
2016-01-29 2:43 ` Olof Johansson
2016-01-29 2:43 ` Olof Johansson
2016-01-29 2:43 ` Olof Johansson
2016-01-30 0:02 ` Suravee Suthikulanit
2016-01-30 0:02 ` Suravee Suthikulanit
2016-01-30 0:02 ` Suravee Suthikulanit
2016-01-30 1:02 ` Frank Rowand
2016-01-30 1:02 ` Frank Rowand
2016-01-30 1:02 ` Frank Rowand
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.