lwn.git/drivers/thermal/cpu_cooling.c, branch docs-mw

thermal/drivers/cpu_cooling: Rename to cpufreq_cooling

2020-01-27T09:24:32+00:00

As we introduced the idle injection cooling device called cpuidle_cooling, let's be consistent and rename the cpu_cooling to cpufreq_cooling as this one mitigates with OPPs changes. Signed-off-by: Daniel Lezcano Acked-by: Viresh Kumar Reviewed-by: Amit Kucheria Link: https://lore.kernel.org/r/20191219225317.17158-3-daniel.lezcano@linaro.org

thermal: cpu_cooling: Appease the kernel-doc deity

2020-01-27T09:24:32+00:00

Describe the function parameter to fix the following warning with make W=1: linux.git/drivers/thermal/cpu_cooling.c:92: warning: Function parameter or member 'qos_req' not described in 'cpufreq_cooling_device' Signed-off-by: Amit Kucheria Reviewed-by: Viresh Kumar Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/ddb09e9728533c274edae7ff3da515b3cf7ef231.1574242756.git.amit.kucheria@linaro.org

thermal: cpu_cooling: Migrate to using the EM framework

2019-11-07T06:02:40+00:00

The newly introduced Energy Model framework manages power cost tables in a generic way. Moreover, it supports several types of models since the tables can come from DT or firmware (through SCMI) for example. On the other hand, the cpu_cooling subsystem manages its own power cost tables using only DT data. In order to avoid the duplication of data in the kernel, and in order to enable IPA with EMs coming from more than just DT, remove the private tables from cpu_cooling.c and migrate it to using the centralized EM framework. Doing so should have no visible functional impact for existing users of IPA since: - recent extenstions to the the PM_OPP infrastructure enable the registration of EMs in PM_EM using the DT property used by IPA; - the existing upstream cpufreq drivers marked with the 'CPUFREQ_IS_COOLING_DEV' flag all use the aforementioned PM_OPP infrastructure, which means they all support PM_EM. The only two exceptions are qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which doesn't use DT for power costs. For existing users of cpu_cooling, PM_EM tables will contain the exact same power values that IPA used to compute on its own until now. The only new dependency for them is to compile in CONFIG_ENERGY_MODEL. The case where the thermal subsystem is used without an Energy Model (cpufreq_cooling_ops) is handled by looking directly at CPUFreq's frequency table which is already a dependency for cpu_cooling.c anyway. Since the thermal framework expects the cooling states in a particular order, bail out whenever the CPUFreq table is unsorted, since that is fairly uncommon in general, and there are currently no users of cpu_cooling for this use-case. Acked-by: Daniel Lezcano Acked-by: Viresh Kumar Signed-off-by: Quentin Perret Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20191030151451.7961-5-qperret@google.com

thermal: cpu_cooling: Make the power-related code depend on IPA

2019-11-07T06:02:40+00:00

The core CPU cooling infrastructure has power-related functions that have only one client: IPA. Since there can be no user of those functions if IPA is not compiled in, make sure to guard them with checks on CONFIG_THERMAL_GOV_POWER_ALLOCATOR to not waste space unnecessarily. Acked-by: Daniel Lezcano Acked-by: Viresh Kumar Suggested-by: Daniel Lezcano Signed-off-by: Quentin Perret Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20191030151451.7961-4-qperret@google.com

cpufreq: Use per-policy frequency QoS

2019-10-21T00:05:21+00:00

Replace the CPU device PM QoS used for the management of min and max frequency constraints in cpufreq (and its users) with per-policy frequency QoS to avoid problems with cpufreq policies covering more then one CPU. Namely, a cpufreq driver is registered with the subsys interface which calls cpufreq_add_dev() for each CPU, starting from CPU0, so currently the PM QoS notifiers are added to the first CPU in the policy (i.e. CPU0 in the majority of cases). In turn, when the cpufreq driver is unregistered, the subsys interface doing that calls cpufreq_remove_dev() for each CPU, starting from CPU0, and the PM QoS notifiers are only removed when cpufreq_remove_dev() is called for the last CPU in the policy, say CPUx, which as a rule is not CPU0 if the policy covers more than one CPU. Then, the PM QoS notifiers cannot be removed, because CPUx does not have them, and they are still there in the device PM QoS notifiers list of CPU0, which prevents new PM QoS notifiers from being registered for CPU0 on the next attempt to register the cpufreq driver. The same issue occurs when the first CPU in the policy goes offline before unregistering the driver. After this change it does not matter which CPU is the policy CPU at the driver registration time and whether or not it is online all the time, because the frequency QoS is per policy and not per CPU. Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework") Reported-by: Dmitry Osipenko Tested-by: Dmitry Osipenko Reported-by: Sudeep Holla Tested-by: Sudeep Holla Diagnosed-by: Viresh Kumar Link: https://lore.kernel.org/linux-pm/5ad2624194baa2f53acc1f1e627eb7684c577a19.1562210705.git.viresh.kumar@linaro.org/T/#md2d89e95906b8c91c15f582146173dce2e86e99f Link: https://lore.kernel.org/linux-pm/20191017094612.6tbkwoq4harsjcqv@vireshk-i7/T/#m30d48cc23b9a80467fbaa16e30f90b3828a5a29b Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar

thermal: cpu_cooling: Switch to QoS requests for freq limits

2019-08-10T12:08:03+00:00

The cpufreq core now takes the min/max frequency constraints via QoS requests and the CPUFREQ_ADJUST notifier shall get removed later on. Switch over to using the QoS request for maximum frequency constraint for cpu_cooling driver. Signed-off-by: Viresh Kumar [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki

thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power

2019-05-14T14:00:41+00:00

The CPU load values passed to the thermal_power_cpu_get_power tracepoint are zero for all CPUs, unless, unless the thermal_power_cpu_limit tracepoint is enabled too: irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815 vs irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959 irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit: cpus=0000000f freq=408000 cdev_state=10 power=416 There seems to be no good reason for omitting the CPU load information depending on another tracepoint. My guess is that the intention was to check whether thermal_power_cpu_get_power is (still) enabled, however 'load_cpu != NULL' already indicates that it was at least enabled when cpufreq_get_requested_power() was entered, there seems little gain from omitting the assignment if the tracepoint was just disabled, so just remove the check. Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor") Signed-off-by: Matthias Kaehlcke Reviewed-by: Daniel Lezcano Acked-by: Javi Merino Acked-by: Viresh Kumar Signed-off-by: Eduardo Valentin

thermal/drivers/cpu_cooling: Remove pointless field

2019-05-14T14:00:35+00:00

The structure cpufreq_cooling_device provides a backpointer to the thermal device but this one is used for a trace and to unregister. For the trace, we don't really need this field and the unregister function as the same pointer passed as parameter. Remove it. Acked-by: Viresh Kumar Signed-off-by: Daniel Lezcano Signed-off-by: Eduardo Valentin

thermal/drivers/cpu_cooling: Add Software Package Data Exchange (SPDX)

2019-05-14T14:00:35+00:00

For license auditing purpose, let's add the SPDX tag. Signed-off-by: Daniel Lezcano Acked-by: Viresh Kumar Acked-by: Philippe Ombredanne Signed-off-by: Eduardo Valentin

thermal/drivers/cpu_cooling: Fixup the header and copyright

2019-05-14T14:00:34+00:00

The copyright format does not conform to the format requested by Linaro: https://wiki.linaro.org/Copyright Fix it. Signed-off-by: Daniel Lezcano Acked-by: Viresh Kumar Signed-off-by: Eduardo Valentin