Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled
Sibi Sankar <[email protected]>
| Newsgroups | org.kernel.vger.linux-pm,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 8/6/2026 4:52 PM, Zhongqiu Han wrote: > Hi Sibi and Ananthu, > > On 8/6/2026 12:42 PM, Sibi Sankar wrote: >> From: Ananthu C V <[email protected]> >> >> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly >> if max boost is known") guarded cpuinfo max updates to only allow >> increases, preserving values set directly by drivers above the freq >> table maximum. This prevents cpuinfo max from decreasing on boost >> disable, leaving policy max pinned at the boost ceiling. >> >> Remove the guard so cpuinfo max is always derived from the frequency >> table scan. Drivers that correctly flag boost entries are unaffected >> since the scan already excludes them when boost is off. >> >> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if >> max boost is known") >> Signed-off-by: Ananthu C V <[email protected]> >> Signed-off-by: Sibi Sankar <[email protected]> >> --- >> drivers/cpufreq/freq_table.c | 7 +------ >> 1 file changed, 1 insertion(+), 6 deletions(-) >> >> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c >> index ea994647abc8..791118466ca4 100644 >> --- a/drivers/cpufreq/freq_table.c >> +++ b/drivers/cpufreq/freq_table.c >> @@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct >> cpufreq_policy *policy) >> } >> policy->cpuinfo.min_freq = min_freq; >> - /* >> - * If the driver has set its own cpuinfo.max_freq above >> max_freq, leave >> - * it as is. >> - */ >> - if (policy->cpuinfo.max_freq < max_freq) >> - policy->cpuinfo.max_freq = max_freq; > > As I understand it, the guard added by commit 538b0188da46 is > intended for drivers (e.g. acpi-cpufreq and AMD) that may set > cpuinfo.max_freq above the maximum frequency in the frequency table. > Removing it may cause those drivers to lose their boost maximum > frequency. Yup, we did mention the same in the cover letter. > > The regression should instead be related to commit db80ad776cd2 > ("cpufreq: Remove driver default policy->min/max init"), which removed > the "policy->max = max_freq" initialization that previously allowed > policy->max to track the result of the boost-aware frequency scan. > > Please feel free to let me know what you think. Thanks > The commit db80ad776cd2 is unrelated. The problem comes from the fact that policy_set_boost uses policy->cpuinfo.max_freq in it's freq_qos_update_request. If we modify it to use a frequency that adheres to the boost and per-policy boost flag instead might be the right thing to do here. > >> + policy->cpuinfo.max_freq = max_freq; >> if (min_freq == ~0) >> return -EINVAL; > >