Revert "remove pronto test"

This reverts commit a0ef1d1a6a49be5f6ccf4f566755a89b07e2b327.
PM: devfreq: Use high priority workqueue

It does not make sense to run kgsl on high and devfreq on regular
priority.

Signed-off-by: flar2 <asegaert@gmail.com>
devfreq: cpubw: update to CAF kk_3.5

Change-Id: I2c0a066064137af4511972922ea6c40b2c1763b3
PM / devfreq: Add a new target flag for the performance governor

The new flag for the devfreq profile->target() function is used
by the performance governor to notify the driver that the device
should wakeup on the max frequency.

Change-Id: I91c2d649177bdd1841a087a2125d1cdbc979f5c1
Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Request based dm-crypt

dm-crypt provides bios based device mapper module. dm-crypt
operates on packets with 512 bytes size which is not effiicent
way for HW based crypto blocks. dm-req-crypt is developed to
address this. dm-req-crypt works on requests which carry upto
512KB of data for unmerged requests.

Change-Id: I479230b2f0c1ab2e2a1ddb84947ebaf0629dff8c
Signed-off-by: Dinesh K Garg <dineshg@codeaurora.org>

Conflicts:
	block/blk-core.c
	drivers/md/dm.c
	include/linux/blk_types.h
dm: updating crypto algorithm used by dm-req-crypt

dm-req-crypt uses AES-XTS algorithm implemented by HW crypto
engine. Crypto driver renamed the aes-xts algorithm to avoid
conflict with SW based implementation of AES-XTS. dm-req-crypt
must use the new name for AES-XTS provided by crypto driver.

Change-Id: I286b6435af33fd64673c7c1af4bb2447f3115868
Signed-off-by: Dinesh K Garg <dineshg@codeaurora.org>
dm: Adding support of AES 256 bits in dm-req-crypt

dm-req-crypt currently uses AES 128 bit. Updating dm-req-crypt
to use AES 256 bit instead.

Change-Id: I2e8a4484b25496d53f1f9aa83ec6c0ed7b947901
Signed-off-by: Dinesh K Garg <dineshg@codeaurora.org>
dm: Clean up dm-req-crypt

dm-req-crypt defines optional functions from device mapper. These
functions are not required for dm-req-crypt. dm-req-crypt has few
memory de-allocation issues. This change removes unnecessary
functions and fixes memory deallocation issues as well.

Change-Id: Id36bd13989940ce41571a8a10277730048df6f6d
Signed-off-by: Dinesh K Garg <dineshg@codeaurora.org>
[LINARO] regulator: core: Use the power efficient workqueue for delayed powerdown

There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.

Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
(cherry picked from commit 070260f07c7daec311f2466eb9d1df475d5a46f8)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
cpufreq: stockdemand: add stock caf ondemand with some enhancements

Signed-off-by: Lens-F <tnoah12@gmail.com>

Conflicts:
	arch/arm/configs/lemur_defconfig

Change-Id: I70ebc7915e999068fe03a1b6cd6c334a3186f7af
CHROMIUM: allow clocksources to be selected earlier during boot

Global and per-CPU timers ought to be initialized once SMP initialization
is complete.  Although the clocksources associated with these timers may
not be registered until later in the boot process, they should be ready
to go once registered.  We'd like to stop using the super low-resolution
boot clocksource (jiffies) as soon as possible since devices may rely on
accurate timekeeping while being brought up during boot, so move
clocksource_done_booting() to arch_initcall time so that we can switch
to a higher-resolution clocksrouce earlier in the boot process.

TEST=Pit and Lumpy both still boot reliably.  Boot time on Pit improves
considerably:
Before: [    3.032967] VFS: Mounted root ...
After:  [    1.855936] VFS: Mounted root ...
Lumpy boot time improves very slightly:
Before: [    1.786347] VFS: Mounted root ...
After:  [    1.754297] VFS: Mounted root ...

Signed-off-by: Lens-F <tnoah12@gmail.com>
ARM: 7493/1: use generic unaligned.h

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Lens-F <tnoah12@gmail.com>
scheduler: compute time-average nr_running per run-queue

Compute the time-average number of running tasks per run-queue for a
trailing window of a fixed time period. The detla add/sub to the
average value is weighted by the amount of time per nr_running value
relative to the total measurement period.

Change-Id: I076e24ff4ed65bed3b8dd8d2b279a503318071ff
Signed-off-by: Diwakar Tundlam <dtundlam@nvidia.com>
(cherry picked from commit 3a12d7499cee352e8a46eaf700259ba3c733f0e3)
Reviewed-on: http://git-master/r/111635
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Tested-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>

forward ported to Linux 3.4 for use on S-800

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

Conflicts:
	kernel/sched/core.c
	kernel/sched/sched.h