fix after mismerge

Change-Id: I6fc5d250147a061a3cdafb23f1176a491486afdc
d2: regenerate defconfig

PS 2: remove selinux config

PS 3: remove CONFIG_MSM_BAM_DMUX_NOLOCK for d2usc

Change-Id: I00399e3a54eac2dbfc7021810ad1ee36f1a2089a
Use hrtimers so that msleep() sleeps for the requested time

Current msleep() snoozes for at least two jiffies, causing msleep(1) to
sleep for at least 20ms on HZ=100 systems.  Using hrtimers allows
msleep() to sleep for something much closer to the requested time.

Change-Id: If06b4fa3f489eed073213c763755ec3b387129e1
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
msm_fb: use hr_msleep when timing DSI commands

Change-Id: I711e8f2343c1a4fcf164c5b8fabba08987eb1728
ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores

commit dbece45894d3ab1baac15a96dc4e1e8e23f64a93 upstream.

When enabling the MMU for ARMv7 CPUs, the decompressor does not touch
the ttbcr register, assuming that it will be zeroed (N == 0, EAE == 0).
Given that only EAE is defined as 0 for non-secure copies of the
register (and a bootloader such as kexec may leave it set to 1 anyway),
we should ensure that we reset the register ourselves before turning on
the MMU.

This patch zeroes TTBCR.EAE and TTBCR.N prior to enabling the MMU for
ARMv7 cores in the decompressor, configuring us exclusively for 32-bit
translation tables via TTBR0.

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Matthew Leach <matthew.leach@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: Remove ARMv3 support from decompressor

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:
	arch/arm/boot/compressed/head.S

Change-Id: Idd6fc7b98d4f98bcb474350a0d8997311236a08f
cpufreq: Add cpu-boost driver

When certain bursty and important events take place, it might take a while
for the current cpufreq governor to notice the new load and react to it.
That would result in poor user experience. To alleviate this, the cpu-boost
driver boosts the frequency of a CPU for a short duration to maintain good
user experience while the governor catches up.

Specifically, this commit deals with ensuring that when "important" tasks
migrate from a fast CPU to a slow CPU, the frequency of the slow CPU is
boosted to be at least as high as the fast CPU for a short duration.

Since this driver enforces the boost by hooking into standard cpufreq
ADJUST notifiers, it has several advantages:
- More portable across kernel versions where the cpufreq internals might
  have been rewritten.
- Governor agnostic and hence works with multiple governors like
  conservative, ondemand, interactive, etc.
- Does not affect the sampling period/logic of existing governors.
- Can have the boost period adjusted independent of governor sampling
  period.

Change-Id: Ibd814a20043d0aba64ee7637a4a79b9ffa1b0991
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
cpufreq: Add a sync limit to cpu-boost

Perform frequency synchronization only when source CPU's frequency
is less than sync_threshold, else sync to the sync_threshold.

Change-Id: I544c414568d4e015b80ce5891dd215275bac95da
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
sched: Fix clear NOHZ_BALANCE_KICK

I have faced a sequence where the Idle Load Balance was sometime not
triggered for a while on my platform, in the following scenario:

 CPU 0 and CPU 1 are running tasks and CPU 2 is idle

 CPU 1 kicks the Idle Load Balance
 CPU 1 selects CPU 2 as the new Idle Load Balancer
 CPU 2 sets NOHZ_BALANCE_KICK for CPU 2
 CPU 2 sends a reschedule IPI to CPU 2

 While CPU 3 wakes up, CPU 0 or CPU 1 migrates a waking up task A on CPU 2

 CPU 2 finally wakes up, runs task A and discards the Idle Load Balance
       task A quickly goes back to sleep (before a tick occurs on CPU 2)
 CPU 2 goes back to idle with NOHZ_BALANCE_KICK set

Whenever CPU 2 will be selected as the ILB, no reschedule IPI will be sent
because NOHZ_BALANCE_KICK is already set and no Idle Load Balance will be
performed.

We must wait for the sched softirq to be raised on CPU 2 thanks to another
part the kernel to come back to clear NOHZ_BALANCE_KICK.

The proposed solution clears NOHZ_BALANCE_KICK in schedule_ipi if
we can't raise the sched_softirq for the Idle Load Balance.

Change since V1:

- move the clear of NOHZ_BALANCE_KICK in got_nohz_idle_kick if the ILB
  can't run on this CPU (as suggested by Peter)

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1370419991-13870-1-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-commit: 873b4c65b519fd769940eb281f77848227d4e5c1
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[smuckle@codeaurora.org: minor merge resolution for 3.4 in scheduler_ipi()]
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Change-Id: I3548612057cccc2ecc29429c129c44183083831f
mm: vmscan: Move pages that fail swapout to LRU active list

Move pages that fail swapout to the LRU active list to reduce
pressure on swap device when swapping out is already failing.
This helps when using a pseudo swap device such as zram which
starts failing when memory is low.

Change-Id: Ib136cd0a744378aa93d837a24b9143ee818c80b3
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
msm: kgsl: Change an overflow check to be "smart" compiler proof

In its infinite wisdom, GCC will optimize out this overflow check:

   if ((gpuaddr + size) < gpuaddr)

Which might totally make sense for the compiler but it doesn't do us
a bit of good. Replace the existing overflow check with something
that GCC can't ignore.

CRs-fixed: 544025
Change-Id: Ic0dedbad921545a01d5fe80a20c3f2f4f86ef641
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Fix overflow check in mmap_range_valid

A eager compiler might optimize out the overflow check in
mmap_range_valid.  Add a check against ULONG_MAX to ensure
that the check is performed.

CRs-fixed: 546373
Change-Id: Ic0dedbad478cc3bd65a00a7b31d2039095c005d6
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Verify the user address before reading a perfcounter group

In adreno_perfcounter_read_group some user input verification is
occuring on a user pointer before copy_from_user is called
resulting in a possible segmentation fault if called with improper
input data.

CRs-fixed: 553314
Change-Id: Ic0dedbad4c5e4b2610368d51ff591d1f716712f4
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
clocksource: arm_arch_timer: Use clocksource for suspend timekeeping

The ARM architected timers keep counting during suspend so we can
mark this clocksource with the CLOCK_SOURCE_SUSPEND_NONSTOP. This
flag will indicate that this clocksource can be used for
calculating suspend time and injecting sleep time into the
timekeeping core. This will usually be more accurate than using
an external RTC or architecture specific persistent clock.

CRs-fixed: 536881
Change-Id: I882bf19a87ceb642aa069bbf26802c66c96b4426
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ASoC: msm: Fix for power collapse hostless usecase

For hostless pcm usecases apps processor is not needed
for data path. Once data path is established hostless
driver will remove the pm_qos_request to allow the host
CPU to power collapse. Change adds the support to remove
the pm_qos_request once data path is setup.

Change-Id: Ic6ac8d99628c770061ec785f8549c164f6a9bbd8
CRs-fixed: 561202
Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
BACKPORT: arm: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)

On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:

1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
   one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
   return code already).

The switch_mm() code includes a DMB operation since the IPI is only sent
to CPUs running the same ASID.

BUG=chromium:226280
TEST=There's unfortunately no simple test to trigger this bug, since it
normally manifests vaguely by random crashes or bad data later during
runtime. General testing to make sure it doesn't add new problems (i.e,
BVT, regression suites) is the best approach, followed by observations
of crash rates from the field.

Change-Id: I8fa68bdac9594a90d29079244efa93750f4319e3
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47427
Reviewed-by: Doug Anderson <dianders@chromium.org>

Conflicts:
	arch/arm/include/asm/mmu_context.h