All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Riwen Lu <luriwen@hotmail.com>,
	beata.michalska@arm.com, rafael@kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	hotran@apm.com, Riwen Lu <luriwen@kylinos.cn>
Subject: Re: [PATCH v3] cpufreq/cppc: Remove the desired_perf compare when set target
Date: Tue, 11 Jun 2024 09:54:43 +0100	[thread overview]
Message-ID: <ZmgQ06jtJBPh5wat@arm.com> (raw)
In-Reply-To: <20240606090737.z3qenphikjs5ijj4@vireshk-i7>

Hey,

On Thursday 06 Jun 2024 at 14:37:37 (+0530), Viresh Kumar wrote:
> Ionela, Beata,
> 
> On 30-05-24, 19:08, Riwen Lu wrote:
> > From: Riwen Lu <luriwen@kylinos.cn>
> > 
> > There is a case that desired_perf is exactly the same with the old perf,
> > but the actual current freq is not.
> > 
> > This happened in S3 while the cpufreq governor is set to powersave.
> > During cpufreq resume process, the booting CPU's new_freq obtained via
> > .get() is the highest frequency, while the policy->cur and
> > cpu->perf_ctrls.desired_perf are in the lowest level(powersave
> > governor). Causing the warning: "CPU frequency out of sync:", and set
> > policy->cur to new_freq. Then the governor->limits() calls
> > cppc_cpufreq_set_target() to configures the CPU frequency and returns
> > directly because the desired_perf converted from target_freq is the
> > same with cpu->perf_ctrls.desired_perf and both are the lowest_perf.
> > Since target_freq and policy->cur have been compared in
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	  [note] below

> > __cpufreq_driver_target(), there's no need to compare desired_perf
> > and cpu->perf_ctrls.desired_perf again in cppc_cpufreq_set_target()
> > to ensure that the CPU frequency is properly configured.
> > 
> > Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
> > 
> > ---
> > v1 -> v2:
> >  - Update commit message and email.
> > v2 -> v3:
> >  - Update patch subject and commit message.
> >  - Remove the desired_perf compare logic.
> > ---
> >  drivers/cpufreq/cppc_cpufreq.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> > index 15f1d41920a3..337cece61ab5 100644
> > --- a/drivers/cpufreq/cppc_cpufreq.c
> > +++ b/drivers/cpufreq/cppc_cpufreq.c
> > @@ -295,9 +295,6 @@ static int cppc_cpufreq_set_target(struct cpufreq_policy *policy,
> >  	int ret = 0;
> >  
> >  	desired_perf = cppc_khz_to_perf(&cpu_data->perf_caps, target_freq);
> > -	/* Return if it is exactly the same perf */
> > -	if (desired_perf == cpu_data->perf_ctrls.desired_perf)
> > -		return ret;
> >  
> >  	cpu_data->perf_ctrls.desired_perf = desired_perf;
> >  	freqs.old = policy->cur;
> 
> Any objections to this change ?

It's alright with me.

Some "nits":
 - the "desired_perf" local variable could be removed in this case.

 - [note] while this change helps, we'd still need policy->cur to always
   have the latest request value (see details at [1]) for this check to
   be made obsolete by the comparison between target_freq and policy->cur,
   as mentioned in the commit message. But this is/can be a separate
   matter.

   [1] https://lore.kernel.org/lkml/ZmB1qKucR5fXk100@arm.com/

Thanks,
Ionela.

> 
> -- 
> viresh

  reply	other threads:[~2024-06-11  8:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29  3:22 [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set target Riwen Lu
2024-05-29  5:36 ` Viresh Kumar
2024-05-29  6:53   ` Riwen Lu
2024-05-29  7:12     ` Viresh Kumar
2024-05-30  1:06       ` Riwen Lu
2024-05-30  5:56         ` Viresh Kumar
2024-05-30  6:02           ` Riwen Lu
2024-05-30  6:16             ` Viresh Kumar
2024-05-30 11:08               ` [PATCH v3] cpufreq/cppc: Remove the desired_perf compare " Riwen Lu
2024-06-06  9:07                 ` Viresh Kumar
2024-06-11  8:54                   ` Ionela Voinescu [this message]
2024-06-11  9:10                     ` Viresh Kumar
2024-06-12  2:52                       ` Riwen Lu
2024-06-12  6:24                         ` Viresh Kumar
2024-06-12  6:26                           ` Viresh Kumar
2024-06-14 12:12                           ` Riwen Lu
2024-06-12  9:08                 ` Pierre Gondois

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=ZmgQ06jtJBPh5wat@arm.com \
    --to=ionela.voinescu@arm.com \
    --cc=beata.michalska@arm.com \
    --cc=hotran@apm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=luriwen@hotmail.com \
    --cc=luriwen@kylinos.cn \
    --cc=rafael@kernel.org \
    --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.