Thread (19 messages) 19 messages, 3 authors, 2021-08-12

Re: [PATCH V2 9/9] cpufreq: scmi: Use .register_em() callback

From: Lukasz Luba <lukasz.luba@arm.com>
Date: 2021-08-11 14:09:20
Also in: linux-arm-kernel, lkml


On 8/11/21 2:17 PM, Quentin Perret wrote:
On Wednesday 11 Aug 2021 at 17:28:47 (+0530), Viresh Kumar wrote:
quoted
Set the newly added .register_em() callback to register with the EM
after the cpufreq policy is properly initialized.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
  drivers/cpufreq/scmi-cpufreq.c | 55 ++++++++++++++++++++--------------
  1 file changed, 32 insertions(+), 23 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 75f818d04b48..b916c9e22921 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -22,7 +22,9 @@
  
  struct scmi_data {
  	int domain_id;
+	int nr_opp;
  	struct device *cpu_dev;
+	cpumask_var_t opp_shared_cpus;
Can we use policy->related_cpus and friends directly in the callback
Unfortunately not. This tricky setup code was introduced because we may
have a platform with per-CPU policy, so single bit set in
policy->related_cpus, but we want EAS to be still working on set
of CPUs. That's why we construct temporary cpumask and pass it to EM.
instead? That should simplify the patch a bit.

Also, we can probably afford calling dev_pm_opp_get_opp_count() from the
em_register callback as it is not a hot path, which would avoid wasting
some 'resident' memory here that is only used during init.

Thanks,
Quentin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help