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

On Wed, May 30, 2012 at 04:49:02PM +0800, Zhang Rui wrote:

quoted

G1. supporting multiple cooling states for active cooling devices.

Sounds fine.

Great!

quoted

G2. introduce cooling states range for a certain trip point

Again, no problem here.

Again, great!

quoted

G3. kernel thermal passive cooling algorithm

quoted

    Currently, tc1 and tc2 are hard requirements for kernel passive
    cooling. But non-ACPI platforms do not have this information
    (please correct me if I'm wrong).
    Say, for the patches here
    http://marc.info/?l=linux-acpi&m=133681581305341&w=2
    They just want to slow down the processor when current temperature
    is higher than the trip point and speed up the processor when the
    temperature is lower than the trip point.

Just slowing the CPU down above a certain temperature is a pretty awful 
approach to passive cooling. You want to maximise performance while 
staying within your thermal envelope, so you need a more advanced 
approach.

Agreed.

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.

I don't fundamentally object to adding support for platform-specific 
passive formulae, but I'd like an explanation for how they're better 
than the existing one.

Hmmm, I'd like to see if it is possible for them to make use of the
current passive cooling implementation.. if no...

how about this?

we can provide an API for the current algorithm in thermal_sys.c

thermal_passive_get_trend(int tc1, int tc2)
{
}
EXPORT_SYMBOL(...);

and in platform driver, they can choose to use this default algorithm if
they are able to.

.get_trend()
{
   return thermal_passive_get_trend(platform_tc1, platform_tc2);
}

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

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