panic: Fix a possible deadlock in panic()

panic_lock is meant to ensure that panic processing takes
place only on one cpu; if any of the other cpus encounter
a panic, they will spin waiting to be shut down.

However, this causes a regression in this scenario:

1. Cpu 0 encounters a panic and acquires the panic_lock
   and proceeds with the panic processing.
2. There is an interrupt on cpu 0 that also encounters
   an error condition and invokes panic.
3. This second invocation fails to acquire the panic_lock
   and enters the infinite while loop in panic_smp_self_stop.

Thus all panic processing is stopped, and the cpu is stuck
for eternity in the while(1) inside panic_smp_self_stop.

To address this, disable local interrupts with
local_irq_disable before acquiring the panic_lock. This will
prevent interrupt handlers from executing during the panic
processing, thus avoiding this particular problem.

Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
(cherry picked from commit dd58afef43357f265e803c317bbaa91f8c440663)

Change-Id: I5f7ebcf2a028df265a57922b6c959e686a82026a
Signed-off-by: Swetha Basineni <sbasin@codeaurora.org>
msm: kgsl: Map a guard page on the back of GPU MMU regions

Add a guard page on the backside of page_alloc MMU mappings to protect
against an over zealous GPU pre-fetch engine that sometimes oversteps the
end of the mapped region. The same phsyical page can be re-used for each
mapping so we only need to allocate one phsyical page to rule them all
and in the darkness bind them.

Change-Id: Ic0dedbad01e1eae5832bb79cc1446353656cf0af
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Optimize page_alloc allocations

User memory needs to be zeroed out before it is sent to the user.
To do this, the kernel maps the page, memsets it to zero and then
unmaps it.  By virtue of mapping it, this forces us to flush the
dcache to ensure cache coherency between kernel and user mappings.
Originally, the page_alloc loop was using GFP_ZERO (which does a
map, memset, and unmap for each individual page) and then we were
additionally calling flush_dcache_page() for each page killing us
on performance.  It is far more efficient, especially for large
allocations (> 1MB), to allocate the pages without GFP_ZERO and
then to vmap the entire allocation, memset it to zero, flush the
cache and then unmap. This process is slightly slower for very
small allocations, but only by a few microseconds, and is well
within the margin of acceptability. In all, the new scheme is
faster than the default for all sizes greater than 16k, and is
almost 4X faster for 2MB and 4MB allocations which are common for
textures and very large buffer objects.

The downside is that if there isn't enough vmalloc room for the
allocation that we are forced to fallback to a slow page by
page memset/flush, but this should happen rarely (if at all) and
is only included for completeness.

CRs-Fixed: 372638
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
(cherry picked from commit 89bd323f4b9c4c2382e5361c52f25f86db330583)

Change-Id: I160d23c25d7cae7b9d432f9f79945e01bcbe89e9
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
msm: kgsl: Align busy times with the end times of samples

Make sure that the busy times are calculated at the end of the
current sample and before the next sample starts. This prevents
false alarms of busy timer events being triggered. Applies only
to devices with idlestats power policy.

Signed-off-by: Ranjhith Kalisamy <ranjhith@codeaurora.org>
(cherry picked from commit 4018a9b5281e1c8bc41c3d54ff8d6d7c866434d0)

Change-Id: I5be7729eedca1e698cbb822342175e2b08b154b1
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>