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

[srinivas pandruvada]

On Mon, 2025-04-07 at 16:49 -0700, Doug Smythies wrote:
> 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.
> 
Hi Doug,

You are correct. But I prefer a branch usually as there may be other
fixes so that I can verify once.

Thanks,
Srinivas

> 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/
> 
> 
>