Re: [PATCH v4 0/2] cpufreq: CPPC: add autonomous mode boot parameter support

[Sumit Gupta <sumitg@nvidia.com>]

On 19/06/26 14:59, Pierre Gondois wrote:
> External email: Use caution opening links or attachments
>
>
> On 6/18/26 07:28, Viresh Kumar wrote:
>> On 16-06-26, 18:22, Sumit Gupta wrote:
>>> The dependency it was waiting on, the "cpufreq: Set policy->min and
>>> max as real QoS constraints" series, is now in linux-pm (linux-next).
>>> I rebased on top and verified autonomous mode works as expected, and
>>> it applies cleanly on the current linux-next.
>>>
>>> The [1] reference in patch 2/2 points to v2 of that series; the merged
>>> version is v3 [2].
>>>
>>> If there are no further comments, please consider acking and queuing
>>> this for the next cycle.
>> I was waiting for CPPC reviewers to provide some feedback.i
>>
>> Jie / Lifeng / Pierre ?
>>
> I think the patchset has the same issue described at:
>
> https://lore.kernel.org/all/86780f97-29ee-4a72-b311-38c89434b707@arm.com/
>
> I don't know if this is important to other persons,
> but IMO it would be preferable to have a solution to this issue
> before adding more functionalities relying on registers that are left
> in an unknown state.
>
> If there are any other opinion ?
>

The concern is valid, but this isn't a new gap. The registers the boot
parameter programs are already writable via existing sysfs:
  - auto_sel via auto_select
  - EPP via energy_performance_preference_val
So userspace can already leave these in a non-default state across
unload / CPU hotplug in mainline. The boot parameter just sets the
same registers at boot via the same paths.

I am already working on the save/restore change we discussed on
the ospm_nominal_perf thread, as a dedicated follow-up grouping
all OSPM-set registers (ospm_nominal_perf, auto_sel, EPP) together.
I think doing it once uniformly is cleaner.

Both features are already under review, so my preference is to take
them first and add the save/restore on top, rather than merging it
first and respinning both features under it. Either order works for me
if you and the maintainers prefer infra-first.

Thanks,
Sumit