[PATCH 0/2] cpufreq: CPPC: Avoid cur frequency modification on governor start

[PATCH 0/2] cpufreq: CPPC: Avoid cur frequency modification on governor start

[Prashant Malani]

This is a short series that handles an issue where, on CPPC-based systems,
the cpu frequency was getting unintentionally set to the wrong value on
governor start ( and overriding the existing policy frequency) because of
unreliable AMU/CPPC counters.

This adds a governor flag that avoids the check against the CPPC AMU-based
frequency when the governor starts. It then modifies the CPPC CPU freq
driver to opt in to using this flag.

Prashant Malani (2):
  cpufreq: Add driver flag to avoid initial frequency verification
  cpufreq: CPPC: Don't verify cur frequency on governor start

 drivers/cpufreq/cppc_cpufreq.c |  3 ++-
 drivers/cpufreq/cpufreq.c      |  3 ++-
 include/linux/cpufreq.h        | 10 ++++++++++
 3 files changed, 14 insertions(+), 2 deletions(-)

-- 
2.51.0.rc2.233.g662b1ed5c5-goog

[PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification

[Prashant Malani]

Some cpufreq drivers have a get() function which can return an unreliable
frequency. This can cause issues when switching governors. For instance,
a CPU would be on performance governor and have it's frequency (and
policy->cur) set to max. When the governor is switched to userspace, the
policy->cur is re-used, but it is checked against the frequency returned
by the driver's get() function. If it's different, the frequency will
get set to the new (incorrect) value.

To avoid this, add a flag that avoids this verify step on governor start
if the cpufreq driver opts in to it.

Since there are no users of this flag, no functional changes are
introduced here.

Cc: Beata Michalska <beata.michalska@arm.com>
Signed-off-by: Prashant Malani <pmalani@google.com>
---
 drivers/cpufreq/cpufreq.c |  3 ++-
 include/linux/cpufreq.h   | 10 ++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b8937737d096..72e6552a40ea 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy)
 
 	pr_debug("%s: for CPU %u\n", __func__, policy->cpu);
 
-	cpufreq_verify_current_freq(policy, false);
+	if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START))
+		cpufreq_verify_current_freq(policy, false);
 
 	if (policy->governor->start) {
 		ret = policy->governor->start(policy);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 95f3807c8c55..1ebc12fcc905 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -474,6 +474,16 @@ struct cpufreq_driver {
  */
 #define CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING	BIT(6)
 
+/*
+ * Set by drivers which want cpufreq core to avoid verifying that the current
+ * frequency of the policy matches the frequency returned by the driver's get()
+ * function. The get() function on certain drivers returns unreliable values,
+ * and this can result in the frequency (and consequently system performance)
+ * being reduced even though the governor didn't want the frequencies to be
+ * reduced.
+ */
+#define CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START	BIT(7)
+
 int cpufreq_register_driver(struct cpufreq_driver *driver_data);
 void cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
 
-- 
2.51.0.rc2.233.g662b1ed5c5-goog

[PATCH 2/2] cpufreq: CPPC: Don't verify cur frequency on governor start

[Prashant Malani]

Opt in to not verifying the policy's current frequency when the governor
starts. CPPC's get() function is known to return unreliable values,
so checking against that can mean the frequency gets set to the
unreliable value even though the governor (and user) didn't intend to do
so. That in turn causes unexpected performance drops.

Cc: Beata Michalska <beata.michalska@arm.com>
Signed-off-by: Prashant Malani <pmalani@google.com>
---
 drivers/cpufreq/cppc_cpufreq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 4a17162a392d..7fd6c03bb726 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -910,7 +910,8 @@ static struct freq_attr *cppc_cpufreq_attr[] = {
 };
 
 static struct cpufreq_driver cppc_cpufreq_driver = {
-	.flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS,
+	.flags = CPUFREQ_CONST_LOOPS | CPUFREQ_NEED_UPDATE_LIMITS |
+		 CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START,
 	.verify = cppc_verify_policy,
 	.target = cppc_cpufreq_set_target,
 	.get = cppc_cpufreq_get_rate,
-- 
2.51.0.rc2.233.g662b1ed5c5-goog

Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification

[Viresh Kumar]

On 23-08-25, 00:17, Prashant Malani wrote:
> Some cpufreq drivers have a get() function which can return an unreliable
> frequency. This can cause issues when switching governors. For instance,
> a CPU would be on performance governor and have it's frequency (and
> policy->cur) set to max. When the governor is switched to userspace, the
> policy->cur is re-used, but it is checked against the frequency returned
> by the driver's get() function. If it's different, the frequency will
> get set to the new (incorrect) value.
> 
> To avoid this, add a flag that avoids this verify step on governor start
> if the cpufreq driver opts in to it.
> 
> Since there are no users of this flag, no functional changes are
> introduced here.
> 
> Cc: Beata Michalska <beata.michalska@arm.com>
> Signed-off-by: Prashant Malani <pmalani@google.com>
> ---
>  drivers/cpufreq/cpufreq.c |  3 ++-
>  include/linux/cpufreq.h   | 10 ++++++++++
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index b8937737d096..72e6552a40ea 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy)
>  
>  	pr_debug("%s: for CPU %u\n", __func__, policy->cpu);
>  
> -	cpufreq_verify_current_freq(policy, false);
> +	if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START))
> +		cpufreq_verify_current_freq(policy, false);

I don't think it is okay to do this to hide a driver's failure to
return the right frequency. What about all the other places where
get() is still used ? Won't that cause similar issues elsewhere ?

The driver must be fixed for this, not the core. The core is doing the
right thing here, asking the driver to return the current frequency.
If the driver is unsure, it can just return the current frequency from
policy->cur instead.

-- 
viresh

Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification

[Beata Michalska]

On Mon, Aug 25, 2025 at 10:26:41AM +0530, Viresh Kumar wrote:
> On 23-08-25, 00:17, Prashant Malani wrote:
> > Some cpufreq drivers have a get() function which can return an unreliable
> > frequency. This can cause issues when switching governors. For instance,
> > a CPU would be on performance governor and have it's frequency (and
> > policy->cur) set to max. When the governor is switched to userspace, the
> > policy->cur is re-used, but it is checked against the frequency returned
> > by the driver's get() function. If it's different, the frequency will
> > get set to the new (incorrect) value.
> > 
> > To avoid this, add a flag that avoids this verify step on governor start
> > if the cpufreq driver opts in to it.
> > 
> > Since there are no users of this flag, no functional changes are
> > introduced here.
> > 
> > Cc: Beata Michalska <beata.michalska@arm.com>
> > Signed-off-by: Prashant Malani <pmalani@google.com>
> > ---
> >  drivers/cpufreq/cpufreq.c |  3 ++-
> >  include/linux/cpufreq.h   | 10 ++++++++++
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index b8937737d096..72e6552a40ea 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy)
> >  
> >  	pr_debug("%s: for CPU %u\n", __func__, policy->cpu);
> >  
> > -	cpufreq_verify_current_freq(policy, false);
> > +	if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START))
> > +		cpufreq_verify_current_freq(policy, false);
> 
> I don't think it is okay to do this to hide a driver's failure to
> return the right frequency. What about all the other places where
> get() is still used ? Won't that cause similar issues elsewhere ?
> 
> The driver must be fixed for this, not the core. The core is doing the
Agreed.

---
BR
Beata
> right thing here, asking the driver to return the current frequency.
> If the driver is unsure, it can just return the current frequency from
> policy->cur instead.
> 
> -- 
> viresh