iMX5 FEC RX FIFO DMA starvation

[mitchmiers]

We have a legacy application that uses an i.MX53 SoC.  The device has, for a long time, rendered MPEG-2 and MP4 streams in SD.  We cannot change the SoC used, so please don't suggest a later iMX or different software.  We are limited to linux-2.6-imx/imx-2.6.35-maintain kernel and the LTIB 11-09-01 system release.

For various reasons, we cannot change the SD output (it's actually an S-Video connection), but we need to start taking ATSC HD as input, so we need to downscale that to SD.  The input is MPEG-TS, with either MPEG-2 or H.264 video, via UDP multicast.

Here is the problem: when I play back a 1080p30 TS stream stored in a file on MMC, video playback at 720x480 is perfect (file -> VPU -> IPU -> display).  When I play back the same stream via UDP (UDP -> VPU -> IPU -> display), the video output is garbled due to missing motion vectors and/or I-frames.

We also notice a relatively high number of RX FIFO overruns in the FEC when streaming via UDP (on the order of 30 rx_fifo_overruns per second).  NOTE: overruns are being measured as OV bit set in RxBD as reported by the driver.  The only that that makes sense to us is that RX DMA is not being scheduled, or is stalling, and the RX FIFO overflows.

 - If we loop the TS at the streaming source, the distortion moves around during playback.  Sometimes the video in a section will play perfectly, while in a later loop it will play back poorly.

 - If we store the file on the MMC attached to the iMX53,  and play it back, we get good playback

 - If we store the file on a host computer, and NFS mount the host, playback occasionally hiccups, but doesn't distort - but the RX FIFO overrun count increases.  Our supposition is that TCP is ensuring we aren't losing packets (our NFS mount is via TCP).

The Freescale VPU decoders aren't particularly forgiving, which is why this is a show stopper.  I can't put this in front of a customer as is.

What can we do to eliminate the ~3% packet loss?  We've tried:

 - change R_FSTART in the FEC.  We dropped this to 0x30 while making sure X_WMRK was 00b.  No significant help.

 - I looked at the arbiter, but it appears as the priorities for the masters are set in silicon?  Specifically, PLARB1.

 - FEC DMA does not appear to be SDMA, but unique to the FEC, correct?

Are there any suggestions on what to look at?

Thanks,

Mitch

[igorpadykov · Accepted solution]

Hi Mitch

one can try to increase FEC priority:
            0x63fd_8044=0x33
            0x63fd_8048=0x1901a3
or  increase FEC RX FIFO size.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mitchmiers]

That did the trick.  With just the M4IF changes, the packet loss rate dropped to just a few packets over a 10 second sample (< .01%).  We'll try increasing the RX FIFO size as well and see if that gets any of the remainder.

Now I've got to go reread the M4IF chapter and try to understand those register settings...

Many thanks!

Mitch