Message-ID:
 <PAXPR04MB84594BED300BCA5DEE9DA79E88FC2@PAXPR04MB8459.eurprd04.prod.outlook.com>
Date: Wed, 12 Feb 2025 08:22:52 +0000
From: Peng Fan <peng.fan@....com>
To: Alexander Stein <alexander.stein@...tq-group.com>, "Peng Fan (OSS)"
	<peng.fan@....nxp.com>
CC: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>, Sascha
 Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team
	<kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>, Srinivas
 Kandagatla <srinivas.kandagatla@...aro.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 04/10] arm64: dts: imx8mn: Add access-controller
 references

> Subject: Re: [PATCH v2 04/10] arm64: dts: imx8mn: Add access-
> controller references
> 
> 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.

Not sure whether dt bindings should be different for one SoC
that some modules maybe fused out that not usable. Actually
this is different SoC per my understanding.

Without changing the binding, the idea I am thinking
is to add nvmem = <&ocotp X>, <& ocotp Y>, xxxx; for
the node. Then driver could check nvmem to see
whether module avaibable.

But for pgc, we still need the pd available from sw view,
otherwise blk ctrl may not probe because of
fwdevlink.

Regards,
Peng

> 
> > 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
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> www.tq-
> group.com%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7Ccb387da
> 6989845e6bee608dd4b3ccd2a%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C0%7C0%7C638749446703427130%7CUnknown%7CTWFpbGZ
> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW
> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d
> OARjpfOaGqV2GNJ9TPiUs7qd703QPOzjUiFFQMRX0s%3D&reserved=0
> 

Powered by blists - more mailing lists