cpufreq_interactiveX.c: Update
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>
sched: fix rq->lock recursion

Enabling SCHED_HRTICK currently results in rq->lock recursion and a hard
hang at bootup.  Essentially try_to_wakeup() grabs rq->lock and tries
arming a hrtimer via hrtimer_restart(), which deep down tries waking up
ksoftirqd, which leads to a recursive call to try_to_wakeup() and thus
attempt to take rq->lock recursively!!

This is fixed by having scheduler queue hrtimer via
__hrtimer_start_range_ns() which avoids waking up ksoftirqd.

Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Change-Id: I11a13be1d9db3a749614ccf3d4f5fb7bf6f18fa1
Bluetooth: Fix hidp_get_connection()

This functions needs crtl_sock and intr_sock to be set first.

Change-Id: I5b62a2b6cd469857ce12f3184a62bc72723664db
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Sumit Bajpai <sbajpai@codeaurora.org>
OMAP4: DVFS: Fix scaling dependent frequencies.

When scaling dependent frequencies down it is observed that the order
in which frequencies are changed is incorrect.  For example, when core
domain changes OPP down from OPP119 to OPP50 the order is:
a) scale L3 freq down to OPP50
b) scale SGX freq down to OPP50
which is wrong.

Frequencies are scaled in order devices are registered in omap dvfs
framework in device list. Devices are inserted to the list in order,
such as dependences are satisfied if scaling frequencies up.

When scaling frequencies down traverse list backwards.

Change-Id: I752bcb264cac12514f358986a906f29ee81ba75e
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
(cherry picked from commit 776ffabf51dbc6a9881d7333bf3341d44a5ed773)
GPIO: OMAP: Fix the sequence to clear the IRQ status

The recommended way to clear the GPIO IRQ status is to:

- Enable the IRQ
- clear the status

If this above sequence is not followed, i.e., if the status
is cleared after disabling the IRQ then sWAKEUP will not be
cleared and gates the module transition.

Change-Id: I8bd1b820ac8be70530cd6430f26ce541bfd3f9d9
Signed-off-by: Huzefa Kankroliwala <huzefank@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Andrii Anisov <andrii.anisov@ti.com>
(cherry picked from commit 290cdf9401be0f6be1b6488a01149374564b07d5)
USB: musb: do not proceed with interrupt completions if qh is not ready

It's not safe to modify hw_ep if qh is not ready.
This may corrupt data in musb_qh. In RX/TX completions this
may happen on SMP system with current musb host implementation
The main issue is with musb_giveback function. It unlocks and
and after that locks musb->lock so during this time
musb_qh data may be corrupted. This results in null-pointers
dereferences / programming of busy DMA channel / etc in
different places.

This often happens during unlinking URB for ISO and looks like:
CPU0                                  CPU1
...                                   musb_urb_dequeue
...                                      spin_lock_irqsave(&musb->lock)
...                                      (work with musb_qh)
...                                      musb_giveback
...                                         spin_unlock(&musb->lock)
generic_interrupt()                         ...
   spin_lock_irqsave(&musb->lock)           ...
   (work with musb_qh)                      ...
   spin_unlock_irqrestore(&musb->lock)      ...
...                                         spin_lock(&musb->lock)
...                                      (continues work with musb_qh)
...                                      spin_lock_irqrestore(&musb->lock)

Go out from completion if qh is not ready.

Change-Id: I9c9280a7ab7f8e89b2e8bf745800217f903108fc
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
(cherry picked from commit d0d4f29c2ac05a66a8b26c00ddd436e71519a1d5)
usb: musb: gadget: use pm autosuspend in musb_gadget_pullup

If musb_gadget_pullup doesn't use pm autosuspend, next may happen:

time |   pseudocode
------------------------------------------------------------
t1   | pm_runtime_put_autosuspend() scedules suspend at 't4'
     |     /* some code running */
t2   | musb_gadget_pullup: pm_runtime_get_sync() <-- cancels requested autosuspend
     |     /* some code running */
t3   | musb_gadget_pullup: pm_runtime_put() <-- suspends device (may happen before t4!)
     |
t4   | <- suspend is expected here, but device may be already suspended between t3 and t4

So use pm autosuspend in musb_gadget_pullup and prevent such situation

Change-Id: I8b9618c6d24bea3810c736f8fc0195802ce79c55
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
(cherry picked from commit fd5404d9033defa72dbbdaace600a67fcf9763bb)
fs/namespace.c: Activate NOATIME and NODIRATIME By Default
+ lib: strncpy_from_user & strnlen_user
-> https://github.com/faux123/tuna/commit/2fb6cccc9fe41bbce04c3bd796dc40768fa2761e
-> https://github.com/faux123/tuna/commit/cc107ec0127d685b4641509293d5bf18c490cb51
-> https://github.com/faux123/tuna/commit/08a87874f10ca874cae08cb0ba8943eb4c5ca923
-> https://github.com/faux123/tuna/commit/96b570368112d422f4e864fef79f727aad8ad328
-> https://github.com/faux123/tuna/commit/8b1ab9edfc006a7cfbf882c9d3d8996e6920032b
tuna_ak_defconfig: Enable STRNCPY_FROM_USER + STRNLEN_USER
Kernel Version: purity.008
Revert "Input: Send events one packet at a time"

This reverts commit 9f0d0fa24898b331513e5d555479038ede7ea930.
cpufreq: Add cpu utilization statistics to aid decisions made by userspace.

Understanding system load as seen by cpufreq can help userspace
algorithms make better decisions to improve system responsiveness.
One such example would be the MP decision algorithm which mines
various system info to make decisions on hotplugging in/out
the additional cores.

Change-Id: I277db7e1a7803a3822b61e7befa25131487cfe17
Signed-off-by: Anitha Anand <anithas@codeaurora.org>
opp4xxx_data.c: Undervolt -10mv for All Freqs
Kernel Version: purity.009
tuna_ak_defconfig: Disable GOV_SAKURACTIVE + Some TCP_CONG
Kernel Version: purity.010