Re: [RFC] the generic thermal layer enhancement

Zhang Rui
2012-05-31T05:53:18Z

On 四, 2012-05-31 at 04:58 +0100, Matthew Garrett wrote:
> On Thu, May 31, 2012 at 11:54:51AM +0800, Zhang Rui wrote:
> > On 三, 2012-05-30 at 13:50 +0100, Matthew Garrett wrote:
> > > The existing algorithm provides a generic mechanism for
> > > balancing performance and thermal output, with the only requirement
> > > being that the platform provide constants that represent the heating and
> > > cooling properties of the system.
> > >
> > I'm not sure if this could work on their platforms. So I'm just looking
> > for an easier way to handle this, i.e. make generic thermal layer
> > simple, and provide the flexibility for platform drivers to do their own
> > tricks.
>
> If it's not possible for a platform to use the existing generic approach
> then we should certainly provide a way for them to handle that, but
> first I'd like to see evidence that it's impossible for them to use the
> existing generic approach. This kind of conversation is better with real
> world examples :)

Agreed.

Amit, do you have any update on this? :)

>
> > > > G4. Multiple passive trip points
> > >
> > > It would be good to have an explanation of the use case here. If it's
> > > acceptable for the device to be at the lower passive trip point, why are
> > > we slowing it down at all?
> > >
> > acceptable does not equal comfortable?
> > Say, I'd like to use the computer at 30C skin temperature.
> > I'm okay with the temperature at 50C, but it would be nice if it can be
> > lower, even if the system would be slower, but not too slow (T-state).
> > If the temperature is higher than 60, it is not usable for me, I'll wait
> > for a while, the system can do everything they want do cool the system
> > down (but hibernate/shutdown would be not a good idea at this time
> > because it is hot enough for some hardware damage).
>
> Ok, that seems reasonable.
>
Great!

thanks,
rui

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html