There are a bunch of irrelevant SPR definitions in asm/processer.h.  Cut
them down a bit, also add a DABR_TRANSLATION define which will be used
shortly.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix a bug in list scanning that can cause us to skip the last buffer on the
checkpoint list (and hence fail to do any progress under some rather
unfavorable conditions).

The problem is we first do jh=next_jh and then test

	} while (jh!=last_jh);

Hence we skip the last buffer on the list (if it was not the only buffer on
the list).  As we already do jh=next_jh; in the beginning of the loop we
are safe to just remove the assignment in the end.  It can happen that 'jh'
will be freed at the point we test jh != last_jh but that does not matter
as we never *dereference* the pointer.
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix possible false assertion failure in log_do_checkpoint().  We might fail
to detect that we actually made a progress when cleaning up the checkpoint
lists if we don't retry after writing something to disk.  The patch was
confirmed to fix observed assertion failures for several users.

When we flushed some buffers we need to retry scanning the list.
Otherwise we can fail to detect our progress.
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

prom_init(), the trampoline code that "talks" to Open Firmware during
early boot, has various issues with managing OF result codes. Some of my
recent fixups in fact made the problem worse on some platforms.

This patch reworks it all. Tested on g5, Maple, POWER3 and POWER5.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This gets rid of an unused variable `error' in sys_ia32.c:sys32_epoll_wait()

Getting rid of this one makes parsing the output of the kernecomp
autobuild easier --- searching for `Error' to find a problem kept
hitting this one, even though it's only a warning.
Signed-off-by: NTony Luck <tony.luck@intel.com>

The attached patch cleans up a compilation warning when ACPI
is turned off (i.e., when compiling for the Ski simulator).
Signed-off-by: NTony Luck <tony.luck@intel.com>

This cleans up the /proc/device-tree representation of the Open Firmware
device-tree on ppc and ppc64.  It does the following things:

 - Workaround an issue in some Apple device-trees where a property may
   exist with the same name as a child node of the parent.  We now
   simply "drop" the property instead of creating duplicate entries in
   /proc with random result...

 - Do not try to chop off the "@0" at the end of a node name whose unit
   address is 0.  This is not useful, inconsistent, and the code was
   buggy and didn't always work anyway.

 - Do not create symlinks for the short name and unit address parts of a
   node.  These were never really used, bloated the memory footprint of
   the device-tree with useless struct proc_dir_entry and their matching
   dentry and inode cache bloat.

This results in smaller code, smaller memory footprint, and a more
accurate view of the tree presented to userland.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is the ppc32 patch equivalent to the just posted ppc64 one working
around a bug in Apple device-trees regarding the "cpus" nodes.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Apple's Open Firmware has a funny bug when creating the /cpus nodes
where it leaves a dangling '\0' character in the CPU name which ends up
appearing in the full path of the node. This is bogus and
confuses /proc/device-tree badly.

This patch strips those bogus zero's from the node full path when
reading the device-tree from Open Firmware. The "name" property is not
modified and still contains the spurrious 0 (it basically contains 0
tailing 0 instead of one) but that shouldn't be a problem.

An equivalent patch for ppc32 will follow shortly
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The initial peek read PIO of the match register is just a waste.
Just do the flush writes first, as that is more efficient.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Documentation for cpufreq stats.
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

Changes to the cpufreq stats driver:
* Changes the way P-state transition table looks in /sysfs providing more
  clear output
* Changes the time unit in the output from HZ to clock_t
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

cpfureq developers cant spel.
Signed-off-by: NDave Jones <davej@redhat.com>

From patch by: Ken Staton <ken_staton@agilent.com>
Signed-off-by: NDave Jones <davej@redhat.com>

As mandated by the spec, disable timer around transitions.

From code by : Ken Staton <ken_staton@agilent.com
Signed-off-by: NDave Jones <davej@redhat.com>

The spec states that we have to do this, which is *horrid*.

Based on code from: Ken Staton <ken_staton@agilent.com>
Signed-off-by: NDave Jones <davej@redhat.com>

