[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1342173213.27605.174.camel@tegra-chromium-2>
Date: Fri, 13 Jul 2012 17:53:33 +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 16:11 +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?
>
> 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.
I read the patches of "Thermal Framework Enhancements", it seems the
fair_share governor can be used for this throttling.
Look forward to your public git tree, so that I can sync the entire
codes :)
> 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