• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 242 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP3530 UART TX DMA Patch

Habib Farahani
Prodigy 110 points
Other Parts Discussed in Thread: OMAP3530

I was looking at a patch having to do with Serial RX FIFO.  I think it is related to the Advisory 3.1.1.169 in the Errata.

 

PATCH:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commitdiff;h=ce13d4716a276f4331d78ba28a5093a63822ab95

 

Advisory 3.1.1.169    UART Not Asserting Its TX DMA Request When RX FIFO Is Not Empty

Revision(s) Affected: 3.1.2 and earlier

Details:              As long as the UART RX FIFO is not empty, the UART will not assert its TX DMA

                      request. This means that in scenario using the DMA in both RX and TX, no UART

                      transmission will occur until the RX fifo is emptied. This can cause deadlock situation if

                      the software leaves some bytes in the RX FIFO.

Workaround(s):        Software must make sure to always empty the RX FIFO when using the UART in full

                      duplex mode.

 

 

We have an ES3.1 omap3530 and seem to read back 0x46 as the UART  IP Version (which is less than 0x52, so the serial over ride isn’t applied).  However, the advisory seems to indicate that the bug is on 3.2.1 silicon and earlier, so it seems like it should use the serial override on an ES3.1. 

 

Can someone clarify this?

 

  • 0
    Prodigy 80 points

    I'm curious about this as well.  The patch doesn't look like it directly applies to the issue in the Advisory to me, but maybe it handles a side-effect of trying to empty the RX FIFO when it's already empty?

    Not having access to the OMAP36xx errata, it's not clear if this is something that's in OMAP35xx.  I didn't immediately see anything about this in the AM37xx errata.