Hi Mike,
On 07/03/2013 08:17 AM, Mike Looijmans wrote:
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
Wouldn't very small periods take up too many interrupts, and also occupy lots of slots?
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.
Thanks for your post Mike. It makes more sense to me now. Correct me if I'm wrong but: - more the periods, more the granularity- but the drawback is you'd need more slots and too many interrupts; so we want fewer periods as many as we need. I still don't know though, how do we arrive at an acceptable number that userspace expects? - periods also will determine buffer size. Considering in future if we'd want to use IRAM as the buffer which is limited on some users of the davinci-pcm, there might not be enough buffer space.
So too many periods is certainly not a good thing. I wonder how we can arrive at what would constitute an acceptable number? As Linus said, "we never break userspace :P" so I'd rather not change anything that breaks someone's audio application.
I will post some RFC notes soon capture our discussion and other ideas I had put together for EDMA as some notes to summarize and get everyone's opinion. I will copy you on that as well. Thanks.
-Joel