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/