linux.git/drivers/thermal/cpu_cooling.c, branch v4.1.29

thermal: cpu_cooling: fix improper order during initialization

2016-06-17T13:44:02+00:00

[ Upstream commit f840ab18bdf2e415dac21d09fbbbd2873111bd48 ]

The freq_table array is not populated before calling
thermal_of_cooling_register. The code which populates the freq table was
introduced in commit f6859014.
This should be done before registering new thermal cooling device.
The log shows effects of this wrong decision.
[    2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34
[    2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34

Cc:  # 3.19+
Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order")
Signed-off-by: Lukasz Luba 
Acked-by: Javi Merino 
Acked-by: Viresh Kumar 
Signed-off-by: Zhang Rui 
Signed-off-by: Sasha Levin

thermal/cpu_cooling: rename cpufreq_val as clipped_freq

2016-06-17T13:43:51+00:00

[ Upstream commit 59f0d21883f39d27f14408d4ca211dce80658963 ]

That's what it is for, lets name it properly.

Signed-off-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Sasha Levin

Merge branches 'thermal-core', 'thermal-soc' and 'thermal-int340x' of .git into next

2014-12-24T02:38:30+00:00

thermal: cpu_cooling: document node in struct cpufreq_cooling_device

2014-12-21T13:40:13+00:00

The node field of struct cpufreq_cooling_device was reintroduced in
2dcd851fe4b4 (thermal: cpu_cooling: Update always cpufreq policy with
thermal constraints) but without the documentation that it once had.
Add it back so that all the fields of struct cpufreq_cooling_device
are documented.

Cc: Yadwinder Singh Brar 
Cc: Eduardo Valentin 
Cc: Zhang Rui 
Signed-off-by: Javi Merino 
Signed-off-by: Zhang Rui

thermal: cpu_cooling: small memory leak on error

2014-12-17T12:54:04+00:00

There was a left over return here so the error handling isn't run.
It leads to a small memory leak and a static checker warning.

	drivers/thermal/cpu_cooling.c:351 __cpufreq_cooling_register()
	info: ignoring unreachable code.

Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order")
Acked-by: Viresh Kumar 
Signed-off-by: Dan Carpenter 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: update copyright tags

2014-12-08T18:12:37+00:00

Adding my copyright information for two purposes:
- To get cc'd for future patches to review (Only if people read this header
  while sending mail)
- Have done enough changes to earn a place here?

Cc: Amit Daniel Kachhap 
Signed-off-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: Use cpufreq_dev->freq_table for finding level/freq

2014-12-08T18:11:54+00:00

get_property() was an over complicated beast with BUGs. It used to believe that
cpufreq table is present in ascending or descending order, which might not
always be true.

Previous patch has created another freq table in descending order for us and we
better use it now. With that get_property() simply goes away and another helper
get_level() comes in.

Signed-off-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: Store frequencies in descending order

2014-12-08T18:11:02+00:00

CPUFreq framework *doesn't* guarantee that frequencies present in cpufreq table
will be in ascending or descending order. But cpu_cooling somehow assumes that.

Probably because most of current users are creating this list from DT, which is
done with the help of OPP layer. And OPP layer creates the list in ascending
order of frequencies.

But cpu_cooling can be used for other platforms too, which don't have
frequencies arranged in any order.

This patch tries to fix this issue by creating another list of valid frequencies
in descending order. Care is also taken to throw warnings for duplicate entries.

Later patches would use it to simplify code.

Signed-off-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: Pass 'cpufreq_dev' to get_property()

2014-12-08T18:10:08+00:00

We already know the value of 'cpufreq_dev->max_level' and so there is no need
calculating that once again. For this, we need to send 'cpufreq_dev' to
get_property().

Make all necessary changes for this change. Because cpufreq_cooling_get_level()
doesn't have access to 'cpufreq_dev', it is updated to iterate over the list of
cpufreq_cooling_devices to get cooling device for the cpu number passed to it.
This also makes it robust to return levels only for the CPU registered via a
cooling device. We don't have to support anything that isn't registered yet.

Signed-off-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: use cpufreq_dev_list instead of cpufreq_dev_count

2014-12-08T18:09:15+00:00

As we already have a list of cpufreq_cooling_devices now, lets use it instead of
a local counter.

Signed-off-by: Viresh Kumar 
Signed-off-by: Eduardo Valentin