ARM: mm: Add v7_flush_dcache_by_level() API.

On ARMv7 based SOC with an integrated L2 cache, there is a need
to have a flush API to operate on each cache level. In few low power
modes, L2 cache is retained where as L1 is lost. The current
v7_flush_dcache_all(), flushes all the levels and
it would be quite expensive.

So introduce v7_flush_dcache_by_level() API which takes a
parameter (cache level), and flush only on that level.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: mm: Flush only CPU local cache instead of all cache levels.

The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention here is to start
with clean CPU local cache.

But on architectures like Cortex-[A15/A8], this code will end
up flushing the L2 cache as well which undesirable and incorrect.
The setup functions are used in CPU hotplug scenario's too and
hence flushing all cache levels should be avoided.

Fix this code by restricting the cache flush to local cpu
cache or L1.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
max8997_vibrator: /sys/vibrator/vibrator_level

enable:
echo 9 > /sys/vibrator/vibrator_level
cat /sys/vibrator/vibrator_level

disable:
echo -1 > /sys/vibrator/vibrator_level
cat /sys/vibrator/vibrator_level

Conflicts:
	drivers/motor/max8997_vibrator.c
net / netfilter: remove annoying 'comparison will always be true' warning

-adding a new function which avoids this warning
-using the new function in all places where it makes no sense to check

+FIX: fs/sync.c
fs/sync.c:25:1: warning: function declaration isn't a prototype

Conflicts:
	fs/sync.c
3.1
implemented BFQ-v5r1 block IO scheduler and updates

Conflicts:
	block/Kconfig.iosched
	block/Makefile

block: update BFQ I/O scheduler to v6r2 for 3.0.y

BFQ uses struct cfq_io_context to store its per-process per-device data,
reusing the same code for cic handling of CFQ.  The code is not shared
ATM to minimize the impact of these patches.

This patch introduces a new hlist to each io_context to store all the
cic's allocated by BFQ to allow calling the right destructor on module
unload; the radix tree used for cic lookup needs to be duplicated
because it can contain dead keys inserted by a scheduler and later
retrieved by the other one.

Update the io_context exit and free paths to take care also of
the BFQ cic's.

Change the type of cfqq inside struct cfq_io_context to void *
to use it also for BFQ per-queue data.

A new bfq-specific ioprio_changed field is necessary, too, to avoid
clobbering cfq's one, so switch ioprio_changed to a bitmap, with one
element per scheduler.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

Implement Update BFQ v6r2 -> v7r2 I/O sched for 3.0
Getting ready to test -O3 GCC Optimizations.

Conflicts:
	Makefile

Conflicts:
	Makefile
Enable -O3 Kernel Code Optimizations + Fixes!

net/ipv4/tcp_input.c: In function âp_data_queueânet/ipv4/tcp_input.c:4417:49: warning: array subscript is above array bounds [-Warray-bounds]
     tp->selective_acks[i-1] = tp->selective_acks[i];

drivers/md/bcache/bset.c: In function âh_btree_sort_partialâdrivers/md/bcache/bset.c:1076:19: warning: array subscript is above array bounds [-Warray-bounds]
    keys += b->sets[i].data->keys;

Conflicts:
	arch/arm/configs/dorimanx_defconfig
	drivers/md/bcache/bset.c

Conflicts:
	arch/arm/configs/kernel_defconfig
pegasusq (based on ondemand): cpuidle detection

I found a problem with the ondemand governor while in earlysuspend
suspend mode (ondemand keeping the freq close to the max at all times
despite near 0% load). The problem is that the cpu starts to go in
long cpuidle cycles, a sampling_rate of 10000 (usec) is applied only
once in a while and the real sampling_rate becomes 1 second (or more).

So when a wakeup happens we return to the 10000usec sampling rate. The
ondemand sees lots of activity after the wakeup but those "loads" must
be adjusted down if the previous wall_time delta was huge and the
current one is tiny. We're too close to long cpuidle to worry about
the cpu freq anyway and it may be just a jitter load that if we take
into account without adjusting it down, will lead to the next long
cpuidle to be entered at the max freq again, and this repeats forever.

So my solution is to tweak the ondemand to scale down the "load"
according to the decrease in the wall_time delta ratio
(deep_sleep_ratio variable). This allows the CPU to stay at the lowest
freq during the deep sleeps even when the ondemand governor is enabled
and the sampling_rate is set to 10000. (setting the sampling_rate to
values >100000 would also tend to hide the problem but it'd screw the
interactive behavior by running at the lowest frequency for too long
during interactive usage)

During interactive usage with the screen on (not in earlysuspend
mode), or during playback or voip with screen off the deep_sleep_rate
is set to 1 practically all the time so it won't alter the behavior of
the ondemand governor unless the system is very idle (and in turn when
we want it to stay at low freq).

Change-Id: If0391e6d6c41c1c8c9fa590502e88e681a800b04

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>