From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Moore Subject: Re: [ACPI] _PDC method in DSDT Date: 24 Jun 2003 14:47:52 -0700 Sender: cpufreq-admin-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org Message-ID: <1056491271.3979.15.camel@aldebaran.caltech.edu> References: <20030623133834.GA2330@brodo.de> <20030623161136.GG19556@poupinou.org> <1056388336.15250.62.camel@ixodes.goop.org> <1056398545.10322.111.camel@aldebaran.caltech.edu> <20030623213726.GA1317@brodo.de> <1056417280.10323.148.camel@aldebaran.caltech.edu> <1056418635.5977.20.camel@sherkaner.pao.digeo.com> <1056420149.10322.160.camel@aldebaran.caltech.edu> <20030624091836.GI19556@poupinou.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20030624091836.GI19556-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> Errors-To: cpufreq-admin-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Ducrot Bruno Cc: Jeremy Fitzhardinge , Dominik Brodowski , Andrew Grover , "Adachi, Kenichi" , acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, cpufreq list List-Id: linux-acpi@vger.kernel.org On Tue, 2003-06-24 at 02:18, Ducrot Bruno wrote: > 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. > Dword 0 should be 0x1 Dword 1 should be 0x1 Dword 2 should be 0x1 The 0x1 in Dword 2 indicates that the driver supports Enhanced Speedstep. In my DSDT, Dwords 0 and 1 are ignored anyway, but the values above should be correct. Feel free to do the split into two files if you think that's the way to go. I'm going to submit my patch to the cpufreq list anyway under a separate email, just so it exists for the record. You might change your mind after seeing it. I also have a patch that fixes a few bugs in the current cpufreq/acpi.c. Regards, David