Comment out for now
Tweak lowmemorykiller, rubix's setting:
2048,3072,6144,15360,17920,20480
omap44xx: cpuidle: Update target residencies to saner values

The current values are insane.

There is no possible way power saving
can be attained by heading into C4 for not much more than 1ms. The average
values are in the 20ms range, so why do we need to even entertain entering
at much lower values when we will use more power than we save in doing so.

The actual recommended values are shown in 79e796f7b993bd82ad108fa488c35ddd1b9387eb
but for some obscure reason, in 16385c726d55f9e84bbc60ff9e329a84d56a13a3 and
22e2193661b6bffcfdc1a4d17f6af0d1782ba860 they were updated to match the exit_latency.

This seems horribly wrong to me as there comes a point when the target residency is
so low that you use more power actually entering the state than you gain from the
insignificant amount of time you spend there.

With the values in this commit, C4 state is used for >95% of the time when the screen
is off, with C3 picking up the remainder.
During audio playback, C4 is used ~50% of the time, C3 is used ~25% of the time and C2
picks up whatever is left.
cpuidle: Add last_residency trace event for residency profiling
omap4: cpuidle: Some obvious optimisations to the code path
OMAP4: Workaround the OCP synchronisation issue with 32K synctimer.

Backport from:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;
a=commitdiff;h=68523f4233de5f233478dde0a63047b4efb710b8

Original comment:
On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value read from 32K sync timer
IP when the IP is comming out of idle.

The issue is due to the synchronization methodology used in the SYNCTIMER IP.
The value of the counter register in 32kHz domain is synchronized to the OCP
domain register only at count up event, and if the OCP clock is switched off,
the OCP register gets out of synch until the first count up event after the
clock is switched back -at the next falling edge of the 32kHz clock.

Further investigation revealed that it applies to gptimer1 and watchdog timer2
as well which may run on 32KHz. This patch fixes the issue for all the
applicable modules.

The BUG has not made it yet to the OMAP errata list and it is applicable to
OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps.

By enabling static depedency of wakeup clockdomain with MPU, as soon as MPU
is woken up from lowpower state(idle) or whenever MPU is active, PRCM forces
the OCP clock to be running and allow the counter value to be updated properly
in the OCP clock domain.

The bug is going to fixed in future OMAP versions.

Change-Id: I3c7ff239c3dcac180fcae50c1b909d417b2b8e16
Reported-Tested-by: dave.long@linaro.org
[dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer
and helped to test this patch]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
(cherry picked from commit 73152a98a25392a451bb0d588a1fbe2796b3c909)
Proportional Rate Reduction for TCP.

This patch implements Proportional Rate Reduction (PRR) for TCP.
PRR is an algorithm that determines TCP's sending rate in fast
recovery. PRR avoids excessive window reductions and aims for
the actual congestion window size at the end of recovery to be as
close as possible to the window determined by the congestion control
algorithm. PRR also improves accuracy of the amount of data sent
during loss recovery.

The patch implements the recommended flavor of PRR called PRR-SSRB
(Proportional rate reduction with slow start reduction bound) and
replaces the existing rate halving algorithm. PRR improves upon the
existing Linux fast recovery under a number of conditions including:
  1) burst losses where the losses implicitly reduce the amount of
outstanding data (pipe) below the ssthresh value selected by the
congestion control algorithm and,
  2) losses near the end of short flows where application runs out of
data to send.

As an example, with the existing rate halving implementation a single
loss event can cause a connection carrying short Web transactions to
go into the slow start mode after the recovery. This is because during
recovery Linux pulls the congestion window down to packets_in_flight+1
on every ACK. A short Web response often runs out of new data to send
and its pipe reduces to zero by the end of recovery when all its packets
are drained from the network. Subsequent HTTP responses using the same
connection will have to slow start to raise cwnd to ssthresh. PRR on
the other hand aims for the cwnd to be as close as possible to ssthresh
by the end of recovery.

A description of PRR and a discussion of its performance can be found at
the following links:
- IETF Draft:
    http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
- IETF Slides:
    http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
    http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
- Paper to appear in Internet Measurements Conference (IMC) 2011:
    Improving TCP Loss Recovery
    Nandita Dukkipati, Matt Mathis, Yuchung Cheng

Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a262f0cdf1f2916ea918dc329492abb5323d9a6c)
Raise 1.5-1.7~ GHz voltages
Merge branch 'zen-tune'
Merge branch 'misc-3.0'

Conflicts:
	arch/arm/mach-omap2/cpuidle44xx.c
Merge branch 'ricer-v2'
Some cleanups to zen I/O scheduler
Adjust zen comments
Merge branch 'IO_cpufreq'

Conflicts:
	block/zen-iosched.c
Update defconfig