2011-08-19 06:26:34     Spurious Gaps during DMA SPORT TX

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-08-19 06:26:34     Spurious Gaps during DMA SPORT TX

Ciaran Watterson (IRELAND)

Message: 103035   

 

I am writing out to SPORT at the same time as receiving USB Data. The  issue is I am seeing gaps in the middle of what should be a continuous SPORT DMA transfer. Does the USB DMA channel have higher priority? or another process interrupting the DMA transfer?

QuoteReplyEditDelete

 

 

2011-08-21 23:15:35     Re: Spurious Gaps during DMA SPORT TX

Sonic Zhang (CHINA)

Message: 103060   

 

Which blackfin chip do you use? Which blackfin uClinux-dist release are you running?

QuoteReplyEditDelete

 

 

2011-08-22 04:47:50     Re: Spurious Gaps during DMA SPORT TX

Ciaran Watterson (IRELAND)

Message: 103072   

 

Running the SVN head revision on a BF-527. I am also finding that the DMA interrupt return and SPORT TX shutdown is very sloppy with extra bytes being written when high clock speeds (30-60MHz) are used. And a gratuitously large 500us delay in the tx cleanup - the 527 fifo is 8bytes deep for 1MHz that takes about 64us to empty. That time between the TXHRE flag and when the last byte is sent is very hardware dependent (fifo size). The TUVF flag is maybe too late (after a sensitive frame sync edge), but surely far more reliable. Can the SPORT not be setup to automatically shutdown when it runs out of data in the fifo? I've only tested write modes.  This is in the bfin_sport driver.

QuoteReplyEditDelete

 

 

2011-08-22 05:07:57     Re: Spurious Gaps during DMA SPORT TX

Sonic Zhang (CHINA)

Message: 103073   

 

Which driver do you refer to? If it is the bfin_sport.c, yes, it is just a simple sample driver for user space direct read/write to SPORT. What kind of device do you connect to the SPORT?

QuoteReplyEditDelete

 

 

2011-08-22 06:09:41     Re: Spurious Gaps during DMA SPORT TX

Ciaran Watterson (IRELAND)

Message: 103076   

 

Yes it is the sport generic character driver, bfin_sport.c.

QuoteReplyEditDelete

 

 

2011-08-22 07:32:23     Re: Spurious Gaps during DMA SPORT TX

Ciaran Watterson (IRELAND)

Message: 103078   

 

Actually, the extra bytes being sent is to do with the DITFS config bit I think. Anyway the main question I have here is about the gaps in the sport transfer.

QuoteReplyEditDelete

 

 

2011-08-23 10:29:38     Re: Spurious Gaps during DMA SPORT TX

Ciaran Watterson (IRELAND)

Message: 103092   

 

Added the following the bfin_sport dma_tx_irq_handler confirms an unhandled error is happening in the DMA transfer. SPORT writes are not necessarily completing successfully. wordsize used was 8-bits

 

do {

        status = get_dma_curr_irqstat(dev->dma_tx_chan);

        if (status & DMA_ERR) {

            pr_warning("%s status dma err:%x\n", __func__, status);

        }

} while (status & DMA_RUN);

QuoteReplyEditDelete

 

 

2011-09-08 04:39:04     Re: Spurious Gaps during DMA SPORT TX

Ciaran Watterson (IRELAND)

Message: 103336   

 

okay this problem is more general. Tried using a network adaptor for my Data source. Still getting gaps. No gaps when I run SPORT transfer in a seperate process, while sending data over ethernet. Could it be some interrupt causing the SPORT DMA interrupt to be executed prematurely? or a thread interrupt from the listening port causing the SPORT write to return early - but wouldn't that cause an error return code?

 

I would like an answer to this as it is a real show stopper.

QuoteReplyEditDelete

 

 

2011-09-08 06:40:35     Re: Spurious Gaps during DMA SPORT TX

Aaron Wu (CHINA)

Message: 103337   

 

We will investigate this and be back to you

QuoteReplyEditDelete

 

 

2011-09-08 06:46:37     Re: Spurious Gaps during DMA SPORT TX

Sonic Zhang (CHINA)

Message: 103338   

 

How do you find the "gaps" is in the middle of a continuous SPORT DMA transfer? Run one DMA transfer and capture DTPRI pin on your oscilloscope?

 

And yes, ethernet DMA on bf527 has higher priority over the SPORT DMA by default. If you think default priority is a problem for your application, change the DMA peripheral map in blackfin_dma_init() in arch/blackfin/kernel/bfin_dma.c by yourself.

 

dma_ch[CH_SPORT0_RX].regs.peripheral_map = 1;

 

dma_ch[CH_SPORT0_TX].regs.peripheral_map = 2;

 

dma_ch[CH_EMAC_RX].regs.peripheral_map = 3;

 

dma_ch[CH_EMAC_TX].regs.peripheral_map = 4;

QuoteReplyEditDelete

 

 

2011-09-08 06:48:11     Re: Spurious Gaps during DMA SPORT TX

Sonic Zhang (CHINA)

Message: 103339   

 

Don't worry about DMA error. If there is error during TX transfer, sport_err_handler will be invoked.

QuoteReplyEditDelete

 

 

2011-09-13 09:35:27     Re: Spurious Gaps during DMA SPORT TX

Ciaran Watterson (IRELAND)

Message: 103372   

 

I am sending X number of bytes on the sport and reading using a logic analyser, triggering on the first Frame edge. I'm sending short bursts 64 - 512 (I've tried various). Then based on the frame frequency I'm calculating the number of bytes in the burst.

 

The PC side is continuously sending data to a TCP/IP port. I had assumed that TCP/IP flow control would prevent this eating all the bandwidth - especially when the Data is not being consumed on the application side. Since the Eth DMA is higher priority, seems not unlikely this is the source of the issue in some way or at least contributory. I thought the DMA engine had a way of handling this though, for when a peripheral has an urgent need of data. I also thought that USB DMA was lower priority than the SPORT - Might test this to see if it works, but I'm concerned the issue is maybe how DMA channels have been configured.

 

I think in data dependent mode for SPORT perhaps the error handler isn't called. I'm definitely having incomplete transfers on SPORT where no error code is returned - my application checks for anything other that the count of bytes to be written.

Attachments

    Outcomes