mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Loehle <christian.loehle@arm.com>
To: Sumit Gupta <sumitg@nvidia.com>,
	rafael@kernel.org, viresh.kumar@linaro.org,
	pierre.gondois@arm.com, ionela.voinescu@arm.com,
	zhenglifeng1@huawei.com, zhanjie9@hisilicon.com, lenb@kernel.org,
	ray.huang@amd.com, mario.limonciello@amd.com, perry.yuan@amd.com,
	kprateek.nayak@amd.com, maciej.wieczor-retman@intel.com,
	pawel.chmielewski@intel.com, linux-pm@vger.kernel.org,
	linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev,
	linux-kernel@vger.kernel.org
Cc: linux-tegra@vger.kernel.org, treding@nvidia.com,
	jonathanh@nvidia.com, vsethi@nvidia.com, ksitaraman@nvidia.com,
	sanjayc@nvidia.com, mochs@nvidia.com, bbasu@nvidia.com
Subject: Re: [PATCH v7 0/5] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload
Date: Tue, 3 Nov 2026 14:11:18 +0000	[thread overview]
Message-ID: <f326f2c5-9012-41bf-a8da-b2fd9698b9fa@arm.com> (raw)
In-Reply-To: <20261030092416.1993889-1-sumitg@nvidia.com>

On 10/30/26 09:24, Sumit Gupta wrote:
> This series preserves the OSPM-set CPPC registers (Energy Performance
> Preference, Autonomous Activity Window, Autonomous Selection - set via
> sysfs) across CPU hotplug and suspend/resume. On driver unload, it puts
> back the values they had before the driver loaded.
> 
> To do this, it keeps the CPPC cpufreq policy alive across CPU hotplug.
> It also orders the performance-control writes in cppc_set_perf(), so
> that restoring them after a platform reset never sends an invalid
> request.
> 
> 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 or suspended.
>  - 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: orders the Desired, MIN and MAX writes in cppc_set_perf(), so
>    that the platform never sees an invalid request. Christian proposed
>    it in [7], and this version adds fixes found in testing.
>  - Patch 2: adds online()/offline() callbacks so the core keeps policy
>    alive across CPU hotplug instead of tearing it down and rebuilding it.
>  - Patch 3: makes the autonomous selection register helpers take a u64.
>  - Patch 4: saves each register's firmware value at init() and each
>    successful sysfs write as the requested value. offline() restores the
>    firmware values, and online() reapplies the requested values.
>  - Patch 5: extends the same restore and reapply to system
>    suspend/resume.
> 
> v6[6] -> v7:
>  - Patch 1:
>    - clamp Desired into MIN and MAX instead of rejecting it. (Sashiko)
>    - store_auto_select() updates its cache only on success. (Sashiko)
>  - Patch 2:
>    - exit() only frees the driver data. (Sashiko)
>    - online() continues if enabling CPPC fails, as init() does.
>  - Patch 4:
>    - save the requested value on each successful sysfs write, instead
>      of reading it in offline(). (Christian, Rafael [8])
>    - init() fails if a firmware value cannot be read. (Christian)
>    - split the auto_act_window store from perf_limited.
>  - Patch 5:
>    - suspend() no longer reads and saves the registers.
> 
> Christian Loehle (1):
>   ACPI: CPPC: Order performance-control updates
> 
> 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       | 318 +++++++++++++++-----
>  drivers/cpufreq/amd-pstate.c   |   2 +-
>  drivers/cpufreq/cppc_cpufreq.c | 530 ++++++++++++++++++++++++++++++---
>  include/acpi/cppc_acpi.h       |   9 +-
>  4 files changed, 729 insertions(+), 130 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/
> [4] v4: https://lore.kernel.org/lkml/20260806200857.601152-1-sumitg@nvidia.com/
> [5] v5: https://lore.kernel.org/lkml/20260916103820.1760297-1-sumitg@nvidia.com/
> [6] v6: https://lore.kernel.org/lkml/20261020121846.691218-1-sumitg@nvidia.com/
> [7] https://lore.kernel.org/lkml/1be30b2b-e1e5-41ed-a0dc-0dd5ad3c47cd@arm.com/
> [8] https://lore.kernel.org/linux-pm/CAJZ5v0iXip_5Ywk3EkrGL_u2w_hOcGKA1XvrubLPb3diWHx5Lw@mail.gmail.com/
> 

My testing setup is far from perfect, but let's hope good enough:
Tested on Orion O6, AmpereOne and Blackview Ryzen 5 7430U (for ACPI-CPPC only):
- native and emulated CPPC hotplug, both auto-select modes
- S3 on Blackview and s2idle on AmpereOne
- amd-pstate active/passive/guided on Blackview.
Didn't observe any violations in restore order with both native register and
fake support (which silently drops requests before the register write).
Tested-by: Christian Loehle <christian.loehle@arm.com>

      parent reply	other threads:[~2026-11-03 14:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30  9:24 Sumit Gupta
2026-10-30  9:24 ` [PATCH v7 2/5] cpufreq: CPPC: Keep the policy across CPU hotplug Sumit Gupta
2026-11-03 11:50   ` Christian Loehle
2026-10-30  9:24 ` [PATCH v7 3/5] ACPI: CPPC: Make autonomous selection helpers take a u64 Sumit Gupta
2026-10-30  9:24 ` [PATCH v7 4/5] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload Sumit Gupta
2026-10-30  9:24 ` [PATCH v7 5/5] cpufreq: CPPC: Preserve OSPM-set registers across suspend/resume Sumit Gupta
2026-10-30  9:33 ` [PATCH v7 1/5] ACPI: CPPC: Order performance-control updates Sumit Gupta
2026-11-03 14:11 ` Christian Loehle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f326f2c5-9012-41bf-a8da-b2fd9698b9fa@arm.com \
    --to=christian.loehle@arm.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=bbasu@nvidia.com \
    --cc=ionela.voinescu@arm.com \
    --cc=jonathanh@nvidia.com \
    --cc=kprateek.nayak@amd.com \
    --cc=ksitaraman@nvidia.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=mario.limonciello@amd.com \
    --cc=mochs@nvidia.com \
    --cc=pawel.chmielewski@intel.com \
    --cc=perry.yuan@amd.com \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=sanjayc@nvidia.com \
    --cc=sumitg@nvidia.com \
    --cc=treding@nvidia.com \
    --cc=viresh.kumar@linaro.org \
    --cc=vsethi@nvidia.com \
    --cc=zhanjie9@hisilicon.com \
    --cc=zhenglifeng1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®