RE: [ACPI] _PDC method in DSDT

Grover, Andrew
2003-06-23T09:19:27Z

> From: David Moore [mailto:dcm-HInyCGIudOg@public.gmane.org]
> 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.

> 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?

The spec intended FixedFunctionalHW registers to be an "escape hatch".
FFH means that while ACPI is used for perf state enumeration, the
transitions will be handled in a CPU-specific driver, not via methods
described in the ACPI spec. This division (use ACPI for enum, x for
control) isn't currently supported by cpufreq; ACPI either does both
enum and control, or neither.

It is not safe to assume the CPU-specific mechanism will be the same
across vendors, or even across models from the same vendor. Indeed, the
whole point of all this was so these mechanisms could be different, and
remain proprietary.

> 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?

Response #1 (practical):
What patch? The patch you haven't written yet? That may or may not be
against files I maintain (as opposed to
arch/i386/kernel/cpu/cpufreq/acpi.c)?

Response #2 (philosophical):
Do you really think a maintainer really has any power? Or just
responsibility?

Regards -- Andy