msm: idle-macro: L2 cache flush optimizations

Following suggestions are made by HW team to optimize the
L2 cache flush code.

1. wait should be for 8 ways as we have only 8 ways , value change from
FFFF (16 ways) to FF (8ways).
2. For the PL310 the sync wait is not needed.
3. add dsb for cache controller register writes.

Change-Id: Idd48e2efabc04b4f913e4b5f1ef8d9fbefb1072f
CRs-fixed: 467112
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Revert "msm: cpr: Save latest frequency and voltage for debug"

This reverts commit 7702c4318bd265cb9696a49e2e05c253d54f40ca.
msm: dma: Refactored driver to avoid queuing of cmds in workq.

Highlights of the changes are:
1. A workqueue is used to configure ADM only when
   the clocks need to be prepared & enabled.
   A function call is used to configure ADM in
   cases where the ADM driver is invoked for data
   transfer when the clock is already prepared &
   enabled.
2. Replaced threaded irqs with hard irqs.

Change-Id: Ifaa5efdde8150f932a12d4f9eeccfb36ecb8f88f
Acked-by: John Nicholas <jnichola@qti.qualcomm.com>
Signed-off-by: Venkatesh Yadav Abbarapu <quicvenkat@codeaurora.org>
msm: memory: remove obsolete stable_size function

The notion of `stable' memory is going away (i.e. all memory is now
treated as `stable'). Remove the stable_size function. Remove the
notion of stability from the total_stable_size function and rename it
to total_size.

Change-Id: I8fd08a36b4948d57f430aea9113a0c704b8a00d0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
msm: memory: use memblock instead of meminfo

msm currently uses meminfo (not memblock) in memory.c for several
purposes (mainly the placement of the memory pool(s)).  When the code
was written originally, memblock didn't exist yet.

Now that memblock exists, this is not strictly correct, but works as
long as nobody calls memblock_remove() besides this code (if that
occurs then the meminfo data no longer reflect reality and will likely
cause overlap problems).

To avoid problems meminfo usage should be replaced with memblock.

Also, since memblock regions of the same type can't be contiguous, the
total_size function, which calculated the aggregate size of contiguous
meminfo banks, can be removed.

Change-Id: I34054c4fe367986f472bdaae65be67cd8fbf273a
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
msm: remove obsolete DMM code and config options

DMM is no longer supported, but there were still fragments
of the DMM support dependent on the obsolete config options
CONFIG_ENABLE_DMM and CONFIG_FIX_MOVABLE_ZONE present.
Remove these config options and the associated code.

Change-Id: I01c715c8d9c65eebc7ff123a8a0878166b606e0c
CRs-fixed: 460735
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
msm: Completely remove memory from the memblock allocator

memblock_remove may not be sufficient to prevent placing
regions on top of each other. Call memblock_reserve and
memblock_free as well to completely remove the memory
from the allocator.

Change-Id: Iec481d7ce7a51c243e43a2d9be2fbfbf7b2717ed
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: simplify placing memory pools

The algorithm for placing memory pools was manually inspecting
the memblock data structures and then doing a memblock_remove()
on the region it decided that the memory pool should be located at.

If other code already did a memblock_remove() it was possible
that the memblock data structures which this algorithm
was inspecting would not be correct and the memory pool might
be placed overlapping this previous allocation.

Instead use arm_memblock_steal() which will not have this
problem (and also lets the memblock subsystem do
the allocation without any manual inspection of memblocks).

Change-Id: I7db5cba0a8d5f222f9f2f131b4b42eb81171c45b
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
lib: Pass the correct align offset to bitmap_find_next_zero_area_off

bitmap_find_next_zero_area_off requires everything to be given in terms
of bits. genpool no longer keeps track of everything in terms of bits
so the start address must be shifted before passing to
bitmap_find_next_zero_area_off. Without this, if the start address
is unaligned, the code will not take this into account.

Change-Id: I49e3dba51c48e2f97b03b21304e1258e83881c6b
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
genalloc: stop crashing the system when destroying a pool

The genalloc code uses the bitmap API from include/linux/bitmap.h and
lib/bitmap.c, which is based on long values.  Both bitmap_set from
lib/bitmap.c and bitmap_set_ll, which is the lockless version from
genalloc.c, use BITMAP_LAST_WORD_MASK to set the first bits in a long in
the bitmap.

That one uses (1 << bits) - 1, 0b111, if you are setting the first three
bits.  This means that the API counts from the least significant bits
(LSB from now on) to the MSB.  The LSB in the first long is bit 0, then.
The same works for the lookup functions.

