user/sven/linux.git/include/linux/cpufreq.h, branch v6.13.7

cpufreq: Avoid a bad reference count on CPU node

2024-10-01T18:43:44Z

In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute. Signed-off-by: Miquel Sabaté Solà Acked-by: Viresh Kumar Link: https://patch.msgid.link/20240917134246.584026-1-mikisabate@gmail.com Cc: All applicable Signed-off-by: Rafael J. Wysocki

cpufreq: Remove LATENCY_MULTIPLIER

2024-08-02T13:56:38Z

The current LATENCY_MULTIPLIER which has been around for nearly 20 years causes rate_limit_us to be always in ms range. On M1 mac mini I get 50 and 56us transition latency, but due to the 1000 multiplier we end up setting rate_limit_us to 50 and 56ms, which gets capped into 2ms and was 10ms before e13aa799c2a6 ("cpufreq: Change default transition delay to 2ms") On Intel I5 system transition latency is 20us but due to the multiplier we end up with 20ms that again is capped to 2ms. Given how good modern hardware and how modern workloads require systems to be more responsive to cater for sudden changes in workload (tasks sleeping/wakeup/migrating, uclamp causing a sudden boost or cap) and that 2ms is quarter of the time of 120Hz refresh rate system, drop the old logic in favour of providing 50% headroom. rate_limit_us = 1.5 * latency. I considered not adding any headroom which could mean that we can end up with infinite back-to-back requests. I also considered providing a constant headroom (e.g: 100us) assuming that any h/w or f/w dealing with the request shouldn't require a large headroom when transition_latency is actually high. But for both cases I wasn't sure if h/w or f/w can end up being overwhelmed dealing with the freq requests in a potentially busy system. So I opted for providing 50% breathing room. This is expected to impact schedutil only as the other user, dbs_governor, takes the max(2*tick, transition_delay_us) and the former was at least 2ms on 1ms TICK, which is equivalent to the max_delay_us before applying this patch. For systems with TICK of 4ms, this value would have almost always ended up with 8ms sampling rate. For systems that report 0 transition latency, we still default to returning 1ms as transition delay. This helps in eliminating a source of latency for applying requests as mentioned in [1]. For example if we have a 1ms tick, most systems will miss sending an update at tick when updating the util_avg for a task/CPU (rate_limit_us will be 2ms for most systems). Link: https://lore.kernel.org/lkml/20240724212255.mfr2ybiv2j2uqek7@airbuntu/ # [1] Link: https://lore.kernel.org/lkml/20240205022500.2232124-1-qyousef@layalina.io/ Signed-off-by: Qais Yousef Link: https://patch.msgid.link/20240728192659.58115-1-qyousef@layalina.io [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki

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

2024-07-09T15:58:20Z

Merge ARM cpufreq updates for 6.11 from Viresh Kumar: "- cpufreq: Add Loongson-3 CPUFreq driver support (Huacai Chen). - Make exit() callback return void (Lizhe and Viresh Kumar). - Minor cleanups and fixes in several drivers (Bryan Brattlof, Javier Carrasco, Jagadeesh Kona, Jeff Johnson, Nícolas F. R. A. Prado, Primoz Fiser, Raphael Gallais-Pou, and Riwen Lu)." * tag 'cpufreq-arm-updates-6.11' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (21 commits) cpufreq: sti: fix build warning cpufreq: mediatek: Use dev_err_probe in every error path in probe cpufreq: Add Loongson-3 CPUFreq driver support cpufreq: Make cpufreq_driver->exit() return void cpufreq: pcc: Remove empty exit() callback cpufreq: loongson2: Remove empty exit() callback cpufreq: nforce2: Remove empty exit() callback cpufreq: sti: add missing MODULE_DEVICE_TABLE entry for stih418 cpufreq: ti: update OPP table for AM62Px SoCs cpufreq: ti: update OPP table for AM62Ax SoCs cpufreq: sun50i: add Allwinner H700 speed bin cpufreq/cppc: Don't compare desired_perf in target() OPP: ti: Fix ti_opp_supply_probe wrong return values cpufreq: ti-cpufreq: Handle deferred probe with dev_err_probe() cpufreq: dt-platdev: add missing MODULE_DESCRIPTION() macro cpufreq: longhaul: Fix kernel-doc param for longhaul_setstate cpufreq: qcom-nvmem: eliminate uses of of_node_put() cpufreq: qcom-nvmem: fix memory leaks in probe error paths cpufreq: scmi: Avoid overflow of target_freq in fast switch cpufreq: sun50i: replace of_node_put() with automatic cleanup handler ...

cpufreq: Make cpufreq_driver->exit() return void

2024-07-09T03:15:30Z

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: make cpufreq_boost_enabled() return bool

