From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 054B3606A327 for ; Wed, 11 Nov 2026 09:53:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=XqqQdXRl; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.a=rsa-sha256 header.s=gloria202408 header.b=28SzyvUr DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=rOYijy98RgI2qIIiyL+QLiDNYX9ODiA3qXMCnsWdXVU=; b=XqqQdXRlsakb2w6iDO3BRglZwo Qi9lcLb94GzrNEvsKV0RRDUrTbORyobjcu4PNOYqm09qewGWUEYrx5W31ixXya1pDh3FHjoD16gTb ziTC7hMSiqy30/eobcV5DmdluAdwqECGdAcrWjeOW3eRcIqgmKSrGvgY4xr57Re92So5XlW/yc1pj wzw/oQ1SjruXYQQar72+jn/GgkzHI+lQ+eN2PbuYp7phEL1XR1svf9XjzvySeskykFwo5U2sf9Lvj vBzR6MHGvauVc+fjkxAnZvlsTK1oz/Rh0szfs6OqymgsarL27NfjmMPFlrQeN6PWKW2wqH/4FctSP CksRFJfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR51X-00000006G7d-3SVh; Wed, 11 Nov 2026 09:53:47 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR51V-00000006G6d-0dES; Wed, 11 Nov 2026 09:53:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Reply-To; bh=rOYijy98RgI2qIIiyL+QLiDNYX9ODiA3qXMCnsWdXVU=; b=28SzyvUrJWEKkHHZXCa1oDz4JF PlSX5euAAMQyENwudCVR6cTty+VH1jG/mgo73RBjbiZivnZXrK+AHWj4VHdAF7otI7kK0Ynp2wXix WRr27PFPkEjrC5iXrkptO3jjbv/C5C4O6OsdamoQ/Zew2t5ZPng/9RL6GZtaX0pN5yybStTSI/Wni VkuKQaOUKYWbYnyU/Mdd2eaVbg0rSr+BKaCuckVeOyYGhiGO/sF2AJtcyfDT4SKsWXQf44zSah16c onKYsT1a7e5TG2rx/E6cxZ/NNmWFX9JRutQCBH8O6CmfwPXX/5a1UWBneR8+DnlP7+TH4FMCM/KdP 3HqbLhtg==; From: Heiko =?UTF-8?B?U3TDvGJuZXI=?= To: aiyengar1990@gmail.com, Will Deacon , Robin Murphy , "Joerg Roedel (AMD)" , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Niklas Cassel , Shawn Lin Cc: shawn.lin@rock-chips.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Simon Xue , "finley.xiao" Subject: Re: [PATCH 0/5] iommu/arm-smmu-v3: power domain and clock of the RK3588 PCIe SMMU Date: Wed, 11 Nov 2026 10:53:28 +0100 Message-ID: <9_7qTfdNSViwtNUGq9D13w@sntech.de> In-Reply-To: References: <20261110-smmu-v3-pcie-pd-v1-0-628819ca44b9@gmail.com> <10924894.NyiUUSuA9g@diego> X-Archived-By: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261111_015345_405892_406CABC4 X-CRM114-Status: GOOD ( 27.84 ) X-Spam-Score: -2.1 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 Am Mittwoch, 11. November 2026, 09:02:30 Mitteleurop=C3=A4ische Normalzeit = schrieb Shawn Lin: > Hi Heiko >=20 > =E5=9C=A8 2026/11/10 =E6=98=9F=E6=9C=9F=E4=BA=8C 16:49, Heiko St=C3=BCbne= r =E5=86=99=E9=81=93: > > Am Dienstag, 10. November 2026, 09:40:44 Mitteleurop=C3=A4ische Normalz= eit schrieb Shawn Lin: > >> Cc: Simon and Finley > >> > >> =E5=9C=A8 2026/11/10 =E6=98=9F=E6=9C=9F=E4=BA=8C 15:11, Arun Iyengar v= ia B4 Relay =E5=86=99=E9=81=93: > >>> The MMU-600 in front of the PCIe controllers of the Rockchip RK3588 > >>> (mmu600_pcie) is enabled for every RK3588 board, but its node describ= es > >>> 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 framew= ork > >>> gates the clock as unused after boot, while arm-smmu-v3 stays bound. > >>> At reboot, arm_smmu_device_shutdown() then writes CR0 and polls CR0AC= K 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. > >=20 > > 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. > >=20 > > Hence we end up in the situation described above. > >=20 >=20 > 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=E2=80=99s 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