From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: alsa-devel@alsa-project.org
Cc: Tony Lindgren <tony@atomide.com>,
Liam Girdwood <lrg@slimlogic.co.uk>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC
Date: Wed, 19 May 2010 11:37:27 +0300 [thread overview]
Message-ID: <201005191137.28029.peter.ujfalusi@nokia.com> (raw)
In-Reply-To: <201005191131.58167.peter.ujfalusi@nokia.com>
On Wednesday 19 May 2010 11:31:57 Ujfalusi Peter (Nokia-D/Tampere) wrote:
> On Wednesday 19 May 2010 08:13:25 ext Jarkko Nikula wrote:
> > On Tue, 18 May 2010 21:13:10 +0100
> >
> > Liam Girdwood <lrg@slimlogic.co.uk> wrote:
> > > I've also added a patch to remove the mcbsp DMA op mode sysfs set
> > > functionality. I think DMA op mode is very specific to the mcbsp client
> > > driver _only_ and shouldn't really be changed by userspace. Please let
> > > me know if you use this feature and I'll drop this patch.
> >
> > I've used to say that the DMA op mode is more like use-case not machine
> > specific but I'm not sure is my point valid onemore. I've used to think
> > that low-latency processing would need accurate DMA pointer (op
> > mode == element) while mp3 playback would need low power consumption
> > (op mode == threshold).
>
> Yeah, it used to be so clear ;)
> I see these:
> element mode: if user want to have constant latency [1]
> threshold mode: variable latency, but possibility to save power [2]
>
> [1] The McBSP is kept full during playback (and empty during capture)
> The DMA pointer moves word-by-word
So the latency is the length of the McBSP FIFO.
>
> [2] The McBSP FIFO fill rate changes (full, drain, refill, full, drain...)
> The DMA pointer moves in bursts.
> Between burst memories can relax, core, MPU also in theory.
> Smart idle helps to conserve more power here
The latency depends on when you are asking.
When the FIFO is full, than you have maximum latency, right at the end of the
drain phase, you will have the shortest latency.
>
> > Peter: what's the status today how well can we do low-latency
> > processing with threshold mode? IRCC, with your FIFO delay query
> > patches, can we estimate the DMA pointer position with enough accuracy?
>
> The DMA pointer is easy, and it was know before as well, but according to
> my tests, the McBSP FIFO caused delay reporting is fairly accurate.
> I'll ask my users, if they have done some additional tests.
So it is not that clear how to view them ;)
--
Péter
next prev parent reply other threads:[~2010-05-19 8:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-18 20:13 [PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC Liam Girdwood
2010-05-18 20:13 ` [PATCH 1/4] OMAP: mcbsp - add omap_mcbsp_set_dma_op_mode() Liam Girdwood
2010-05-19 6:13 ` Jarkko Nikula
2010-05-19 10:50 ` Eduardo Valentin
2010-05-19 11:30 ` Liam Girdwood
2010-05-18 20:13 ` [PATCH 2/4] OMAP: mcbsp - add smart idle configuration API Liam Girdwood
2010-05-18 20:42 ` Nishanth Menon
2010-05-18 23:01 ` [alsa-devel] " Kevin Hilman
2010-05-19 10:43 ` Liam Girdwood
2010-05-19 12:15 ` Peter Ujfalusi
2010-05-19 15:33 ` Kevin Hilman
2010-05-19 5:22 ` Jarkko Nikula
2010-05-19 10:46 ` Eduardo Valentin
2010-05-19 11:21 ` [alsa-devel] " Liam Girdwood
2010-05-19 11:31 ` Eduardo Valentin
2010-05-18 20:13 ` [PATCH 3/4] ASoC: mcbsp - add machine threshold callback Liam Girdwood
2010-05-18 20:38 ` Mark Brown
2010-05-18 20:56 ` Candelaria Villarreal, Jorge
2010-05-19 5:45 ` Jarkko Nikula
2010-05-19 9:37 ` [alsa-devel] " Liam Girdwood
2010-05-18 20:13 ` [PATCH 4/4] OMAP: mcbsp - remove sysfs set for DMA op mode Liam Girdwood
2010-05-19 5:13 ` [PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC Jarkko Nikula
2010-05-19 8:31 ` Peter Ujfalusi
2010-05-19 8:37 ` Peter Ujfalusi [this message]
2010-05-19 10:52 ` Eduardo Valentin
2010-05-19 11:36 ` Peter Ujfalusi
2010-05-19 11:46 ` Eduardo Valentin
2010-05-19 12:09 ` Peter Ujfalusi
2010-05-19 10:42 ` Eduardo Valentin
2010-05-19 11:07 ` Liam Girdwood
2010-05-19 11:28 ` Eduardo Valentin
2010-05-19 12:27 ` Peter Ujfalusi
2010-05-19 14:50 ` Jarkko Nikula
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=201005191137.28029.peter.ujfalusi@nokia.com \
--to=peter.ujfalusi@nokia.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=tony@atomide.com \
/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;
as well as URLs for NNTP newsgroup(s).