[PATCH v4 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload

Sumit Gupta posted 4 patches 1 month, 3 weeks ago
There is a newer version of this series
drivers/acpi/cppc_acpi.c       |  20 +-
drivers/cpufreq/amd-pstate.c   |   2 +-
drivers/cpufreq/cppc_cpufreq.c | 369 ++++++++++++++++++++++++++++++++-
include/acpi/cppc_acpi.h       |   8 +-
4 files changed, 376 insertions(+), 23 deletions(-)
[PATCH v4 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
Posted by Sumit Gupta 1 month, 3 weeks ago
This series keeps the CPPC cpufreq policy alive across CPU hotplug and
preserves the OSPM-set CPPC registers (Energy Performance Preference,
Autonomous Activity Window, Autonomous Selection - set via sysfs).

Without online()/offline() callbacks, the core tears a policy down when
its last CPU goes offline and rebuilds it on the way back, re-reading the
CPPC capabilities each time. The values written to these registers can
be lost:

 - Across CPU hotplug or suspend/resume: the platform may reset them
   while the CPU is offline.
 - On driver unload: the driver-written value is left in the register
   instead of returning to its pre-driver state.

Handle these with:

 - Patch 1: adds online()/offline() callbacks so the core keeps policy
   alive across CPU hotplug instead of tearing it down and rebuilding it.
 - Patch 2: makes the autonomous selection register helpers take a u64.
 - Patch 3: adds a table-driven mechanism that captures each register's
   firmware value at init(), restores it from offline(), and reapplies
   the OSPM-set value from online().
 - Patch 4: extends the same save/restore to system suspend/resume.

v3[3] -> v4:
 - Patch 1:
   - offline() parks the perf request at lowest_perf, as exit() did.
   - online() resyncs the frequency invariance counters.
   - raise MAX before the perf restore when the saved MIN is above it.
 - Patch 3:
   - write auto_sel first when enabling it and last when disabling it.
   - replace the four save/restore helpers into save_regs() and
     apply_saved_regs(), each taking the firmware or requested type.
   - keep the per-policy saved values in one struct, and name each
     register for the pr_debug diagnostics.
 - Patch 4:
   - suspend() also restores the firmware values and flags it, so
     offline() skips them and resume() only handles still-online policies.

Sumit Gupta (4):
  cpufreq: CPPC: Keep the policy across CPU hotplug
  ACPI: CPPC: Make autonomous selection helpers take a u64
  cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
  cpufreq: CPPC: Preserve OSPM-set registers across suspend/resume

 drivers/acpi/cppc_acpi.c       |  20 +-
 drivers/cpufreq/amd-pstate.c   |   2 +-
 drivers/cpufreq/cppc_cpufreq.c | 369 ++++++++++++++++++++++++++++++++-
 include/acpi/cppc_acpi.h       |   8 +-
 4 files changed, 376 insertions(+), 23 deletions(-)

[1] v1: https://lore.kernel.org/lkml/20260623095403.3407436-1-sumitg@nvidia.com/
[2] v2: https://lore.kernel.org/lkml/20260716153820.2007095-1-sumitg@nvidia.com/
[3] v3: https://lore.kernel.org/lkml/20260724215937.3368276-1-sumitg@nvidia.com/

-- 
2.34.1
Re: [PATCH v4 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
Posted by Sumit Gupta 1 month ago
On 07/08/26 01:38, Sumit Gupta wrote:
> This series keeps the CPPC cpufreq policy alive across CPU hotplug and
> preserves the OSPM-set CPPC registers (Energy Performance Preference,
> Autonomous Activity Window, Autonomous Selection - set via sysfs).
>
> Without online()/offline() callbacks, the core tears a policy down when
> its last CPU goes offline and rebuilds it on the way back, re-reading the
> CPPC capabilities each time. The values written to these registers can
> be lost:
>
>   - Across CPU hotplug or suspend/resume: the platform may reset them
>     while the CPU is offline.
>   - On driver unload: the driver-written value is left in the register
>     instead of returning to its pre-driver state.
>
> Handle these with:
>
>   - Patch 1: adds online()/offline() callbacks so the core keeps policy
>     alive across CPU hotplug instead of tearing it down and rebuilding it.
>   - Patch 2: makes the autonomous selection register helpers take a u64.
>   - Patch 3: adds a table-driven mechanism that captures each register's
>     firmware value at init(), restores it from offline(), and reapplies
>     the OSPM-set value from online().
>   - Patch 4: extends the same save/restore to system suspend/resume.

Gentle reminder.
Could this be considered for queuing if nothing further needs addressing.

Thanks,
Sumit


> v3[3] -> v4:
>   - Patch 1:
>     - offline() parks the perf request at lowest_perf, as exit() did.
>     - online() resyncs the frequency invariance counters.
>     - raise MAX before the perf restore when the saved MIN is above it.
>   - Patch 3:
>     - write auto_sel first when enabling it and last when disabling it.
>     - replace the four save/restore helpers into save_regs() and
>       apply_saved_regs(), each taking the firmware or requested type.
>     - keep the per-policy saved values in one struct, and name each
>       register for the pr_debug diagnostics.
>   - Patch 4:
>     - suspend() also restores the firmware values and flags it, so
>       offline() skips them and resume() only handles still-online policies.
>
> Sumit Gupta (4):
>    cpufreq: CPPC: Keep the policy across CPU hotplug
>    ACPI: CPPC: Make autonomous selection helpers take a u64
>    cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
>    cpufreq: CPPC: Preserve OSPM-set registers across suspend/resume
>
>   drivers/acpi/cppc_acpi.c       |  20 +-
>   drivers/cpufreq/amd-pstate.c   |   2 +-
>   drivers/cpufreq/cppc_cpufreq.c | 369 ++++++++++++++++++++++++++++++++-
>   include/acpi/cppc_acpi.h       |   8 +-
>   4 files changed, 376 insertions(+), 23 deletions(-)
>
> [1] v1: https://lore.kernel.org/lkml/20260623095403.3407436-1-sumitg@nvidia.com/
> [2] v2: https://lore.kernel.org/lkml/20260716153820.2007095-1-sumitg@nvidia.com/
> [3] v3: https://lore.kernel.org/lkml/20260724215937.3368276-1-sumitg@nvidia.com/
>
Re: [PATCH v4 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
Posted by Christian Loehle 1 month ago
On 8/25/26 22:20, Sumit Gupta wrote:
> 
> On 07/08/26 01:38, Sumit Gupta wrote:
>> This series keeps the CPPC cpufreq policy alive across CPU hotplug and
>> preserves the OSPM-set CPPC registers (Energy Performance Preference,
>> Autonomous Activity Window, Autonomous Selection - set via sysfs).
>>
>> Without online()/offline() callbacks, the core tears a policy down when
>> its last CPU goes offline and rebuilds it on the way back, re-reading the
>> CPPC capabilities each time. The values written to these registers can
>> be lost:
>>
>>   - Across CPU hotplug or suspend/resume: the platform may reset them
>>     while the CPU is offline.
>>   - On driver unload: the driver-written value is left in the register
>>     instead of returning to its pre-driver state.
>>
>> Handle these with:
>>
>>   - Patch 1: adds online()/offline() callbacks so the core keeps policy
>>     alive across CPU hotplug instead of tearing it down and rebuilding it.
>>   - Patch 2: makes the autonomous selection register helpers take a u64.
>>   - Patch 3: adds a table-driven mechanism that captures each register's
>>     firmware value at init(), restores it from offline(), and reapplies
>>     the OSPM-set value from online().
>>   - Patch 4: extends the same save/restore to system suspend/resume.
> 
> Gentle reminder.
> Could this be considered for queuing if nothing further needs addressing.

FWIW both sashiko findings look legit to me, the feedback counters one I
wouldn't consider that drastic, given that these counters are expected to
have 'fuzzy' readings anyhow, the second one is worse (losing sysfs settings
on cpu_online())

Re: [PATCH v4 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
Posted by Rafael J. Wysocki (Intel) 1 month ago
On Wed, Aug 26, 2026 at 11:07 AM Christian Loehle
<christian.loehle@arm.com> wrote:
>
> On 8/25/26 22:20, Sumit Gupta wrote:
> >
> > On 07/08/26 01:38, Sumit Gupta wrote:
> >> This series keeps the CPPC cpufreq policy alive across CPU hotplug and
> >> preserves the OSPM-set CPPC registers (Energy Performance Preference,
> >> Autonomous Activity Window, Autonomous Selection - set via sysfs).
> >>
> >> Without online()/offline() callbacks, the core tears a policy down when
> >> its last CPU goes offline and rebuilds it on the way back, re-reading the
> >> CPPC capabilities each time. The values written to these registers can
> >> be lost:
> >>
> >>   - Across CPU hotplug or suspend/resume: the platform may reset them
> >>     while the CPU is offline.
> >>   - On driver unload: the driver-written value is left in the register
> >>     instead of returning to its pre-driver state.
> >>
> >> Handle these with:
> >>
> >>   - Patch 1: adds online()/offline() callbacks so the core keeps policy
> >>     alive across CPU hotplug instead of tearing it down and rebuilding it.
> >>   - Patch 2: makes the autonomous selection register helpers take a u64.
> >>   - Patch 3: adds a table-driven mechanism that captures each register's
> >>     firmware value at init(), restores it from offline(), and reapplies
> >>     the OSPM-set value from online().
> >>   - Patch 4: extends the same save/restore to system suspend/resume.
> >
> > Gentle reminder.
> > Could this be considered for queuing if nothing further needs addressing.
>
> FWIW both sashiko findings look legit to me, the feedback counters one I
> wouldn't consider that drastic, given that these counters are expected to
> have 'fuzzy' readings anyhow, the second one is worse (losing sysfs settings
> on cpu_online())

I agree.

Besides, as I said elsewhere, I want this series to go in before any
other pending changes related to CPPC:

https://lore.kernel.org/linux-acpi/20260826063019.670240-1-christian.loehle@arm.com/

and I really would like to get some tags on it before it goes in.  It
clearly is not ready for 7.3, but it may be applicable early for 7.4
if people care to respond to it.

Thanks!
Re: [PATCH v4 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
Posted by Sumit Gupta 1 month ago
On 26/08/26 15:57, Rafael J. Wysocki (Intel) wrote:
> External email: Use caution opening links or attachments
>
>
> On Wed, Aug 26, 2026 at 11:07 AM Christian Loehle
> <christian.loehle@arm.com> wrote:
>> On 8/25/26 22:20, Sumit Gupta wrote:
>>> On 07/08/26 01:38, Sumit Gupta wrote:
>>>> This series keeps the CPPC cpufreq policy alive across CPU hotplug and
>>>> preserves the OSPM-set CPPC registers (Energy Performance Preference,
>>>> Autonomous Activity Window, Autonomous Selection - set via sysfs).
>>>>
>>>> Without online()/offline() callbacks, the core tears a policy down when
>>>> its last CPU goes offline and rebuilds it on the way back, re-reading the
>>>> CPPC capabilities each time. The values written to these registers can
>>>> be lost:
>>>>
>>>>    - Across CPU hotplug or suspend/resume: the platform may reset them
>>>>      while the CPU is offline.
>>>>    - On driver unload: the driver-written value is left in the register
>>>>      instead of returning to its pre-driver state.
>>>>
>>>> Handle these with:
>>>>
>>>>    - Patch 1: adds online()/offline() callbacks so the core keeps policy
>>>>      alive across CPU hotplug instead of tearing it down and rebuilding it.
>>>>    - Patch 2: makes the autonomous selection register helpers take a u64.
>>>>    - Patch 3: adds a table-driven mechanism that captures each register's
>>>>      firmware value at init(), restores it from offline(), and reapplies
>>>>      the OSPM-set value from online().
>>>>    - Patch 4: extends the same save/restore to system suspend/resume.
>>> Gentle reminder.
>>> Could this be considered for queuing if nothing further needs addressing.
>> FWIW both sashiko findings look legit to me, the feedback counters one I
>> wouldn't consider that drastic, given that these counters are expected to
>> have 'fuzzy' readings anyhow, the second one is worse (losing sysfs settings
>> on cpu_online())
> I agree.
>
> Besides, as I said elsewhere, I want this series to go in before any
> other pending changes related to CPPC:
>
> https://lore.kernel.org/linux-acpi/20260826063019.670240-1-christian.loehle@arm.com/
>
> and I really would like to get some tags on it before it goes in.  It
> clearly is not ready for 7.3, but it may be applicable early for 7.4
> if people care to respond to it.
>
> Thanks!

Thanks for pointing this out.

I did not receive a Sashiko review email for this series, so I was
unaware of the findings. I have found the web review now. I will go
through both findings and address them in v5.

Thanks,
Sumit