This is an updated version of my posting to port-i386@netbsd.org.
I'm decorating the obsoleted sections with */**/*** marks, and added
some updated information below. The original posting follows:

-----8<----------------------------------

I have reviewed the patch proposed by Martin Vegiard to support
the AMD PowerNow! CPU frequency scaling technology and I have
added support for CPUID-based detection of CPU support, fixed some
minor problems, and altered the kernel messages output by the code.

Here are the results:

CVS diff of my changes against netbsd-current (as of 01.16.2005):
http://quasar.dynaweb.hu/~rumi/powernow/powernow_050116.diff

The original patch by Martin Vegiard against 2.0G:
http://quasar.dynaweb.hu/~rumi/powernow/powernow_k7-vegiard.patch

A quick'n'dirty patch against estd-r3 to support PowerNow:
http://quasar.dynaweb.hu/~rumi/powernow/estd_powernow.patch

(*) The estd tarball can be found at (not in pkgsrc, dunno why):
http://www.elektro-eel.org/estd-netbsd.html

Related PR numbers: 26239, 26423(*)

There are two strange issues:

1.) Some braindead BIOSes (for Acer/ALi chipsets as it seems)
report CPU signatures that start at 0x700, and this will never
match the actual signatures because as far as I could tell, the
'7' would stand there for the CPU Family which is actually 6 for
the Athlon (K7) series. This means that for my Athlon XP-M,
the signature 0x781 is expected by the BIOS list, but the CPU
correctly returns 0x681. These do not match and with the Vegiard
patch this produces an error so I have added a hack for it in
my code. (**)

2.) These BIOSes also seem to supply a bogus/incomplete frequency
list. In my case the machine has an Athlon XP-M 2000+ CPU which
operates at a maximum of 1666MHz but the frequency list only
contains values up to 1396Mhz. All supplied values work, but
the CPU cannot be set to it's maximum frequency by PowerNow,
only up to 1396Mhz. Maybe the manufacturers try to solve thermal
design issues this way? (***)

-----8<-----------------------------

*) According to the closure of PR#26423, estd is now in pkgsrc.

**) I learned that there are more functions in the AMD CPUID to
detect CPU model information and one of them reports the family
number +1 by design, maybe this is the reason for the signatures
having +0x100 on the notebook I have tested (FSC Amilo-A). Anyways,
I found no indication of consistency between vendors regarding this
practice so I don't think one can rely on that. My patch tries to match
both the original signature and the signature+0x100 and this actually
does work but I don't think this is the right way to do it.

***) I learned that one cannot rely on BIOS support to extract the
proper FID/VID values from PSBs. Some vendors do provide this
information in their BIOSes, some do not, some provide incorrect,
incomplete, or unusable information. Even worse, the ACPI P-states
list was also empty in the notebook I had, which means one cannot
rely neither on APM nor on ACPI to get proper FID/VID pairs, one can
only hope that something is present or is usable.

Conclusion:

If one sets a FID/VID pair which is not supported by the CPU then
it may hang completely, so one has to make sure the FID/VID values
are correct before they are tried. Currently I think the only way to
ensure that is to get the correct tables from AMD for each and
every CPU model and include these in the kernel, detect the
exact CPU model by CPUID at boot time and use the table
specific to that particular CPU.