linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Pierre Gondois <pierre.gondois@arm.com>
Cc: linux-kernel@vger.kernel.org,
	Christian Loehle <christian.loehle@arm.com>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 1/3] firmware: arm_scmi: Populate perf commands rate_limit
Date: Mon, 4 Mar 2024 07:55:47 +0000	[thread overview]
Message-ID: <ZeV-g6WR7IYNXEJX@pluto> (raw)
In-Reply-To: <20240222135702.2005635-2-pierre.gondois@arm.com>

On Thu, Feb 22, 2024 at 02:56:59PM +0100, Pierre Gondois wrote:
> Arm SCMI spec. v3.2, s4.5.3.4 PERFORMANCE_DOMAIN_ATTRIBUTES
> defines a per-domain rate_limit for performance requests:
> """
> Rate Limit in microseconds, indicating the minimum time
> required between successive requests. A value of 0
> indicates that this field is not supported by the
> platform. This field does not apply to FastChannels.
> """"
> The field is first defined in SCMI v1.0.
> 
> Add support to fetch this value and advertise it through
> a rate_limit_get() callback.
> 

Hi,

LGTM.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>

Thanks,
Cristian

> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
>  drivers/firmware/arm_scmi/perf.c | 21 +++++++++++++++++++++
>  include/linux/scmi_protocol.h    |  4 ++++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
> index 211e8e0aef2c..37c80376bd0a 100644
> --- a/drivers/firmware/arm_scmi/perf.c
> +++ b/drivers/firmware/arm_scmi/perf.c
> @@ -153,6 +153,7 @@ struct perf_dom_info {
>  	bool perf_fastchannels;
>  	bool level_indexing_mode;
>  	u32 opp_count;
> +	u32 rate_limit_us;
>  	u32 sustained_freq_khz;
>  	u32 sustained_perf_level;
>  	unsigned long mult_factor;
> @@ -266,6 +267,8 @@ scmi_perf_domain_attributes_get(const struct scmi_protocol_handle *ph,
>  		if (PROTOCOL_REV_MAJOR(version) >= 0x4)
>  			dom_info->level_indexing_mode =
>  				SUPPORTS_LEVEL_INDEXING(flags);
> +		dom_info->rate_limit_us = le32_to_cpu(attr->rate_limit_us) &
> +						GENMASK(19, 0);
>  		dom_info->sustained_freq_khz =
>  					le32_to_cpu(attr->sustained_freq_khz);
>  		dom_info->sustained_perf_level =
> @@ -855,6 +858,23 @@ scmi_dvfs_transition_latency_get(const struct scmi_protocol_handle *ph,
>  	return dom->opp[dom->opp_count - 1].trans_latency_us * 1000;
>  }
>  
> +static int
> +scmi_dvfs_rate_limit_get(const struct scmi_protocol_handle *ph,
> +			 u32 domain, u32 *rate_limit)
> +{
> +	struct perf_dom_info *dom;
> +
> +	if (!rate_limit)
> +		return -EINVAL;
> +
> +	dom = scmi_perf_domain_lookup(ph, domain);
> +	if (IS_ERR(dom))
> +		return PTR_ERR(dom);
> +
> +	*rate_limit = dom->rate_limit_us;
> +	return 0;
> +}
> +
>  static int scmi_dvfs_freq_set(const struct scmi_protocol_handle *ph, u32 domain,
>  			      unsigned long freq, bool poll)
>  {
> @@ -970,6 +990,7 @@ static const struct scmi_perf_proto_ops perf_proto_ops = {
>  	.level_set = scmi_perf_level_set,
>  	.level_get = scmi_perf_level_get,
>  	.transition_latency_get = scmi_dvfs_transition_latency_get,
> +	.rate_limit_get = scmi_dvfs_rate_limit_get,
>  	.device_opps_add = scmi_dvfs_device_opps_add,
>  	.freq_set = scmi_dvfs_freq_set,
>  	.freq_get = scmi_dvfs_freq_get,
> diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
> index f2f05fb42d28..acd956ffcb84 100644
> --- a/include/linux/scmi_protocol.h
> +++ b/include/linux/scmi_protocol.h
> @@ -128,6 +128,8 @@ struct scmi_perf_domain_info {
>   * @level_set: sets the performance level of a domain
>   * @level_get: gets the performance level of a domain
>   * @transition_latency_get: gets the DVFS transition latency for a given device
> + * @rate_limit_get: gets the minimum time (us) required between successive
> + *	requests
>   * @device_opps_add: adds all the OPPs for a given device
>   * @freq_set: sets the frequency for a given device using sustained frequency
>   *	to sustained performance level mapping
> @@ -154,6 +156,8 @@ struct scmi_perf_proto_ops {
>  			 u32 *level, bool poll);
>  	int (*transition_latency_get)(const struct scmi_protocol_handle *ph,
>  				      u32 domain);
> +	int (*rate_limit_get)(const struct scmi_protocol_handle *ph,
> +			      u32 domain, u32 *rate_limit);
>  	int (*device_opps_add)(const struct scmi_protocol_handle *ph,
>  			       struct device *dev, u32 domain);
>  	int (*freq_set)(const struct scmi_protocol_handle *ph, u32 domain,
> -- 
> 2.25.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-03-04  7:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22 13:56 [PATCH 0/3] scmi-cpufreq: Set transition_delay_us Pierre Gondois
2024-02-22 13:56 ` [PATCH 1/3] firmware: arm_scmi: Populate perf commands rate_limit Pierre Gondois
2024-03-04  7:55   ` Cristian Marussi [this message]
2024-03-05 11:47   ` Sudeep Holla
2024-02-22 13:57 ` [PATCH 2/3] firmware: arm_scmi: Populate fast channel rate_limit Pierre Gondois
2024-03-04  8:00   ` Cristian Marussi
2024-03-05 11:46   ` Sudeep Holla
2024-02-22 13:57 ` [PATCH 3/3] cpufreq: scmi: Set transition_delay_us Pierre Gondois
2024-03-04  8:15   ` Cristian Marussi
2024-03-04  7:00 ` [PATCH 0/3] scmi-cpufreq: " Viresh Kumar
2024-03-04 11:42   ` Sudeep Holla
2024-03-06  5:24     ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZeV-g6WR7IYNXEJX@pluto \
    --to=cristian.marussi@arm.com \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).