Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting fwnode for scmi cpufreq
From: Sudeep Holla
Date: Mon Mar 10 2025 - 08:03:08 EST
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://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx95.dtsi#L2971
> https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx95.dtsi#L3043
> https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx95.dtsi#L80
>
> 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 ?
--
Regards,
Sudeep