All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: Joel Fernandes <joelf@ti.com>
Cc: alsa-devel@alsa-project.org, lars@metafoo.de
Subject: Re: Query on Audio DMA using DMAEngine
Date: Tue, 02 Jul 2013 07:50:16 +0200	[thread overview]
Message-ID: <51D26A18.8040903@topic.nl> (raw)
In-Reply-To: <51D24A01.2050709@ti.com>

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.

  reply	other threads:[~2013-07-02  5:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <083BC63EECB6FD41B8E81CF7FD87CC0F2E4F1488@DLEE08.ent.ti.com>
2013-06-30 12:06 ` Query on Audio DMA using DMAEngine Lars-Peter Clausen
2013-07-01  6:10   ` Mike Looijmans
2013-07-02  1:28     ` Joel Fernandes
2013-07-02  6:02       ` Mike Looijmans
2013-07-02 12:16         ` Mark Brown
2013-07-02 13:30           ` Mike Looijmans
2013-07-02 14:58             ` Mark Brown
2013-07-04 11:00       ` Clemens Ladisch
2013-07-02  3:33     ` Joel Fernandes
2013-07-02  5:50       ` Mike Looijmans [this message]
2013-07-02 12:13         ` Mark Brown
2013-07-02 13:40           ` Mike Looijmans
2013-07-03  9:09           ` Lars-Peter Clausen
2013-07-03  9:43             ` Mark Brown
2013-07-03 13:17               ` Mike Looijmans
     [not found]                 ` <51D4245F.8070307-Oq418RWZeHk@public.gmane.org>
2013-07-03 19:56                   ` Joel Fernandes
     [not found]               ` <20130703094307.GE27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-03 17:55                 ` [alsa-devel] " Joel Fernandes
     [not found]                   ` <51D46598.6070005-l0cyMroinI0@public.gmane.org>
2013-07-03 18:12                     ` Mark Brown
2013-07-04  5:56                       ` Mike Looijmans
2013-07-04 10:49                         ` Mark Brown
2013-07-03 18:18                   ` [alsa-devel] " Joel Fernandes
2013-07-04  6:06                   ` Mike Looijmans
2013-07-04 10:53                     ` Mark Brown
     [not found]                     ` <51D510EA.1030809-Oq418RWZeHk@public.gmane.org>
2013-07-04 10:59                       ` [alsa-devel] " Sekhar Nori
2013-08-14  4:30         ` Joel Fernandes
2013-08-14  4:53           ` Joel Fernandes
2013-08-14 14:10             ` Mike Looijmans
2013-08-14 12:06           ` Mark Brown
2013-07-02  1:04   ` Joel Fernandes
2013-07-03  9:07     ` Lars-Peter Clausen

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=51D26A18.8040903@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=alsa-devel@alsa-project.org \
    --cc=joelf@ti.com \
    --cc=lars@metafoo.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.