This series adds provision to mark dynamic opps as boost capable and adds
boost frequency support to the scmi cpufreq driver.
V3:
* Don't set per-policy boost flags from the cpufreq driver. [Viresh]
* Drop patch 1 since Viresh already pulled it in.
* Drop depends on bug link. [Viresh]
V2:
* Document boost flag. [Lukasz]
* Remove sustained_freq check. [Pierre]
* simplify sustained_freq_khz calculation. [Sudeep]
* fix default per-policy state. [Dietmar]
* fix typo in commit message in patch 3.
Sibi Sankar (2):
firmware: arm_scmi: Add support for marking certain frequencies as
boost
cpufreq: scmi: Enable boost support
drivers/cpufreq/scmi-cpufreq.c | 20 +++++++++++++++++++-
drivers/firmware/arm_scmi/perf.c | 8 +++++++-
2 files changed, 26 insertions(+), 2 deletions(-)
--
2.34.1
The X1E80100 SoC hosts a number of cpu boost frequencies, so let's enable
boost support if the freq_table has any opps marked as turbo in it.
Signed-off-by: Sibi Sankar <[email protected]>
---
v3:
* Don't set per-policy boost flags from the cpufreq driver. [Viresh]
drivers/cpufreq/scmi-cpufreq.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 0b483bd0d3ca..3b4f6bfb2f4c 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -30,6 +30,7 @@ struct scmi_data {
static struct scmi_protocol_handle *ph;
static const struct scmi_perf_proto_ops *perf_ops;
+static struct cpufreq_driver scmi_cpufreq_driver;
static unsigned int scmi_cpufreq_get_rate(unsigned int cpu)
{
@@ -167,6 +168,12 @@ scmi_get_rate_limit(u32 domain, bool has_fast_switch)
return rate_limit;
}
+static struct freq_attr *scmi_cpufreq_hw_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+ NULL,
+};
+
static int scmi_cpufreq_init(struct cpufreq_policy *policy)
{
int ret, nr_opp, domain;
@@ -276,6 +283,17 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
policy->transition_delay_us =
scmi_get_rate_limit(domain, policy->fast_switch_possible);
+ if (policy_has_boost_freq(policy)) {
+ ret = cpufreq_enable_boost_support();
+ if (ret) {
+ dev_warn(cpu_dev, "failed to enable boost: %d\n", ret);
+ goto out_free_opp;
+ } else {
+ scmi_cpufreq_hw_attr[1] = &cpufreq_freq_attr_scaling_boost_freqs;
+ scmi_cpufreq_driver.boost_enabled = true;
+ }
+ }
+
return 0;
out_free_opp:
@@ -334,7 +352,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
CPUFREQ_NEED_INITIAL_FREQ_CHECK |
CPUFREQ_IS_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
- .attr = cpufreq_generic_attr,
+ .attr = scmi_cpufreq_hw_attr,
.target_index = scmi_cpufreq_set_target,
.fast_switch = scmi_cpufreq_fast_switch,
.get = scmi_cpufreq_get_rate,
--
2.34.1
On Fri, Mar 08, 2024 at 04:14:10PM +0530, Sibi Sankar wrote:
> The X1E80100 SoC hosts a number of cpu boost frequencies, so let's enable
> boost support if the freq_table has any opps marked as turbo in it.
>
I had asked if you could put the information about how and when the boost
frequencies are used, it would be useful for reference purposes when someone
attempts to use this feature. But it is not a blocker, just good to have
info.
Also I would not sure specific platform name, just refer as certain platforms
as it such information becomes stale soon.
Anyways apart for those nits on the commit message, this looks good.
Reviewed-by: <[email protected]>
I am assuming Viresh might take both these changes for via his tree. If not,
I can take it for v6.10 after v6.9-rc1
--
Regards,
Sudeep
On 08-03-24, 14:06, Sudeep Holla wrote:
> Anyways apart for those nits on the commit message, this looks good.
>
> Reviewed-by: <[email protected]>
:)
--
viresh
On Mon, Mar 11, 2024 at 10:25:13AM +0530, Viresh Kumar wrote:
> On 08-03-24, 14:06, Sudeep Holla wrote:
> > Anyways apart for those nits on the commit message, this looks good.
> >
> > Reviewed-by: <[email protected]>
>
> :)
>
????
So stupid of me, I wanted to make sure you were in to and seem to have
copied the same address for my reviewed by. Sorry for that, obviously
I meant:
Reviewed-by: Sudeep Holla <[email protected]>
--
Regards,
Sudeep