Re: [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set target

From: Riwen Lu
Date: Wed May 29 2024 - 21:07:03 EST


在 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;