2009-05-11 07:21:31     DMA prioritisation between PPI-connected camera and serial

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

2009-05-11 07:21:31     DMA prioritisation between PPI-connected camera and serial

Tom Parker (UNITED KINGDOM)

Message: 73945   

 

I've been doing some work recently with an SRV-1, using an OV9655 camera attached via the PPI interface. For some reason, I've been seeing wide variations in the time it takes to acquire an image from the camera (with constant resolution), and I was puzzled as to why this was. Variation appears to be in the 35-73ms range, with no discernible pattern, and I'm trying to eventually do capture synchronisation across multiple nodes, so getting this to a constant (or at least more constant) time would be very useful. However, enabling various debugging shed *some* light on this...

 

I'm using a serial interface attached to a Matchport and running pppd over that to establish a network interface. This is running at 921600 baud, with RTS/CTS pins and DMA transfers enabled, and these DMA transfers appear to be interfering with the camera transfers, and hence the seemingly random delays in the camera time. Here's part of my logs (spaces inserted for clarity)

 

<7>[  416.644000] bcap_ppi2dma: reading 153600 bytes (320x240) into [0x00001000]

<7>[  416.644000] bcap_ppi2dma: done read in 153600 bytes for [0x00001000-0x00026800]

<7>[  416.644000] VIDIOCSYNC(0) called when state is 2 (416644)

 

Camera capture starts (ignore "done read", it's wrong, it's just finished the "enable_dma"). DMA has been setup with a callback function tied to the interrupt on end of transfer, and enable_dma has been called.

 

<7>[  416.644000] Starting DMA request for TX (250)

<7>[  416.648000] bfin_5xx: DMA request complete

<7>[  416.648000] Starting DMA request for TX (61)

<7>[  416.648000] bfin_5xx: DMA request complete

<7>[  416.684000] Starting DMA request for TX (250)

<7>[  416.684000] bfin_5xx: DMA request complete

<7>[  416.684000] Starting DMA request for TX (9)

<7>[  416.684000] bfin_5xx: DMA request complete

 

Before the camera DMA request finishes, a number of other DMA requests occur from the serial module, and are in fact completed before the camera request finishes. These are done in the same manner with a callback on completion interrupt and enable_dma.

 

<7>[  416.704000] ->bcap_ppi_irq: pdev->done=1 (416704)

<7>[  416.704000] State change for 0079870c to FRAME_DONE(3)

 

Finally, the camera finishes.

 

Given that the PPI interface should have the highest priority (0) and serial transfer on port 0 is much lower (8/9), I'm puzzled as to why this occurs. I would have thought the camera transfer would have to complete before the serial transfers could start. DMA_TC_PER and DMA_TC_CNT are both 0, so I'm not seeing any obvious overrides. Is there any way to give the camera some sort of override priority to be the only thing using DMA temporarily? Is there anything else that could be causing this slowdown?

QuoteReplyEditDelete

 

 

2009-05-11 08:36:22     DMA prioritisation between PPI-connected camera and serial

Michael Hennerich (GERMANY)

Message: 73949    First of all - when making such analysis - be sure that your debug output is not written out via the serial interface too.

 

Then the serial driver disables global interrupts for some period in various places.

So I guess this is not going to be a DMA priority kind of issue.

-Michael

QuoteReplyEditDelete

 

 

2009-05-11 09:44:55     Re: DMA prioritisation between PPI-connected camera and serial

Tom Parker (UNITED KINGDOM)

Message: 73950   

 

I'm not writing debug to serial (actually, if I did, it would interfere with pppd, as I found out earlier on). The log was taken from dmesg output after running my program. I've also just tried doing this with both the serial and camera debug disabled, which outputs nothing to dmesg after startup, and I'm still getting the same level of variability.

 

Is there any way to reduce the level of interrupt disabling in serial_core? It seems to disable interrupts every time it wants to read to/from the buffer. Might spin_lock_bh work ok enough rather than using spin_lock_irqsave everywhere?

QuoteReplyEditDelete

 

 

2009-05-11 14:18:40     Re: DMA prioritisation between PPI-connected camera and serial

Mike Frysinger (UNITED STATES)

Message: 73960   

 

spin locks are to protect against other cores.  on a UP system, they'll be optimized away.  if the serial core needs to protect against the code running in the interrupt handler, then disabling irqs is the correct behavior.

QuoteReplyEditDelete

 

 

2009-05-12 00:17:17     Re: DMA prioritisation between PPI-connected camera and serial

Sonic Zhang (CHINA)

Message: 73976   

 

You may replace

 

spin_lock_irqsave(&uart->port.lock, flags);

 

with

 

dma_disable_irq(uart->rx_dma_channel);

 

spin_lock_bh(&uart->port.lock);

 

and

 

spin_unlock_irqrestore(&uart->port.lock, flags);

 

with

 

spin_unlock_bh(&uart->port.lock);

 

dma_enable_irq(uart->rx_dma_channel);

 

in function bfin_serial_rx_dma_timeout() to see if this does any help.

QuoteReplyEditDelete

 

 

2009-05-14 08:30:36     Re: DMA prioritisation between PPI-connected camera and serial

Ashish Gupta (INDIA)

Message: 74064   

 

Dear Tom,

 

Since you are using the OV9655 camera driver (so am I), I just wanted to know which specific driver you are using with the uClinux distribution.

 

1. Have you written your own driver or you are using an existing driver from the distribution.

 

2. If it is an existing uClinux driver, can you please lead me to the location in the distribution.

 

3. From your experience of using it, is it fairly stable

 

Thanks & regards

 

Ashish

Attachments

    Outcomes