15 Aug, 2013
2 commits
-
In case the trend is not changing or when there is no
request for throttling, it is expected that the instance
would not change its requested target. This patch improves
the code implementation to cover for this expected behavior.With current implementation, the instance will always
reset to cdev.cur_state, even in not expected cases,
like those mentioned above.This patch changes the step_wise governor implementation
of get_target so that we accomplish:
(a) - default value will be current instance->target, so
we do not change the thermal instance target unnecessarily.
(b) - the code now it is clear about what is the intention.
There is a clear statement of what are the expected outcomes
(c) - removal of hardcoded constants, now it is put in use
the THERMAL_NO_TARGET macro.
(d) - variable names are also improved so that reader can
clearly understand the difference between instance cur target,
next target and cdev cur_state.Cc: Zhang Rui
Cc: Durgadoss R
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reported-by: Ruslan Ruslichenko
Signed-of-by: Eduardo Valentin
Signed-off-by: Zhang Rui -
The cooling device only needs update on a new target state. Since we
already check old target in thermal_zone_trip_update(), we can do one
more check to see if it's a new target state. If not, we can reasonably
save some uncecesary code execution.Signed-off-by: Shawn Guo
Acked-by: Eduardo Valentin
Signed-off-by: Zhang Rui
14 Apr, 2013
1 commit
-
The thermal governors are part of the thermal framework,
rather than a seperate feature/module.
Because the generic thermal layer can not work without
thermal governors, and it must load the thermal governors
during its initialization.Build them into one module in this patch.
This also fix a problem that the generic thermal layer does not
work when CONFIG_THERMAL=m and CONFIG_THERMAL_GOV_XXX=y.Signed-off-by: Zhang Rui
Acked-by: Eduardo Valentin
Acked-by: Durgadoss R
12 Apr, 2013
1 commit
-
When selecting a target cooling state in get_target_state(), make sure
that the state is at least as high as the minimum when the temperature
is rising and at least as low as the maximum when the temperature is
falling. This is necessary because, in the THREAML_TREND_RAISING and
THERMAL_TREND_DROPPING cases, the current state may only be incremented
or decremented by one even if it is outside the bounds of the thermal
instance. This might occur, for example, if the CPU is heating up
and hits a thermal trip point for the first time when it's frequency
is much higher than the range specified by the thermal instance
corresponding to the trip point.Signed-off-by: Andrew Bresticker
Acked-by: Eduardo Valentin
Signed-off-by: Zhang Rui
04 Jan, 2013
2 commits
-
Signed-off-by: Zhang Rui
-
step_wise governor should set the device cooling state to
upper/lower limit directly when THERMAL_TREND_RAISE/DROP_FULL.Signed-off-by: Zhang Rui
12 Dec, 2012
1 commit
-
Fix DEFAULT_THERMAL_GOVERNOR to be consistant with the
default governor selected in kernel config file.Signed-off-by: Zhang Rui
05 Nov, 2012
2 commits
-
Fixes the following sparse warnings:
drivers/thermal/step_wise.c:153:5: warning:
symbol 'step_wise_throttle' was not declared. Should it be static?
drivers/thermal/step_wise.c:172:25: warning:
symbol 'thermal_gov_step_wise' was not declared. Should it be static?Signed-off-by: Sachin Kamat
Acked-by: Durgadoss R
Signed-off-by: Zhang Rui -
This patch adds a simple step_wise governor to the
generic thermal layer. This algorithm throttles the
cooling devices in a linear fashion. If the 'trend'
is heating, it throttles by one step. And if the
thermal trend is cooling it de-throttles by one step.This actually moves the throttling logic from thermal_sys.c
and puts inside step_wise.c, without any change.Signed-off-by: Durgadoss R
Signed-off-by: Zhang Rui
