On Mon, Apr 03, 2017 at 07:54:26PM -0300, Fabio Estevam wrote:
Hi Nicolin,
On Mon, Apr 3, 2017 at 7:36 PM, Nicolin Chen nicoleotsuka@gmail.com wrote:
My extra concern for this change is that ENGcm06222 suggests to set TE and SSIEN together. However, we are still not setting the SSIEN and TE together -- SSIEN is set already before this line in the "ssi_private->use_dma && (vals->scr & CCSR_SSI_SCR_TE)".
On the other hand, ENGcm06222 doesn't mention anything related to the RE bit. Although ENGcm06474 suggests to set TE and RE together, yet it's for another bug (when TE is set after RE, the TX channels might be swapped.)
The idea for this patch came from commit f8fdf5375e2005 ("ASoC: fsl-ssi: add SSIEN errata work around").
I understand what's this patch doing.
In this commit SSIEN, TE and RE are written at the same time as a workaround to ENGcm06222 and ENGcm06532 from the errata document.
Are you sure? Because there is a line of code set SSIEN separately right before the line that this patch applies to. So this patch actually only applies the workaround for ENGcm06532 (the bug when setting RX prior to TX.)
Seems to cause other issues though as reported by Caleb and Arnaud, so we need to find other way to solve this.
Then, the test case: aplay swap_test.wav& sleep 1; killall aplay
It doesn't involve RE at all. So I don't get why setting RE and TE together after setting SSIEN (three bits are not set together here.) could solve the channel swapping problem for a test case which has never involved RE at all. Am I missing something?
Your understanding is correct. In my usecase there is no audio capture involved at all, just stereo audio playback.
The only explanation I can give is the same one from commit f8fdf5375e2005 ("ASoC: fsl-ssi: add SSIEN errata work around").
I don't think that's an explanation. For non-AC97 cases, we are not setting SSIEN and TE together at all, even by applying this change.
Do you have access to any imx board with SSI?
I do. Will try to test it later.