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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
