lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1352701993.1834.26.camel@rzhang1-mobl4>
Date:	Mon, 12 Nov 2012 14:33:13 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	"R, Durgadoss" <durgadoss.r@...el.com>
Cc:	Amit Kachhap <amit.kachhap@...aro.org>,
	"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

On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
> 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
> 	}
> 
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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