[v4] cpufreq/cppc: Remove the desired_perf compare when set target

Commit Message

Riwen Lu June 12, 2024, 11:46 a.m. UTC

From: Riwen Lu <[e-mail]>

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
__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 <[e-mail]>

---
v1 -> v2:
 - Update commit message and email.
v2 -> v3:
 - Update patch subject and commit message.
 - Remove the desired_perf compare logic.
v3 -> v4:
 - Remove the desired_perf local variable.
---
 drivers/cpufreq/cppc_cpufreq.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

Comments

Viresh Kumar June 13, 2024, 9:42 a.m. UTC | #1

On 12-06-24, 19:46, Riwen Lu wrote:
> From: Riwen Lu <[e-mail]>
> 
> 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
> __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 <[e-mail]>

Applied. Thanks.

Patch

diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 15f1d41920a3..9095fd5f8c2d 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -291,15 +291,10 @@  static int cppc_cpufreq_set_target(struct cpufreq_policy *policy,
 	struct cppc_cpudata *cpu_data = policy->driver_data;
 	unsigned int cpu = policy->cpu;
 	struct cpufreq_freqs freqs;
-	u32 desired_perf;
 	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;
+	cpu_data->perf_ctrls.desired_perf =
+			cppc_khz_to_perf(&cpu_data->perf_caps, target_freq);
 	freqs.old = policy->cur;
 	freqs.new = target_freq;