From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dominik Brodowski Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-statedriver Date: Tue, 21 Oct 2003 22:01:14 +0200 Sender: cpufreq-bounces@www.linux.org.uk Message-ID: <20031021200114.GB26971@brodo.de> References: Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cpufreq-bounces@www.linux.org.uk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Moore, Robert" Cc: "Therien, Guy" , "Grover, Andrew" , cpufreq@www.linux.org.uk, "Nakajima, Jun" , linux-acpi , "Mallick, Asit K" , "Pallipadi, Venkatesh" , linux-kernel@vger.kernel.org On Tue, Oct 21, 2003 at 10:12:14AM -0700, Moore, Robert wrote: > > This is exactly what I was looking at doing, looks like most of the work > is done. I have some concerns about the actual algorithm used for > changing the CPU frequency (20%/80%), but this of course can be tuned. Well, so write a different governor, and feel free to use Venkatesh's code as a base [it's GPLed, after all...]. I prefer to have several different governors available, so that different users with different needs can use different "policies". > I suspect that CPUs that have the capability of changing frequency > themselves would not use this particular governor. They can't -- If the driver for Transmeta CPUs is loaded, cpufreq governors cannot be started. > You may want to make the sampling rate configurable at run time. Such a "tweaking by sysfs" patch can be added later. Dominik