[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D68720C2E767A4AA6A8796D42C8EB59206068@BGSMSX101.gar.corp.intel.com>
Date: Mon, 12 Nov 2012 05:55:48 +0000
From: "R, Durgadoss" <durgadoss.r@...el.com>
To: Amit Kachhap <amit.kachhap@...aro.org>,
"Zhang, Rui" <rui.zhang@...el.com>
CC: "linux-pm@...ts.linux-foundation.org"
<linux-pm@...ts.linux-foundation.org>,
"linux-samsung-soc@...r.kernel.org"
<linux-samsung-soc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lenb@...nel.org" <lenb@...nel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"jonghwa3.lee@...sung.com" <jonghwa3.lee@...sung.com>
Subject: RE: [PATCH 1/4] thermal: Add new thermal trend type to support
quick cooling
Hi Amit/Rui,
> -----Original Message-----
> From: Amit Kachhap [mailto:amit.kachhap@...aro.org]
> Sent: Friday, November 09, 2012 11:52 AM
> To: Zhang, Rui
> Cc: linux-pm@...ts.linux-foundation.org; linux-samsung-
> soc@...r.kernel.org; linux-kernel@...r.kernel.org; R, Durgadoss;
> lenb@...nel.org; linux-acpi@...r.kernel.org; jonghwa3.lee@...sung.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.zhang@...el.com> wrote:
> > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> >> On 8 November 2012 11:31, Zhang Rui <rui.zhang@...el.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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists