[PATCH v2 0/4] iommu/arm-smmu-v3: Keep the clock of the RK3588 PCIe SMMU running

[PATCH v2 0/4] iommu/arm-smmu-v3: Keep the clock of the RK3588 PCIe SMMU running

[Arun Iyengar via B4 Relay]

The MMU-600 in front of the PCIe controllers of the Rockchip RK3588
(mmu600_pcie) is enabled for every RK3588 board, but its node does not
describe its clock (ACLK_MMU_PCIE). Any enabled PCIe controller holds
that clock, which is why nobody noticed: on a board that enables none
of them (an Orange Pi 5 with its M.2 slot in SATA mode, or any RK3588
board without PCIe), the clock framework gates the clock as unused
after boot, while arm-smmu-v3 stays bound. The SMMU registers then stop
responding: at reboot, arm_smmu_device_shutdown() writes CR0 and polls
CR0ACK, "reboot: Restarting system" is never reached and the board only
comes back ~90 s later when the watchdog fires.

Patch 1 allows a single clock and a single reset in the arm,smmu-v3
binding (arm,smmu.yaml already allows clocks for the earlier SMMUs).
Patch 2 makes the driver get and enable the optional clock of its
firmware node first in probe, before any register access, for as long
as it is bound; nodes without a clock (and ACPI/IORT systems) are
unaffected. Patch 3 describes the clock in rk3588-base.dtsi, and patch
4 the reset (SRST_A_MMU_PCIE). Patches 1 and 2 are for the iommu tree,
patches 3 and 4 for the Rockchip tree once the binding is accepted.

This series is related to Pranjal Shrivastava's "iommu/arm-smmu-v3:
Implement Runtime/System Sleep ops" v11 (2026-09-29,
20260929034510.2023173-1-praan@google.com, not merged), which adds
pm_domain-based runtime PM and resumes the SMMU around shutdown, but has
no clock handling. The two are compatible: once it lands, the clock from
patch 2 should move into its runtime suspend/resume callbacks.

The second MMU-600 of the RK3588 (mmu600_php), which Shawn Lin asked
about, is disabled in rk3588-base.dtsi and is not changed here. Giving
it the same handling, as Heiko Stuebner suggested, needs a test with
that SMMU enabled and is left for a separate series.

Tested on an Orange Pi 5 (RK3588S) with the M.2 slot in SATA mode and
the root filesystem on the SATA SSD, where every reboot used to hang.
v1 (clock and PD_PCIE power domain): three consecutive reboots printed
"reboot: Restarting system" and the boot loader started 0.6 s later
(previously ~89 s, from the watchdog); clk_summary showed aclk_mmu_pcie
enabled with iommu@fc900000 as consumer; the SMMU probed as before and
SATA kept running at 6.0 Gbps without errors. With the power domain
alone (clock still gated) the reboot still hung at "arm-smmu-v3
fc900000.iommu: shutdown" on the serial console. Boards with PCIe
enabled are already in the state this series describes.

v2 (clock only, no power domain; patches 2 and 3, together with the
separately sent CMDQV fix, on a 7.3 kernel):
again three consecutive reboots printed "reboot: Restarting system" and
the boot loader started 0.59 s later each time; clk_summary showed
aclk_mmu_pcie enabled with fc900000.iommu as consumer; arm-smmu-v3
probed without errors or deferrals in all four boots; the root
filesystem stayed on the SATA SSD at 6.0 Gbps with no ATA errors, and
the kernel log had no warnings.

Patch 4 only completes the hardware description: the driver does not
use the reset, which is already deasserted at boot, so the board test of
the clock change covers all functional changes of this series.

This series was developed with Claude (Anthropic) as a coding assistant:
it wrote the code and the commit messages, and I reviewed and tested
every change as described above.

Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
Changes in v2:
- The existing Tegra CMDQV reference leak on a bad #iommu-cells that
  the Sashiko AI review of v1 found is fixed in a separate patch,
  "iommu/arm-smmu-v3: Don't leak the CMDQV device on a bad
  #iommu-cells", as it is not related to this series.
