Re: [PATCH 0/5] ASoC: davinci: Use edma-pcm and remove davinci-pcm

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

On 03/05/2015 11:43 AM, Mike Looijmans wrote:
> On 04-03-15 15:10, Peter Ujfalusi wrote:
>> On 03/04/2015 02:28 PM, Mike Looijmans wrote:
>>>> W/o the AFIFO enabled OMAP-L138 should be close enough for the platforms
>>>> which
>>>> does not have FIFO. But I can test w/o FIFO and w/ FIFO on this platform.
>>>
>>> Okay, I hadn't even thought of simply disabling the FIFO. Good to know you
>>> already took this into consideration, good work.
>>
>> Do you have possibility of testing the edma-pcm in your setup by any chance?
> 
> Not really, since the board has some TI hardware that doesn't work on newer
> kernels. The 1271 Wifi chip for one, that stopped working after 3.2.
> 
>>> BTW, I simply linked the params for the McASP-to-DDR in a big loop for my
>>> 2.6.37 based kernel, which solved the problems when sampling 16 channels.
>>
>> Sounds interesting, is it possible to share this code with me so I can see
>> what you have done and I can check if your use case will work with the
>> edma-pcm as well?
> 
> Sure, though I think I've posted it before.
> 
> What I did was just create a set of params in a closed circle, each pointing
> to the next, and the last pointing to the first. This means you'll need as
> many param slots as there are periods though. I typically use 8, but as few as
> 2 will do as well (which is what ping-pong does into the SRAM).

The edma-pcm (via dmaengine) does the same thing, we have the max limit for
periods at 19 ATM, but I'm working on to get that one increased.

> The IRQ handler is then reduced to emit just the "period" signal. There's no
> hard timing requirement to the IRQ handler, user space just needs to grab (or
> fill) the data before the DMA loops around. (This allows for very short
> periods too, if low latency is your goal, since missing one or even several
> interrupts won't harm the transfer.)
> 
> I set up the DMA to use larger chunks by only triggering once every ~16 words,
> so that the "a" parameter of the param can be set much larger, and hence the
> bytes-per-period can be set to values beyond 64k. So the McASP only sends out
> one event every 16 words, and the DMA is set up accordingly.

OK, this is also supported by the edma-pcm, you need to enable the FIFO and
specify the threshold.

> I use a 4MB buffer for that 16-channels-of-32-bits system, usually with 8
> periods of 512kB each.

Glad to hear, if you ever need to update the kernel, the edma-pcm conversion
will not going to cause you regression ;)

> Met vriendelijke groet / kind regards,
> 
> Mike Looijmans
> System Expert
> 
> 
> TOPIC Embedded Systems
> Eindhovenseweg 32-C, NL-5683 KH Best
> Postbus 440, NL-5680 AK Best
> Telefoon: (+31) (0) 499 33 69 79
> Telefax:  (+31) (0) 499 33 69 70
> E-mail: mike.looijmans@topic.nl
> Website: www.topic.nl
> 
> Please consider the environment before printing this e-mail
> 
> Topic zoekt gedreven (embedded) software specialisten!
> http://topic.nl/vacatures/topic-zoekt-software-engineers/
> 


-- 
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel