RE: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting fwnode for scmi cpufreq

[Peng Fan <peng.fan@xxxxxxx>]

> Subject: RE: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting
> fwnode for scmi cpufreq
> 
> > Subject: Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting
> > fwnode for scmi cpufreq
> >
> > On Mon, Mar 10, 2025 at 11:59:33AM +0000, Sudeep Holla wrote:
> > > On Mon, Mar 10, 2025 at 10:45:44AM +0000, Peng Fan wrote:
> > > > > Subject: Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypass
> setting
> > > > > fwnode for scmi cpufreq
> > > > >
> > > > > On Thu, Feb 20, 2025 at 08:59:18AM +0800, Peng Fan wrote:
> > > > > >
> > > > > > Sorry, if I misunderstood.
> > > > > >
> > > > > > I will give a look on this and propose a RFC.
> > > > > >
> > > > > > DT maintainers may ask for a patchset including binding
> change
> > > > > > and driver changes to get a whole view on the compatible
> stuff.
> > > > > >
> > > > > > BTW, Cristian, Saravana if you have any objections/ideas or
> > > > > > would
> > > > > take
> > > > > > on this effort, please let me know.
> > > > > >
> > > > >
> > > > > Can you point me to the DTS with which you are seeing this
> issue ?
> > > > > I am trying to reproduce the issue but so far not successful. I
> > > > > did move to power-domains for CPUFreq on Juno. IIUC all we
> > need is
> > > > > both cpufreq and performance genpd drivers in the kernel and
> > then
> > > > > GPU using perf genpd fails with probe deferral right ? I need
> > > > > pointers to reproduce the issue so that I can check if what I
> > > > > have cooked up as a solution really works.
> > > >
> > > > This is in downstream tree:
> > > >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > gi
> > > > thub.com%2Fnxp-imx%2Flinux-imx%2Fblob%2Flf-
> > 6.6.y%2Farch%2Farm64%2Fbo
> > > >
> >
> ot%2Fdts%2Ffreescale%2Fimx95.dtsi%23L2971&data=05%7C02%7Cpe
> > ng.fan%40
> > > >
> >
> nxp.com%7C72778d531e944c7214ca08dd5fd95012%7C686ea1d3bc2
> > b4c6fa92cd99
> > > >
> > c5c301635%7C0%7C0%7C638772109152491267%7CUnknown%7CT
> > WFpbGZsb3d8eyJFb
> > > >
> >
> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> > joiTWFpb
> > > >
> >
> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nHFiE5qD7NpmdGmj
> > SUL0mIdOq8P4W
> > > > ErqVq8xE%2Fb3WM0%3D&reserved=0
> > > >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > gi
> > > > thub.com%2Fnxp-imx%2Flinux-imx%2Fblob%2Flf-
> > 6.6.y%2Farch%2Farm64%2Fbo
> > > >
> >
> ot%2Fdts%2Ffreescale%2Fimx95.dtsi%23L3043&data=05%7C02%7Cpe
> > ng.fan%40
> > > >
> >
> nxp.com%7C72778d531e944c7214ca08dd5fd95012%7C686ea1d3bc2
> > b4c6fa92cd99
> > > >
> > c5c301635%7C0%7C0%7C638772109152521215%7CUnknown%7CT
> > WFpbGZsb3d8eyJFb
> > > >
> >
> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> > joiTWFpb
> > > >
> >
> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=M4LJumL6y9bQ%2FL
> > ocPvlNiMnCFtO
> > > > vODYNrC0DGbbydxY%3D&reserved=0
> > > >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > gi
> > > > thub.com%2Fnxp-imx%2Flinux-imx%2Fblob%2Flf-
> > 6.6.y%2Farch%2Farm64%2Fbo
> > > >
> >
> ot%2Fdts%2Ffreescale%2Fimx95.dtsi%23L80&data=05%7C02%7Cpeng
> > .fan%40nx
> > > >
> >
> p.com%7C72778d531e944c7214ca08dd5fd95012%7C686ea1d3bc2b4
> > c6fa92cd99c5
> > > >
> >
> c301635%7C0%7C0%7C638772109152541725%7CUnknown%7CTWF
> > pbGZsb3d8eyJFbXB
> > > >
> >
> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> > TWFpbCI
> > > >
> >
> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VpxcGrB6Dnr9yCO%2F
> > wl8sEw1LYSlX5
> > > > nPHqnlJ5mKm%2B7A%3D&reserved=0
> > > >
> > > > we are using "power-domains" property for cpu perf and gpu/vpu
> > perf.
> > > >
> > > > If cpufreq.off=1 is set in bootargs, the vpu/gpu driver will defer
> > probe.
> > > >
> > >
> > > OK, does the probe of these drivers get called or they don't as the
> > > driver core doesn't allow that ? I just have a dummy driver for mali
> > > on Juno which just does dev_pm_domain_attach_list() in the probe
> > and
> > > it seem to succeed even when cpufreq.off=1 is passed. I see
> > > scmi-cpufreq failing with -ENODEV as expected.
> > >
> > > I need to follow the code and check if I can somehow reproduce.
> Also
> > > are you sure this is not with anything in the downstream code ?
> Also
> > > have you tried this with v6.14-rc* ? Are you sure all the fw_devlink
> > > code is backported in the tree you pointed me which is v6.6-stable ?
> > >
> >
> > I even tried the above branch, but no luck. The above is neither
> > latest stable version nor pure stable. It has few extra patches
> > backported though IIUC. Anyways any pointers to enable me to
> reproduce
> > the issue would be much appreciated.
> 
> I will setup test based latest linux-next and share results. Please wait.


Based on linux-next, I added below node:

+
+               test@4f000000 {
+                       compatible = "fsl,imx-test";
+                       power-domains = <&scmi_devpd IMX95_PD_VPU>, <&scmi_perf IMX95_PERF_VPU>;
+                       power-domain-names = "vpumix", "vpuperf";
+               };

I not write a driver for it, so just check devlink information from sysfs interface.