defconfig: enable lz4 compress and decompress.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/configs/elementalx_defconfig
lib/decompress_unlz4.c: always set an error return code on failures

"ret", being set to -1 early on, gets cleared by the first invocation of
lz4_decompress()/lz4_decompress_unknownoutputsize(), and hence subsequent
failures wouldn't be noticed by the caller without setting it back to -1
right after those calls.

Reported-by: Matthew Daley <mattjd@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: hotplug: remove code related to cpu_killed

Earlier the completion event cpu_killed was used to synchronize
notify to hot plug framework that the CPU is dead. But now it is
replaced with another completion event cpu_died and it is placed
in the hotplug framework itself. So there is no need for a
platform to implement a completion event.

But in msm platform driver the completion event related code
was not removed with the changes in hotplug framework. This
patch removes the unused code.

Change-Id: I4418e5e397821e39a7b6a6efa997c4a866e9b46b
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>
msm: hotplug: Block hotplug removal of CPU0

Hotplug removal of CPU0 is not currently supported. Attempts to
remove it may result in undefined behaviour. Explicitly block
any such attempts before other hotplug notifiers get the chance
to run by setting the notifier priority to INT_MAX.

Change-Id: I9e1f5b4a0db554295a097220417f2bdf4c690f5f
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: reschedule early with the user chooses either 0 or 100 as the load_threshold for quad-core or dual-core respectively.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
mako_hotplug: if the device is input boosted ignore the condition to keep the cpu core online for extra 5 samples to avoid weird race conditions.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
cpufreq: interactive: make boosted a global var so that my hotplug driver can access it for a check.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: ondemand: Use hotplug thread infrastructure

The dbs_sync threads caused considerable load, even when ondemand
wasn't even active. Use the hotplug thread infrastructure to park
the threads.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
mako_hotplug: clean up some code, remove the high priority flag from the workqueue, don't see why we need it and on screen on instead of onlining all cores just online cpu1 and 1 second after screen on, at least for now to test.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
mako_hotplug: online cpu1 right after screen on instead of waiting 1 second. Also fix identations and remove blank spaces.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
mako_hotplug: instead of calculating the load every sample (which is kinda expensive) we can use the governors load calculation instead of trying to recreate the same thing (adding unecessary overhead). Also cleanup some code.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
mako_hotplug: we're getting the load from the governors, no need to increment the counter by 2 and we can increase the threshold to 70 to balance things out.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
mako_hotplug: fix a bug where cores would get stuck online caused by a wrong if check during an input boost case.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: clean up a little bit.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: we should care about very high load spikes so when the load
is 100% the core that is next in line is onlined, no questions asked.
It won't go through the 1s minimum time for a core to be online before
hotplug though.

hackbench -p -T:
Before: 1.816sec
After: 0.917sec

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: code revision

  * clean it up to remove clutter on the main function
  * move all the hard-work to the cpu_revive and cpu_smash wrappers
for code clarity
  * for load spikes instead of relying on a single sample on 100% load
the counter needs to be >= 2 to avoid spurious online calls

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
mako_hotplug: simplify whole process, I was not happy with the solution of cpu0->cpu2 / cpu1->cpu3 logic. And besides it created extra overhead.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	arch/arm/kernel/mako_hotplug.c
mako_hotplug: fix styling.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: fix a small bug.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: Persist cpufreq time in state data across hotplug

Cpufreq time_in_state data for all CPUs is made persistent across
hotplug and exposed to userspace via sysfs file
/sys/devices/system/cpu/cpufreq/all_time_in_state

Change-Id: I97cb5de24b6de16189bf8b5df9592d0a6e6ddf32
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: MassStash <MassStash@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_stats.c