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>
prev 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®