Linux Power Management development
 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,
	saket.dumbre@intel.co, 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
Subject: Re: [PATCH v6 1/2] ACPI: CPPC: Add ospm_nominal_perf support
Date: Mon, 27 Jul 2026 22:23:48 +0100	[thread overview]
Message-ID: <d75cbdd0-4372-48b6-8445-03f2401a6784@arm.com> (raw)
In-Reply-To: <498f0051-e549-4be4-b5bf-56aba1670881@arm.com>

On 7/27/26 18:49, Christian Loehle wrote:
> On 7/27/26 15:01, Christian Loehle wrote:
>> On 7/17/26 22:53, Sumit Gupta wrote:
>>> Expose the OSPM Nominal Performance register (ACPI 6.6, Section
>>> 8.4.6.1.2.6), which conveys the desired nominal performance level
>>> at which the platform may run. Unlike the existing read-only
>>> Nominal Performance register, it is writable and lets OSPM
>>> request a lower nominal level than the platform-reported nominal.
>>> The platform classifies performance above this level as boosted
>>> and below as throttled for its power/thermal decisions.
>>>
>>> It is exposed as a per-policy cpufreq sysfs attribute in kHz, to
>>> match the cpufreq sysfs unit convention:
>>>
>>>   /sys/devices/system/cpu/cpuX/cpufreq/ospm_nominal_freq
>>>
>>> The attribute is documented in
>>> Documentation/ABI/testing/sysfs-devices-system-cpu.
>>>
>>> Writes are converted to perf via cppc_khz_to_perf(), validated
>>> against [Lowest Performance, Nominal Performance], and applied to
>>> the policy->cpu. The register is assumed shared across the
>>> policy->cpus.
>>>
>>> On read, the current register value is returned, or
>>> "<unsupported>" if the platform does not implement the register.
>>>
>>> Also add the register to the OSPM-set register save/restore
>>> table, so its value survives CPU hotplug and reverts to the
>>> firmware value on driver unload, like the other registers in
>>> the table.
>>>
>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>> ---
>>>  .../ABI/testing/sysfs-devices-system-cpu      | 26 ++++++++++
>>>  drivers/acpi/cppc_acpi.c                      | 32 +++++++++++++
>>>  drivers/cpufreq/cppc_cpufreq.c                | 47 +++++++++++++++++++
>>>  include/acpi/cppc_acpi.h                      | 10 ++++
>>>  4 files changed, 115 insertions(+)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
>>> index 82d10d556cc8..a8d592c08823 100644
>>> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
>>> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
>>> @@ -346,6 +346,32 @@ Description:	Performance Limited
>>>  
>>>  		This file is only present if the cppc-cpufreq driver is in use.
>>>  
>>> +What:		/sys/devices/system/cpu/cpuX/cpufreq/ospm_nominal_freq
>>> +Date:		May 2026
>>> +Contact:	linux-pm@vger.kernel.org
>>> +Description:	OSPM Nominal Performance (kHz)
>>> +
>>> +		OSPM uses this attribute to request a nominal performance
>>> +		level lower than the platform-reported nominal. The
>>> +		platform treats performance above this level as boost
>>> +		and below as throttle for power and thermal decisions.
>>> +
>>> +		Read returns the current value in kHz, or "<unsupported>"
>>> +		if the platform does not implement the register. Write a
>>> +		kHz value in the range [lowest_freq, nominal_freq].
>>> +
>>> +		Note that tasks may be migrated from one CPU to another
>>> +		by the scheduler's load-balancing algorithm, and if
>>> +		different OSPM Nominal Performance values are set for
>>> +		those CPUs (through different cpufreq policies), that may
>>> +		lead to undesirable outcomes. To avoid such issues it is
>>> +		better to set the same value across all policies, or to
>>> +		pin every task potentially sensitive to it to a specific
>>> +		CPU.
>>> +
>>> +		This file is only present if the cppc-cpufreq driver is
>>> +		in use.
>>> +
>>>  What:		/sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
>>>  Date:		August 2008
>>>  KernelVersion:	2.6.27
>>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
>>> index a7fec6c93178..681d4fd40c11 100644
>>> --- a/drivers/acpi/cppc_acpi.c
>>> +++ b/drivers/acpi/cppc_acpi.c
>>> @@ -1685,6 +1685,38 @@ int cppc_set_epp(int cpu, u64 epp_val)
>>>  }
>>>  EXPORT_SYMBOL_GPL(cppc_set_epp);
>>>  
>>> +/**
>>> + * cppc_set_ospm_nominal_perf() - Write OSPM Nominal Performance register.
>>> + * @cpu: CPU on which to write register.
>>> + * @ospm_nominal_perf: Value to write to the OSPM Nominal Performance register.
>>> + *
>>> + * OSPM Nominal Performance conveys the desired nominal performance level
>>> + * at which the platform may run. Per ACPI 6.6, s8.4.6.1.2.6, the value
>>> + * must lie within [Lowest Performance, Nominal Performance] and may be
>>> + * set independently of Minimum, Maximum and Desired performance. The
>>> + * caller is responsible for validating the range.
>>> + *
>>> + * Return: 0 on success or negative error code.
>>> + */
>>> +int cppc_set_ospm_nominal_perf(int cpu, u64 ospm_nominal_perf)
>>> +{
>>> +	return cppc_set_reg_val(cpu, OSPM_NOMINAL_PERF, ospm_nominal_perf);
>>> +}
>>> +EXPORT_SYMBOL_GPL(cppc_set_ospm_nominal_perf);
>>> +
>>> +/**
>>> + * cppc_get_ospm_nominal_perf() - Read OSPM Nominal Performance register.
>>> + * @cpu: CPU from which to read register.
>>> + * @ospm_nominal_perf: Pointer to store the OSPM Nominal Performance value.
>>> + *
>>> + * Return: 0 on success or negative error code.
>>> + */
>>> +int cppc_get_ospm_nominal_perf(int cpu, u64 *ospm_nominal_perf)
>>> +{
>>> +	return cppc_get_reg_val(cpu, OSPM_NOMINAL_PERF, ospm_nominal_perf);
>>> +}
>>> +EXPORT_SYMBOL_GPL(cppc_get_ospm_nominal_perf);
>>
>> It's a write-only register, we need to track everything in the driver.
>>
> 
> So just reread Pierre's comments, TBH I don't see the point of ever
> reading it, even for sysfs reads, but I don't think
> reading it for cppc_cpufreq_get_effective_nominal() would be valid
> in any case?

