public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
From: Sumit Gupta <sumitg@nvidia.com>
To: Mario Limonciello <mario.limonciello@amd.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Russell Haley <yumpusamongus@gmail.com>,
	"zhenglifeng (A)" <zhenglifeng1@huawei.com>,
	pierre.gondois@arm.com, viresh.kumar@linaro.org,
	ionela.voinescu@arm.com, corbet@lwn.net, rdunlap@infradead.org,
	ray.huang@amd.com, gautham.shenoy@amd.com, perry.yuan@amd.com,
	zhanjie9@hisilicon.com, linux-pm@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-doc@vger.kernel.org,
	acpica-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-tegra@vger.kernel.org, treding@nvidia.com,
	jonathanh@nvidia.com, vsethi@nvidia.com, ksitaraman@nvidia.com,
	sanjayc@nvidia.com, nhartman@nvidia.com, bbasu@nvidia.com,
	sumitg@nvidia.com
Subject: Re: [PATCH v7 4/7] ACPI: CPPC: add APIs and sysfs interface for min/max_perf
Date: Wed, 4 Feb 2026 15:21:10 +0530	[thread overview]
Message-ID: <b8603fcb-b0ab-47da-ae90-e82f7b9bcd67@nvidia.com> (raw)
In-Reply-To: <e7570bc3-5420-4743-8a75-8602559ca235@amd.com>


