Re: [RFC] the generic thermal layer enhancement

On 四, 2012-05-31 at 04:58 +0100, Matthew Garrett wrote:

On Thu, May 31, 2012 at 11:54:51AM +0800, Zhang Rui wrote:

quoted

On 三, 2012-05-30 at 13:50 +0100, Matthew Garrett wrote:

quoted

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? :)

quoted

quoted

quoted

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