Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
Thanks,
Amit Daniel
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
agree.
patches have been refreshed, please review.
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 22 November 2012 13:42, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
agree.
patches have been refreshed, please review.
Thanks Rui, Your patches looks nice. I will re-base my patches against
your implementation and submit them shortly.
Thanks,
Amit D
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Fri, 2012-11-23 at 09:35 +0530, Amit Kachhap wrote:
On 22 November 2012 13:42, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-22 at 10:11 +0530, Amit Kachhap wrote:
On 22 November 2012 06:52, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support
rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance
*instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type
trip_type)
+ int trip, enum thermal_trip_type
trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
what do you expect to happen if the trend is THERMAL_TREND_RAISE_FULL at
this time?
Hi Rui,
I suppose this is dethrotle routine and hence this will be called when
only drop in temperature happens. Also I did not used get_target_state
here because I thought it might cause regression in the other existing
thermal drivers(I am not sure) But I guess calling get_target_state is
the good way to know next target state and is fine if you agree.
Also one suggestion, 2 functions for throttle/dethrottle can be merged
as both look same and just get_target_state can be used in that
function
agree.
patches have been refreshed, please review.
Thanks Rui, Your patches looks nice. I will re-base my patches against
your implementation and submit them shortly.
great. please rebase your patch on top of thermal-thermal tree.
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Fri, 2012-11-09 at 11:51 +0530, Amit Kachhap wrote:
On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
No actually I was thinking of having a simple governor with a feature
like it only sets to upper level and lower level. Also since the
temperature sensor is capable of interrupting for both increase in
threshold(say 100C) and fall in threshold (say 90C), so polling or
step increments is not needed at all.
Currently stepwise governor governor does that so we might change the
macro name as,
THERMAL_TREND_RAISE_STEP,
THERMAL_TREND_DROP_STEP,
THERMAL_TREND_RAISE_MAX,
THERMAL_TREND_DROP_MAX,
and file step_wise.c can be named as state_wise.c or trend_wise.c.
I am not sure if it is the best way . How do you feel ?
this sounds good to me.
I'd like to see Durga' comments on this as well.
thanks,
rui
what do you think?
thanks,
rui
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance
*instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type
trip_type)
+ int trip, enum thermal_trip_type
trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
Hi Amit/Rui,
-Original Message-
From: Amit Kachhap [mailto:amit.kach...@linaro.org]
Sent: Friday, November 09, 2012 11:52 AM
To: Zhang, Rui
Cc: linux...@lists.linux-foundation.org; linux-samsung-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
quick cooling
On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type
THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
quickly
jump to the upper or lower cooling level instead of incremental
increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which
always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
No actually I was thinking of having a simple governor with a feature
like it only sets to upper level and lower level. Also since the
temperature sensor is capable of interrupting for both increase in
threshold(say 100C) and fall in threshold (say 90C), so polling or
step increments is not needed at all.
Currently stepwise governor governor does that so we might change the
macro name as,
THERMAL_TREND_RAISE_STEP,
THERMAL_TREND_DROP_STEP,
THERMAL_TREND_RAISE_MAX,
THERMAL_TREND_DROP_MAX,
and file step_wise.c can be named as state_wise.c or trend_wise.c.
Yes, in this particular case, we neither need to poll nor do step wise
operations. But, most of the other sensors need at least one of them.
So, I think we can try it this way:
if (sensor supports interrupt) {
'always' use RAISE_MAX and DROP_MAX;
} else {
Do Step wise operations
}
And this could be plugged into step wise. I don't think we need a
complete new governor just to get this case working.
For this to work, we need a way for the governor to know 'whether the
sensor can work on interrupt mode'. May be introducing a new field in
tzd structure can help us here.
I am fine with any name for the governor :-)
Thanks,
Durga
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
Hi Amit/Rui,
-Original Message-
From: Amit Kachhap [mailto:amit.kach...@linaro.org]
Sent: Friday, November 09, 2012 11:52 AM
To: Zhang, Rui
Cc: linux...@lists.linux-foundation.org; linux-samsung-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
quick cooling
On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type
THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
quickly
jump to the upper or lower cooling level instead of incremental
increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which
always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
No actually I was thinking of having a simple governor with a feature
like it only sets to upper level and lower level. Also since the
temperature sensor is capable of interrupting for both increase in
threshold(say 100C) and fall in threshold (say 90C), so polling or
step increments is not needed at all.
Currently stepwise governor governor does that so we might change the
macro name as,
THERMAL_TREND_RAISE_STEP,
THERMAL_TREND_DROP_STEP,
THERMAL_TREND_RAISE_MAX,
THERMAL_TREND_DROP_MAX,
and file step_wise.c can be named as state_wise.c or trend_wise.c.
Yes, in this particular case, we neither need to poll nor do step wise
operations. But, most of the other sensors need at least one of them.
So, I think we can try it this way:
if (sensor supports interrupt) {
'always' use RAISE_MAX and DROP_MAX;
} else {
Do Step wise operations
}
why should the generic thermal layer be aware of this?
IMO, it is the platform thermal driver that is responsible for returning
THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.
and the step_wise governor just takes action based on the return value
of .get_trend() callback.
thanks,
rui
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
-Original Message-
From: Zhang, Rui
Sent: Monday, November 12, 2012 12:03 PM
To: R, Durgadoss
Cc: Amit Kachhap; linux...@lists.linux-foundation.org; linux-samsung-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; l...@kernel.org; linux-
a...@vger.kernel.org; jonghwa3@samsung.com
Subject: RE: [PATCH 1/4] thermal: Add new thermal trend type to support
quick cooling
On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
Hi Amit/Rui,
-Original Message-
From: Amit Kachhap [mailto:amit.kach...@linaro.org]
Sent: Friday, November 09, 2012 11:52 AM
To: Zhang, Rui
Cc: linux...@lists.linux-foundation.org; linux-samsung-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
l...@kernel.org; linux-a...@vger.kernel.org;
jonghwa3@samsung.com
Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to
support
quick cooling
On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type
THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used
to
quickly
jump to the upper or lower cooling level instead of incremental
increase
or decrease.
IMO, what we need is a new more aggressive cooling governor
which
always
uses upper limit when the temperature is raising and lower limit
when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
No actually I was thinking of having a simple governor with a feature
like it only sets to upper level and lower level. Also since the
temperature sensor is capable of interrupting for both increase in
threshold(say 100C) and fall in threshold (say 90C), so polling or
step increments is not needed at all.
Currently stepwise governor governor does that so we might change the
macro name as,
THERMAL_TREND_RAISE_STEP,
THERMAL_TREND_DROP_STEP,
THERMAL_TREND_RAISE_MAX,
THERMAL_TREND_DROP_MAX,
and file step_wise.c can be named as state_wise.c or trend_wise.c.
Yes, in this particular case, we neither need to poll nor do step wise
operations. But, most of the other sensors need at least one of them.
So, I think we can try it this way:
if (sensor supports interrupt) {
'always' use RAISE_MAX and DROP_MAX;
} else {
Do Step wise operations
}
why should the generic thermal layer be aware of this?
IMO, it is the platform thermal driver that is responsible for returning
THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.
and the step_wise governor just takes action based on the return value
of .get_trend() callback.
Yes, agree with the flow ..
Thanks,
Durga
N�r��yb�X��ǧv�^�){.n�+{�x,�ȧ���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
what do you think?
thanks,
rui
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
Hi Rui/Amit,
Sorry for the late response..
-Original Message-
From: Amit Kachhap [mailto:amit.kach...@linaro.org]
Sent: Thursday, November 08, 2012 11:56 AM
To: Zhang, Rui
Cc: linux...@lists.linux-foundation.org; linux-samsung-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
quick cooling
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type
THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which
always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
Yes, this sounds like a feasible and not-so-complicated implementation for now.
In future, if we see a lot of drivers requiring this sudden raise/drop
functionality,
at that time we can introduce an 'aggressive' governor.
Thanks,
Durga
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void
update_instance_for_dethrottle(struct thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature
RE: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
Hi Amit/Rui,
-Original Message-
From: Zhang, Rui
Sent: Friday, November 09, 2012 9:21 AM
To: Amit Kachhap
Cc: linux...@lists.linux-foundation.org; linux-samsung-
s...@vger.kernel.org; linux-ker...@vger.kernel.org; R, Durgadoss;
l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
quick cooling
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type
THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which
always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
what do you think?
I have only one concern here: (mostly on Passive cooling cases)
Setting the cooling state to upper limit will surely help in rapid cooling,
but it will also disrupt the thermal steady state, and the performance might
be jittery.
Let me explain a bit:
On small form factors (like smartphones, tablets, netbooks), when we run
CPU intensive benchmarks, we can easily observe this jittery performance.
The CPU will run in a very high freq for few seconds(which means temperature is
well below trip point), and then switch back to very low frequency in the next
few seconds(which means temperature hit the trip point). This switch will keep
happening for every few seconds. So, the temperature never settles (say for
example,
somewhere in the middle of [low CPU temp, CPU Trip temp].
I could see two reasons for this:
1. The poll delay: Between two successive polls, however small the poll
delay(~20s) may be,
the CPU temperature can raise up to 15C (Just my observation)
2. Sudden passive cooling. The freq switches between HFM and LFM and never
something in between.
That’s why for passive cooling cases, this behavior might not be welcomed
always.
So, I would prefer not to set the cooling state to upper limit always. Instead,
we will
keep the existing behavior but introduce new trend types (something like what
Amit
has done). In this case, the user/tester is explicitly is setting the cooling
trend to
'SUDDEN cooling' which means he/she is 'Ok' with Jitter in performance. Things
are
explicitly said here, which makes it easy to identify performance issues, if
any arise.
In fact, this is one of the reasons, why we have the 'weight' and the
'cur_trip_level'
variables in the fair share governor. Together, both these variables, ensure
that
we do not throttle a cooling device, to more than what is necessary.
I do not think any of this matters for active cooling, where we do not impact
performance :-)
Sorry again for the late response. Thanks both of you for bringing this up..
Thanks,
Durga
thanks,
rui
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance
*instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 9 November 2012 09:21, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
hmmm,
I think a more proper way is to set the cooling state to upper limit
when it overheats and reduce the cooling state step by step when the
temperature drops.
No actually I was thinking of having a simple governor with a feature
like it only sets to upper level and lower level. Also since the
temperature sensor is capable of interrupting for both increase in
threshold(say 100C) and fall in threshold (say 90C), so polling or
step increments is not needed at all.
Currently stepwise governor governor does that so we might change the
macro name as,
THERMAL_TREND_RAISE_STEP,
THERMAL_TREND_DROP_STEP,
THERMAL_TREND_RAISE_MAX,
THERMAL_TREND_DROP_MAX,
and file step_wise.c can be named as state_wise.c or trend_wise.c.
I am not sure if it is the best way . How do you feel ?
what do you think?
thanks,
rui
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device
*tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git
[PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease. This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
I can write such a governor if you do not have time to.
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling
On 8 November 2012 11:31, Zhang Rui rui.zh...@intel.com wrote:
On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
jump to the upper or lower cooling level instead of incremental increase
or decrease.
IMO, what we need is a new more aggressive cooling governor which always
uses upper limit when the temperature is raising and lower limit when
the temperature is dropping.
Yes I agree that a new aggressive governor is the best approach but
then i thought adding a new trend type is a simple solution to achieve
this and since most of the governor logic might be same as the
step-wise governor. I have no objection in doing it through governor.
I can write such a governor if you do not have time to.
ok. thanks
thanks,
rui
This is needed for temperature sensors which support rising/falling
threshold interrupts and polling can be totally avoided.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/step_wise.c | 19 +++
include/linux/thermal.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 1242cff..0d2d8d6 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,6 +35,10 @@
* state for this trip point
*b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
* state for this trip point
+ *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
+ * state for this trip point
+ *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
+ * state for this trip point
*/
static unsigned long get_target_state(struct thermal_instance *instance,
enum thermal_trend trend)
@@ -50,7 +54,10 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
} else if (trend == THERMAL_TREND_DROPPING) {
cur_state = cur_state instance-lower ?
(cur_state - 1) : instance-lower;
- }
+ } else if (trend == THERMAL_TREND_RAISE_FULL)
+ cur_state = instance-upper;
+ else if (trend == THERMAL_TREND_DROP_FULL)
+ cur_state = instance-lower;
return cur_state;
}
@@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct
thermal_zone_device *tz,
}
static void update_instance_for_dethrottle(struct thermal_zone_device *tz,
- int trip, enum thermal_trip_type trip_type)
+ int trip, enum thermal_trip_type trip_type,
+ enum thermal_trend trend)
{
struct thermal_instance *instance;
struct thermal_cooling_device *cdev;
@@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct
thermal_zone_device *tz,
cdev = instance-cdev;
cdev-ops-get_cur_state(cdev, cur_state);
- instance-target = cur_state instance-lower ?
+ if (trend == THERMAL_TREND_DROP_FULL)
+ instance-target = instance-lower;
+ else
+ instance-target = cur_state instance-lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
/* Deactivate a passive thermal instance */
@@ -133,7 +144,7 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
if (tz-temperature = trip_temp)
update_instance_for_throttle(tz, trip, trip_type, trend);
else
- update_instance_for_dethrottle(tz, trip, trip_type);
+ update_instance_for_dethrottle(tz, trip, trip_type, trend);
mutex_unlock(tz-lock);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 807f214..8bce3ec 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -68,6 +68,8 @@ enum thermal_trend {
THERMAL_TREND_STABLE, /* temperature is stable */
THERMAL_TREND_RAISING, /* temperature is raising */
THERMAL_TREND_DROPPING, /* temperature is dropping */
+ THERMAL_TREND_RAISE_FULL, /* Apply highest cooling action*/
+ THERMAL_TREND_DROP_FULL, /* Apply lowest cooling action*/
};
/* Events supported by Thermal Netlink */
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
