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: Tue, 4 Apr 2017 08:38:54 -0300	[thread overview]
Message-ID: <CAOMZO5Ahe7fYxZH28J7B0wDFmRc1J2aJv6qoktHoKo15s4b9uQ@mail.gmail.com> (raw)
In-Reply-To: <e5c3ee01-e807-e74d-f90f-2c207a74e539@invoxia.com>

Hi Arnaud,

On Tue, Apr 4, 2017 at 5:59 AM, Arnaud Mouiche
<arnaud.mouiche@invoxia.com> 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.

That's correct. The mode is I2S slave in our case.

>
> 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 ?

Right now I am using 4.11-rc5 + the pinctrl patch
https://patchwork.ozlabs.org/patch/745349/ .

The swap also happens with 3.14, 4.1.15 and 4.10.8.

> 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


In the slave mode case while the wav is playing:

                         ipg              5            6    66000000
       0 0
                            usboh3           0            0
66000000          0 0
                            uart_ipg           1            2
66000000          0 0
                            ssi3_ipg           0            0
66000000          0 0
                            ssi2_ipg           0            0
66000000          0 0
                            ssi1_ipg           1            2
66000000          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

I have the following SSI1 values (with the original 4.1-rc5 + pictrl patch):

# cat /sys/kernel/debug/regmap/2028000.ssi/registers
00: 00000200
04: 00000000
10: 0000105b
18: 009031a3
1c: 0000028d
20: 0000020d
24: 0004e100
28: 00040100
2c: 00880d88
30: 00000000
34: 00000000
38: 00000000
48: 00000000
4c: 00000000
50: 00000000
54: 00000000
58: 00000000

  parent reply	other threads:[~2017-04-04 11:38 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 [this message]
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
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=CAOMZO5Ahe7fYxZH28J7B0wDFmRc1J2aJv6qoktHoKo15s4b9uQ@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.