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

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

[Sumit Gupta]

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.

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

>> - 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(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 0a1abed1b93c..751817b0573a 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1067,6 +1067,19 @@ Kernel parameters
>>                        policy to use. This governor must be registered in the
>>                        kernel before the cpufreq driver probes.
>>
>> +     cppc_cpufreq.auto_sel_mode=
>> +                     [CPU_FREQ] Enable ACPI CPPC autonomous performance
>> +                     selection. When enabled, hardware automatically adjusts
>> +                     CPU frequency on all CPUs based on workload demands.
>> +                     In Autonomous mode, Energy Performance Preference (EPP)
>> +                     hints guide hardware toward performance (0x0) or energy
>> +                     efficiency (0xff).
>> +                     Requires ACPI CPPC autonomous selection register support.
>> +                     Format: <bool>
>> +                     Default: 0 (disabled)
>> +                     0: use cpufreq governors
>> +                     1: enable if supported by hardware
>> +
>>        cpu_init_udelay=N
>>                        [X86,EARLY] Delay for N microsec between assert and de-assert
>>                        of APIC INIT to start processors.  This delay occurs
>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>> index 02db03d03755..672fc3058190 100644
>> --- a/drivers/cpufreq/cppc_cpufreq.c
>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> @@ -28,6 +28,9 @@
>>
>>   static struct cpufreq_driver cppc_cpufreq_driver;
>>
>> +/* Autonomous Selection boot parameter */
>> +static bool auto_sel_mode;
>> +
>>   #ifdef CONFIG_ACPI_CPPC_CPUFREQ_FIE
>>   static enum {
>>        FIE_UNSET = -1,
>> @@ -656,6 +659,14 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
>>        caps = &cpu_data->perf_caps;
>>        policy->driver_data = cpu_data;
>>
>> +     /*
>> +      * Enable CPPC for both OS-driven and autonomous modes.
>> +      * The Enable register is optional - some platforms may not support it
>> +      */
>> +     ret = cppc_set_enable(cpu, true);
>> +     if (ret && ret != -EOPNOTSUPP)
>> +             pr_warn("Failed to enable CPPC for CPU%d (%d)\n", cpu, ret);
>> +
>>        min = cppc_perf_to_khz(caps, caps->lowest_nonlinear_perf);
>>        max = cppc_perf_to_khz(caps, policy->boost_enabled ?
>>                        caps->highest_perf : caps->nominal_perf);
>> @@ -711,11 +722,71 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
>>        policy->cur = cppc_perf_to_khz(caps, caps->highest_perf);
>>        cpu_data->perf_ctrls.desired_perf =  caps->highest_perf;
>>
>> -     ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>> -     if (ret) {
>> -             pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
>> -                      caps->highest_perf, cpu, ret);
>> -             goto out;
>> +     /*
>> +      * Enable autonomous mode on first init if boot param is set.
>> +      * Check last_governor to detect first init and skip if auto_sel
>> +      * is already enabled.
>> +      */
>> +     if (auto_sel_mode && policy->last_governor[0] == '\0' &&
>> +         !cpu_data->perf_ctrls.auto_sel) {
>> +             /* Init min/max_perf from caps if not already set by HW. */
>> +             if (!cpu_data->perf_ctrls.min_perf)
>> +                     cpu_data->perf_ctrls.min_perf = caps->lowest_nonlinear_perf;
>> +             if (!cpu_data->perf_ctrls.max_perf)
>> +                     cpu_data->perf_ctrls.max_perf = policy->boost_enabled ?
>> +                             caps->highest_perf : caps->nominal_perf;
> Is it automatically adjusted when switching boost on and off?

Yes. Here just setting the the initial value. Subsequent boost toggles
propagate via the existing QoS/CPUFREQ_NEED_UPDATE_LIMITS flow:
a FREQ_QOS_MAX update triggers .target (cppc_cpufreq_set_target)
-> cppc_set_perf, which sets the new max_perf to HW.

>> +
>> +             cpu_data->perf_ctrls.desired_perf =
>> +                     clamp_t(u32, cpu_data->perf_ctrls.desired_perf,
>> +                             cpu_data->perf_ctrls.min_perf,
>> +                             cpu_data->perf_ctrls.max_perf);
> Why do we need to clamp desire_perf here?

You are right, the clamp isn't really needed.
With auto_sel, the desired_perf is an optional hint. EPP and the
platform drive actual selection within [min_perf, max_perf].
We can simply initialize desired_perf to max_perf as starting hint.
I will update it to below in v3:
     cpu_data->perf_ctrls.desired_perf = cpu_data->perf_ctrls.max_perf;

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


>> +             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;
>> +
>> +             /* Program min/max/desired into CPPC regs before enabling auto_sel. */
>> +             ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>> +             if (ret) {
>> +                     pr_debug("Err setting perf for autonomous mode CPU:%d ret:%d\n",
>> +                              cpu, ret);
>> +                     goto out;
> Shouldn't this be pr_warn(), or even pr_err(), if it needs to bail out?
>
> However, IIUC setting min/max/desired perf is optional for auto_sel, so
> better to pr_info() and continue setting auto_sel?

Agree that we shouldn't fail the whole init here.
Even if cppc_set_perf fails, HW can still operate in autonomous mode.
Prefer pr_warn to pr_info as a non-zero cppc_set_perf return means a
real error, not a missing register, so it's worth flagging.
Will update in v3.


>> +             }
>> +
>> +             ret = cppc_set_auto_sel(cpu, true);
>> +             if (ret && ret != -EOPNOTSUPP) {
>> +                     pr_warn("Failed autonomous config for CPU%d (%d)\n",
>> +                             cpu, ret);
>> +                     goto out;
> Bailing out here would end up without DVFS support.
> Can we fall back to the normal OS directed mode?

Good point.
The fallback is already wired up: when auto_sel stays false, the next
else branch takes the OS directed path. So I will just drop the goto out
and update the message in v3.

Thank you,
Sumit Gupta


>> +             }
>> +             if (!ret)
>> +                     cpu_data->perf_ctrls.auto_sel = true;
>> +     }
>> +
>> +     if (cpu_data->perf_ctrls.auto_sel) {
>> +             /* Sync policy limits from HW when autonomous mode is active */
>> +             policy->min = cppc_perf_to_khz(caps,
>> +                                            cpu_data->perf_ctrls.min_perf ?:
>> +                                            caps->lowest_nonlinear_perf);
>> +             policy->max = cppc_perf_to_khz(caps,
>> +                                            cpu_data->perf_ctrls.max_perf ?:
>> +                                            (policy->boost_enabled ?
>> +                                             caps->highest_perf :
>> +                                             caps->nominal_perf));
>> +     } else {
>> +             /* Normal mode: governors control frequency */
>> +             ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>> +             if (ret) {
>> +                     pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
>> +                              caps->highest_perf, cpu, ret);
>> +                     goto out;
>> +             }
>>        }
>>
>>        cppc_cpufreq_cpu_fie_init(policy);
>> @@ -1035,10 +1106,18 @@ static int __init cppc_cpufreq_init(void)
>>
>>   static void __exit cppc_cpufreq_exit(void)
>>   {
>> +     unsigned int cpu;
>> +
>> +     for_each_present_cpu(cpu)
>> +             cppc_set_auto_sel(cpu, false);
>> +
>>        cpufreq_unregister_driver(&cppc_cpufreq_driver);
>>        cppc_freq_invariance_exit();
>>   }
>>
>> +module_param(auto_sel_mode, bool, 0444);
>> +MODULE_PARM_DESC(auto_sel_mode, "Enable CPPC autonomous performance selection at boot");
>> +
>>   module_exit(cppc_cpufreq_exit);
>>   MODULE_AUTHOR("Ashwin Chaugule");
>>   MODULE_DESCRIPTION("CPUFreq driver based on the ACPI CPPC v5.0+ spec");

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

[Jie Zhan]

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;
>>> +
...

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

[Sumit Gupta]

On 08/05/26 08:03, Jie Zhan wrote:
> External email: Use caution opening links or attachments
>
>
> 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.

To consider the BIOS default case, we can extend the parameter to accept
an EPP mode in v3:
- cppc_cpufreq.auto_sel_mode=performance / =1 (EPP=performance)
- cppc_cpufreq.auto_sel_mode=default / =2 (preserve BIOS EPP)

Thank you,
Sumit Gupta

....