Hi,
On 02/17/11 15:45, ext Jason Fox wrote:
This appears to work, or at least makes the problem much more rare. I'm trying to understand if the problem is a silicon bug in the AT91 hardware, or if the DMA start code in the Atmel SoC driver is buggy.
I'm not familiar with the Atmel platform, but we have had similar channel swap/shift problems (random channel swap at stream start) in OMAP3 McBSP. In our case it was due to the fact, that OMAP3 McBSP has two bits to actually enable the digital interface. The early code enabled this two bit at the same time, and that was the root of the problem. This is what happened: - DMA has been configured, and started (HW synchronized DMA, McBSP requests the DMA to push data) - McBSP got enabled, and got released at the same time McBSP immediately signaled the DMA to push data. Depending on the timing, there were cases, when McBSP started to send out the data, while the DMA has not pushed anything to McBSP FIFO. So the first word was 0, and the second was the first word from the sample -> channels swapped. This has happened in McBSP slave configuration as well: depending on the timing of the McBSP start we have seen random channel swap. If the McBSP was enabled just right before the start condition on the I2S bus, it sent out 0 for the first word, and than the audio data -> channel swapped. We have fixed this by first enabling the McBSP, but keeping it unreleased state. When McBSP is enabled, it will trigger DMA to start pushing data, so we have valid audio data in the FIFO. We wait for 500us. We release the McBSP. At this point it will either start listening for the start condition on I2S bus (slave), or start the clocks on the bus. Since we already had the valid audio data in the FIFO, the channel swap has gone.
I suppose you also have similar issue. Other solution which we considered could have been used only in case of 16bit/stereo audio: Configure McBSP for 32bit word length (and single slot) in case of 16bit/streo audio. When the race happens McBSP would have sent 0 for both channels, so we would not have the channels swapped. But this will only work with 16bit/stereo mode - and mono as well ;)
So we sticked with the former solution.
I hope this helps for you to figure out something similar for your problem.