OMAP4: OMAPFB: Set overlay zorder to 0 if omapfb API used

Since there's no ioctl to set zorder when modifying overlays
using SETUP_PLANE, it's more useful to userland code if
overlay is 0, so they don't have to use sysfs and first
figure out which overlay is being used by omapfb.

Change-Id: I1c2eeecb0b950439e40eec895d6b89c73df2fd7e
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>

Conflicts:
	drivers/video/omap2/omapfb/omapfb-main.c
OMAP4: DSSCOMP: Check user passed arg in ioctl

Prevent stack overflow if user passes in a value
that's too large for num_ovl.

Change-Id: I86a232544f8acc6a08eca00dfdb71db41f355341
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
[OMAPRPC] Fix locking mutex twice

Fix calling mutex_lock twice.

Change-Id: I687c2785a6ffc00428bc3975a9bd637df36de8b0
Signed-off-by: Alberto Aguirre <a-aguirre@ti.com>
rpmsg: omaprpc: Fix omaprpc_release hang

omaprpc_release can hang due to an uninterruptible
wait for an ack from the remote core.

Change wait to be interruptible.

Change-Id: Iaf449119b5525db131c536434c84ea296f6e8a95
Signed-off-by: Alberto Aguirre <a-aguirre@ti.com>
I2C: omap: Fix error condition when slave sends a NAK

Fix an issue in the omap i2c host controller driver where it was not properly
clearing out an error condition in the unit after a NAK'ed transaction causing
the subsequent transaction to time out.

Change-Id: I5cdc8e740acdbc8116dca4d13f1a2cee37f75582
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
OMAP: mcbsp: Fix error checks of rx_irq.

rx_irq is intialized via a call to platform_get_irq_byname(), which can
return a negative error value.  Also, zero is a valid irq.  Fix checks
that assumed non-zero values were the only valid rx_irq values.

Change-Id: I6be171eefa5923021e4adccf71f21baad3383554
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
OMAP: McBSP: Fix rx_irq handling in omap_mcbsp_request.

Fix a logic error in omap_mcbsp_request in the TI McBSP libraries.
Looks like this lib is trying to support a unit which has been around
since OMAP1, but which has been evolving.  In particular, the
libraries are expecting there to be two different IRQs going into the
GIC.  One for TX and another for RX.  This may have been true on older
OMAPs, but on OMAP4, the TX and RX halves of each McBSP share a single
IRQ routed to the GIC.  The hwmod file for OMAP44xx attempts to signal
this to the library by passing 0 for the RX IRQ.  Someone has made
some attempt in the lib to embrace the fact that there may only be one
interrupt line by checking the rx_irq parameter and only attempting to
request the IRQ if rx_irq >= 0.

There is a problems with this.  The hwmod file is passing 0 as the IRQ
number.  0 is a legal IRQ number on OMAP 4; GIC IRQ IDs range from 0
to 127.  The library code only registers for an rx_irq if one is
passed to it by the hwmod definition, but it makes no attempt to
embrace the fact that there is a shared IRQ line, not that there is a
TX interrupt but no RX interrupt.  As such, the IRQ handlers are
split, and each assumes that if an interrupt fired, that it either
signals a error, or if there is no error, then the TX (or RX) buffer
must need service.  IOW - the interrupt handlers are not fully
decoding their IRQ status registers.  To be correct, on systems with a
shared IRQ, the handlers would both need to get called (right now, the
RX handler is not called), and each handler would need to fully
decoder their status, and not assume that because there was no (TX|RX)
error, that the (TX|RX) buffers need service.

This change fixes the initial issue by checking to see if the IRQ
passed from hwmod is > 0 instead of >= 0.  While 0 is a legal value
for a system IRQ, it is not a legal value for any McBSP IRQ (and
almost certainly never will be).  I am not doing anything to fix the
RX IRQ handler right now, mostly because I don't have a platform to
test any changes on.

It might be good to bring this to TI's attention, hopefully they can
fix their shared IRQ issues themselves.

Change-Id: I2f30a036595898f296f642df9a93a77caeec76a5
Signed-off-by: John Grossman <johngro@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
gcx: improved MMU table dumping.

Change-Id: Ib08231c481533e349affd792ef944386dbcc0593
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: changed debug module names for consistency.

Also fixed compiler warnings.

Change-Id: I254abc86fd08c1be1d2f904f0c10018bcbc5a8c6
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: feature support checks revised.

Packed YUV source rotation is enabled.

Change-Id: I0beaae011e576fcd8dd78e800cc5acde7de9311f
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: source setup optimization.

Share the same setup routines for blitting and
scaling. Use old-style registers for source 0
in blit setup due to a hardware problem.

Change-Id: Ic9ed5c95d37833521f2eda21d818f8a8696bcd4c
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: fixed surface offset calculations.

This is primarily to fix YUV plane location
calculations, but RGB formats are affected as well.

Change-Id: I2877c3c0ec35c03425903c2df9de08ba201cf091
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: two pass filter fixes.

Use the destination format (RGB) for the temporary buffer
if destination angle is not 0 degree due to a hardware
limitation for 4:2:2 rotated destination.

Performance is optimized for temporary buffer by setting
proper buffer geomerty.

Change-Id: Ie53da18fe854adeaaf3d568605bb8630288aee5d
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: fixed scaler temp parameter calculations.

Change-Id: I137acb5efc00bc3ea2dbb9ad596234061cf78257
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: fixed YUV planar odd location origin.

Change-Id: I0bbe26fd4dba445bd9b9c5135fe99bc8099626ff
Signed-off-by: Alexei Shlychkov <x0177296@ti.com>
gcx: version update to 2.2.2

Change-Id: I68624e1604a30c854843f3a2206e70a516cc57a0
Signed-off-by: Craig Stout <craig.stout@ti.com>