[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <005501dba817$b710fe60$2532fb20$@telus.net>
Date: Mon, 7 Apr 2025 16:49:34 -0700
From: "Doug Smythies" <dsmythies@...us.net>
To: "'srinivas pandruvada'" <srinivas.pandruvada@...ux.intel.com>
Cc: "'Linux PM'" <linux-pm@...r.kernel.org>,
"'LKML'" <linux-kernel@...r.kernel.org>,
"'Viresh Kumar'" <viresh.kumar@...aro.org>,
"'Mario Limonciello'" <mario.limonciello@....com>,
"'Sudeep Holla'" <sudeep.holla@....com>,
"Doug Smythies" <dsmythies@...us.net>,
"'Rafael J. Wysocki'" <rjw@...ysocki.net>,
"'Rafael J. Wysocki'" <rafael@...nel.org>
Subject: RE: [PATCH v1 10/10] cpufreq: Pass policy pointer to ->update_limits()
On 2025.04.07 15:38 srinivas pandruvada wrote:
> On Mon, 2025-04-07 at 20:48 +0200, Rafael J. Wysocki wrote:
>> On Fri, Mar 28, 2025 at 9:49 PM Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>>>
>>> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>>
>>> Since cpufreq_update_limits() obtains a cpufreq policy pointer for
>>> the
>>> given CPU and reference counts the corresponding policy object, it
>>> may
>>> as well pass the policy pointer to the cpufreq driver's -
>>> >update_limits()
>>> callback which allows that callback to avoid invoking
>>> cpufreq_cpu_get()
>>> for the same CPU.
>>>
>>> Accordingly, redefine ->update_limits() to take a policy pointer
>>> instead
>>> of a CPU number and update both drivers implementing it,
>>> intel_pstate
>>> and amd-pstate, as needed.
>>>
>>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>>
> Hi Rafael,
>
>> Hi Srinivas,
>>
>> If you have any concerns regarding this patch, please let me know
>> (note that it is based on the [05/10]).
>>
> Changes looks fine, but wants to test out some update limits from
> interrupt path.
> Checked your branches at linux-pm, not able to locate in any branch to
> apply.
> Please point me to a branch.
Hi Srinivas,
You can get the series from patchworks [1].
Then just edit it, deleting patch 1 of 10, because that one was included in kernel 6.15-rc1
The rest will apply cleanly to kernel 6.15-rc1.
I just did all this in the last hour, because I wanted to check if the patchset fixed a years old
issue with HWP enabled, intel_cpufreq, schedutil, minimum frequency set above hardware
minimum was properly reflected in scaling_cur_freq when the frequency was stale. [2]
The issue is not fixed.
[1] https://patchwork.kernel.org/project/linux-pm/patch/2315023.iZASKD2KPV@rjwysocki.net/
[2] https://lore.kernel.org/linux-pm/CAAYoRsU2=qOUhBKSRskcoRXSgBudWgDNVvKtJA+c22cPa8EZ1Q@mail.gmail.com/
Powered by blists - more mailing lists