linux.git/drivers/cpufreq/mediatek-cpufreq-hw.c, branch v6.18.8

cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency

2025-10-01T11:56:24+00:00

Commit a755d0e2d41b ("cpufreq: Honour transition_latency over
transition_delay_us") caused platforms where cpuinfo.transition_latency
is CPUFREQ_ETERNAL to get a very large transition latency whereas
previously it had been capped at 10 ms (and later at 2 ms).

This led to a user-observable regression between 6.6 and 6.12 as
described by Shawn:

"The dbs sampling_rate was 10000 us on 6.6 and suddently becomes
 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these platforms
 because the default transition delay was dropped [...].

 It slows down dbs governor's reacting to CPU loading change
 dramatically.  Also, as transition_delay_us is used by schedutil
 governor as rate_limit_us, it shows a negative impact on device
 idle power consumption, because the device gets slightly less time
 in the lowest OPP."

Evidently, the expectation of the drivers using CPUFREQ_ETERNAL as
cpuinfo.transition_latency was that it would be capped by the core,
but they may as well return a default transition latency value instead
of CPUFREQ_ETERNAL and the core need not do anything with it.

Accordingly, introduce CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS and make
all of the drivers in question use it instead of CPUFREQ_ETERNAL.  Also
update the related Rust binding.

Fixes: a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us")
Closes: https://lore.kernel.org/linux-pm/20250922125929.453444-1-shawnguo2@yeah.net/
Reported-by: Shawn Guo 
Reviewed-by: Mario Limonciello (AMD) 
Reviewed-by: Jie Zhan 
Acked-by: Viresh Kumar 
Cc: 6.6+  # 6.6+
Signed-off-by: Rafael J. Wysocki 
Link: https://patch.msgid.link/2264949.irdbgypaU6@rafael.j.wysocki
[ rjw: Fix typo in new symbol name, drop redundant type cast from Rust binding ]
Tested-by: Shawn Guo  # with cpufreq-dt driver
Reviewed-by: Qais Yousef 
Signed-off-by: Rafael J. Wysocki

cpufreq: mediatek-hw: don't use error path on NULL fdvfs

2025-08-20T04:06:58+00:00

The IS_ERR_OR_NULL check for priv->fdvfs is inappropriate, and should be
an IS_ERR check instead, as a NULL value here would propagate it to
PTR_ERR.

In practice, there is no problem here, as devm_of_iomap cannot return
NULL in any circumstance. However, it causes a Smatch static checker
warning.

Fix the warning by changing the check from IS_ERR_OR_NULL to IS_ERR.

Fixes: 32e0d669f3ac ("cpufreq: mediatek-hw: Add support for MT8196")
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/linux-pm/aKQubSEXH1TXQpnR@stanley.mountain/
Signed-off-by: Nicolas Frattaroli 
Signed-off-by: Viresh Kumar

cpufreq: mediatek-hw: Add support for MT8196

2025-08-11T06:49:03+00:00

The MT8196 SoC uses DVFS to set a desired target frequency for each CPU
core. It also uses slightly different register offsets.

Add support for it, which necessitates reworking how the mmio regs are
acquired, as mt8196 has the fdvfs register before the performance domain
registers.

I've verified with both `sysbench cpu run` and `head -c 10G \
/dev/urandom | pigz -p 8 -c - | pv -ba > /dev/null` that we don't just
get a higher reported clock frequency, but that the observed performance
also increases, by a factor of 2.64 in an 8 thread sysbench test.

Signed-off-by: Nicolas Frattaroli 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Viresh Kumar

cpufreq: mediatek-hw: Separate per-domain and per-instance data

2025-08-11T06:49:02+00:00

As it stood, the mediatek cpufreq driver could get away with never
really having a private driver instance struct. This is because all data
was stored in the per-domain structs.

However, this complicates matters when actual per-instance data like the
variant struct is introduced. Instead of having a pointer to it for
every domain, have a pointer to a global "priv" struct that can be
extended over time, and rename the "data" struct to "domain" to
distinguish its purpose better.

Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Nicolas Frattaroli 
Signed-off-by: Viresh Kumar

cpufreq: mediatek-hw: Refactor match data into struct

2025-08-11T06:49:02+00:00

While the driver could get away with having the per-compatible match
data just be an array of the reg offsets, the only thing it used it for
right now, this doesn't really allow it to be extended in any meaningful
way if some other per-variant information needs to be communicated.

In preparation of adding support for hybrid "FDVFS" for MT8196, refactor
the code to make the DT match data a struct, which currently only
contains a single member: the reg offsets. This will allow this struct
to be extended with other members for other hardware variants.

Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Nicolas Frattaroli 
Signed-off-by: Viresh Kumar

cpufreq: Init cpufreq only for present CPUs

2025-03-17T05:59:18+00:00

for_each_possible_cpu() is currently used to initialize cpufreq.
However, in cpu_dev_register_generic(), for_each_present_cpu()
is used to register CPU devices which means the CPU devices are
only registered for present CPUs and not all possible CPUs.

With nosmp or maxcpus=0, only the boot CPU is present, lead
to the cpufreq probe failure or defer probe due to no cpu device
available for not present CPUs.

Change for_each_possible_cpu() to for_each_present_cpu() in the
above cpufreq drivers to ensure it only registers cpufreq for
CPUs that are actually present.

Fixes: b0c69e1214bc ("drivers: base: Use present CPUs in GENERIC_CPU_DEVICES")
Reviewed-by: Sudeep Holla 
Signed-off-by: Jacky Bai 
Signed-off-by: Viresh Kumar

cpufreq: mediatek: Stop setting cpufreq_driver->attr field

2025-02-07T04:15:12+00:00

The cpufreq core now handles this for basic attributes, including boost
frequencies, the driver can skip setting them.

Signed-off-by: Viresh Kumar 
Acked-by: Rafael J. Wysocki

Merge tag 'cpufreq-arm-updates-6.13' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/vireshk/pm

2024-11-19T20:35:14+00:00

Merge ARM cpufreq updates for 6.13 from Viresh Kumar:

"- Add virtual cpufreq driver for guest kernels (David Dai).

 - Minor cleanup to various cpufreq drivers (Andy Shevchenko, Dhruva
   Gole, Jie Zhan, Jinjie Ruan, Shuosheng Huang, Sibi Sankar, and Yuan
   Can).

 - Revert "cpufreq: brcmstb-avs-cpufreq: Fix initial command check"
   (Colin Ian King).

 - Improve DT bindings for qcom-hw driver (Dmitry Baryshkov, Konrad
   Dybcio, and Nikunj Kela)."

* tag 'cpufreq-arm-updates-6.13' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
  arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw
  dt-bindings: cpufreq: cpufreq-qcom-hw: Add SC8180X compatible
  cpufreq: sun50i: add a100 cpufreq support
  cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()
  cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()
  cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()
  cpufreq: loongson3: Check for error code from devm_mutex_init() call
  cpufreq: scmi: Fix cleanup path when boost enablement fails
  cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()
  cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()
  Revert "cpufreq: brcmstb-avs-cpufreq: Fix initial command check"
  dt-bindings: cpufreq: cpufreq-qcom-hw: Add SAR2130P compatible
  cpufreq: add virtual-cpufreq driver
  dt-bindings: cpufreq: add virtual cpufreq device
  cpufreq: loongson2: Unregister platform_driver on failure
  cpufreq: ti-cpufreq: Remove revision offsets in AM62 family
  cpufreq: ti-cpufreq: Allow backward compatibility for efuse syscon
  cppc_cpufreq: Remove HiSilicon CPPC workaround
  cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged
  dt-bindings: cpufreq: qcom-hw: document support for SA8255p

cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()

2024-11-11T04:15:17+00:00

mtk_cpufreq_get_cpu_power() return 0 if the policy is NULL. Then in
em_create_perf_table(), the later zero check for power is not invalid
as power is uninitialized. As Lukasz suggested, it must return -EINVAL when
the 'policy' is not found. So return -EINVAL to fix it.

Cc: stable@vger.kernel.org
Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW")
Reviewed-by: Lukasz Luba 
Suggested-by: Lukasz Luba 
Signed-off-by: Jinjie Ruan 
Signed-off-by: Viresh Kumar

cpufreq: Switch back to struct platform_driver::remove()

2024-10-28T11:24:39+00:00

After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.

Convert all platform drivers below drivers/cpufreq to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.

Signed-off-by: Uwe Kleine-König 
Acked-by: Viresh Kumar 
Link: https://patch.msgid.link/20241020153910.324096-2-u.kleine-koenig@baylibre.com
Signed-off-by: Rafael J. Wysocki