cpufreq: interactiveX V4: limit max freq when screen off

screen_off_max configurable via sysfs - default 1267200
cpufreq: ondemandX - screen_off_maxfreq support

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: ondemand: set screen off max freq to 2.2ghz

*restore stock behavior
cpufreq: don't go above 2.27ghz when adding device
cpufreq: make thermal-engine play nicely with OC

* not perfect yet but should do for now

Conflicts:

	drivers/cpufreq/cpufreq.c
clock-krait/cpufreq: custom voltage control v1

* TODO: control only available frequencies
cpufreq: set policy max properly

* how did this ever work?
cpufreq: cpu-boost: Use hotplug thread infrastructure

Before this patch, thread migration ran in uninterruptible threads.
Use the relatively new hotplug thread infrastructure with parked
threads to reduce cpu load (x4).

Change-Id: I4fa1f3a6d6b2b68ecb6e751678584f24abd85992
cpufreq: interactiveX V4: limit max freq when screen off

screen_off_max configurable via sysfs - default 2.27ghz
cpufreq: Sync on thread migration optimizations

When threads migrate between CPUs the destination CPU will temporarily
have a boosted frequency and the source CPU will have a residual higher
frequency even though the load could have just been reduced. To avoid
leaving CPUs at a high frequencies notify the source CPU after a thread
migration and make the interactive governor's timer reschedule
conditionally.

Change-Id: Id55055f2a116ca7ffd2a34dc3d0ec519c888a111
Signed-off-by: Patrick Cain <pcain@codeaurora.org>
Forced Fast Charge for Samsung Note 3 v1.1 by Yank555.lu

- redone fast charge for new KK kernel sourcedrop

SysFS interface :

 * /sys/kernel/fast_charge/force_fast_charge (rw)
 *
 *   0 - disabled (default)
 *   1 - substitute AC to USB
 *   2 - use custom mA configured through sysfs interface (see below)
 *
 * /sys/kernel/fast_charge/ac_charge_level (rw)
 *
 *   rate at which to charge when on AC (1.0A/h to 2.1A/h)
 *
 * /sys/kernel/fast_charge/usb_charge_level (r/w)
 *
 *   rate at which to charge when on USB (0.460A/h to 1.0A/h)
 *
 * /sys/kernel/fast_charge/failsafe (rw)
 *
 *   0 - disabled - allow anything up to 2.1A/h to be used as AC / USB custom current
 *   1 - enabled  - behaviour as described above (default)
 *
 * /sys/kernel/fast_charge/ac_levels (ro)
 *
 *   display available levels for AC (for failsafe enabled mode)
 *
 * /sys/kernel/fast_charge/usb_levels (ro)
 *
 *   display available levels for USB (for failsafe enabled mode)
 *
 * /sys/kernel/fast_charge/version (ro)
 *
 *   display fast charge version information
 *
 * /sys/kernel/fast_charge/info (ro)
 *
 *   display complete fast charge configuration in human readable format

Credits to Chad Froebel <chadfroebel@gmail.com> for the base idea.
cpufreq: OC up to 2.5GHz (Yank555.lu)

- added 2.34GHz, 2.42 GHz and 2.50GHz step
- max. voltage increased from 1100000 to 1200000 microVolt
Build Beta 1
Optimized ARM RWSEM algorithm

RWSEM implementation for ARM using atomic functions.
Heavily based on arch/sh/include/asm/rwsem.h

Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>
arm/crypto: Add optimized AES and SHA1 routines

Add assembler versions of AES and SHA1 for ARM platforms.  This has provided
up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.

Platform   CPU SPeed    Endian   Before (bps)   After (bps)   Improvement

IXP425      533 MHz      big     11217042        15566294        ~38%
KS8695      166 MHz     little    3828549         5795373        ~51%

Signed-off-by: David McCullough <ucdevel@gmail.com>
Signed-off-by: faux123 <reioux@gmail.com>
arm: Add support for LZ4-compressed kernel

Date	Tue, 26 Feb 2013 15:24:29 +0900

This patch integrates the LZ4 decompression code to the arm pre-boot code.
And it depends on two patchs below

lib: Add support for LZ4-compressed kernel
decompressor: Add LZ4 decompressor module

Signed-off-by: Kyungsik Lee <kyungsik.lee@lge.com>

v2:
- Apply CFLAGS, -Os to decompress.o to improve decompress
  performance during boot-up process

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: mm: rename jump labels in v7_flush_dcache_all function

This patch renames jump labels in v7_flush_dcache_all in order to define
a specific flush cache levels entry point.

TODO: factor out the level flushing loop if considered worthwhile and
      define the input registers requirements.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API

When a CPU is hotplugged out caches that reside in its power domain
lose their contents and so must be cleaned to the next memory level.

Currently, __cpu_disable calls flush_cache_all() that for new generation
processor like A15/A7 ends up cleaning and invalidating all cache levels
up to Level of Coherency, which includes the unified L2.

This ends up being a waste of cycles since the L2 cache contents are not
lost on power down.

This patch updates __cpu_disable to use the new LoUIS API cache operations.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API

The ARMv7 processor setup function __v7_setup() cleans and invalidates the
CPU cache before enabling MMU to start the CPU with a clean CPU local cache.

But on ARMv7 architectures like Cortex-[A15/A8], this code will end
up flushing the L2 caches(up to level of Coherency) which is undesirable
and expensive. The setup functions are used in the CPU hotplug scenario too
and hence flushing all cache levels should be avoided.

This patch replaces the cache flushing call with the newly introduced
v7 dcache LoUIS API where only cache levels up to LoUIS are cleaned and
invalidated when a processors executes __v7_setup which is the expected
behavior.

For processors like A9 and A5 where the L2 cache is an outer one the
behavior should be unchanged.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: move VFP init to an earlier boot stage

In order to use the NEON unit in the kernel, we should
initialize it a bit earlier in the boot process so NEON users
that like to do a quick benchmark at load time (like the
xor_blocks or RAID-6 code) find the NEON/VFP unit already
enabled.

Replaced late_initcall() with core_initcall().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>

Signed-off-by: Paul Reioux <reioux@gmail.com>