From: Dominik Brodowski <linux@brodo.de>
To: David Moore <dcm@acm.org>
Cc: "Grover, Andrew" <andrew.grover@intel.com>,
"Adachi, Kenichi" <adachi@rd.scei.sony.co.jp>,
acpi-devel@lists.sourceforge.net, cpufreq@www.linux.org.uk
Subject: Re: [ACPI] _PDC method in DSDT
Date: Mon, 23 Jun 2003 15:42:43 +0200 [thread overview]
Message-ID: <20030623134243.GB2330@brodo.de> (raw)
In-Reply-To: <1056354807.10323.71.camel@aldebaran.caltech.edu>
On Mon, Jun 23, 2003 at 12:53:27AM -0700, David Moore wrote:
> 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.
Actually, in 2.5. ACPI provides one of several cpufreq drivers. The user can
choose which one best suits his needs [e.g. speedstep-centrino for the
faster wrmsr method instead of the slow io-based ACPI-2.0 module -
arch/i386/cpu/cpufreq]. Also I doubt that ACPI will allow maximum
compatibility: this new _PCT method again tries to implement things
in a "proprietary", "legacy", "secret" way, supported only by
reverse-engineered or binary-only drivers.
Dominik
WARNING: multiple messages have this Message-ID (diff)
From: Dominik Brodowski <linux-JhLEnvuH02M@public.gmane.org>
To: David Moore <dcm-HInyCGIudOg@public.gmane.org>
Cc: "Grover,
Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Adachi,
Kenichi"
<adachi-fvZ7ij+YLgEZc9YY0SgeQc8NsWr+9BEh@public.gmane.org>,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
cpufreq-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org
Subject: Re: [ACPI] _PDC method in DSDT
Date: Mon, 23 Jun 2003 15:42:43 +0200 [thread overview]
Message-ID: <20030623134243.GB2330@brodo.de> (raw)
In-Reply-To: <1056354807.10323.71.camel-cfibRQahR+cF6I9xFAAkN5QCsf4PZ8us@public.gmane.org>
On Mon, Jun 23, 2003 at 12:53:27AM -0700, David Moore wrote:
> 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.
Actually, in 2.5. ACPI provides one of several cpufreq drivers. The user can
choose which one best suits his needs [e.g. speedstep-centrino for the
faster wrmsr method instead of the slow io-based ACPI-2.0 module -
arch/i386/cpu/cpufreq]. Also I doubt that ACPI will allow maximum
compatibility: this new _PCT method again tries to implement things
in a "proprietary", "legacy", "secret" way, supported only by
reverse-engineered or binary-only drivers.
Dominik
next prev parent reply other threads:[~2003-06-23 13:42 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-23 7:11 [ACPI] _PDC method in DSDT Grover, Andrew
2003-06-23 7:11 ` Grover, Andrew
2003-06-23 7:53 ` David Moore
2003-06-23 7:53 ` David Moore
2003-06-23 12:27 ` Ducrot Bruno
2003-06-23 12:27 ` Ducrot Bruno
2003-06-23 13:42 ` Dominik Brodowski [this message]
2003-06-23 13:42 ` Dominik Brodowski
2003-06-23 7:59 ` Arjan van de Ven
2003-06-23 7:59 ` Arjan van de Ven
2003-06-23 13:44 ` Dominik Brodowski
2003-06-23 13:44 ` Dominik Brodowski
-- strict thread matches above, loose matches on Subject: below --
2003-06-23 9:19 Grover, Andrew
2003-06-23 9:19 ` Grover, Andrew
2003-06-23 13:38 ` Dominik Brodowski
2003-06-23 13:38 ` Dominik Brodowski
2003-06-23 16:11 ` Ducrot Bruno
2003-06-23 16:11 ` Ducrot Bruno
2003-06-23 17:12 ` Jeremy Fitzhardinge
2003-06-23 17:12 ` Jeremy Fitzhardinge
2003-06-23 20:02 ` David Moore
2003-06-23 20:02 ` David Moore
2003-06-23 21:37 ` Dominik Brodowski
2003-06-23 21:37 ` Dominik Brodowski
2003-06-24 1:14 ` David Moore
2003-06-24 1:14 ` David Moore
2003-06-24 1:37 ` Jeremy Fitzhardinge
2003-06-24 1:37 ` Jeremy Fitzhardinge
2003-06-24 2:02 ` David Moore
2003-06-24 2:02 ` David Moore
2003-06-24 2:16 ` Jeremy Fitzhardinge
2003-06-24 2:16 ` Jeremy Fitzhardinge
2003-06-24 9:18 ` Ducrot Bruno
2003-06-24 9:18 ` Ducrot Bruno
2003-06-24 21:47 ` David Moore
2003-06-24 21:47 ` David Moore
2003-06-26 10:40 ` Ducrot Bruno
2003-06-26 10:40 ` Ducrot Bruno
2003-06-26 11:13 ` Ducrot Bruno
2003-06-26 11:13 ` Ducrot Bruno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030623134243.GB2330@brodo.de \
--to=linux@brodo.de \
--cc=acpi-devel@lists.sourceforge.net \
--cc=adachi@rd.scei.sony.co.jp \
--cc=andrew.grover@intel.com \
--cc=cpufreq@www.linux.org.uk \
--cc=dcm@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.