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

[Mike Looijmans <mike.looijmans@topic.nl>]

On 04-03-15 09:49, Peter Ujfalusi wrote:
> On 03/04/2015 08:19 AM, Mike Looijmans wrote:
>> On 03-03-15 15:45, Peter Ujfalusi wrote:
>>> Hi,
>>>
>>> This series will deprecate and removes the davinci-pcm platform driver and
>>> converts the daVinci DAI drivers to use the edma-pcm.
>>>
>>> The main feature of davinci-pcm has been the so called ping-pong mode, which
>>> can help in situations when the McASP/McBSP/ASP/VCIF experiences underrun or
>>> overrun in playback or capture. This was due to the fact the davinci-pcm w/o
>>> ping-pong needed to reprogram the paRAM slot after each period, this could
>>> cause delay in DMA operation, which leads to starvation.
>>> The edm-pcm does not need reprogramming and it seams to be working as good as
>>> the davinci-pcm with ping-pong.
>>>
>>> I have tested this series on OMAP-L138 EVM with McASP and McBSP. VCIF has been
>>> only compile tested since I do not have access to the HW. The edma-pcm is
>>> already used by AM335x and AM437x and it has been tested on those platforms
>>> extensively.
>>
>> On the OMAP-L138, the "ping pong" only had a negative effect, it even
>> increased the chances of overrun by reducing the interrupt latency tolerance
>> and by doubling the amount of traffic on the bus. The L138 has a FIFO in the
>> McASP which compensates for DDR access latencies and allows for larger
>> transfer blocks. Many other OMAP chips do not have this FIFO and that is why
>> the ping-pong was actually introduced. It compensates for DDR access times,
>> not for interrupt latencies.
>
> I did tested the OMAP-L138 with AFIFO disabled as well. The edma-pcm was
> behaved in a similar manner to the ping-pong mode of davinci-pcm.
> While we are here at the ping-pong: the implementation in the davinci-pcm is
> not the ping-pong which is described in the TRMs, it is more like double
> buffering. The channel which services the McASP is operating to/from SRAM and
> we have the other channel to copy chunks of data from/to DDR to/from SRAM.
> In the case of ping-pong the paRAM entries needs no update runtime, they are
> chained/linked.
> In the distant past we had similar sw setup for OMAP1510/1710 McBSP, the DMA
> was reprogrammed after each period and this introduced random channel
> swap/shift during audio operation. After we introduced the way to link the DMA
> channels this issue were fixed.
>
> But, yes. McASP FIFO is not used, the DMA need to fetch word-by-word from DDR
> in case of the edma-pcm. In the ping-pong case we had burst access to DDR and
> word-by-word access to SRAM.
>
>> If you intend to test the DMA transfers, the L138 is definitely NOT the
>> platform to test this on, as it will actually perform better without ping-pong
>> through on-chip RAM.
>
> 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.

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.

Mike.



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/

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