On 07/03/2013 11:43 AM, Mark Brown wrote:
On Wed, Jul 03, 2013 at 11:09:22AM +0200, Lars-Peter Clausen wrote:
On 07/02/2013 02:13 PM, Mark Brown wrote:
This sort of cyclic thing tends to be best, ideally you don't need interrupts at all (other than a timer).
Yes, this is usually how it is done. But I'm wondering maybe the EDMA controller only has a small total amount of slots available.
Well, you don't need particularly many slots so long as you can cope with a large period size.
On the OMAP L138, there are 128 PARAM slots. 32 of those are tied to hardware events (though you can use them if you aren't using the related hardware, for example the UART drivers don't use DMA so you can freely use those slots if you want), leaving (at least) 96 PARAM slots free. Both audio events are on the same controller, so you can't use the 128 of the other one (the OMAP has 2 EDMA controllers). Only a few dozen of those are being used by various drivers, the SD card driver being the most hungry. For the system to work, you can even get away with only using one slot, and hence one period, but then you'll have to use a mmap and a timer to fill it.
I experimented with various memory layouts. For large transfers, using 2 big periods was quite enough. I also tested with very small period sizes. Using the original code, I was unable to reliably capture (to /dev/null) at period sizes below 80 samples. With the cyclic DMA, I could set a period size of only 40 samples and still be able to record audio reliably, when using only 8 periods. The same for playback, basically. So that's how I arrived at the MAX_PERIODS define of "8". It will only claim channels when you use them, so setting it to say "100" will not crash the system.
The period size is limited by the EDMA parameter set. It can only transfer 64k-1 "words" per slot. You can (and should!) use the McASP FIFO buffer to increase the word size, thus allowing for period sizes in the megabyte range.
M.