kernel/git/next/linux-next.git/drivers/cpufreq/cpufreq-dt.c, branch master

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: dt: Add register helper

2025-07-09T08:11:33+00:00

Cpufreq-dt currently exports no functions. This means that drivers that are based on cpufreq-dt have no way of establishing a depmod dependency on it. This helper allows that link. Signed-off-by: Aaron Kling 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: dt: Set .set_boost directly

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

The boost feature can be controlled at two levels currently, driver level (applies to all policies) and per-policy. Currently the driver enables driver level boost support from the per-policy ->init() callback, which isn't really efficient as that gets called for each policy and then there is online/offline path too where this gets done unnecessarily. Instead set the .set_boost field directly and always enable the boost support. If a policy doesn't support boost feature, the core will not enable it for that policy. Keep the initial state of driver level boost to disabled and let the user enable it if required as ideally the boost frequencies must be used only when really required. Signed-off-by: Viresh Kumar

cpufreq: dt: Stop setting cpufreq_driver->attr field

2025-02-07T04:15:11+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

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

cpufreq: Use of_property_present()

2024-08-07T06:41:45+00:00

Use of_property_present() to test for property presence rather than of_(find|get)_property(). This is part of a larger effort to remove callers of of_find_property() and similar functions. of_find_property() leaks the DT struct property and data pointers which is a problem for dynamically allocated nodes which may be freed. Signed-off-by: Rob Herring (Arm) Acked-by: Chen-Yu Tsai Signed-off-by: Viresh Kumar

cpufreq: Make cpufreq_driver->exit() return void

2024-07-09T03:15:30+00:00

The cpufreq core doesn't check the return type of the exit() callback and there is not much the core can do on failures at that point. Just drop the returned value and make it return void. Signed-off-by: Lizhe [ Viresh: Reworked the patches to fix all missing changes together. ] Signed-off-by: Viresh Kumar Reviewed-by: AngeloGioacchino Del Regno # Mediatek Acked-by: Sudeep Holla # scpi, scmi, vexpress Acked-by: Mario Limonciello # amd Reviewed-by: Florian Fainelli # bmips Acked-by: Rafael J. Wysocki Acked-by: Kevin Hilman # omap

cpufreq: dt: eliminate uses of of_node_put()

2024-04-23T09:29:56+00:00

Make use of the __free() cleanup handler to automatically free nodes when they get out of scope. Only find_supply_name() is affected, and the new mechanism removes the need for a 'goto' and the 'name' local variable. Signed-off-by: Javier Carrasco Signed-off-by: Viresh Kumar

cpufreq: dt: always allocate zeroed cpumask

2024-03-15T05:48:54+00:00

Commit 0499a78369ad ("ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512") changed the handling of cpumasks on ARM 64bit, what resulted in the strange issues and warnings during cpufreq-dt initialization on some big.LITTLE platforms. This was caused by mixing OPPs between big and LITTLE cores, because OPP-sharing information between big and LITTLE cores is computed on cpumask, which in turn was not zeroed on allocation. Fix this by switching to zalloc_cpumask_var() call. Fixes: dc279ac6e5b4 ("cpufreq: dt: Refactor initialization to handle probe deferral properly") CC: stable@vger.kernel.org # v5.10+ Signed-off-by: Marek Szyprowski Reviewed-by: Christoph Lameter (Ampere) Reviewed-by: Dhruva Gole Signed-off-by: Viresh Kumar