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

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

> So this series fixes the actual underlying problem, making these
> workarounds unnecessary in the future :-)
>
>
> So definitly thanks a lot
> Heiko