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

[Riwen Lu <luriwen@hotmail.com>]

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