Re: [PATCH v2 2/2] cpufreq: CPPC: Dont read counters for idle CPUs

[Beata Michalska <beata.michalska@arm.com>]

On Wed, Jul 30, 2025 at 12:31:33AM -0700, Prashant Malani wrote:
> Sorry for restarting this thread, but I think the solution submitted
> solves the write path. The read path still needs addressing.
> 
> As such, given the limitations and scheduler uncertainties
> around the reads of the FFH registers, I think the patch in this
> thread is still a good optimization to include; namely, if we know
> the CPU is idle, don't bother trying to wake up that CPU just to
> calculate frequency.
> 
I am still wondering whether cpufreq core is not a better suited place for
checking whether the CPU is idle. We could potentially try on anther CPU within
the policy and if there is none, just provide the last known freq ?

@Viresh: What are your thoughts on that ?

In the meantime I'm still trying to figure out smht to mitigate the issues with
the numbers we get from counters after waking up the CPU.

---
BR
Beata
> 
> On Mon, 21 Jul 2025 at 23:02, Prashant Malani <pmalani@google.com> wrote:
> >
> > Hi Viresh and Rafael,
> >
> > Thank you for taking the time to look at this series.
> >
> > On Mon, 21 Jul 2025 at 20:27, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > >
> > > On 21-07-25, 12:40, Prashant Malani wrote:
> > > > On Mon, 21 Jul 2025 at 10:00, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > Why don't you flag the driver as CPUFREQ_NEED_UPDATE_LIMITS?
> > > > >
> > > > > That would kind of make sense given how the driver works overall, or
> > > > > am I missing anything?
> > >
> > > +1
> >
> > Thanks, I posted [1] which implements what's suggested by Rafael. PTAL
> >
> > Best regards,
> >
> > [1] https://lore.kernel.org/linux-pm/20250722055611.130574-2-pmalani@google.com/
> >
> > --
> > -Prashant
> 
> 
> 
> -- 
> -Prashant