arm: mm: Add VM_ARM_EMPTY_MAPPING flag to mark the PMD gaps

ioremap optimization to return the addresses from the static mapping
if already present added the feature to add the pmd empty gaps into
the VM area but don't map such gaps in this commit "19b52abe3c5d".

This introduces the problem when the pfn is 0x0 and ends up into the
empty section gap found by the fill_pmd_gaps. If the driver calls
the ioremap(0, PAGE_SIZE) then it will return the address which is never
mapped, and access to that address will result in the crash.

To resolve this mark the empty PMD gaps with new flag VM_ARM_EMPTY_MAPPING
instead of the VM_ARM_STATIC_MAPPING, so that ioremap only checks
the VM_ARM_STATIC_MAPPING flag and skips over the VM_ARM_EMPTY_MAPPING
sections.

CRs-Fixed: 385828
Change-Id: I71e053f05abd2f611a6f17e7c86635404c31751e
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
ARM: gic: Refactor code for gic_configure_and_raise

Currently the offset and bit calculation in the function was
hardcoded for IPC1 interrupt. To support other secondary cores
we have to refactor the code to calculate the offset and bits
as per the cpu and interrupt number.

Change-Id: I33de8f185c219fb6a8e9d7f9676e958f27d54a12
Signed-off-by: Taniya Das <tdas@codeaurora.org>
ARM: gic: save/restore distributor ISR register values

Before going into power collapse we have to save/restore the ISR
registers in case we configure GIC to handle FIQ on apps side.
Otherwise we will end up in wrong ISR configurations after PC.

Change-Id: Ib58b701fc462c10ec88576feab3c8a9eb3027009
Signed-off-by: Taniya Das <tdas@codeaurora.org>
android: lowmemorykiller: add lmk parameters tunning code.

There are cases that LMK doesn't run, even when it must run.
It is due to LMK shrinker not considering memory status per zone.
So add LMK parameters(other_free, other_file) tunnig code to
consider target zone of LMK shrinker.

Change-Id: I6f1f8660d5da920a0e3af45a160499965032081d
Git-commit: 22d990a58fc17b3f0155e15eb2dc3efa037bea1c
Git-repo: https://android.googlesource.com/kernel/common/
[ohaugan@codeaurora.org: Fix compilation issues]
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
android/lowmemorykiller: Selectively count free CMA pages

In certain memory configurations there can be a large number of
CMA pages which are not suitable to satisfy certain memory
requests.

This large number of unsuitable pages can cause the
lowmemorykiller to not kill any tasks because the
lowmemorykiller counts all free pages.
In order to ensure the lowmemorykiller properly evaluates the
free memory only count the free CMA pages if they are suitable
for satisfying the memory request.

Change-Id: I7f06d53e2d8cfe7439e5561fe6e5209ce73b1c90
CRs-fixed: 437016
Signed-off-by: Liam Mark <lmark@codeaurora.org>
mmc: msm_sdcc: Check for unclocked register access in IRQ handler

After SDCC has been suspended and clocks turned off, an asynchronous
interrupt from an SDIO device will result in a call to the IRQ handler.
Since SDCC hardware registers are unclocked, a read of the status
register will result in an exception. Verify that clock to SDCC is on
before access in the IRQ handler.

CRs-Fixed: 424960
Change-Id: I81afd2dd5c5fa4785f11f2eec03e5b454b8f5dbe
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
block: row: Prevent starvation of regular priority by high priority

At the moment all REGULAR and LOW priority requests are starved as long as
there are HIGH priority requests to dispatch.
This patch prevents the above starvation by setting a starvation limit the
REGULAR\LOW priority requests can tolerate.

Change-Id: Ibe24207982c2c55d75c0b0230f67e013d1106017
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: row: Update sysfs functions

All ROW (time related) configurable parameters are stored in ms so there
is no need to convert from/to ms when reading/updating them via sysfs.

Change-Id: Ib6a1de54140b5d25696743da944c076dd6fc02ae
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: urgent request: Update dispatch_urgent in case of requeue/reinsert

The block layer implements a mechanism for verifying that the device
driver won't be notified of an URGENT request if there is already an
URGENT request in flight. This is due to the fact that interrupting an
URGENT request isn't efficient.
This patch fixes the above described mechanism in case the URGENT request
was returned back to the block layer from some reason: by requeue or
reinsert.

CRs-fixed: 473376, 473036, 471736
Change-Id: Ie8b8208230a302d4526068531616984825f1050d
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
hrtimer: Don't reinitialize a cpu_base's lock on CPU_UP

The current code makes the assumption that a cpu_base lock cannot
be held if a CPU is offline, which is tragically wrong.

If a hrtimer is not queued, then it will not be migrated by
migrate_hrtimers() when a CPU is offlined. Therefore, the
hrtimer's cpu_base may still point to a CPU which has
subsequently gone offline if the timer wasn't enqueued at the
time the CPU went down.

