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.