remove PMEM; not needed anymore, frees a few extra MB of memory

Change-Id: Ic5905568ef499d81acbc3130431e8624560e5668
Changes to support Integrated Kernel Building

Change-Id: Ie9645fb0084729cb03cb8caaa959fadc0583b186
fix ANDROID_PMEM ifdefs to include TEXSTREAM

this amended portion of previous commit was missed
when this repo was forked to CyanogenMod

Change-Id: I846e75fdf0aba2c7fcb646eb0573a36e684b36a8
remove deprecated build scripts

Change-Id: Ib5befad1ddcffa26ce8cd41568a85f4778293d43
reduce MFC reserved memory to 32mb

Change-Id: Iae36a007bf95895d2b9a73b87081b6c825f8c505
Create kernel file to disable capacitive buttons

credit to sbradymobile for this patch

Change-Id: I827552fd966ea78bf395b832c42a17880baf5091
Optimize MFC memory usage, properly

- There are several bugs in MFC memory management that needs to be
  fixed for non-equal buffer size to work properly.
- Samsung originally reduced CPB_BUF_SIZE, but it causes mis-decoding
  of some videos. So we increase it back and also slightly increase
  the memory allocation to support it.
- Userspace mmap size needs to be changed to 35328*1024
  (port0_size - firmware_size + port1_size)

Change-Id: I9a344ff2e5911846673015dfef5cf850558c1b8f
defconfig: enable CONFIG_KSM

Change-Id: Id284aa5badab925acb35b5561ada0b3e9acfff0c
ksm: annotate ksm_thread_mutex is no deadlock source

