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>

Trivial ondemand governor clean-ups:
- change from sampling_rate_in_HZ() to the official function
usecs_to_jiffies().
- use for_each_online_cpu() to instead of using "if (cpu_online(i))"
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDave Jones <davej@redhat.com>

The Pentium 4 - Ms (HT) with CPUID 0xF34 and 0xF41 seem to support
centrino-like enhanced speedstep; however, no "table" support is possible.
Therefore, put NULL entries into speedstep-centrino.c
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDave Jones <davej@redhat.com>

cpufreq core is printing out messages at KERN_WARNING level that the core
recovers from without intervention, and that the system administrator can
do nothing about.  Patch below reduces the severity of these messages to
debug.
Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDave Jones <davej@redhat.com>

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

Signed-off-by: NEdgar E Iglesias <edgar@axis.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Firstly, if the direction is TODEVICE, then dirty data in the
streaming cache is impossible so we can elide the flush-flag
synchronization in that case.

Next, the context allocator is broken.  It is highly likely
that contexts get used multiple times for different dma
mappings, which confuses the strbuf flushing code and makes
it run inefficiently.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NThomas Graf <tgraf@suug.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>