make aux next
build: update makefile
build: update ramdisk
dtsi: reduce lcd voltage
powersuspend: new PM kernel driver for Android w/o early_suspend

Android early_suspend/late_resume PM kernel driver framework has been
deprecated by Google. This new powersuspend PM kernel driver is a replacement
for it and existing early_suspend drivers can be easily adapted to use this
new replacement driver

Signed-off-by: Paul Reioux <reioux@gmail.com>

powersuspend: fix logci derps :p

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
kernel/power/powersuspend: remove userspace dependency from powersuspend

make powersuspend not depend on a userspace initiator anymore, but use a hook
in autosleep instead.

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
kernel/power/powersuspend: add back userpace control w/ default kernel control

make kernel / userspace mode switchable

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
thermal: update script
fs: add dyn_fsync
fs: add async_fsync
vibrator: use 75 as default strength
PM: Introduce suspend state PM_SUSPEND_FREEZE

PM_SUSPEND_FREEZE state is a general state that
does not need any platform specific support, it equals
frozen processes + suspended devices + idle processors.

Compared with PM_SUSPEND_MEMORY,
PM_SUSPEND_FREEZE saves less power
because the system is still in a running state.
PM_SUSPEND_FREEZE has less resume latency because it does not
touch BIOS, and the processors are in idle state.

Compared with RTPM/idle,
PM_SUSPEND_FREEZE saves more power as
1. the processor has longer sleep time because processes are frozen.
   The deeper c-state the processor supports, more power saving we can get.
2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
   more power saving from the devices that does not have good RTPM support.

This state is useful for
1) platforms that do not have STR, or have a broken STR.
2) platforms that have an extremely low power idle state,
   which can be used to replace STR.

The following describes how PM_SUSPEND_FREEZE state works.
1. echo freeze > /sys/power/state
2. the processes are frozen.
3. all the devices are suspended.
4. all the processors are blocked by a wait queue
5. all the processors idles and enters (Deep) c-state.
6. an interrupt fires.
7. a processor is woken up and handles the irq.
8. if it is a general event,
   a) the irq handler runs and quites.
   b) goto step 4.
9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving,
   a) the irq handler runs and activate the wakeup source
   b) wakeup_source_activate() notifies the wait queue.
   c) system starts resuming from PM_SUSPEND_FREEZE
10. all the devices are resumed.
11. all the processes are unfrozen.
12. system is back to working.

Known Issue:
The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
from the previous suspend state.
Take ACPI platform for example, there are some GPEs that only enabled
when the system is in sleep state, to wake the system backk from S3/S4.
But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
This means we may lose some wake event.
But on the other hand, as we do not disable all the Interrupts during
PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are
not available for S3/S4.

The patches has been tested on an old Sony laptop, and here are the results:

Average Power:
1. RPTM/idle for half an hour:
   14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
2. Freeze for half an hour:
   11W, 10.4W, 9.4W, 11.3W 10.5W
3. RTPM/idle for three hours:
   11.6W
4. Freeze for three hours:
   10W
5. Suspend to Memory:
   0.5~0.9W

Average Resume Latency:
1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
   Less than 0.2s
2. Freeze: (From pressing power button to screen back)
   2.50s
3. Suspend to Memory: (From pressing power button to screen back)
   4.33s

From the results, we can see that all the platforms should benefit from
this patch, even if it does not have Low Power S0.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	kernel/power/main.c
	kernel/power/suspend.c
cpufreq: allow for low CPU clock policy when hotplugging new cores

Signed-off-by: faux123 <reioux@gmail.com>

Conflicts:
	arch/arm/mach-msm/cpufreq.c
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
usb: gadget: Fix race condition in connect/disconnect

This commit fixes race condition in fast connect/disconnect
of USB cable. This race condition can also be reproduced in
USB composition change. Thus this commit also adds support
for USB composition change for BAMtoBAM compositions.

CRs-fixed: 463705
Change-Id: I21abaff6a64bb405ce2d698605aff8e0050ef8d6
Signed-off-by: Anna Perel <aperel@codeaurora.org>
Signed-off-by: Bar Weiner <bweiner@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: ipc: Possible memory corruption due to Sign Conversion

msm_ipc_router_skb_to_buf() takes an unsigned argument and assigns the
same to a signed local variable. This might cause issues when the value
of the argument is too high.

Change the datatype of the local variable to unsigned.

Signed-off-by: Zaheerulla Meer <zmeer@codeaurora.org>
msm: use of swp{b} is deprecated for ARMv6+

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
timerfd: support CLOCK_BOOTTIME clock
mm: increase readahead
Input: Send events one packet at a time

On heavy event loads, such as a multitouch driver, the irqsoff latency
can be as high as 250 us.  By accumulating a frame worth of data
before passing it on, the latency can be dramatically reduced.  As a
side effect, the special EV_SYN handling can be removed, since the
frame is now atomic.

This patch adds the events() handler callback and uses it if it
exists. The latency is improved by 50 us even without the callback.

Change-Id: Iebd9b1868ae6300a922a45b6d104e7c2b38e4cf5
Cc: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Tested-by: Ping Cheng <pingc@wacom.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>

Input: Improve the events-per-packet estimate

The events-per-packet estimate has so far been used by MT devices
only. This patch adjusts the packet buffer size to also accomodate the
KEY and MSC events.  Keyboards normally send one or two keys at a
time. MT devices normally send a number of button keys along with the
MT information.  The buffer size chosen here covers those cases, and
matches the default buffer size in evdev. Since the input estimate is
now preferred, remove the special input-mt estimate.

Reviewed-and-tested-by: Ping Cheng <pingc@wacom.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
cpufreq: add smartassH3