From owner-acpi-jp@jp.FreeBSD.org Wed Dec 17 05:09:15 2003
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id hBGK9FY58511;
	Wed, 17 Dec 2003 05:09:15 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from rootlabs.com (root.org [67.118.192.226])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with SMTP/inet id hBGK9EM58506
	for <acpi-jp@jp.freebsd.org>; Wed, 17 Dec 2003 05:09:14 +0900 (JST)
	(envelope-from nate@rootlabs.com)
Received: (qmail 67260 invoked by uid 1000); 16 Dec 2003 20:09:09 -0000
From: Nate Lawson <nate@root.org>
To: Ducrot Bruno <ducrot@poupinou.org>
cc: Lukas Ertl <l.ertl@univie.ac.at>, acpi-jp@jp.FreeBSD.org,
   current@freebsd.org
In-Reply-To: <20031215094108.GA14031@poupinou.org>
Message-ID: <20031216120640.A67249@root.org>
References: <20031209175230.I44055@root.org> <20031210184201.Y598@korben.in.tern>
 <20031210100527.X46577@root.org> <20031211181049.GA3872@poupinou.org>
 <20031211115236.B50138@root.org> <20031215094108.GA14031@poupinou.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Tue, 16 Dec 2003 12:09:09 -0800
X-Sequence: acpi-jp 2918
Subject: [acpi-jp 2918] Re: ACPI throttling changes
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: nate@root.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+031216

On Mon, 15 Dec 2003, Ducrot Bruno wrote:
> On Thu, Dec 11, 2003 at 11:53:31AM -0800, Nate Lawson wrote:
> > On Thu, 11 Dec 2003, Ducrot Bruno wrote:
> > > On Wed, Dec 10, 2003 at 10:06:45AM -0800, Nate Lawson wrote:
> > > > This is getting a bit off-topic.  It's too early to discuss how all the
> > > > different parts of cpufreq work.  The answer is "yes and no", depending on
> > > > which underlying technologies your laptop has available.  ACPI throttling:
> > > > yes, SpeedStep: mostly yes, ACPI performance states: no.
> > >
> > > ACPI performance states (IO only though) should be ok, no?
> >
> > There's no way to read the current ACPI performance state value.  The only
> > thing you can do is set a performance state and validate that it
> > succeeded.
>
> Indeed, but at least you can have some older technology supported though.
> Ok, most of them are now completely understood, even though you can only
> have at most beta support due to lack of documentations from vendors if
> you do not want IO based acpi performance support.  Also, you may
> want to add some stuff for configuration only purpose in order to simplify
> things (like in centrino platform for example), or to get configuration for
> powernow-k7 when the legacy method fail.

cpufreq will support as many hardware technologies as possible.  ACPI
performance control will only be used if it is present and no other, more
specific driver has attached.  FreeBSD has a nice feature in newbus where
if a driver returns say -100 and another returns -10, the second one will
be attached.  This allows for drivers to claim hardware only if no other
driver thinks it can do better.

-Nate
