[alsa-devel] [PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC

[Eduardo Valentin]

On Wed, May 19, 2010 at 10:31:57AM +0200, 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 at 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
> 
> [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
> 
> > 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.

OK. fair enough. What if you really want to avoid the delay at all?

> 
> -- 
> Péter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html