Re: [ACPI] _PDC method in DSDT

[Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>]

On Mon, Jun 23, 2003 at 07:02:29PM -0700, David Moore wrote:
> 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.
> 

Then break cpufreq/acpi.c in 2 files.  One common acting like a library.
And the other will be the real cpufreq driver.

Still, I don't see why you want the Enhanced SpeedStep in the cpufreq driver
called acpi.  Better to export the table via a function if that is really
needed, and to support it in an external driver like speedstep-centrino.
This was the intention of ACPI to do things like this anyway, or you
miss-interpret the current ACPI specification perhaps.

Then only concern I may have for is still the _PDC method.  It is currently
only documented in a MS document.  It is defined as an optional method
used by the OS in order to be somehow compatible with older releases
of Windows.  But it has the folowing:

Arguments:
Arg0 (buffer):
DWORD 0:         Revision Id
DWORD 1:    Number of capabilities DWORDs in buffer
DWORD 2-n:   Capabilities DWORDs, where each bit
	defines capabilities and features supported by the OSPM for
	processor power management.
	The definitions and meaning of each capabilities bit is vendor
	specific, and shared with OSPM by the vendor.

Result Code:
None

Then give us now the correct values to be passed for Pentium-M found
in Centrino platform, and I will be glad to do the break of cpufreq/acpi.c
for you.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.