FWIW desired_perf was read/write up until ACPI 6.5 and only 6.6 marked
it as write-only. I don't think we should be reading it either on
platforms advertising 6.6.
I will clarify and send a patch.

  reply	other threads:[~2026-07-27 21:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17 21:53 [PATCH v6 0/2] ACPI / cpufreq: CPPC: Add ospm_nominal_perf support Sumit Gupta
2026-07-17 21:53 ` [PATCH v6 1/2] ACPI: " Sumit Gupta
2026-07-27 14:01   ` Christian Loehle
2026-07-27 17:49     ` Christian Loehle
2026-07-27 21:23       ` Christian Loehle [this message]
2026-08-04 16:12         ` Sumit Gupta
2026-07-28 13:24   ` Zhongqiu Han
2026-08-04 16:15     ` Sumit Gupta
2026-07-17 21:53 ` [PATCH v6 2/2] cpufreq: CPPC: Reflect ospm_nominal_perf in boost and limits Sumit Gupta
2026-07-27 13:27 ` [PATCH v6 0/2] ACPI / cpufreq: CPPC: Add ospm_nominal_perf support Rafael J. Wysocki (Intel)

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=d75cbdd0-4372-48b6-8445-03f2401a6784@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=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=mochs@nvidia.com \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=saket.dumbre@intel.co \
    --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