On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote: > Hi Amit/Rui, > > > -----Original Message----- > > From: Amit Kachhap [mailto:amit.kachhap@xxxxxxxxxx] > > Sent: Friday, November 09, 2012 11:52 AM > > To: Zhang, Rui > > Cc: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-samsung- > > soc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; R, Durgadoss; > > lenb@xxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; jonghwa3.lee@xxxxxxxxxxx > > 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@xxxxxxxxx> wrote: > > > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote: > > >> On 8 November 2012 11:31, Zhang Rui <rui.zhang@xxxxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
