All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabio Estevam <festevam@gmail.com>
To: Arnaud Mouiche <arnaud.mouiche@invoxia.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Sascha Hauer <kernel@pengutronix.de>, Timur Tabi <timur@tabi.org>,
	Caleb Crome <caleb@crome.org>,
	Nicolin Chen <nicoleotsuka@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Max Krummenacher <max.krummenacher@toradex.com>,
	Fabio Estevam <fabio.estevam@nxp.com>
Subject: Re: [PATCH v2] ASoC: fsl_ssi: Fix channel swap on playback start
Date: Wed, 5 Apr 2017 10:43:44 -0300	[thread overview]
Message-ID: <CAOMZO5BRh4DHVZKM1Kb6hwnJsH+v17RzxFS7G-QLyMGuuWcRAg@mail.gmail.com> (raw)
In-Reply-To: <2c31e502-4171-7426-1c24-c258a4d02c55@invoxia.com>

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 :-)

  reply	other threads:[~2017-04-05 13:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 14:48 Fabio Estevam
2017-04-01 15:13 ` Arnaud Mouiche
2017-04-01 16:03   ` Fabio Estevam
2017-04-03  8:19 ` Max Krummenacher
2017-04-03 20:32 ` Caleb Crome
2017-04-03 20:50   ` Caleb Crome
2017-04-03 21:53   ` Fabio Estevam
2017-04-03 22:05     ` Arnaud Mouiche
2017-04-03 22:20       ` Nicolin Chen
2017-04-03 23:22     ` Caleb Crome
2017-04-03 23:40       ` Fabio Estevam
2017-04-03 23:42         ` Caleb Crome
2017-04-04  8:59           ` Arnaud Mouiche
2017-04-04  9:03             ` Arnaud Mouiche
2017-04-04 11:38             ` Fabio Estevam
2017-04-04 17:12               ` Fabio Estevam
2017-04-04 20:09                 ` Arnaud Mouiche
2017-04-04 20:28                   ` Fabio Estevam
2017-04-05  7:54                     ` Arnaud Mouiche
2017-04-05 13:43                       ` Fabio Estevam [this message]
2017-04-05 14:04                       ` Max Krummenacher
2017-04-03 22:08   ` Nicolin Chen
2017-04-03 23:31     ` Caleb Crome
2017-04-03 23:55       ` Nicolin Chen
2017-04-04  0:07         ` Timur Tabi
2017-04-04  0:39         ` Caleb Crome
2017-04-04  1:25           ` Nicolin Chen
2017-04-03 22:36 ` Nicolin Chen
2017-04-03 22:54   ` Fabio Estevam
2017-04-04  0:08     ` Nicolin Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOMZO5BRh4DHVZKM1Kb6hwnJsH+v17RzxFS7G-QLyMGuuWcRAg@mail.gmail.com \
    --to=festevam@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnaud.mouiche@invoxia.com \
    --cc=broonie@kernel.org \
    --cc=caleb@crome.org \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=max.krummenacher@toradex.com \
    --cc=nicoleotsuka@gmail.com \
    --cc=timur@tabi.org \
    --subject='Re: [PATCH v2] ASoC: fsl_ssi: Fix channel swap on playback start' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.