Testing LCD Panel at 72khz from 59.1khz and basically trying out new encore(Nook Colour) settings by steven676
omaplfb: add rotation check to pass the correct stride

Currently omaplfb_bv does calculate stride correctly for NV12.
This patch fixed the stride calculation based on rotation angle.

Change-Id: Icf4b099b2b6780a9e8743c8e712e00d580d1acf4
Signed-off-by: Jack Yen <jyen@ti.com>
OMAPDSS: DISPC: do not lose taps selection

Move taps selection logic before scaling check, so 3- of 5-tap always
get selected, no metter whether we do scaling or not.

Change-Id: I284b29933ca9fd69ae2088f279554dab9a66542c
Signed-off-by: Sergiy Kibrik <sergiy.kibrik@globallogic.com>
OMAP4: USBTLL: Off mode disconnect workaround (Errata i754)

When resuming from OFF mode, the EHCI controller was performing a
reset resume for ports using the TLL interface because the port
status was being cleared. This was caused by the host controller
not restoring the state of the ID pin in the TLL module correctly.
This issue is workarounded by enabling the ID pin pull-up in the TLL
(because the EHCI controller is always the host) and disabling ID
pin events as these are not required for the TLL connection.

Change-Id: Ibc22d77606e05e4dd138819079028ebcf254039e
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ASoC: OMAP ABE: Add "450Hz High-pass" to DL1 Equalizer

For the ABE configured in DL1-only, the DL1 Equalizer can be used
when audio is routed to speaker, so an appropriate profile for that
output must be added. The "450Hz High-pass" has been chosen, its
coefficients were taken from the corresponding profile for DL2
Equalizer.

Change-Id: I6a58a20499d29f06418b82ba1d499a57f945c962
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
ASoC: OMAP ABE: Fix TONES_DL 44.1kHz task settings

Back port of change-id: I0361bc6a1ae2bbc4fa0155e92c9d9c21cff7dfea

C_ABE_FW_TASK_IO_TONES_DL task wasn't scheduled for TONES_DL port at
44.1kHz which introduced noise.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Change-Id: I8972f1dd4524fe04a522fff4d5928886a8f94ad3
gcx: Use GFP_ATOMIC flag for opp_freqs table.

Use GFP_ATOMIC instead of GFP_KERNEL to avoid potential blocking.

Change-Id: Id405a2aa609560b849adf0e096970d0251cfd140
Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
cache-2dmanager: handle case where physical page not found.

This can happen if a userspace app allocates a buffer but doesn't
initialize it, and does not explicitly map the buffer.

Change-Id: Ia431bb8bd713c3eb8ac937b274e8422bc23651f0
Signed-off-by: Craig Stout <craig.stout@ti.com>
cache-2dmanager: force compile fail if cache sizes not specified.

Change-Id: Iad49ef78552994e4611c1c7b79af2d38b2fb141c
Signed-off-by: Craig Stout <craig.stout@ti.com>
OMAPRPC: Updates to OMAPRPC from 3.4 Kernel tree changes.

This patch contains fixes from
* lindent
* checkPatch
* sparse
* comments from 3.4 fixes in offline email
* moved code from drivers/staging/omaprpc to drivers/rpmsg/omaprpc
* Fixes for offset length checking in ION case
* made debugging verboseness switchable from kernel boot args if supplied.

An RPMSG driver that exposes the Remote Procedure Call API to
user space, in order to allow applications to distribute
remote calls to more power-efficient remote processors on OMAP systems.
Like DOMX it uses the existing RPMSG driver.
Used for Distributed Vision Processing.

3.4 branch commit : 34b5939f30e1d5c0c0f2742b4a080b700d01df6f

Change-Id: Ib428e7a346ce11db371b578a2ff41239db7db483
Signed-off-by: Erik Rainey <erik.rainey@ti.com>

Conflicts:
	drivers/staging/Kconfig
OMAPRPC: Ask tiler for pa in buffer lookups

For buffer lookups where no valid handle is available
(either PVR or ion) ask tiler for the physical address
in case there are valid virtual maps for the virtual
address in question.

Change-Id: I7f5d47223a38bef96e2d4aaf52534e6fc7e8f743
Signed-off-by: Alberto Aguirre <a-aguirre@ti.com>
OMAP4: OMAPFB: Always set a x_decim and y_decim in overlays

When using the framebuffer API to setup overlay, there's
currently no way to pass a x_decim and y_decim value in
so set some safe non-zero defaults.  Otherwise, when
the overlay is enabled, zero values will cause divide
by zero error in dispc.

Change-Id: Id2cb4bc4cb6be7b57e3ab5fc28fffc57163faecb
Signed-off-by: Mike J. Chen <mjchen@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
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>
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>
OMAP:DSSCOMP:Limit modedb_len in query ioctl

Add an argument sanity check/limit to prevent
heap corruption attacks.

Change-Id: Ib466af13dba8da6bd4d9b326cdc6b842c8f3caa7
Signed-off-by: Erik Gilling <konkers@android.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>