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

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

On Tuesday 01 June 2010 12:29:21 ext Jarkko Nikula wrote:
> On Tue, 1 Jun 2010 11:19:30 +0300
> 
> Peter Ujfalusi <peter.ujfalusi@nokia.com> wrote:
> > If threshold is configured to 100 (99 in register), than McBSP will
> > asserts the DMA request line, when 100 locations are free. Than DMA has
> > to send 100 words per DMA request.
> > 
> > So we need to limit the period size (which is used to configure the DMA's
> > elem count - number of words per DMA request) that it shall never be
> > bigger than the threshold.
> 
> Now I get it with some get hands dirty testing :-)
> 
> So this is a feature of SDMA that in threshold mode the transfer size
> must equal or smaller than threshold (as says the TRM).

No exactly. This is the feature of McBSP, that the SDMA must transfer exactly 
the same number of words as the McBSP threshold on DMA request.

> Still don't understand why the transfer size is dependent on peripheral FIFO
> threshold size but that's the fact and we must obey it as Eduardo's
> original patch and your's are doing.

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?

> 
> > If there is interest, I might look at this.
> > I guess this could be useful on McBSP1,3,4, and 5, which has small
> > FIFO...
> 
> Yes, have a packet based DMA transfer saving power and then we have
> bunch of interrupts coming :-)

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?



-- 
Péter