Re: contiguous DMA while transferring data over IP

Hi Ned,
Thanks for the ideas.  Looking into the driver, pxa_camera.c, I see that it was written for V4L and is therefore frame oriented.  I am reading single frames from a large CCD over the QuickCapture interface and it takes a few seconds to complete a read.  It then takes another few seconds to transfer the data.  The overall latency is too high.  So, I really do need to get a single frame out faster rather than keeping up with a frame rate.  I may only get a frame a minute, driven by an external trigger signal.

I tried fooling the driver by telling it that each frame is a fraction of the actual frame.  Unfortunately, I ended up with bad data at the subframe boundaries (I guess the FIFO overflowed).  There should be a way for the driver to provide 'updates' to the application -- I got x% of the data, go ahead and read it...  This is much lower level code than I am used to, so any suggestions are very welcome.  Thanks for pointing me to the right section of the dev manual, I'll see if I can make some sense of it.


Thanks.



----- Original Message ----
From: Ned Forrester <nforrester@...>
To: General mailing list for gumstix users. <gumstix-users@...>
Sent: Tuesday, June 30, 2009 8:10:17 PM
Subject: Re: [Gumstix-users] contiguous DMA while transferring data over IP

On 06/30/2009 08:37 PM, Eugene Grayver wrote:
> Hmm... I must be entirely ignorant about the details of PXA DMA
> transfers.  We modified the kernel to have 16MB of coherent memory
> space and were doing a single LONG DMA transfer from the FIFO to the
> memory.  I did not realize that the transfer was already being broken
> up into 8k chunks.  I would be entirely happy with chunks of ~100kB.
> However, when I tried to break the transfer up into multiple DMAs
> from user mode, I got overruns.

Hmmm...  The kernel driver must be breaking the transfer into smaller
bits.  I suggest you take a look at the driver code and see if you can
figure out what it is doing for you with regard to partitioning the DMA
and how it is managing to keep up with the data input.  I gather 16MB is
enough for a whole picture.

Exactly which peripheral on the PXA270 are you using?  Which driver?
What speed (bytes/sec) does this device require?

If you are using the Quick Capture Interface, I see reference in section
27.4.4.3 of the Developer's Manual to setting up a descriptor chain for
and entire frame.  That is what I would expect to be required to capture
data from an external device that is supplying the transfer clock.
Perhaps this is what the kernel driver is doing.

Do you really have to get a single frame faster, or is it a matter of
keeping up with a particular frame rate?  If the latter, could you just
use two buffers so that you can be transmitting one while the other is
being filled by the driver?

--
Ned Forrester                                      nforrester@...
Oceanographic Systems Lab                                  508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution          Woods Hole, MA 02543, USA
http://www.whoi.edu/
http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212
http://www.whoi.edu/hpb/Site.do?id=1532
http://www.whoi.edu/page.do?pid=10079


------------------------------------------------------------------------------
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users