* [PATCH v3 0/2] arm64/cpufreq: report and track frequencies above 4.19 GHz @ 2026-09-10 6:34 Oleg Keri 2026-09-10 6:34 ` [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow " Oleg Keri 2026-09-10 6:34 ` [PATCH v3 2/2] cpufreq: update capacity_freq_ref when the boost state changes Oleg Keri 0 siblings, 2 replies; 6+ messages in thread From: Oleg Keri @ 2026-09-10 6:34 UTC (permalink / raw) To: Catalin Marinas, Will Deacon, Mark Rutland, Sumit Gupta, Prasanna Kumar T S M, Beata Michalska, Russell King, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Sudeep Holla, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Viresh Kumar Cc: linux-arm-kernel, linux-kernel, linux-riscv, driver-core, linux-pm, jonathan.cameron, sibi.sankar The Snapdragon X2 Elite (Glymur) is the first arm64 laptop part I have seen whose boost OPP, 4723200 kHz, sits above 4194304 kHz. Two independent problems become visible there, both of which make the kernel believe a boosted CPU is running slower than it is. Patch 1 fixes an overflow in arch_freq_get_on_cpu(): the u64 product of the frequency scale and the reference frequency is truncated to unsigned int before being shifted back down, which wraps for any reference frequency above 2^32 / SCHED_CAPACITY_SCALE = 4194304 kHz. Patch 2 makes capacity_freq_ref follow the boost state. It is latched once on CPUFREQ_CREATE_POLICY, and boost frequencies are excluded from policy->cpuinfo.max_freq while boost is off, so on a machine that boots with boost disabled it keeps the sustained maximum forever. On arm64 that saturates the AMU frequency scale at SCHED_CAPACITY_SCALE, so the scheduler cannot distinguish a boosted CPU from one at the sustained maximum, and arch_freq_get_on_cpu() cannot report above it. The order matters: patch 2 is what raises capacity_freq_ref past 4194304 kHz on this machine, so patch 1 has to land with or before it. Measured on a Lenovo Yoga Slim 7x Gen 11 (Glymur, 4032000 kHz sustained, 4723200 kHz boost), pinning a policy to a single OPP and timing a fixed workload on one of its CPUs: requested OPP time cpuinfo_avg_freq --------------------------------------------------------- 4032000 kHz 2.011s 4031325 (0.02% low) 4723200 kHz 1.726s 524283 before 4723200 kHz 1.726s 4032000 with patch 1 only 4723200 kHz 1.726s 4718587 with both (0.10% low) The timings never change: 2.011 / 1.726 = 1.165 against a frequency ratio of 4723200 / 4032000 = 1.171, so the hardware was running at the requested frequency throughout. Only the kernel's view of it was wrong. Note that cpuinfo_cur_freq still reports 4032000 kHz at the boost OPP on this machine. That is a separate path -- scmi_dvfs_freq_get() asking firmware for the current performance level -- with no clamp in the kernel, and it is not addressed here. Changes in v3: - Patch 1: drop the Suggested-by trailer. It was not warranted for a review comment on the shape of an existing patch; my mistake. - No code changes. - Link to v2: https://lore.kernel.org/all/20260909192351.33910-1-okerixx@gmail.com/ Changes in v2: - Patch 1: fold the multiply and the shift into a single expression, as suggested on v1, instead of reusing the u64 scale variable as scratch. Same semantics - the multiply and the shift both stay in u64 and only the final value is narrowed to the unsigned int - but it reads better. - Patch 2: unchanged. - Link to v1: https://lore.kernel.org/all/cover.1788712186.git.okerixx@gmail.com/ Oleg Keri (2): arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz cpufreq: update capacity_freq_ref when the boost state changes arch/arm/include/asm/topology.h | 1 + arch/arm64/include/asm/topology.h | 1 + arch/arm64/kernel/topology.c | 3 +-- arch/riscv/include/asm/topology.h | 1 + drivers/base/arch_topology.c | 19 +++++++++++++------ drivers/cpufreq/cpufreq.c | 2 ++ include/linux/arch_topology.h | 1 + include/linux/cpufreq.h | 7 +++++++ 8 files changed, 27 insertions(+), 8 deletions(-) -- 2.55.0 base-commit: df2908090cda368b01ff43709f51890076c56157 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz 2026-09-10 6:34 [PATCH v3 0/2] arm64/cpufreq: report and track frequencies above 4.19 GHz Oleg Keri @ 2026-09-10 6:34 ` Oleg Keri 2026-09-14 7:04 ` Beata Michalska 2026-09-16 10:52 ` Dietmar Eggemann 2026-09-10 6:34 ` [PATCH v3 2/2] cpufreq: update capacity_freq_ref when the boost state changes Oleg Keri 1 sibling, 2 replies; 6+ messages in thread From: Oleg Keri @ 2026-09-10 6:34 UTC (permalink / raw) To: Catalin Marinas, Will Deacon, Mark Rutland, Sumit Gupta, Prasanna Kumar T S M, Beata Michalska, Russell King, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Sudeep Holla, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Viresh Kumar Cc: linux-arm-kernel, linux-kernel, linux-riscv, driver-core, linux-pm, jonathan.cameron, sibi.sankar arch_freq_get_on_cpu() computes the product of the frequency scale and the reference frequency as a u64, but assigns it to an unsigned int before shifting it back down: freq = scale * arch_scale_freq_ref(cpu); freq >>= SCHED_CAPACITY_SHIFT; The product is truncated to 32 bits before the shift, so the result wraps once arch_scale_freq_ref() exceeds 2^32 / SCHED_CAPACITY_SCALE, i.e. 4194304 kHz. On a Snapdragon X2 Elite (Glymur) laptop, whose boost OPP is 4723200 kHz, cpuinfo_avg_freq reports 524283 kHz instead of ~4723200 kHz while the CPU demonstrably runs at the boost frequency: a fixed workload completes in 1.72 s at the 4723200 kHz OPP versus 2.01 s at 4032000 kHz, matching the 1.171 frequency ratio. Keep the arithmetic in 64 bits until after the shift. Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu") Signed-off-by: Oleg Keri <okerixx@gmail.com> --- arch/arm64/kernel/topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c index d28438f8b83f..0eca321ff113 100644 --- a/arch/arm64/kernel/topology.c +++ b/arch/arm64/kernel/topology.c @@ -245,8 +245,7 @@ int arch_freq_get_on_cpu(int cpu) * (see amu_scale_freq_tick for details) */ scale = arch_scale_freq_capacity(cpu); - freq = scale * arch_scale_freq_ref(cpu); - freq >>= SCHED_CAPACITY_SHIFT; + freq = (scale * arch_scale_freq_ref(cpu)) >> SCHED_CAPACITY_SHIFT; return freq; } -- 2.55.0 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz 2026-09-10 6:34 ` [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow " Oleg Keri @ 2026-09-14 7:04 ` Beata Michalska 2026-09-16 10:52 ` Dietmar Eggemann 1 sibling, 0 replies; 6+ messages in thread From: Beata Michalska @ 2026-09-14 7:04 UTC (permalink / raw) To: Oleg Keri Cc: Catalin Marinas, Will Deacon, Mark Rutland, Sumit Gupta, Prasanna Kumar T S M, Russell King, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Sudeep Holla, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Viresh Kumar, linux-arm-kernel, linux-kernel, linux-riscv, driver-core, linux-pm, jonathan.cameron, sibi.sankar Ack. Thanks for the patch. --- BR Beata On Thu, Sep 10, 2026 at 08:34:39AM +0200, Oleg Keri wrote: > arch_freq_get_on_cpu() computes the product of the frequency scale and > the reference frequency as a u64, but assigns it to an unsigned int > before shifting it back down: > > freq = scale * arch_scale_freq_ref(cpu); > freq >>= SCHED_CAPACITY_SHIFT; > > The product is truncated to 32 bits before the shift, so the result > wraps once arch_scale_freq_ref() exceeds 2^32 / SCHED_CAPACITY_SCALE, > i.e. 4194304 kHz. > > On a Snapdragon X2 Elite (Glymur) laptop, whose boost OPP is 4723200 > kHz, cpuinfo_avg_freq reports 524283 kHz instead of ~4723200 kHz while > the CPU demonstrably runs at the boost frequency: a fixed workload > completes in 1.72 s at the 4723200 kHz OPP versus 2.01 s at 4032000 > kHz, matching the 1.171 frequency ratio. > > Keep the arithmetic in 64 bits until after the shift. > > Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu") > Signed-off-by: Oleg Keri <okerixx@gmail.com> > --- > arch/arm64/kernel/topology.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c > index d28438f8b83f..0eca321ff113 100644 > --- a/arch/arm64/kernel/topology.c > +++ b/arch/arm64/kernel/topology.c > @@ -245,8 +245,7 @@ int arch_freq_get_on_cpu(int cpu) > * (see amu_scale_freq_tick for details) > */ > scale = arch_scale_freq_capacity(cpu); > - freq = scale * arch_scale_freq_ref(cpu); > - freq >>= SCHED_CAPACITY_SHIFT; > + freq = (scale * arch_scale_freq_ref(cpu)) >> SCHED_CAPACITY_SHIFT; > return freq; > } > > -- > 2.55.0 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz 2026-09-10 6:34 ` [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow " Oleg Keri 2026-09-14 7:04 ` Beata Michalska @ 2026-09-16 10:52 ` Dietmar Eggemann 2026-09-16 11:23 ` Oleg Keri 1 sibling, 1 reply; 6+ messages in thread From: Dietmar Eggemann @ 2026-09-16 10:52 UTC (permalink / raw) To: Oleg Keri, Catalin Marinas, Will Deacon, Mark Rutland, Sumit Gupta, Prasanna Kumar T S M, Beata Michalska, Russell King, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Sudeep Holla, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Viresh Kumar Cc: linux-arm-kernel, linux-kernel, linux-riscv, driver-core, linux-pm, jonathan.cameron, sibi.sankar On 10.09.26 08:34, Oleg Keri wrote: [...] > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c > index d28438f8b83f..0eca321ff113 100644 > --- a/arch/arm64/kernel/topology.c > +++ b/arch/arm64/kernel/topology.c > @@ -245,8 +245,7 @@ int arch_freq_get_on_cpu(int cpu) > * (see amu_scale_freq_tick for details) > */ > scale = arch_scale_freq_capacity(cpu); > - freq = scale * arch_scale_freq_ref(cpu); > - freq >>= SCHED_CAPACITY_SHIFT; > + freq = (scale * arch_scale_freq_ref(cpu)) >> SCHED_CAPACITY_SHIFT; > return freq; > } In task scheduler code we use cap_scale(v, s) for CPU capacity related scaling. We could move its definition from private task scheduler include file kernel/sched/sched.h to include/linux/topology.h to be able to use it also outside the task scheduler? Only compile tested on arm64 and x86. -->8-- diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c index 0eca321ff113..180a7aa97752 100644 --- a/arch/arm64/kernel/topology.c +++ b/arch/arm64/kernel/topology.c @@ -186,7 +186,6 @@ int arch_freq_get_on_cpu(int cpu) struct amu_cntr_sample *amu_sample; unsigned int start_cpu = cpu; unsigned long last_update; - unsigned int freq = 0; u64 scale; if (!amu_fie_cpu_supported(cpu) || !arch_scale_freq_ref(cpu)) @@ -245,8 +244,7 @@ int arch_freq_get_on_cpu(int cpu) * (see amu_scale_freq_tick for details) */ scale = arch_scale_freq_capacity(cpu); - freq = (scale * arch_scale_freq_ref(cpu)) >> SCHED_CAPACITY_SHIFT; - return freq; + return cap_scale(arch_scale_freq_ref(cpu), scale); } static void amu_fie_setup(const struct cpumask *cpus) diff --git a/include/linux/topology.h b/include/linux/topology.h index 709a2dcf4c73..0a4ee12a98d5 100644 --- a/include/linux/topology.h +++ b/include/linux/topology.h @@ -351,4 +351,6 @@ static inline unsigned long topology_get_cpu_scale(int cpu) void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity); +#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT) + #endif /* _LINUX_TOPOLOGY_H */ diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 6c3ad70e58b8..45796fccdc84 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -236,8 +236,6 @@ static inline int task_has_dl_policy(struct task_struct *p) return dl_policy(p->policy); } -#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT) - static inline void update_avg(u64 *avg, u64 sample) { s64 diff = sample - *avg; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow above 4.19 GHz 2026-09-16 10:52 ` Dietmar Eggemann @ 2026-09-16 11:23 ` Oleg Keri 0 siblings, 0 replies; 6+ messages in thread From: Oleg Keri @ 2026-09-16 11:23 UTC (permalink / raw) To: Dietmar Eggemann Cc: Catalin Marinas, Will Deacon, Mark Rutland, Sumit Gupta, Prasanna Kumar T S M, Beata Michalska, Russell King, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Sudeep Holla, Greg Kroah-Hartman, Rafael J. Wysocki, Viresh Kumar, linux-arm-kernel, linux-pm, linux-kernel Hi Dietmar, On Wed, Sep 16, 2026, Dietmar Eggemann wrote: > In task scheduler code we use cap_scale(v, s) for CPU capacity related > scaling. > > We could move its definition from private task scheduler include file > kernel/sched/sched.h to include/linux/topology.h to be able to use it > also outside the task scheduler? Fine by me, that reads better than open-coding the shift. Your diff builds here on arm64 (topology.o and kernel/sched/), so I will fold it into v4 and add the scheduler maintainers to Cc for the header move. Since the diff is yours: is a Suggested-by enough, or would you rather have Co-developed-by and your Signed-off-by on the patch? Thanks, Oleg ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v3 2/2] cpufreq: update capacity_freq_ref when the boost state changes 2026-09-10 6:34 [PATCH v3 0/2] arm64/cpufreq: report and track frequencies above 4.19 GHz Oleg Keri 2026-09-10 6:34 ` [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow " Oleg Keri @ 2026-09-10 6:34 ` Oleg Keri 1 sibling, 0 replies; 6+ messages in thread From: Oleg Keri @ 2026-09-10 6:34 UTC (permalink / raw) To: Catalin Marinas, Will Deacon, Mark Rutland, Sumit Gupta, Prasanna Kumar T S M, Beata Michalska, Russell King, Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Sudeep Holla, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Viresh Kumar Cc: linux-arm-kernel, linux-kernel, linux-riscv, driver-core, linux-pm, jonathan.cameron, sibi.sankar capacity_freq_ref is latched from policy->cpuinfo.max_freq by init_cpu_capacity_callback() on CPUFREQ_CREATE_POLICY, and never updated afterwards. cpufreq_frequency_table_cpuinfo() excludes CPUFREQ_BOOST_FREQ entries while boost is disabled, so on a system that boots with boost off the latched value is the non-boost maximum. Enabling boost later raises policy->cpuinfo.max_freq but leaves capacity_freq_ref behind. Two things then go wrong on arm64, where the AMU drives frequency invariance. amu_scale_freq_tick() caps the computed scale at SCHED_CAPACITY_SCALE, so a CPU running above capacity_freq_ref saturates at 1024: the scheduler cannot tell a boosted CPU from one at the sustained maximum, and utilisation is underestimated. And arch_freq_get_on_cpu(), which reverses that computation, cannot report more than capacity_freq_ref, so cpuinfo_avg_freq is pinned to the non-boost maximum. On a Snapdragon X2 Elite (Glymur) laptop with a 4032000 kHz sustained and a 4723200 kHz boost OPP, cpuinfo_avg_freq reads exactly 4032000 while the CPU runs at 4723200; a fixed workload completes in 1.72 s rather than the 2.01 s that frequency would imply. Factor the update out of init_cpu_capacity_callback() into topology_update_freq_ref() and call it from policy_set_boost(), which is the common path for the global boost knob, the per-policy one, and the CPU online path. Signed-off-by: Oleg Keri <okerixx@gmail.com> --- arch/arm/include/asm/topology.h | 1 + arch/arm64/include/asm/topology.h | 1 + arch/riscv/include/asm/topology.h | 1 + drivers/base/arch_topology.c | 19 +++++++++++++------ drivers/cpufreq/cpufreq.c | 2 ++ include/linux/arch_topology.h | 1 + include/linux/cpufreq.h | 7 +++++++ 7 files changed, 26 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h index ad36b6570067..a776a79885ee 100644 --- a/arch/arm/include/asm/topology.h +++ b/arch/arm/include/asm/topology.h @@ -11,6 +11,7 @@ #ifndef CONFIG_BL_SWITCHER /* Replace task scheduler's default frequency-invariant accounting */ #define arch_set_freq_scale topology_set_freq_scale +#define arch_update_freq_ref topology_update_freq_ref #define arch_scale_freq_capacity topology_get_freq_scale #define arch_scale_freq_invariant topology_scale_freq_invariant #define arch_scale_freq_ref topology_get_freq_ref diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h index b9eaf4ad7085..a4b96a7ee4a5 100644 --- a/arch/arm64/include/asm/topology.h +++ b/arch/arm64/include/asm/topology.h @@ -22,6 +22,7 @@ void update_freq_counters_refs(void); /* Replace task scheduler's default frequency-invariant accounting */ #define arch_scale_freq_tick topology_scale_freq_tick #define arch_set_freq_scale topology_set_freq_scale +#define arch_update_freq_ref topology_update_freq_ref #define arch_scale_freq_capacity topology_get_freq_scale #define arch_scale_freq_invariant topology_scale_freq_invariant #define arch_scale_freq_ref topology_get_freq_ref diff --git a/arch/riscv/include/asm/topology.h b/arch/riscv/include/asm/topology.h index fe1a8bf6902d..a363d72c174f 100644 --- a/arch/riscv/include/asm/topology.h +++ b/arch/riscv/include/asm/topology.h @@ -11,6 +11,7 @@ /* Replace task scheduler's default frequency-invariant accounting */ #define arch_scale_freq_tick topology_scale_freq_tick #define arch_set_freq_scale topology_set_freq_scale +#define arch_update_freq_ref topology_update_freq_ref #define arch_scale_freq_capacity topology_get_freq_scale #define arch_scale_freq_invariant topology_scale_freq_invariant #define arch_scale_freq_ref topology_get_freq_ref diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 8c5e47c28d9a..79eb1681065d 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -317,6 +317,18 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu) return !ret; } +void topology_update_freq_ref(const struct cpumask *cpus, unsigned int max_freq) +{ + int cpu; + + for_each_cpu(cpu, cpus) { + per_cpu(capacity_freq_ref, cpu) = max_freq; + freq_inv_set_max_ratio(cpu, + per_cpu(capacity_freq_ref, cpu) * HZ_PER_KHZ); + } +} +EXPORT_SYMBOL_GPL(topology_update_freq_ref); + void __weak freq_inv_set_max_ratio(int cpu, u64 max_rate) { } @@ -392,7 +404,6 @@ init_cpu_capacity_callback(struct notifier_block *nb, void *data) { struct cpufreq_policy *policy = data; - int cpu; if (val != CPUFREQ_CREATE_POLICY) return 0; @@ -403,11 +414,7 @@ init_cpu_capacity_callback(struct notifier_block *nb, cpumask_andnot(cpus_to_visit, cpus_to_visit, policy->related_cpus); - for_each_cpu(cpu, policy->related_cpus) { - per_cpu(capacity_freq_ref, cpu) = policy->cpuinfo.max_freq; - freq_inv_set_max_ratio(cpu, - per_cpu(capacity_freq_ref, cpu) * HZ_PER_KHZ); - } + topology_update_freq_ref(policy->related_cpus, policy->cpuinfo.max_freq); if (cpumask_empty(cpus_to_visit)) { if (raw_capacity) { diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 96515880b4ac..a70805a1d9d3 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -594,6 +594,8 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable) return ret; } + arch_update_freq_ref(policy->related_cpus, policy->cpuinfo.max_freq); + return 0; } diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h index ebd7f8935f96..4974f5e1a7fe 100644 --- a/include/linux/arch_topology.h +++ b/include/linux/arch_topology.h @@ -31,6 +31,7 @@ static inline unsigned long topology_get_freq_scale(int cpu) void topology_set_freq_scale(const struct cpumask *cpus, unsigned long cur_freq, unsigned long max_freq); +void topology_update_freq_ref(const struct cpumask *cpus, unsigned int max_freq); bool topology_scale_freq_invariant(void); enum scale_freq_source { diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 35ce665edfd8..5b904e13eb21 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -1235,6 +1235,13 @@ void arch_set_freq_scale(const struct cpumask *cpus, } #endif +#ifndef arch_update_freq_ref +static __always_inline +void arch_update_freq_ref(const struct cpumask *cpus, unsigned int max_freq) +{ +} +#endif + /* the following are really really optional */ extern struct freq_attr cpufreq_freq_attr_scaling_available_freqs; extern struct freq_attr cpufreq_freq_attr_scaling_boost_freqs; -- 2.55.0 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-16 11:23 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-09-10 6:34 [PATCH v3 0/2] arm64/cpufreq: report and track frequencies above 4.19 GHz Oleg Keri 2026-09-10 6:34 ` [PATCH v3 1/2] arm64: topology: fix arch_freq_get_on_cpu() overflow " Oleg Keri 2026-09-14 7:04 ` Beata Michalska 2026-09-16 10:52 ` Dietmar Eggemann 2026-09-16 11:23 ` Oleg Keri 2026-09-10 6:34 ` [PATCH v3 2/2] cpufreq: update capacity_freq_ref when the boost state changes Oleg Keri
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®