powernow_k6 has almost all pieces in place for its own ->get() function.
Add the rest.

p4-clockmod is a bit more complicated as it might run on SMP, HT, and
the instructions need to run on the specific (physical) CPU.

Longrun users might be interested in their CPU's current frequency as
well, so use a longrun-specific cpuid-call in longrun_get().

Notifications in i386, sparc64, x86_64, sh-sci and sa11xx-pcmcia notifiers.
sa1100-framebuffer doesn't seem to be able to handle frequency transitions
behind its back well. So, sa11xx will be marked
CPUFREQ_PANIC_OUTOFSYNC | CPUFREQ_PANIC_RESUME_OUTOFSYNC later.

 
Upon resuming, first CPUfreq hardware support needs to be re-enabled in certain cases
(call to cpufreq_driver->resume()).
 
Then, two different paths may need to be taken:
a) frequency during suspend equals frequency during resume ==> everything is fine,
 
b) frequency differ ==> either we can't handle it, then panic (see flag
   CPUFREQ_PANIC_RESUME_OUTOFSYNC). Or we can handle it, then notify all

Sometimes we might discover during a call to cpufreq_get() that we're "out of sync",
meaning the actual CPU frequency changed "behind our back". If this happens, the flag
CPUFREQ_PANIC_OUTOFSYNC decides what can be done: if it is set, the kernel panic's,
it it is not set, the cpufreq transition notifiers are informed of this change, and
a call to cpufreq_update_policy() is scheduled [using the default workqueue] so that
the user-defined values override BIOS / external interaction.

As it involves calls to hardware which might take some time,
only let the super-user read out this value.

Contrary to the previous implementation, it now calls the cpufreq driver,
and reads out the _actual_ current frequency, and not the frequency the
CPUfreq core _thinks_ the CPU is running at. Most cpufreq drivers do provide
such a "hw get" function (only ACPI-io can definitely not be supported,
I'm not sure about sh, sparc64 and powermac) anyway, and it is useful for
other issues.

Many users want to know the current cpu freqeuncy, even if not using
the userspace frequency. On ->target cpufreq drivers (if they do their
calls to cpufreq_notify_transition correctly) this just means reading
out cpufreq_policy->cur.

From paul.devriendt@amd.com

From paul.devriendt@amd.com

cpuid changes to support new processors that will be coming out in the
future. Also works around a processor that we have released to the field
that can have an erroneous cpuid value.

From paul.devriendt@amd.com

Brad Spengler <spender@grsecurity.net> found an exploitable bug in the proc handler
of cpufreq, where a user-supplied unsigned int is cast to a signed int and then
passed on to copy_[to|from]_user() allowing arbitary amounts of memory to be written
(root only thankfully), or read (as any user).

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2004-0228 to this issue.

From Dominik.

One big limitation of the ACPI specification is that it's impossible to
detect the current P-State by reading from ACPI-defined registers. And the
CPU isn't always at P0 when the system boots. So, try to "guess" the current
P-State by analyzing cpu_khz.

From Dominik.

If used as a bootparam, this would've become powernow-k7.powernow_acpi_force which looks silly.

Spotted by Charles Coffing <ccoffing@novell.com>

This breaks on x86-64 with the following warning.

drivers/cpufreq/cpufreq_userspace.c: In function `cpufreq_procctl':
drivers/cpufreq/cpufreq_userspace.c:170: warning: cast from pointer to integer of different size
drivers/cpufreq/cpufreq_userspace.c: In function `cpufreq_sysctl':
drivers/cpufreq/cpufreq_userspace.c:208: warning: cast from pointer to integer of different size

We don't need this, we can infer from CONFIG_ACPI_PROCESSOR

From Paul Devriendt

Decoding the legacy tables may have set these values.

As much as I like the idea of a 13GHz laptop, setting it to 1.3GHz is probably
for the best for the time being.

Due to the possible dependancy on ACPI.

acpi fallback is handled already in the init function.

More from Bruno Ducrot.

Warning: it will only half work on the ACER Aspire, though: there is
no pstate in the DSDT corresponding to the max frequency...
I'm looking how to handle that correctly, probably at the init stage,
if the max frequency is not given, then add it to powernow_table.

* Integrate acpi perflib from Dominik.
* Use acpi if the PST tables are known to be broken (ASUS Aspire match one PST,
  but give brain damaged values), or use ACPI if no PST found.

From: Dominik Brodowski <linux@dominikbrodowski.de>

Don't use the ACPI data on CPUs we don't know nothing about.

into delerium.codemonkey.org.uk:/mnt/nfs/sepia/bar/src/kernel/2.6/trees/cpufreq

From: Bruno Ducrot <ducrot@poupinou.org>

I think this patch is needed especially if the FSB is around 166MHz or
200MHz, or else I believe we get instabilities on some K7's motherboard
powernow capable (it's called Cool'n Quiet IIRC).
                                                                                         
                                                                                         
* Deduce fsb from cpu_khz and the max multiplier.  It will be given as kHz now,
  so that frequency associated to a multiplier will be computate more
  accurately.  Also, we need it for SGTC (see below).
* Fix how cpuid is computed in powernow_decode_bios().
* Be more restrictive for PST.  It may be possible (on desktop shipped with
  low power Athlon models) that FSB can be changed by dip switchs on
  motherboard for example.
* Fix computation for SGTC.  It use the bus timer (and then the bus
  frequency given by fsb).

From: Anton Blanchard <anton@samba.org>

We have to restore r13 when entering unrecoverable_exception.

From: Paul Mackerras <paulus@samba.org>

This patch changes PCI_DMA_TODEVICE to DMA_TO_DEVICE in a couple of
places in drivers/net/ibmveth.c, since it doesn't compile without this
change and it does compile with it.  It also reformats a couple of
over-long lines in the vicinity of the other changes.

From: Niraj Kumar <niraj17@iitbombay.org>

This is in continuation of the ufs2 read-only code that went into 2.6.5.

This patch fixes a bug where wrong content was being read off the disk
after around 4 MB mark.

From: Anton Blanchard <anton@samba.org>

It's been there since the kernel was first imported into bk.  We see no
reason for this.