| Message ID | 20240529023059.2821104-1-luriwen@kylin.cn (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [v1] cpufreq/cppc: Take policy->cur into judge when set target | expand |
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index 15f1d41920a3..802f7c7c0ad8 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -296,7 +296,8 @@ static int cppc_cpufreq_set_target(struct cpufreq_policy *policy, 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) + if (desired_perf == cpu_data->perf_ctrls.desired_perf && + desired_perf == policy->cur) return ret; cpu_data->perf_ctrls.desired_perf = desired_perf;
There is a case that desired_perf is exactly the same with the old perf, but the actual current freq is not. Add a judgment condition to return only when the three values are exactly the same. This happened in S3 while the cpufreq governor is set to powersave. During resume process, the CPU frequency is adjusted to the highest perf. For the booting CPU, there's a warning that "CPU frequency out of sync", because the policy->cur is the lowest_perf while the actual current frequency is the highest_perf that obtained via cppc_cpufreq_get_rate(), then set policy->cur to highest_perf. The governor->limits() intent to configure the CPU frequency to lowest_perf and the governor->target() returned because the desired_perf is equal to cpu->perf_ctrls.desired_perf leaving the actual current frequency and policy->cur are remain the highest_perf. Add the judgement that whether policy->cur is the same with desired_perf. Signed-off-by: luriwen <luriwen@kylin.cn> --- drivers/cpufreq/cppc_cpufreq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)