[PATCH] DMAEngine: sirf: let the users be able to pause and resume specific buffer
21cnbao at gmail.com
Mon Jul 29 08:46:58 EDT 2013
2013/7/29 Russell King - ARM Linux <linux at arm.linux.org.uk>:
> On Mon, Jul 29, 2013 at 03:20:31PM +0800, Barry Song wrote:
>> 2013/7/29 Vinod Koul <vinod.koul at intel.com>:
>> > The above can be done by
>> > a) have two buffers:
>> > - prepare first and submit, and start
>> > - while first is ongoing, prepare second and start
>> > - first is completed, so you start processing that while second is
>> > getting DMAed
>> > - when processing is completed, submit first again
>> > - when second is completed, start processing that and submit that once
>> > proocessed
>> > b) have multiple buffers, A, B, C & D and redo above schema.
>> yes, that is the original idea for multiple buffer management for DMA.
>> the reason which pushed us to the ping-pong pause is that we don't
>> need to issue software dma descriptor every time for every buffer as
>> hardware can do that.
> If your DMA engine is correctly implemented (and this only works for
> correctly implemented DMA engines), what you can do is:
> - at the start of the transfer, prepare, submit and issue two buffers,
> each with a callback.
> - when the first callback happens
> - that buffer has been transferred.
> - you can now do whatever you need with that data.
> - prepare, submit and issue the next buffer
> This means the DMA engine always has a buffer available to it, so if
> your CPU is fast enough, you can keep the transfer going without the
> DMA channel ever stopping or having to be paused. If your CPU isn't
> fast enough to keep up, the DMA engine will stop at the end of the
> last queued and issued buffer automatically.
yes, suppose there are 4 buffers, we can issue all of buffer 0,1,2,3
at first. if buffer 0 has been read when buffer 3 is transferred,
buffer0 must have been issued again.
so that will keep buffers always alive if cpu is fast enough.
> Bonus points if you have implemented the "move to next buffer" correctly
> too, so that the hardware can do a continuous transfer without having to
> stop and wait between the buffers (provided of course that the next
> transfer is compatible with the previous.)
More information about the linux-arm-kernel