From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Moore Subject: RE: [ACPI] _PDC method in DSDT Date: 23 Jun 2003 00:53:27 -0700 Sender: cpufreq-admin-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org Message-ID: <1056354807.10323.71.camel@aldebaran.caltech.edu> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: cpufreq-admin-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: "Grover, Andrew" Cc: "Adachi, Kenichi" , acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, cpufreq-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org List-Id: linux-acpi@vger.kernel.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