AMD recently errata'd the definition of the PSB/PST for recent Athlon 64 and Opteron parts.  The errata
allows for a second, identical PST for those parts.
The current powernow-k8 driver will not work in PST/PSB mode on those parts because it requires 
there be 1 and only 1 PST.

From: Mark Langsdorf
Signed-off-by: Dave Jones <davej@redhat.com>

speedstep-smi only makes sense on Intel mobile Pentium III systems.
So, unify the distributed checks for speedstep_processor there,
and disallow P4s.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>

I tried to load the new SMP capable powernow k8 driver on a machine
with an too old BIOS. I got a lot of cryptic "init not cpu 0"
messages until the "MP systems not supported by PSB ..." message.

This patch switches the order of the checks around to print the
other message first. It will be still printed multiple times
because the cpufreq setup will probe all CPUs, but that's probably
ok.

From: Andi Kleen <ak@muc.de>
Signed-off-by: Dave Jones <davej@redhat.com>

The current CPU frequency is already exported one directory upwards, so there
is no need to duplicate it in the ondemand governor.

From: Dominik Brodowski <linux@dominikbrodowski.de>
Signed-off-by: Dave Jones <davej@redhat.com>

The SA1100 and SA1110 platforms can handle situations well where the
CPU frequency is different to the value the cpufreq (and timing) code
thinks it is, e.g. when resuming from sleep. So, remove the flags
noting the opposite.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.de>
Signed-off-by: Dave Jones <davej@redhat.com>

It's being passed a global everywhere, so it may as well directly reference it.
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dave Jones <davej@redhat.com>

Some daemons try to set the speed to the same speed we're currently
running at. Detect that, and bail out early before we fiddle
with registers and such.
Signed-off-by: Dave Jones <davej@redhat.com>

From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>

From: Sven Traenkle

The second part adresses a problem of resetting the max cpu-freq when
unloading the driver. This didn't work for my cpu and I doubt it does
for other. There is no need to pass the computed index of the max.
multiplier in the clock_ratio[] table to longhault_table[] cause the
longhaul_setstate function works with the clock_ratio[] index.
                                                                                                          
Changing the while loop to a for loop with upper limit isn't actually
necessary as long as the driver is bug free, but thats IMHO not yet the
case, so I suggest this change in order to not loop endlessly or read
beyond the limits of the clock_ratio array.
Signed-off-by: Dave Jones <davej@redhat.com>

From: Sven Traenkle.

here's a patch that solves some issues I have with the longhaul cpufreq
driver on my epia 6000CL/Via EDEN (actually reporting as CentaurHauls,
family 6, model 7, VIA Samuel 2). The driver tries to compute the fsb speed
while it could actually use the fixed values (as it does for model == 6).
I got this change from the via forum, so no credits to me.
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Dave Jones <davej@redhat.com>

By defining the cpu type at startup, we can make a lot of comparisons
a lot more obvious what they are meaning.
Signed-off-by: Dave Jones <davej@redhat.com>

If its >= 1000MHz print it as GHz.
Signed-off-by: Dave Jones <davej@redhat.com>

into delerium.codemonkey.org.uk:/mnt/data/src/bk/cpufreq

Signed-off-by: Dave Jones <davej@redhat.com>

We currently don't do voltage scaling, but we can at least set things up
to prepare for when we do.
Signed-off-by: Dave Jones <davej@redhat.com>

This makes some of the code quite a bit cleaner, and a lot more
obvious whats going on on which CPUs.
Signed-off-by: Dave Jones <davej@redhat.com>

This patch changes hose_list from a simple linked list to a
"list.h"-style list.  This is in preparation for the runtime
addition/removal of PCI Host Bridges.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

On some platforms (notably power5) you can't enable surveillance
(firmware/service processor watchdog) from the kernel - you have to do
it in the firmware.

This patch changes enable_surveillance() to make the message that is
printed in this situation more informative.  Additionaly, the rtas_call
was changed to rtas_set_indicator so as to avoid having to handle
RTAS_BUSY returns.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

The code doesn't actually _care_ about 32/64-bit issues,
only about F_SETLK vs F_SETLKW, and the F_SETLK64 doesn't
exist except as a compatibility thing on 64-bit architectures
(since the regular one already _is_ 64-bit, of course).

into fys.uio.no:/home/linux/bitkeeper/nfsclient-2.6

   server are not allowed to be interrupted as that may result in the
   client and server disagreeing.

   recall ability.
Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

   NFS4ERR_CB_PATH_DOWN error.

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

Signed-off-by: Trond Myklebust <trond.myklebust@fys.uio.no>

into fys.uio.no:/home/linux/bitkeeper/work/nfsclient-2.6

into fys.uio.no:/home/linux/bitkeeper/nfsclient-2.6

   rather than an inode argument. Fix up nfs_instantiate() and
   _nfs4_do_open to use this since doing a new lookup might be racy.

   NFS4ERR_DELAY on the GETATTR call.