From: vinod.koul@intel.com (Koul, Vinod)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] dmaengine: mxs-dma: add dma support for i.MX23/28
Date: Wed, 23 Feb 2011 16:36:46 +0530 [thread overview]
Message-ID: <1298459206.23371.267.camel@vkoul-udesk3> (raw)
In-Reply-To: <20110223102140.GH29559@n2100.arm.linux.org.uk>
On Wed, 2011-02-23 at 15:51 +0530, Russell King - ARM Linux wrote:
> On Wed, Feb 23, 2011 at 10:05:47AM +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 23, 2011 at 11:25:16AM +0530, Koul, Vinod wrote:
> > > Well in that case you are calling the callback from irq handler which is
> > > not so good. The tasklet is other extreme (slow).
> >
> > tasklets are run on the exit path of interrupts.
> >
> > > Given that this is
> > > also intended for audio I am not sure if calling period elapsed from
> > > tasklet callback will not cause any audio over/underruns, last I tried
> > > it used to break quite often in stressed situations.
> >
> > Nevertheless, the DMA engine API specifies that callbacks shall be called
> > from tasklet context.
>
> Note also that the DMA engine API is supposed to work as follows:
>
> 1. You submit DMA jobs to it.
> 2. The DMA engine starts the first job
> 3. When the first job is complete, it retires it to a retired list and
> marks the tasklet to run
> 4. If there is another job waiting, the DMA engine starts the next job
> 5. Repeat 3 until no further jobs are queued
>
> The tasklet then processes the list of retired jobs, cleaning them
> up and calling their callbacks.
>
> So the way to efficiently handle audio is to initially submit several
> 'period' sized buffers for the DMA engine. As each buffer completes,
> you call snd_pcm_elapsed() to tell ALSA that a period has finished
> and submit the next buffer. As there's always several buffers submitted,
> the DMA engine never waits for the callback to complete. And ALSA is
> capable of handling latency in snd_pcm_elapsed().
Russel,
agree with you on this. But in case you have few periods say 2 and small
period sizes (10ms), or similar scenarios where client is waiting to do
something (process data) on callback notification, faster the callback
better it is.
I know DMA engine species callback to be called from tasklet context,
but do we need this for slave-dma or not? If this is posing some
limitation then I am okay to discuss on ways to improve :)
Thoughts??
--
~Vinod
next prev parent reply other threads:[~2011-02-23 11:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-21 10:21 [PATCH v3] dmaengine: mxs-dma: add dma support for i.MX23/28 Shawn Guo
2011-02-21 17:19 ` Wolfram Sang
2011-02-23 4:01 ` Koul, Vinod
2011-02-23 5:57 ` Shawn Guo
2011-02-23 5:55 ` Koul, Vinod
2011-02-23 10:05 ` Russell King - ARM Linux
2011-02-23 10:21 ` Russell King - ARM Linux
2011-02-23 11:06 ` Koul, Vinod [this message]
2011-02-23 12:12 ` Russell King - ARM Linux
2011-02-23 7:58 ` Lothar Waßmann
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=1298459206.23371.267.camel@vkoul-udesk3 \
--to=vinod.koul@intel.com \
--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