bcmdhd: disable GAN_LITE_NAT_KEEPALIVE_FILTER

Change-Id: Ibffa4612d418a93483d3a6b374b3f87a554b57d5
bcmdhd: reenable IPv6, disable multicast in suspend

Change-Id: Ibed08394600cd00bbace45d55f75d0bb1e12c537
s3cfb: disable spam

Change-Id: If4e3b7a2ded1dbe4e9940fc8d2ff45b80093d8ac
ondemand: cpuidle detection

I found a problem with the ondemand governor while in earlysuspend
suspend mode (ondemand keeping the freq close to the max at all times
despite near 0% load). The problem is that the cpu starts to go in
long cpuidle cycles, a sampling_rate of 10000 (usec) is applied only
once in a while and the real sampling_rate becomes 1 second (or more).

So when a wakeup happens we return to the 10000usec sampling rate. The
ondemand sees lots of activity after the wakeup but those "loads" must
be adjusted down if the previous wall_time delta was huge and the
current one is tiny. We're too close to long cpuidle to worry about
the cpu freq anyway and it may be just a jitter load that if we take
into account without adjusting it down, will lead to the next long
cpuidle to be entered at the max freq again, and this repeats forever.

So my solution is to tweak the ondemand to scale down the "load"
according to the decrease in the wall_time delta ratio
(deep_sleep_ratio variable). This allows the CPU to stay at the lowest
freq during the deep sleeps even when the ondemand governor is enabled
and the sampling_rate is set to 10000. (setting the sampling_rate to
values >100000 would also tend to hide the problem but it'd screw the
interactive behavior by running at the lowest frequency for too long
during interactive usage)

During interactive usage with the screen on (not in earlysuspend
mode), or during playback or voip with screen off the deep_sleep_rate
is set to 1 practically all the time so it won't alter the behavior of
the ondemand governor unless the system is very idle (and in turn when
we want it to stay at low freq).

Change-Id: If0391e6d6c41c1c8c9fa590502e88e681a800b04

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>
isa1200_vibrator: user configurable vibration intensity

This patch was taken from maxx77693_haptic motor.
Vibration is configured via DeviceSettings.

Change-Id: Ibca1271798b22a6aacd6e81f2f2d128def69845e
Frandom.c
xens writeback
little tweak for performance improvements
Some updates
namespace.c NOATIME & NODIRATIOME
Reduce logger ram allocation
Reduce wireless wakelocks
MEDIA_TUNER=n
Add 'scaling_available_freqs'
 input: evdev: Move wake_lock_destroy call

Calling wake_lock_destroy from inside a spinlock
protected region (or, in general, from atomic context)
leads to a 'scheduling while atomic bug' because the
internal wakeup source deletion logic calls
synchronize_rcu, which can sleep. Moreover,
since the interal lists are already protected with
RCUs and spinlocks, putting the wake_lock_destroy
call in a spinlock is redundant.

Change-Id: I10a2239b664a5f43e54495f24fe588fb09282305
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
 mm/vmscan.c: avoid possible deadlock caused by too_many_isolated() Ne…

…il found that if too_many_isolated() returns true while performing direct reclaim we can end up waiting for other threads to complete their direct reclaim. If those threads are allowed to enter the FS or IO to free memory, but this thread is not, then it is possible that those threads will be waiting on this thread and so we get a circular deadlock.

some task enters direct reclaim with GFP_KERNEL
  => too_many_isolated() false
    => vmscan and run into dirty pages
      => pageout()
        => take some FS lock
          => fs/block code does GFP_NOIO allocation
            => enter direct reclaim again
              => too_many_isolated() true
                => waiting for others to progress, however the other
                   tasks may be circular waiting for the FS lock..

priority than normal ones, by lowering the throttle threshold for the
latter.

Allowing ~1/8 isolated pages in normal is large enough.  For example, for
a 1GB LRU list, that's ~128MB isolated pages, or 1k blocked tasks (each
isolates 32 4KB pages), or 64 blocked tasks per logical CPU (assuming 16
logical CPUs per NUMA node).  So it's not likely some CPU goes idle
waiting (when it could make progress) because of this limit: there are
much more sleeping reclaim tasks than the number of CPU, so the task may
well be blocked by some low level queue/lock anyway.

reclaims, however that's very unlikely because the IO-less direct reclaims
is able to progress much more faster, and they won't deadlock each other.
The threshold is raised high enough for them, so that there can be

[akpm@linux-foundation.org: tweak comment]
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: Torsten Kaiser <just.for.lkml@googlemail.com>
Tested-by: NeilBrown <neilb@suse.de>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
set the transition latency value=40000
Optimized ARM RWSEM algorithm
 mmc: fix the workqueue overload battery waste

After switching to the smdk4412 kernel I noticed a workqueue overload,
battery lasting less, and Android OS showing up at the top as result.

Tracing showed that mmc_host_clk_gate_work was one of the runqueues
called regularly in the background.

The #ifdef is clearly reversed and that leads to the ndelay being called
every time, while ndelay was never called before.

Not yet sure if this fixes the apparent regression but it's not bad so
far, after 1h of uptime android OS is below Android System.

Change-Id: Ief78ed7ddb3eec85636844b9a730cac832b096b4
drivers: modem_if : Remove some debugging