Message-ID: <66f58f43-631b-40a0-8d42-4e90cd24b757@arm.com>
Date: Fri, 16 Jan 2026 18:05:31 +0100
From: Pierre Gondois <pierre.gondois@....com>
To: Sumit Gupta <sumitg@...dia.com>, "zhenglifeng (A)"
 <zhenglifeng1@...wei.com>, rafael@...nel.org, viresh.kumar@...aro.org
Cc: linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org, ray.huang@....com,
 corbet@....net, robert.moore@...el.com, lenb@...nel.org,
 acpica-devel@...ts.linux.dev, mario.limonciello@....com,
 rdunlap@...radead.org, linux-kernel@...r.kernel.org, gautham.shenoy@....com,
 zhanjie9@...ilicon.com, ionela.voinescu@....com, perry.yuan@....com,
 linux-doc@...r.kernel.org, linux-acpi@...r.kernel.org, treding@...dia.com,
 jonathanh@...dia.com, vsethi@...dia.com, ksitaraman@...dia.com,
 sanjayc@...dia.com, nhartman@...dia.com, bbasu@...dia.com
Subject: Re: [PATCH v5 10/11] cpufreq: CPPC: make scaling_min/max_freq
 read-only when auto_sel enabled


On 1/15/26 16:22, Sumit Gupta wrote:
>
>>>> n 08/01/26 22:16, Pierre Gondois wrote:
>>>>> External email: Use caution opening links or attachments
>>>>>
>>>>>
>>>>> Hello Sumit, Lifeng,
>>>>>
>>>>> On 12/23/25 13:13, Sumit Gupta wrote:
>>>>>> When autonomous selection (auto_sel) is enabled, the hardware 
>>>>>> controls
>>>>>> performance within min_perf/max_perf register bounds making the
>>>>>> scaling_min/max_freq effectively read-only.
>>>>> If auto_sel is set, the governor associated to the policy will 
>>>>> have no
>>>>> actual control.
>>>>>
>>>>> E.g.:
>>>>> If the schedutil governor is used, attempts to set the
>>>>> frequency based on CPU utilization will be periodically
>>>>> sent, but they will have no effect.
>>>>>
>>>>> The same thing will happen for the ondemand, performance,
>>>>> powersave, userspace, etc. governors. They can only work if
>>>>> frequency requests are taken into account.
>>>>>
>>>>> ------------
>>>>>
>>>>> This looks like the intel_pstate governor handling where it is 
>>>>> possible
>>>>> not to have .target() or .target_index() callback and the hardware 
>>>>> is in
>>>>> charge (IIUC).
>>>>> For this case, only 2 governor seem available: performance and 
>>>>> powersave.
>>>>>
>> As you mentioned in [2], 'it still makes sense to have cpufreq 
>> requesting a
>> certain performance level even though autonomous selection is 
>> enabled'. So I
>> think it's OK to have a governor when auto_selection is enabled.
>>
Thanks for the pointer, I forgot the spec said said that the 
desired_perf register
could still be used while autonomous selection is activated. This means that
having an autonomous selection governor is not a good idea and that your
implementation is correct.

I'm asking some questions about this to someone who should know more.

Would it still be possible to split you patch in two as you suggested in 
another
message, i.e. PATCH[1-7] and PATCH[8-11] ? I don't have any additional 
comment
for PATCH[1-7], but I might have some questions for PATCH[8-11]. This would
give me a bit more time.

>> [2] 
>> https://lore.kernel.org/all/9f46991d-98c3-41f5-8133-6612b397e33a@arm.com/
>>
>>> Thanks for pointing me to the first version, I forgot how your
>>> first implementation was.
>>>
>>>
>>>> In v1 [1], I added a separate cppc_cpufreq_epp_driver instance without
>>>> target*() hooks, using setpolicy() instead (similar to AMD pstate).
>>>> However, this approach doesn't allow per-CPU control: if we boot 
>>>> with the
>>>> EPP driver, we can't dynamically disable auto_sel for individual 
>>>> CPUs and
>>>> return to OS governor control (no target hook available). AMD and 
>>>> Intel
>>>> pstate drivers seem to set HW autonomous mode for all CPUs globally,
>>>> not per-CPU. So, changed it in v2.
>>>> [1] 
>>>> https://lore.kernel.org/lkml/20250211103737.447704-6-sumitg@nvidia.com/ 
>>>>
>>>>
>>> Ok right.
>>> This is something I don't really understand in the current intel/amd 
>>> cpufreq
>>> drivers. FWIU:
>>> - the cpufreq drivers abstractions allow to access different hardware
>>> - the governor abstraction allows to switch between different 
>>> algorithms
>>> to select the 'correct' frequency.
>>>
>>> So IMO switching to autonomous selection should be done by switching
>>> to another governor and the 'auto_sel' file should not be accessible 
>>> to users.

The cpufreq driver / governor abstraction still seems a bit stretched 
for the CPPC
case. Indeed, cpufreq uses:
- .setpolicy() callback and CPUFREQ_POLICY_XXX policies to allow 
external scaling
   algorithms
- .target() and .target_index() callbacks and scaling governors for 
internal scaling
   algorithms

But if CPPC allows to use both internal/external algorithms at the same 
time,
so for instance it is unknown what the 'performance' governor should be
converted to:
- using the the linux drivers/cpufreq/cpufreq_performance.c governor
- setting the energy performance preference to the maximum perf. value 
with auto_sel=0
- setting the energy performance preference to the maximum perf. value 
with auto_sel=1

------------

Right not selecting the 'performance' or 'powersave' policy gives a 
clear result
for pstate as autonomous selection is alwasy enabled IIUC. It would be nice
if we could switch between an 'autonomous_performance' and
'non_autonomous_performance' without manually toggling the auto_sel file.

Powered by blists - more mailing lists