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>