On 04/02/26 01:58, Mario Limonciello wrote:
> External email: Use caution opening links or attachments
>
>
> On 2/3/26 2:24 PM, Rafael J. Wysocki wrote:
>> On Tue, Feb 3, 2026 at 3:32 PM Sumit Gupta <sumitg@nvidia.com> wrote:
>>>
>>>
>>> On 03/02/26 18:24, Rafael J. Wysocki wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> On Tue, Feb 3, 2026 at 1:45 PM Rafael J. Wysocki 
>>>> <rafael@kernel.org> wrote:
>>>>> On Tue, Feb 3, 2026 at 10:41 AM Sumit Gupta <sumitg@nvidia.com> 
>>>>> wrote:
>>>>>>>>> Hi Sumit,
>>>>>>>>>
>>>>>>>>> I am thinking that maybe it is better to call these two sysfs 
>>>>>>>>> interface
>>>>>>>>> 'min_freq' and 'max_freq' as users read and write khz instead 
>>>>>>>>> of raw
>>>>>>>>> value.
>>>>>>>> Thanks for the suggestion.
>>>>>>>> Kept min_perf/max_perf to match the CPPC register names
>>>>>>>> (MIN_PERF/MAX_PERF), making it clear to users familiar with
>>>>>>>> CPPC what's being controlled.
>>>>>>>> The kHz unit is documented in the ABI.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Sumit Gupta
>>>>>>> On my x86 machine with kernel 6.18.5, the kernel is exposing raw 
>>>>>>> values:
>>>>>>>
>>>>>>>> grep . /sys/devices/system/cpu/cpu0/acpi_cppc/*
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/feedback_ctrs:ref:342904018856568 
>>>>>>>
>>>>>>> del:437439724183386
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/guaranteed_perf:63
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf:88
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq:0
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_nonlinear_perf:36
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_perf:1
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq:3900
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_perf:62
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/reference_perf:62
>>>>>>> /sys/devices/system/cpu/cpu0/acpi_cppc/wraparound_time:18446744073709551615 
>>>>>>>
>>>>>>>
>>>>>>> It would be surprising for a nearby sysfs interface with very 
>>>>>>> similar
>>>>>>> names to use kHz instead.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Russell Haley
>>>>>> I can rename to either of the below:
>>>>>> - min/max_freq: might be confused with scaling_min/max_freq.
>>>>>> - min/max_perf_freq: keeps the CPPC register association clear.
>>>>>>
>>>>>> Rafael, Any preferences here?
>>>>> On x86 the units in CPPC are not kHz and there is no easy reliable 
>>>>> way
>>>>> to convert them to kHz.
>>>>>
>>>>> Everything under /sys/devices/system/cpu/cpu0/acpi_cppc/ needs to be
>>>>> in CPPC units, not kHz (unless, of course, kHz are CPPC units).
>>>
>>>
>>> In v1 [1], these controls were added under acpi_cppc sysfs.
>>> After discussion, they were moved under cpufreq, and [2] was merged 
>>> first.
>>> The decision to use frequency scale instead of raw perf was made
>>> for consistency with other cpufreq interfaces as per (v3 [3]).
>>>
>>> CPPC units in our case are also not in kHz. The kHz conversion uses the
>>> existing cppc_perf_to_khz()/cppc_khz_to_perf() helpers which are 
>>> already
>>> used in cppc_cpufreq attributes. So the conversion behavior is 
>>> consistent
>>> with existing cpufreq interfaces.
>>>
>>> [1]
>>> https://lore.kernel.org/lkml/076c199c-a081-4a7f-956c-f395f4d5e156@nvidia.com/ 
>>>
>>> [2]
>>> https://lore.kernel.org/all/20250507031941.2812701-1-zhenglifeng1@huawei.com/ 
>>>
>>> [3]
>>> https://lore.kernel.org/lkml/80e16de0-63e4-4ead-9577-4ebba9b1a02d@nvidia.com/ 
>>>
>>>
>>>> That said, the new attributes will show up elsewhere.
>>>>
>>>> So why do you need to add these things in the first place?
>>>
>>> Currently there's no sysfs interface to dynamically control the
>>> MIN_PERF/MAX_PERF bounds when using autonomous mode. This helps
>>> users tune power and performance at runtime.
>>
>> So what about scaling_min_freq and scaling_max_freq?
>>
>> intel_pstate uses them for an analogous purpose.
>
> FWIW same thing for amd_pstate.
>

intel_pstate and amd_pstate seem to use setpolicy() to update
scaling_min/max_freq and program MIN_PERF/MAX_PERF.
However, as discussed in v5 [1], cppc_cpufreq cannot switch to
a setpolicy based approach because:
- We need per-CPU control of auto_sel: With setpolicy, we can't
   dynamically disable auto_sel for individual CPUs and return to the
   target() (no target hook available).
   intel_pstate and amd_pstate seem to set HW autonomous mode for
   all CPUs, not per-CPU.
- We need to retain the target() callback - the CPPC spec allows
   desired_perf to be used even when autonomous selection is enabled.

[1] 
https://lore.kernel.org/lkml/66f58f43-631b-40a0-8d42-4e90cd24b757@arm.com/

Thank You,
Sumit Gupta



  reply	other threads:[~2026-02-04  9:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29 10:48 [PATCH v7 0/7] Enhanced autonomous selection and improvements Sumit Gupta
2026-01-29 10:48 ` [PATCH v7 1/7] ACPI: CPPC: Add cppc_get_perf() API to read performance controls Sumit Gupta
2026-01-29 10:48 ` [PATCH v7 2/7] ACPI: CPPC: Warn on missing mandatory DESIRED_PERF register Sumit Gupta
2026-01-29 10:48 ` [PATCH v7 3/7] ACPI: CPPC: Extend cppc_set_epp_perf() for FFH/SystemMemory Sumit Gupta
2026-01-29 10:48 ` [PATCH v7 4/7] ACPI: CPPC: add APIs and sysfs interface for min/max_perf Sumit Gupta
2026-01-31  4:06   ` zhenglifeng (A)
2026-01-31 13:58     ` Sumit Gupta
2026-02-03  1:36       ` Russell Haley
2026-02-03  9:41         ` Sumit Gupta
2026-02-03 12:45           ` Rafael J. Wysocki
2026-02-03 12:54             ` Rafael J. Wysocki
2026-02-03 14:31               ` Sumit Gupta
2026-02-03 20:24                 ` Rafael J. Wysocki
2026-02-03 20:28                   ` Mario Limonciello
2026-02-04  9:51                     ` Sumit Gupta [this message]
2026-02-04 13:02                       ` Rafael J. Wysocki
2026-02-05 19:21                         ` Sumit Gupta
2026-02-05 19:27                           ` Rafael J. Wysocki
2026-02-03 12:43   ` Rafael J. Wysocki
2026-02-03 12:50     ` Rafael J. Wysocki
2026-02-05 13:10     ` Artem Bityutskiy
2026-01-29 10:48 ` [PATCH v7 5/7] ACPI: CPPC: add APIs and sysfs interface for perf_limited Sumit Gupta
2026-01-29 10:48 ` [PATCH v7 6/7] cpufreq: CPPC: Add sysfs for min/max_perf and perf_limited Sumit Gupta
2026-01-29 10:48 ` [PATCH v7 7/7] cpufreq: CPPC: Update cached perf_ctrls on sysfs write Sumit Gupta
2026-01-30  8:23 ` [PATCH v7 0/7] Enhanced autonomous selection and improvements Pierre Gondois
2026-01-31  2:58 ` zhenglifeng (A)

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=b8603fcb-b0ab-47da-ae90-e82f7b9bcd67@nvidia.com \
    --to=sumitg@nvidia.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=bbasu@nvidia.com \
    --cc=corbet@lwn.net \
    --cc=gautham.shenoy@amd.com \
    --cc=ionela.voinescu@arm.com \
    --cc=jonathanh@nvidia.com \
    --cc=ksitaraman@nvidia.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@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=nhartman@nvidia.com \
    --cc=perry.yuan@amd.com \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=rdunlap@infradead.org \
    --cc=sanjayc@nvidia.com \
    --cc=treding@nvidia.com \
    --cc=viresh.kumar@linaro.org \
    --cc=vsethi@nvidia.com \
    --cc=yumpusamongus@gmail.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