public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Sumit Gupta <sumitg@nvidia.com>
To: Pierre Gondois <pierre.gondois@arm.com>
Cc: linux-kernel@vger.kernel.org, acpica-devel@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-pm@vger.kernel.org, zhanjie9@hisilicon.com,
	ionela.voinescu@arm.com, perry.yuan@amd.com,
	mario.limonciello@amd.com, ray.huang@amd.com,
	zhenglifeng1@huawei.com, corbet@lwn.net, robert.moore@intel.com,
	lenb@kernel.org, viresh.kumar@linaro.org, rafael@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,
	rdunlap@infradead.org, gautham.shenoy@amd.com, sumitg@nvidia.com
Subject: Re: [PATCH v4 7/8] cpufreq: CPPC: update policy min/max when toggling auto_select
Date: Fri, 28 Nov 2025 19:38:27 +0530	[thread overview]
Message-ID: <ff17a1d4-1bdb-4ea1-8c11-b8f49a73d22c@nvidia.com> (raw)
In-Reply-To: <4e80be28-df9c-4c73-a8fd-a28cf3f8f3ad@arm.com>


On 27/11/25 20:23, Pierre Gondois wrote:
> External email: Use caution opening links or attachments
>
>
> On 11/5/25 12:38, Sumit Gupta wrote:
>> When CPPC autonomous selection (auto_select) is enabled or disabled,
>> the policy min/max frequency limits should be updated appropriately to
>> reflect the new operating mode.
>>
>> Currently, toggling auto_select only changes the hardware register but
>> doesn't update the cpufreq policy constraints, which can lead to
>> inconsistent behavior between the hardware state and the policy limits
>> visible to userspace and other kernel components.
>>
>> When auto_select is enabled, preserve the current min/max performance
>> values to maintain user-configured limits. When disabled, the hardware
>> operates in a default mode where the OS directly controls performance,
>> so update the policy limits accordingly.
>>
>> Signed-off-by: Sumit Gupta<sumitg@nvidia.com>
>> ---
>>   drivers/cpufreq/cppc_cpufreq.c | 67 ++++++++++++++++++++++++++++++++--
>>   1 file changed, 64 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cppc_cpufreq.c 
>> b/drivers/cpufreq/cppc_cpufreq.c
>> index a425ad575aa6..d1b44beaddda 100644
>> --- a/drivers/cpufreq/cppc_cpufreq.c
>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> @@ -646,6 +646,26 @@ static int cppc_cpufreq_set_mperf_limit(struct 
>> cpufreq_policy *policy, u64 val,
>>   #define cppc_cpufreq_set_max_perf(policy, val, update_reg, 
>> update_policy) \
>>       cppc_cpufreq_set_mperf_limit(policy, val, update_reg, 
>> update_policy, false)
>>
>> +static int cppc_cpufreq_update_autosel_val(struct cpufreq_policy 
>> *policy, bool auto_sel)
>> +{
>> +     struct cppc_cpudata *cpu_data = policy->driver_data;
>> +     unsigned int cpu = policy->cpu;
>> +     int ret;
>> +
>> +     pr_debug("cpu%d, auto_selcurr:%u,new:%d\n", cpu, 
>> cpu_data->perf_caps.auto_sel, auto_sel);
>> +
>> + guard(mutex)(&cppc_cpufreq_update_autosel_config_lock);
> Would it be possible to explain why we need this mutex specifically for
> auto_sel ?

Used lock to protect writes to auto_sel related registers (min_perf,
max_perf, epp, auto_sel) of a CPU from concurrent update by multiple
CPUs. Re-looked it and it seems better to take lock at parent function
and make sure all register writes happen together. That will prevent
concurrent sysfs operations from different CPUs from interleaving.


>> +
>> +     ret = cppc_set_auto_sel(cpu, auto_sel);
>> +     if (ret) {
>> +             pr_warn("Failed to set auto_sel=%d for CPU%d (%d)\n", 
>> auto_sel, cpu, ret);
>> +             return ret;
>> +     }
>> +     cpu_data->perf_caps.auto_sel = auto_sel;
>> +
>> +     return 0;
>> +}
>> +
>>   static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
>>   {
>>       unsigned int cpu = policy->cpu;
>> @@ -879,8 +899,49 @@ static ssize_t show_auto_select(struct 
>> cpufreq_policy *policy, char *buf)
>>       return sysfs_emit(buf, "%d\n", val);
>>   }
>>
>> -static ssize_t store_auto_select(struct cpufreq_policy *policy,
>> -                              const char *buf, size_t count)
>> +/**
>> + * cppc_cpufreq_update_auto_select - Update autonomous selection 
>> config for policy->cpu
>> + * @policy: cpufreq policy
>> + * @enable: enable/disable autonomous selection
>> + */
>> +static int cppc_cpufreq_update_auto_select(struct cpufreq_policy 
>> *policy, bool enable)
>> +{
>> +     struct cppc_cpudata *cpu_data = policy->driver_data;
>> +     struct cppc_perf_caps *caps = &cpu_data->perf_caps;
>> +     u64 min_perf = caps->lowest_nonlinear_perf;
>> +     u64 max_perf = caps->nominal_perf;
>> +     int ret;
>> +
>> +     if (enable) {
>> +             if (cpu_data->perf_ctrls.min_perf)
>> +                     min_perf = cpu_data->perf_ctrls.min_perf;
>> +             if (cpu_data->perf_ctrls.max_perf)
>> +                     max_perf = cpu_data->perf_ctrls.max_perf;
>> +     }
>
> I think the min/max performance values are still relevant when 
> auto_sel is
> disabled/absent. So:
> - enabling/disabling autonomous selection
> - setting min/max perf values
> should not have any dependency I think.
>

When enable auto_sel, update both the min/max_perf registers and policy
limits with respective values.
When disable, update only policy limits with the default mode values
and not update the min/max_perf registers. These register values last set
by user are kept and used to update policy limits when auto_sel is enabled
next time.

Thank you,
Sumit Gupta


>
>> +
>> +     /*
>> +      * Set min/max performance registers and update policy 
>> constraints.
>> +      *   When enabling: update both registers and policy.
>> +      *   When disabling: update policy only.
>> +      * Continue even if min/max are not supported, as EPP and autosel
>> +      * might still be supported.
>> +      */
>> +     ret = cppc_cpufreq_set_min_perf(policy, min_perf, enable, true);
>> +     if (ret && ret != -EOPNOTSUPP)
>> +             return ret;
>> +
>> +     ret = cppc_cpufreq_set_max_perf(policy, max_perf, enable, true);
>> +     if (ret && ret != -EOPNOTSUPP)
>> +             return ret;
>> +
>> +     ret = cppc_cpufreq_update_autosel_val(policy, enable);
>> +     if (ret)
>> +             return ret;
>> +
>> +     return 0;
>> +}
>> +
>> +static ssize_t store_auto_select(struct cpufreq_policy *policy, 
>> const char *buf, size_t count)
>>   {
>>       bool val;
>>       int ret;
>> @@ -889,7 +950,7 @@ static ssize_t store_auto_select(struct 
>> cpufreq_policy *policy,
>>       if (ret)
>>               return ret;
>>
>> -     ret = cppc_set_auto_sel(policy->cpu, val);
>> +     ret = cppc_cpufreq_update_auto_select(policy, val);
>>       if (ret)
>>               return ret;
>>

  reply	other threads:[~2025-11-28 14:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-05 11:38 [PATCH v4 0/8] Enhanced autonomous selection and improvements Sumit Gupta
2025-11-05 11:38 ` [PATCH v4 1/8] cpufreq: CPPC: Add generic helpers for sysfs show/store Sumit Gupta
2025-11-10 10:56   ` Viresh Kumar
2025-11-11 11:20     ` Sumit Gupta
2025-11-05 11:38 ` [PATCH v4 2/8] ACPI: CPPC: Add cppc_get_perf() API to read performance controls Sumit Gupta
2025-11-27 14:53   ` Pierre Gondois
2025-11-28 14:01     ` Sumit Gupta
2025-11-28 15:05       ` Pierre Gondois
2025-11-05 11:38 ` [PATCH v4 3/8] ACPI: CPPC: extend APIs to support auto_sel and epp Sumit Gupta
2025-11-12 15:02   ` Ionela Voinescu
2025-11-18  9:17     ` Sumit Gupta
2025-11-27 14:54   ` Pierre Gondois
2025-12-09 18:10     ` Sumit Gupta
2025-11-05 11:38 ` [PATCH v4 4/8] ACPI: CPPC: add APIs and sysfs interface for min/max_perf Sumit Gupta
2025-11-06 10:30   ` kernel test robot
2025-11-07 10:00     ` Sumit Gupta
2025-11-07 20:08       ` Rafael J. Wysocki
2025-11-11 11:06         ` Sumit Gupta
2025-11-13 10:56   ` Ionela Voinescu
2025-11-18  9:34     ` Sumit Gupta
2025-11-27 14:54   ` Pierre Gondois
2025-12-09 16:38     ` Sumit Gupta
2025-11-05 11:38 ` [PATCH v4 5/8] ACPI: CPPC: add APIs and sysfs interface for perf_limited register Sumit Gupta
2025-11-13 11:35   ` Ionela Voinescu
2025-11-18 10:20     ` Sumit Gupta
2025-11-27 14:54   ` Pierre Gondois
2025-12-09 17:22     ` Sumit Gupta
2025-11-05 11:38 ` [PATCH v4 6/8] cpufreq: CPPC: Add sysfs for min/max_perf and perf_limited Sumit Gupta
2025-11-13 12:41   ` Ionela Voinescu
2025-11-18 10:46     ` Sumit Gupta
2025-11-05 11:38 ` [PATCH v4 7/8] cpufreq: CPPC: update policy min/max when toggling auto_select Sumit Gupta
2025-11-27 14:53   ` Pierre Gondois
2025-11-28 14:08     ` Sumit Gupta [this message]
2025-11-05 11:38 ` [PATCH v4 8/8] cpufreq: CPPC: add autonomous mode boot parameter support Sumit Gupta
2025-11-13 15:15   ` Ionela Voinescu
2025-11-26 13:32     ` Sumit Gupta
2025-11-27 14:53   ` Pierre Gondois
2025-11-28 14:29     ` Sumit Gupta
2025-11-28 15:05       ` Pierre Gondois
2025-12-01 14:09         ` Sumit Gupta
2025-11-10 11:00 ` [PATCH v4 0/8] Enhanced autonomous selection and improvements Viresh Kumar
2025-11-18  8:45 ` Jie Zhan

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=ff17a1d4-1bdb-4ea1-8c11-b8f49a73d22c@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=lenb@kernel.org \
    --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=robert.moore@intel.com \
    --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