[alsa-devel] fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

Roberto Fichera kernel at tekno-soft.it
Wed Oct 28 15:48:19 CET 2015 

On 10/28/2015 03:24 PM, Caleb Crome wrote:
> On Wed, Oct 28, 2015 at 7:05 AM, Roberto Fichera <kernel at tekno-soft.it> wrote:
>> On 10/28/2015 02:59 PM, Caleb Crome wrote:
>>> On Wed, Oct 28, 2015 at 1:11 AM, Roberto Fichera <kernel at tekno-soft.it> wrote:
>>>> On 10/27/2015 07:57 PM, Fabio Estevam wrote:
>>>>> [Adding Roberto in the thread as he is also trying to get SSI TDM support/
>>>> Thanks Fabio,
>>>>
>>>> I'm also having the same issue but employing SSI in TDM master mode against a SLIC Si32178
>>>> using its PCM mode. PCLK is at 2048KHz, FSYNC is 8KHz slot length is 32 bits (SSI wants
>>>> this since when in master mode) but valid data set to be 8bits in the SSI register.
>>>>
>>>> My Current situation is that I've a custom fsl_ssi.c driver to control the SSI in TDM master mode
>>>> both PCLK and FSYNC works perfectly fine, the SLIC has a register that I can check via SPI for
>>>> such purpose, I can see the clocking status from its side. The main problem I've is exactly the same
>>>> Caleb is having, after a certain amount of SDMA transfers, roughly 1000 or so, everything stops
>>>> without any apparent reason.
>>> My problem is that the channels randomly slip a slot and all words end
>>> up in the wrong slot.  I suspect this is a DMA issue, but I really
>>> haven't diagnosed it yet.  I don't get a full stop on the data.
>> Ah! Ok!
>>
>>> FYI, I'm using a very recent 4.3 kernel from linus's repo, but 4.2
>>> behaved the same.
>> Can you please post the code you are using to setup the SSI, what PCLK and FSYNC rates?
> My codec is generating the clocks and the MX6 is in slave mode.  PCLK
> (I assume that's the bit clock or BCLK in my workld) is 12.288MHz, 
Yes! I meant BCLK.
> and
> the FSYNC is 48kHz.  16 channels/frame, 16 bits/channel.

Ok! In my case it's BCLK at 2048KHz and FSYNC 8KHz, 8 slots at 8bits

>
> I hardly changed the SSI driver at all.  It's goofy now for sure
> because I force it to 16 slots/frame no matter what, so beware.  Other
> than that, I also set the STCCR for 16 channels and set channels_max
> to 16.
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 37c5cd4..73778c2 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -749,7 +749,10 @@ static int fsl_ssi_hw_params(struct
> snd_pcm_substream *substream,
>                  CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK,
>                  channels == 1 ? 0 : i2smode);
>      }
> -
> +    ssi_private->i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET;
> +    regmap_update_bits(regs, CCSR_SSI_SCR,
> +               CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK,
> +               ssi_private->i2s_mode);
>      /*
>       * FIXME: The documentation says that SxCCR[WL] should not be
>       * modified while the SSI is enabled.  The only time this can
> @@ -863,6 +866,15 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
>          return -EINVAL;
>      }
>      scr |= ssi_private->i2s_mode;
> +    // Set to 16 slots/frame
> +    regmap_update_bits(regs, CCSR_SSI_STCCR,
> +               CCSR_SSI_SxCCR_DC_MASK,
> +               CCSR_SSI_SxCCR_DC(16));
> +
> +    regmap_update_bits(regs, CCSR_SSI_SRCCR,
> +               CCSR_SSI_SxCCR_DC_MASK,
> +               CCSR_SSI_SxCCR_DC(16));
> +
>
>      /* DAI clock inversion */
>      switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
> @@ -1084,14 +1099,14 @@ static struct snd_soc_dai_driver
> fsl_ssi_dai_template = {
>      .playback = {
>          .stream_name = "CPU-Playback",
>          .channels_min = 1,
> -        .channels_max = 2,
> +        .channels_max = 16,
>          .rates = FSLSSI_I2S_RATES,
>          .formats = FSLSSI_I2S_FORMATS,
>      },
>      .capture = {
>          .stream_name = "CPU-Capture",
>          .channels_min = 1,
> -        .channels_max = 2,
> +        .channels_max = 16,
>          .rates = FSLSSI_I2S_RATES,
>          .formats = FSLSSI_I2S_FORMATS,
>      },
>
>
> There are other changes I've tried, including watermark changes (check
> out the alsa-dev archives on this thread for what I did before).  This
> morning I am about to try the watermark changes suggested by Nicolin
> Chen.
>
>> Did you have your own DMA handling?
> Nope, I don't really know how to do that.  I'm relying on the built in
> sdma driver (drivers/dma/imx-sdma.c) + fsl pcm
> (sound/soc/fsl/imx-pcm-dma.c) and my modified fsl_ssi.c driver.
In case you need to increase the SSI clock, have a look at CLK_SSI1_PODF within arch/arm/mach-imx/clk-imx6*.c
depending by your SoC, in this file you can change the max clock rate supported by the given SSI clock.

Have you tried to set the SSI in I2S_MODE_SLAVE BTW?

>
> -Caleb
>
>
>>> -Caleb
>>>
>>>>> On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam <festevam at gmail.com> wrote:
>>>>>> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb at crome.org> wrote:
>>>>>>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam at gmail.com> wrote:
>>>>>>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb at crome.org> wrote:
>>>>>>>>
>>>>>>>>>> Could you please try it without using the external SDMA firmware?
>>>>>>>>> I do need *some* SDMA firmware, correct?  The firmware that I'm using
>>>>>>>>> ends up in /lib/firmware/imx/sdma/sdma-imx6q.bin and is md5sum
>>>>>>>>> 5d4584134cc4cba62e1be2f382cd6f3a.
>>>>>>>> SSI can operate with the ROM SDMA firmware.
>>>>>>>>
>>>>>>>> I would like to know if this issue also happens if you don't pass the
>>>>>>>> external firmware and use the internal ROM SDMA firmware instead.
>>>>>>> Ah, good to know.  Do I just remove reference in the .dtsi file?
>>>>>>> Remove the file from the filesystem?  I'll do both to be doubly sure
>>>>>>> :-)
>>>>>> Just remove it from the rootfs. Then you will see a message from the
>>>>>> kernel saying that no external SDMA firmware could be found and that
>>>>>> the internal one is going to be used.
>>>>>>
>>>>>>>> Also, could you try bumping the SSI and SDMA clock rates at the maximum?
>>>>>>> Any idea how I do that?  I guess it's in the .dtsi file perhaps?  I'll
>>>>>>> poke around.
>>>>>> You can try to call clk_set_rate() with the maximum allowed frequency
>>>>>> inside the ssi driver. I don't recall on top of my head what is this
>>>>>> value though.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Fabio Estevam
>>>>> _______________________________________________
>>>>> Alsa-devel mailing list
>>>>> Alsa-devel at alsa-project.org
>>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>>
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel at alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

More information about the Alsa-devel mailing list