We aren't supposed to return our own error type here. Return what we got.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
ret is initialized before it is used, so no need to set it to 0 in its declaration.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
It will be overwritten soon with return value of kzalloc().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This wasn't explained well anywhere and should be clearly specified. Lets add a
top level comment for this.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
cooling_cpufreq_lock isn't used to protect this structure and so the comment
over it is outdated. Fix it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
cpufreq_cooling_register() expects mask of all the CPUs where frequency
constraint is applicable.
This platform has more than one CPU to which these constraints will apply and so
passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a
single cluster of CPUs and the constraint applies to all CPUs.
If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework
isn't aware of any siblings sharing clock line.
Fix it by passing cpu_present_mask to cpufreq_cooling_register().
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
cpufreq_cooling_register() expects mask of all the CPUs where frequency
constraint is applicable.
This platform has more than one CPU to which these constraints will apply and so
passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a
single cluster of CPUs and the constraint applies to all CPUs.
If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework
isn't aware of any siblings sharing clock line.
Fix it by passing cpu_present_mask to cpufreq_cooling_register().
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
cpufreq_cooling_register() expects mask of all the CPUs where frequency
constraint is applicable.
This platform has more than one CPU to which these constraints will apply and so
passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a
single cluster of CPUs and the constraint applies to all CPUs.
If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework
isn't aware of any siblings sharing clock line.
Fix it by passing cpu_present_mask to cpufreq_cooling_register().
Cc: Hongbo Zhang <hongbo.zhang@linaro.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
In this patch, the cpu_cooling code checks for the usability of cpufreq
layer before proceeding with the CPU cooling device registration. The
main reason is: CPU cooling device is not usable if cpufreq cannot
switch frequencies.
Similar checks are spread in thermal drivers. Thus, the advantage now
is to have the check in a single place: cpu cooling device registration.
For this reason, this patch also updates the existing drivers that
depend on CPU cooling to simply propagate the error code of the cpu
cooling registration call. Therefore, in case cpufreq is not ready, the
thermal drivers will still return -EPROBE_DEFER, in an attempt to try
again when cpufreq layer gets ready.
Cc: devicetree@vger.kernel.org
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
thermal_unregister_governors() and class_unregister() were being called in
the wrong order.
Fixes: 80a26a5c22 ("Thermal: build thermal governors into thermal_sys module")
Cc: stable@vger.kernel.org
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Currently, userspace can request a governor change while the governor
itself is running. Grab the thermal zone lock when changing the
governor to prevent this race.
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Ignore invalid trip temperature less or equal to zero. Some
buggy systems have invalid trips, causing system shutdown.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The Armada 375 Z1 SoC revision is no longer supported. This commit
removes the quirk needed for the thermal sensor.
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Thermal is TS-ADC Controller module supports
user-defined mode and automatic mode.
User-defined mode refers,TSADC all the control signals entirely by
software writing to register for direct control.
Automaic mode refers to the module automatically poll TSADC output,
and the results were checked.If you find that the temperature High
in a period of time,an interrupt is generated to the processor
down-measures taken;If the temperature over a period of time High,
the resulting TSHUT gave CRU module,let it reset the entire chip,
or via GPIO give PMIC.
Signed-off-by: zhaoyifeng <zyf@rock-chips.com>
Signed-off-by: Caesar Wang <caesar.wang@rock-chips.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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 <elfring@users.sourceforge.net>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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 <maxime.coquelin@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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 <yadi.brar@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
There is no longer need to share defines between exynos_tmu.c
and exynos_tmu_data.c (as they are now only used by the former
file) so move them accordingly. Then move externs for struct
exynos_tmu_init_data instances to exynos_tmu.h and remove no
longer needed exynos_tmu_data.h include.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
__EXYNOS5420_TMU_DATA macro is now identical to __EXYNOS5260_TMU_DATA
one and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Maximum theoretical size saving (i.e. with only Exynos5410
SoC support enabled in kernel config so all SoC dependend
Exynos thermal driver code was dropped) is 4096 bytes so
there is no much sense in keeping these ifdefs (especially
given that they are useless once the driver gets updated to
use device tree).
While at it remove needless 'void *' casts.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace pdata->test_mux check in get_con_reg() by explicitly
checking for SoC type.
Also since the used pdata->test_mux value is always identical
use it directly and remove pdata->test_mux completely.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Remove unused TMU_SUPPORT_MULTI_INST flag, no longer
needed TMU_SUPPORTS() macro and features field from
struct exynos_tmu_platform_data.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace TMU_SUPPORT_ADDRESS_MULTIPLE flag check in exynos_map_dt_data()
by an explicit check for a SoC type (only Exynos5420 with TRIMINFO
quirk and Exynos5440 have TMU_SUPPORT_ADDRESS_MULTIPLE flag set in
their struct exynos_tmu_init_data instances).
Please note that this requires moving SoC type assignment and verification
from exynos_tmu_probe() to exynos_map_dt_data() so it happens earlier
(which is a good thing in itself).
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace TMU_SUPPORT_EMULATION flag check in exynos_tmu_set_emulation()
by an explicit check for a SoC type (all SoC types except Exynos4210
have TMU_SUPPORT_EMULATION flag set in their struct exynos_tmu_init_data
instances).
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace TMU_SUPPORT_EMUL_TIME flag check in get_emul_con_reg()
by an explicit check for a SoC type (all SoC types except
Exynos4210 and Exynos5440 have TMU_SUPPORT_EMUL_TIME flag set
in their struct exynos_tmu_init_data instances).
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace TMU_SUPPORT_FALLING_TRIP flag check in
exynos[4210,5440]_tmu_control() by an explicit check
for a SoC type (all SoC types except Exynos4210 have
TMU_SUPPORT_FALLING_TRIP flag set in their struct
exynos_tmu_init_data instances).
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add ->tmu_clear_irqs method to struct exynos_tmu_data and use
it instead exynos_tmu_clear_irqs(). Then add ->tmu_clear_irqs
implementations for Exynos4210+ and Exynos5440. Finally
remove no longer needed reg->tmu_int[stat,clear] abstractions
and struct exynos_tmu_registers instances.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add ->tmu_set_emulation method to struct exynos_tmu_data and
use it in exynos_tmu_set_emulation(). Then add ->tmu_set_emulation
implementations for Exynos4412+ and Exynos5440. Finally remove
no longer needed reg->emul_con abstraction.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Factor out code for preparing EMUL_CON register value from
exynos_tmu_set_emulation() into get_emul_con_reg().
This is a preparation for introducing per-SoC type
tmu_set_emulation method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add ->tmu_read method to struct exynos_tmu_data and use it
in exynos_tmu_control(). Then add ->tmu_read implementations
for Exynos4210, Exynos4412+ and Exynos5440. Finally remove
no longer needed reg->tmu_cur_temp abstractions.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add ->tmu_control method to struct exynos_tmu_data and use it
in exynos_tmu_control(). Then add ->tmu_control implementations
for Exynos4210+ and Exynos5440. Finally remove no longer needed
reg->tmu_[ctrl,inten], reg->inten_rise[0,1,2,3]_shift and
reg->inten_fall0_shift abstractions.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Factor out code for preparing TMU_CONTROL register value from
exynos_tmu_control() into get_con_reg().
This is a preparation for introducing per-SoC type tmu_control
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add ->tmu_initialize method to struct exynos_tmu_data and
use it in exynos_tmu_initialize(). Then add ->tmu_initialize
implementations for Exynos4210, Exynos4412+ and Exynos5440.
Finally remove no longer needed reg->threshold_th[0,1],
reg->intclr_[fall,rise]_shift and reg->intclr_[rise,fall]_mask
abstractions.
There are more improvements available in the future on top
of this patch like merging HW_TRIP level setting with setting
of other levels for Exynos4412+ or adding separate method
for clearing IRQs using INTCLEAR register (for Exynos5420,
Exynos5260 and Exynos4412+).
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Factor out code for preparing threshold register value from
exynos_tmu_initialize() into get_th_reg().
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Factor out code for initializing data->temp_error[1,2] values
from exynos_tmu_initialize() into sanitize_temp_error().
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace TMU_SUPPORT_TRIM_RELOAD flag check in exynos_tmu_initialize()
by an explicit check for a SoC type (only Exynos3250, Exynos4412 and
Exynos5250 have TMU_SUPPORT_READY_STATUS flag set in their struct
exynos_tmu_init_data instances). Please note that this requires
adding separate SoC type for Exynos5420 so it doesn't get mistaken
with Exynos5250.
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace TMU_SUPPORT_READY_STATUS flag check in
exynos_tmu_initialize() by an explicit check for a SoC type
(all SoC types except Exynos5440 have TMU_SUPPORT_READY_STATUS
flag set in their struct exynos_tmu_init_data instances).
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Replace pdata->threshold_falling check for non-zero value in
exynos_tmu_initialize() by an explicit check for a SoC type
(all SoC types except Exynos5440 have pdata->threshold_falling
assigned to non-zero value in their struct exynos_tmu_registers
instances).
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Simplify HW_TRIP level setting in exynos_tmu_initialize() (don't
pretend that the current code is hardware and configuration
independent and just do SoC type check explicitly). Then remove
no longer needed reg->threshold_[th2,th3_l0_shift] abstractions
(only assigned for Exynos5440 in exynos5440_tmu_registers) and
EXYNOS_MAX_TRIGGER_PER_REG define.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->tmu_pmin is set to non-zero value only for Exynos5440
so replace check for non-zero value of reg->tmu_pmin by
explicitly checking for Exynos5440 SoC type. Then remove no
longer needed reg->tmu_pmin register abstraction.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->tmu_irqstatus is set to non-zero value only for Exynos5440
so replace check for non-zero value of reg->tmu_irqstatus by
explicitly checking for Exynos5440 SoC type. Then remove no
longer needed reg->tmu_irqstatus register abstraction.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->emul_time_shift is used only in exynos_tmu_set_emulation()
and accessed only if TMU_SUPPORT_EMUL_TIME flag is set. This
flag is not set for Exynos4210 and Exynos5440 (reg->emul_time_shift
field is not even assigned in exynos[4210,5440]_tmu_registers
and is assigned to identical value for all other SoC types) so
the abstraction is not needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->emul_temp_shift is used only in exynos_tmu_set_emulation()
and accessed only if TMU_SUPPORT_EMULATION flag is set. This
flag is not set for Exynos4210 (reg->emul_temp_shift field is
not even assigned in exynos4210_tmu_registers and is assigned
to identical value for all other SoC types) so the abstraction
is not needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->therm_trip_en_shift is used only in exynos_tmu_initialize()
and not accessed on Exynos4210 (also reg->therm_trip_en_shift is
not even assigned in exynos4210_tmu_registers but it is assigned
to identical value for all other SoC types) so the register
abstraction is not needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->therm_trip_mode_shift and reg->therm_trip_mode_mask are
used only in exynos_tmu_control() and accessed only if
pdata->noise_cancel_mode is non-zero. pdata->noise_cancel
field is not defined on Exynos4210 (also therm_trip_mode_shift
and therm_trip_mode_mask entries are not even assigned in
exynos4210_tmu_registers but they are assigned to identical
values for all other SoC types) so the abstractions are not
needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->test_mux_addr_shift is used only if pdata->test_mux is
non-zero. pdata->test_mux is defined only on Exynos3250 and
Exynos4412 (other SoC types don't even have pdata->test_mux
entry assigned in their struct exynos_tmu_registers instances)
so the abstraction is not needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->triminfo_ctrl[] is used in only exynos_tmu_initialize() and
accessed only if TMU_SUPPORT_TRIM_RELOAD flag is set. This flag
is set only on Exynos3250, Exynos4412 and Exynos5250 (other SoC
types don't even have triminfo_ctrl[] entries assigned in their
struct exynos_tmu_registers instances) so the register abstraction
is not needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->threshold_temp is used only in exynos_tmu_initialize() and
is accessed only on Exynos4210 (other SoC types don't even have
threshold_temp entry assigned in their struct exynos_tmu_registers
instances) so the register abstraction is not needed and can be
removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->tmu_status is used only in exynos_tmu_initialize() and it
is accessed only if TMU_SUPPORT_READY_STATUS flag is set. This
flag is not set for Exynos5440 and TMU_STATUS register offset
is identical for all other SoC types so the abstraction is not
needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
reg->triminfo_data is used only in exynos_tmu_initialize() and
the code has already different paths for Exynos5440 and other
SoC types (on which TRIMINFO_DATA register offset is identical)
so the register abstraction is not needed and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Different drivers request API extensions in of-thermal. For this reason,
additional callbacks are required to fit the new drivers needs.
The current API implementation expects the registering sensor driver
to provide a get_temp and get_trend callbacks as function parameters.
As the amount of callbacks is growing, this patch changes the existing
implementation to use a .ops field to hold all the of thermal callbacks
to sensor drivers.
This patch also changes the existing of-thermal users to fit the new
API design. No functional change is introduced in this patch.
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: lm-sensors@lm-sensors.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Mikko Perttunen <mikko.perttunen@kapsi.fi>
Reviewed-by: Mikko Perttunen <mikko.perttunen@kapsi.fi>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. This initial driver supports
temperature polling for four thermal zones.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This patch introduces a new thermal cooling device based on common clock
framework. The original motivation to write this cooling device is to be
able to cool down thermal zones using clocks that feed co-processors, such
as GPUs, DSPs, Image Processing Co-processors, etc. But it is written
in a way that it can be used on top of any clock.
The implementation is pretty straight forward. The code creates
a thermal cooling device based on a pair of a struct device and a clock name.
The struct device is assumed to be usable by the OPP layer. The OPP layer
is used as source of the list of possible frequencies. The (cpufreq) frequency
table is then used as a map from frequencies to cooling states. Cooling
states are indexes to the frequency table.
The logic sits on top of common clock framework, specifically on clock
pre notifications. Any PRE_RATE_CHANGE is hijacked, and the transition is
only allowed when the new rate is within the thermal limit (cooling state -> freq).
When a thermal cooling device state transition is requested, the clock
is also checked to verify if the current clock rate is within the new
thermal limit.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Len Brown <len.brown@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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 <heiner.kallweit@web.de>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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 <ch.naveen@samsung.com>
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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 <b51503@freescale.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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 <tianyu.lan@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
result is always zero when comes here.
Signed-off-by: Yao Dongdong <yaodongdong@huawei.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
* 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 <amit.daniel@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Here on function return all temporarily used device nodes shall
decrement their usage counter. The problems are found with device
nodes allocated by for_each_child_of_node(), of_parse_phandle()
and of_find_node_by_name(), fix all problems at once.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: devicetree@vger.kernel.org
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This patch add support for TRIM_RELOAD feature at Exynos3250. The TMu of
Exynos3250 has two TRIMINFO_CON register and must need to set RELOAD bit
before reading TRIMINFO register.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Reviewed-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This patch support many TRIMINFO_CTRL registers if specific Exynos SoC
has one more TRIMINFO_CTRL registers. Also this patch uses proper 'RELOAD'
shift/mask bit operation to set RELOAD feature instead of static value.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Reviewed-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Currently these SoCs claim TRIM_RELOAD support but don't have
triminfo_ctrl register address defined in their struct
exynos_tmu_registers entries. This causes incorrect write of
value "1" to data->base + 0x00 address (which happens to be
TRIMINFO register). Additionally according to the documentation
that I have neither Exynos5260 nor Exynos5420 support/require
TRIM_RELOAD feature. Thus fix the aforementioned issue by
removing TMU_SUPPORT_TRIM_RELOAD flag for both Exynos5260 and
Exynos5420.
Cc: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Cc: Amit Daniel Kachhap <amit.daniel@samsung.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
There is no need for abstracting configuration for registers that
are identical on all SoC types.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
pdata->reference_voltage and pdata->gain are always defined
to non-zero values so remove the redundant checks from
exynos_tmu_control().
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Cache number of non-hardware trigger levels in a new pdata field
(non_hw_trigger_levels) and convert code in exynos_tmu_initialize()
accordingly.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
* Remove dead temp check from temp_to_code() (this function users
in exynos_tmu_initialize() always pass correct temperatures and
exynos_tmu_set_emulation() returns early for EXYNOS4210 because
TMU_SUPPORT_EMULATION flag is not set on this SoC).
* Move temp_code check from code_to_temp() to exynos_tmu_read()
(code_to_temp() only user).
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Remove runtime checks for negative return values of temp_to_code()
from exynos_tmu_initialize().
The current level temperature data hardcoded in pdata will never
cause a negative temp_to_code() return values and checking itself
is not proper. The checks in question are done at runtime in
a production code for data that is hardcoded inside driver during
development time and later it doesn't change. Such data should
be verified during development and review time (i.e. by a script
parsing relevant data from exynos_tmu_data.c, one can also argue
that verification to be done is so simple that the review by
a maintainer should be enough).
Theres should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Remove runtime checks for pdata sanity from exynos_tmu_initialize().
The current values hardcoded in pdata will never trigger the checks
and checking itself is not proper. The checks in question are done
at runtime in a production code for data that is hardcoded inside
driver during development time and later it doesn't change. Such
data should be verified during development and review time (i.e. by
a script parsing relevant data from exynos_tmu_data.c, one can also
argue that verification to be done is so simple that the review by
a maintainer should be enough).
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
The commit 1928457 ("thermal: exynos: Add hardware mode thermal
calibration support") has added HW_MODE feature but it has never
been enabled. As such it has been a dead code for over a year
now and should be removed from the kernel.
We don't keep the unused/untested features in the kernel just
in case that some future hardware might need it. Such code has
a real maintainance cost (all other code changes have to take
the dead code into account) and usually makes future changes
more difficult, not easier (i.e. recent additions of Exynos5420
SoC and Exynos5260 SoC thermal support has not made use of any
of the driver's currently unused/untested features, moreover
the recently added code is more complex than needed because of
the existing dead code). Also all removed dead code is still
accessible in the kernel git repository and can be easily
brought back if/when needed.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Remove unused / write-only entries from struct exynos_tmu_registers.
Then remove unused defines while at it.
We don't keep the unused/untested features in the kernel just
in case that some future hardware might need it. Such code has
a real maintainance cost (all other code changes have to take
the dead code into account) and usually makes future changes
more difficult, not easier (i.e. recent additions of Exynos5420
SoC and Exynos5260 SoC thermal support has not made use of any
of the driver's currently unused/untested features, moreover
the recently added code is more complex than needed because of
the existing dead code). Also all removed dead code is still
accessible in the kernel git repository and can be easily
brought back if/when needed.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Pull thermal management updates from Zhang Rui:
"Sorry that I missed the merge window as there is a bug found in the
last minute, and I have to fix it and wait for the code to be tested
in linux-next tree for a few days. Now the buggy patch has been
dropped entirely from my next branch. Thus I hope those changes can
still be merged in 3.18-rc2 as most of them are platform thermal
driver changes.
Specifics:
- introduce ACPI INT340X thermal drivers.
Newer laptops and tablets may have thermal sensors and other
devices with thermal control capabilities that are exposed for the
OS to use via the ACPI INT340x device objects. Several drivers are
introduced to expose the temperature information and cooling
ability from these objects to user-space via the normal thermal
framework.
From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui.
- introduce a new thermal governor, which just uses a hysteresis to
switch abruptly on/off a cooling device. This governor can be used
to control certain fan devices that can not be throttled but just
switched on or off. From: Peter Feuerer.
- introduce support for some new thermal interrupt functions on
i.MX6SX, in IMX thermal driver. From: Anson, Huang.
- introduce tracing support on thermal framework. From: Punit
Agrawal.
- small fixes in OF thermal and thermal step_wise governor"
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits)
Thermal: int340x thermal: select ACPI fan driver
Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs
Thermal: int340x_thermal: expose acpi thermal relationship tables
Thermal: introduce int3403 thermal driver
Thermal: introduce INT3402 thermal driver
Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h
ACPI / Fan: support INT3404 thermal device
ACPI / Fan: add ACPI 4.0 style fan support
ACPI / fan: convert to platform driver
ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant
ACPI / fan: remove no need check for device pointer
ACPI / fan: remove unused macro
Thermal: int3400 thermal: register to thermal framework
Thermal: int3400 thermal: add capability to detect supporting UUIDs
Thermal: introduce int3400 thermal driver
ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package()
ACPI: make acpi_create_platform_device() an external API
thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
ACPI: introduce ACPI int340x thermal scan handler
thermal: Added Bang-bang thermal governor
...
we share the same driver for both ACPI predefined Fan device
and INT3404 Fan device, thus we should select the ACPI Fan
driver when int340x thermal drivers are enabeld.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The kernel used to contain two functions for length-delimited,
case-insensitive string comparison, strnicmp with correct semantics and
a slightly buggy strncasecmp. The latter is the POSIX name, so strnicmp
was renamed to strncasecmp, and strnicmp made into a wrapper for the new
strncasecmp to avoid breaking existing users.
To allow the compat wrapper strnicmp to be removed at some point in the
future, and to avoid the extra indirection cost, do
s/strnicmp/strncasecmp/g.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ACPI _TRT and _ART parsing code has been moved to acpi_thermal_rel such
that it can be used by other devices in the future. Use the parsing APIs
in acpi_thermal_rel.c instead.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ACPI 4.0 introduced two thermal relationship tables via _ART
(active cooling) and _TRT (passive cooling) objects. These
tables contain many to many relationships among thermal sensors
and cooling devices.
This patch parses _ART and _TRT and makes the result available to
the userspace via an misc device interface. At the same time,
kernel drivers can also request parsing results from internal
kernel APIs.
The results include source and target devices, influence, and
sampling rate in case of _TRT. For _ART, the result shows source
device, target device, and weight percentage.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ACPI INT3403 device object can be used to retrieve temperature date
from temperature sensors present in the system, and to expose
device' performance control.
The previous INT3403 thermal driver supports temperature reporting only,
thus remove it and introduce this new & enhanced one.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ACPI INT3402 device object could report temperature for the memory module.
To expose such information to user space, a thermal zone device is registered
for it so that the thermal sysfs interface can expose such information for
userspace to use.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Introduce int3400 thermal driver. And make INT3400 driver
enumerate the other int340x thermal components shown in _ART/_TRT.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
It turns out that some boards can have instance->lower greater than 0 and
when thermal trend is dropping it results with next_target equal to -1.
Since the next_target is defined as unsigned long it is interpreted as
0xFFFFFFFF and larger than instance->upper.
As a result the next_target is set to instance->upper which ramps up to
maximal cooling device target when the temperature is steadily decreasing.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Newer laptops and tablets that use ACPI may have thermal sensors and
other devices with thermal control capabilities outside the core CPU/SOC,
for thermal safety reasons.
They are exposed for the OS to use via
1) INT3400 ACPI device object as the master.
2) INT3401 ~ INT340B ACPI device objects as the slaves.
This patch introduces a scan handler to enumerate the INT3400
ACPI device object to platform bus, and prevent its slaves
from being enumerated before the controller driver being probed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
mach-kirkwood has been removed, now that kirkwood lives in mach-mvebu.
Depend on MACH_KIRKWOOD, which will be set when kirkwood is built as
part of ARCH_MVEBU.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Link: https://lkml.kernel.org/r/1409417172-6846-4-git-send-email-andrew@lunn.ch
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The bang-bang thermal governor uses a hysteresis to switch abruptly on
or off a cooling device. It is intended to control fans, which can
not be throttled but just switched on or off.
Bang-bang cannot be set as default governor as it is intended for
special devices only. For those special devices the driver needs to
explicitely request it.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Javi Merino <javi.merino@arm.com>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Peter Feuerer <peter@piie.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
i.MX6SX has some new features of thermal interrupt function,
there are LOW, HIGH and PANIC irq for thermal sensor, so add
platform data to separate different thermal version;
The reset value of LOW ALARM is 0 which means the highest
temp, so the LOW ALARM will be triggered once irq is enabled,
so we need to correct it before enabling thermal irq;
Enable PANIC ALARM as critical trip point, it will trigger
system reset via SRC module once PANIC IRQ is triggered, it
is pure hardware function, so use it instead of software
reset by cooling device.
Signed-off-by: Anson Huang <b20788@freescale.com>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add support to check status of the thermal zone before registering the
zone. This will help on disabling some non-existing thermal zone from
the top level DTS file out of common dtsi thermalzone file.
For example,
we have 3 platforms almost same but thermal zones on this platform are
little bit different. Platform 1 and 2 have three thermal zones and
platform 3 has two thermal zones. To avoid duplication of the thermal
zones entries on each DTS file of platforms,we created one common
dtsi file for thermal zone and included this dtsi file from these
3 platform's top level dts file.
On common thermal zone com dtsi file, all thermal zone are enabled and
need to disable one of thermal zone on platform 3 dts file. For this, we
just added entry status = "disabled" for that thermal zone on platform 3
dts file and along with this change to make it work.
This way, we reuse the common file and control the enable/disable of the
thermal zone from top level dts file.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Create a new event to trace when the temperature is above a trip
point. Use the trace-point when handling non-critical and critical
trip pionts.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Introduce and use an event to trace when a cooling device's state is
updated. This is useful to follow the effect of governor decisions on
cooling devices.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Create a new event to trace the temperature of a thermal zone. Using
this event trace the temperature changes of the thermal zone every-time
it is updated.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Viresh Kumar