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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
