[CPUFREQ] add sampling_down_factor tunable to improve ondemand performance

Adds a new global tunable, sampling_down_factor.  Set to 1 it makes no
changes from existing behavior, but set to greater than 1 (e.g. 100)
it acts as a multiplier for the scheduling interval for reevaluating
load when the CPU is at its top speed due to high load.  This improves
performance by reducing the overhead of load evaluation and helping
the CPU stay at its top speed when truly busy, rather than shifting
back and forth in speed.  This tunable has no effect on behavior at
lower speeds/lower CPU loads.

This patch is against 2.6.36-rc6.

This patch should help solve kernel bug 19672 "ondemand is slow".

Signed-off-by: David Niemi <dniemi@verisign.com>
Acked-by: Venkatesh Pallipadi <venki@google.com>
CC: Daniel Hollocher <danielhollocher@gmail.com>
CC: <cpufreq-list@vger.kernel.org>
CC: <linux-kernel@vger.kernel.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: interactive: add load based suspend

Some users reported that some background task won't
work as they worked before the new suspend/resume logic.

The easiest way would be to bump up suspend_freq to 600 Mhz,
but this would result in wasted cpu power and is also
not efficient. This patch tries to address the issue
with two approaches;

1.) The simple one
    Instead of boosting the cpu MAYBE to max_freq on
    resume, boost it in any case to 1 Ghz.

2.) The load balanced one
    Like in one of the previous implementation i added
    a cpu_load value. If we are suspended and above 85%
    cpu_load we scale to the next available frequency.

In my test scenario this ensured smooth audio-playback
as well as a fast wake up. Any wakeup delay should be now
in the hands of Android itself.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>