2024-06-28T18:58:04Z

Since this function is supposed to return boost_enabled which is anyway a bool type make sure that it's return value is also marked as bool. This helps maintain better consistency in data types being used. Signed-off-by: Dhruva Gole Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/20240627060117.1809477-1-d-gole@ti.com Signed-off-by: Rafael J. Wysocki

cpufreq: Add a cpufreq pressure feedback for the scheduler

2024-04-24T10:07:58Z

Provide to the scheduler a feedback about the temporary max available capacity. Unlike arch_update_thermal_pressure(), this doesn't need to be filtered as the pressure will happen for dozens of ms or more. Signed-off-by: Vincent Guittot Signed-off-by: Ingo Molnar Tested-by: Lukasz Luba Reviewed-by: Qais Yousef Reviewed-by: Lukasz Luba Reviewed-by: Dhruva Gole Acked-by: Rafael J. Wysocki Acked-by: Viresh Kumar Link: https://lore.kernel.org/r/20240326091616.3696851-2-vincent.guittot@linaro.org

Merge tag 'soc-late-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2024-03-19T18:57:26Z

Pull more ARM SoC updates from Arnd Bergmann: "These are changes that for some reason ended up not making it into the first four branches but that should still make it into 6.9: - A rework of the omap clock support that touches both drivers and device tree files - The reset controller branch changes that had a dependency on late bugfixes. Merging them here avoids a backmerge of 6.8-rc5 into the drivers branch - The RISC-V/starfive, RISC-V/microchip and ARM/Broadcom devicetree changes that got delayed and needed some extra time in linux-next for wider testing" * tag 'soc-late-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (31 commits) soc: fsl: dpio: fix kcalloc() argument order bus: ts-nbus: Improve error reporting bus: ts-nbus: Convert to atomic pwm API riscv: dts: starfive: jh7110: Add camera subsystem nodes ARM: bcm: stop selecing CONFIG_TICK_ONESHOT ARM: dts: omap3: Update clksel clocks to use reg instead of ti,bit-shift ARM: dts: am3: Update clksel clocks to use reg instead of ti,bit-shift clk: ti: Improve clksel clock bit parsing for reg property clk: ti: Handle possible address in the node name dt-bindings: pwm: opencores: Add compatible for StarFive JH8100 dt-bindings: riscv: cpus: reg matches hart ID reset: Instantiate reset GPIO controller for shared reset-gpios reset: gpio: Add GPIO-based reset controller cpufreq: do not open-code of_phandle_args_equal() of: Add of_phandle_args_equal() helper reset: simple: add support for Sophgo SG2042 dt-bindings: reset: sophgo: support SG2042 riscv: dts: microchip: add specific compatible for mpfs pdma riscv: dts: microchip: add missing CAN bus clocks ARM: brcmstb: Add debug UART entry for 74165 ...

Merge tag 'opp-updates-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm into pm

2024-03-11T15:22:36Z

Merge OPP (operating performance points) updates for 6.9 from Viresh Kumar: "- Fix couple of warnings related to W=1 builds. (Viresh Kumar). - Move Move dev_pm_opp_{init|free}_cpufreq_table() to pm_opp.h (Viresh Kumar). - Extend dev_pm_opp_data with turbo support (Sibi Sankar). - dt-bindings: drop maxItems from inner items (David Heidelberg)." * tag 'opp-updates-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: dt-bindings: opp: drop maxItems from inner items OPP: debugfs: Fix warning around icc_get_name() OPP: debugfs: Fix warning with W=1 builds cpufreq: Move dev_pm_opp_{init|free}_cpufreq_table() to pm_opp.h OPP: Extend dev_pm_opp_data with turbo support

cpufreq: Move dev_pm_opp_{init|free}_cpufreq_table() to pm_opp.h

2024-03-11T05:09:24Z

Move the declaration of functions defined in the OPP core to pm_opp.h. These were added to cpufreq.h as it was the only user of the APIs, but that was a mistake perhaps. Fix it. Signed-off-by: Viresh Kumar

cpufreq: Limit resolving a frequency to policy min/max

2024-02-29T19:21:44Z

Resolving a frequency to an efficient one should not transgress policy->max (which can be set for thermal reason) and policy->min. Currently, there is possibility where scaling_cur_freq can exceed scaling_max_freq when scaling_max_freq is an inefficient frequency. Add a check to ensure that resolving a frequency will respect policy->min/max. Cc: All applicable Fixes: 1f39fa0dccff ("cpufreq: Introducing CPUFREQ_RELATION_E") Signed-off-by: Shivnandan Kumar [ rjw: Whitespace adjustment, changelog edits ] Signed-off-by: Rafael J. Wysocki