From: Niklas Cassel <cassel@kernel.org>
To: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: Damien Le Moal <dlemoal@kernel.org>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Niklas Cassel <cassel@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: [PATCH] arm64: dts: rockchip: enable the mmu600_pcie IOMMU on the rk3588 SoC
Date: Thu, 7 Nov 2024 13:37:33 +0100 [thread overview]
Message-ID: <20241107123732.1160063-2-cassel@kernel.org> (raw)
Commit cd81d3a0695c ("arm64: dts: rockchip: add rk3588 pcie and php
IOMMUs") added the rk3588 SoC's pcie IOMMU and php IOMMU as disabled.
The mmu600_pcie is connected with the five PCIe controllers.
See 8.2 Block Diagram, in rk3588 TRM (Technical Reference Manual).
The five PCIe controllers are:
pcie3x4, pcie3x2, pcie2x1l0, pcie2x1l1, pcie2x1l2.
pcie3x4 can run in either Root Complex mode or Endpoint mode, the other
four PCIe controllers can only run in Root Complex mode. To describe this
we thus have six different device nodes in the device tree.
A PCIe controller in Root Complex mode needs to specify an iommu-map, such
that the device knows how to convert a Requester ID (PCI BDF) to an IOMMU
master ID (stream ID). (A PCIe controller in Endpoint mode should use the
iommus property, just like a regular device.)
If you look at the device tree bindings for msi-map and iommu-map, you can
see that the conversion from Requester ID to MSI-specifier data is the same
as the conversion from Requester ID to IOMMU specifier data. Thus it is
sensible to define the iommu-map property value similar to the msi-map,
such that the conversion will be identical.
Add the proper iommu device tree properties for these six device nodes
connected to the mmu600_pcie, so that we can enable the mmu600_pcie IOMMU.
(The mmu600_php IOMMU is not touched, so it is still disabled.)
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
Testing done:
-pcie2x1l2: Ethernet connected to the pcie2x1l2 works as expected.
-pcie3x4: A PCIe endpoint (running the PCI endpoint framework) connected to
pcie3x4 can run pcitest.sh without any issues.
Modifying the PCI endpoint to DMA to an invalid address gives IOMMU errors
(as expected).
-pcie3x4_ep: A PCIe root complex (running Linux) connected to pcie3x4_ep can
run pcitest.sh without any issues.
Modifying the PCI endpoint's inbound address translation to point to a
buffer that has not been mapped using the DMA API, results in IOMMU errors
when the RC writes to the PCI BARs exposed by the endpoint (as expected).
-My board does not expose a convenient method to test the other PCIe
controllers, but considering that the ones that I did test worked fine,
I do not see any reason why the others should not do the same.
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 3 ++-
| 4 ++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index d97d84b888375..f96e607db2857 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -551,7 +551,6 @@ mmu600_pcie: iommu@fc900000 {
<GIC_SPI 367 IRQ_TYPE_LEVEL_HIGH 0>;
interrupt-names = "eventq", "gerror", "priq", "cmdq-sync";
#iommu-cells = <1>;
- status = "disabled";
};
mmu600_php: iommu@fcb00000 {
@@ -1641,6 +1640,7 @@ pcie2x1l1: pcie@fe180000 {
linux,pci-domain = <3>;
max-link-speed = <2>;
msi-map = <0x3000 &its0 0x3000 0x1000>;
+ iommu-map = <0x3000 &mmu600_pcie 0x3000 0x1000>;
num-lanes = <1>;
phys = <&combphy2_psu PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
@@ -1692,6 +1692,7 @@ pcie2x1l2: pcie@fe190000 {
linux,pci-domain = <4>;
max-link-speed = <2>;
msi-map = <0x4000 &its0 0x4000 0x1000>;
+ iommu-map = <0x4000 &mmu600_pcie 0x4000 0x1000>;
num-lanes = <1>;
phys = <&combphy0_ps PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index 0ce0934ec6b79..4a950907ea6f5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -162,6 +162,7 @@ pcie3x4: pcie@fe150000 {
linux,pci-domain = <0>;
max-link-speed = <3>;
msi-map = <0x0000 &its1 0x0000 0x1000>;
+ iommu-map = <0x0000 &mmu600_pcie 0x0000 0x1000>;
num-lanes = <4>;
phys = <&pcie30phy>;
phy-names = "pcie-phy";
@@ -212,6 +213,7 @@ pcie3x4_ep: pcie-ep@fe150000 {
interrupt-names = "sys", "pmc", "msg", "legacy", "err",
"dma0", "dma1", "dma2", "dma3";
max-link-speed = <3>;
+ iommus = <&mmu600_pcie 0x0000>;
num-lanes = <4>;
phys = <&pcie30phy>;
phy-names = "pcie-phy";
@@ -248,6 +250,7 @@ pcie3x2: pcie@fe160000 {
linux,pci-domain = <1>;
max-link-speed = <3>;
msi-map = <0x1000 &its1 0x1000 0x1000>;
+ iommu-map = <0x1000 &mmu600_pcie 0x1000 0x1000>;
num-lanes = <2>;
phys = <&pcie30phy>;
phy-names = "pcie-phy";
@@ -297,6 +300,7 @@ pcie2x1l0: pcie@fe170000 {
linux,pci-domain = <2>;
max-link-speed = <2>;
msi-map = <0x2000 &its0 0x2000 0x1000>;
+ iommu-map = <0x2000 &mmu600_pcie 0x2000 0x1000>;
num-lanes = <1>;
phys = <&combphy1_ps PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
--
2.47.0
WARNING: multiple messages have this Message-ID (diff)
From: Niklas Cassel <cassel@kernel.org>
To: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: Damien Le Moal <dlemoal@kernel.org>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Niklas Cassel <cassel@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: [PATCH] arm64: dts: rockchip: enable the mmu600_pcie IOMMU on the rk3588 SoC
Date: Thu, 7 Nov 2024 13:37:33 +0100 [thread overview]
Message-ID: <20241107123732.1160063-2-cassel@kernel.org> (raw)
Commit cd81d3a0695c ("arm64: dts: rockchip: add rk3588 pcie and php
IOMMUs") added the rk3588 SoC's pcie IOMMU and php IOMMU as disabled.
The mmu600_pcie is connected with the five PCIe controllers.
See 8.2 Block Diagram, in rk3588 TRM (Technical Reference Manual).
The five PCIe controllers are:
pcie3x4, pcie3x2, pcie2x1l0, pcie2x1l1, pcie2x1l2.
pcie3x4 can run in either Root Complex mode or Endpoint mode, the other
four PCIe controllers can only run in Root Complex mode. To describe this
we thus have six different device nodes in the device tree.
A PCIe controller in Root Complex mode needs to specify an iommu-map, such
that the device knows how to convert a Requester ID (PCI BDF) to an IOMMU
master ID (stream ID). (A PCIe controller in Endpoint mode should use the
iommus property, just like a regular device.)
If you look at the device tree bindings for msi-map and iommu-map, you can
see that the conversion from Requester ID to MSI-specifier data is the same
as the conversion from Requester ID to IOMMU specifier data. Thus it is
sensible to define the iommu-map property value similar to the msi-map,
such that the conversion will be identical.
Add the proper iommu device tree properties for these six device nodes
connected to the mmu600_pcie, so that we can enable the mmu600_pcie IOMMU.
(The mmu600_php IOMMU is not touched, so it is still disabled.)
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
Testing done:
-pcie2x1l2: Ethernet connected to the pcie2x1l2 works as expected.
-pcie3x4: A PCIe endpoint (running the PCI endpoint framework) connected to
pcie3x4 can run pcitest.sh without any issues.
Modifying the PCI endpoint to DMA to an invalid address gives IOMMU errors
(as expected).
-pcie3x4_ep: A PCIe root complex (running Linux) connected to pcie3x4_ep can
run pcitest.sh without any issues.
Modifying the PCI endpoint's inbound address translation to point to a
buffer that has not been mapped using the DMA API, results in IOMMU errors
when the RC writes to the PCI BARs exposed by the endpoint (as expected).
-My board does not expose a convenient method to test the other PCIe
controllers, but considering that the ones that I did test worked fine,
I do not see any reason why the others should not do the same.
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 3 ++-
| 4 ++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index d97d84b888375..f96e607db2857 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -551,7 +551,6 @@ mmu600_pcie: iommu@fc900000 {
<GIC_SPI 367 IRQ_TYPE_LEVEL_HIGH 0>;
interrupt-names = "eventq", "gerror", "priq", "cmdq-sync";
#iommu-cells = <1>;
- status = "disabled";
};
mmu600_php: iommu@fcb00000 {
@@ -1641,6 +1640,7 @@ pcie2x1l1: pcie@fe180000 {
linux,pci-domain = <3>;
max-link-speed = <2>;
msi-map = <0x3000 &its0 0x3000 0x1000>;
+ iommu-map = <0x3000 &mmu600_pcie 0x3000 0x1000>;
num-lanes = <1>;
phys = <&combphy2_psu PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
@@ -1692,6 +1692,7 @@ pcie2x1l2: pcie@fe190000 {
linux,pci-domain = <4>;
max-link-speed = <2>;
msi-map = <0x4000 &its0 0x4000 0x1000>;
+ iommu-map = <0x4000 &mmu600_pcie 0x4000 0x1000>;
num-lanes = <1>;
phys = <&combphy0_ps PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index 0ce0934ec6b79..4a950907ea6f5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -162,6 +162,7 @@ pcie3x4: pcie@fe150000 {
linux,pci-domain = <0>;
max-link-speed = <3>;
msi-map = <0x0000 &its1 0x0000 0x1000>;
+ iommu-map = <0x0000 &mmu600_pcie 0x0000 0x1000>;
num-lanes = <4>;
phys = <&pcie30phy>;
phy-names = "pcie-phy";
@@ -212,6 +213,7 @@ pcie3x4_ep: pcie-ep@fe150000 {
interrupt-names = "sys", "pmc", "msg", "legacy", "err",
"dma0", "dma1", "dma2", "dma3";
max-link-speed = <3>;
+ iommus = <&mmu600_pcie 0x0000>;
num-lanes = <4>;
phys = <&pcie30phy>;
phy-names = "pcie-phy";
@@ -248,6 +250,7 @@ pcie3x2: pcie@fe160000 {
linux,pci-domain = <1>;
max-link-speed = <3>;
msi-map = <0x1000 &its1 0x1000 0x1000>;
+ iommu-map = <0x1000 &mmu600_pcie 0x1000 0x1000>;
num-lanes = <2>;
phys = <&pcie30phy>;
phy-names = "pcie-phy";
@@ -297,6 +300,7 @@ pcie2x1l0: pcie@fe170000 {
linux,pci-domain = <2>;
max-link-speed = <2>;
msi-map = <0x2000 &its0 0x2000 0x1000>;
+ iommu-map = <0x2000 &mmu600_pcie 0x2000 0x1000>;
num-lanes = <1>;
phys = <&combphy1_ps PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
--
2.47.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next reply other threads:[~2024-11-07 12:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 12:37 Niklas Cassel [this message]
2024-11-07 12:37 ` [PATCH] arm64: dts: rockchip: enable the mmu600_pcie IOMMU on the rk3588 SoC Niklas Cassel
2024-11-18 11:52 ` Niklas Cassel
2024-11-18 11:52 ` Niklas Cassel
2024-11-18 13:24 ` Heiko Stübner
2024-11-18 13:24 ` Heiko Stübner
2024-12-02 23:29 ` Heiko Stuebner
2024-12-02 23:29 ` Heiko Stuebner
2025-08-06 19:36 ` Heiko Stübner
2025-08-06 19:36 ` Heiko Stübner
2025-08-13 18:42 ` Niklas Cassel
2025-08-13 18:42 ` Niklas Cassel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241107123732.1160063-2-cassel@kernel.org \
--to=cassel@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlemoal@kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.