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]
Date:	Fri, 27 Jul 2012 10:58:21 +0800
From:	Wei Ni <wni@...dia.com>
To:	Zhang Rui <rui.zhang@...el.com>
CC:	"R, Durgadoss" <durgadoss.r@...el.com>,
	"Brown, Len" <len.brown@...el.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"khali@...ux-fr.org" <khali@...ux-fr.org>,
	"joe@...ches.com" <joe@...ches.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@....kernel.org>,
	Alex Courbot <acourbot@...dia.com>
Subject: RE: How to use the generic thermal sysfs.

On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote:
> On 四, 2012-07-26 at 17:31 +0800, Wei Ni wrote:
> > On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> > > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > > > 
> > > > Our tegra thermal framework also will use the generic thermal layer. It
> > > > will register the cooling device, and run the throttling in this generic
> > > > framework.
> > > > But we have a special mechanism, when the temp is below the trip temp,
> > > > we will set different cpu capability for different temp range. For
> > > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu
> > > > to the max capability, it mean the cpu can run up to the max freq and
> > > > voltage in this temp range. if the temp is out that range, the sensor
> > > > will have irq/alert to notify the tegra framework, then we will set to
> > > > another temperature range and cpu capability.
> > > > I think we can try to add this mechanism to the generic framework as a
> > > > new policy, right?
> > > > 
> > > I think you can make use of the upper&lower limit in my patch set.
> > > Say, here is your thermal policy
> > > 20C - 30C, P0
> > > 30C - 40C, P1 - P2
> > > 40C - 60C, P3 - P5
> > > 60C+, P6 ~ Pn
> > > 
> > > you can register to the thermal layer 4 passive trip points,
> > > 20C, 30C, 40C, 60C, and then
> > > 1) for trip 0 (20C), upper limit 0, lower limit 0
> > > 2) for trip 1 (30C), upper limit 2, lower limit 1
> > > 3) for trip 2 (40C), upper limit 5, lower limit 3
> > > 4) for trip 3 (60C), upper limit n, lower limit 6
> > > 
> > > you can program your own sensor to get interrupt when the temperature
> > > hits 20C/30C/40C/60C, and the generic thermal layer will put the
> > > processors to proper frequency for each trip point.
> > > 
> > > what do you think?
> > 
> > Hi, Rui
> > I'm trying your upper/lower codes on our tegra platform.
> > Since we want to set limit value to the sensor to get interrupt, and
> > many sensor drivers can support the limit alert property, could we add a
> > new callback .set_limits() for the thermal zone device, so that we can
> > program it in the generic layer. when the temperature hits the
> > trip_temp,
> 
> at this time, there should be an interrupt, right?

Yes, there will have an interrupt.

> 
> >  we can try to set to the next limit range.
> 
> is it possible to program the sensor at this time, in your own thermal
> driver?

Since we are using the generic thermal driver lm90.c, I'm not sure if we
could program these limits in the generic driver, I think it's better to
have a generic interface to set the limits, so I wish to add a
callback .set_limits() in the generic thermal framework.

> 
> thanks,
> rui
> > I can try to add these codes base on your patches.
> > 
> > Thanks.
> > Wei.
> > 
> > > 
> > > BTW, the upper and lower limit is introduced in the patch set I'm
> > > testing, so maybe you were not aware of it.
> > > 
> > > 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