The genalloc code uses longs for the bitmap, as it should.  In
include/linux/genalloc.h, struct gen_pool_chunk has unsigned long
bits[0] as its last member.  When allocating the struct, genalloc should
reserve enough space for the bitmap.  This should be a proper number of
longs that can fit the amount of bits in the bitmap.

However, genalloc allocates an integer number of bytes that fit the
amount of bits, but may not be an integer amount of longs.  9 bytes, for
example, could be allocated for 70 bits.

This is a problem in itself if the Least Significat Bit in a long is in
the byte with the largest address, which happens in Big Endian machines.
This means genalloc is not allocating the byte in which it will try to
set or check for a bit.

This may end up in memory corruption, where genalloc will try to set the
bits it has not allocated.  In fact, genalloc may not set these bits
because it may find them already set, because they were not zeroed since
they were not allocated.  And that's what causes a BUG when
gen_pool_destroy is called and check for any set bits.

What really happens is that genalloc uses kmalloc_node with __GFP_ZERO
on gen_pool_add_virt.  With SLAB and SLUB, this means the whole slab
will be cleared, not only the requested bytes.  Since struct
gen_pool_chunk has a size that is a multiple of 8, and slab sizes are
multiples of 8, we get lucky and allocate and clear the right amount of
bytes.

Hower, this is not the case with SLOB or with older code that did memset
after allocating instead of using __GFP_ZERO.

So, a simple module as this (running 3.6.0), will cause a crash when
rmmod'ed.

  [root@phantom-lp2 foo]# cat foo.c
  #include <linux/kernel.h>
  #include <linux/module.h>
  #include <linux/init.h>
  #include <linux/genalloc.h>

  MODULE_LICENSE("GPL");
  MODULE_VERSION("0.1");

  static struct gen_pool *foo_pool;

  static __init int foo_init(void)
  {
          int ret;
          foo_pool = gen_pool_create(10, -1);
          if (!foo_pool)
                  return -ENOMEM;
          ret = gen_pool_add(foo_pool, 0xa0000000, 32 << 10, -1);
          if (ret) {
                  gen_pool_destroy(foo_pool);
                  return ret;
          }
          return 0;
  }

  static __exit void foo_exit(void)
  {
          gen_pool_destroy(foo_pool);
  }

  module_init(foo_init);
  module_exit(foo_exit);
  [root@phantom-lp2 foo]# zcat /proc/config.gz | grep SLOB
  CONFIG_SLOB=y
  [root@phantom-lp2 foo]# insmod ./foo.ko
  [root@phantom-lp2 foo]# rmmod foo
  ------------[ cut here ]------------
  kernel BUG at lib/genalloc.c:243!
  cpu 0x4: Vector: 700 (Program Check) at [c0000000bb0e7960]
      pc: c0000000003cb50c: .gen_pool_destroy+0xac/0x110
      lr: c0000000003cb4fc: .gen_pool_destroy+0x9c/0x110
      sp: c0000000bb0e7be0
     msr: 8000000000029032
    current = 0xc0000000bb0e0000
    paca    = 0xc000000006d30e00   softe: 0        irq_happened: 0x01
      pid   = 13044, comm = rmmod
  kernel BUG at lib/genalloc.c:243!
  [c0000000bb0e7ca0] d000000004b00020 .foo_exit+0x20/0x38 [foo]
  [c0000000bb0e7d20] c0000000000dff98 .SyS_delete_module+0x1a8/0x290
  [c0000000bb0e7e30] c0000000000097d4 syscall_exit+0x0/0x94
  --- Exception: c00 (System Call) at 000000800753d1a0
  SP (fffd0b0e640) is in userspace

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: eedce141cd2dad8d0cefc5468ef41898949a7031
Git-repo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Change-Id: Ic8a8a2d05ee16d59af61d0cc79c88e6e7ab442ae
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
genalloc: Correct nbytes calculation on long boundary

In existing code we calculate nbytes based on the byte
boundary, but genalloc uses bitmap for maintaining the
memory allocation aligned to long. So while calculating
nbytes we end up getting wrong nbytes.
example: lets say nbytes comes to 9 bytes for 70 bits when
bytes aligned,but if long aligned we will have 3 long words
i.e 12 bytes. This difference may lead to choosing the
wrong api for freeing the memory i.e Between kfree() and
vfree().
Fix was inspired by an upstream commit
eedce141cd2dad8d0cefc5468ef41898949a7031, bringing same fix
into the gen_pool_detroy path.

Change-Id: I942caf59e25515c780896b328b912604df9e10bf
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
lib: genalloc: remove spinlocks in 'gen_destroy_pool()'

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
ARM: 7608/1: l2x0: Only set .set_debug on PL310 r3p0 and earlier

