Revert "cpufreq: smartmax: Move get_cpu_idle_time() to cpufreq.c"

This reverts commit 5df400b010bd0ba5cdb4a0641eeb33504113614c.

Change-Id: Ibac6700ecadd02cdc407bfa18746eca1fba823f7
drivers: tfa9887: Update TFA9887 AMP driver

* HTC kernel package memul-3.4.0-ga072f6c

Change-Id: I26f92fb9243e25d21f8952936db42969cf7e13e0
Cpufreq: interactive: Check actual freq before setting new freq

In case Actual freq is not updated till next timer interrupt
and new target freq comes same as actual freq.
Don't go for setting same frequency again.

Bug 1316765

Reviewed-on: http://git-master/r/249103
(cherry picked from commit d5a4d9622c27db40334ba2df3503c2d2e7457bcb)

Change-Id: If81786911fd85adb8469b49c59f2ab70ae12f96a
Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: http://git-master/r/254352
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
cpufreq: interface for setting governor for a cpu

This implementation sets governor for a cpu using existing
cpufreq interfaces.

bug 871958

Change-Id: I63e2875b94a4bf9a27e9bf295acb5b967ce11a3b
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: http://git-master/r/97939
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
ARM: 7536/1: smp: Formalize an IPI for wakeup

Remove the offset from ipi_msg_type and assume that SGI0 is the
wakeup interrupt now that all WFI hotplug users call
gic_raise_softirq() with 0 instead of 1. This allows us to
track how many wakeup interrupts are sent and also removes the
unknown IPI printk message for WFI hotplug based systems.

Change-Id: If1c4eabd365d9b4e89d55c97db2b4b405d6848a2
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: cleanup undefined instruction entry code

We don't need to keep reloading the thread into into r10 - we can do
this once and keep the value cached in the register.  Also, schedule
some instructions better so that the pipeline doesn't stall after a
load in the neon code.

Change-Id: I42ba8e20641efcb7f3108f74d570199f7b0271ec
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: mm: Remove unnecessary CMO in Cortex A15 startup

Cortex-A15 flush L2 cache after reset, there is no need to do this
in software, if L2 is already invalidated in bootloader and
cache is disabled. For secondary startup, there is no reason to
flush L2 as well.

This change assumes the setup code is always entered as the result
of CPU reset.

Change-Id: I6d58f8b4a638b70acfb35b97c87a09266aceef41
Signed-off-by: Bo Yan <byan@nvidia.com>
Reviewed-on: http://git-master/r/170563
Reviewed-by: Mrutyunjay Sawant <msawant@nvidia.com>
Tested-by: Mrutyunjay Sawant <msawant@nvidia.com>
ARM: mm: Skip I-cache invalidate for Cortex-A15 boot

This is not required since cache is invalidated by HW in the reset
sequence. Bootloader is supposed to do the same before it hands
over control to kernel.

Change-Id: I0991de3ba1015a32f2c49a0333fd0b17a51a4f31
Signed-off-by: Bo Yan <byan@nvidia.com>
Reviewed-on: http://git-master/r/197028
(cherry picked from commit 9c49ffd08d6da03caa820711db83f561d9333aee)
Reviewed-on: http://git-master/r/200854
GVS: Gerrit_Virtual_Submit
Reviewed-by: Seshendra Gadagottu <sgadagottu@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
freezer: set PF_SUSPEND_TASK flag on tasks that call freeze_processes

Calling freeze_processes sets a global flag that will cause any
process that calls try_to_freeze to enter the refrigerator.  It
skips sending a signal to the current task, but if the current
task ever hits try_to_freeze, all threads will be frozen and the
system will deadlock.

Set a new flag, PF_SUSPEND_TASK, on the task that calls
freeze_processes.  The flag notifies the freezer that the thread
is involved in suspend and should not be frozen.  Also add a
WARN_ON in thaw_processes if the caller does not have the
PF_SUSPEND_TASK flag set to catch if a different task calls
thaw_processes than the one that called freeze_processes, leaving
a task with PF_SUSPEND_TASK permanently set on it.

Threads that spawn off a task with PF_SUSPEND_TASK set (which
swsusp does) will also have PF_SUSPEND_TASK set, preventing them
from freezing while they are helping with suspend, but they need
to be dead by the time suspend is triggered, otherwise they may
run when userspace is expected to be frozen.  Add a WARN_ON in
thaw_processes if more than one thread has the PF_SUSPEND_TASK
flag set.

