Re: [PATCH 0/5] iommu/arm-smmu-v3: power domain and clock of the RK3588 PCIe SMMU

["Heiko Stübner" <heiko@sntech.de>]

Am Mittwoch, 11. November 2026, 09:02:30 Mitteleuropäische Normalzeit schrieb Shawn Lin:
> Hi Heiko
> 
> 在 2026/11/10 星期二 16:49, Heiko Stübner 写道:
> > Am Dienstag, 10. November 2026, 09:40:44 Mitteleuropäische Normalzeit schrieb Shawn Lin:
> >> Cc: Simon and Finley
> >>
> >> 在 2026/11/10 星期二 15:11, 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 describes
> >>> neither the power domain it lives in (RK3588_PD_PCIE) nor its clock
> >>> (ACLK_MMU_PCIE). Both are held by any enabled PCIe controller, which is
> >>> why nobody noticed: on a board that enables no PCIe controller in that
> >>> domain (an Orange Pi 5 with its M.2 slot in SATA mode, or any RK3588
> >>> board without PCIe), genpd powers the domain off and the clock framework
> >>> gates the clock as unused after boot, while arm-smmu-v3 stays bound.
> >>> At reboot, arm_smmu_device_shutdown() then writes CR0 and polls CR0ACK on
> >>> the dead block, the interconnect stalls, "reboot: Restarting system" is
> >>> never reached and the board only comes back ~90 s later when the
> >>> watchdog fires.
> > 
> > We have a work-around for that in some boards, manually disabling the
> > smmu until now. As the SMMU is part of the SoC and always present
> > the general DT practice is to have it always enabled, as it does not
> > depend on the actual board design.
> > 
> > Hence we end up in the situation described above.
> > 
> 
> I notice that mmu600_php is disabled in rk3588-base.dtsi. If describing
> the SMMU that way is incorrect, should we enable mmu600_php as well? I'm
> asking because I see a different picture in the RK3588 TRM: both
> mmu600_php and mmu600_pcie reside under PD_PHP, not PD_PCIE. Therefore,
> even without any PCIe controller enabled, PD_PHP should remain powered
> on (it is never added in rk3588-base.dtsi, so it should be outside the
> kernel’s scope). How does the original problem occur in that case?

The original problem is the smmu probing (probably during boot when
everything is still powered), not doing anything with it and on shutdown
the smmu driver wanting to access the smmu registers and thus ending
in a hang.

So the problem is not necessarily the power-domain, but can also be
the clocks getting turned off during clk_disable_unused.


As for not disabling it, the case is also the some for things like the
video-encoders - they are also present all the time, so we don't have
devicetree wiggling for them.

The fully correct thing would be, power-domain + clock handling
and adding runtime-pm to the smmu for when it is not in use.
So this would then not require any special thinking

And yes, I think the other smmu should also use the same handling.

@Arun care to also add a runtime-pm patch? :-)


Heiko