Linux 3.4.84
msm: lpm_levels: update suspend stats counters and time

suspend stats in the debug pm stats are not getting updated as
suspend stats in the suspend wake path is missing. This change
will add and update the suspend stats in the suspend wake path.

CRs-fixed: 536881
Change-Id: I3b47511afb75926e51e82fc83929f405404fbf07
Signed-off-by: Anil kumar mamidala <amami@codeaurora.org>
ASoC: dapm: Unlock mutex in error cases

Dapm functions are not unlocking the mutex when an error
is encountered.This change fixes the mutex unlock issue.

Change-Id: Ia7ffaea9a30ae09a501f8f861c62c64d6c110d44
CRs-fixed: 613644
Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
ion: Add missing unlock on error path

A mutex_unlock was missing for the alloc_lock on an error
path. Add it.

Change-Id: If88b72fbc2fd18504347b784d5daa2bc9170c55f
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mm/compaction: Break out of loop on !PageBuddy in isolate_freepages_block

We received several reports of bad page state when freeing CMA pages
previously allocated with alloc_contig_range:

 BUG: Bad page state in process Binder_A  pfn:63202
 page:d21130b0 count:0 mapcount:1 mapping:  (null) index:0x7dfbf
 page flags: 0x40080068(uptodate|lru|active|swapbacked)

Based on the page state, it looks like the page was still in use. The page
flags do not make sense for the use case though. Further debugging showed
that despite alloc_contig_range returning success, at least one page in the
range still remained in the buddy allocator.

There is an issue with isolate_freepages_block. In strict mode (which CMA
uses), if any pages in the range cannot be isolated,
isolate_freepages_block should return failure 0. The current check keeps
track of the total number of isolated pages and compares against the size
of the range:

        if (strict && nr_strict_required > total_isolated)
                total_isolated = 0;

After taking the zone lock, if one of the pages in the range is not
in the buddy allocator, we continue through the loop and do not
increment total_isolated. If in the last iteration of the loop we isolate
more than one page (e.g. last page needed is a higher order page), the
check for total_isolated may pass and we fail to detect that a page was
skipped. The fix is to bail out if the loop immediately if we are in
strict mode. There's no benfit to continuing anyway since we need all
pages to be isolated. Additionally, drop the error checking based on
nr_strict_required and just check the pfn ranges. This matches with
what isolate_freepages_range does.

Change-Id: I2a8bc4d381ae35aa15a4d2a2424f0c2de801d9ba
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: kgsl: Fix memleak in IOMMU clock disable

IOMMU clock disable on timestamp allocates memory and passes
the pointer to event created, this memory should be freed
when the event fires.

Change-Id: Ia714550ce8a05958fb6668293cd0400a0f69d4af
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
msm: mpm-of: set wakeup interrupt as NO_SUSPEND

The MPM wakeup interrupt is used to wakeup the Apps processor from
a system wide low power mode when the GIC isn't operational.

The MPM interrupt is configured as a wakeup interrupt by calling into
irq_set_irq_wake().It also needs to be configured with the
IRQF_NO_SUSPEND to prevent the irq from getting disabled during
suspend_device_irqs() in the suspend path. The interrupt is not
re-enabled until after gic_suspend() is executed as a part of the
syscore_suspend() callback.

If the CPU's idle thread enters RPM assisted power collapse between
suspend_device_irqs() and syscore_suspend, the masking of the RPM wakeup
interrupt could prevent wakeup by RPM.

Change-Id: I0d5f0d7277774ddef6817eac10156f92174ec15f
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
qcom: mpm-of: fix bug in finding the pending interrupts

When APPS proc wakeup from RPM assisted PC states it reads
the vMPM status register to know the reason for wakeup and
retrigger the interrupts to handle it. Current code is not
caring about actual enabled interrupts in vMPM. Sometimes
this is causing APPS proc unnecessarily triggering the
interrupts which are not raised in the system. Fix this by
considering the enabled interrupts in vMPM before triggering
the interrupts.

