From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and resume specific buffer
Date: Mon, 29 Jul 2013 13:17:15 +0100 [thread overview]
Message-ID: <20130729121715.GI24642@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAGsJ_4yVxAJc0UNTFMM1yjKQh6=xv12qPYpnUFZ=wmzrdpUOXQ@mail.gmail.com>
On Mon, Jul 29, 2013 at 03:20:31PM +0800, Barry Song wrote:
> 2013/7/29 Vinod Koul <vinod.koul@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.
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.)
next prev parent reply other threads:[~2013-07-29 12:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 8:42 [PATCH] DMAEngine: sirf: let the users be able to pause and resume specific buffer Barry Song
2013-07-29 2:14 ` Barry Song
2013-07-29 6:08 ` Vinod Koul
2013-07-29 7:20 ` Barry Song
2013-07-29 12:17 ` Russell King - ARM Linux [this message]
2013-07-29 12:46 ` Barry Song
2013-07-29 12:08 ` Russell King - ARM Linux
2013-07-29 11:35 ` Vinod Koul
2013-07-29 12:49 ` Barry Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130729121715.GI24642@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).