- Dropped the v1 patches that allowed power-domains in the binding and
  put the SMMU in RK3588_PD_PCIE: the TRM puts MMU600_PCIE in PD_PHP,
  which Linux does not control (rk3588-base.dtsi has no PD_PHP node), so
  no power domain is needed (Sebastian Reichel, Shawn Lin). The hang was
  the clock alone, now tested on its own.
- Binding: allow a single clock with a description instead of up to
  four unconstrained clocks, and say why in the commit message (Sashiko
  AI review, Sebastian Reichel).
- Driver: get one optional clock to match the binding, and get it
  before the firmware probe, so that a failure or -EPROBE_DEFER cannot
  leak the CMDQV device reference (Sashiko AI review). Its comment now
  only says why the clock is got first (Sebastian Reichel). Sebastian's
  Reviewed-by of v1 is not carried over, as the patch changed.
- DTS: the clock patch's commit message now gives the whole cause on
  its own (clock gated as unused, SMMU registers no longer respond, hang
  in arm_smmu_device_shutdown()). Its diff is the same as in v1, so
  Sebastian's Reviewed-by is kept.
- Added the reset line to the binding and the PCIe SMMU node (new
  patch 4) (Sebastian Reichel).
- Capitalized the patch subjects.
- Link to v1: https://patch.msgid.link/20261110-smmu-v3-pcie-pd-v1-0-628819ca44b9@gmail.com

---
Arun Iyengar (4):
      dt-bindings: iommu: arm,smmu-v3: Allow a clock and a reset
      iommu/arm-smmu-v3: Enable an optional clock
      arm64: dts: rockchip: Add the clock of the RK3588 PCIe SMMU
      arm64: dts: rockchip: Add the reset of the RK3588 PCIe SMMU

 Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 11 +++++++++++
 arch/arm64/boot/dts/rockchip/rk3588-base.dtsi            |  2 ++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c              | 11 +++++++++++
 3 files changed, 24 insertions(+)
---
base-commit: 2cf4be57b301ed2d7af82e70cff5dfd96894d8de
change-id: 20261110-smmu-v3-pcie-pd-a2f127b81d8f

Best regards,
--  
Arun Iyengar <aiyengar1990@gmail.com>

[PATCH v2 1/4] dt-bindings: iommu: arm,smmu-v3: Allow a clock and a reset

[Arun Iyengar via B4 Relay]

From: Arun Iyengar <aiyengar1990@gmail.com>

Some SoCs feed the SMMUv3 from a clock that the OS controls. On the
Rockchip RK3588 the MMU-600 for PCIe runs from ACLK_MMU_PCIE, whose only
other consumers are the PCIe controllers. When no PCIe controller is
enabled, the clock framework gates it as unused, and the SMMU can no
longer be accessed. The same SMMU also has a reset line in the CRU,
SRST_A_MMU_PCIE.

Allow a single clock and a single reset, so that both can be described.
The architecture defines no clock or reset inputs; the MMU-600 TRM lists
one clock and one reset signal, and the one integration that needs this
has one of each. An implementation with more clocks or resets can add
them with names and a specific compatible.

Link: https://support.arm.com/documentation/100310/0202/Signal-descriptions/Clock-and-reset-signals
Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
 Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
index 3c044e4f03d4..29b81b4fb650 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
@@ -63,6 +63,17 @@ properties:
 
   msi-parent: true
 
+  clocks:
+    maxItems: 1
+    description:
+      Clock of the SMMU's register and memory interfaces, on SoCs where the
+      OS has to keep it running.
+
+  resets:
+    maxItems: 1
+    description:
+      Reset of the SMMU, on SoCs where it is controlled by the OS.
+
   nvidia,cmdqv:
     description: |
       A phandle to its pairing CMDQV extension for an implementation on NVIDIA

-- 
2.55.0

