Re: [PATCH] cpufreq: intel_pstate: Fix Raptor Lake-E cpufreq limits

[srinivas pandruvada]

On Tue, 2026-05-12 at 12:20 +0200, Rafael J. Wysocki wrote:
> On Tue, May 12, 2026 at 1:53 AM Srinivas Pandruvada
> <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote:
> > 
> > Raptor Lake-E processors are not correctly showing cpufreq
> > frequency
> > limits.
> > 
> > These CPUs don't set X86_FEATURE_HYBRID_CPU and have no E-cores,
> > but
> > P-cores still use hybrid scaling factor.
> > 
> > commit 0fcfc9e51990 ("cpufreq: intel_pstate: Fix scaling for
> > hybrid-capable systems with disabled E-cores") added support for
> > such configuration. Here using CPPC nominal freq and perf was
> > compared
> > to still return hybrid scaling factor.
> > 
> > Commit 9b18d536b124 ("cpufreq: intel_pstate: Use CPPC to get
> > scaling
> > factors") restructured hwp_get_cpu_scaling() and added an explicit
> > check
> > for X86_FEATURE_HYBRID_CPU and when not set returns core scaling
> > factor.
> > 
> > To address this remove check for X86_FEATURE_HYBRID_CPU and call
> > intel_pstate_cppc_get_scaling().
> > 
> > Ideally this change should be enough. But using CPPC for scaling
> > factor
> > results in rounding error, so still doesn't restore the original
> > behavior.
> > 
> > In intel_pstate_cppc_get_scaling() return core scaling factor when
> > ACPI CPPC is not present or when CPPC nominal frequency or nominal
> > performance are invalid.
> > 
> > Use hybrid_scaling_factor for P-cores when defined for a CPU, if
> > not
> > calculate from ACPI CPPC nominal frequency and performance.
> > 
> > Fixes: 9b18d536b124 ("cpufreq: intel_pstate: Use CPPC to get
> > scaling factors")
> > Reported-by: Henry Tseng <henrytseng@xxxxxxxx>
> > Closes:
> > https://lore.kernel.org/linux-pm/20260508063032.3248602-1-henrytseng@xxxxxxxx/
> > Signed-off-by: Srinivas Pandruvada
> > <srinivas.pandruvada@xxxxxxxxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx
> > ---
> >  drivers/cpufreq/intel_pstate.c | 29 +++++++++++++++--------------
> >  1 file changed, 15 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/intel_pstate.c
> > b/drivers/cpufreq/intel_pstate.c
> > index 1292da53e5fc..0379efdee5f8 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -421,15 +421,23 @@ static int intel_pstate_cppc_get_scaling(int
> > cpu)
> >  {
> >         struct cppc_perf_caps cppc_perf;
> > 
> > +       if (cppc_get_perf_caps(cpu, &cppc_perf) ||
> > !cppc_perf.nominal_freq ||
> > +           !cppc_perf.nominal_perf)
> > +               goto core_scaling;
> > +
> > +       if (cppc_perf.nominal_perf * 100 == cppc_perf.nominal_freq)
> > +               goto core_scaling;
> > +
> > +       if (hybrid_scaling_factor)
> > +               return hybrid_scaling_factor;
> > +
> >         /*
> > -        * Compute the perf-to-frequency scaling factor for the
> > given CPU if
> > -        * possible, unless it would be 0.
> > +        * Compute the perf-to-frequency scaling factor for the
> > given CPU
> > +        * from nominal freq and nominal_perf
> >          */
> > -       if (!cppc_get_perf_caps(cpu, &cppc_perf) &&
> > -           cppc_perf.nominal_perf && cppc_perf.nominal_freq)
> > -               return div_u64(cppc_perf.nominal_freq *
> > KHZ_PER_MHZ,
> > -                              cppc_perf.nominal_perf);
> > +       return div_u64(cppc_perf.nominal_freq * KHZ_PER_MHZ,
> > cppc_perf.nominal_perf);
> > 
> > +core_scaling:
> >         return core_get_scaling();
> >  }
> > 
> > @@ -2281,17 +2289,10 @@ static int hwp_get_cpu_scaling(int cpu)
> >                  */
> >                 if (hybrid_get_cpu_type(cpu) ==
> > INTEL_CPU_TYPE_CORE)
> >                         return hybrid_scaling_factor;
> > -
> > -               return core_get_scaling();
> 
> Why is this change necessary or even useful?
> 
> This is about E-cores (because P-cores have been covered above) and
> if
> hybrid_scaling_factor is set, it is known that the processor is
> hybrid
> and E-cores have the "core" scaling factor.
> 
> Or is Raptor Lake-E covered by one of the
> intel_hybrid_scaling_factor[] entries and hybrid_get_cpu_type(cpu)
> doesn't return INTEL_CPU_TYPE_CORE on it?  This piece of information
> is missing from the changelog.

Raptor Lake-E (Xeon) uses CPU model as Raptor Lake-S, for which there
is already a hardcoded scaling factor in the driver. So this "if" block
will enter. But since there is no hybrid CPUID feature is defined,
hybrid_get_cpu_type(cpu) will return 0 for P-core or E-core. Here there
are no E-cores. So need to remove core_get_scaling() as this will
return non hybrid factor.



> 
> >         }
> > 
> > -       /* Use core scaling on non-hybrid systems. */
> > -       if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU))
> > -               return core_get_scaling();
> > -
> 
> So we're now exposing all of the non-hybrid processors to the fun
> with
> possibly incorrectly populated CPPC, which is kind of risky.
> 

This was already used before with
commit0fcfc9e51990246a9813475716746ff5eb98c6aa
relying that all non hybrid processor (including servers) didn't set
nominal frequency, so will return core_scaling without using CPPC.
I retested change on servers and non hybrids.

> If Raptor Lake-E is not covered by an existing
> intel_hybrid_scaling_factor[] entry, why don't we add one for it with
> a "scaling factor" value indicating that CPPC needs to be used for
> computing it on all CPUs?

It is already covered by existing, but we can only call 
for intel_pstate_cppc_get_scaling() when hybrid_scaling_factor is
defined. This will require a hardcoding for Bartlett Lake also which
uses different CPU model, which Henry Tseng is planing to send.

Thanks,
Srinivas


> 
> >         /*
> > -        * The system is hybrid, but the hybrid scaling factor is
> > not known or
> > -        * the CPU type is not one of the above, so use CPPC to
> > compute the
> > +        * The system is hybrid, so use CPPC to compute the
> >          * scaling factor for this CPU.
> >          */
> >         return intel_pstate_cppc_get_scaling(cpu);
> > --