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 ?
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@xxxxxxxxx> wrote:
Hi Caleb,
On Mon, Apr 3, 2017 at 8:22 PM, Caleb Crome <caleb@xxxxxxxxx> 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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