Reported-and-tested-by: Michael Leun <lkml20130126@newton.leun.net>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 2b44c4db2e2f1765d35163a861d301038e0c8a75)
Change-Id: I12e00d2ba61db827c07b8f4ef48e88a722f02d71
Reviewed-on: http://git-master/r/259126
Reviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Tested-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
FIX warning: the frame size of 1104 bytes is larger than 1024 bytes

[-Wframe-larger-than=]

Change-Id: I9b9c4faa0d03fea122dda3c9260b8f7cf8965c3b
msm: msm_bus: Suspected fix for deadlock

mutex is not released while checking for
null pdata which can lead to possible deadlock
condition.

Change-Id: I1dc3efd725df5bb75c96434a81d9a8f3f868cd0a
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
cpufreq: slim: add new governor and adpt it for new cm branch

Change-Id: Ia75f59cb90087732e31ca24602f58e0fe9906845
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
arm: don't call try_to_freeze() from do_signal()

get_signal_to_deliver() will handle it itself

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-on: http://gerrit.pcs.mot.com/625802
Submit-Approved: Jira Key <jirakey@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Reviewed-by: Christopher Fries <c.fries@motorola.com>

Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>

Change-Id:I7b3c1a72526a4f4e271721117ceaa3ae7be16269
msm: memutils: 8974: memcpy, memmove optimization

According to tune result, change preload distance to 10
cache lines for 8974.
And considering bkk-b is sharing code for 8974, 8226, 8x16,
we seperate the code for 8974 specially.

The markable improvement:
    memcpy : 67%
    copy_to_user : 37%
    copy_from_user : 37%
    memmove : 70%

Raw data is as below:

BEFORE:
	memcpy 1000MB at 5MB       : took 659744 usec, bandwidth 1515.515 MB/s
	copy_to_user 1000MB at 5MB : took 681202 usec, bandwidth 1467.467 MB/s
	copy_from_user 1000MB at 5M: took 682052 usec, bandwidth 1466.466 MB/s
	memmove 1000GB at 5MB      : took 763133 usec, bandwidth 1310.310 MB/s
	copy_to_user 1000GB at 4kB : took 714487 usec, bandwidth 1399.399 MB/s
	copy_from_user 1000GB at 4k: took 699861 usec, bandwidth 1428.428 MB/s
	copy_page 1000GB at 4kB    : took 634857 usec, bandwidth 1575.575 MB/s
	memmove 1000GB at 4kB      : took 791389 usec, bandwidth 1263.263 MB/s
	memcpy 1000MB at 5MB       : took 659744 usec, bandwidth 1515.515 MB/s

AFTER:
	memcpy 1000MB at 5MB       : took 395178 usec, bandwidth 2530.530 MB/s
	copy_to_user 1000MB at 5MB : took 497667 usec, bandwidth 2009.009 MB/s
	copy_from_user 1000MB at 5M: took 496832 usec, bandwidth 2012.012 MB/s
	memmove 1000GB at 5MB      : took 449217 usec, bandwidth 2226.226 MB/s
	copy_to_user 1000GB at 4kB : took 489006 usec, bandwidth 2044.044 MB/s
	copy_from_user 1000GB at 4k: took 483982 usec, bandwidth 2066.066 MB/s
	copy_page 1000GB at 4kB    : took 377170 usec, bandwidth 2651.651 MB/s
	memmove 1000GB at 4kB      : took 483015 usec, bandwidth 2070.070 MB/s

Change-Id: I678d418b15701efea902efae9b94490993d53f37
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
Reviewed-on: http://gerrit.mot.com/634422
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
SLTApproved: Christopher Fries <c.fries@motorola.com>
Reviewed-by: John Zafiris <johnz@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
cpufreq: interactive: don't schedule timer on offline cpu

It shall not add timer on an offline CPUs, else it will cause
kernel panic.

And also don't reschedule the timer on an offline cpu in idle
and timer callback. Actually the timer shall be cancelled when
cpu is offline.

Change-Id: Id314f15be3d12ab49e5cdcf6ae89bd88b376308a
Signed-off-by: Lianwei Wang <a22439@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/539160
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
Fine tune Smartmax

Change-Id: Iadd960b92cef814cd9c3d931a0c2ce652345c477
cpufreq: cpufreq_smartmax: set global RW writeable for all and fix min_sampling_rate

Change-Id: I60069a65d05f48a45a95db124ed82643e25c21f7
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
deadline: update settings to match franco

Conflicts:
	block/deadline-iosched.c

Change-Id: I6229dc790b494ecbbad2c2f8a2ffa9a934559203