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@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....