linux-stable.git/drivers/thermal, branch v3.18.2

thermal: Fix error path in thermal_init()

2015-01-08T18:30:24+00:00

commit 9d367e5e7b05c71a8c1ac4e9b6e00ba45a79f2fc upstream.

thermal_unregister_governors() and class_unregister() were being called in
the wrong order.

Fixes: 80a26a5c22b9 ("Thermal: build thermal governors into thermal_sys module")
Signed-off-by: Luis Henriques 
Signed-off-by: Zhang Rui 
Signed-off-by: Greg Kroah-Hartman

thermal: Exynos: Deletion of unnecessary checks before two function calls

2014-11-21T19:20:17+00:00

The functions cpufreq_cooling_unregister() and thermal_zone_device_unregister()
test whether their argument is NULL and then return immediately.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
Signed-off-by: Eduardo Valentin

thermal: sti: Ignore suspend/resume functions when !PM_SLEEP

2014-11-21T18:27:37+00:00

Prevents build warning:

st_thermal.c:278:12:
    warning: ‘st_thermal_suspend’ defined but not used [-Wunused-function]
st_thermal.c:286:12:
    warning: ‘st_thermal_resume’ defined but not used [-Wunused-function]

Acked-by: Maxime Coquelin 
Signed-off-by: Lee Jones 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: Update always cpufreq policy with thermal constraints

2014-11-20T22:17:11+00:00

Existing code updates cupfreq policy only while executing
cpufreq_apply_cooling() function (i.e. when notify_device != NOTIFY_INVALID).
It doesn't apply constraints when cpufreq policy update happens from any other
place but it should update the cpufreq policy with thermal constraints every
time when there is a cpufreq policy update, to keep state of
cpufreq_cooling_device and max_feq of cpufreq policy in sync. For instance
while resuming cpufreq updates cpufreq_policy and it restores default
policy->usr_policy values irrespective of cooling device's cpufreq_state since
notification gets missed because (notify_device == NOTIFY_INVALID).
Another problem, is that userspace is able to change max_freq irrespective of
cooling device's state, as notification gets missed.

This patch modifies code to maintain a global cpufreq_dev_list and applies
constraints of all matching cooling devices for policy's cpu when there is any
policy update(ends up applying the lowest max_freq among the matching cpu
cooling devices).

This patch also removes redundant check (max_freq > policy->user_policy.max),
as cpufreq framework takes care of user_policy constraints already where ever
required, otherwise its causing an issue while increasing max_freq in normal
scenerio as it restores max_freq with policy->user_policy.max which is old
(smaller) value.

Signed-off-by: Yadwinder Singh Brar 
Signed-off-by: Eduardo Valentin

imx: thermal: imx_get_temp might be called before sensor clock is prepared

2014-11-09T19:42:53+00:00

imx_get_temp might be called before the sensor clock is prepared
thus resulting in a timeout of the first attempt to read temp:
thermal thermal_zone0: failed to read out thermal zone 0
Happened to me on a Utilite Standard with IMX6 Dual SoC.

Reason is that in imx_thermal_probe thermal_zone_device_register
is called before the sensor clock is prepared.
thermal_zone_device_register however calls
thermal_zone_device_update which eventually calls imx_get_temp.

Fix this by preparing the clock before calling
thermal_zone_device_register.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Eduardo Valentin

thermal: exynos: use correct offset for TMU_CONTROL register on Exynos5260

2014-11-07T18:52:42+00:00

In exynos5260_tmu_registers tmu_ctrl entry is erroneously
assigned twice.  The second assignment (to EXYNOS_TMU_REG_CONTROL1
define which represents 0x24 value) overrides the first one
(to EXYNOS_TMU_REG_CONTROL define which represents 0x20 value)
which results in the wrong (according to the Exynos5260 SoC
documentation that I have) offset being used for TMU_CONTROL
register.  Fix it by removing the wrong assignment and then
remove no longer used EXYNOS_TMU_REG_CONTROL1 define.

Cc: Naveen Krishna Chatradhi 
Cc: Amit Daniel Kachhap 
Cc: Lukasz Majewski 
Cc: Eduardo Valentin 
Cc: Zhang Rui 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Acked-by: Kyungmin Park 
Signed-off-by: Eduardo Valentin

thermal: imx: correct driver load sequence for cpu cooling

2014-11-07T18:44:41+00:00

thermal driver should be regisetered after cpufreq driver has
been registered and probed. Doing so is to make sure that thermal
driver can get the max cpu cooling states correctly when calling
get_property.

Signed-off-by: Bai Ping 
Signed-off-by: Eduardo Valentin

Thermal/int3403: Fix thermal hysteresis unit conversion

2014-11-04T23:17:32+00:00

Thermal hysteresis represents a temperature difference.
But the original code treats it as a temperature value,
Convert it from tenths of degree Kelvin to Milli-Celsius
by deducing 273200. This is not right.

Kelvin and Celsius have same degree size. From temperature
difference view, the conversion between tenths of degree
Kelvin unit and Milli-Celsius unit is just to multiply 100.

Signed-off-by: Lan Tianyu 
Acked-by: Srinivas Pandruvada 
Signed-off-by: Zhang Rui 
Signed-off-by: Eduardo Valentin

Thermal:Remove usless if(!result) before return tz

2014-11-03T22:59:50+00:00

result is always zero when comes here.

Signed-off-by: Yao Dongdong 
Acked-by: Eduardo Valentin 
Signed-off-by: Eduardo Valentin

thermal: exynos: fix IRQ clearing on TMU initialization

2014-11-03T03:02:49+00:00

* Factor out code for clearing raised IRQs from exynos_tmu_work() to
  exynos_tmu_clear_irqs().

* Add a comment about documentation bugs to exynos_tmu_clear_irqs().

  [ The documentation for Exynos3250, Exynos4412, Exynos5250 and
    Exynos5260 incorrectly states that INTCLEAR register has
    a different placing of bits responsible for FALL IRQs than
    INTSTAT register.  Exynos5420 and Exynos5440 documentation is
    correct (Exynos4210 doesn't support FALL IRQs at all). ]

* Use exynos_tmu_clear_irqs() in exynos_tmu_initialize() instead
  of open-coded code trying to clear IRQs according to predefined
  masks.  After this change exynos_tmu_initialize() just clears
  IRQs that are raised like it is already done in exynos_tmu_work().

  As a nice side-effect the code now uses the correct offset
  (16 instead of 12) for bits responsible for clearing FALL IRQs
  in INTCLEAR register on Exynos3250, Exynos4412 and Exynos5250.

* Remove no longer needed intclr_rise_[mask,shift] and
  intclr_fall_[mask,shift] fields from struct exynos_tmu_registers.

* Remove no longer needed defines.

This patch has been tested on Exynos4412 and Exynos5420 SoCs.

Cc: Amit Daniel Kachhap 
Cc: Lukasz Majewski 
Cc: Eduardo Valentin 
Cc: Zhang Rui 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Acked-by: Kyungmin Park 
Signed-off-by: Eduardo Valentin