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

[Rafael J. Wysocki]

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.

>         }
>
> -       /* 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.

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?

>         /*
> -        * 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);
> --