Re: [PATCH 0/2] cpufreq: governor: Apply limits with target_freq instead of policy->cur

[Rafael J. Wysocki]

On Tue, Mar 17, 2026 at 9:26 AM zhenglifeng (A) <zhenglifeng1@xxxxxxxxxx> wrote:
>
> On 3/17/2026 2:20 PM, Viresh Kumar wrote:
> > On 13-03-26, 18:12, zhenglifeng (A) wrote:
> >> Let's forget what happens on our platform. The current discussion is no
> >> longer about applying this patchset. What I really want to discuss are two
> >> questions:
> >>
> >> 1. Is the platform allowed to adjust to frequencies out of the limits?
> >>
> >> My answer is YES. policy->min and policy->max can be modified by the user.
> >> policy->min can even be increased to be as large as policy->max. However,
> >> due to some other limitations(temperature, power, current etc.), the
> >> platform sometimes has to (secretly as you say) reduce the actual
> >> frequency, inevitably falling below the OS's frequency limits.
> >
> > It is fine if you want to do that, just that you should use OS to make that
> > change.
> > - Update freq table to contain all valid frequencies (1/4 of min in you case).
> > - Update policy->min to current min, so you don't go to those low frequencies.
> > - Use freq qos or sysfs to change min/max when you want to go really low, like
> >   1/4 of min.
> >
> >> I believe
> >> this situation will occur not only on our platform. The OS should not treat
> >> this situation as an anomaly, and leading to unpredictable behavior. The OS
> >> should have the ability to self-regulate. I believe that your patch is for
> >> this purpose.
> >
> > When the OS is kept in the dark about such a change, it needs to figure out a
> > way to get back. That's all we are trying here.
>
> I see. Then I think the point is how to let OS know when hardware change the
> frequency. It's worth thinking about.

An interrupt needs to trigger and then it depends.  On systems with
ACPI the OS will get a notification on the processor object, for
example.