RE: [ACPI] _PDC method in DSDT

[David Moore <dcm-HInyCGIudOg@public.gmane.org>]

On Mon, 2003-06-23 at 00:11, Grover, Andrew wrote:
> > From: David Moore [mailto:dcm-HInyCGIudOg@public.gmane.org] 
> > Given this document, I think I have enough information now to patch
> > processor.c to support Enhanced Speedstep on Pentium M for 
> > those BIOSes
> > that have a correctly written _PDC method in the DSDT.  Would the
> > maintainers of the ACPI driver be willing to accept such a patch?
> 
> I don't think so, at least not right now.
> 
> However, since the recently added non-vendor-supported Pentium M cpufreq
> driver uses hardcoded tables and cpuid instead of relying on ACPI for
> this information anyways, adding _PDC support to processor.c would not
> affect its behavior. If that driver were changed to use ACPI for
> determining platform capabilities, like Windows and our released binary
> driver do, then yes, adding _PDC support would be important.
> 

My intention was not for processor.c and cpufreq to cooperate, but
rather for processor.c to be able to control Enhanced Speedstep solely
with P-states -- no cpufreq necessary.  Cpufreq is certainly useful for
those systems not running the ACPI driver, but in the long run, ACPI and
processor.c seem to be the right way to get maximum compatibility with
many platforms.

If my understanding is correct, once _PDC is called, the only change
necessary to drive Enhanced Speedstep with P-states is simply to
interpret the registers returned by _PCT and if they are of type
FixedHardware, to use wrmsr() instead of outb().  I'm slightly
oversimplifying, but such an approach works on my system.

I only have two concerns:
1) If the processor is an AMD or a Transmeta, it looks like _PCT may
also return FixedHardware registers for their respective power
management systems.  Do we need to read cpuid to treat these cases
differently in processor.c, or will the blind wrmsr() do the trick?
2) If this capability is open-source, do you personally have a conflict
of interest between protecting the binary-only module vs. accepting the
patch?

Thanks for your input,

David