OC and voltage control and KT versioning (ktoonsez)
Dont let limiter override user MAX freq

(cherry picked from commit 95c083c1fdaad3437a67ff7a5512cf1403f6d3dc)
Bump up minimum bandwidth for a few OC steps from twistedumbrella

(cherry picked from commit 74f620110972c599369d41359f87170b09481a47)
Add KThermal

(cherry picked from commit 433bb2672ab4e4ff227d24469c92450d62fe34e2)
Add KT Hotplug

(cherry picked from commit c981ce99f2a0b05b49cf76ed8ee7bac6c6b0aa70)
Fast charge from my S4 and S5 code plus removal of alot of dmesg spam

(cherry picked from commit 128616d0a2c0c6542e58de57c8366e50dd9fd280)
rmnet: Good-bye moronic idiotic read/write buffer dump

(cherry picked from commit a4aeaab73794ec172738315633f2cd54d1af4087)
Add variant detection

(cherry picked from commit 25bac2231ca23bbe9348e2386e0c54be06380889)
Add a butt load of tcp congestion control options

(cherry picked from commit 8d28d45a573e4e9a5b5eadba205944e49de2c8bc)
f2fs: Enable it

(cherry picked from commit 4a04d6b78bee0d7b8184e59dfc2b54532e152a80)
defconfig: Add missing TMO flags

(cherry picked from commit 8b8c6905f1ac069195bb10c0daa08dc2f1ffefc2)
Enable last_kmsg and increase log buffer shift plus add pr_alert when last_kmsg is not initialized

(cherry picked from commit 308b5ec6582052e78bec0b0fea45a4dee20daf1d)
cpufreq: Just a bunch of crap trying to debug cpu_up() not working in Linux 3.10 and making max freq obey

(cherry picked from commit 3f488867b1b23edf0103624b9c83e0941ba0d8b9)
devfreq: Re-enable simple_ondemand. Also fix simple_ondemand crashing

(cherry picked from commit 1100a7df63ae81eb4deb19f265ba5465e13e636f)
cpufreq:  Bring in KTOONSERVATIVEQ along with battery hooks, gpu hoos, screen on-off hooks and bunch of mods to cpufreq.c to try and get multicore control going (unsuccessful)

(cherry picked from commit 11fce4a76c2d0c4f017be8b6fa50f7470e499ad7)
sched: Add bfq scheduler

(cherry picked from commit 674232cb60c87047192e40948270e5091e603675)
mdss: implement panel color control

Adapted and modified work by CM-10.2, morfic and ktoonsez

Creates a syfs interface here:
/sys/class/lcd/panel/panel_colors

Will accept 0-4 for parameters:
0 - Cold (more blues)
1 - Cool
2 - Normal (stock colors)
3 - Warm
4 - Hot (more reds)

(cherry picked from commit e3548519c119be79073ac0de24a4fdaee7167f9b)
mdss: Modify panel_color code to apply color change without cycling screen

(cherry picked from commit 19dbe944d44367f5d42c1b41134b3659f52a53b8)
Enable music/media and bluetooth hooks for min/max Mhz and hotplugging

(cherry picked from commit d54758f6b1692ce899f91f9756549d812f8c0543)
sync: don't block the flusher thread waiting on IO

When sync does it's WB_SYNC_ALL writeback, it issues data Io and
then immediately waits for IO completion. This is done in the
context of the flusher thread, and hence completely ties up the
flusher thread for the backing device until all the dirty inodes
have been synced. On filesystems that are dirtying inodes constantly
and quickly, this means the flusher thread can be tied up for
minutes per sync call and hence badly affect system level write IO
performance as the page cache cannot be cleaned quickly.

We already have a wait loop for IO completion for sync(2), so cut
this out of the flusher thread and delegate it to wait_sb_inodes().
Hence we can do rapid IO submission, and then wait for it all to
complete.

Effect of sync on fsmark before the patch:

FSUse%        Count         Size    Files/sec     App Overhead
.....
     0       640000         4096      35154.6          1026984
     0       720000         4096      36740.3          1023844
     0       800000         4096      36184.6           916599
     0       880000         4096       1282.7          1054367
     0       960000         4096       3951.3           918773
     0      1040000         4096      40646.2           996448
     0      1120000         4096      43610.1           895647
     0      1200000         4096      40333.1           921048

And a single sync pass took:

  real    0m52.407s
  user    0m0.000s
  sys     0m0.090s

After the patch, there is no impact on fsmark results, and each
individual sync(2) operation run concurrently with the same fsmark
workload takes roughly 7s:

  real    0m6.930s
  user    0m0.000s
  sys     0m0.039s

IOWs, sync is 7-8x faster on a busy filesystem and does not have an
adverse impact on ongoing async data write operations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

(cherry picked from commit e9a6566fdaa3722e2960e2ee3ca33ba11b4b1886)