Re: [RFC] the generic thermal layer enhancement

[Zhang Rui <rui.zhang@intel.com>]

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