* 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
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
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.
One minor point though is that I'm working on pxa27x. If the serie is not
compatible in a way with pxa27x, I won't be able to do anything.
Another point I'd like to know, is what is the performance penalty in using
dmaengine, and do you have any figures ?
Lastly, they was debug information to debug descriptors chaining, channel
statuses, requestors. I didn't see where these had gone, could you point me to
the right file ?
Cheers.
--
Robert
Hi Robert,
On 10.08.2013 00:50, Robert Jarzmik wrote:
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.
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.
One minor point though is that I'm working on pxa27x. If the serie is not
compatible in a way with pxa27x, I won't be able to do anything.
No, it should work just fine on pxa27x.
Another point I'd like to know, is what is the performance penalty in using
dmaengine, and do you have any figures ?
The DMA transfers themselves certainly perform equally well, and the
framework is just a thin layer. Where would you expect performance penalty?
Lastly, they was debug information to debug descriptors chaining, channel
statuses, requestors. I didn't see where these had gone, could you point me to
the right file ?
Such a debug interface is not part of the mmp-pdma implementation at
this point, and the core doesn't have a generic debugfs feature either.
If you need that, we'd have to add it back.
FWIW, I attached my work-in-progress patch for this driver which just
does some basic dmaengine preparations. Be aware that this does not even
compile, it's really just a snapshot.
Thanks,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drivers-media-platform-soc_camera-pxa_camera.c-DMAEN.patch
Type: text/x-patch
Size: 13827 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130810/d527dc67/attachment-0001.bin>
We might reduce the thread broadcast, I don't think these many people care about
pxa camera specifics, and its DMA constraints.
quoted
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.
Well, I think there is a good one.
The current video4linux flow, for video capture, is :
1) userland prepares buffers (ie. dma transfers are prepared, one sg list for
each "image" or "frame")
2) userland queues buffers (no hardware operation)
3) userland starts the capture
4) userland poll for each frame end
a) When a frame is finished, userland unqueues it
=> no overwrite of this frame is possible anymore
b) Userland treats is (might be sent to storage, or compressed, ...)
c) Userland requeues it (while other frame is being DMAed)
Moreover, it should be assumed that waiting for a "end of DMA transfer" before
requeuing the next one (ie. "cold queuing" instead of "hot queueing") will imply
the miss of the next frame start, and one frame will be missed.
With a cyclic DMA, if I understand dmaengine correctly, step 4a. is not
posssible (ie. if userland is slow enough, the frame will be overwritten without
userland knowing it, and while userland is handling it).
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.
The first one that comes to my mind is :
- enable to submit a transfer to a running channel, the same one that served a
previous transfer :
=> this will guarantee ordering of DMA transfers
=> this will guarantee no DMA stops if 2 or more buffers are queued
=> this will try to chain this transfer to the last one queued on the channel
=> if by bad luck the "miss window is hit", ie. the DMA finishes while the
chaining was being done, restart the DMA on its stop
quoted
Another point I'd like to know, is what is the performance penalty in using
dmaengine, and do you have any figures ?
The DMA transfers themselves certainly perform equally well, and the
framework is just a thin layer. Where would you expect performance penalty?
Well, last time I had a look (in [1]), I think I remember having a 3% penalty
on SD card transfers (pxamci driver, mioa701 board, transcend 16Go SD card).
It's been a while and my memory is a bit fuzzy about it. The loss I had at the
time was in queuing/unqueuing the DMA requests IIRC.
quoted
Lastly, they was debug information to debug descriptors chaining, channel
statuses, requestors. I didn't see where these had gone, could you point me to
the right file ?
Such a debug interface is not part of the mmp-pdma implementation at
this point, and the core doesn't have a generic debugfs feature either.
If you need that, we'd have to add it back.
Well, I use that. It's not vital for DMA to work of course, but it's very nice
to have when you mess with DMA transfers :)
FWIW, I attached my work-in-progress patch for this driver which just
does some basic dmaengine preparations. Be aware that this does not even
compile, it's really just a snapshot.
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
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.
Great.
Have you guys read: Documentation/dmaengine.txt?
Yes. I had not understood the "hot chaining" was implied in it, but now I
understand it is part of it, and at the discretion of the slave engine driver.
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.
OK, that settles it then. The API allows hot chaining, and if I understand
Daniel's driver properly, he already thought about it (in
append_pending_queue()).
I have some homework now Daniel, I'll send you my work to include into your
patch serie for the review, and my tests of your patches.
I need a bit of time (1 or 2 weeks), because of holidays, for my patch.
Cheers.
--
Robert
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.
OK, that settles it then. The API allows hot chaining, and if I understand
Daniel's driver properly, he already thought about it (in
append_pending_queue()).
Just for the records: it's not my driver :) I just added some functions
recently to make it work in DT and audio environments.
I have some homework now Daniel, I'll send you my work to include into your
patch serie for the review, and my tests of your patches.
I need a bit of time (1 or 2 weeks), because of holidays, for my patch.
Great, thanks a lot. I extracted some of the patches of my set to
individual trees so they can be merged for 3.12. I'll rebase my series
once 3.12-rc1 is released.
Many thanks for your help,
Daniel