[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZbfKB4M8FHfma0js@pluto>
Date: Mon, 29 Jan 2024 15:53:43 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Sibi Sankar <quic_sibis@...cinc.com>
Cc: sudeep.holla@....com, rafael@...nel.org, viresh.kumar@...aro.org,
morten.rasmussen@....com, dietmar.eggemann@....com,
lukasz.luba@....com, linux-arm-kernel@...ts.infradead.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
quic_mdtipton@...cinc.com, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH V2 2/4] firmware: arm_scmi: Add perf_freq_xlate interface
On Wed, Jan 17, 2024 at 04:11:14PM +0530, Sibi Sankar wrote:
> Add a new perf_freq_xlate interface to the existing perf_ops to translate
> a given perf index to frequency.
>
> This can be used by the cpufreq driver and framework to determine the
> throttled frequency from a given perf index and apply HW pressure
> accordingly.
>
> Signed-off-by: Sibi Sankar <quic_sibis@...cinc.com>
> ---
>
> v2:
> * Rename opp_xlate -> freq_xlate [Viresh]
>
> drivers/firmware/arm_scmi/perf.c | 21 +++++++++++++++++++++
> include/linux/scmi_protocol.h | 3 +++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
> index ae7681eda276..e286f04ee6e3 100644
> --- a/drivers/firmware/arm_scmi/perf.c
> +++ b/drivers/firmware/arm_scmi/perf.c
> @@ -977,6 +977,26 @@ static int scmi_notify_support(const struct scmi_protocol_handle *ph, u32 domain
> return 0;
> }
>
> +static int scmi_perf_freq_xlate(const struct scmi_protocol_handle *ph, u32 domain,
> + int idx, unsigned long *freq)
> +{
> + struct perf_dom_info *dom;
> +
> + dom = scmi_perf_domain_lookup(ph, domain);
> + if (IS_ERR(dom))
> + return PTR_ERR(dom);
> +
> + if (idx >= dom->opp_count)
> + return -ERANGE;
> +
> + if (!dom->level_indexing_mode)
> + *freq = dom->opp[idx].perf * dom->mult_factor;
> + else
> + *freq = dom->opp[idx].indicative_freq * dom->mult_factor;
> +
> + return 0;
> +}
Potentially, once the dom info are exposed you can also drop this
accessor and move all of these checks/calculations in the the SCMI cpufreq
driver...but maybe Sudeep/Viresh prefer to keep this accessor exposed
like others.
Thanks,
Cristian
Powered by blists - more mailing lists