ramdisk-4.4: initial commit
- rebase for CM-based SELinux paid apps breakage
- move most tweaks to bootscript to keep things simple
ramdisk-4.3: initial commit
- move most tweaks to bootscript to keep things simple
track flashable zip files
video: omap2: displays: disable Content Adaptive Brightness by default
to workaround known reboot at screen-off issue on first boot Lockscreen
when disabled by tweaking apps
ARM: OMAP4: l2x0: Cleanup prefetch offset register setting

The bits [31:5] of Prefetch Offset Register are reserved in
PL310 r2p0 so they should be kept unchanged.
It's enough to set Data prefetch enable bit in PL310 auxiliary
control register to enable the feature, so setting of bit 28 of POR
is removed.
Before writing POR value, the bits [4:0] has to be cleared to remove
previous value.
ARM: OMAP4: l2x0: Set optimized value for prefetch offset

Tuning the value of prefetch offset register of PL310 cache controller
for OMAP4 family. The patch can give up to 4% better results in low level
benchmarks (like bw_mem at block size above 2 Mb) and up to 2% in benchmarks
imitating use cases (like Sunspider).
Note: if double line fill is enabled, the optimal value can be different.
OMAP4: do not force workarounds for errata fixed in 4460

Signed-off-by: Mans Rullgard <mans.rullgard at linaro.org>
Enable PL310 double linefill for Tuna board

Double linefill was disabled because of single cache line
corruption in first revisions of OMAP 4460. On Tuna board,
after extensive testing, no cache corruption cases were
observed.

Benchmarks (RgBandwidth, Antutu) show up to 45% performance
gains in memory bandwidth tests.

RgBandwidth (Threads: Auto, Test: Misc)

     Single Linefill   Double Linefill

Copy   1403.0 MB/s  ->  1826.6 MB/s
Scale  1386.8 MB/s  ->  1672.2 MB/s
Add    1227.7 MB/s  ->  1778.9 MB/s
Triad  1225.3 MB/s  ->  1746.2 MB/s
Tuna: set PL310 cache controller prefetch offset to 3

Now that double linefill is enabled the PL310 prefetch
offset needs re-evaluation. Benchmarks show that value
of 3 (or 4, close second) is the optimal value.

Performance gains in memory bandwidth tests up to 9%.

RgBandwidth (Threads: Auto, Test: Misc)

Copy   1826.6 MB/s  ->  1915.8 MB/s
Scale  1672.2 MB/s  ->  1812.7 MB/s
Add    1778.9 MB/s  ->  1905.3 MB/s
Triad  1746.2 MB/s  ->  1844.7 MS/s
Enable SCU Speculative linefills

By enabling SCU Speculative linefills in the SCU Control
Register, the  L2 cache access latency seems tp be reduced
a bit with an overall ~1.5% improvement.
tuna: Enable Cortex A9 optimizations

Enable Zero fills and tune speculative SCU line feeds for tuna board
Add sysfs vibrator intensity controls

Patch Set 2
    Removed unused variable

Patch Set 3
    Use pwm_old variable

Patch Set 4
    Add authorship
board-tuna-vibrator.c: Low vibrator dmesg log Spam
BMP180: Report temperature through ABS_MISC.
BMP180: Finish temperature reporting.
BMP180: Fix typo.
input: touchboost: I've tried a gazillion different ways to deal with input cpu-boost events, but in the end what really works for me and flawlessly is leaving the governor taking care of the cpu frequency changes. I'd rather have a global input register handler that feeds the governor with the touch input times in usecs and leave the boosting logic to the governor. CAF's cpu-boost code is half broken too so I'm not bothering with trying it again.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Merge remote-tracking branch 'upstream/nightlies-4.3' into sm-4.4