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@xxxxxxxxxxx>
> ---
>
> 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
