linux.git/drivers/thermal/cpu_cooling.c, branch v5.4.228

thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed

2021-01-06T13:48:35+00:00

commit 236761f19a4f373354f1dcf399b57753f1f4b871 upstream.

If state has not changed successfully and we updated cpufreq_state,
next time when the new state is equal to cpufreq_state (not changed
successfully last time), we will return directly and miss a
freq_qos_update_request() that should have been.

Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits")
Cc: v5.4+  # v5.4+
Signed-off-by: Zhuguangqing 
Acked-by: Viresh Kumar 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20201106092243.15574-1-zhuguangqing83@gmail.com
Signed-off-by: Greg Kroah-Hartman

thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power

2020-07-22T07:33:16+00:00

commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream.

The function cpu_power_to_freq is used to find a frequency and set the
cooling device to consume at most the power to be converted. For example,
if the power to be converted is 80mW, and the em table is as follow.
struct em_cap_state table[] = {
	/* KHz     mW */
	{ 1008000, 36, 0 },
	{ 1200000, 49, 0 },
	{ 1296000, 59, 0 },
	{ 1416000, 72, 0 },
	{ 1512000, 86, 0 },
};
The target frequency should be 1416000KHz, not 1512000KHz.

Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power tables")
Cc:  # v4.13+
Signed-off-by: Finley Xiao 
Acked-by: Viresh Kumar 
Reviewed-by: Amit Kucheria 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20200619090825.32747-1-finley.xiao@rock-chips.com
Signed-off-by: Viresh Kumar 
Signed-off-by: Greg Kroah-Hartman

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

thermal/drivers/cpu_cooling: Remove pointless test in power2state()

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

When the static power computation was removed, the test with the power
being negative was not removed. However, the substraction which was
responsible of the negative value was removed and the variable is now
an u32. A double reason to remove the test which does not make sense.

Fixes: 84fe2cab48590 ("cpu_cooling: Drop static-power related stuff")
Cc: Viresh Kumar 
Signed-off-by: Daniel Lezcano 
Acked-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: Remove unused cur_freq variable

2019-03-18T14:11:06+00:00

The 'cur_freq' local variable became unused after commit 84fe2cab4859
("cpu_cooling: Drop static-power related stuff"), let's remove it.

Cc: Amit Daniel Kachhap 
Cc: Viresh Kumar 
Cc: Javi Merino 
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: Daniel Lezcano 
Signed-off-by: Shaokun Zhang 
Acked-by: Viresh Kumar 
Signed-off-by: Zhang Rui