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;