Am Dienstag, 11. Februar 2025, 04:33:41 CET schrieb Peng Fan: > > On Mon, Feb 10, 2025 at 04:48:56PM +0100, Alexander Stein wrote: > >Am Montag, 10. Februar 2025, 03:36:48 CET schrieb Peng Fan: > >> > Subject: Re: [PATCH v2 04/10] arm64: dts: imx8mn: Add access- > >> > controller references > >> > > >> > Hi Peng, > >> > > >> > Am Freitag, 7. Februar 2025, 13:02:13 CET schrieb Peng Fan: > >> > > On Fri, Feb 07, 2025 at 09:36:09AM +0100, Alexander Stein wrote: > >> > > >Mark ocotp as a access-controller and add references on peripherals > >> > > >which can be disabled (fused). > >> > > > >> > > I am not sure whether gpcv2 changes should be included in this > >> > > patchset or not. Just add access-controller for fused IP will not work. > >> > > >> > Well, I was able to successfully boot a i.MX8M Nano DualLite. > >> > > >> > > i.MX8M BLK-CTRL/GPC will hang if the related power domain is still > >> > > touched by kernel. The pgc can't power up/down because clock is > >> > gated. > >> > > >> > Well, with GPU node disabled, no one should enable the power domain. > >> > But to be on the safe side I would also add access-controllers to the > >> > corresponding power domains as well. > >> > > >> > > This comment also apply to i.MX8MM/P. > >> > > >> > Sure. Do you have any information what is actually disabled by those > >> > fused? > >> > It seems it's the IP and their power domains. Anything else? > >> > >> In NXP downstream there is a patch for drivers/pmdomain/imx/imx8m-blk-ctrl.c > >> > >> soc: imx8m-blk-ctrl: Support fused modules > >> > >> For fused module, its pgc can't power up/down and clock is gated. > >> Because imx8m-blk-ctrl driver will pm_runtime_get_sync/pm_runtime_put > >> all power domains during suspend/resume. So we have to remove the > >> pgc and clock of fused module from blk-ctrl DTS node. > >> Update the driver to support such case. > >> > >> But this patch also needs U-Boot to update device tree nodes, > >> I recalled that U-Boot will remove gpc nodes, but not update blk-ctrl nodes. > > > >Does it work, if we add the access-controller as well for pgc_gpu3d > >on imx8mp? There is nothing in blk-ctrl AFAICS. But for VPU there is. > > Adding access-controller under pgc_gpu node will not make fwdevlink > work for the pgc_gpu nodes. It does not have compatible, and device > is created by gpcv2 driver using platform_device_alloc. Same to vpu. > > >Which clock needs to be removed there in case g1 is disabled? > > Take i.MX8MP VC8000E as example, the vpumix blk ctrl, the vc8000e > reference under vpumix blkctrl should be removed, including pd and clock. Wait, so you want to remove the last entry from these properties? > clocks = <&clk IMX8MP_CLK_VPU_G1_ROOT>, > <&clk IMX8MP_CLK_VPU_G2_ROOT>, > <&clk IMX8MP_CLK_VPU_VC8KE_ROOT>; > clock-names = "g1", "g2", "vc8000e"; This violates the DT binding. > So for non-blkctrl nodes, it is fine to use access-controller and rely > on fwdelink to defer probe. But for blk ctrl nodes, it will not work. > > For pgc nodes, it may or may not matter, not very sure for now. > > For blk ctrl nodes, we need provide a generic API saying > access_control_check or directly using nvmem API. Reading access-controllers.yaml this should still be feasible for providing the necessary information. But I'm note sure where to implement this. In e.g. imx-ocotp would be a very SoC-specific API. Best regards, Alexander -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
