But warn loudly if anyone tries to use it -- you really should use speedstep-centrino
instead. On Dothans, the TSC is _not_ affected by TSC transitions (contrary
to Banias processors), so set the CPUFREQ_CONST_LOOPS flag.
                                                                                
Many thanks to Thomas Renninger for reporting the lack of, and testing
the support for Dothan processors.

Until further review, only ACPI data will get this driver to run - no built-in tables will exist.
                                                                                
Many thanks to Thomas Renninger for reporting the lack of, and testing
the support for Dothan processors.

The built-in tables are only valid for Pentium M (Banias) processors
with CPUID 6/9/5. So, add a pointer to the proper struct cpu_id to the
cpu_model struct, and re-name _CPU/CPU to _BANIAS/BANIAS

Add a new "struct cpu_id" for better handling of different Pentium M
steppings / revisions.

Currently, the TSC cpufreq notifiers does almost nothing on P4s, as we
assumed the TSC to be constant independent of _all_ frequency transitions.
Extensive testing by Karol Kozimor has shown, though, that only _throttling_
does not affect the TSC, but _scaling_ does.
                                                                                
So:
- pass the CPUFREQ_CONST_LOOPS flags (to be exact, all flags) to cpufreq
  transition notifiers
- skip TSC value changes if this flag is set
- set this flag for P4 / P4-Ms only in p4-clockmod [On Pentium-M banias
  the TSC _is_ affected by p4-clock modulation

[CPUFREQ] Also check whether the CPU frequency is out of sync once we get to cpufreq_notify_transition.

Once we detected 50 consecutive ticks with lost ticks (and this is half of
the amount needed to trigger the fallback to a "sane" timesource), verify
the CPU frequency is in sync if cpufreq is used: sometimes the CPU frequency
changes behind the user's back, and then the TSC detects lost ticks. By a
call to cpufreq_get(), the frequency the TSC driver thinks the CPU is in
is updated to the actual frequency, in case these differ. Works really nice
on my notebook -- it's never falling back to a different timesource now, even
if I plug in the power cord.

sa11x0_getspeed can be used by both cpu-sa1100.c and cpu-sa1110.c as
->get() function. Update calling conventions, and un-export it as
we fixed the handling of cpufreq_get in the cpufreq core. Also,
remove special call to userspace-governor init as it isn't needed
any longer.

arm-integrator had its ->get() implementation inside
integrator_cpufreq_init(). Move it to an extra function,
and add it as ->get() function.

but be careful as some code needs to run on specified CPU only.

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.