Thread (50 messages) 50 messages, 6 authors, 2025-06-20

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

From: Peng Fan <hidden>
Date: 2025-02-12 05:54:32
Also in: arm-scmi, imx, linux-gpio, lkml

On Tue, Feb 11, 2025 at 05:13:21PM +0000, Sudeep Holla wrote:
On Wed, Dec 25, 2024 at 04:20:44PM +0800, Peng Fan (OSS) wrote:
quoted
From: Peng Fan <peng.fan@nxp.com>

Two drivers scmi_cpufreq.c and scmi_perf_domain.c both use
SCMI_PROTCOL_PERF protocol, but with different name, so two scmi devices
will be created. But the fwnode->dev could only point to one device.

If scmi cpufreq device created earlier, the fwnode->dev will point to
the scmi cpufreq device. Then the fw_devlink will link performance
domain user device(consumer) to the scmi cpufreq device(supplier).
But actually the performance domain user device, such as GPU, should use
the scmi perf device as supplier. Also if 'cpufreq.off=1' in bootargs,
the GPU driver will defer probe always, because of the scmi cpufreq
device not ready.

Because for cpufreq, no need use fw_devlink. So bypass setting fwnode
for scmi cpufreq device.
Not 100% sure if above is correct. See:

Commit 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider")

Am I missing something ?
Could we update juno-scmi.dtsi to use ?

 &A53_0 {
-       clocks = <&scmi_dvfs 1>;
+       power-domains = <&scmi_perf x>;
+       power-domain-names = "perf";
 };

Even for scmi-cpufreq.c that needs fw_devlink because of the clocks entry in
juno-scmi.dtsi, there is no issue here.
Because the dummy clock provider will always be ready before opp with
your upper fix. So we could safetly ignore fw_devlink per my understanding.

Regards,
Peng
-- 
Regards,
Sudeep
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help