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

[Rafael J. Wysocki]

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

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().

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

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.

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.