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

On Sat, Aug 10, 2013 at 12:56:19PM +0200, Daniel Mack wrote:

Hi Robert,

On 10.08.2013 00:50, Robert Jarzmik wrote:

quoted

Daniel Mack [off-list ref] writes:

quoted

 * 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.

quoted

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.

quoted

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