Re: [PATCH] cpufreq: cppc: discard out-of-range delivered_perf samples

[Jie Zhan <zhanjie9@hisilicon.com>]

On 5/2/2026 12:32 AM, Breno Leitao wrote:
> cppc_cpufreq_get_rate() derives delivered_perf as:
> 
>     delivered_perf = reference_perf * delta_delivered / delta_reference
> 
> over a short udelay()-bounded window between two cppc_get_perf_ctrs()
> calls. Per-read latency jitter on the underlying CPC register access
> can skew the ratio, occasionally producing delivered_perf >
> highest_perf. cppc_perf_to_khz() then linearly extrapolates above
> (nominal_perf, nominal_freq), so the value reported via
> /sys/.../cpufreq/cpuinfo_cur_freq exceeds cpuinfo_max_freq.
> 
> Observed on an arm64 host (governor=performance,
> cpuinfo_max_freq=3339 MHz): 15 back-to-back reads returned values
> between 2997 and 4230 MHz.
Hi Breno,

Frequency sampling discrepancy through 'cpuinfo_cur_freq' in the
cppc_cpufreq driver has been an issue discussed for a very long time.

If the CPPC feedback counters are FFH on your platform, can you have a look
at [1] and see if that helps?

Thanks,
Jie
> 
> Treat an out-of-range sample as invalid and reuse the existing
> out_invalid_counters fallback, which returns the platform's
> desired_perf. This keeps cpuinfo_cur_freq within
> [0, cpuinfo_max_freq] without reporting a value the hardware did
> not deliver.
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
>  drivers/cpufreq/cppc_cpufreq.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
...