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

[Riwen Lu]

在 2024/5/30 13:56, Viresh Kumar 写道:
> Cc'ing few more people.
>
> On 30-05-24, 09:06, Riwen Lu wrote:
> > 在 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;
>
> This is what I was thinking as well yesterday.
OK, I'll push a V3 patch.