[alsa-devel] [PATCH v2] ASoC: fsl_ssi: Fix channel swap on playback start

[Arnaud Mouiche]

On 04/04/2017 10:59, Arnaud Mouiche wrote:
> So to summarize:
>
> - Caleb and I don't see the issue without the patch, but we are 
> working on DSP mode @ 48K (mostly as master of the bus). But the patch 
> break none trivial "playback only" cases. platforms: imx6 quad for 
> Caleb, imx6sl for me. We are working without codec, checking the bit 
> stream generated by one SSI by recording and checking the content 
> using another SSI.
> - Fabio and Max experience the issue very easily in I2S mode, acting 
> as slave (I guess otherwise generating precise 44.1Khz would be hard), 
> connecting to a STGL5000 codec.
>
> When you are master of the bus, it is important to start EN before TE 
> for the FIFO pre-fill reasons. The samples need to be ready as soon as 
> TE starts.
> I also guess that ENGcm06222 doesn't affect us when the SSI is master 
> (since the SSI is govern only by its own timing)
>
> As slave, this is less important to start EN before TE because you 
> have little chance to receive the SYNC trigger as soon as EN+TE starts 
> => the DMA did get time to fill the FIFO.
> Yet, as slave, ENGcm06222 affect the order of channels, as experienced 
> by Fabio.
>
> So I switch on I2S mode for my SSI => SSI tests and, sadly, I didn't 
> experience issues without the patch.
> I did the test on vanilla 4.11.0-rc5.
>
> which branch/repository are Fabio using for his tests ?
>
> The way clocks are configured may explain the difference:
> Dumping /sys/kernel/debug/clk/clk_summary and checking the differences 
> can give some clues.
> In my case, I have, for the slave SSI #2, while the PCM bus is running 
> at 48khz+I2Smode+2 channels.
>
>     pll4                                  0            0 
> 786432000          0 0
>        pll4_bypass                        0            0 
> 786432000          0 0
>           pll4_audio                      0            0 
> 786432000          0 0
>              pll4_post_div                0            0 
> 786432000          0 0
>                 pll4_audio_div            0            0 
> 786432000          0 0
>                    ssi2_sel               0            0 
> 786432000          0 0
>                       ssi2_pred           0            0 
> 196608000          0 0
>                          ssi2_podf           0 0 98304000          0 0
>                             ssi2           0 0 98304000          0 0
>
> Strangely, the 'enable_cnt' is kept equal to zero while the SSI 
> transmit frames correctly...
> Is there a patch or a branch somewhere that fix this issue ?

Ok, I remember that only IPG clock is necessary when SSI is slave. So 
this is normal.
Arnaud

>
> Also, here is a dump of SSI registers.
> /var/root # cat /sys/kernel/debug/regmap/202c000.ssi/registers
> 00: 00000000
> 04: 00000000
> 10: 0000105b
> 18: 009031a3
> 1c: 00000285
> 20: 00000205
> 24: 0004e100
> 28: 00040100
> 2c: 00880888
> 30: 00000000
> 34: 00000000
> 38: 00000000
> 48: fffffffc
> 4c: fffffffc
> 50: 00000000
> 54: 00000000
> 58: 00000000
>
>
> Arnaud
>
> On 04/04/2017 01:42, Caleb Crome wrote:
>> On Mon, Apr 3, 2017 at 4:40 PM, Fabio Estevam <festevam at gmail.com> 
>> wrote:
>>> Hi Caleb,
>>>
>>> On Mon, Apr 3, 2017 at 8:22 PM, Caleb Crome <caleb at crome.org> wrote:
>>>
>>>> With a vanilla kernel, it works perfectly with the pinctrl patch.
>>>> In this case, I ran a cable from the wandboard over to my computer and
>>>> recorded with audacity, using your wile true script above.
>>>> Here you can see that with 4.11-rc5 plus the pinctrl patch, there is
>>>> no channel swapping:
>>>>
>>>> http://imgur.com/od0LoJP
>>> Which wandboard type do you have? mx6solo,dl or quad?
>>>
>>> I am using  imx6dl-wandboard.
>>>
>>> I am surprised that the channel swap does not happen on your case.
>>> Maybe you need to run the test for an extended period of time?
>> Running on a quad.
>>
>>> On my case I usually get the swap in 1/10 of times. Max uses a Toradex
>>> MX6DL Colibri board and sees the swap in 3-4% of the times.
>> I'll run it for a much longer time and see what happens.
>