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

[Christian Loehle <christian.loehle@arm.com>]

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@huawei.com>


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).

The question is also how often the combination of "enable nominal < highest"
and then explicitly toggling boost at runtime actually happens...

> ---
> Changes in v2:
> - Drop "even" and clarify the commit message (Christian).
> - Link to v1: https://lore.kernel.org/all/20261015015812.867988-1-zhangpengjie2@huawei.com/
> 
>  drivers/cpufreq/cppc_cpufreq.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 80893844353c..0a4255a36f60 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -1052,6 +1052,25 @@ static struct cpufreq_driver cppc_cpufreq_driver = {
>  	.name = "cppc_cpufreq",
>  };
>  
> +static void __init cppc_cpufreq_default_boost_init(void)
> +{
> +	struct cppc_perf_caps caps;
> +	bool enable = false;
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		if (cppc_get_perf_caps(cpu, &caps))
> +			continue;
> +
> +		if (caps.highest_perf > caps.nominal_perf) {
> +			enable = true;
> +			break;
> +		}
> +	}
> +
> +	cppc_cpufreq_driver.boost_enabled = enable;

Any reason for the scan instead of just setting
boost_enabled = true? Platforms without boost would
also expose the toggle, but that's mostly in line with
the other drivers? (also again the ospm_nominal_perf
angle)

> +}
> +
>  static int __init cppc_cpufreq_init(void)
>  {
>  	int ret;
> @@ -1061,6 +1080,7 @@ static int __init cppc_cpufreq_init(void)
>  
>  	cppc_freq_invariance_init();
>  	populate_efficiency_class();
> +	cppc_cpufreq_default_boost_init();
>  
>  	ret = cpufreq_register_driver(&cppc_cpufreq_driver);
>  	if (ret)