Message-ID: <EDC461A30AC4D511ADE10002A5072CAD0236DEEA@orsmsx119.jf.intel.com>
From: "Grover, Andrew" <andrew.grover@intel.com>
To: "'Pavel Machek'" <pavel@suse.cz>, Dominik Brodowski <linux@brodo.de>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org, hpa@zytor.com,
       cpufreq@www.linux.org.uk
Subject: RE: cpufreq patches for 2.5.39 follow
Date: Tue, 1 Oct 2002 15:55:38 -0700 
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1346
Lines: 33

> From: Pavel Machek [mailto:pavel@suse.cz] 
> How does it interact with ACPI? Ie. I do echo "100%100%foo", 
> but ACPI thermal
> managment decides to slow down?

How do you think it should be handled?

Will the ACPI thermal driver be able to use a standard cpufreq interface to
request that the CPU drop to a lower mhz/voltage?

Things get interesting on a system that implements ACPI 2.0-style processor
performance controls, instead of proprietary methods. Then you could have
ACPI thermal telling cpufreq to slow down, which in turn tells the ACPI
processor driver. IMHO this is the way it should work. There is a connection
right now between the ACPI thermal and processor driver, but that is just
there because cpufreq didn't exist. This dependency should be severed, and
cpufreq should go in the middle.

This was discussed on cpufreq a few months ago and I think Dominik even
whipped up some code, but it may have bit-rotted...

> > Support for mobile AMD K7 processors is still in development.
> 
> What about mobile celerons?

Mobile Celerons do not support voltage scaling.

Regards -- Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/