Re: [ACPI] _PDC method in DSDT

[David Moore <dcm@acm.org>]

On Mon, 2003-06-23 at 18:37, Jeremy Fitzhardinge wrote:
> Hardly any of the code in speedstep-centrino has to do with actually
> setting the speed; nor is much of it to do with identifying the CPU and
> selecting the right table.  Most of it is to do with being a
> well-behaved cpufreq driver.  You would need to move more code than just
> the "wrmsr" into acpi.c.
> 

My understanding was that i386/kernel/cpu/cpufreq/acpi.c in 2.5.x was
already a well-behaved cpufreq driver.  Am I wrong about that?

> The driver as it stands still has to exist for the case where you're not
> using ACPI, but if ACPI is available, using its table is certainly a
> useful thing to have.  If the ACPI code for getting that table
> information is so complicated, then how about a nice simple entrypoint
> which provides the appropiate frequency points with the corresponding
> PERF_CTL values?

> The core of the tension is whether to put ACPI code under
> arch/i386/kernel/cpu/cpufreq or put cpufreq code into drivers/acpi. 
> There doesn't seem to be much to choose between the two, but if ACPI is
> a mechanism which is supposed to supply services to other drivers, it
> doesn't make much sense to migrate all those drivers into drivers/acpi.
> 

Right, that's why the ACPI performance control code got moved out of
drivers/acpi and into arch/i386/kernel/cpu/cpufreq in the 2.5 series. 
The problem is that, if I understand it correctly, the current code for
ACPI performance control in 2.5 does not really work as a library for
other drivers -- it's basically just a standalone cpufreq driver.  It
would be much easier to add a few lines for Enhanced Speedstep than to
restructure the code to work well as a library.

-David