double-buffering with the omap3 parallel interface

double-buffering with the omap3 parallel interface

[Michael Jones]

Hi Laurent & co.,

I'd like to look at what the maximum possible frame rates are for a 
sensor connected to the OMAP3 ISP CCDC via the parallel interface, 
writing frames directly to memory.  I understand that there is some 
minimum amount of time required between frames to pass on the finished 
frame and set up the address to be written to for the next frame.  From 
the manual it looks like a double buffering scheme would've been 
available on a different sensor interface, but isn't on the parallel one.

Do I see that right?  Is it impossible to use double buffering of any 
sort while using the parallel interface to memory?

I'm still using an older version of the driver, but I've browsed the 
current state of the code, too.  What behavior do you expect if the time 
between frames is too short for the buffer management?  Can it be 
recovered from?  Has this behavior changed in recent versions?

I see from the ISP block diagram that the "circular buffer" is between 
the SBL and the MMU.  Could this maybe be used to help the situation? 
It seems to currently not be used at all along this path.

thanks,
Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier

Re: double-buffering with the omap3 parallel interface

[Sakari Ailus]

Hi Michael,

On Wed, Jun 12, 2013 at 06:16:26PM +0200, Michael Jones wrote:
> Hi Laurent & co.,
> 
> I'd like to look at what the maximum possible frame rates are for a
> sensor connected to the OMAP3 ISP CCDC via the parallel interface,
> writing frames directly to memory.  I understand that there is some
> minimum amount of time required between frames to pass on the
> finished frame and set up the address to be written to for the next
> frame.  From the manual it looks like a double buffering scheme
> would've been available on a different sensor interface, but isn't
> on the parallel one.
> 
> Do I see that right?  Is it impossible to use double buffering of
> any sort while using the parallel interface to memory?
> 
> I'm still using an older version of the driver, but I've browsed the
> current state of the code, too.  What behavior do you expect if the
> time between frames is too short for the buffer management?  Can it
> be recovered from?  Has this behavior changed in recent versions?
> 
> I see from the ISP block diagram that the "circular buffer" is
> between the SBL and the MMU.  Could this maybe be used to help the
> situation? It seems to currently not be used at all along this path.

The way the hardware is controlled has stayed the same for a very long time.
My recollection matches with your findings --- even if double buffering of
the buffer pointers would be available in some situations, it isn't used by
the driver. You might ask why, and the reason for that is that there are
tonds of other things that typically need to be configured (as a result of
the configuration given by the user using the private IOCTLs) at that very
time. If a block becomes busy while you're configuring it you can say good
bye to your frame in any case; whether yousd set up writing it to system
memory using DMA or not...

What comes to the minimum time per frames, I could give you a guesstimate of
1 ms. It depends a lot on how well other drivers in the system behave, but
in general that should be enough. Something must be very wrong if you need
significantly more than that.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: double-buffering with the omap3 parallel interface

[Laurent Pinchart]

Hi Michael,

On Monday 17 June 2013 02:44:50 Sakari Ailus wrote:
> On Wed, Jun 12, 2013 at 06:16:26PM +0200, Michael Jones wrote:
> > Hi Laurent & co.,
> > 
> > I'd like to look at what the maximum possible frame rates are for a sensor
> > connected to the OMAP3 ISP CCDC via the parallel interface, writing frames
> > directly to memory. I understand that there is some minimum amount of time
> > required between frames to pass on the finished frame and set up the
> > address to be written to for the next frame. From the manual it looks like
> > a double buffering scheme would've been available on a different sensor
> > interface, but isn't on the parallel one.
> > 
> > Do I see that right? Is it impossible to use double buffering of any sort
> > while using the parallel interface to memory?

That's correct. The CCDC has a single destination memory address register, so 
you can only queue a single buffer to the hardware.

> > I'm still using an older version of the driver, but I've browsed the
> > current state of the code, too. What behavior do you expect if the time
> > between frames is too short for the buffer management? Can it be recovered
> > from?

The CCDC is stopped after each frame, reconfigured, and then restarted. If a 
new frame arrives before the CCDC is restarted the frame will be dropped, but 
the CCDC might lose synchronization as well (this would need to be verified, 
the OMAP3 ISP hardware is pretty sensitive to such issues, but I don't 
remember from the top of my head the details of what synchronization problems 
affect each block).

> > Has this behavior changed in recent versions?

The overall behaviour shouldn't have changed, no.

> > I see from the ISP block diagram that the "circular buffer" is between the
> > SBL and the MMU. Could this maybe be used to help the situation? It seems
> > to currently not be used at all along this path.

Not that I know of. The circular buffer allows allocating less physical memory 
than what would be required to store a full frame, if the consumer can process 
image data as it gets written to memory. The memory buffer then essentially 
acts as a FIFO.

> The way the hardware is controlled has stayed the same for a very long time.
> My recollection matches with your findings --- even if double buffering of
> the buffer pointers would be available in some situations, it isn't used by
> the driver. You might ask why, and the reason for that is that there are
> tonds of other things that typically need to be configured (as a result of
> the configuration given by the user using the private IOCTLs) at that very
> time. If a block becomes busy while you're configuring it you can say good
> bye to your frame in any case; whether yousd set up writing it to system
> memory using DMA or not...

Several CCDC registers are latched by the VS sync pulse. It might thus be 
possible to reconfigure the CCDC right after frame start instead of right 
after frame end.

> What comes to the minimum time per frames, I could give you a guesstimate of
> 1 ms. It depends a lot on how well other drivers in the system behave, but
> in general that should be enough. Something must be very wrong if you need
> significantly more than that.

-- 
Regards,

Laurent Pinchart