Received-SPF: pass (google.com: domain of linux-kernel+bounces-194981-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 30 May 2024 11:46:21 +0530
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Riwen Lu <luriwen@hotmail.com>
Cc: Ionela Voinescu <ionela.voinescu@arm.com>,
	Beata Michalska <beata.michalska@arm.com>,
	Hoan Tran <hotran@apm.com>, rafael@kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Riwen Lu <luriwen@kylinos.cn>
Subject: Re: [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set
 target
Message-ID: <20240530061621.36byo5a2iqc6o2az@vireshk-i7>
References: <TYCP286MB24861BA890594C119892FB3DB1F22@TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM>
 <20240529053652.pzcjoyor7i23qc4i@vireshk-i7>
 <TYCP286MB248669BCAD7A7E54C5071EF9B1F22@TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM>
 <20240529071244.vwognqagaa4347dm@vireshk-i7>
 <TYCP286MB2486B1D734F8E2D74BFBEEB1B1F32@TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM>
 <20240530055624.quutkzdd44l3oevc@vireshk-i7>
 <TYCP286MB2486A0F14AE38F83F425F506B1F32@TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <TYCP286MB2486A0F14AE38F83F425F506B1F32@TYCP286MB2486.JPNP286.PROD.OUTLOOK.COM>

On 30-05-24, 14:02, Riwen Lu wrote:
> 在 2024/5/30 13:56, Viresh Kumar 写道:
> > Cc'ing few more people.
> > 
> > On 30-05-24, 09:06, Riwen Lu wrote:
> > > 在 2024/5/29 15:12, Viresh Kumar 写道:
> > > > On 29-05-24, 14:53, Riwen Lu wrote:
> > > > > Yes, you are right， I didn't think it through. In this circumstance, the
> > > > > policy->cur is the highest frequency, desired_perf converted from
> > > > > target_freq is the same with cpu_data->perf_ctrls.desired_perf which
> > > > > shouldn't.
> > > > 
> > > > Please investigate more and see where the real problem is.
> > > > 
> > > The boot CPU's frequency would be configured to the highest perf when
> > > powered on from S3 even though the policy governor is powersave.
> > > 
> > > In 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 and cpu->perf_ctrls.desired_perf are the same and
> > > both are the lowest_perf.
> > > 
> > > The problem is that the cpu->perf_ctrls.desired_perf is the lowest_perf but
> > > it should be the highest_perf.
> > > 
> > > In my opinion, desired_perf and cpu->perf_ctrls.desired_perf represent the
> > > target_freq and policy->cur respectively. Since target_freq and policy->cur
> > > have been compared in __cpufreq_driver_target(), there's no need to compare
> > > desired_perf and cpu->perf_ctrls.desired_perf again in
> > > cppc_cpufreq_set_target().
> > > So, maybe we can remove the following logic in cppc_cpufreq_set_target().
> > > /* Return if it is exactly the same perf */
> > > if (desired_perf == cpu_data->perf_ctrls.desired_perf)
> > > 	return ret;
> > 
> > This is what I was thinking as well yesterday.
> > 
> OK, I'll push a V3 patch.

Please CC everyone from this email.

-- 
viresh