From: Sumit Gupta <sumitg@nvidia.com>
To: Christian Loehle <christian.loehle@arm.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,
saket.dumbre@intel.co, ray.huang@amd.com,
mario.limonciello@amd.com, perry.yuan@amd.com,
kprateek.nayak@amd.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org,
acpica-devel@lists.linux.dev, linux-tegra@vger.kernel.org
Cc: treding@nvidia.com, jonathanh@nvidia.com, vsethi@nvidia.com,
ksitaraman@nvidia.com, sanjayc@nvidia.com, mochs@nvidia.com,
bbasu@nvidia.com, sumitg@nvidia.com
Subject: Re: [PATCH v3 4/4] cpufreq: CPPC: Preserve OSPM-set registers across suspend/resume
Date: Tue, 4 Aug 2026 21:37:09 +0530 [thread overview]
Message-ID: <d0869a24-55c3-41bf-af04-dadb6a86c666@nvidia.com> (raw)
In-Reply-To: <443cae7f-bd01-4022-9703-7a1e6ae883bb@arm.com>
On 27/07/26 19:15, Christian Loehle wrote:
> External email: Use caution opening links or attachments
>
>
> On 7/24/26 22:59, Sumit Gupta wrote:
>> The previous patch preserves the OSPM-set registers across CPU hotplug,
>> but system suspend/resume is a separate path. On platforms that reset
>> those registers or the performance controls across suspend, the values
>> are lost.
>>
>> Reuse the same save/restore mechanism for suspend/resume:
>>
>> - suspend() only saves the current OSPM-set values. It does not revert
>> them to firmware, since a later offline() already does that when
>> system suspend offlines the secondary CPUs.
>> - resume() needs the same steps as online(), so .resume points at
>> online() directly.
>>
>> Suggested-by: Christian Loehle <christian.loehle@arm.com>
>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>> ---
>> drivers/cpufreq/cppc_cpufreq.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>> index 8a13ec49eb9d..be2d873ccd84 100644
>> --- a/drivers/cpufreq/cppc_cpufreq.c
>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> @@ -921,6 +921,22 @@ static int cppc_cpufreq_cpu_online(struct cpufreq_policy *policy)
>> return 0;
>> }
>>
>> +/*
>> + * suspend() only saves the OSPM-set values. It does not revert them to the
>> + * firmware values.
>> + *
>> + * This is because system suspend may later offline the secondary CPUs.
>> + * That runs offline(), which saves the values and then reverts to firmware.
>> + * If suspend() had already reverted, offline() would save the firmware value
>> + * instead of the user's request, and the request would be lost.
>> + */
>> +static int cppc_cpufreq_cpu_suspend(struct cpufreq_policy *policy)
>> +{
>> + cppc_cpufreq_save_requested_regs(policy);
>> +
>> + return 0;
>> +}
>> +
> Wouldn't it be safer to commit everything here and not rely on the later
> offline() to still need a fully usable CPPC platform (in particular for
> PCC), as at this stage all but 2 CPUs might already be offline()d?
> Also either the later offline() saves registers successfully, and overwrites
> this snapshot, or it fails and overwrites them with U64, right?
>
Agreed.
I will save the requested values and restore the firmware values in
suspend(), while the CPPC is still fully usable.
offline() will skip these steps when suspend() has already performed them.
Thanks,
Sumit
>> static void cppc_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>> {
>> struct cppc_cpudata *cpu_data = policy->driver_data;
>> @@ -1235,6 +1251,8 @@ static struct cpufreq_driver cppc_cpufreq_driver = {
>> .exit = cppc_cpufreq_cpu_exit,
>> .online = cppc_cpufreq_cpu_online,
>> .offline = cppc_cpufreq_cpu_offline,
>> + .suspend = cppc_cpufreq_cpu_suspend,
>> + .resume = cppc_cpufreq_cpu_online,
>> .set_boost = cppc_cpufreq_set_boost,
>> .attr = cppc_cpufreq_attr,
>> .name = "cppc_cpufreq",
prev parent reply other threads:[~2026-08-04 16:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 21:59 [PATCH v3 0/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload Sumit Gupta
2026-07-24 21:59 ` [PATCH v3 1/4] cpufreq: CPPC: Keep the policy across CPU hotplug Sumit Gupta
2026-07-27 13:27 ` Christian Loehle
2026-07-29 14:41 ` Sumit Gupta
2026-07-28 8:41 ` zhenglifeng (A)
2026-07-29 17:05 ` Sumit Gupta
2026-07-24 21:59 ` [PATCH v3 2/4] ACPI: CPPC: Make autonomous selection helpers take a u64 Sumit Gupta
2026-07-24 21:59 ` [PATCH v3 3/4] cpufreq: CPPC: Preserve OSPM-set registers across hotplug and unload Sumit Gupta
2026-07-27 13:15 ` Christian Loehle
2026-07-29 19:10 ` Sumit Gupta
2026-07-24 21:59 ` [PATCH v3 4/4] cpufreq: CPPC: Preserve OSPM-set registers across suspend/resume Sumit Gupta
2026-07-27 13:45 ` Christian Loehle
2026-08-04 16:07 ` Sumit Gupta [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=d0869a24-55c3-41bf-af04-dadb6a86c666@nvidia.com \
--to=sumitg@nvidia.com \
--cc=acpica-devel@lists.linux.dev \
--cc=bbasu@nvidia.com \
--cc=christian.loehle@arm.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=mario.limonciello@amd.com \
--cc=mochs@nvidia.com \
--cc=perry.yuan@amd.com \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=ray.huang@amd.com \
--cc=saket.dumbre@intel.co \
--cc=sanjayc@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