RE: [PATCH v1 10/10] cpufreq: Pass policy pointer to ->update_limits()

[Doug Smythies]

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@xxxxxxxxxxxxx> wrote:
>>> 
>>> From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
>>> 
>>> 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@xxxxxxxxx>
>> 
> 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@xxxxxxxxxxxxx/
[2] https://lore.kernel.org/linux-pm/CAAYoRsU2=qOUhBKSRskcoRXSgBudWgDNVvKtJA+c22cPa8EZ1Q@xxxxxxxxxxxxxx/