[PATCH v2 2/4] iommu/arm-smmu-v3: Enable an optional clock

[Arun Iyengar via B4 Relay]

From: Arun Iyengar <aiyengar1990@gmail.com>

On some platforms the SMMU's clock is controlled by the OS, and without a
consumer the clock framework gates it as unused late in boot. Any later
register access, for example the CR0 write in the shutdown path, then
hangs. This happens on the RK3588 when no PCIe controller keeps the PCIe
MMU-600 clock running.

Get and enable the clock described in the firmware node, if there is
one, and keep it enabled while the driver is bound. Do it first in
probe: the firmware probe may take a reference on the Tegra CMDQV device
that only arm_smmu_impl_probe() releases, so a failure (or deferral)
between the two would leak it. Nodes without a clock and ACPI systems
are not affected.

Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 6d4520c47308..d3f42316b0d6 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -12,6 +12,7 @@
 #include <linux/acpi.h>
 #include <linux/acpi_iort.h>
 #include <linux/bitops.h>
+#include <linux/clk.h>
 #include <linux/crash_dump.h>
 #include <linux/delay.h>
 #include <linux/err.h>
@@ -5786,12 +5787,22 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
 	resource_size_t ioaddr;
 	struct arm_smmu_device *smmu;
 	struct device *dev = &pdev->dev;
+	struct clk *clk;
 
 	smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
 	if (!smmu)
 		return -ENOMEM;
 	smmu->dev = dev;
 
+	/*
+	 * Before the firmware probe: it may take a reference on the Tegra
+	 * CMDQV device that only arm_smmu_impl_probe() releases.
+	 */
+	clk = devm_clk_get_optional_enabled(dev, NULL);
+	if (IS_ERR(clk))
+		return dev_err_probe(dev, PTR_ERR(clk),
+				     "failed to enable clock\n");
+
 	if (dev->of_node) {
 		ret = arm_smmu_device_dt_probe(pdev, smmu);
 	} else {

-- 
2.55.0

[PATCH v2 3/4] arm64: dts: rockchip: Add the clock of the RK3588 PCIe SMMU

[Arun Iyengar via B4 Relay]

From: Arun Iyengar <aiyengar1990@gmail.com>

The MMU-600 for the PCIe controllers (mmu600_pcie) is enabled for every
RK3588 board, but its node does not describe its clock, ACLK_MMU_PCIE.
That gate is also the parent of the PCIe controllers' master clocks, so
on most boards an enabled PCIe controller keeps it running.

On a board that enables none of these PCIe controllers (the Orange Pi 5
with its M.2 slot in SATA mode is one), nothing holds the clock and it
is gated as unused late in boot, while arm-smmu-v3 is still bound to the
SMMU. The SMMU registers then stop responding: at reboot,
arm_smmu_device_shutdown() writes CR0 and polls CR0ACK, the kernel never
reaches "reboot: Restarting system" and the board only comes back once
the watchdog fires.

Describe the clock, so that the SMMU driver keeps it running for as long
as it is bound.

Fixes: da92d3dfc871 ("arm64: dts: rockchip: enable the mmu600_pcie IOMMU on the rk3588 SoC")
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index aa69fd3793fd..dfed34a8aa57 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -559,6 +559,7 @@ mmu600_pcie: iommu@fc900000 {
 			     <GIC_SPI 374 IRQ_TYPE_EDGE_RISING 0>,
 			     <GIC_SPI 367 IRQ_TYPE_EDGE_RISING 0>;
 		interrupt-names = "eventq", "gerror", "priq", "cmdq-sync";
+		clocks = <&cru ACLK_MMU_PCIE>;
 		#iommu-cells = <1>;
 	};
 

-- 
2.55.0

[PATCH v2 4/4] arm64: dts: rockchip: Add the reset of the RK3588 PCIe SMMU

[Arun Iyengar via B4 Relay]

From: Arun Iyengar <aiyengar1990@gmail.com>

The MMU-600 for the PCIe controllers (mmu600_pcie) has a reset line in
the CRU, SRST_A_MMU_PCIE, which its node does not describe. Add it, so
that the node describes both the clock and the reset of the MMU-600.

Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index dfed34a8aa57..45c1bb335447 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -560,6 +560,7 @@ mmu600_pcie: iommu@fc900000 {
 			     <GIC_SPI 367 IRQ_TYPE_EDGE_RISING 0>;
 		interrupt-names = "eventq", "gerror", "priq", "cmdq-sync";
 		clocks = <&cru ACLK_MMU_PCIE>;
+		resets = <&cru SRST_A_MMU_PCIE>;
 		#iommu-cells = <1>;
 	};
 

-- 
2.55.0

Re: [PATCH v2 4/4] arm64: dts: rockchip: Add the reset of the RK3588 PCIe SMMU

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Hi,

On Thu, Nov 12, 2026 at 08:20:25AM +0000, Arun Iyengar via B4 Relay wrote:
> From: Arun Iyengar <aiyengar1990@gmail.com>
> 
> The MMU-600 for the PCIe controllers (mmu600_pcie) has a reset line in
> the CRU, SRST_A_MMU_PCIE, which its node does not describe. Add it, so
> that the node describes both the clock and the reset of the MMU-600.
> 
> Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
> ---

squash this into the previous commit.

-- Sebastian

>  arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> index dfed34a8aa57..45c1bb335447 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
> @@ -560,6 +560,7 @@ mmu600_pcie: iommu@fc900000 {
>  			     <GIC_SPI 367 IRQ_TYPE_EDGE_RISING 0>;
>  		interrupt-names = "eventq", "gerror", "priq", "cmdq-sync";
>  		clocks = <&cru ACLK_MMU_PCIE>;
> +		resets = <&cru SRST_A_MMU_PCIE>;
>  		#iommu-cells = <1>;
>  	};
>  
> 
> -- 
> 2.55.0
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 1/4] dt-bindings: iommu: arm,smmu-v3: Allow a clock and a reset

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

