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)
Android alarm: IOCTL command encoding fix

commit 6bd4a5d96c08dc2380f8053b1bd4f879f55cd3c9 upstream.

Fixed a bug. Data was being written to user space using an IOCTL
command encoded with _IOC_WRITE access mode.

Backported: 3.4 -> 3.0

Change-Id: I228662c2da6ff3df087d2c97486f3ef1fd9a2280
Signed-off-by: Dae S. Kim <dae@velatum.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrii Beregovenko <a.beregovenko@ti.com>
(cherry picked from commit 8d60d6aaf085d1728a4fda1f59b47622fe2ab495)
ASoC: ABE: Increase volume ramps for DMic's

Most digital microphones need about 10 ms to settle after setting bias
and clocks.  The OMAP DMic module is not able to set the clocks before
beginning the transfer, creating a full-scale pop at the beginning of
the transfer.

This patch works around this behavior by increasing the volume ramp
from 2ms to 50ms for DMic's.

Change-Id: I55fe727fb624965ad22c0f9087c8b426b18080ef
Signed-off-by: Gabriel M. Beddingfield <gabrbedd@ti.com>
(cherry picked from commit 7d9b7835a90ff8935034ed97bafd9d84d3172bc0)
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)
Kernel Version: ak.555.42.berserk