summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
diff options
context:
space:
mode:
authorNicola Mazzucato <nicola.mazzucato@arm.com>2020-06-17 12:43:32 +0300
committerSudeep Holla <sudeep.holla@arm.com>2020-06-30 16:07:43 +0300
commitfb3571276b970cbe7b45ecdc762e92f3f305ad6d (patch)
tree3d7067f3e3c9123b9541c7f5a55f74e6af77af37 /drivers/cpufreq
parent1909872ff20fc378ec6a44ea1a2b2966d834e504 (diff)
downloadlinux-fb3571276b970cbe7b45ecdc762e92f3f305ad6d.tar.xz
cpufreq: arm_scmi: Set fast_switch_possible conditionally
Currently the fast_switch_possible flag is set unconditionally to true. Based on this, schedutil does not create a thread for frequency switching and would always use the fast switch path. However, if the platform does not support SCMI fast channel, we use polling mode for SCMI message transfer. This may be possible only if there is dedicated channel for DVFS and all operations are in polling mode. Update this by retrieving the fast_switch capability based on the presence of fast channels in SCMI platform firmware. Link: https://lore.kernel.org/r/20200617094332.8391-2-nicola.mazzucato@arm.com Suggested-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Diffstat (limited to 'drivers/cpufreq')
-rw-r--r--drivers/cpufreq/scmi-cpufreq.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 61623e2ff149..1cf688fcb56b 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -198,7 +198,8 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
policy->cpuinfo.transition_latency = latency;
- policy->fast_switch_possible = true;
+ policy->fast_switch_possible =
+ handle->perf_ops->fast_switch_possible(handle, cpu_dev);
em_register_perf_domain(policy->cpus, nr_opp, &em_cb);