Hi,

On Thu, Nov 12, 2026 at 08:20:22AM +0000, Arun Iyengar via B4 Relay wrote:
> From: Arun Iyengar <aiyengar1990@gmail.com>
> 
> Some SoCs feed the SMMUv3 from a clock that the OS controls. On the
> Rockchip RK3588 the MMU-600 for PCIe runs from ACLK_MMU_PCIE, whose only
> other consumers are the PCIe controllers. When no PCIe controller is
> enabled, the clock framework gates it as unused, and the SMMU can no
> longer be accessed. The same SMMU also has a reset line in the CRU,
> SRST_A_MMU_PCIE.
> 
> Allow a single clock and a single reset, so that both can be described.
> The architecture defines no clock or reset inputs; the MMU-600 TRM lists
> one clock and one reset signal, and the one integration that needs this
> has one of each. An implementation with more clocks or resets can add
> them with names and a specific compatible.

You can trim that down quite a bit. Don't take over AI text 1:1.

> 
> Link: https://support.arm.com/documentation/100310/0202/Signal-descriptions/Clock-and-reset-signals
> Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index 3c044e4f03d4..29b81b4fb650 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -63,6 +63,17 @@ properties:
>  
>    msi-parent: true
>  
> +  clocks:
> +    maxItems: 1
> +    description:
> +      Clock of the SMMU's register and memory interfaces, on SoCs where the
> +      OS has to keep it running.
> +
> +  resets:
> +    maxItems: 1
> +    description:
> +      Reset of the SMMU, on SoCs where it is controlled by the OS.

The ', on SoCs where it is controlled by the OS.' is completley
useless for both. You need to review your AI output and not take
it over without doing any thinking yourself.

Greetings,

-- Sebastian

>    nvidia,cmdqv:
>      description: |
>        A phandle to its pairing CMDQV extension for an implementation on NVIDIA
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]