Using DMA

[Timur Tabi]

On Fri, Nov 7, 2008 at 3:31 PM,  <Bruce_Leonard at selinc.com> wrote:

> I'm not sure if I need something as complicated as sound/soc/fsl/fsl_dma.c
> or not.  Maybe you can offer an opinion.  The NAND flash in our product is
> our backing storage, i.e., our hard drive.  We know that we're going to be
> storing away system status at about a 1 second rate and in the future
> we'll probably end up storing collected data at a very high rate, so we're
> potentially going to be doing a LOT of data movement to the NAND.  I'm
> still not clear on the adma stuff, so I'm not sure if a "single-shot
> one-way transfer" is appropriate or not.  Seems like I'd waste a lot of
> time setting up and tearing down the DMA channel.
>
> So, do I need something complicated?

The Async DMA code is very much like an "offload memcpy".  The Elo
control will handle the memcpy while the host CPU can do something
else.  Keep in mind that while the Elo is transferring data, the
memory bus will be saturated.

Whether or not using async dma is worth the effort can only be
determined by profiling the code.  Either it's better, or it's not.
There's no real way to tell in advance.

The advantage of using async DMA over memcpy is that you don't have to
worry about large memcpy operations blocking the CPU and causing apps
the kernel and apps to stall while your driver is copying data.  So
even if overall performance drops, latency will improve and
the system will appear to be faster.  The drawback is that async dma
is more complicated than plain old memcpy.  Since the dma is
asynchronous, you'll need to register a callback function which gets
notified when the Elo has completed the DMA transfer.  That's a very
different design than memcpy.

-- 
Timur Tabi
Linux kernel developer at Freescale