Re: [PATCH v2] cpufreq: CPPC: Enable boost by default when supported

[Jie Zhan]

On 10/29/2026 4:51 AM, Christian Loehle wrote:
> On 10/22/26 08:59, Pengjie Zhang wrote:
>> The CPPC driver leaves boost disabled by default when Highest Performance
>> exceeds Nominal Performance. Userspace must explicitly enable boost
>> before governors can use the full advertised performance range.
>>
>> Enable boost by default when at least one possible CPU reports support,
>> while users who prefer to stay within the sustained nominal limit can
>> still disable it via the boost knob without determining scaling_max_freq
>> for each policy.
>>
>> Check the performance capabilities before registering the driver so that
>> the cpufreq core enables boost for each policy that supports it.
>>
>> Signed-off-by: Pengjie Zhang <zhangpengjie2@xxxxxxxxxx>
> 
> 
> Just to be clear I'm not blocking this per se, but continuing my comments:
> 
> I just wonder if this is a configuration worth keeping.
> You mentioned your platforms have a BIOS to set nominal==highest or not.
> If we removed interpreting highest - nominal as boost entirely that
> would also make that BIOS setting obsolete. Userspace could still
> query nominal and restrict cpufreq to that if it wishes to do that,
> we could add that to cpupower for convenience (i.e. set all policies'
> max to nominal).
> 
> With the changes that are coming with CPCv4 we would save ourselves
> some headache (like keeping track of boost status when ospm_nominal_perf
> is being written).
That would be just some bonus functions.

I think the idea is to give userspace a knob to toggle boost on/off and
check the current status.

As of now, we don't have a better way to achieve this other than taking
highest > nominal.
> 
> The question is also how often the combination of "enable nominal < highest"
> and then explicitly toggling boost at runtime actually happens...
> 
In most cases, it's only set up once on boot.
Some experimental, debugging, or clever userspace strategies may toggle it
more often. Who knows :)

[...]