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