PL310 errata work-arounds using .set_debug function are only needed on
r3p0 and earlier, so check the rev and only set .set_debug on older revs.

Avoiding debug register accesses fixes aborts on non-secure platforms
like highbank. It is assumed that non-secure platforms needing these
work-arounds have already implemented .set_debug with secure monitor
calls.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7507/1: cache-l2x0.c: save the final aux ctrl value for resuming

There is a bug if l2x0 controller has been enabled when calling
l2x0_init, the aux ctrl register will not be saved in l2x0_saved_regs.
Therefore we will use uninitialized l2x0_saved_regs.aux_ctrl for
resuming later.

In this patch, the aux ctrl value is read and saved after it is
initialized. So we have the real value being set for resuming.

Link: http://lkml.kernel.org/r/1336046857-24133-1-git-send-email-ylmao@marvell.com

Signed-off-by: Yilu Mao <ylmao@marvell.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: cache_l2x0: Set outer_cache resume

Set the outer_cache.resume function during l2x0_init and declare a static
inline void version to allow compilation when OUTER_CACHE is not defined.
The outer_cache functions are used for L2 cache management in chips that
have an external cache controller. The outer_cache.resume re-enables the
L2 cache controller and is called when exiting power collapse.
This change is needed to allow drivers to call outer_cache API's instead
of directly using the APIs defined in cache-l2x0.c and thus avoid having
to use #ifdef macros in the code.

Change-Id: Ifc7d25f905e3248f864c9eaf019436968e77b8a2
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
config: disable SUPPORT_SYSTEMTAP

* this feature is for debugging purposes only

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
Revert "drivers: power: Add watchdog timer to catch drivers which lockup during suspend."

This reverts commit 9109a22de417cce528f15ae2e51ebb3d826f1bf5.

Conflicts:
	drivers/base/power/main.c
PM / Sleep: Detect device suspend/resume lockup and log event

Rather than hard-lock the kernel, dump the suspend/resume thread stack
and panic() to capture a message in pstore when a driver takes too long
to suspend/resume. Default suspend/resume watchdog timeout is set to 12
seconds to be longer than the usbhid 10 second timeout, but could be
changed at compile time.

Exclude from the watchdog the time spent waiting for children that
are resumed asynchronously and time every device, whether or not they
resumed synchronously.

This patch is targeted for mobile devices where a suspend/resume lockup
could cause a system reboot. Information about failing device can be
retrieved in subsequent boot session by mounting pstore and inspecting
the log. Laptops with EFI-enabled pstore could also benefit from
this feature.

The hardware watchdog timer is likely suspended during this time and
couldn't be relied upon. The soft-lockup detector would eventually tell
that tasks are not scheduled, but would provide little context as to why.
The patch hence uses system timer and assumes it is still active while the
devices are suspended/resumed.

This feature can be enabled/disabled during kernel configuration.

This change is based on earlier work by San Mehat.

Signed-off-by: Benoit Goby <benoit@android.com>
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ARM: 7587/1: implement optimized percpu variable access

Use the previously unused TPIDRPRW register to store percpu offsets.
TPIDRPRW is only accessible in PL1, so it can only be used in the kernel.

This replaces 2 loads with a mrc instruction for each percpu variable
access. With hackbench, the performance improvement is 1.4% on Cortex-A9
(highbank). Taking an average of 30 runs of "hackbench -l 1000" yields:

Before: 6.2191
After: 6.1348

Will Deacon reported similar delta on v6 with 11MPCore.

The asm "memory clobber" are needed here to ensure the percpu offset
gets reloaded. Testing by Will found that this would not happen in
__schedule() which is a bit of a special case as preemption is disabled
but the execution can move cores.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7747/1: pcpu: ensure __my_cpu_offset cannot be re-ordered across barrier()

__my_cpu_offset is non-volatile, since we want its value to be cached
when we access several per-cpu variables in a row with preemption
disabled. This means that we rely on preempt_{en,dis}able to hazard
with the operation via the barrier() macro, so that we can't end up
migrating CPUs without reloading the per-cpu offset.

Unfortunately, GCC doesn't treat a "memory" clobber on a non-volatile
asm block as a side-effect, and will happily re-order it before other
memory clobbers (including those in prempt_disable()) and cache the
value. This has been observed to break the cmpxchg logic in the slub
allocator, leading to livelock in kmem_cache_alloc in mainline kernels.

This patch adds a dummy memory input operand to __my_cpu_offset,
forcing it to be ordered with respect to the barrier() macro.

Cc: <stable@vger.kernel.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>