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: <1342167087.27605.158.camel@tegra-chromium-2>
Date:	Fri, 13 Jul 2012 16:11:27 +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@....kernel.org" <linux-tegra@...r.kernel.org>,
	Alex Courbot <acourbot@...dia.com>
Subject: RE: How to use the generic thermal sysfs.

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?

It's great, this is exactly what we need.
I think for these trip points, we can use a new trip type, such as
TRIP_LIMIT, and use new policy. Because in these state, we only need to
set the processors to proper frequency capability, it's not like the
passive type, the currently passive type will try to set cooling device
state continually.
And for these trip temp, it's better to add hysteresis value, so that it
can avoid unnecessary interrupt.

> 
> BTW, the upper and lower limit is introduced in the patch set I'm
> testing, so maybe you were not aware of it.

How can I get these codes?

> 
> 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