Re: [PATCH v2] cpufreq: CPPC: add autonomous mode boot parameter support

[Jie Zhan <zhanjie9@hisilicon.com>]

On 5/5/2026 8:29 PM, Sumit Gupta wrote:
> Hi Jie,
> 
> 
> On 27/04/26 13:54, Jie Zhan wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> Hi Sumit,
>>
>> In general, I would expect this parameter only toggles on auto_sel by
>> default.  IIUC, other CPPC configurations (min/max/desired perf, EPP,
>> enable) are optional and not closely related to this.
>>
>> Why including those stuff here?
>>
>>
>> Please see other questions inline.
>>
>> Thanks!
>> Jie
> 
> These together provide a known, predictable autonomous mode boot.
> min/max/desired seeding ensures HW has a known starting bound (BIOS
> may leave them unset).
> EPP=PERFORMANCE_PREF is needed as BIOS defaults often bias toward
> energy saving, and admins on many CPU systems shouldn't have to script
> per CPU sysfs writes at every boot to undo that.
Hi Sumit,

The min/max/desired perf might be a slightly different case, but the EPP
value should probably follow the default if there is?
Otherwise, users may complain that their BIOS defaults don't work and find
out it's driver's fault.

Alternatively, we may also make an assumption that we ignore BIOS EPP
config, but not sure if that's suitable?

(Perhaps let's just discuss in the bottom trunk because the main issue is
pretty much the same.)
>>
>> On 4/25/2026 4:18 AM, Sumit Gupta wrote:
>>> Add a kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable
>>> CPPC autonomous performance selection on all CPUs at system startup.
>>> When autonomous mode is enabled, the hardware automatically adjusts
>>> CPU performance based on workload demands using Energy Performance
>>> Preference (EPP) hints.
>>>
>>> When auto_sel_mode=1:
>>> - Configure all CPUs for autonomous operation on first init
>>> - Set EPP to performance preference (0x0)
>>> - Use HW min/max_perf when available; otherwise initialize from caps
>>> - Clamp desired_perf to bounds before enabling autonomous mode
>>> - Hardware controls frequency instead of the OS governor
>>>
>>> The boot parameter is applied only during first policy initialization.
>>> Skip applying it on CPU hotplug to preserve runtime sysfs configuration.
>>>
>>> This patch depends on patch [2] ("cpufreq: Set policy->min and max
>>> as real QoS constraints") so that the policy->min/max set in
>>> cppc_cpufreq_cpu_init() are not overridden by cpufreq_set_policy()
>>> during init.
>>>
>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> (Documentation)
>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>> ---
>>> v[1] -> v2:
>>> - Call cppc_set_enable() unconditionally so CPPC is enabled for both
>>>    OS-driven and autonomous modes.
>> Why adding this in v2?
>> This looks like a separate issue since setting CPPC Enable reg doesn't seem
>> to be related with autonomous control.
> 
> In v2, moved it out of the auto_sel specific check.
> Agree that cppc_set_enable() is general CPPC enablement and can be split
> into a separate patch in v3 if preferred.
> 
Yeah it should be a separate patch I think.
>>> - Init min/max from caps instead of cppc_cpufreq_update_perf_limits()
>>>    as policy->min/max aren't yet populated.
>>>
>>> [1] https://lore.kernel.org/lkml/20260317151053.2361475-1-sumitg@nvidia.com/
>>> [2] https://lore.kernel.org/lkml/20260423084731.1090384-2-pierre.gondois@arm.com/
>>> ---
>>>   .../admin-guide/kernel-parameters.txt         | 13 +++
>>>   drivers/cpufreq/cppc_cpufreq.c                | 89 +++++++++++++++++--
>>>   2 files changed, 97 insertions(+), 5 deletions(-)
>>>
...
>>> +
>>> +             policy->cur = cppc_perf_to_khz(caps,
>>> +                                            cpu_data->perf_ctrls.desired_perf);
>>> +
>>> +             /* EPP is optional - some platforms may not support it */
>>> +             ret = cppc_set_epp(cpu, CPPC_EPP_PERFORMANCE_PREF);
>> Why setting this to PERFORMANCE by default?
>> A platform can have its own default EPP value.  This would override that.
> 
> The boot option targets performance oriented use cases on many CPU
> systems, avoiding sysfs scripting across all CPUs on every boot.
> The BIOS default EPP (often biased toward energy saving) would otherwise
> steer HW away from that goal. Admins can still re-tune EPP at runtime via
> the existing energy_performance_preference_val sysfs.
> 
Yeah, avoiding scripting makes sense for sure.
The thing is how do we do this nicely.

For now we need to consider follow either the BIOS default or the driver
default.
They seem to be exclusive since there isn't a clear way to support both at
the same time.

So, are we going to support the BIOS default case?
For example, users can config a default EPP in the BIOS setup menu.
>>> +             if (ret && ret != -EOPNOTSUPP)
>>> +                     pr_warn("Failed to set EPP for CPU%d (%d)\n", cpu, ret);
>>> +             else if (!ret)
>>> +                     cpu_data->perf_ctrls.energy_perf = CPPC_EPP_PERFORMANCE_PREF;
>>> +
...