Re: [PATCH] cpufreq: conservative: Drop cached requested_freq

[Viresh Kumar]

On 12-03-26, 17:27, Rafael J. Wysocki wrote:
> On Thu, Mar 12, 2026 at 4:59 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> >
> > On 12-03-26, 16:43, Rafael J. Wysocki wrote:
> > > But how exactly does policy->cur get out the limits?
> >
> > From the first email:
> >
> > "Later, some frequency division strategies on our platform were triggered
> > and the actual frequency become 500MHz -- 1/4 of the OS distribution
> > frequency."
> 
> Maybe it's too late into the day, but I have problems with parsing this.

:)

> IIUC, the platform drops the frequency to something small without
> giving a notice to the OS.

I think so.

> > > I guess there's some notification from the firmware or similar that
> > > causes the limits to be updated, but the only way policy->cur can
> > > change is to still fall between the new limits AFAICS.
> >
> > AFAIU, the limits (in the view of cpufreq core) doesn't change, just
> > the end hardware frequency changes without informing the cpufreq core.
> > And if someone tries to read cpuinfo_cur_freq, cpufreq core tries to
> > get everything in sync.
> 
> In that path it ends up calling cpufreq_verify_current_freq() which
> invokes the driver's ->get() callback, so I guess that's the one
> providing the "real" frequency.

Yes.

> Next, policy->cur changes via cpufreq_out_of_sync() and
> handle_update() is scheduled which ends up calling
> cpufreq_set_policy() via refresh_frequency_limits().

Right.

> Say the limits are not updated, so we end up in
> cpufreq_governor_limits(), which calls cpufreq_dbs_governor_limits()
> in this particular case.

Yes.

> Next, cpufreq_policy_apply_limits() which should squash policy->cur
> between the existing limits.  Effectively, this means that policy->cur
> will become equal to one of the limits after that.

Right, policy->min in this case (where we went below it).

> Now, IIUC the problem is that a change of the limits may not be the
> only reason why requested_freq may need to be updated and adding a
> .limits() callback to the conservative governor like in your patch
> should address that.

Yes, it hopefully takes care of all the cases where policy->cur may
not be equal to requested_freq. If it is same (or close), this change
won't harm.

-- 
viresh