[PATCH] [5/5] ondemand governor default sampling downfactor as 1

Make default sampling downfactor 1.
This works better with earlier auto downscaling change in ondemand governor.
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

[PATCH] [4/5] ondemand governor automatic downscaling

Here is a change of policy for the ondemand governor. The modification
concerns the frequency downscaling. Instead of decreasing to a lower
frequency when the CPU usage is under 20%, this new policy automatically
scales to the optimal frequency. The optimal frequency being the lowest
frequency which provides enough power to not trigger the upscaling policy.
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

[PATCH] [3/5] ondemand,conservative governor idle_tick clean-up

Ondemand and conservative governor clean-up, it factorises the idle ticks 
measurement.
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

[PATCH] [2/5] ondemand,conservative governor store the idle ticks for all cpus

Ondemand, conservative governor did not store prev_cpu_idle_up into 
prev_cpu_idle_down for other CPUs than the current CPU.
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

[PATCH] [1/5] ondemand,conservative minor bug-fix and cleanup

Attached patch fixes some minor issues with Alexander's patch and related
cleanup in both ondemand and conservative governor.
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>

Adds support so that the cpufreq change stepping is no longer fixed at 5% and
can be changed dynamically by the user
Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
Signed-off-by: NDave Jones <davej@redhat.com>

Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
Signed-off-by: NDave Jones <davej@redhat.com>

Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
Signed-off-by: NDave Jones <davej@redhat.com>

A new cpufreq module, based on the ondemand one with my additional patches
just posted.  This one is more suitable for battery environments where its
probably more appealing to have the cpu freq gracefully increase and decrease
rather than flip between the min and max freq's.

N.B. Bruno Ducrot pointed out that the amd64's "do have unacceptable latency
between min and max freq transition, due to the step-by-step requirements
(200MHz IIRC)"; so AMD64 users would probably benefit from this too.
Signed-off-by: NAlexander Clouter <alex-kernel@digriz.org.uk>
Signed-off-by: NDave Jones <davej@redhat.com>

Fix up comment in cpufreq.h stating transition latency should be passed
in microseconds -- it was decided long ago to switch to nanoseconds.
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDave Jones <davej@redhat.com>

With the release of the dual-core AMD Opterons last week,
it's high time that cpufreq supported them.  The attached
patch applies cleanly to 2.6.12-rc3 and updates powernow-k8
to support the latest Athlon 64 and Opteron processors.

Update the driver to version 1.40.0 and provide support
for dual-core processors.
Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: NDave Jones <davej@redhat.com>

This patch makes a needlessly global and EXPORT_SYMBOL'ed struct static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Jones <davej@redhat.com>

Some cpufreq drivers (at that time, only powernow-k7) need to recalibrate the
cpu_khz at runtime.
Signed-off-by: NBruno Ducrot <ducrot@poupinou.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDave Jones <davej@redhat.com>

We have to recalibrate cpu_khz in order to use the current FID instead the max
FID since some BIOS do not put the processor at maximum frequency at POST. 
Also, some BIOS will change the processor frequency at our back after cpu_khz
was calibrate.  Finally, this will fix a long standing bug when we do
something like this:

# rmmod powernow-k7
# modprobe powernow-k7
Signed-off-by: NBruno Ducrot <ducrot@poupinou.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDave Jones <davej@redhat.com>

From: Sean Young <sean@mess.org>
Signed-off-by: NDave Jones <davej@redhat.com>

This comes up time and time again. Until its fixed, place this
comment in the Kconfig which should stem the flow of resubmissions.
Signed-off-by: NRob Weryk <rjweryk@uwo.ca>
Signed-off-by: NDave Jones <davej@redhat.com>

The speedstep-smi driver actually works on >=1 notebook with a
Pentium 4-M CPU where all other cpufreq drivers fail. Therefore,
allow speedstep-smi on P4Ms again, but warn users of likely failure
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDave Jones <davej@redhat.com>