commit 62b61f611e ("ksm: memory hotremove migration only") caused the
following new lockdep warning.

  =======================================================
  [ INFO: possible circular locking dependency detected ]
  -------------------------------------------------------
  bash/1621 is trying to acquire lock:
   ((memory_chain).rwsem){.+.+.+}, at: [<ffffffff81079339>]
  __blocking_notifier_call_chain+0x69/0xc0

  but task is already holding lock:
   (ksm_thread_mutex){+.+.+.}, at: [<ffffffff8113a3aa>]
  ksm_memory_callback+0x3a/0xc0

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (ksm_thread_mutex){+.+.+.}:
       [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
       [<ffffffff81505d74>] __mutex_lock_common+0x44/0x3f0
       [<ffffffff81506228>] mutex_lock_nested+0x48/0x60
       [<ffffffff8113a3aa>] ksm_memory_callback+0x3a/0xc0
       [<ffffffff8150c21c>] notifier_call_chain+0x8c/0xe0
       [<ffffffff8107934e>] __blocking_notifier_call_chain+0x7e/0xc0
       [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff813afbfb>] memory_notify+0x1b/0x20
       [<ffffffff81141b7c>] remove_memory+0x1cc/0x5f0
       [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
       [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
       [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
       [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
       [<ffffffff8114f398>] vfs_write+0xc8/0x190
       [<ffffffff8114fc14>] sys_write+0x54/0x90
       [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b

  -> #0 ((memory_chain).rwsem){.+.+.+}:
       [<ffffffff8108b5ba>] __lock_acquire+0x155a/0x1600
       [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
       [<ffffffff81506601>] down_read+0x51/0xa0
       [<ffffffff81079339>] __blocking_notifier_call_chain+0x69/0xc0
       [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff813afbfb>] memory_notify+0x1b/0x20
       [<ffffffff81141f1e>] remove_memory+0x56e/0x5f0
       [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
       [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
       [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
       [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
       [<ffffffff8114f398>] vfs_write+0xc8/0x190
       [<ffffffff8114fc14>] sys_write+0x54/0x90
       [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b

But it's a false positive.  Both memory_chain.rwsem and ksm_thread_mutex
have an outer lock (mem_hotplug_mutex).  So they cannot deadlock.

Thus, This patch annotate ksm_thread_mutex is not deadlock source.

[akpm@linux-foundation.org: update comment, from Hugh]
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ksm: drain pagevecs to lru

It was hard to explain the page counts which were causing new LTP tests
of KSM to fail: we need to drain the per-cpu pagevecs to LRU occasionally.

Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: CAI Qian <caiqian@redhat.com>
Cc:Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ksm: fix NULL pointer dereference in scan_get_next_rmap_item()

Andrea Righi reported a case where an exiting task can race against
ksmd::scan_get_next_rmap_item (http://lkml.org/lkml/2011/6/1/742) easily
triggering a NULL pointer dereference in ksmd.

ksm_scan.mm_slot == &ksm_mm_head with only one registered mm

CPU 1 (__ksm_exit)		CPU 2 (scan_get_next_rmap_item)
 				list_empty() is false
lock				slot == &ksm_mm_head
list_del(slot->mm_list)
(list now empty)
unlock
				lock
				slot = list_entry(slot->mm_list.next)
				(list is empty, so slot is still ksm_mm_head)
				unlock
				slot->mm == NULL ... Oops

Close this race by revalidating that the new slot is not simply the list
head again.

Andrea's test case:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>

#define BUFSIZE getpagesize()

int main(int argc, char **argv)
{
	void *ptr;

	if (posix_memalign(&ptr, getpagesize(), BUFSIZE) < 0) {
		perror("posix_memalign");
		exit(1);
	}
	if (madvise(ptr, BUFSIZE, MADV_MERGEABLE) < 0) {
		perror("madvise");
		exit(1);
	}
	*(char *)NULL = 0;

	return 0;
}

Reported-by: Andrea Righi <andrea@betterlinux.com>
Tested-by: Andrea Righi <andrea@betterlinux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Backport (read: copied) net/wireless and drivers/net/wireless from 3.0.8 for bcmdhd

These are the version as of e0de0a507d83e84c833d01de9e46a44b12419431
on common/android-3.0.

The bcmdhd module allows Wi-Fi direct to be used for bcm4329 and
bcm4330. The module is now compiled into the kernel (the same
as Galaxy Nexus) as the system won't load the module correctly
for Wi-Fi direct and it sometimes crashes the system.

Both the wifi and tethering interfaces are renamed wlan0 with this
patch.

Change-Id: Iaf9786bd6c247a2ff9bd86a5ab286e1a8980715d
Use example country table for bcmdhd

This table is the same as the one Galaxy Nexus uses, but GN copied
it to its platform directory.
defconfig: fix NVRAM_PATH

eaut's MAC address fix installs nvram_net.txt to /data
make sure the wifi driver knows its correct location

Change-Id: Iddb8e5c4d445e94dcf68d1fefec8166b3e245564
Fixed touchscreen issues with Unity3D based games

Fixed touchscreen bugs related to BTN_TOUCH = 0 and ABS_MT according to
commit 5450554 in repo android_kernel_samsung_p1 and
http://review.cyanogenmod.com/#/c/12761/. These bugs previously prevented
Unity3D based games from properly registering touches, requiring multiple
touches to activate a button, practically rendering swipes/gestures
useless as well.

Change-Id: Ia55b7c905ac0e44378a4c94d6bcd31f662e931ae
bcmdhd: Fix IBSS (ad-hoc) network support

Based on 69274f020a9245c4f1079d602384d616f236568b and
e494632efcd9e24875e9a83230c514c51875cbe2 in
drivers/staging/brcm80211/brcmfmac

bcmdhd ships with broken ad-hoc network support and this patch
fixes it
bcmdhd: Fix AP mode support

broken when added IBSS support
Use DVFS locks instead of cpufreq policy mangling in pvr.

The pvr driver requires that the memory bus speed is kept fast while the
GPU is active. Since the memory bus speed is tied to the CPU frequency,
pvr (previously) used a cpufreq notifier called on policy updates to ensure
the CPU is running at a minimum 200 MHz while active. The problem with
this approach is that any changes to scaling_min_freq while the GPU is
active (e.g., while interacting with the Processor settings menu) get
clamped to 200 MHz, which persists even when the GPU is inactive.

By switching to DVFS locks, changes to scaling_min_freq persist, and so
allows the use of 100 MHz when the GPU is inactive. Fixes epiccm #14.

Change-Id: I87da92c3b69ae62e78b888080acad9f1c0d99f61
mach-p1.c: change machine name to p1c

Change-Id: Ia11493e8e688cc9e586354c9c606cebf1b1c269c
remove unused partition table and rename existing one to p1c

Change-Id: I7e7ab79c9f25fa0af635ebbc433e41bddc59af0c