[PATCH 00/20] ARM: pxa: move core and drivers to dmaengine

[Vinod Koul]

On Sat, Aug 10, 2013 at 12:56:19PM +0200, Daniel Mack wrote:
> Hi Robert,
> 
> On 10.08.2013 00:50, Robert Jarzmik wrote:
> > Daniel Mack <zonque at gmail.com> writes:
> > 
> >>  * camera driver:
> >>      I started the transition, but I'm not sure how much sense that
> >>      makes without access to the hardware. I'd much appreciate if
> >>      anyone could volunteer for this piece; I'll happily share what
> >>      I got so far. Sascha, Sachin, Guennadi?
> > Hi Daniel,
> > 
> > Do you mean this driver ? :
> > drivers/media/platform/soc_camera/pxa_camera.c
> 
> Yes, exactly.
> 
> > In that case I might help. But before I can do that, I have to be convinced that
> > dmaengine can deal with this driver. I'm thinking in particular of :
> >  - "hot running DMA" queuing
> >  - multiple DMA channel synchronization (ie. 3 channel sync)
> > 
> > All that is described in there :
> >   Documentation/video4linux/pxa_camera.txt
> 
> Yes, I've seen that, and while the documentation about all that is
> excellent, I lack an explanation why things are so complicated for this
> application, and why a simple cyclic DMA approach does not suffice here.
> I'm sure there's a reason though.
> 
> There might be need to teach the dmaengine core more functionality, but
> in order to do that, we first need to understand the exact requirements.
> 
> > If someone with dmaengine knowledge could have a look at pxa_camera.txt (maybe
> > Vinod ?) and tell me that dma_engine framework fullfills the 2 requirements,
> > then I'll be happy to help.
> 
> Yes, Vinod and and Dan are certainly the best ones to comment on that I
> think.
I read the file esp the "DMA flow" and "DMA hot chaining timeslice issue". I can
say with "properly" implemented dmaengine driver this is very much doable.


Have you guys read: Documentation/dmaengine.txt?

So for "hot chaning" it would work as follows:

Client, allocates and channel and prepares the descriptors A B & C
Client (video), submits buffer A, Buffer B. Both are queued by dma driver
Client calls dma_async_issue_pending
DMA driver will start Buffer A. It gets the completetion for A and then Starts
B. It will invoke callbakc for A.

If you submit C, and invoke dma_async_issue_pending(), C is queued
On B completetion, the DMA driver will start C and invoke callback for B.

If B completes before C is submitted, after submit and invoking
dma_async_issue_pending(), the C buffer will be queued and started.

~Vinod