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

[Peter Ujfalusi]

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.

> 
> 
>>
>> After this series we no longer have legacy eDMA users which clears the path for
>> the eDMA driver stack cleanup.
>>
>> Regards,
>> Peter
>> ---
>> Peter Ujfalusi (5):
>>    ASoC: davinci: Select SND_EDMA_SOC when SND_DAVINCI_SOC is enabled
>>    ASoC: davinci-i2s: Convert to use edma-pcm
>>    ASoC: davinci-vcif: Convert to use edma-pcm
>>    ASoC: davinci-mcasp: Deprecate the use of davinci-pcm in favor of
>>      edma-pcm
>>    ASoC: davinci: Remove unused davinci-pcm platform driver
>>
>>   sound/soc/davinci/Kconfig         |  18 +-
>>   sound/soc/davinci/Makefile        |   2 -
>>   sound/soc/davinci/davinci-i2s.c   |  67 ++-
>>   sound/soc/davinci/davinci-mcasp.c |  87 +---
>>   sound/soc/davinci/davinci-pcm.c   | 861
>> --------------------------------------
>>   sound/soc/davinci/davinci-pcm.h   |  41 --
>>   sound/soc/davinci/davinci-vcif.c  |  55 ++-
>>   7 files changed, 79 insertions(+), 1052 deletions(-)
>>   delete mode 100644 sound/soc/davinci/davinci-pcm.c
>>   delete mode 100644 sound/soc/davinci/davinci-pcm.h
>>

Kind regards,
Péter