CRs-fixed: 623293
Change-Id: Ia793e6d501cac3d85b51ed6e359703239a4b9945
Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
mmc: sdhci: finish the request if sdhc is in bad state

In the current code, if sdhci_check_state returns true a tasklet is
scheduled which doesn't complete the request if host->mrq is NULL,
which is the case, if sdhci is in bad state. This would make the
mmcqd thread wait for completion infinitely.
Hence, complete the request if sdhci_check_state returns true instead
of scheduling the tasklet.

CRs-Fixed: 615537
Change-Id: I8e2950c3999ac3806f9d631c52d86f0dc13b992f
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
msm: msm_bus: Introduce multi level BKE limiting.

Introduce multi level BKE throttling for BIMC masters. By specifying an
array of thresholds and limiting bandwidth values, multiple levels of
master throttling can be achieved.

Change-Id: Ic3b483d3e987266e8f37e66dff8bedd49ddd1d4d
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
ARM: dts: Modify BKE limiting for Krait master

Modify the BKE limiting properties for Krait master by setting up 2
levels of threshold checks and limiting bandwidth values to be applied.
These levels of throttling are needed in certain concurrency usecases to
protect real time masters from surges in bus usage from some APSS masters.

Change-Id: I04d086e10df27d0f7cc1a234fe9eb36a9ea73e65
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
Temporary disable Intelli-Plug
Build v3.11
Revert "dts: up cpu voltage for better stability"

This reverts commit d9410ad5464917656f4f5cc1f1155324f53fb69b.
Revert "dts: overclock CPU to 2.72Ghz"

This reverts commit ceb16853c636ecb476519d46038491ffb476858f.
dts: overclock CPU to 2.72Ghz
msm8974: Adapt memutils optimizations from msm8960pro

Preload farther to take advantage of the memory bus, and assume
64-byte cache lines.  Unroll some pairs of ldm/stm as well, for
unexplainable reasons.

Future enhancements should include,

- #define for how far to preload, possibly defined separately for
  memcpy, copy_*_user
- Tuning for misaligned buffers
- Tuning for memmove
- Tuning for small buffers
- Understanding mechanism behind ldm/stm unroll causing some gains
  in copy_to_user

BASELINE (msm8960pro):
======================================================================
memcpy 1000MB at 5MB       : took 808850 usec, bandwidth 1236.236 MB/s
copy_to_user 1000MB at 5MB : took 810071 usec, bandwidth 1234.234 MB/s
copy_from_user 1000MB at 5M: took 942926 usec, bandwidth 1060.060 MB/s
memmove 1000GB at 5MB      : took 848588 usec, bandwidth 1178.178 MB/s
copy_to_user 1000GB at 4kB : took 847916 usec, bandwidth 1179.179 MB/s
copy_from_user 1000GB at 4k: took 935113 usec, bandwidth 1069.069 MB/s
copy_page 1000GB at 4kB    : took 779459 usec, bandwidth 1282.282 MB/s

THIS PATCH:
======================================================================
memcpy 1000MB at 5MB       : took 346223 usec, bandwidth 2888.888 MB/s
copy_to_user 1000MB at 5MB : took 348084 usec, bandwidth 2872.872 MB/s
copy_from_user 1000MB at 5M: took 348176 usec, bandwidth 2872.872 MB/s
memmove 1000GB at 5MB      : took 348267 usec, bandwidth 2871.871 MB/s
copy_to_user 1000GB at 4kB : took 377018 usec, bandwidth 2652.652 MB/s
copy_from_user 1000GB at 4k: took 371829 usec, bandwidth 2689.689 MB/s
copy_page 1000GB at 4kB    : took 383763 usec, bandwidth 2605.605 MB/s
Enable memutils optimizations from msm8960pro
msm: rng: pass correct size to kzalloc

The size passed to kzalloc should be structure size
instead of pointer size.

Signed-off-by: Yuanyuan Zhong <zyy@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/548864
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Build v3.12