RE: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting fwnode for scmi cpufreq
From: Peng Fan <peng.fan@nxp.com>
Date: 2025-03-11 11:12:48
Also in:
arm-scmi, imx, linux-gpio, lkml
Subject: RE: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting fwnode for scmi cpufreqquoted
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:quoted
On Mon, Mar 10, 2025 at 10:45:44AM +0000, Peng Fan wrote:quoted
quoted
Subject: Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypasssettingquoted
quoted
quoted
quoted
fwnode for scmi cpufreq On Thu, Feb 20, 2025 at 08:59:18AM +0800, Peng Fan wrote:quoted
Sorry, if I misunderstood. I will give a look on this and propose a RFC. DT maintainers may ask for a patchset including bindingchangequoted
quoted
quoted
quoted
quoted
and driver changes to get a whole view on the compatiblestuff.quoted
quoted
quoted
quoted
quoted
BTW, Cristian, Saravana if you have any objections/ideas or wouldtakequoted
on this effort, please let me know.Can you point me to the DTS with which you are seeing thisissue ?quoted
quoted
quoted
quoted
I am trying to reproduce the issue but so far not successful. I did move to power-domains for CPUFreq on Juno. IIUC all weneed isquoted
quoted
quoted
both cpufreq and performance genpd drivers in the kernel andthenquoted
quoted
quoted
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%2Fquoted
giquoted
quoted
thub.com%2Fnxp-imx%2Flinux-imx%2Fblob%2Flf-6.6.y%2Farch%2Farm64%2Fboquoted
quoted
ot%2Fdts%2Ffreescale%2Fimx95.dtsi%23L2971&data=05%7C02%7Cpequoted
ng.fan%40quoted
quoted
nxp.com%7C72778d531e944c7214ca08dd5fd95012%7C686ea1d3bc2quoted
b4c6fa92cd99quoted
quoted
c5c301635%7C0%7C0%7C638772109152491267%7CUnknown%7CT WFpbGZsb3d8eyJFbquoted
quoted
XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIquoted
joiTWFpbquoted
quoted
CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nHFiE5qD7NpmdGmjquoted
SUL0mIdOq8P4Wquoted
quoted
ErqVq8xE%2Fb3WM0%3D&reserved=0https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquoted
giquoted
quoted
thub.com%2Fnxp-imx%2Flinux-imx%2Fblob%2Flf-6.6.y%2Farch%2Farm64%2Fboquoted
quoted
ot%2Fdts%2Ffreescale%2Fimx95.dtsi%23L3043&data=05%7C02%7Cpequoted
ng.fan%40quoted
quoted
nxp.com%7C72778d531e944c7214ca08dd5fd95012%7C686ea1d3bc2quoted
b4c6fa92cd99quoted
quoted
c5c301635%7C0%7C0%7C638772109152521215%7CUnknown%7CT WFpbGZsb3d8eyJFbquoted
quoted
XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIquoted
joiTWFpbquoted
quoted
CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=M4LJumL6y9bQ%2FLquoted
ocPvlNiMnCFtOquoted
quoted
vODYNrC0DGbbydxY%3D&reserved=0https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquoted
giquoted
quoted
thub.com%2Fnxp-imx%2Flinux-imx%2Fblob%2Flf-6.6.y%2Farch%2Farm64%2Fboquoted
quoted
ot%2Fdts%2Ffreescale%2Fimx95.dtsi%23L80&data=05%7C02%7Cpengquoted
.fan%40nxquoted
quoted
p.com%7C72778d531e944c7214ca08dd5fd95012%7C686ea1d3bc2b4quoted
c6fa92cd99c5quoted
quoted
c301635%7C0%7C0%7C638772109152541725%7CUnknown%7CTWFquoted
pbGZsb3d8eyJFbXBquoted
quoted
0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiquoted
TWFpbCIquoted
quoted
sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VpxcGrB6Dnr9yCO%2Fquoted
wl8sEw1LYSlX5quoted
quoted
nPHqnlJ5mKm%2B7A%3D&reserved=0 we are using "power-domains" property for cpu perf and gpu/vpuperf.quoted
quoted
If cpufreq.off=1 is set in bootargs, the vpu/gpu driver will deferprobe.quoted
quoted
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 probeandquoted
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.Alsoquoted
quoted
are you sure this is not with anything in the downstream code ?Alsoquoted
quoted
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 toreproducequoted
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.
From below sys directory, this test device takes scmi_dev.4 and scmi_dev.3 as supplier.
root@imx95evk:/sys/bus/platform/devices/soc:test@4f000000# ls
driver_override of_node subsystem supplier:scmi_protocol:scmi_dev.4 waiting_for_supplier
modalias power supplier:scmi_protocol:scmi_dev.3 uevent
Checking scmi_dev.4 below, it is scmi cpufreq, not the scmi perf device.
scmi_dev.3 is correct, it is genpd.
root@imx95evk:/sys/bus/platform/devices/soc:test@4f000000# cat /sys/bus/scmi_protocol/devices/scmi_dev.4/modalias
scmi_dev.4:13:cpufreq
root@imx95evk:/sys/bus/platform/devices/soc:test@4f000000# cat /sys/bus/scmi_protocol/devices/scmi_dev.3/modalias
scmi_dev.3:11:genpd
root@imx95evk:/sys/bus/platform/devices/soc:test@4f000000#
So it is clear that wrong fw_devlink is created, it is because scmi cpufreq device is
created earlier and when device_add, the below logic makes the fwnode pointer points
to scmi cpufreq device.
if (dev->fwnode && !dev->fwnode->dev) {
dev->fwnode->dev = dev;
fw_devlink_link_device(dev);
}
Hope this is clear.
Regards,
Peng.
Thanks, Peng.quoted
-- Regards, Sudeep