* [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api @ 2020-06-17 9:43 ` Nicola Mazzucato 2020-06-17 9:43 ` [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally Nicola Mazzucato 2020-07-03 14:49 ` [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api Sudeep Holla 0 siblings, 2 replies; 7+ messages in thread From: Nicola Mazzucato @ 2020-06-17 9:43 UTC (permalink / raw) To: linux-kernel, sudeep.holla, rjw, viresh.kumar, linux-arm-kernel, linux-pm Cc: lukasz.luba Add a new fast_switch_possible interface to the existing perf_ops api to export the information of whether or not fast_switch is possible in this driver. This can be used by the CPUFreq driver and framework to choose proper mechanism for frequency change. Suggested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> --- drivers/firmware/arm_scmi/perf.c | 12 ++++++++++++ include/linux/scmi_protocol.h | 2 ++ 2 files changed, 14 insertions(+) diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c index eadc171e254b..ef747a9bb948 100644 --- a/drivers/firmware/arm_scmi/perf.c +++ b/drivers/firmware/arm_scmi/perf.c @@ -697,6 +697,17 @@ static int scmi_dvfs_est_power_get(const struct scmi_handle *handle, u32 domain, return ret; } +static bool scmi_fast_switch_possible(const struct scmi_handle *handle, + struct device *dev) +{ + struct perf_dom_info *dom; + struct scmi_perf_info *pi = handle->perf_priv; + + dom = pi->dom_info + scmi_dev_domain_id(dev); + + return (dom->fc_info && dom->fc_info->level_set_addr); +} + static struct scmi_perf_ops perf_ops = { .limits_set = scmi_perf_limits_set, .limits_get = scmi_perf_limits_get, @@ -708,6 +719,7 @@ static struct scmi_perf_ops perf_ops = { .freq_set = scmi_dvfs_freq_set, .freq_get = scmi_dvfs_freq_get, .est_power_get = scmi_dvfs_est_power_get, + .fast_switch_possible = scmi_fast_switch_possible, }; static int scmi_perf_protocol_init(struct scmi_handle *handle) diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h index ce2f5c28b2df..19e50b89117e 100644 --- a/include/linux/scmi_protocol.h +++ b/include/linux/scmi_protocol.h @@ -118,6 +118,8 @@ struct scmi_perf_ops { unsigned long *rate, bool poll); int (*est_power_get)(const struct scmi_handle *handle, u32 domain, unsigned long *rate, unsigned long *power); + bool (*fast_switch_possible)(const struct scmi_handle *handle, + struct device *dev); }; /** -- 2.27.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally 2020-06-17 9:43 ` [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api Nicola Mazzucato @ 2020-06-17 9:43 ` Nicola Mazzucato 2020-06-17 12:47 ` Sudeep Holla 2020-06-18 9:54 ` Viresh Kumar 2020-07-03 14:49 ` [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api Sudeep Holla 1 sibling, 2 replies; 7+ messages in thread From: Nicola Mazzucato @ 2020-06-17 9:43 UTC (permalink / raw) To: linux-kernel, sudeep.holla, rjw, viresh.kumar, linux-arm-kernel, linux-pm Cc: lukasz.luba 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 frequency fast switch, this may cause the governor to attempt an operation that is not supported by the platform. Fix this by correctly retrieve the fast_switch capability from the driver which knows if the platform can support this feature. Suggested-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> --- drivers/cpufreq/scmi-cpufreq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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); -- 2.27.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally 2020-06-17 9:43 ` [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally Nicola Mazzucato @ 2020-06-17 12:47 ` Sudeep Holla 2020-06-18 6:14 ` Viresh Kumar 2020-06-18 9:54 ` Viresh Kumar 1 sibling, 1 reply; 7+ messages in thread From: Sudeep Holla @ 2020-06-17 12:47 UTC (permalink / raw) To: Nicola Mazzucato, viresh.kumar Cc: linux-kernel, rjw, linux-arm-kernel, linux-pm, lukasz.luba, Sudeep Holla On Wed, Jun 17, 2020 at 10:43:32AM +0100, Nicola Mazzucato wrote: > 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 frequency > fast switch, this may cause the governor to attempt an > operation that is not supported by the platform. > > Fix this by correctly retrieve the fast_switch capability > from the driver which knows if the platform can support > this feature. > Hi Viresh, This is first step towards avoiding polling based cpufreq set if firmware has fast access registers that bypass normal mailbox based messaging. If you happy with this and provide ack, I will take this along with scmi changes via ARM SoC. Hope that is fine by you. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally 2020-06-17 12:47 ` Sudeep Holla @ 2020-06-18 6:14 ` Viresh Kumar 2020-06-18 8:08 ` Sudeep Holla 0 siblings, 1 reply; 7+ messages in thread From: Viresh Kumar @ 2020-06-18 6:14 UTC (permalink / raw) To: Sudeep Holla Cc: Nicola Mazzucato, linux-kernel, rjw, linux-arm-kernel, linux-pm, lukasz.luba On 17-06-20, 13:47, Sudeep Holla wrote: > This is first step towards avoiding polling based cpufreq set if firmware > has fast access registers that bypass normal mailbox based messaging. > > If you happy with this and provide ack, I will take this along with scmi > changes via ARM SoC. Hope that is fine by you. Sudeep, I am not sure how it concerns me frankly :) AFAICT, this is enabling fast switch based on some mechanism (internal to scmi) and so either the cpufreq driver will have fast-switch enabled or not, and both are fine by the cpufreq core. And so I am confused on why my Ack is important here :) -- viresh ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally 2020-06-18 6:14 ` Viresh Kumar @ 2020-06-18 8:08 ` Sudeep Holla 0 siblings, 0 replies; 7+ messages in thread From: Sudeep Holla @ 2020-06-18 8:08 UTC (permalink / raw) To: Viresh Kumar Cc: Nicola Mazzucato, linux-kernel, rjw, linux-arm-kernel, linux-pm, lukasz.luba, Sudeep Holla On Thu, Jun 18, 2020 at 11:44:20AM +0530, Viresh Kumar wrote: > On 17-06-20, 13:47, Sudeep Holla wrote: > > This is first step towards avoiding polling based cpufreq set if firmware > > has fast access registers that bypass normal mailbox based messaging. > > > > If you happy with this and provide ack, I will take this along with scmi > > changes via ARM SoC. Hope that is fine by you. > > Sudeep, > > I am not sure how it concerns me frankly :) > Sorry I wasn't clear. > AFAICT, this is enabling fast switch based on some mechanism (internal > to scmi) and so either the cpufreq driver will have fast-switch > enabled or not, and both are fine by the cpufreq core. > Indeed. > And so I am confused on why my Ack is important here :) > Generally ARM SoC team expects a stamp from other subsystem maintainers if they are pulling it. I understand there is more firmware aspect than cpufreq aspect here, but still we may need your stamp to this 😉 for logistic reasons. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally 2020-06-17 9:43 ` [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally Nicola Mazzucato 2020-06-17 12:47 ` Sudeep Holla @ 2020-06-18 9:54 ` Viresh Kumar 1 sibling, 0 replies; 7+ messages in thread From: Viresh Kumar @ 2020-06-18 9:54 UTC (permalink / raw) To: Nicola Mazzucato Cc: linux-kernel, sudeep.holla, rjw, linux-arm-kernel, linux-pm, lukasz.luba On 17-06-20, 10:43, Nicola Mazzucato wrote: > 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 frequency > fast switch, this may cause the governor to attempt an > operation that is not supported by the platform. > > Fix this by correctly retrieve the fast_switch capability > from the driver which knows if the platform can support > this feature. > > Suggested-by: Lukasz Luba <lukasz.luba@arm.com> > Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> > --- > drivers/cpufreq/scmi-cpufreq.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > 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); Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- viresh ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api 2020-06-17 9:43 ` [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api Nicola Mazzucato 2020-06-17 9:43 ` [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally Nicola Mazzucato @ 2020-07-03 14:49 ` Sudeep Holla 1 sibling, 0 replies; 7+ messages in thread From: Sudeep Holla @ 2020-07-03 14:49 UTC (permalink / raw) To: Sudeep Holla, Cristian Marussi, linux-kernel, linux-arm-kernel, Nicola Mazzucato, rjw, linux-pm, viresh.kumar Cc: james.quinlan, Jonathan.Cameron, lukasz.luba On Wed, 17 Jun 2020 10:43:31 +0100, Nicola Mazzucato wrote: > Add a new fast_switch_possible interface to the existing > perf_ops api to export the information of whether or not > fast_switch is possible in this driver. > > This can be used by the CPUFreq driver and framework to > choose proper mechanism for frequency change. Applied to sudeep.holla/linux (for-next/scmi), thanks! [1/2] firmware: arm_scmi: Add fast_switch_possible() interface https://git.kernel.org/sudeep.holla/c/1909872ff2 [2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally https://git.kernel.org/sudeep.holla/c/fb3571276b -- Regards, Sudeep ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-07-03 14:50 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <159378759580.7741.1360234334350850998.b4-ty@arm.com> [not found] ` <159378764840.7835.7289029317816454363.b4-ty@arm.com> 2020-06-17 9:43 ` [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api Nicola Mazzucato 2020-06-17 9:43 ` [PATCH 2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally Nicola Mazzucato 2020-06-17 12:47 ` Sudeep Holla 2020-06-18 6:14 ` Viresh Kumar 2020-06-18 8:08 ` Sudeep Holla 2020-06-18 9:54 ` Viresh Kumar 2020-07-03 14:49 ` [PATCH 1/2] firmware: arm_scmi: Add fast_switch_possible() api Sudeep Holla
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).