public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Jie Zhan <zhanjie9@hisilicon.com>,
	Beata Michalska <beata.michalska@arm.com>,
	rafael@kernel.org, linux-pm@vger.kernel.org,
	linux-acpi@vger.kernel.org, linuxarm@huawei.com,
	liaochang1@huawei.com, wanghuiqiang@huawei.com,
	prime.zeng@hisilicon.com, fanghao11@huawei.com,
	jonathan.cameron@huawei.com
Subject: Re: [PATCH] cpufreq: CPPC: Return desired perf in ->get() if feedback counters are 0
Date: Wed, 28 Aug 2024 09:17:33 +0100	[thread overview]
Message-ID: <Zs7dHdj6xaR1cpSN@arm.com> (raw)
In-Reply-To: <20240828065041.xf4csybut3csl5mn@vireshk-i7>

Hi,

On Wednesday 28 Aug 2024 at 12:20:41 (+0530), Viresh Kumar wrote:
> Cc'd few developers.
> 
> On 19-08-24, 11:51, Jie Zhan wrote:
> > The CPPC performance feedback counters could return 0 when the target cpu
> > is in a deep idle state (e.g. powered off) and those counters are not
> > powered.  cppc_cpufreq_get_rate() returns 0 in this case, triggering two
> > problems:
> > 
> > 1. cpufreq_online() gets a false error and doesn't generate a cpufreq
> > policy, which happens in cpufreq_add_dev() when a new cpu device is added.
> > 2. 'cpuinfo_cur_freq' shows '<unknown>'

I suppose 2. is not necessarily a problem as the current (hardware)
frequency is indeed unknown.

But there's not clean way to fix 1. while keeping 2. as is, or at least
not one I could identify.

> > 
> > Don't take it as an error and return the frequency corresponding to the
> > desired perf when the feedback counters are 0.
> > 
> > Fixes: 6a4fec4f6d30 ("cpufreq: cppc: cppc_cpufreq_get_rate() returns zero in all error cases.")
> > Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
> > ---
> >  drivers/cpufreq/cppc_cpufreq.c | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> > index bafa32dd375d..1c5eb12c1a5a 100644
> > --- a/drivers/cpufreq/cppc_cpufreq.c
> > +++ b/drivers/cpufreq/cppc_cpufreq.c
> > @@ -748,18 +748,25 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int cpu)
> >  
> >  	ret = cppc_get_perf_ctrs(cpu, &fb_ctrs_t0);
> >  	if (ret)
> > -		return 0;
> > +		goto out_err;
> >  
> >  	udelay(2); /* 2usec delay between sampling */
> >  
> >  	ret = cppc_get_perf_ctrs(cpu, &fb_ctrs_t1);
> >  	if (ret)
> > -		return 0;
> > +		goto out_err;
> >  
> >  	delivered_perf = cppc_perf_from_fbctrs(cpu_data, &fb_ctrs_t0,
> >  					       &fb_ctrs_t1);
> >  
> >  	return cppc_perf_to_khz(&cpu_data->perf_caps, delivered_perf);
> > +
> > +out_err:
> > +	if (ret == -EFAULT)
> > +		return cppc_perf_to_khz(&cpu_data->perf_caps,
> > +					cpu_data->perf_ctrls.desired_perf);
> > +

A better way might be to cppc_get_desired_perf(cpu, &desired_perf) first
and return the khz equivalent of the result, as currently done in
hisi_cppc_cpufreq_get_rate(). Even a merge of the two functions might be
suitable, but I'm not familiar with the specifics of the hisilicon platforms
involved. This might be better as some platforms can provide performance
feedback through the desired performance register so a read of it would
be better than using the cached desired_perf value.

Hope it helps,
Ionela.

> > +	return 0;
> >  }
> >  
> >  static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
> > -- 
> > 2.33.0
> > 
> 
> -- 
> viresh

  reply	other threads:[~2024-08-28  8:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19  3:51 [PATCH] cpufreq: CPPC: Return desired perf in ->get() if feedback counters are 0 Jie Zhan
2024-08-21  8:27 ` Jie Zhan
2024-08-28  2:19   ` Jie Zhan
2024-08-28  6:50 ` Viresh Kumar
2024-08-28  8:17   ` Ionela Voinescu [this message]
2024-08-28  9:45     ` Jie Zhan
2024-08-28 10:12       ` Ionela Voinescu

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=Zs7dHdj6xaR1cpSN@arm.com \
    --to=ionela.voinescu@arm.com \
    --cc=beata.michalska@arm.com \
    --cc=fanghao11@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=liaochang1@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=rafael@kernel.org \
    --cc=viresh.kumar@linaro.org \
    --cc=wanghuiqiang@huawei.com \
    --cc=zhanjie9@hisilicon.com \
    /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