[alsa-devel] Query on Audio DMA using DMAEngine

Mike Looijmans mike.looijmans at topic.nl
Tue Jul 2 07:50:16 CEST 2013


On 07/02/2013 05:33 AM, Joel Fernandes wrote:
> Hi Mike,
>
> On 07/01/2013 01:10 AM, Mike Looijmans wrote:
> [..]
>> The trouble with the current davinci driver is that the IRQ handler has a
>> real-time requirement, it must finish before the next DMA block completes. This
>
> I looked into this a little more.
>
> I think you are picturing the following:
>
> DMA transfer -> IRQ has to complete -> DMA transfer -> IRQ has to complete.. etc.
>
> This is not really true in the davinci-pcm driver, the normal case without IRAM
> works more like..
>
> DMA ----> DMA ---> DMA
>   \        \        \
>    \__ IRQ  \__ IRQ  \__ IRQ
>
> The only hard requirement is the IRQ handler much finish updating before the
> next DMA transfer, or we're in trouble. Is this what you mean by real-time
> requirement, or did you mean something else?


Yep, that's what I meant. Because I was capturing 16 channels of 32-bit 
data, the DMA buffer would drain in mere milliseconds. Interrupt latency 
on the L138 is pretty bad, I've seen it take over 10ms to handle an IRQ 
on occasion.

But even with much lower loads, I got underruns when recording to SD 
card that I couldn't really explain. I noticed that the SD transfers 
took up a lot of DMA params (about 40), so maybe that was just causing 
too much work for the IRQ or DMA handler routines.

> Either way I'm sure your multi-slot approach is superior, but I don't see how
> you can get away with not updating the DMA addresses on every IRQ with the
> current davinci-pcm or EDMA controller (Unless you use a complicated mechanism
> like ping-pong where the address updates take care of itself). If you are using
> a set of chained slots, you only have so many slots so you have to continuously
> change addresses of the slots at some point or the other for a large transfer.

I use a chain like this:

DMA1 -> DMA2 -> DMA... -> DMA1

This meant I had to use a DMA PARAM slot for every "period". The OMAP 
L138 has 128 of those slots, so it's no problem to use a bunch of them. 
Because the chain is cyclic, there is no need to update any DMA 
parameter while running. All that ALSA needs to do is empty the buffer 
before the cycle completes and the current position gets overwritten.

The IRQ handler is called after each DMA completion, but it's no problem 
if it isn't handled in time. It is only used to give the ALSA framework 
a gentle push that a period has been transferred. Completely missing a 
bunch of interrupts has no effect whatsoever.

>
> Thanks,
>

You're welcome.

Mike.



More information about the Alsa-devel mailing list