Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

[Matthew Garrett <mjg@redhat.com>]

On Fri, Dec 05, 2008 at 11:05:39PM +0000, Tom Hughes wrote:
> Thomas Renninger wrote:
> 
> >The biggest problem I see with these "special" ACPI cpufreq interface is:
> >Can there be Asus/eeepcs which provide these ACPI functions (maybe dummies 
> >on
> >future machines?), but can still be switched via the spec conform and more 
> >efficient acpi-cpufreq driver via PSS tables?
> 
> So should we tie this driver to particular DMI signature(s) then? As far 
> as I know it is only useful for the Eee 900 and possibly the 701 when 
> running later BIOSes.

It appears to be implemented in the 900 and 901 BIOSes as well, so some 
kind of limitation is probably needed. The best approach would probably 
to check whether the CPU has the EST flag. Just do something like:

struct cpuinfo_x86 *cpu = &cpu_data(policy->cpu);

if (cpu->x86_vendor != X86_VENDOR_INTEL || cpu_has(cpu, X86_FEATURE_EST))
	return -ENODEV

at the top of the cpufreq init code. That way you'll refuse to bind on 
anything that implements speedstep and acpi-cpufreq can be used instead.

> Running with wifi and the screen off, and the CPU busy (doing m5sum of 
> /dev/zero) I get 2:37 run time at 900MHz and 3:09 at 630MHz so the 
> increase in run time is about 20% on that test.

My only concern about this is that implementing it via cpufreq means 
that on most distributions you'll end up with ondamend running the CPU. 
This makes sense on systems where the cpu scaling drops the voltage, but 
that isn't the case here as far as I can tell. This may result in some 
workloads now having lower battery lives than they did previously. I'll 
try to do some experimentation next week.

Other than that, this patch looks good. I think it makes sense to 
integrate it into eeepc-laptop.

-- 
Matthew Garrett | mjg59@srcf.ucam.org