From: Cristian Marussi <cristian.marussi@arm.com>
To: Sibi Sankar <quic_sibis@quicinc.com>
Cc: sudeep.holla@arm.com, rafael@kernel.org, viresh.kumar@linaro.org,
morten.rasmussen@arm.com, dietmar.eggemann@arm.com,
lukasz.luba@arm.com, linux-arm-kernel@lists.infradead.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
quic_mdtipton@quicinc.com, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH V2 4/4] cpufreq: scmi: Register for limit change notifications
Date: Mon, 29 Jan 2024 15:59:50 +0000 [thread overview]
Message-ID: <ZbfLdvi_sePXiVmM@pluto> (raw)
In-Reply-To: <20240117104116.2055349-5-quic_sibis@quicinc.com>
On Wed, Jan 17, 2024 at 04:11:16PM +0530, Sibi Sankar wrote:
> Register for limit change notifications if supported with the help of
> perf_notify_support interface and determine the throttled frequency
> using the perf_freq_xlate to apply HW pressure.
>
> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
> ---
>
> v2:
> * Export cpufreq_update_pressure and use it directly [Lukasz]
>
> drivers/cpufreq/scmi-cpufreq.c | 42 +++++++++++++++++++++++++++++++++-
> 1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 4ee23f4ebf4a..e0aa85764451 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -25,9 +25,13 @@ struct scmi_data {
> int domain_id;
> int nr_opp;
> struct device *cpu_dev;
> + struct cpufreq_policy *policy;
> cpumask_var_t opp_shared_cpus;
> + struct notifier_block limit_notify_nb;
> };
>
> +const struct scmi_handle *handle;
> +static struct scmi_device *scmi_dev;
> static struct scmi_protocol_handle *ph;
> static const struct scmi_perf_proto_ops *perf_ops;
>
> @@ -144,6 +148,22 @@ scmi_get_cpu_power(struct device *cpu_dev, unsigned long *power,
> return 0;
> }
>
> +static int scmi_limit_notify_cb(struct notifier_block *nb, unsigned long event, void *data)
> +{
> + unsigned long freq_hz;
> + struct scmi_perf_limits_report *limit_notify = data;
> + struct scmi_data *priv = container_of(nb, struct scmi_data, limit_notify_nb);
> + struct cpufreq_policy *policy = priv->policy;
> +
> + if (perf_ops->perf_freq_xlate(ph, priv->domain_id, limit_notify->range_max, &freq_hz))
> + return NOTIFY_OK;
> +
> + policy->max = freq_hz / HZ_PER_KHZ;
> + cpufreq_update_pressure(policy);
> +
> + return NOTIFY_OK;
> +}
> +
> static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> {
> int ret, nr_opp, domain;
> @@ -151,6 +171,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> struct device *cpu_dev;
> struct scmi_data *priv;
> struct cpufreq_frequency_table *freq_table;
> + struct scmi_perf_notify_info info = {};
>
> cpu_dev = get_cpu_device(policy->cpu);
> if (!cpu_dev) {
> @@ -250,6 +271,25 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> policy->fast_switch_possible =
> perf_ops->fast_switch_possible(ph, domain);
>
> + ret = perf_ops->perf_notify_support(ph, domain, &info);
> + if (ret)
> + dev_warn(cpu_dev, "failed to get supported notifications: %d\n", ret);
> +
> + if (info.perf_limit_notify) {
> + priv->limit_notify_nb.notifier_call = scmi_limit_notify_cb;
> + ret = handle->notify_ops->devm_event_notifier_register(scmi_dev, SCMI_PROTOCOL_PERF,
> + SCMI_EVENT_PERFORMANCE_LIMITS_CHANGED,
> + &domain,
> + &priv->limit_notify_nb);
> + if (ret) {
> + dev_err(cpu_dev, "Error in registering limit change notifier for domain %d\n",
> + domain);
> + return ret;
> + }
Is there a reason to fail completely here if it was not possible to register
the notifier ? (even though expected to succeed given perf_limit_notify
was true...)
Maybe a big fat warn that the system perf could be degraded, but
carrying on ?
Or maybe you have in mind a good reason to fail like you did, so please
explain in that case in a comment.
Thanks,
Cristian
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sibi Sankar <quic_sibis@quicinc.com>
Cc: sudeep.holla@arm.com, rafael@kernel.org, viresh.kumar@linaro.org,
morten.rasmussen@arm.com, dietmar.eggemann@arm.com,
lukasz.luba@arm.com, linux-arm-kernel@lists.infradead.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
quic_mdtipton@quicinc.com, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH V2 4/4] cpufreq: scmi: Register for limit change notifications
Date: Mon, 29 Jan 2024 15:59:50 +0000 [thread overview]
Message-ID: <ZbfLdvi_sePXiVmM@pluto> (raw)
In-Reply-To: <20240117104116.2055349-5-quic_sibis@quicinc.com>
On Wed, Jan 17, 2024 at 04:11:16PM +0530, Sibi Sankar wrote:
> Register for limit change notifications if supported with the help of
> perf_notify_support interface and determine the throttled frequency
> using the perf_freq_xlate to apply HW pressure.
>
> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
> ---
>
> v2:
> * Export cpufreq_update_pressure and use it directly [Lukasz]
>
> drivers/cpufreq/scmi-cpufreq.c | 42 +++++++++++++++++++++++++++++++++-
> 1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index 4ee23f4ebf4a..e0aa85764451 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -25,9 +25,13 @@ struct scmi_data {
> int domain_id;
> int nr_opp;
> struct device *cpu_dev;
> + struct cpufreq_policy *policy;
> cpumask_var_t opp_shared_cpus;
> + struct notifier_block limit_notify_nb;
> };
>
> +const struct scmi_handle *handle;
> +static struct scmi_device *scmi_dev;
> static struct scmi_protocol_handle *ph;
> static const struct scmi_perf_proto_ops *perf_ops;
>
> @@ -144,6 +148,22 @@ scmi_get_cpu_power(struct device *cpu_dev, unsigned long *power,
> return 0;
> }
>
> +static int scmi_limit_notify_cb(struct notifier_block *nb, unsigned long event, void *data)
> +{
> + unsigned long freq_hz;
> + struct scmi_perf_limits_report *limit_notify = data;
> + struct scmi_data *priv = container_of(nb, struct scmi_data, limit_notify_nb);
> + struct cpufreq_policy *policy = priv->policy;
> +
> + if (perf_ops->perf_freq_xlate(ph, priv->domain_id, limit_notify->range_max, &freq_hz))
> + return NOTIFY_OK;
> +
> + policy->max = freq_hz / HZ_PER_KHZ;
> + cpufreq_update_pressure(policy);
> +
> + return NOTIFY_OK;
> +}
> +
> static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> {
> int ret, nr_opp, domain;
> @@ -151,6 +171,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> struct device *cpu_dev;
> struct scmi_data *priv;
> struct cpufreq_frequency_table *freq_table;
> + struct scmi_perf_notify_info info = {};
>
> cpu_dev = get_cpu_device(policy->cpu);
> if (!cpu_dev) {
> @@ -250,6 +271,25 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> policy->fast_switch_possible =
> perf_ops->fast_switch_possible(ph, domain);
>
> + ret = perf_ops->perf_notify_support(ph, domain, &info);
> + if (ret)
> + dev_warn(cpu_dev, "failed to get supported notifications: %d\n", ret);
> +
> + if (info.perf_limit_notify) {
> + priv->limit_notify_nb.notifier_call = scmi_limit_notify_cb;
> + ret = handle->notify_ops->devm_event_notifier_register(scmi_dev, SCMI_PROTOCOL_PERF,
> + SCMI_EVENT_PERFORMANCE_LIMITS_CHANGED,
> + &domain,
> + &priv->limit_notify_nb);
> + if (ret) {
> + dev_err(cpu_dev, "Error in registering limit change notifier for domain %d\n",
> + domain);
> + return ret;
> + }
Is there a reason to fail completely here if it was not possible to register
the notifier ? (even though expected to succeed given perf_limit_notify
was true...)
Maybe a big fat warn that the system perf could be degraded, but
carrying on ?
Or maybe you have in mind a good reason to fail like you did, so please
explain in that case in a comment.
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-29 15:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 10:41 [PATCH V2 0/4] firmware: arm_scmi: Register and handle limits change notification Sibi Sankar
2024-01-17 10:41 ` Sibi Sankar
2024-01-17 10:41 ` [PATCH V2 1/4] firmware: arm_scmi: Add perf_notify_support interface Sibi Sankar
2024-01-17 10:41 ` Sibi Sankar
2024-01-29 15:50 ` Cristian Marussi
2024-01-29 15:50 ` Cristian Marussi
2024-01-29 17:33 ` Cristian Marussi
2024-01-29 17:33 ` Cristian Marussi
2024-01-31 11:28 ` Sudeep Holla
2024-01-31 11:28 ` Sudeep Holla
2024-01-31 11:35 ` Cristian Marussi
2024-01-31 11:35 ` Cristian Marussi
2024-02-12 12:44 ` Cristian Marussi
2024-02-12 12:44 ` Cristian Marussi
2024-02-13 5:40 ` Sibi Sankar
2024-02-13 5:40 ` Sibi Sankar
2024-01-17 10:41 ` [PATCH V2 2/4] firmware: arm_scmi: Add perf_freq_xlate interface Sibi Sankar
2024-01-17 10:41 ` Sibi Sankar
2024-01-29 15:53 ` Cristian Marussi
2024-01-29 15:53 ` Cristian Marussi
2024-01-31 11:45 ` Cristian Marussi
2024-01-31 11:45 ` Cristian Marussi
2024-01-17 10:41 ` [PATCH V2 3/4] cpufreq: Export cpufreq_update_pressure Sibi Sankar
2024-01-17 10:41 ` Sibi Sankar
2024-01-17 10:41 ` [PATCH V2 4/4] cpufreq: scmi: Register for limit change notifications Sibi Sankar
2024-01-17 10:41 ` Sibi Sankar
2024-01-29 15:59 ` Cristian Marussi [this message]
2024-01-29 15:59 ` Cristian Marussi
2024-02-13 5:42 ` Sibi Sankar
2024-02-13 5:42 ` Sibi Sankar
2024-01-31 14:29 ` Pierre Gondois
2024-01-31 14:29 ` Pierre Gondois
2024-02-13 5:46 ` Sibi Sankar
2024-02-13 5:46 ` Sibi Sankar
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=ZbfLdvi_sePXiVmM@pluto \
--to=cristian.marussi@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=morten.rasmussen@arm.com \
--cc=quic_mdtipton@quicinc.com \
--cc=quic_sibis@quicinc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.