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

[Shawn Lin <shawn.lin@rock-chips.com>]

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