On Wed, Apr 5, 2017 at 4:54 AM, Arnaud Mouiche arnaud.mouiche@invoxia.com wrote:
Good catch. All of this makes sense. The SSI surely detect a glitch at the start of the stream and takes it for a sync frame, but not followed by the expected 32x2 bits. It also explain why Caleb and I are not able to reproduce, since we connect SSI internally using the audmux, leaving no place for such glitch.
If only Max can validate this fix...
Yes, that would be nice.
But what is strange is that writing TE and EN at once also avoid the issue... or it means the issue was really timing dependent.
Do you know which one is started first ?
- fsl_ssi_trigger(SNDRV_PCM_TRIGGER_START)
or
- stgl5000 PCM bus being turned on
We can expect that stgl5000 turns the PCM clocks first, and then SSI is turned on. Otherwise anything can happened when the codec starts its clocking.
Correct: stgl5000 turns the PCM clocks first.
Maybe we should look at the Fsync state when idle, and see how it behave during the startup. Depending of pull-up /down-down configuration of the pads, it may be leaved in a undefined state with undefined transitions when stgl5000 turns its output on...
Another way to definitively fix this kind of issue is to use SND_SOC_DAIFMT_CBS_CFS
- the codec generates the N*8*64 kHz or 44.1*64 kHz precise bitclock
(something which is not flexible for the SSI who is connected to a fix PLL output clock)
- but the SSI generate the Sync, leaving no place for wrong detection.
Unfortunately, stgl5000 doesn't seem to support this mode.
Correct. I plan to submitting a sgtl5000 patch that allows setting the lrclk pad strength via device tree.
Will wait for Max to confirm if this solves the swap channel issue on his board as well.
I would like to thank you and Caleb for the tests.
Glad to see your atest application working as expected with the SSI driver :-)