Re: [PATCH v3 2/2] cpufreq: fix policy max not returning to non-boost freq on boost disable

[Viresh Kumar]

Hi,

On 29-09-26, 17:08, Ananthu C V wrote:
> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if
> max boost is known") introduced a guard for cpuinfo max updates to only
> increase, to preserve driver-set values above the freq table maximum.
> Later commit db80ad776cd2 ("cpufreq: Remove driver default policy->min/max
> init") dropped the 'policy->max = max_freq' assignment from
> cpufreq_frequency_table_cpuinfo, leaving that one-way-guard to be the only
> path for cpuinfo max and consequently policy max to be updated, causing
> both values to be stuck at boost frequency even when boost is disabled.
> 
> Unconditionally track the highest non-boost frequency (max_base_freq)
> in the freq table. If boost frequencies are available, use the highest
> frequency from the table/max_base_freq instead of cpuinfo->max_freq to
> control boost values, so the value can decrease again when boost is
> disabled.

If this is a fix, it should be submitted separately so we can get this merged
independently.

> Fixes: db80ad776cd2 ("cpufreq: Remove driver default policy->min/max init")

I am not able to understand the current problem though. I see from the sequence
of events mentioned in your cover-letter that scaling_max_freq doesn't return
back, but why ?

And does a simple revert of the above commit (just freq_table.c) fixes it ?

> Signed-off-by: Ananthu C V <ananthu.cv@xxxxxxxxxxxxxxxx>
> ---
>  drivers/cpufreq/cpufreq.c    | 16 +++++++++++++++-
>  drivers/cpufreq/freq_table.c |  9 ++++++++-
>  include/linux/cpufreq.h      |  3 +++
>  3 files changed, 26 insertions(+), 2 deletions(-)

-- 
viresh