* [PATCH] cpufreq: intel_pstate: Use CPPC to get scaling factor for Bartlett Lake @ 2026-05-06 9:51 Henry Tseng 2026-05-06 12:15 ` srinivas pandruvada 0 siblings, 1 reply; 5+ messages in thread From: Henry Tseng @ 2026-05-06 9:51 UTC (permalink / raw) To: Rafael J. Wysocki, Srinivas Pandruvada, Len Brown, Viresh Kumar Cc: linux-pm, SW Chen, Kevin Ko, Henry Tseng Previously, hwp_get_cpu_scaling() returned INTEL_PSTATE_CORE_SCALING (100000) as the scaling factor for non-hybrid CPUs. However, this value is too large for Bartlett Lake processors, where HWP performance levels do not map 1:1 to PERF_CTL P-state ratios. Per the Intel datasheet [1], the Intel Core 9 273PE specifies: Performance-cores: 12 Efficient-cores: 0 Max Turbo Frequency: 5.7 GHz Intel Thermal Velocity Boost Frequency: 5.7 GHz Intel Turbo Boost Max Technology 3.0 Frequency: 5.6 GHz Performance-core Max Turbo Frequency: 5.4 GHz Performance-core Base Frequency: 2.3 GHz Because this CPU has no E-cores and does not report X86_FEATURE_HYBRID_CPU, hwp_get_cpu_scaling() returns 100000. In intel_pstate_get_cpu_pstates(), the condition cpu->pstate.scaling == perf_ctl_scaling then takes the early path that simply multiplies HWP performance levels by 100000, producing cpuinfo_max_freq values that exceed the documented maximum turbo frequency: intel_pstate: CPU0: PERF_CTL turbo = 57 intel_pstate: CPU0: HWP_CAP guaranteed = 30 intel_pstate: CPU0: HWP_CAP highest = 70 intel_pstate: CPU0: HWP-to-frequency scaling factor: 100000 intel_pstate: set_policy cpuinfo.max 7000000 policy->max 7000000 ... intel_pstate: CPU12: HWP_CAP highest = 73 intel_pstate: CPU12: HWP-to-frequency scaling factor: 100000 intel_pstate: set_policy cpuinfo.max 7300000 policy->max 7300000 To avoid impacting traditional non-hybrid CPUs, introduce a new intel_cppc_scaling_ids[] table that lists non-hybrid CPU models requiring dynamic scaling factor computation via CPPC. CPUs in this list call intel_pstate_cppc_get_scaling() instead of core_get_scaling(). Because the scaling factor is now obtained from CPPC, intel_pstate_hybrid_hwp_adjust() no longer takes the early return on these CPUs. To prevent hwp_is_hybrid from being set incorrectly on non-hybrid systems (which would enable asymmetric capacity scaling and disable ITMT), guard the assignment with X86_FEATURE_HYBRID_CPU. Since intel_pstate_hybrid_hwp_adjust() now also handles non-hybrid processors, rename it to intel_pstate_hwp_adjust() and update the kerneldoc and inline comments accordingly. After this patch (Intel Core 9 273PE): intel_pstate: CPU0: PERF_CTL turbo = 57 intel_pstate: CPU0: HWP_CAP guaranteed = 30 intel_pstate: CPU0: HWP_CAP highest = 70 intel_pstate: CPU0: HWP-to-frequency scaling factor: 79310 intel_pstate: set_policy cpuinfo.max 5500000 policy->max 5500000 ... intel_pstate: CPU12: HWP_CAP highest = 73 intel_pstate: CPU12: HWP-to-frequency scaling factor: 79310 intel_pstate: set_policy cpuinfo.max 5700000 policy->max 5700000 The scaling factor 79310 is computed from CPPC nominal_freq=2300 MHz and nominal_perf=29. The resulting sysfs values are: $ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_max_freq 5500000 (20 CPUs with HWP_CAP highest = 70) 5700000 ( 4 CPUs with HWP_CAP highest = 73) $ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq 5500000 5700000 The reported maximum turbo frequency now matches the datasheet's Max Turbo Frequency of 5.7 GHz. [1] https://www.intel.com/content/www/us/en/products/sku/245717/intel-core-9-processor-273pe-36m-cache-up-to-5-70-ghz/specifications.html Signed-off-by: Henry Tseng <henrytseng@qnap.com> --- drivers/cpufreq/intel_pstate.c | 37 +++++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 1292da53e5fc..4d3dbea19eb7 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -557,17 +557,17 @@ static int intel_pstate_freq_to_hwp(struct cpudata *cpu, int freq) } /** - * intel_pstate_hybrid_hwp_adjust - Calibrate HWP performance levels. + * intel_pstate_hwp_adjust - Calibrate HWP performance levels. * @cpu: Target CPU. * - * On hybrid processors, HWP may expose more performance levels than there are + * On some processors, HWP may expose more performance levels than there are * P-states accessible through the PERF_CTL interface. If that happens, the * scaling factor between HWP performance levels and CPU frequency will be less * than the scaling factor between P-state values and CPU frequency. * * In that case, adjust the CPU parameters used in computations accordingly. */ -static void intel_pstate_hybrid_hwp_adjust(struct cpudata *cpu) +static void intel_pstate_hwp_adjust(struct cpudata *cpu) { int perf_ctl_max_phys = cpu->pstate.max_pstate_physical; int perf_ctl_scaling = cpu->pstate.perf_ctl_scaling; @@ -585,7 +585,8 @@ static void intel_pstate_hybrid_hwp_adjust(struct cpudata *cpu) if (scaling == perf_ctl_scaling) return; - hwp_is_hybrid = true; + if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) + hwp_is_hybrid = true; cpu->pstate.turbo_freq = rounddown(cpu->pstate.turbo_pstate * scaling, perf_ctl_scaling); @@ -1815,6 +1816,7 @@ static const struct attribute_group intel_pstate_attr_group = { }; static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[]; +static const struct x86_cpu_id intel_cppc_scaling_ids[]; static struct kobject *intel_pstate_kobject; @@ -2285,15 +2287,16 @@ static int hwp_get_cpu_scaling(int cpu) return core_get_scaling(); } - /* Use core scaling on non-hybrid systems. */ - if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) - return core_get_scaling(); - /* - * 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 - * scaling factor for this CPU. + * Use core scaling on non-hybrid systems, except for those whose + * perf-to-frequency scaling factor differs from the default + * (e.g. Bartlett Lake) and must be computed via CPPC. */ + if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU) && + !x86_match_cpu(intel_cppc_scaling_ids)) + return core_get_scaling(); + + /* Compute the scaling factor via CPPC. */ return intel_pstate_cppc_get_scaling(cpu); } @@ -2328,7 +2331,7 @@ static void intel_pstate_get_cpu_pstates(struct cpudata *cpu) if (pstate_funcs.get_cpu_scaling) { cpu->pstate.scaling = pstate_funcs.get_cpu_scaling(cpu->cpu); - intel_pstate_hybrid_hwp_adjust(cpu); + intel_pstate_hwp_adjust(cpu); } else { cpu->pstate.scaling = perf_ctl_scaling; } @@ -3739,6 +3742,16 @@ static const struct x86_cpu_id intel_hybrid_scaling_factor[] = { {} }; +/* + * Non-hybrid CPUs whose perf-to-frequency scaling factor differs from + * INTEL_PSTATE_CORE_SCALING. For these, compute the scaling factor + * dynamically via CPPC. + */ +static const struct x86_cpu_id intel_cppc_scaling_ids[] = { + X86_MATCH_VFM(INTEL_BARTLETTLAKE, NULL), + {} +}; + static bool hwp_check_epp(void) { if (boot_cpu_has(X86_FEATURE_HWP_EPP)) -- 2.43.0 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] cpufreq: intel_pstate: Use CPPC to get scaling factor for Bartlett Lake 2026-05-06 9:51 [PATCH] cpufreq: intel_pstate: Use CPPC to get scaling factor for Bartlett Lake Henry Tseng @ 2026-05-06 12:15 ` srinivas pandruvada 2026-05-07 9:25 ` Henry Tseng 0 siblings, 1 reply; 5+ messages in thread From: srinivas pandruvada @ 2026-05-06 12:15 UTC (permalink / raw) To: Henry Tseng, Rafael J. Wysocki, Len Brown, Viresh Kumar Cc: linux-pm, SW Chen, Kevin Ko On Wed, 2026-05-06 at 17:51 +0800, Henry Tseng wrote: > Previously, hwp_get_cpu_scaling() returned INTEL_PSTATE_CORE_SCALING > (100000) as the scaling factor for non-hybrid CPUs. However, this > value is too large for Bartlett Lake processors, where HWP > performance levels do not map 1:1 to PERF_CTL P-state ratios. > > Per the Intel datasheet [1], the Intel Core 9 273PE specifies: > > Performance-cores: 12 > Efficient-cores: 0 > Max Turbo Frequency: 5.7 GHz > Intel Thermal Velocity Boost Frequency: 5.7 GHz > Intel Turbo Boost Max Technology 3.0 Frequency: 5.6 GHz > Performance-core Max Turbo Frequency: 5.4 GHz > Performance-core Base Frequency: 2.3 GHz > > Because this CPU has no E-cores and does not report > X86_FEATURE_HYBRID_CPU, hwp_get_cpu_scaling() returns 100000. In > intel_pstate_get_cpu_pstates(), the condition > cpu->pstate.scaling == perf_ctl_scaling then takes the early path > that simply multiplies HWP performance levels by 100000, producing > cpuinfo_max_freq values that exceed the documented maximum turbo > frequency: > > intel_pstate: CPU0: PERF_CTL turbo = 57 > intel_pstate: CPU0: HWP_CAP guaranteed = 30 > intel_pstate: CPU0: HWP_CAP highest = 70 > intel_pstate: CPU0: HWP-to-frequency scaling factor: 100000 > intel_pstate: set_policy cpuinfo.max 7000000 policy->max 7000000 > ... > intel_pstate: CPU12: HWP_CAP highest = 73 > intel_pstate: CPU12: HWP-to-frequency scaling factor: 100000 > intel_pstate: set_policy cpuinfo.max 7300000 policy->max 7300000 > > To avoid impacting traditional non-hybrid CPUs, introduce a new > intel_cppc_scaling_ids[] table that lists non-hybrid CPU models > requiring dynamic scaling factor computation via CPPC. CPUs in > this list call intel_pstate_cppc_get_scaling() instead of > core_get_scaling(). > > Because the scaling factor is now obtained from CPPC, > intel_pstate_hybrid_hwp_adjust() no longer takes the early return > on these CPUs. To prevent hwp_is_hybrid from being set incorrectly > on non-hybrid systems (which would enable asymmetric capacity > scaling and disable ITMT), guard the assignment with > X86_FEATURE_HYBRID_CPU. > > Since intel_pstate_hybrid_hwp_adjust() now also handles non-hybrid > processors, rename it to intel_pstate_hwp_adjust() and update the > kerneldoc and inline comments accordingly. > > After this patch (Intel Core 9 273PE): > > intel_pstate: CPU0: PERF_CTL turbo = 57 > intel_pstate: CPU0: HWP_CAP guaranteed = 30 > intel_pstate: CPU0: HWP_CAP highest = 70 > intel_pstate: CPU0: HWP-to-frequency scaling factor: 79310 > intel_pstate: set_policy cpuinfo.max 5500000 policy->max 5500000 > ... > intel_pstate: CPU12: HWP_CAP highest = 73 > intel_pstate: CPU12: HWP-to-frequency scaling factor: 79310 > intel_pstate: set_policy cpuinfo.max 5700000 policy->max 5700000 > > The scaling factor 79310 is computed from CPPC > nominal_freq=2300 MHz and nominal_perf=29. > This is a special embedded processor, so to reduce enabling effort by in BIOS, why not just add diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index ec4abe374573..763598ca13cd 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -3732,6 +3732,7 @@ static const struct x86_cpu_id intel_hybrid_scaling_factor[] = { X86_MATCH_VFM(INTEL_RAPTORLAKE, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_RAPTORLAKE_P, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_RAPTORLAKE_S, HYBRID_SCALING_FACTOR_ADL), + X86_MATCH_VFM(INTEL_BARTLETTLAKE, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_METEORLAKE_L, HYBRID_SCALING_FACTOR_MTL), X86_MATCH_VFM(INTEL_LUNARLAKE_M, HYBRID_SCALING_FACTOR_LNL), {} CPPC scaling introduces rounding issues for some frequency. This will avoid introducing another CPU model list. Thanks, Srinivas > The resulting sysfs values are: > > $ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_max_freq > 5500000 (20 CPUs with HWP_CAP highest = 70) > 5700000 ( 4 CPUs with HWP_CAP highest = 73) > $ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq > 5500000 > 5700000 > > The reported maximum turbo frequency now matches the datasheet's > Max Turbo Frequency of 5.7 GHz. > > [1] > https://www.intel.com/content/www/us/en/products/sku/245717/intel-core-9-processor-273pe-36m-cache-up-to-5-70-ghz/specifications.html > > Signed-off-by: Henry Tseng <henrytseng@qnap.com> > --- > drivers/cpufreq/intel_pstate.c | 37 +++++++++++++++++++++++--------- > -- > 1 file changed, 25 insertions(+), 12 deletions(-) > > diff --git a/drivers/cpufreq/intel_pstate.c > b/drivers/cpufreq/intel_pstate.c > index 1292da53e5fc..4d3dbea19eb7 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -557,17 +557,17 @@ static int intel_pstate_freq_to_hwp(struct > cpudata *cpu, int freq) > } > > /** > - * intel_pstate_hybrid_hwp_adjust - Calibrate HWP performance > levels. > + * intel_pstate_hwp_adjust - Calibrate HWP performance levels. > * @cpu: Target CPU. > * > - * On hybrid processors, HWP may expose more performance levels than > there are > + * On some processors, HWP may expose more performance levels than > there are > * P-states accessible through the PERF_CTL interface. If that > happens, the > * scaling factor between HWP performance levels and CPU frequency > will be less > * than the scaling factor between P-state values and CPU frequency. > * > * In that case, adjust the CPU parameters used in computations > accordingly. > */ > -static void intel_pstate_hybrid_hwp_adjust(struct cpudata *cpu) > +static void intel_pstate_hwp_adjust(struct cpudata *cpu) > { > int perf_ctl_max_phys = cpu->pstate.max_pstate_physical; > int perf_ctl_scaling = cpu->pstate.perf_ctl_scaling; > @@ -585,7 +585,8 @@ static void intel_pstate_hybrid_hwp_adjust(struct > cpudata *cpu) > if (scaling == perf_ctl_scaling) > return; > > - hwp_is_hybrid = true; > + if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) > + hwp_is_hybrid = true; > > cpu->pstate.turbo_freq = rounddown(cpu->pstate.turbo_pstate > * scaling, > perf_ctl_scaling); > @@ -1815,6 +1816,7 @@ static const struct attribute_group > intel_pstate_attr_group = { > }; > > static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[]; > +static const struct x86_cpu_id intel_cppc_scaling_ids[]; > > static struct kobject *intel_pstate_kobject; > > @@ -2285,15 +2287,16 @@ static int hwp_get_cpu_scaling(int cpu) > return core_get_scaling(); > } > > - /* Use core scaling on non-hybrid systems. */ > - if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) > - return core_get_scaling(); > - > /* > - * 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 > - * scaling factor for this CPU. > + * Use core scaling on non-hybrid systems, except for those > whose > + * perf-to-frequency scaling factor differs from the default > + * (e.g. Bartlett Lake) and must be computed via CPPC. > */ > + if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU) && > + !x86_match_cpu(intel_cppc_scaling_ids)) > + return core_get_scaling(); > + > + /* Compute the scaling factor via CPPC. */ > return intel_pstate_cppc_get_scaling(cpu); > } > > @@ -2328,7 +2331,7 @@ static void intel_pstate_get_cpu_pstates(struct > cpudata *cpu) > > if (pstate_funcs.get_cpu_scaling) { > cpu->pstate.scaling = > pstate_funcs.get_cpu_scaling(cpu->cpu); > - intel_pstate_hybrid_hwp_adjust(cpu); > + intel_pstate_hwp_adjust(cpu); > } else { > cpu->pstate.scaling = perf_ctl_scaling; > } > @@ -3739,6 +3742,16 @@ static const struct x86_cpu_id > intel_hybrid_scaling_factor[] = { > {} > }; > > +/* > + * Non-hybrid CPUs whose perf-to-frequency scaling factor differs > from > + * INTEL_PSTATE_CORE_SCALING. For these, compute the scaling factor > + * dynamically via CPPC. > + */ > +static const struct x86_cpu_id intel_cppc_scaling_ids[] = { > + X86_MATCH_VFM(INTEL_BARTLETTLAKE, NULL), > + {} > +}; > + > static bool hwp_check_epp(void) > { > if (boot_cpu_has(X86_FEATURE_HWP_EPP)) ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] cpufreq: intel_pstate: Use CPPC to get scaling factor for Bartlett Lake 2026-05-06 12:15 ` srinivas pandruvada @ 2026-05-07 9:25 ` Henry Tseng 2026-05-07 14:47 ` srinivas pandruvada 0 siblings, 1 reply; 5+ messages in thread From: Henry Tseng @ 2026-05-07 9:25 UTC (permalink / raw) To: Srinivas Pandruvada, Rafael J. Wysocki, Len Brown, Viresh Kumar Cc: linux-pm, SW Chen, Kevin Ko, Henry Tseng On Wed, 06 May 2026 05:15:49 -0700, Srinivas Pandruvada wrote: > This is a special embedded processor, so to reduce enabling effort by > in BIOS, why not just add > > diff --git a/drivers/cpufreq/intel_pstate.c > b/drivers/cpufreq/intel_pstate.c > index ec4abe374573..763598ca13cd 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -3732,6 +3732,7 @@ static const struct x86_cpu_id > intel_hybrid_scaling_factor[] = { > X86_MATCH_VFM(INTEL_RAPTORLAKE, HYBRID_SCALING_FACTOR_ADL), > X86_MATCH_VFM(INTEL_RAPTORLAKE_P, HYBRID_SCALING_FACTOR_ADL), > X86_MATCH_VFM(INTEL_RAPTORLAKE_S, HYBRID_SCALING_FACTOR_ADL), > + X86_MATCH_VFM(INTEL_BARTLETTLAKE, HYBRID_SCALING_FACTOR_ADL), > X86_MATCH_VFM(INTEL_METEORLAKE_L, HYBRID_SCALING_FACTOR_MTL), > X86_MATCH_VFM(INTEL_LUNARLAKE_M, HYBRID_SCALING_FACTOR_LNL), > {} > > CPPC scaling introduces rounding issues for some frequency. This will > avoid introducing another CPU model list. Thanks for the review, the static table is definitely simpler. I had referenced commit 9b18d536b124 and went with CPPC, but I take your point about the rounding issues. After adding INTEL_BARTLETTLAKE to intel_hybrid_scaling_factor[], I noticed hwp_get_cpu_scaling() still falls back to core_get_scaling() on 273PE, because hybrid_get_cpu_type() returns 0 (not INTEL_CPU_TYPE_CORE) on a non-hybrid CPU, so the table value doesn't get picked up. I added a check for X86_FEATURE_HYBRID_CPU there to let non-hybrid CPUs in the table use hybrid_scaling_factor. I also kept hwp_is_hybrid = 0 on 273PE to match the current mainline behavior on non-hybrid CPUs. Draft below, based on v7.1-rc2 (7fd2df204f34), tested on Intel Core 9 273PE: diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 1292da53e5fc..b66455252745 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -585,7 +585,7 @@ static void intel_pstate_hybrid_hwp_adjust(struct cpudata *cpu) if (scaling == perf_ctl_scaling) return; - hwp_is_hybrid = true; + hwp_is_hybrid = cpu_feature_enabled(X86_FEATURE_HYBRID_CPU); cpu->pstate.turbo_freq = rounddown(cpu->pstate.turbo_pstate * scaling, perf_ctl_scaling); @@ -2279,7 +2279,8 @@ static int hwp_get_cpu_scaling(int cpu) * Return the hybrid scaling factor for P-cores and use the * default core scaling for E-cores. */ - if (hybrid_get_cpu_type(cpu) == INTEL_CPU_TYPE_CORE) + if (hybrid_get_cpu_type(cpu) == INTEL_CPU_TYPE_CORE || + !cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) return hybrid_scaling_factor; return core_get_scaling(); @@ -3734,6 +3735,7 @@ static const struct x86_cpu_id intel_hybrid_scaling_factor[] = { X86_MATCH_VFM(INTEL_RAPTORLAKE, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_RAPTORLAKE_P, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_RAPTORLAKE_S, HYBRID_SCALING_FACTOR_ADL), + X86_MATCH_VFM(INTEL_BARTLETTLAKE, HYBRID_SCALING_FACTOR_ADL), X86_MATCH_VFM(INTEL_METEORLAKE_L, HYBRID_SCALING_FACTOR_MTL), X86_MATCH_VFM(INTEL_LUNARLAKE_M, HYBRID_SCALING_FACTOR_LNL), {} Result on 273PE: intel_pstate: CPU0: HWP_CAP highest = 70, scaling = 78741, cpuinfo.max = 5500000 intel_pstate: CPU12: HWP_CAP highest = 73, scaling = 78741, cpuinfo.max = 5700000 If this direction looks OK, I'll send a v2 with a proper commit message. Thanks, Henry ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] cpufreq: intel_pstate: Use CPPC to get scaling factor for Bartlett Lake 2026-05-07 9:25 ` Henry Tseng @ 2026-05-07 14:47 ` srinivas pandruvada 2026-05-08 6:37 ` Henry Tseng 0 siblings, 1 reply; 5+ messages in thread From: srinivas pandruvada @ 2026-05-07 14:47 UTC (permalink / raw) To: Henry Tseng, Rafael J. Wysocki, Len Brown, Viresh Kumar Cc: linux-pm, SW Chen, Kevin Ko On Thu, 2026-05-07 at 17:25 +0800, Henry Tseng wrote: > On Wed, 06 May 2026 05:15:49 -0700, Srinivas Pandruvada wrote: > > This is a special embedded processor, so to reduce enabling effort > > by > > in BIOS, why not just add > > > > diff --git a/drivers/cpufreq/intel_pstate.c > > b/drivers/cpufreq/intel_pstate.c > > index ec4abe374573..763598ca13cd 100644 > > --- a/drivers/cpufreq/intel_pstate.c > > +++ b/drivers/cpufreq/intel_pstate.c > > @@ -3732,6 +3732,7 @@ static const struct x86_cpu_id > > intel_hybrid_scaling_factor[] = { > > X86_MATCH_VFM(INTEL_RAPTORLAKE, HYBRID_SCALING_FACTOR_ADL), > > X86_MATCH_VFM(INTEL_RAPTORLAKE_P, > > HYBRID_SCALING_FACTOR_ADL), > > X86_MATCH_VFM(INTEL_RAPTORLAKE_S, > > HYBRID_SCALING_FACTOR_ADL), > > + X86_MATCH_VFM(INTEL_BARTLETTLAKE, > > HYBRID_SCALING_FACTOR_ADL), > > X86_MATCH_VFM(INTEL_METEORLAKE_L, > > HYBRID_SCALING_FACTOR_MTL), > > X86_MATCH_VFM(INTEL_LUNARLAKE_M, > > HYBRID_SCALING_FACTOR_LNL), > > {} > > > > CPPC scaling introduces rounding issues for some frequency. This > > will > > avoid introducing another CPU model list. > > Thanks for the review, the static table is definitely simpler. I had > referenced commit 9b18d536b124 and went with CPPC, but I take your > point > about the rounding issues. > After adding INTEL_BARTLETTLAKE to intel_hybrid_scaling_factor[], I > noticed hwp_get_cpu_scaling() still falls back to core_get_scaling() > on > 273PE, because hybrid_get_cpu_type() returns 0 (not > INTEL_CPU_TYPE_CORE) > on a non-hybrid CPU, so the table value doesn't get picked up. I > added a > check for X86_FEATURE_HYBRID_CPU there to let non-hybrid CPUs in the > table > use hybrid_scaling_factor. > This situation is not new, refer to commit 0fcfc9e51990246a9813475716746ff5eb98c6aa cpufreq: intel_pstate: Fix scaling for hybrid-capable systems with disabled E-cores So it seems some regression as it should returned hybrid scaling factor. Don't have this system handy to test. hybrid_get_cpu_type() will return 0 when hybrid feature is not set. With this commit 9b18d536b124357fee56d82b1462c02f78d219e5 adding if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)), will break such configuration. So I suggest to send two patches. The first one can have --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -2273,6 +2273,9 @@ static int knl_get_turbo_pstate(int cpu) static int hwp_get_cpu_scaling(int cpu) { if (hybrid_scaling_factor) { + if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) + return hybrid_scaling_factor; + You can add Fixes tag for commit 9b18d536b124357fee56d82b1462c02f78d219e5. The second patch with hybrid scaling factor for Bartlett Lake, which is like RPL. Thanks, Srinivas > I also kept hwp_is_hybrid = 0 on 273PE to match the current mainline > behavior on non-hybrid CPUs. > > Draft below, based on v7.1-rc2 (7fd2df204f34), tested on Intel Core 9 > 273PE: > > diff --git a/drivers/cpufreq/intel_pstate.c > b/drivers/cpufreq/intel_pstate.c > index 1292da53e5fc..b66455252745 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -585,7 +585,7 @@ static void intel_pstate_hybrid_hwp_adjust(struct > cpudata *cpu) > if (scaling == perf_ctl_scaling) > return; > > - hwp_is_hybrid = true; > + hwp_is_hybrid = cpu_feature_enabled(X86_FEATURE_HYBRID_CPU); > > cpu->pstate.turbo_freq = rounddown(cpu->pstate.turbo_pstate > * scaling, > perf_ctl_scaling); > @@ -2279,7 +2279,8 @@ static int hwp_get_cpu_scaling(int cpu) > * Return the hybrid scaling factor for P-cores and > use the > * default core scaling for E-cores. > */ > - if (hybrid_get_cpu_type(cpu) == INTEL_CPU_TYPE_CORE) > + if (hybrid_get_cpu_type(cpu) == INTEL_CPU_TYPE_CORE > || > + !cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) > return hybrid_scaling_factor; > > return core_get_scaling(); > @@ -3734,6 +3735,7 @@ static const struct x86_cpu_id > intel_hybrid_scaling_factor[] = { > X86_MATCH_VFM(INTEL_RAPTORLAKE, HYBRID_SCALING_FACTOR_ADL), > X86_MATCH_VFM(INTEL_RAPTORLAKE_P, > HYBRID_SCALING_FACTOR_ADL), > X86_MATCH_VFM(INTEL_RAPTORLAKE_S, > HYBRID_SCALING_FACTOR_ADL), > + X86_MATCH_VFM(INTEL_BARTLETTLAKE, > HYBRID_SCALING_FACTOR_ADL), > X86_MATCH_VFM(INTEL_METEORLAKE_L, > HYBRID_SCALING_FACTOR_MTL), > X86_MATCH_VFM(INTEL_LUNARLAKE_M, HYBRID_SCALING_FACTOR_LNL), > {} > > Result on 273PE: > > intel_pstate: CPU0: HWP_CAP highest = 70, scaling = 78741, > cpuinfo.max = 5500000 > intel_pstate: CPU12: HWP_CAP highest = 73, scaling = 78741, > cpuinfo.max = 5700000 > > If this direction looks OK, I'll send a v2 with a proper commit > message. > > Thanks, > Henry ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] cpufreq: intel_pstate: Use CPPC to get scaling factor for Bartlett Lake 2026-05-07 14:47 ` srinivas pandruvada @ 2026-05-08 6:37 ` Henry Tseng 0 siblings, 0 replies; 5+ messages in thread From: Henry Tseng @ 2026-05-08 6:37 UTC (permalink / raw) To: Srinivas Pandruvada, Rafael J. Wysocki, Len Brown, Viresh Kumar Cc: linux-pm, SW Chen, Kevin Ko, Henry Tseng On Thu, 07 May 2026 07:47:05 -0700, srinivas pandruvada wrote: > So I suggest to send two patches. The first one can have > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -2273,6 +2273,9 @@ static int knl_get_turbo_pstate(int cpu) > static int hwp_get_cpu_scaling(int cpu) > { > if (hybrid_scaling_factor) { > + if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) > + return hybrid_scaling_factor; > + > You can add Fixes tag for commit > 9b18d536b124357fee56d82b1462c02f78d219e5. > > The second patch with hybrid scaling factor for Bartlett Lake, which is > like RPL. > > Thanks, > Srinivas Thanks for the review. I've sent v2 with the two patches as suggested. Henry ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-05-08 6:38 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-05-06 9:51 [PATCH] cpufreq: intel_pstate: Use CPPC to get scaling factor for Bartlett Lake Henry Tseng 2026-05-06 12:15 ` srinivas pandruvada 2026-05-07 9:25 ` Henry Tseng 2026-05-07 14:47 ` srinivas pandruvada 2026-05-08 6:37 ` Henry Tseng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox