Hi,

On Wed, Nov 11, 2026 at 10:53:28AM +0100, Heiko Stübner wrote:
> 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? :-)

Adding runtime PM support is already WIP:

https://lore.kernel.org/all/20260929034510.2023173-1-praan@google.com/

(this is also needed to avoid potential crashes with system
suspend/resume on RK3588, since we enable PCIe IOMMU by default)

Greetings,

-- Sebastian