Normally this wouldn't be a problem, but a cpu_base's lock is
blindly reinitialized each time a CPU is brought up. If a CPU is
brought online during the period that another thread is
performing a hrtimer operation on a stale hrtimer, then the lock
will be reinitialized under its feet, and a SPIN_BUG() like the
following will be observed:

 [  448.212369] BUG: spinlock already unlocked on CPU#3,
 swapper/3/0
[  448.217368]  lock: 0xc47b1a40, .magic: dead4ead, .owner:
swapper/3/0, .owner_cpu: -1
[  448.217398] [<c0014398>] (unwind_backtrace+0x0/0x120) from
[<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc)
[  448.217419] [<c0269ab0>] (do_raw_spin_unlock+0x44/0xdc) from
[<c071bbb0>] (_raw_spin_unlock_irqrestore+0xc/0x38)
[  448.217438] [<c071bbb0>]
(_raw_spin_unlock_irqrestore+0xc/0x38) from [<c00aa498>]
(hrtimer_try_to_cancel+0xf8/0x10c)
[  448.217455] [<c00aa498>] (hrtimer_try_to_cancel+0xf8/0x10c)
from [<c00aa4bc>] (hrtimer_cancel+0x10/0x20)
[  448.217475] [<c00aa4bc>] (hrtimer_cancel+0x10/0x20) from
[<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0)
[  448.217494] [<c00e6934>] (rcu_idle_exit_common+0x5c/0xe0) from
[<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4)
[  448.217514] [<c00e6ae8>] (rcu_idle_exit+0x9c/0xb4) from
[<c000f2dc>] (cpu_idle+0x98/0xf0)
[  448.217529] [<c000f2dc>] (cpu_idle+0x98/0xf0) from
[<000081ac>] (0x81ac)

CRs-Fixed: 460670
Change-Id: I588f6a864054abe6d4c249aad815c6d2f5a54077
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
hrtimer: Consider preemption when migrating hrtimer cpu_bases

When switching to a new cpu_base in switch_hrtimer_base(), we
briefly enable preemption by unlocking the cpu_base lock in two
places. During this interval it's possible for the running thread
to be swapped to a different CPU.

Consider the following example:

CPU #0                                 CPU #1
----                                   ----
hrtimer_start()                        ...
 lock_hrtimer_base()
 switch_hrtimer_base()
  this_cpu = 0;
  target_cpu_base = 0;
  raw_spin_unlock(&cpu_base->lock)
<migrate to CPU 1>
...                                    this_cpu == 0
                                       cpu == this_cpu
                                       timer->base = CPU #0
                                       timer->base != LOCAL_CPU

Since the cached this_cpu is no longer accurate, we'll skip the
hrtimer_check_target() check. Once we eventually go to program
the hardware, we'll decide not to do so since it knows the real
CPU that we're running on is not the same as the chosen base. As
a consequence, we may end up missing the hrtimer's deadline.

Fix this by updating the local CPU number each time we retake a
cpu_base lock in switch_hrtimer_base().

Another possibility is to disable preemption across the whole of
switch_hrtimer_base.  This looks suboptimal since preemption
would be disabled while waiting for lock(s).

Change-Id: I3f76d528ab2288ef5f950f4d048e7f3fa6cf1228
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
hrtimer: Prevent enqueue of hrtimer on dead CPU

When switching the hrtimer cpu_base, we briefly allow for
preemption to become enabled by unlocking the cpu_base lock.
During this time, the CPU corresponding to the new cpu_base
that was selected may in fact go offline. In this scenario, the
hrtimer is enqueued to a CPU that's not online, and therefore
it never fires.

As an example, consider this example:

CPU #0                          CPU #1
----                            ----
...                             hrtimer_start()
                                 lock_hrtimer_base()
                                 switch_hrtimer_base()
                                  cpu = hrtimer_get_target() -> 1
                                  spin_unlock(&cpu_base->lock)
                                <migrate thread to CPU #0>
                                <offline>
spin_lock(&new_base->lock)
this_cpu = 0
cpu != this_cpu
enqueue_hrtimer(cpu_base #1)

To prevent this scenario, verify that the CPU corresponding to
the new cpu_base is indeed online before selecting it in
hrtimer_switch_base(). If it's not online, fallback to using the
base of the current CPU.

Change-Id: I6359cb299ba7e08abf25d3360fcdd925b4c03b69
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
msm: camera: Fix locking in msm_close

Change-Id: Id832a967f5f790a93102b7761285012d5231de7a
sec_debug: Forward-port SEC_DEBUG feature from Samsung

 * Forward port, fix warnings, fix ifdefs.
 * Very useful for debugging hard problems, no impact when disabled.
 * Also required to get correct ramdumps.

Change-Id: I375e0dcce83b717e5f1228925d7269c5197b2016