Re: ACPI throttling changes

From: Nate Lawson <nate_at_root.org>
Date: Tue, 16 Dec 2003 12:09:09 -0800 (PST)
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
Received on Tue Dec 16 2003 - 11:09:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:34 UTC