cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Moore <dcm@acm.org>
To: Dominik Brodowski <linux@brodo.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Ducrot Bruno <ducrot@poupinou.org>,
	Andrew Grover <andrew.grover@intel.com>,
	"Adachi, Kenichi" <adachi@rd.scei.sony.co.jp>,
	acpi-devel@lists.sourceforge.net,
	cpufreq list <cpufreq@www.linux.org.uk>
Subject: Re: [ACPI] _PDC method in DSDT
Date: 23 Jun 2003 18:14:40 -0700	[thread overview]
Message-ID: <1056417280.10323.148.camel@aldebaran.caltech.edu> (raw)
In-Reply-To: <20030623213726.GA1317@brodo.de>

On Mon, 2003-06-23 at 14:37, Dominik Brodowski wrote:
> 
> Firstly, please let me explain the goal of the cpufreq project: it is a
> cross-architecture, _generic framework_ which provides

Thanks for your explanation.  My fault was that I was too busy looking
at 2.4.21-ac1 and I didn't realize cpufreq had matured a lot in the
development series and resolved the duplication between it and the ACPI
drivers.

> Because of this, the ACPI P-States driver became a "cpufreq driver" in the
> _development_ series -- see arch/i386/kernel/cpu/cpufreq/acpi.c in latest 
> 2.5. kernels.
> 

Yes, I see that now.  That looks like exactly the right way to do it.

> IMO the ACPI P-States driver should only include the ACPI 2.0 P-States driver,
> and not try to support all other sorts of legacy support and become one
> "mega-driver". Instead, the other information stored in _PCT you talk about 
> should be available to other processor-specific cpufreq drivers which see 
> a need to obtain this information -- ACPI as a library, available to those 
> who want it.
> 

I see your rationale for wanting the P-state driver to be ACPI 2.0-only,
but I think there is some advantage to adding Enhanced Speedstep support
to i386/kernel/cpu/cpufreq/acpi.c rather than just added ACPI query
capabilities to speedstep-centrino.c:

speedstep-centrino.c is very picky about the precise CPU because its
tables are hard-coded with no margin for error.  With ACPI, the test for
Enhanced Speedstep would be more general:
if cpu_has(cpu, X86_FEATURE_EST) is true, and after calling _PDC, if
_PTC returns FFH registers, then treat those registers as MSRs instead
of IO ports.  Thus, it supports any Enhanced Speedstep hardware with a
correct BIOS, not just the ones enumerated by speedstep-centrino.c.

I guess my main point is that in order for speedstep-centrino.c to call
ACPI as a library, it would basically need to use every function already
written in acpi.c.  Why not just dispatch the wrmsr() from acpi.c rather
than the other way around?  It would take probably a 15-line patch to
add Enhanced Speedstep support to acpi.c, but probably would be much
more complicated to query ACPI from speedstep-centrino.c.  For AMD and
Transmeta processors, there would be no point in specific support for
them in acpi.c since ACPI doesn't really provide useful information for
their performance control anyway.

-David

  reply	other threads:[~2003-06-24  1:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-23  9:19 [ACPI] _PDC method in DSDT Grover, Andrew
2003-06-23 13:38 ` Dominik Brodowski
2003-06-23 16:11   ` Ducrot Bruno
2003-06-23 17:12     ` Jeremy Fitzhardinge
2003-06-23 20:02       ` David Moore
2003-06-23 21:37         ` Dominik Brodowski
2003-06-24  1:14           ` David Moore [this message]
2003-06-24  1:37             ` Jeremy Fitzhardinge
2003-06-24  2:02               ` David Moore
2003-06-24  2:16                 ` Jeremy Fitzhardinge
2003-06-24  9:18                 ` Ducrot Bruno
2003-06-24 21:47                   ` David Moore
2003-06-26 10:40                     ` Ducrot Bruno
2003-06-26 11:13                       ` Ducrot Bruno
2003-09-04 23:19                     ` [RFC] cpufreq: use new acpi processor perflib in speedstep-centrino [Was: Re: [ACPI] _PDC method in DSDT] Dominik Brodowski
2003-09-05 16:53                       ` Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2003-06-23  7:11 [ACPI] _PDC method in DSDT Grover, Andrew
2003-06-23  7:53 ` David Moore
2003-06-23 12:27   ` Ducrot Bruno
2003-06-23 13:42   ` Dominik Brodowski
2003-06-23  7:59 ` Arjan van de Ven
2003-06-23 13:44 ` Dominik Brodowski

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=1056417280.10323.148.camel@aldebaran.caltech.edu \
    --to=dcm@acm.org \
    --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=ducrot@poupinou.org \
    --cc=jeremy@goop.org \
    --cc=linux@brodo.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox