[alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams

[Peter Ujfalusi]

On Tuesday 01 June 2010 14:20:47 ext Jarkko Nikula wrote:
> On Tue, 1 Jun 2010 13:30:10 +0300
> 
> Peter Ujfalusi <peter.ujfalusi at nokia.com> wrote:
> > Because, if you want to transfer in one SDMA burst more than the space
> > free in the McBSP FIFO, than where would the rest go?
> 
> I would have expected peripheral to deassert the DMA request but I
> haven't read the TRM so detail and experimenting with bigger period
> sizes didn't work so some /dev/null effect was obviously happening :-)

And for exchange I have tried the following:
in element mode (DMA is set to transfer 1 word on DMA request).
I have configured the McBSP threshold to max - 4 words.
It does not work either. Playback did not start.
I think McBSP is waiting to receive max - 4 samples, while only one word arrived
Or something, don't know...

> 
> > I guess it could be better than having 128 word long periods on McBSP1,
> > 3, 4, and 5. With small period size the applications also need to be
> > woken up, but if we silently handling the DMA IRQs, and the application
> > is only woken up by every 10. DMA IRQ, it might still save some power?
> 
> This is worth to experiment. Probably more interrupts with or without
> application wakeup reduction does not increase power as much as the
> savings are from core clocks being more idle.

Although application can also configure the avail_min, so it will be not woken 
up for every period....

-- 
Péter