msm: mpm: Print interrupts which are not monitorable.

This patch is to print the non mpm monitarable interrupts
which are enabled but not released to allow power collapse.
Intead of printing bitmap of such irqs, print the irq number
and owner which is more meaningfull for debug.

Change-Id: I8a87984560afe83330657569ffc5de6ba629ae52
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
ARM: Fix negative idle stats for offline cpu
ARM: mm: implement LoUIS API for cache maintenance ops

ARM v7 architecture introduced the concept of cache levels and related
control registers. New processors like A7 and A15 embed an L2 unified cache
controller that becomes part of the cache level hierarchy. Some operations in
the kernel like cpu_suspend and __cpu_disable do not require a flush of the
entire cache hierarchy to DRAM but just the cache levels belonging to the
Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
correspond to L1.

The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.

Therefore a new kernel cache maintenance API must be added to cope with
latest ARM system requirements.

This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.

This function cleans and invalidates all data cache levels up to the
Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
cache for processors that support it (> v7).

This patch also creates an alias of the cache LoUIS function to flush_kern_all
for all processor versions prior to v7, so that the current cache flushing
behaviour is unchanged for those processors.

v7 cache maintenance code implements a cache LoUIS function that cleans and
invalidates the D-cache up to LoUIS and invalidates the I-cache, according
to the new API.

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Shawn Guo <shawn.guo@linaro.org>

Change-Id: I561c3b187b5b87b25de07ea82a4ef73a42761e27
Signed-off-by: Karthik Parsha <kparsha@codeaurora.org>
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>

Conflicts:
	arch/arm/mm/cache-v7.S
Clean
msm: acpuclock-krait: Work-around retention corner-case

The CPU clock source MUXes cannot switch while a CPU is in
retention, but callers of acpuclock APIs may not known that
the CPU is in retention.

Work around this problem be always performing the CPU MUX
switch on the affected CPU using smp_call_function_single()
in cases where cross-calling might otherwise be possible.
The one exception to this is during hotplug code paths,
where cross-calling is expected by design (since the target
CPU is not online and cannot be in retention).

Change-Id: I76b6de436e71da7979f30bdce841f414c26bfe44
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
gpu: ion: Remove code for reusable heap

The reusable feature is no longer supported. Remove
the associated code.

Change-Id: I7cf6eb302969287d629603fa0ea05ad9714bfb70
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: acpuclock-krait: Add __init markings to 'krait vmin' functions

These functions are only called during boot and can be safely
discarded after.

Change-Id: I6bf20a42fec8b82c3f35e1c042b799ef2dad7790
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: acpuclock-krait: Enable HFPLL for init only if switching to it

The existing code left the HFPLL enabled in hfpll_init(), even if
the CPU was detected to be at a non-HFPLL rate. Correct this for
power savings between when hfpll_init() and the first runtime CPU
frequency switch happen. This also ensure votes for HFPLL
regulators are not left unnecessarily asserted.

Change-Id: Iaca5dc7e4769bdbd494d669726ba9b500256f793
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: acpuclock-krait: Only print supported number of frequencies once

The current code prints the number of CPU frequencies supported
once for each possible CPU, even though the number of supported
frequencies is the same for each CPU. Cut down on log noise by
printing this number only once.

For example, print:

  [ 0.412932] acpuclk-8974 qcom,acpuclk.23: CPU Frequencies Supported: 11

...instead of:

  [ 0.426013] acpuclk-8974 qcom,acpuclk.23: CPU0: 11 frequencies supported
  [ 0.426052] acpuclk-8974 qcom,acpuclk.23: CPU1: 11 frequencies supported
  [ 0.426089] acpuclk-8974 qcom,acpuclk.23: CPU2: 11 frequencies supported
  [ 0.426124] acpuclk-8974 qcom,acpuclk.23: CPU3: 11 frequencies supported

Change-Id: Iaf15970e6cfcfaec79c0edf8564cab9141fbc05f
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: acpuclock-krait: Remove inapplicable 8064 errata workaround
msm: acpuclock-krait: Add support for HFPLL lock detect bit polling

Some recent devices have a lock detect bit that can be used to
determine when the HFPLL frequency has stabilized. Add optional
support for polling this bit instead of delaying pessimistically
for 60us.

Change-Id: I38bb0c98e36f66fc5efadf9189dbe817f648a972
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: pm-8x60: Do not default to WFI when not enabled

Return MSM_PM_SLEEP_MODE_NOT_SELECTED in msm_pm_idle_prepare as the
default mode instead of WFI. Skip enter low power mode when this
mode is selected.

Change-Id: Id4a07ba1353b358726c81ed441e0327a9154de8a
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>
msm: pm-8x60: Use ktime_get for suspend stats

During suspend, the sched clock is stopped and the suspends ops
cannot rely on sched clock to report time spent in suspend. Use ktime
interface to determine the time spent in suspend.

Change-Id: Id244cd8d470c45c1edd408e98ccaf84d30c3e253
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Revert "msm: iommu: re-use existing buffers for `extra' mappings"
gpu: ion: Align va address to biggest buffer size

Align the virtual address to the max buffer size to
allow IOMMU mappings at the biggest buffer size.

Change-Id: I74ba665c1782e2f0631274766c5caeeb192224e0
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: enable the kmalloc heap

There are some Ion clients who would like to use the kmalloc
heap. Enable it.

Change-Id: Ie818be9e1211d52d489ad2cb63d94e2fddfc0f01
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
timer: optimize apply_slack()
Date	Sat, 17 Mar 2012 22:31:35 +0100
__fls(mask) is equivalent to find_last_bit(&mask, BITS_PER_LONG), but cheaper.
find_last_bit was showing up high on the list when I was profiling for stalls
on icache misses on a system with very small cache size (MIPS).

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
mm/vmalloc.c: remove dead code in vb_alloc

Space in a vmap block that was once allocated is considered dirty and
not made available for allocation again before the whole block is
recycled.  The result is that free space within a vmap block is always
contiguous.

So if a vmap block has enough free space for allocation, the allocation
is impossible to fail.  Thus, the fragmented block purging was never
invoked from vb_alloc().  So remove this dead code.

[ Same patches also sent by:

    Chanho Min <chanho.min@lge.com>
    Johannes Weiner <hannes@cmpxchg.org>

  but git doesn't do "multiple authors" ]

Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/vmalloc.c: remove unused purge_fragmented_blocks_thiscpu

This function is nowhere used now, so remove it.

Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/vmalloc.c: remove alloc_map from vmap_block

As we have removed the dead code in the vb_alloc, it seems there is no
place to use the alloc_map.  So there is no reason to maintain the
alloc_map in vmap_block.

Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>