fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

Hello Arnaud, all,

I'm trying to get the i.MX6 SSI working in 16-channel TDM mode.  FYI, I'm
working with the stock 4.3 kernel at https://github.com/torvalds/linux.

When I apply the patch below, the SSI does all configure properly and even
starts streaming properly with all the bits in the right place on the SSI
pins.  However, given a little bit of time and/or IO to the SD card, the
bit-stream slips by 1 slot, causing all of the channels to be misaligned.

My changes to the SSI driver are very minimal (shown below), and amount to
forcing it into network (TDM) mode, and changing the maximum channels, and
setting the STCCR DC mask.

There is no indication from user space that anything has slipped, so the
data stream just continues on shifted by 1 slot.

You (Arnaud) mentioned in a previous thread ("Multiple codecs on one sound
card for multi-channel sound card"), that I should just have to set
channels_max (and presumably the other changes I mentioned), and it'll work
mostly.  However, it's very unreliable at the moment.

Any thoughts to how I can diagnose this problem would be greatly
appreciated!

So, what happens is this:

The SSI Starts sending data like this:
SLOT 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
DATA 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15

But then after time, something slips and without warning it goes to:
SLOT 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
DATA 15 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14

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,
     },

Another thing I have tried is changing the watermark level for the fifo to
give the DMA interrupt some extra time.  The problem still happens, but
seems to be a bit better.

The fifo watermark change is this:
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 73778c2..7c2e4b0 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -54,6 +54,8 @@
 #include "fsl_ssi.h"
 #include "imx-pcm.h"

+#define WATERMARK 8
+
 /**
  * FSLSSI_I2S_RATES: sample rates supported by the I2S
  *
@@ -943,7 +950,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
      * size.
      */
     if (ssi_private->use_dma)
-        wm = ssi_private->fifo_depth - 2;
+        wm = ssi_private->fifo_depth - WATERMARK;
     else
         wm = ssi_private->fifo_depth;

@@ -1260,8 +1267,8 @@ static int fsl_ssi_imx_probe(struct platform_device
*pdev,
      * We have burstsize be "fifo_depth - 2" to match the SSI
      * watermark setting in fsl_ssi_startup().
      */
-    ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
-    ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
+    ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth -
WATERMARK;
+    ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth -
WATERMARK;
     ssi_private->dma_params_tx.addr = ssi_private->ssi_phys +
CCSR_SSI_STX0;
     ssi_private->dma_params_rx.addr = ssi_private->ssi_phys +
CCSR_SSI_SRX0;


Thanks,
  -Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[arnaud.mouiche]

Hello Caleb,

I go through all [few] patchs we apply to the 4.0 linux tree (didn't 
jump to 4.2 yet).
There is one concerning the DMA firmware you can find in the freescale 
tree, available at git://git.freescale.com/imx/linux-2.6-imx.git

commit 619bfca89908b90cd6606ed894c180df0c481508
Author: Shawn Guo <shawn.guo@freescale.com>
Date:   Tue Jul 16 22:53:18 2013 +0800

     ENGR00269945: firwmare: imx: add imx6q sdma script

     Add imx6q sdma script which will be used by all i.MX6 series.

     Signed-off-by: Shawn Guo <shawn.guo@freescale.com>

  firmware/Makefile                     |   1 +
  firmware/imx/sdma/sdma-imx6q.bin.ihex | 116 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 117 insertions(+)


I don't know how 4.3rcN catch some of the freescale patch. but you may 
check if you need to apply this one.
I know there are some other SDMA firmware available all around in this 
freescale tree. I didn't find proper release note or documentation. May 
be you can test them also.

Arnaud

Le 19/10/2015 17:55, Caleb Crome a écrit :
> Hello Arnaud, all,
>
> I'm trying to get the i.MX6 SSI working in 16-channel TDM mode.  FYI, 
> I'm working with the stock 4.3 kernel at 
> https://github.com/torvalds/linux.
>
> When I apply the patch below, the SSI does all configure properly and 
> even starts streaming properly with all the bits in the right place on 
> the SSI pins.  However, given a little bit of time and/or IO to the SD 
> card, the bit-stream slips by 1 slot, causing all of the channels to 
> be misaligned.
>
> My changes to the SSI driver are very minimal (shown below), and 
> amount to forcing it into network (TDM) mode, and changing the maximum 
> channels, and setting the STCCR DC mask.
>
> There is no indication from user space that anything has slipped, so 
> the data stream just continues on shifted by 1 slot.
>
> You (Arnaud) mentioned in a previous thread ("Multiple codecs on one 
> sound card for multi-channel sound card"), that I should just have to 
> set channels_max (and presumably the other changes I mentioned), and 
> it'll work mostly. However, it's very unreliable at the moment.
>
> Any thoughts to how I can diagnose this problem would be greatly 
> appreciated!
>
> So, what happens is this:
>
> The SSI Starts sending data like this:
> SLOT 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
> DATA 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
>
> But then after time, something slips and without warning it goes to:
> SLOT 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
> DATA 15 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14
>
> 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,
>      },
>
> Another thing I have tried is changing the watermark level for the 
> fifo to give the DMA interrupt some extra time. The problem still 
> happens, but seems to be a bit better.
>
> The fifo watermark change is this:
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 73778c2..7c2e4b0 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -54,6 +54,8 @@
>  #include "fsl_ssi.h"
>  #include "imx-pcm.h"
>
> +#define WATERMARK 8
> +
>  /**
>   * FSLSSI_I2S_RATES: sample rates supported by the I2S
>   *
> @@ -943,7 +950,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
>       * size.
>       */
>      if (ssi_private->use_dma)
> -        wm = ssi_private->fifo_depth - 2;
> +        wm = ssi_private->fifo_depth - WATERMARK;
>      else
>          wm = ssi_private->fifo_depth;
>
> @@ -1260,8 +1267,8 @@ static int fsl_ssi_imx_probe(struct 
> platform_device *pdev,
>       * We have burstsize be "fifo_depth - 2" to match the SSI
>       * watermark setting in fsl_ssi_startup().
>       */
> -    ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
> -    ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
> +    ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 
> WATERMARK;
> +    ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 
> WATERMARK;
>      ssi_private->dma_params_tx.addr = ssi_private->ssi_phys + 
> CCSR_SSI_STX0;
>      ssi_private->dma_params_rx.addr = ssi_private->ssi_phys + 
> CCSR_SSI_SRX0;
>
>
> Thanks,
>   -Caleb
>

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Tue, Oct 20, 2015 at 12:36 AM, arnaud.mouiche@invoxia.com
<arnaud.mouiche@invoxia.com> wrote:
> Hello Caleb,
>
> I go through all [few] patchs we apply to the 4.0 linux tree (didn't jump to
> 4.2 yet).
> There is one concerning the DMA firmware you can find in the freescale tree,
> available at git://git.freescale.com/imx/linux-2.6-imx.git
>
> commit 619bfca89908b90cd6606ed894c180df0c481508
> Author: Shawn Guo <shawn.guo@freescale.com>
> Date:   Tue Jul 16 22:53:18 2013 +0800
>
>     ENGR00269945: firwmare: imx: add imx6q sdma script
>
>     Add imx6q sdma script which will be used by all i.MX6 series.
>
>     Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
>
>  firmware/Makefile                     |   1 +
>  firmware/imx/sdma/sdma-imx6q.bin.ihex | 116
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 117 insertions(+)
>
>
> I don't know how 4.3rcN catch some of the freescale patch. but you may check
> if you need to apply this one.
> I know there are some other SDMA firmware available all around in this
> freescale tree. I didn't find proper release note or documentation. May be
> you can test them also.
>
> Arnaud

Hi Arnaud,
  My root filesystem already had that firmware in it (the kernel
didn't have the kernel patch, but when I applied that patch, the
generated sdma script was identical.

So, unfortunately, that's not the problem with the channel slipping.
Any other thoughts on why the channel would slip?  Or pointers on how
to diagnose?  I have an oscilloscope & know how to use it :-)  Also, I
can flip a GPIO to watch for timing of interrupts, etc (although I
haven't done that yet).


Thanks,
  -Caleb




>
>
> Le 19/10/2015 17:55, Caleb Crome a écrit :
>>
>> Hello Arnaud, all,
>>
>> I'm trying to get the i.MX6 SSI working in 16-channel TDM mode.  FYI, I'm
>> working with the stock 4.3 kernel at https://github.com/torvalds/linux.
>>
>> When I apply the patch below, the SSI does all configure properly and even
>> starts streaming properly with all the bits in the right place on the SSI
>> pins.  However, given a little bit of time and/or IO to the SD card, the
>> bit-stream slips by 1 slot, causing all of the channels to be misaligned.
>>
>> My changes to the SSI driver are very minimal (shown below), and amount to
>> forcing it into network (TDM) mode, and changing the maximum channels, and
>> setting the STCCR DC mask.
>>
>> There is no indication from user space that anything has slipped, so the
>> data stream just continues on shifted by 1 slot.
>>
>> You (Arnaud) mentioned in a previous thread ("Multiple codecs on one sound
>> card for multi-channel sound card"), that I should just have to set
>> channels_max (and presumably the other changes I mentioned), and it'll work
>> mostly. However, it's very unreliable at the moment.
>>
>> Any thoughts to how I can diagnose this problem would be greatly
>> appreciated!
>>
>> So, what happens is this:
>>
>> The SSI Starts sending data like this:
>> SLOT 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
>> DATA 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
>>
>> But then after time, something slips and without warning it goes to:
>> SLOT 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
>> DATA 15 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14
>>
>> 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,
>>      },
>>
>> Another thing I have tried is changing the watermark level for the fifo to
>> give the DMA interrupt some extra time. The problem still happens, but seems
>> to be a bit better.
>>
>> The fifo watermark change is this:
>> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
>> index 73778c2..7c2e4b0 100644
>> --- a/sound/soc/fsl/fsl_ssi.c
>> +++ b/sound/soc/fsl/fsl_ssi.c
>> @@ -54,6 +54,8 @@
>>  #include "fsl_ssi.h"
>>  #include "imx-pcm.h"
>>
>> +#define WATERMARK 8
>> +
>>  /**
>>   * FSLSSI_I2S_RATES: sample rates supported by the I2S
>>   *
>> @@ -943,7 +950,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
>>       * size.
>>       */
>>      if (ssi_private->use_dma)
>> -        wm = ssi_private->fifo_depth - 2;
>> +        wm = ssi_private->fifo_depth - WATERMARK;
>>      else
>>          wm = ssi_private->fifo_depth;
>>
>> @@ -1260,8 +1267,8 @@ static int fsl_ssi_imx_probe(struct platform_device
>> *pdev,
>>       * We have burstsize be "fifo_depth - 2" to match the SSI
>>       * watermark setting in fsl_ssi_startup().
>>       */
>> -    ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
>> -    ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
>> +    ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth -
>> WATERMARK;
>> +    ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth -
>> WATERMARK;
>>      ssi_private->dma_params_tx.addr = ssi_private->ssi_phys +
>> CCSR_SSI_STX0;
>>      ssi_private->dma_params_rx.addr = ssi_private->ssi_phys +
>> CCSR_SSI_SRX0;
>>
>>
>> Thanks,
>>   -Caleb
>>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[arnaud.mouiche]

Le 20/10/2015 19:43, Caleb Crome a écrit :
> On Tue, Oct 20, 2015 at 12:36 AM, arnaud.mouiche@invoxia.com
> <arnaud.mouiche@invoxia.com> wrote:
>> Hello Caleb,
>>
>> I go through all [few] patchs we apply to the 4.0 linux tree (didn't jump to
>> 4.2 yet).
>> There is one concerning the DMA firmware you can find in the freescale tree,
>> available at git://git.freescale.com/imx/linux-2.6-imx.git
>>
>> commit 619bfca89908b90cd6606ed894c180df0c481508
>> Author: Shawn Guo <shawn.guo@freescale.com>
>> Date:   Tue Jul 16 22:53:18 2013 +0800
>>
>>      ENGR00269945: firwmare: imx: add imx6q sdma script
>>
>>      Add imx6q sdma script which will be used by all i.MX6 series.
>>
>>      Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
>>
>>   firmware/Makefile                     |   1 +
>>   firmware/imx/sdma/sdma-imx6q.bin.ihex | 116
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 117 insertions(+)
>>
>>
>> I don't know how 4.3rcN catch some of the freescale patch. but you may check
>> if you need to apply this one.
>> I know there are some other SDMA firmware available all around in this
>> freescale tree. I didn't find proper release note or documentation. May be
>> you can test them also.
>>
>> Arnaud
> Hi Arnaud,
>    My root filesystem already had that firmware in it (the kernel
> didn't have the kernel patch, but when I applied that patch, the
> generated sdma script was identical.
>
> So, unfortunately, that's not the problem with the channel slipping.
> Any other thoughts on why the channel would slip?  Or pointers on how
> to diagnose?  I have an oscilloscope & know how to use it :-)  Also, I
> can flip a GPIO to watch for timing of interrupts, etc (although I
> haven't done that yet).
>
>
> Thanks,
>    -Caleb

Hello Caleb,

In your situation, I would:
- check if TUE0/1 flag never rise (Transmitter Underrun) by activating 
the TUE0/1IE bit to generate related interrupts. It looks like already 
enabled in 4.0 by collecting statistics with fsl_ssi_dbg_isr(). Despite 
there is no printk message on underrun, stats can be read from 
/sys/kernel/debug/xxxx.ssi/stats.

- I suspect the dma is not fast enough to fill the FIFO. may be you 
should dig to check how SDMA priority are configured amongs the 
differents DMA channels.
Not something I already look at before. A quick look suggest that 
DMA_PRIO_HIGH is _NOT_ configured by the fsl_ssi.c driver (wheras the 
imx-ssi.c did)

Regards,
Arnaud


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Wed, Oct 21, 2015 at 12:32 AM, arnaud.mouiche@invoxia.com
<arnaud.mouiche@invoxia.com> wrote:
>
>
> Le 20/10/2015 19:43, Caleb Crome a écrit :
>> Hi Arnaud,
>>    My root filesystem already had that firmware in it (the kernel
>> didn't have the kernel patch, but when I applied that patch, the
>> generated sdma script was identical.
>>
>> So, unfortunately, that's not the problem with the channel slipping.
>> Any other thoughts on why the channel would slip?  Or pointers on how
>> to diagnose?  I have an oscilloscope & know how to use it :-)  Also, I
>> can flip a GPIO to watch for timing of interrupts, etc (although I
>> haven't done that yet).
>>
>>
>> Thanks,
>>    -Caleb
>
>
> Hello Caleb,
>
> In your situation, I would:
> - check if TUE0/1 flag never rise (Transmitter Underrun) by activating the
> TUE0/1IE bit to generate related interrupts. It looks like already enabled
> in 4.0 by collecting statistics with fsl_ssi_dbg_isr(). Despite there is no
> printk message on underrun, stats can be read from
> /sys/kernel/debug/xxxx.ssi/stats.

Heh, I checked that and I couldn't get the fsl_ssi_dbg_isr to trigger
ever, for any reason.  Somehow interrupts seem to be disabled in the
SSI driver, and I can't figure out how to enable them.  It appears
that the only interrupt required is the DMA interrupt, and SSI
interrupts are not checked.    The /sys/kernel/debug/xxxx.ssi/stats
file reads all zeros no matter what, even during playing, and even
after the user space detects underruns.

>
> - I suspect the dma is not fast enough to fill the FIFO. may be you should
> dig to check how SDMA priority are configured amongs the differents DMA
> channels.
> Not something I already look at before. A quick look suggest that
> DMA_PRIO_HIGH is _NOT_ configured by the fsl_ssi.c driver (wheras the
> imx-ssi.c did)


Ah ha!  Perhaps that's it.  I will check into that.  Maybe that's the
root cause.  Thanks so much.

-Caleb


>
> Regards,
> Arnaud
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Wed, Oct 21, 2015 at 12:37 PM, Caleb Crome <caleb@crome.org> wrote:
> On Wed, Oct 21, 2015 at 12:32 AM, arnaud.mouiche@invoxia.com
> <arnaud.mouiche@invoxia.com> wrote:
>>
>>
>> Le 20/10/2015 19:43, Caleb Crome a écrit :
>>> Hi Arnaud,
>>>    My root filesystem already had that firmware in it (the kernel
>>> didn't have the kernel patch, but when I applied that patch, the
>>> generated sdma script was identical.
>>>
>>> So, unfortunately, that's not the problem with the channel slipping.
>>> Any other thoughts on why the channel would slip?  Or pointers on how
>>> to diagnose?  I have an oscilloscope & know how to use it :-)  Also, I
>>> can flip a GPIO to watch for timing of interrupts, etc (although I
>>> haven't done that yet).
>>>
>>>
>>> Thanks,
>>>    -Caleb
>>
>>
>> Hello Caleb,
>>
>> In your situation, I would:
>> - check if TUE0/1 flag never rise (Transmitter Underrun) by activating the
>> TUE0/1IE bit to generate related interrupts. It looks like already enabled
>> in 4.0 by collecting statistics with fsl_ssi_dbg_isr(). Despite there is no
>> printk message on underrun, stats can be read from
>> /sys/kernel/debug/xxxx.ssi/stats.
>
> Heh, I checked that and I couldn't get the fsl_ssi_dbg_isr to trigger
> ever, for any reason.  Somehow interrupts seem to be disabled in the
> SSI driver, and I can't figure out how to enable them.  It appears
> that the only interrupt required is the DMA interrupt, and SSI
> interrupts are not checked.    The /sys/kernel/debug/xxxx.ssi/stats
> file reads all zeros no matter what, even during playing, and even
> after the user space detects underruns.
>
>>
>> - I suspect the dma is not fast enough to fill the FIFO. may be you should
>> dig to check how SDMA priority are configured amongs the differents DMA
>> channels.
>> Not something I already look at before. A quick look suggest that
>> DMA_PRIO_HIGH is _NOT_ configured by the fsl_ssi.c driver (wheras the
>> imx-ssi.c did)
>
>
> Ah ha!  Perhaps that's it.  I will check into that.  Maybe that's the
> root cause.  Thanks so much.

So, the dma priority doesn't seem to be the issue.  It's now set in
the device tree, and strangely it's set to priority 0 (the highest)
along with the UARTS.  priority 0 is just the highest in the device
tree -- it gets remapped to priority 3 in the sdma driver.  the DT
exposes only 3 levels of DMA priority, low, medium, and high.  I
created a new level that maps to DMA priroity 7 (the highest in the
hardware), but still got the problem.

So, still something unknown causing dma to miss samples.  must be in
the dma ISR I would assume.  I guess it's time to look into that.

-Caleb
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Markus Pargmann]

[-- Attachment #1.1: Type: text/plain, Size: 3479 bytes --]

Hi,

On Mon, Oct 26, 2015 at 10:31:08AM -0700, Caleb Crome wrote:
> On Wed, Oct 21, 2015 at 12:37 PM, Caleb Crome <caleb@crome.org> wrote:
> > On Wed, Oct 21, 2015 at 12:32 AM, arnaud.mouiche@invoxia.com
> > <arnaud.mouiche@invoxia.com> wrote:
> >>
> >>
> >> Le 20/10/2015 19:43, Caleb Crome a écrit :
> >>> Hi Arnaud,
> >>>    My root filesystem already had that firmware in it (the kernel
> >>> didn't have the kernel patch, but when I applied that patch, the
> >>> generated sdma script was identical.
> >>>
> >>> So, unfortunately, that's not the problem with the channel slipping.
> >>> Any other thoughts on why the channel would slip?  Or pointers on how
> >>> to diagnose?  I have an oscilloscope & know how to use it :-)  Also, I
> >>> can flip a GPIO to watch for timing of interrupts, etc (although I
> >>> haven't done that yet).
> >>>
> >>>
> >>> Thanks,
> >>>    -Caleb
> >>
> >>
> >> Hello Caleb,
> >>
> >> In your situation, I would:
> >> - check if TUE0/1 flag never rise (Transmitter Underrun) by activating the
> >> TUE0/1IE bit to generate related interrupts. It looks like already enabled
> >> in 4.0 by collecting statistics with fsl_ssi_dbg_isr(). Despite there is no
> >> printk message on underrun, stats can be read from
> >> /sys/kernel/debug/xxxx.ssi/stats.
> >
> > Heh, I checked that and I couldn't get the fsl_ssi_dbg_isr to trigger
> > ever, for any reason.  Somehow interrupts seem to be disabled in the
> > SSI driver, and I can't figure out how to enable them.  It appears
> > that the only interrupt required is the DMA interrupt, and SSI
> > interrupts are not checked.    The /sys/kernel/debug/xxxx.ssi/stats
> > file reads all zeros no matter what, even during playing, and even
> > after the user space detects underruns.
> >
> >>
> >> - I suspect the dma is not fast enough to fill the FIFO. may be you should
> >> dig to check how SDMA priority are configured amongs the differents DMA
> >> channels.
> >> Not something I already look at before. A quick look suggest that
> >> DMA_PRIO_HIGH is _NOT_ configured by the fsl_ssi.c driver (wheras the
> >> imx-ssi.c did)
> >
> >
> > Ah ha!  Perhaps that's it.  I will check into that.  Maybe that's the
> > root cause.  Thanks so much.
> 
> So, the dma priority doesn't seem to be the issue.  It's now set in
> the device tree, and strangely it's set to priority 0 (the highest)
> along with the UARTS.  priority 0 is just the highest in the device
> tree -- it gets remapped to priority 3 in the sdma driver.  the DT
> exposes only 3 levels of DMA priority, low, medium, and high.  I
> created a new level that maps to DMA priroity 7 (the highest in the
> hardware), but still got the problem.
> 
> So, still something unknown causing dma to miss samples.  must be in
> the dma ISR I would assume.  I guess it's time to look into that.

Cc Nicolin, Fabio, Shawn

Perhaps you have an idea about this?

Regards,

Markus

> 
> -Caleb
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Fabio Estevam]

Hi Markus/Caleb,

On Tue, Oct 27, 2015 at 5:13 AM, Markus Pargmann <mpa@pengutronix.de> wrote:
> Hi,

> Cc Nicolin, Fabio, Shawn
>
> Perhaps you have an idea about this?

Could you please try it without using the external SDMA firmware?

Regards,

Fabio Estevam

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Tue, Oct 27, 2015 at 2:41 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Markus/Caleb,
>
> On Tue, Oct 27, 2015 at 5:13 AM, Markus Pargmann <mpa@pengutronix.de> wrote:
>> Hi,
>
>> Cc Nicolin, Fabio, Shawn
>>
>> Perhaps you have an idea about this?
>
> 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.

It's the exact same file that came on the root filesystem as is
generated from the freescale kernel tree, literally the same MD5SUM.

Or, should I simply remove that file?  I haven't looked into how the
kernel driver and the .bin file interact, but I do see that the
imx6qdl.dtsi references the imx/sdma/sdma-imx6q.bin file.

Thanks,
  -Caleb

>
> Regards,
>
> Fabio Estevam

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Fabio Estevam]

On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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.

Also, could you try bumping the SSI and SDMA clock rates at the maximum?

Adding Shengjiu in case he has any thoughts on getting TDM support in
the SSI driver.

Regards,

Fabio Estevam

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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
:-)


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

Thanks so much for your help.  We've got several systems where we'd
really like to use the MX6, but this issues is blocking us.

  -caleb


>
> Adding Shengjiu in case he has any thoughts on getting TDM support in
> the SSI driver.
>
> Regards,
>
> Fabio Estevam

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Fabio Estevam]

On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Fabio Estevam]

[Adding Roberto in the thread as he is also trying to get SSI TDM support/

On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

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.


>
> On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
>>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Wed, Oct 28, 2015 at 1:11 AM, Roberto Fichera <kernel@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.

FYI, I'm using a very recent 4.3 kernel from linus's repo, but 4.2
behaved the same.

-Caleb

>
>>
>> On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
>>>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/28/2015 02:59 PM, Caleb Crome wrote:
> On Wed, Oct 28, 2015 at 1:11 AM, Roberto Fichera <kernel@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?
Did you have your own DMA handling?

>
> -Caleb
>
>>> On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>>> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
>>>>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>>>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Wed, Oct 28, 2015 at 7:05 AM, Roberto Fichera <kernel@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@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, and
the FSYNC is 48kHz.  16 channels/frame, 16 bits/channel.

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.

-Caleb


>
>>
>> -Caleb
>>
>>>> On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>>>> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
>>>>>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>>>>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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@alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/28/2015 03:24 PM, Caleb Crome wrote:
> On Wed, Oct 28, 2015 at 7:05 AM, Roberto Fichera <kernel@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@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@gmail.com> wrote:
>>>>>> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
>>>>>>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>>>>>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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@alsa-project.org
>>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>>
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Wed, Oct 28, 2015 at 6:59 AM, Caleb Crome <caleb@crome.org> wrote:
> On Wed, Oct 28, 2015 at 1:11 AM, Roberto Fichera <kernel@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.
>
> FYI, I'm using a very recent 4.3 kernel from linus's repo, but 4.2
> behaved the same.
>

Now I'm recalling when I tried the patches on 4.1, everything
definitely froze.  What kernel are you using?.  I'm basically using
the 4.3-rc7

-Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/28/2015 11:09 PM, Caleb Crome wrote:
> On Wed, Oct 28, 2015 at 6:59 AM, Caleb Crome <caleb@crome.org> wrote:
>> On Wed, Oct 28, 2015 at 1:11 AM, Roberto Fichera <kernel@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.
>>
>> FYI, I'm using a very recent 4.3 kernel from linus's repo, but 4.2
>> behaved the same.
>>
> Now I'm recalling when I tried the patches on 4.1, everything
> definitely froze.  What kernel are you using?.  I'm basically using
> the 4.3-rc7

Currently the Freescale offical v3.14.28_ga_1.0.0 coming with Yocto Fido.

>
> -Caleb
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Wed, Oct 28, 2015 at 09:11:39AM +0100, Roberto Fichera wrote:
 
> 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.

I will start to help you to figure out your problem. But it seems that
you are having a different issue here with clock generation. I don't
get why you said *same issue*. For double confirm, the the "everything
stops" mentioned, does it mean that clock from SSI stops?

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/30/2015 12:04 AM, Nicolin Chen wrote:
> On Wed, Oct 28, 2015 at 09:11:39AM +0100, Roberto Fichera wrote:
>  
>> 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.
> I will start to help you to figure out your problem. But it seems that
> you are having a different issue here with clock generation. I don't
> get why you said *same issue*. For double confirm, the the "everything
> stops" mentioned, does it mean that clock from SSI stops?
>

Definitively yes! My problem is different than Caleb's one. Just to summarize the things.
I've the SSI1 connected to a SiLabs SLIC Si32178 via AUDMUX6 padmux is below:

        pinctrl_audmux_1: audmuxgrp-3 {
            fsl,pins = <
                MX6SX_PAD_SD3_DATA1__AUDMUX_AUD6_TXC    0x130b0    /* PCLK */
                MX6SX_PAD_SD3_DATA2__AUDMUX_AUD6_TXFS   0x130b0    /* FSYNC */
                MX6SX_PAD_SD3_DATA0__AUDMUX_AUD6_RXD    0x130b0    /* DTX */
                MX6SX_PAD_SD3_DATA3__AUDMUX_AUD6_TXD    0x120b0    /* DRX */
            >;
        };

The Si32178 is slave device so the SSI1 has to generate both BCLK and FSYNC. I've configured
the AUDMUX as:

int si3217x_audmux_config(unsigned int master, unsigned int slave)
{
  unsigned int ptcr, pdcr;
 
  ptcr = IMX_AUDMUX_V2_PTCR_SYN |
         IMX_AUDMUX_V2_PTCR_TFSDIR |
         IMX_AUDMUX_V2_PTCR_TFSEL(master) |
         IMX_AUDMUX_V2_PTCR_TCLKDIR |
         IMX_AUDMUX_V2_PTCR_TCSEL(master);
  pdcr = IMX_AUDMUX_V2_PDCR_RXDSEL(master);
  si3217x_audmux_v2_configure_port(slave, ptcr, pdcr); /* configure internal port */
 
  ptcr = IMX_AUDMUX_V2_PTCR_SYN;
  pdcr = IMX_AUDMUX_V2_PDCR_RXDSEL(slave);
  si3217x_audmux_v2_configure_port(master, ptcr, pdcr); /* configure external port */
 
  return 0;
}

BCLK is 2048KHz, FSYNC@8KHz, frame is 32 slots at 8bits each. Looking at TXC and TXFS
with a logical analyzer everything looks ok.

The SSI is setup at beginning as:

        unsigned long flags;
        struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
        u32 srcr;
        u8 wm;

        clk_prepare_enable(ssi_private->clk);

        /*
         * Section 16.5 of the MPC8610 reference manual says that the
         * SSI needs to be disabled before updating the registers we set
         * here.
         */
        write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);

        /*
         * Program the SSI into I2S Master Network Synchronous mode.
         * Also enable the transmit and receive FIFO.
         */
        write_ssi_mask(&ssi->scr,
            CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
            CCSR_SSI_SCR_I2S_MODE_NORMAL
            | CCSR_SSI_SCR_SYN | CCSR_SSI_SCR_NET
            | CCSR_SSI_SCR_SYS_CLK_EN);

        /*
         * TX falling edge PCLK is mandatory because the RX SLIC side works in this way
         */
        writel( CCSR_SSI_STCR_TXBIT0 /* LSB Aligned */
              | CCSR_SSI_STCR_TFEN0  /* Enable TX FIFO0 */
              | CCSR_SSI_STCR_TSCKP  /* Transmit Clock Polarity - Data Clocked out on falling edge */
              | CCSR_SSI_STCR_TFDIR  /* Transmit Frame Direction Internal - generated internally */
              | CCSR_SSI_STCR_TXDIR, /* Transmit Clock Direction Internal - generated internally */
            &ssi->stcr);

    srcr = readl(&ssi->srcr);

        /*
         * clear out RFDIR and RXDIR because the clock is synchronous
         */
    srcr &= ~(CCSR_SSI_SRCR_RFDIR | CCSR_SSI_SRCR_RXDIR);

        srcr |= CCSR_SSI_SRCR_RXBIT0 /* LSB Aligned */
             |  CCSR_SSI_SRCR_RFEN0  /* Enable RX FIFO0 */
             |  CCSR_SSI_SRCR_RSCKP  /* Receive Clock Polarity - Data latched on rising edge */
            ;

    writel(srcr, &ssi->srcr);

        /* do not service the isr yet */
        writel(0, &ssi->sier);

        /*
         * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
         * don't use FIFO 1.  We program the transmit water to signal a
         * DMA transfer if there are only two (or fewer) elements left
         * in the FIFO. 
         */

       /*
        * tdm_real_slots is 2 because mask all except first 2 slots
        * our buffer is 2 slots * 8 bytes each, so set watermarks to a multiple of it
        * 8 words in our case
        */

        wm = ssi_private->tdm_real_slots * 4; //ssi_private->use_dma ? ssi_private->fifo_depth - 2 :
ssi_private->fifo_depth;

        writel(CCSR_SSI_SFCSR_TFWM0(wm) |
               CCSR_SSI_SFCSR_RFWM0(wm) |
               CCSR_SSI_SFCSR_TFWM1(wm) |
               CCSR_SSI_SFCSR_RFWM1(wm),
               &ssi->sfcsr);

        /* enable one FIFO */
        write_ssi_mask(&ssi->srcr, CCSR_SSI_SRCR_RFEN1, 0);
        write_ssi_mask(&ssi->stcr, CCSR_SSI_STCR_TFEN1, 0);

        /* disable SSI two-channel mode operation */
        write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TCH_EN, 0);

        /*
         * We keep the SSI disabled because if we enable it, then the
         * DMA controller will start.  It's not supposed to start until
         * the SCR.TE (or SCR.RE) bit is set, but it does anyway.  The
         * DMA controller will transfer one "BWC" of data (i.e. the
         * amount of data that the MR.BWC bits are set to).  The reason
         * this is bad is because at this point, the PCM driver has not
         * finished initializing the DMA controller.
         */

        /* Set default slot number -- 32 in our case */
        write_ssi_mask(&ssi->stccr, CCSR_SSI_SxCCR_DC_MASK,
            CCSR_SSI_SxCCR_DC(ssi_private->tdm_slots));
        write_ssi_mask(&ssi->srccr, CCSR_SSI_SxCCR_DC_MASK,
            CCSR_SSI_SxCCR_DC(ssi_private->tdm_slots));

        /* Set default word length -- 8 bits */
        write_ssi_mask(&ssi->stccr, CCSR_SSI_SxCCR_WL_MASK,
            CCSR_SSI_SxCCR_WL(ssi_private->tdm_word_size));
        write_ssi_mask(&ssi->srccr, CCSR_SSI_SxCCR_WL_MASK,
            CCSR_SSI_SxCCR_WL(ssi_private->tdm_word_size));

        /* enable the SSI */
        write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, CCSR_SSI_SCR_SSIEN);

        /*
         * we are interested only at first 2 slots
         */
        writel(~ssi_private->tdm_slots_enabled, &ssi->stmsk);
        writel(~ssi_private->tdm_slots_enabled, &ssi->srmsk);

       return 0;
}

SSI clock calculated and then enabled. Both TX and RX DMA channel are requested in the probe() function as below.
and the corresponding TX and RX SDMA event in DTS are using the default from imx6sx.dtsi:

            slave_config.direction = DMA_MEM_TO_DEV;
            slave_config.dst_addr = ssi_private->ssi_phys + offsetof(struct ccsr_ssi, stx0);
            slave_config.dst_addr_width = width;
            slave_config.dst_maxburst = ssi_private->tdm_real_slots * 4;
            ret = dmaengine_slave_config(ssi_private->tx_chan, &slave_config);

            ssi_private->rx_chan = dma_request_slave_channel_reason(&pdev->dev, "rx");
            slave_config.direction = DMA_DEV_TO_MEM;
            slave_config.src_addr = ssi_private->ssi_phys + offsetof(struct ccsr_ssi, srx0);
            slave_config.src_addr_width = width;
            slave_config.src_maxburst = ssi_private->tdm_real_slots * 4;
            ret = dmaengine_slave_config(ssi_private->rx_chan, &slave_config);

and setup before RDMAE and TDMAE bits, like this:

        ssi_private->tx_buf = dma_alloc_coherent(NULL, buffer_len,
                                        &ssi_private->tx_dmaaddr, GFP_KERNEL);
        desc = dmaengine_prep_dma_cyclic(ssi_private->tx_chan, ssi_private->tx_dmaaddr,
                buffer_len, ssi_private->tdm_real_slots*4,
                DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);

        desc->callback = dma_tx_callback;
        desc->callback_param = ssi_private;

        printk("TX: prepare for the DMA.\n");
        dmaengine_submit(desc);
        dma_async_issue_pending(ssi_private->tx_chan);

        ssi_private->rx_buf = dma_alloc_coherent(NULL, buffer_len,
                                        &ssi_private->rx_dmaaddr, GFP_KERNEL);

        desc = dmaengine_prep_dma_cyclic(ssi_private->rx_chan, ssi_private->rx_dmaaddr,
                buffer_len, ssi_private->tdm_real_slots*4,
                DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);

        desc->callback = dma_rx_callback;
        desc->callback_param = ssi_private;

        printk("RX: prepare for the DMA.\n");
        dmaengine_submit(desc);
        dma_async_issue_pending(ssi_private->rx_chan);

Finally, the SSI's TX and RX parts are now enabled

    scr = readl(&ssi->scr);

    scr |= CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE;   /* enable both TX and RX SSI sections */

    writel(scr, &ssi->scr);

Finally the SIER si programmed as:

   struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
    u32 sier = CCSR_SSI_SIER_RFF0_EN | CCSR_SSI_SIER_TFE0_EN;

    /*
     * if DMA is enabled than allow SSI request for DMA transfers
     * otherwise normal interrupt requests
     */

    if (ssi_private->use_dma>0)
    {
      sier |= CCSR_SSI_SIER_RDMAE | CCSR_SSI_SIER_TDMAE;
    }
   
    if (ssi_private->use_dma>1 || !ssi_private->use_dma)
    {
      sier |= CCSR_SSI_SIER_RIE | CCSR_SSI_SIER_TIE;
    }

    sier &= ~(CCSR_SSI_SIER_TDE1_EN | CCSR_SSI_SIER_TFE1_EN |
              CCSR_SSI_SIER_TFE0_EN | CCSR_SSI_SIER_TDE0_EN);

    writel(sier, &ssi->sier);

At this time I should see the DMA callbacks called every burst_size words. This behaviour
doesn't really happen as I wish because I can see from a proc file that such callbacks
are called from 1 to 20000 times and then anymore. This is also confirmed by the fact that
the interrupt 34 (sdma) doesn't increase anymore but matches my internal counters collected
within my callbacks. Here is what I can inspect from the data I have collected:

root@voneus-domus-imx6sx:~# cat /proc/domus_ssi_stats
SSI TDM Info:
        PLL clk=66000000
        SSI baudclk=49152000
        ssi_phy=0x02028000
        irq=78
        fifo_depth=15 <---- this is what is read from DTS but not as watermark
        tdm_frame_rate=8000
        tdm_slots=32 (real 2)
        tdm_word_size=8
        tdm_slots_enabled=00000000000000000000000000000011
        clk_frequency=2048000
        clock_running=yes
        DMA=yes
        Dual FIFO=no
        RX DMA frame count=17121
        RX DMA addr=0x9c692000
        RX DMA buffer len=16
        TX DMA frame count=17121
        TX DMA addr=0x9c4aa000
        TX DMA buffer len=16

SSI Registers:
        ssi_scr=0x0000009f
        ssi_sier=0x00500004
        ssi_stcr=0x000002e8
        ssi_srcr=0x00000288
        ssi_stccr=0x00007f0b
        ssi_srccr=0x00007f0b
        ssi_sfcsr=0x0088f088
        ssi_stmsk=0xfffffffc
        ssi_srmsk=0xfffffffc

Cheers,
Roberto Fichera.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Fri, Oct 30, 2015 at 12:42:53PM +0100, Roberto Fichera wrote:


>         /*
>          * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
>          * don't use FIFO 1.  We program the transmit water to signal a
>          * DMA transfer if there are only two (or fewer) elements left
>          * in the FIFO. 
>          */

> SSI clock calculated and then enabled. Both TX and RX DMA channel are requested in the probe() function as below.
> and the corresponding TX and RX SDMA event in DTS are using the default from imx6sx.dtsi:

Since you are using single FIFO configuration, which SDMA script
are you using? This should reflects in the Device Tree. As far as
I learned, FSL 3.14 is using number 22 for SSIs which is the one
for Dual FIFO Mode.

> At this time I should see the DMA callbacks called every burst_size words. This behaviour
> doesn't really happen as I wish because I can see from a proc file that such callbacks
> are called from 1 to 20000 times and then anymore. This is also confirmed by the fact that
> the interrupt 34 (sdma) doesn't increase anymore but matches my internal counters collected
> within my callbacks. Here is what I can inspect from the data I have collected:

Just for clarification, the behaviour doesn't happen as you wish
is just the DMA stopped? I remember you also mentioned bit clock
has stopped as you can check the clock status from the Codec chip.

> SSI Registers:
>         ssi_sfcsr=0x0088f088

At this point you have data in RxFIFO and get empty in TxFIFO, so
the DMA requests from both side should be issued. If the DMA stops
as you described, you must check those two channels from the SDMA
side by dumping SDMAARM_STOP_STAT, SDMAARM_HSTART, SDMAARM_EVTOVR,
SDMAARM_EVTPEND, SDMAARM_EVTERR, SDMAARM_DSPOVR and SDMAARM_HOSTOVR
registers.

Overall, I don't see an obvious defect from you SSI side, but you
may also try to toggle TDMAE and RDMAE at the point that callback
stops -- re-raise the DMA requests by disabling and enabling TDMAE
and RDMAE again and see if it works. I think either something did
intervene register controls of SDMA or SSI, or SDMA have missed the
request signals from SSI.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Tue, Oct 27, 2015 at 9:45 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome <caleb@crome.org> wrote:
>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam <festevam@gmail.com> wrote:
>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome <caleb@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.

I gave it a try.  No noticeable  change in behavior.

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

I don't know what to use as a parameter to clk_set_rate().  The 2
clocks that I see in the SDMA configuration are clk_ipg, and clk_ahb.
The IMX6SDLRM syas, "configurable clock options for the SDMA core and
the ARM platform DMA units.  1:2 ratio with maximum of SDMA core
running at ARM platform peripheral bus speed and DMS running at max
DMA frequency.  1:1 ratio when both SDMA core and ARM platform DMA
clocks are set to the ARM platform peripheral bus speed"

But, I have a hard time reconsiling that statement with the code in
sdma_init, which references only the ipg and ahb clocks.  I put in a
printk, and found the clk_ipg and clk_ahb to be 132 MHz.

The IMX6SDLRM.pdf, page 4717 says: "...but the SDMA core is physically
limited to a maximum 104 MHz frequency...".

So, I just don't know what clock to set to 104 MHz, or if the 104MHz
really is the right limit.  Any ideas?


This made me think that possibly the problem is with cpufreq
dynamically scaling the core frequency. So I tried:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

To ensure that the clocks don't dynamically switch on me, but I still
get channel slips.  Unfortunately,  it's hard to get statistical
measures with my eyeballs (watching a scope with TDM decode).  It
might be a little better, but still fails.

Thanks,
  -Caleb


>
> Regards,
>
> Fabio Estevam

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Tue, Oct 27, 2015 at 08:13:44AM +0100, Markus Pargmann wrote:

> > So, the dma priority doesn't seem to be the issue.  It's now set in
> > the device tree, and strangely it's set to priority 0 (the highest)
> > along with the UARTS.  priority 0 is just the highest in the device
> > tree -- it gets remapped to priority 3 in the sdma driver.  the DT
> > exposes only 3 levels of DMA priority, low, medium, and high.  I
> > created a new level that maps to DMA priroity 7 (the highest in the
> > hardware), but still got the problem.
> > 
> > So, still something unknown causing dma to miss samples.  must be in
> > the dma ISR I would assume.  I guess it's time to look into that.

> Cc Nicolin, Fabio, Shawn
> 
> Perhaps you have an idea about this?

Off the top of my head:

1) Enable TUE0, TUE1, ROE0, ROE1 to see if there is any IRQ trigged.

2) Set the watermarks for both TX and RX to 8 while using burst sizes
   of 6. It'd be nicer to provisionally set these numbers using hard
   code than your current change depending on fifo_depth as it might
   be an odd value.

3) Try to enlarge the ALSA period size in the asound.conf or passing
   parameters when you do the playback/capture so that the number of
   interrupts from SDMA may reduce.

You may also see if the reproducibility is somehow reduced or not.

Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/27/2015 09:11 PM, Nicolin Chen wrote:
> On Tue, Oct 27, 2015 at 08:13:44AM +0100, Markus Pargmann wrote:
>
>>> So, the dma priority doesn't seem to be the issue.  It's now set in
>>> the device tree, and strangely it's set to priority 0 (the highest)
>>> along with the UARTS.  priority 0 is just the highest in the device
>>> tree -- it gets remapped to priority 3 in the sdma driver.  the DT
>>> exposes only 3 levels of DMA priority, low, medium, and high.  I
>>> created a new level that maps to DMA priroity 7 (the highest in the
>>> hardware), but still got the problem.
>>>
>>> So, still something unknown causing dma to miss samples.  must be in
>>> the dma ISR I would assume.  I guess it's time to look into that.
>> Cc Nicolin, Fabio, Shawn
>>
>> Perhaps you have an idea about this?
> Off the top of my head:
>
> 1) Enable TUE0, TUE1, ROE0, ROE1 to see if there is any IRQ trigged.

I'm my case I was never able to see an interrupt triggered when setting both RDMAE and TDMAE
bits in the SIER register.

> 2) Set the watermarks for both TX and RX to 8 while using burst sizes
>    of 6. It'd be nicer to provisionally set these numbers using hard
>    code than your current change depending on fifo_depth as it might
>    be an odd value.
>
> 3) Try to enlarge the ALSA period size in the asound.conf or passing
>    parameters when you do the playback/capture so that the number of
>    interrupts from SDMA may reduce.
>
> You may also see if the reproducibility is somehow reduced or not.
>
> Nicolin
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Wed, Oct 28, 2015 at 09:23:01AM +0100, Roberto Fichera wrote:
> On 10/27/2015 09:11 PM, Nicolin Chen wrote:
> > On Tue, Oct 27, 2015 at 08:13:44AM +0100, Markus Pargmann wrote:
> >
> >>> So, the dma priority doesn't seem to be the issue.  It's now set in
> >>> the device tree, and strangely it's set to priority 0 (the highest)
> >>> along with the UARTS.  priority 0 is just the highest in the device
> >>> tree -- it gets remapped to priority 3 in the sdma driver.  the DT
> >>> exposes only 3 levels of DMA priority, low, medium, and high.  I
> >>> created a new level that maps to DMA priroity 7 (the highest in the
> >>> hardware), but still got the problem.
> >>>
> >>> So, still something unknown causing dma to miss samples.  must be in
> >>> the dma ISR I would assume.  I guess it's time to look into that.
> >> Cc Nicolin, Fabio, Shawn
> >>
> >> Perhaps you have an idea about this?
> > Off the top of my head:
> >
> > 1) Enable TUE0, TUE1, ROE0, ROE1 to see if there is any IRQ trigged.
> 
> I'm my case I was never able to see an interrupt triggered when setting both RDMAE and TDMAE
> bits in the SIER register.

Your problem may not involve with hardware FIFO underrun at all
so it's quite normal for you to have no IRQ in my opinion.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Tue, Oct 27, 2015 at 1:11 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 08:13:44AM +0100, Markus Pargmann wrote:
>
>> > So, the dma priority doesn't seem to be the issue.  It's now set in
>> > the device tree, and strangely it's set to priority 0 (the highest)
>> > along with the UARTS.  priority 0 is just the highest in the device
>> > tree -- it gets remapped to priority 3 in the sdma driver.  the DT
>> > exposes only 3 levels of DMA priority, low, medium, and high.  I
>> > created a new level that maps to DMA priroity 7 (the highest in the
>> > hardware), but still got the problem.
>> >
>> > So, still something unknown causing dma to miss samples.  must be in
>> > the dma ISR I would assume.  I guess it's time to look into that.
>
>> Cc Nicolin, Fabio, Shawn
>>
>> Perhaps you have an idea about this?
>
> Off the top of my head:
>
> 1) Enable TUE0, TUE1, ROE0, ROE1 to see if there is any IRQ trigged.
Ah, I found that SIER TIE & RIE were not enabled. I enabled them (and
just submitted a patch to the list, which will need to be fixed).

With my 2 patches, the

/sys/kernel/debug/2028000.ssi/stats

file now shows the proper interrupts.

>
> 2) Set the watermarks for both TX and RX to 8 while using burst sizes
>    of 6. It'd be nicer to provisionally set these numbers using hard
>    code than your current change depending on fifo_depth as it might
>    be an odd value.

Ah, this is fascinating you say this.  fifo_depth is definitely odd,
it's 15 as set in imx6qdl.dtsi:
fsl,fifo-depth = <15>;
But the DMA maxburst is made even later in the code...

Setting the watermark to 8 and maxburst to 8 dramatically reduces the
channel slip rate, in fact, i didn't see a slip for more than 30
minutes of playing.  That's a new record for sure.  But, eventually,
there was an underrun, and the channels slipped.

Setting watermark to 8 and maxburst to 6 still had some slips,
seemingly more than 8 & 8.

I feel like a monkey randomly typing at my keyboard though.  I don't
know why maxburst=8 worked better.  I get the
feeling that I was just lucky.

There does seem to be a correlation between user space reported
underruns and this channel slip, although they definitely are not 1:1
ratio:  underruns happen without slips and slips happen without
underruns.  The latter is very disturbing because user space has no
idea something is wrong.

My test is simply to run aplay with a 1000 second, 16 channel sound
file, and watch
the data decoded on my scope.   The sound file has the channel number
encoded as the most significant nibble of each word, and a do a
conditional trigger to watch to make sure the most significant nibble
after the fram sync is '0'.  i.e. trigger if there is a rising edge on
data within 300ns of the rising edge of fsync.

Here's the patch that has worked the best so far.

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 73778c2..b834f77 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -943,7 +943,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
         * size.
         */
        if (ssi_private->use_dma)
-               wm = ssi_private->fifo_depth - 2;
+               wm = 8;
        else
                wm = ssi_private->fifo_depth;

@@ -1260,8 +1260,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev,
         * We have burstsize be "fifo_depth - 2" to match the SSI
         * watermark setting in fsl_ssi_startup().
         */
-       ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
-       ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
+       ssi_private->dma_params_tx.maxburst = 8;
+       ssi_private->dma_params_rx.maxburst = 8;
        ssi_private->dma_params_tx.addr = ssi_private->ssi_phys + CCSR_SSI_STX0;
        ssi_private->dma_params_rx.addr = ssi_private->ssi_phys + CCSR_SSI_SRX0;


>
> 3) Try to enlarge the ALSA period size in the asound.conf or passing
>    parameters when you do the playback/capture so that the number of
>    interrupts from SDMA may reduce.
I checked this earlier and it seemed to help, but didn't solve the
issue.  I will check it again with my latest updates.

-Caleb



>
> You may also see if the reproducibility is somehow reduced or not.
>
> Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Wed, Oct 28, 2015 at 03:06:40PM -0700, Caleb Crome wrote:

> > 2) Set the watermarks for both TX and RX to 8 while using burst sizes
> >    of 6. It'd be nicer to provisionally set these numbers using hard
> >    code than your current change depending on fifo_depth as it might
> >    be an odd value.

> Ah, this is fascinating you say this.  fifo_depth is definitely odd,
> it's 15 as set in imx6qdl.dtsi:

> fsl,fifo-depth = <15>;
> But the DMA maxburst is made even later in the code...

And odd number for burst size may course a similar problem like
channel swapping in two-channel cases because the number of data
FIFO is 2 -- an even number. But it seems not to be related to
your problem here.

> Setting the watermark to 8 and maxburst to 8 dramatically reduces the
> channel slip rate, in fact, i didn't see a slip for more than 30
> minutes of playing.  That's a new record for sure.  But, eventually,
> there was an underrun, and the channels slipped.
> 
> Setting watermark to 8 and maxburst to 6 still had some slips,
> seemingly more than 8 & 8.
> 
> I feel like a monkey randomly typing at my keyboard though.  I don't
> know why maxburst=8 worked better.  I get the
> feeling that I was just lucky.

That's actually another possible root cause -- performance issue.
burst=8 will have less bus transaction number than the case when
burst=6. As you have quite a lot channels comparing to normal 2
channels, you need to feed the FIFO more frequently. If SDMA does
not feed the data before the input FIFO gets underrun, a channel
swapping might happen: in your case, channel slip.

> There does seem to be a correlation between user space reported
> underruns and this channel slip, although they definitely are not 1:1

Reported by user space? Are you saying that's an ALSA underrun in
the user space, not a hardware underrun reported by the IRQ in the
driver? They are quite different. ALSA underrun comes from the DMA
buffer gets underrun while the other one results from FIFO feeding
efficiency. For ALSA underrun, enlarging the playback period size
and period number will ease the problem:

period number = buffer size / period size;

An ALSA underrun may not be companied by a hardware underrun but
they may co-exist.

> ratio:  underruns happen without slips and slips happen without
> underruns.  The latter is very disturbing because user space has no
> idea something is wrong.

> @@ -1260,8 +1260,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev,
>          * We have burstsize be "fifo_depth - 2" to match the SSI
>          * watermark setting in fsl_ssi_startup().
>          */
> -       ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
> -       ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
> +       ssi_private->dma_params_tx.maxburst = 8;
> +       ssi_private->dma_params_rx.maxburst = 8;

I am actually thinking about setting a watermark to a larger number.
I forgot how the SDMA script handles this number. But if this burst
size means the overall data count per transaction, it might indicate
that each FIFO only gets half of the burst size due to dual FIFOs.

Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
left, the largest safe burst size could be 14 (7 * 2) actually.

Yes. That's kind of fine tunning the parameters. And for your case,
you may try a larger number as the SSI is simultaneously consuming
a large amount of data even though it sounds risky. But it's worth
trying since you are using SSI which only has tight FIFOs not like
ESAI has 128 depth.

Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Wed, Oct 28, 2015 at 03:06:40PM -0700, Caleb Crome wrote:
>
>> > 2) Set the watermarks for both TX and RX to 8 while using burst sizes
>> >    of 6. It'd be nicer to provisionally set these numbers using hard
>> >    code than your current change depending on fifo_depth as it might
>> >    be an odd value.
>
>> Ah, this is fascinating you say this.  fifo_depth is definitely odd,
>> it's 15 as set in imx6qdl.dtsi:
>
>> fsl,fifo-depth = <15>;
>> But the DMA maxburst is made even later in the code...
>
> And odd number for burst size may course a similar problem like
> channel swapping in two-channel cases because the number of data
> FIFO is 2 -- an even number. But it seems not to be related to
> your problem here.
>
>> Setting the watermark to 8 and maxburst to 8 dramatically reduces the
>> channel slip rate, in fact, i didn't see a slip for more than 30
>> minutes of playing.  That's a new record for sure.  But, eventually,
>> there was an underrun, and the channels slipped.
>>
>> Setting watermark to 8 and maxburst to 6 still had some slips,
>> seemingly more than 8 & 8.
>>
>> I feel like a monkey randomly typing at my keyboard though.  I don't
>> know why maxburst=8 worked better.  I get the
>> feeling that I was just lucky.
>
> That's actually another possible root cause -- performance issue.
> burst=8 will have less bus transaction number than the case when
> burst=6. As you have quite a lot channels comparing to normal 2
> channels, you need to feed the FIFO more frequently. If SDMA does
> not feed the data before the input FIFO gets underrun, a channel
> swapping might happen: in your case, channel slip.
>
>> There does seem to be a correlation between user space reported
>> underruns and this channel slip, although they definitely are not 1:1
>
> Reported by user space? Are you saying that's an ALSA underrun in
> the user space, not a hardware underrun reported by the IRQ in the
> driver? They are quite different. ALSA underrun comes from the DMA
> buffer gets underrun while the other one results from FIFO feeding
> efficiency. For ALSA underrun, enlarging the playback period size
> and period number will ease the problem:
>
> period number = buffer size / period size;
>
> An ALSA underrun may not be companied by a hardware underrun but
> they may co-exist.

Sometimes they happen at the same time.  So, I run aplay, and all is
fine.  Then the user space app will underrun, and then I look at the
scope, and the channels have slipped.  So somehow the start/restart
after the underrun is not always perfect I guess.

Is there any mechanism for the DMA fifo underruns to be reported back
to user space?  There certainly should be, because the consequences
are catastrophic, yet the user space app goes on as if everything is
just great.  Much, much worse than the underrun that is reported (i.e.
a skip in audio is bad but sometimes tolerable.  A channel slip is
permanent and absolutely intolerable).

>
>> ratio:  underruns happen without slips and slips happen without
>> underruns.  The latter is very disturbing because user space has no
>> idea something is wrong.
>
>> @@ -1260,8 +1260,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev,
>>          * We have burstsize be "fifo_depth - 2" to match the SSI
>>          * watermark setting in fsl_ssi_startup().
>>          */
>> -       ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
>> -       ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
>> +       ssi_private->dma_params_tx.maxburst = 8;
>> +       ssi_private->dma_params_rx.maxburst = 8;
>
> I am actually thinking about setting a watermark to a larger number.
> I forgot how the SDMA script handles this number. But if this burst
> size means the overall data count per transaction, it might indicate
> that each FIFO only gets half of the burst size due to dual FIFOs.
>
> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
> left, the largest safe burst size could be 14 (7 * 2) actually.

Oh, does this depend on the data size?  I'm using 16-bit data, so I
guess the bursts are measured in 2 byte units?  Does this mean that
the burst size should be dynamically adjusted depending on word size
(I guess done in hw_params)?

>
> Yes. That's kind of fine tunning the parameters. And for your case,
> you may try a larger number as the SSI is simultaneously consuming
> a large amount of data even though it sounds risky. But it's worth
> trying since you are using SSI which only has tight FIFOs not like
> ESAI has 128 depth.
>
> Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote:
> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>
>> I am actually thinking about setting a watermark to a larger number.
>> I forgot how the SDMA script handles this number. But if this burst
>> size means the overall data count per transaction, it might indicate
>> that each FIFO only gets half of the burst size due to dual FIFOs.
>>
>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
>> left, the largest safe burst size could be 14 (7 * 2) actually.
>
> Oh, does this depend on the data size?  I'm using 16-bit data, so I
> guess the bursts are measured in 2 byte units?  Does this mean that
> the burst size should be dynamically adjusted depending on word size
> (I guess done in hw_params)?
>
>> Nicolin

Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
maxburst=8 works okay, but still not perfect.

I just discovered some new information:

With wm=8 and maxburst=8 (which is my best setting so far), I just
captured a problem at the very start of playing a file, and restarted
enough times to capture it starting wrong:

Instead of the playback starting with

(hex numbers:  my ramp file has first nibble as channel, second nibble as frame)

frame 0:  00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0
frame 1:  01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1

It started with:

frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1

So, the transfer started wrong right out of the gate -- with an extra
sample inserted at the beginning. Again, my setup is:
1) use scope to capture the TDM bus.  Trigger on first data change
2) aplay myramp.wav
3) If okay, ctrl-c and goto 2.
4) The capture below shows everything off by 1 sample.

The capture is here:
https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc

This test definitely reveals that there is a startup issue.  Now for
the $64,000 question: what to do with this knowledge?  I'm quite
unfamiliar with how the DMA works at all.

I'll start poking around the DMA I guess.

Thanks,
  -Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/29/2015 03:55 PM, Caleb Crome wrote:
> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote:
>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>> I am actually thinking about setting a watermark to a larger number.
>>> I forgot how the SDMA script handles this number. But if this burst
>>> size means the overall data count per transaction, it might indicate
>>> that each FIFO only gets half of the burst size due to dual FIFOs.
>>>
>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
>>> left, the largest safe burst size could be 14 (7 * 2) actually.
>> Oh, does this depend on the data size?  I'm using 16-bit data, so I
>> guess the bursts are measured in 2 byte units?  Does this mean that
>> the burst size should be dynamically adjusted depending on word size
>> (I guess done in hw_params)?
>>
>>> Nicolin
> Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
> maxburst=8 works okay, but still not perfect.
>
> I just discovered some new information:
>
> With wm=8 and maxburst=8 (which is my best setting so far), I just
> captured a problem at the very start of playing a file, and restarted
> enough times to capture it starting wrong:
>
> Instead of the playback starting with
>
> (hex numbers:  my ramp file has first nibble as channel, second nibble as frame)
>
> frame 0:  00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0
> frame 1:  01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1
>
> It started with:
>
> frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
> frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1
>
> So, the transfer started wrong right out of the gate -- with an extra
> sample inserted at the beginning. Again, my setup is:
> 1) use scope to capture the TDM bus.  Trigger on first data change
> 2) aplay myramp.wav
> 3) If okay, ctrl-c and goto 2.
> 4) The capture below shows everything off by 1 sample.
>
> The capture is here:
> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc
>
> This test definitely reveals that there is a startup issue.  Now for
> the $64,000 question: what to do with this knowledge?  I'm quite
> unfamiliar with how the DMA works at all.

I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI
clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure
that everything has been setup (DMA and callback). Note that I'm not using alsa because,
my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app.

Back to the DMA question, in your case shouldn't be really a problem since all DMA
stuff is handled by the linux audio framework.

Regarding my SSI problem, I was able to keep the DMA working for few second once before
it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX
I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA
has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with
and without SSI DMA support, but this end with a full system freeze. The ISR was never changed
in my fsl_ssi.c.

                ssi1: ssi@02028000 {
                    compatible = "fsl,imx6sx-ssi", "fsl,imx21-ssi";
                    reg = <0x02028000 0x4000>;
                    interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
                    clocks = <&clks IMX6SX_CLK_SSI1_IPG>,
                         <&clks IMX6SX_CLK_SSI1>,
--->>>                         <&clks IMX6SX_CLK_SPBA>,
                         <&clks IMX6SX_CLK_SDMA>;
                    clock-names = "ipg", "baud", "dma", "ahb";
                    dmas = <&sdma 37 1 0>, <&sdma 38 1 0>;
                    dma-names = "rx", "tx";


Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference
manual to

37 -> SSI1 Receive 0 DMA request
38 -> SSI1 Transmit 0 DMA request

along that there are also

35 -> SSI1 Receive 1 DMA request
36 -> SSI1 Transmit 1 DMA request

I don't know actually how the two events types will behaves from the SDMA point of view.

I'm also considering to make plain new audio driver to at least try to use something which
is supposed to work fine with SSI.

>
> I'll start poking around the DMA I guess.

I guess it's a SSI startup problem.

>
> Thanks,
>   -Caleb
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
> On 10/29/2015 03:55 PM, Caleb Crome wrote:
>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote:
>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>>> I am actually thinking about setting a watermark to a larger number.
>>>> I forgot how the SDMA script handles this number. But if this burst
>>>> size means the overall data count per transaction, it might indicate
>>>> that each FIFO only gets half of the burst size due to dual FIFOs.
>>>>
>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
>>>> left, the largest safe burst size could be 14 (7 * 2) actually.
>>> Oh, does this depend on the data size?  I'm using 16-bit data, so I
>>> guess the bursts are measured in 2 byte units?  Does this mean that
>>> the burst size should be dynamically adjusted depending on word size
>>> (I guess done in hw_params)?
>>>
>>>> Nicolin
>> Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
>> maxburst=8 works okay, but still not perfect.
>>
>> I just discovered some new information:
>>
>> With wm=8 and maxburst=8 (which is my best setting so far), I just
>> captured a problem at the very start of playing a file, and restarted
>> enough times to capture it starting wrong:
>>
>> Instead of the playback starting with
>>
>> (hex numbers:  my ramp file has first nibble as channel, second nibble as frame)
>>
>> frame 0:  00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0
>> frame 1:  01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1
>>
>> It started with:
>>
>> frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
>> frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1
>>
>> So, the transfer started wrong right out of the gate -- with an extra
>> sample inserted at the beginning. Again, my setup is:
>> 1) use scope to capture the TDM bus.  Trigger on first data change
>> 2) aplay myramp.wav
>> 3) If okay, ctrl-c and goto 2.
>> 4) The capture below shows everything off by 1 sample.
>>
>> The capture is here:
>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc
>>
>> This test definitely reveals that there is a startup issue.  Now for
>> the $64,000 question: what to do with this knowledge?  I'm quite
>> unfamiliar with how the DMA works at all.
>
> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI
> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure
> that everything has been setup (DMA and callback). Note that I'm not using alsa because,
> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app.
>
> Back to the DMA question, in your case shouldn't be really a problem since all DMA
> stuff is handled by the linux audio framework.
>
> Regarding my SSI problem, I was able to keep the DMA working for few second once before
> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX
> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA
> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with
> and without SSI DMA support, but this end with a full system freeze.

I got this system freeze too when enabling RIE and TIE because the
interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset.
(Check ref manual 61.9.5).   which I suspect was a livelock kind of
situation where the ISR is just called infinitely often.  After
disabling those, then the system worked okay.  Check out the previous
patch I sent on the issue yesterday or the day before.
>
> Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference
> manual to
>
> 37 -> SSI1 Receive 0 DMA request
> 38 -> SSI1 Transmit 0 DMA request
>
> along that there are also
>
> 35 -> SSI1 Receive 1 DMA request
> 36 -> SSI1 Transmit 1 DMA request
>
> I don't know actually how the two events types will behaves from the SDMA point of view.

The 35 and 36 are for Dual fifo mode only, and no current system (with
fsl_ssi.c anyway) uses dual fifo mode.  How do I know?  Because the
it's definitely broken in the fsl_ssi.c.  I was just about to report
that bug.

hint:  fsl_ssi.c:  if (ssi_private->use_dma && !ret && dmas[3] ==
IMX_DMATYPE_SSI_DUAL) {
should read  if (ssi_private->use_dma && !ret && dmas[4] ==
IMX_DMATYPE_SSI_DUAL) {

>
> I'm also considering to make plain new audio driver to at least try to use something which
> is supposed to work fine with SSI.

Yeah, maybe that's the easiest way to go just to get operational.
Start with just the bare minimum ssi driver so you know all the
registers are locked into place the way you like.

-caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/29/2015 04:54 PM, Caleb Crome wrote:
> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>> On 10/29/2015 03:55 PM, Caleb Crome wrote:
>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote:
>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>>>> I am actually thinking about setting a watermark to a larger number.
>>>>> I forgot how the SDMA script handles this number. But if this burst
>>>>> size means the overall data count per transaction, it might indicate
>>>>> that each FIFO only gets half of the burst size due to dual FIFOs.
>>>>>
>>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
>>>>> left, the largest safe burst size could be 14 (7 * 2) actually.
>>>> Oh, does this depend on the data size?  I'm using 16-bit data, so I
>>>> guess the bursts are measured in 2 byte units?  Does this mean that
>>>> the burst size should be dynamically adjusted depending on word size
>>>> (I guess done in hw_params)?
>>>>
>>>>> Nicolin
>>> Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
>>> maxburst=8 works okay, but still not perfect.
>>>
>>> I just discovered some new information:
>>>
>>> With wm=8 and maxburst=8 (which is my best setting so far), I just
>>> captured a problem at the very start of playing a file, and restarted
>>> enough times to capture it starting wrong:
>>>
>>> Instead of the playback starting with
>>>
>>> (hex numbers:  my ramp file has first nibble as channel, second nibble as frame)
>>>
>>> frame 0:  00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0
>>> frame 1:  01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1
>>>
>>> It started with:
>>>
>>> frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
>>> frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1
>>>
>>> So, the transfer started wrong right out of the gate -- with an extra
>>> sample inserted at the beginning. Again, my setup is:
>>> 1) use scope to capture the TDM bus.  Trigger on first data change
>>> 2) aplay myramp.wav
>>> 3) If okay, ctrl-c and goto 2.
>>> 4) The capture below shows everything off by 1 sample.
>>>
>>> The capture is here:
>>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc
>>>
>>> This test definitely reveals that there is a startup issue.  Now for
>>> the $64,000 question: what to do with this knowledge?  I'm quite
>>> unfamiliar with how the DMA works at all.
>> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI
>> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure
>> that everything has been setup (DMA and callback). Note that I'm not using alsa because,
>> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app.
>>
>> Back to the DMA question, in your case shouldn't be really a problem since all DMA
>> stuff is handled by the linux audio framework.
>>
>> Regarding my SSI problem, I was able to keep the DMA working for few second once before
>> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX
>> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA
>> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with
>> and without SSI DMA support, but this end with a full system freeze.
> I got this system freeze too when enabling RIE and TIE because the
> interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset.
> (Check ref manual 61.9.5).   which I suspect was a livelock kind of
> situation where the ISR is just called infinitely often.  After
> disabling those, then the system worked okay.  Check out the previous
> patch I sent on the issue yesterday or the day before.

Ooohh!!! Forgot to check this!!! I'm now going to mask them!!!

>
>> Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference
>> manual to
>>
>> 37 -> SSI1 Receive 0 DMA request
>> 38 -> SSI1 Transmit 0 DMA request
>>
>> along that there are also
>>
>> 35 -> SSI1 Receive 1 DMA request
>> 36 -> SSI1 Transmit 1 DMA request
>>
>> I don't know actually how the two events types will behaves from the SDMA point of view.
> The 35 and 36 are for Dual fifo mode only, and no current system (with
> fsl_ssi.c anyway) uses dual fifo mode.  How do I know?  Because the
> it's definitely broken in the fsl_ssi.c.  I was just about to report
> that bug.

Ah! Thanks! The reference manual is really clear to explain it :-D !

> hint:  fsl_ssi.c:  if (ssi_private->use_dma && !ret && dmas[3] ==
> IMX_DMATYPE_SSI_DUAL) {
> should read  if (ssi_private->use_dma && !ret && dmas[4] ==
> IMX_DMATYPE_SSI_DUAL) {

Yep! I know such piece of code.

>
>> I'm also considering to make plain new audio driver to at least try to use something which
>> is supposed to work fine with SSI.
> Yeah, maybe that's the easiest way to go just to get operational.
> Start with just the bare minimum ssi driver so you know all the
> registers are locked into place the way you like.
>
> -caleb
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 9:02 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
> On 10/29/2015 04:54 PM, Caleb Crome wrote:
>> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>> On 10/29/2015 03:55 PM, Caleb Crome wrote:
>>> I don't know actually how the two events types will behaves from the SDMA point of view.
>> The 35 and 36 are for Dual fifo mode only, and no current system (with
>> fsl_ssi.c anyway) uses dual fifo mode.  How do I know?  Because the
>> it's definitely broken in the fsl_ssi.c.  I was just about to report
>> that bug.
>
> Ah! Thanks! The reference manual is really clear to explain it :-D !
>
>> hint:  fsl_ssi.c:  if (ssi_private->use_dma && !ret && dmas[2] ==
>> IMX_DMATYPE_SSI_DUAL) {
>> should read  if (ssi_private->use_dma && !ret && dmas[3] ==
>> IMX_DMATYPE_SSI_DUAL) {

Oops, nevermid.  I was looking at that wrong.  It's correct as is.
-Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/29/2015 05:02 PM, Roberto Fichera wrote:
> On 10/29/2015 04:54 PM, Caleb Crome wrote:
>> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>> On 10/29/2015 03:55 PM, Caleb Crome wrote:
>>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote:
>>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>>>>> I am actually thinking about setting a watermark to a larger number.
>>>>>> I forgot how the SDMA script handles this number. But if this burst
>>>>>> size means the overall data count per transaction, it might indicate
>>>>>> that each FIFO only gets half of the burst size due to dual FIFOs.
>>>>>>
>>>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
>>>>>> left, the largest safe burst size could be 14 (7 * 2) actually.
>>>>> Oh, does this depend on the data size?  I'm using 16-bit data, so I
>>>>> guess the bursts are measured in 2 byte units?  Does this mean that
>>>>> the burst size should be dynamically adjusted depending on word size
>>>>> (I guess done in hw_params)?
>>>>>
>>>>>> Nicolin
>>>> Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
>>>> maxburst=8 works okay, but still not perfect.
>>>>
>>>> I just discovered some new information:
>>>>
>>>> With wm=8 and maxburst=8 (which is my best setting so far), I just
>>>> captured a problem at the very start of playing a file, and restarted
>>>> enough times to capture it starting wrong:
>>>>
>>>> Instead of the playback starting with
>>>>
>>>> (hex numbers:  my ramp file has first nibble as channel, second nibble as frame)
>>>>
>>>> frame 0:  00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0
>>>> frame 1:  01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1
>>>>
>>>> It started with:
>>>>
>>>> frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
>>>> frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1
>>>>
>>>> So, the transfer started wrong right out of the gate -- with an extra
>>>> sample inserted at the beginning. Again, my setup is:
>>>> 1) use scope to capture the TDM bus.  Trigger on first data change
>>>> 2) aplay myramp.wav
>>>> 3) If okay, ctrl-c and goto 2.
>>>> 4) The capture below shows everything off by 1 sample.
>>>>
>>>> The capture is here:
>>>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc
>>>>
>>>> This test definitely reveals that there is a startup issue.  Now for
>>>> the $64,000 question: what to do with this knowledge?  I'm quite
>>>> unfamiliar with how the DMA works at all.
>>> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI
>>> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure
>>> that everything has been setup (DMA and callback). Note that I'm not using alsa because,
>>> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app.
>>>
>>> Back to the DMA question, in your case shouldn't be really a problem since all DMA
>>> stuff is handled by the linux audio framework.
>>>
>>> Regarding my SSI problem, I was able to keep the DMA working for few second once before
>>> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX
>>> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA
>>> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with
>>> and without SSI DMA support, but this end with a full system freeze.
>> I got this system freeze too when enabling RIE and TIE because the
>> interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset.
>> (Check ref manual 61.9.5).   which I suspect was a livelock kind of
>> situation where the ISR is just called infinitely often.  After
>> disabling those, then the system worked okay.  Check out the previous
>> patch I sent on the issue yesterday or the day before.
> Ooohh!!! Forgot to check this!!! I'm now going to mask them!!!

Doesn't work for me! Still freeze the system!  SIER=0x01d005f4

>
>>> Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference
>>> manual to
>>>
>>> 37 -> SSI1 Receive 0 DMA request
>>> 38 -> SSI1 Transmit 0 DMA request
>>>
>>> along that there are also
>>>
>>> 35 -> SSI1 Receive 1 DMA request
>>> 36 -> SSI1 Transmit 1 DMA request
>>>
>>> I don't know actually how the two events types will behaves from the SDMA point of view.
>> The 35 and 36 are for Dual fifo mode only, and no current system (with
>> fsl_ssi.c anyway) uses dual fifo mode.  How do I know?  Because the
>> it's definitely broken in the fsl_ssi.c.  I was just about to report
>> that bug.
> Ah! Thanks! The reference manual is really clear to explain it :-D !
>
>> hint:  fsl_ssi.c:  if (ssi_private->use_dma && !ret && dmas[3] ==
>> IMX_DMATYPE_SSI_DUAL) {
>> should read  if (ssi_private->use_dma && !ret && dmas[4] ==
>> IMX_DMATYPE_SSI_DUAL) {
> Yep! I know such piece of code.
>
>>> I'm also considering to make plain new audio driver to at least try to use something which
>>> is supposed to work fine with SSI.
>> Yeah, maybe that's the easiest way to go just to get operational.
>> Start with just the bare minimum ssi driver so you know all the
>> registers are locked into place the way you like.
>>
>> -caleb
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 9:34 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
> On 10/29/2015 05:02 PM, Roberto Fichera wrote:
>> On 10/29/2015 04:54 PM, Caleb Crome wrote:
>>> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>>> On 10/29/2015 03:55 PM, Caleb Crome wrote:
>>>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote:
>>>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>>>>>> I am actually thinking about setting a watermark to a larger number.
>>>>>>> I forgot how the SDMA script handles this number. But if this burst
>>>>>>> size means the overall data count per transaction, it might indicate
>>>>>>> that each FIFO only gets half of the burst size due to dual FIFOs.
>>>>>>>
>>>>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
>>>>>>> left, the largest safe burst size could be 14 (7 * 2) actually.
>>>>>> Oh, does this depend on the data size?  I'm using 16-bit data, so I
>>>>>> guess the bursts are measured in 2 byte units?  Does this mean that
>>>>>> the burst size should be dynamically adjusted depending on word size
>>>>>> (I guess done in hw_params)?
>>>>>>
>>>>>>> Nicolin
>>>>> Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
>>>>> maxburst=8 works okay, but still not perfect.
>>>>>
>>>>> I just discovered some new information:
>>>>>
>>>>> With wm=8 and maxburst=8 (which is my best setting so far), I just
>>>>> captured a problem at the very start of playing a file, and restarted
>>>>> enough times to capture it starting wrong:
>>>>>
>>>>> Instead of the playback starting with
>>>>>
>>>>> (hex numbers:  my ramp file has first nibble as channel, second nibble as frame)
>>>>>
>>>>> frame 0:  00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0
>>>>> frame 1:  01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1
>>>>>
>>>>> It started with:
>>>>>
>>>>> frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
>>>>> frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1
>>>>>
>>>>> So, the transfer started wrong right out of the gate -- with an extra
>>>>> sample inserted at the beginning. Again, my setup is:
>>>>> 1) use scope to capture the TDM bus.  Trigger on first data change
>>>>> 2) aplay myramp.wav
>>>>> 3) If okay, ctrl-c and goto 2.
>>>>> 4) The capture below shows everything off by 1 sample.
>>>>>
>>>>> The capture is here:
>>>>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc
>>>>>
>>>>> This test definitely reveals that there is a startup issue.  Now for
>>>>> the $64,000 question: what to do with this knowledge?  I'm quite
>>>>> unfamiliar with how the DMA works at all.
>>>> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI
>>>> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure
>>>> that everything has been setup (DMA and callback). Note that I'm not using alsa because,
>>>> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app.
>>>>
>>>> Back to the DMA question, in your case shouldn't be really a problem since all DMA
>>>> stuff is handled by the linux audio framework.
>>>>
>>>> Regarding my SSI problem, I was able to keep the DMA working for few second once before
>>>> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX
>>>> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA
>>>> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with
>>>> and without SSI DMA support, but this end with a full system freeze.
>>> I got this system freeze too when enabling RIE and TIE because the
>>> interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset.
>>> (Check ref manual 61.9.5).   which I suspect was a livelock kind of
>>> situation where the ISR is just called infinitely often.  After
>>> disabling those, then the system worked okay.  Check out the previous
>>> patch I sent on the issue yesterday or the day before.
>> Ooohh!!! Forgot to check this!!! I'm now going to mask them!!!
>
> Doesn't work for me! Still freeze the system!  SIER=0x01d005f4

You still have many per-frame interrupts enabled, which is still too
many enabled.  for example, you have RLSIE, TLSIE, RFSIE, TFSIE, etc.
These all generate one interrupt per frame, and not necessarily at the
same time, so you could be having 4 or more interrupts per frame.  Be
sure they're all zero except for the DMA enable and the specific ones
you actually want enabled.

-C

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera]

On 10/29/2015 05:39 PM, Caleb Crome wrote:
> On Thu, Oct 29, 2015 at 9:34 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>> On 10/29/2015 05:02 PM, Roberto Fichera wrote:
>>> On 10/29/2015 04:54 PM, Caleb Crome wrote:
>>>> On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>>>>> On 10/29/2015 03:55 PM, Caleb Crome wrote:
>>>>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@crome.org> wrote:
>>>>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>>>>>>> I am actually thinking about setting a watermark to a larger number.
>>>>>>>> I forgot how the SDMA script handles this number. But if this burst
>>>>>>>> size means the overall data count per transaction, it might indicate
>>>>>>>> that each FIFO only gets half of the burst size due to dual FIFOs.
>>>>>>>>
>>>>>>>> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
>>>>>>>> left, the largest safe burst size could be 14 (7 * 2) actually.
>>>>>>> Oh, does this depend on the data size?  I'm using 16-bit data, so I
>>>>>>> guess the bursts are measured in 2 byte units?  Does this mean that
>>>>>>> the burst size should be dynamically adjusted depending on word size
>>>>>>> (I guess done in hw_params)?
>>>>>>>
>>>>>>>> Nicolin
>>>>>> Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
>>>>>> maxburst=8 works okay, but still not perfect.
>>>>>>
>>>>>> I just discovered some new information:
>>>>>>
>>>>>> With wm=8 and maxburst=8 (which is my best setting so far), I just
>>>>>> captured a problem at the very start of playing a file, and restarted
>>>>>> enough times to capture it starting wrong:
>>>>>>
>>>>>> Instead of the playback starting with
>>>>>>
>>>>>> (hex numbers:  my ramp file has first nibble as channel, second nibble as frame)
>>>>>>
>>>>>> frame 0:  00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0
>>>>>> frame 1:  01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1
>>>>>>
>>>>>> It started with:
>>>>>>
>>>>>> frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
>>>>>> frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1
>>>>>>
>>>>>> So, the transfer started wrong right out of the gate -- with an extra
>>>>>> sample inserted at the beginning. Again, my setup is:
>>>>>> 1) use scope to capture the TDM bus.  Trigger on first data change
>>>>>> 2) aplay myramp.wav
>>>>>> 3) If okay, ctrl-c and goto 2.
>>>>>> 4) The capture below shows everything off by 1 sample.
>>>>>>
>>>>>> The capture is here:
>>>>>> https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc
>>>>>>
>>>>>> This test definitely reveals that there is a startup issue.  Now for
>>>>>> the $64,000 question: what to do with this knowledge?  I'm quite
>>>>>> unfamiliar with how the DMA works at all.
>>>>> I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI
>>>>> clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure
>>>>> that everything has been setup (DMA and callback). Note that I'm not using alsa because,
>>>>> my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app.
>>>>>
>>>>> Back to the DMA question, in your case shouldn't be really a problem since all DMA
>>>>> stuff is handled by the linux audio framework.
>>>>>
>>>>> Regarding my SSI problem, I was able to keep the DMA working for few second once before
>>>>> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX
>>>>> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA
>>>>> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with
>>>>> and without SSI DMA support, but this end with a full system freeze.
>>>> I got this system freeze too when enabling RIE and TIE because the
>>>> interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset.
>>>> (Check ref manual 61.9.5).   which I suspect was a livelock kind of
>>>> situation where the ISR is just called infinitely often.  After
>>>> disabling those, then the system worked okay.  Check out the previous
>>>> patch I sent on the issue yesterday or the day before.
>>> Ooohh!!! Forgot to check this!!! I'm now going to mask them!!!
>> Doesn't work for me! Still freeze the system!  SIER=0x01d005f4

I thought the same but setting only RFF0, TFE0, RDMAE and TDMAE along the RIE and TIE still free the system.

> You still have many per-frame interrupts enabled, which is still too
> many enabled.  for example, you have RLSIE, TLSIE, RFSIE, TFSIE, etc.
> These all generate one interrupt per frame, and not necessarily at the
> same time, so you could be having 4 or more interrupts per frame.  Be
> sure they're all zero except for the DMA enable and the specific ones
> you actually want enabled.

Yep! But I still think that the CPU should be able to handle all them.

>
> -C
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Thu, Oct 29, 2015 at 08:54:00AM -0700, Caleb Crome wrote:

> The 35 and 36 are for Dual fifo mode only, and no current system (with
> fsl_ssi.c anyway) uses dual fifo mode.  How do I know?  Because the
> it's definitely broken in the fsl_ssi.c.  I was just about to report
> that bug.

Broken? Where? The reason why there's no current system using that
is because there is no SDMA patch to upload a newer version of the
SDMA firmware which is always included in the Freescale official
release. Yes, you saw that patch in the beginning of this thread.
For SDMA DT binding, number 22 is the configurations of Dual FIFO
script but it would break most of the upstream users as upstream
Kernels running with a default ROM firmware don't have that script.

If you want to use Dual FIFO mode with upstream Kernels, apply the
change I provided you in my previous reply along with these two:

commit 2490a94afbcb139f68f7872e5645d66b99720a52
Author: Shawn Guo <shawn.guo@freescale.com>
Date:   Tue Jul 16 22:53:18 2013 +0800

    ENGR00269945: firwmare: imx: add imx6q sdma script
    
    Add imx6q sdma script which will be used by all i.MX6 series.
    
    Signed-off-by: Shawn Guo <shawn.guo@freescale.com>

diff --git a/firmware/Makefile b/firmware/Makefile
index e297e1b..7b22ab3 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -61,6 +61,7 @@ fw-shipped-$(CONFIG_DRM_RADEON) += radeon/R100_cp.bin radeon/R200_cp.bin \
 				   radeon/RV770_pfp.bin radeon/RV770_me.bin \
 				   radeon/RV730_pfp.bin radeon/RV730_me.bin \
 				   radeon/RV710_pfp.bin radeon/RV710_me.bin
+fw-shipped-$(CONFIG_IMX_SDMA) += imx/sdma/sdma-imx6q.bin
 fw-shipped-$(CONFIG_DVB_AV7110) += av7110/bootcode.bin
 fw-shipped-$(CONFIG_DVB_TTUSB_BUDGET) += ttusb-budget/dspbootcode.bin
 fw-shipped-$(CONFIG_E100) += e100/d101m_ucode.bin e100/d101s_ucode.bin \
diff --git a/firmware/imx/sdma/sdma-imx6q.bin.ihex b/firmware/imx/sdma/sdma-imx6q.bin.ihex
new file mode 100644
index 0000000..2e561f0
--- /dev/null
+++ b/firmware/imx/sdma/sdma-imx6q.bin.ihex
@@ -0,0 +1,116 @@
+:1000000053444D4101000000010000001C000000AD
+:1000100026000000B40000007A0600008202000002
+:10002000FFFFFFFF00000000FFFFFFFFFFFFFFFFDC
+:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
+:10004000FFFFFFFFFFFFFFFF6A1A0000FFFFFFFF38
+:10005000EB020000BB180000FFFFFFFF08040000D8
+:10006000FFFFFFFFC0030000FFFFFFFFFFFFFFFFD9
+:10007000FFFFFFFFAB020000FFFFFFFF7B0300005D
+:10008000FFFFFFFFFFFFFFFF4C0400006E040000B6
+:10009000FFFFFFFF00180000FFFFFFFFFFFFFFFF54
+:1000A000000000000018000062180000161A00008E
+:1000B000061B0000E3C1DB57E35FE357F352016A1D
+:1000C0008F00D500017D8D00A005EB5D7804037DD8
+:1000D00079042C7D367C79041F7CEE56000F600677
+:1000E000057D0965437E0A62417E20980A623E7E54
+:1000F00009653C7E12051205AD026007037DFB55C4
+:10010000D36D2B98FB55041DD36DC86A2F7F011F3B
+:1001100003200048E47C5398FB55D76D1500057803
+:100120000962C86A0962C86AD76D5298FB55D76DD3
+:100130001500150005780A62C86A0A62C86AD76D98
+:100140005298FB55D76D15001500150005780B6208
+:10015000C86A0B62C86AD76D097CDF6D077F000033
+:10016000EB55004D077DFAC1E35706980700CC68B0
+:100170000C6813C20AC20398D9C1E3C1DB57E35F1D
+:10018000E357F352216A8F00D500017D8D00A00551
+:10019000EB5DFB567804037D79042A7D317C79047C
+:1001A000207C700B1103EB53000F6003057D096584
+:1001B000377E0A62357E86980A62327E0965307E15
+:1001C00012051205AD026007027C065A8E98265A67
+:1001D000277F011F03200048E87C700B1103135395
+:1001E000AF98150004780962065A0962265AAE983B
+:1001F0001500150004780A62065A0A62265AAE985B
+:1002000015001500150004780B62065A0B62265A79
+:10021000077C0000EB55004D067DFAC1E357699855
+:1002200007000C6813C20AC26698700B11031353BF
+:100230006C07017CD9C1FB5E8A066B07017CD9C1C2
+:10024000F35EDB59D3588F0110010F398B003CC18D
+:100250002B7DC05AC85B4EC1277C88038906E35CAE
+:10026000FF0D1105FF1DBC053E07004D187D7008F0
+:1002700011007E07097D7D07027D2852E698F8521D
+:10028000DB54BC02CC02097C7C07027D2852EF982B
+:10029000F852D354BC02CC02097D0004DD988B00D7
+:1002A000C052C85359C1D67D0002CD98FF08BF0087
+:1002B0007F07157D8804D500017D8D00A005EB5DCD
+:1002C0008F0212021202FF3ADA05027C3E071899E9
+:1002D000A402DD02027D3E0718995E071899EB55CE
+:1002E0009805EB5DF352FB546A07267D6C07017D90
+:1002F00055996B07577C6907047D6807027D010EDD
+:100300002F999358D600017D8E009355A005935DDB
+:10031000A00602780255045D1D7C004E087C69072A
+:10032000037D0255177E3C99045D147F8906935026
+:100330000048017D2799A099150006780255045DB3
+:100340004F070255245D2F07017CA09917006F0706
+:10035000017C012093559D000700A7D9F598D36C27
+:100360006907047D6807027D010E64999358D600E1
+:10037000017D8E009355A005935DA006027802557D
+:10038000C86D0F7C004E087C6907037D0255097E0D
+:100390007199C86D067F890693500048017D5C996C
+:1003A000A0999A99C36A6907047D6807027D010EC6
+:1003B00087999358D600017D8E009355A005935DD3
+:1003C000A0060278C865045D0F7C004E087C6907B2
+:1003D000037DC865097E9499045D067F8906935064
+:1003E0000048017D7F99A09993559D000700FF6CFF
+:1003F000A7D9F5980000E354EB55004D017CF59822
+:10040000DD98E354EB55FF0A1102FF1A7F07027CC7
+:10041000A005B4999D008C05BA05A0051002BA0488
+:10042000AD0454040600E3C1DB57FB52C36AF35228
+:10043000056A8F00D500017D8D00A005EB5D780475
+:10044000037D79042B7D1E7C7904337CEE56000FEE
+:10045000FB556007027DC36DD599041DC36DC8624D
+:100460003B7E6006027D10021202096A357F12028D
+:10047000096A327F1202096A2F7F011F0320004898
+:10048000E77C099AFB55C76D150015001500057826
+:10049000C8620B6AC8620B6AC76D089AFB55C76DC4
+:1004A000150015000578C8620A6AC8620A6AC76D35
+:1004B000089AFB55C76D15000578C862096AC862BD
+:1004C000096AC76D097C286A077F0000EB55004D5B
+:1004D000057DFAC1DB57BF9977C254040AC2BA99A5
+:1004E000D9C1E3C1DB57F352056A8F00D500017D06
+:1004F0008D00A005FB567804037D7904297D1F7CBF
+:1005000079042E7CE35D700D1105ED55000F600739
+:10051000027D0652329A2652337E6005027D100219
+:100520001202096A2D7F1202096A2A7F1202096AE1
+:10053000277F011F03200048EA7CE3555D9A1500E0
+:1005400015001500047806520B6A26520B6A5C9A55
+:1005500015001500047806520A6A26520A6A5C9A47
+:10056000150004780652096A2652096A097C286A2D
+:10057000077F0000DB57004D057DFAC1DB571B9A52
+:1005800077C254040AC2189AE3C1DB57F352056AD2
+:10059000FB568E02941AC36AC8626902247D941EB7
+:1005A000C36ED36EC8624802C86A9426981EC36E92
+:1005B000D36EC8624C02C86A9826C36E981EC36E7A
+:1005C000C8629826C36E6002097CC8626E02247DF0
+:1005D000096A1E7F0125004D257D849A286A187FAF
+:1005E00004627AC2B89AE36E8F00D805017D8D004F
+:1005F000A005C8626E02107D096A0A7F0120F97C9D
+:10060000286A067F0000004D0D7DFAC1DB576E9A07
+:10061000070004620C6AB59A286AFA7F04627AC2FB
+:1006200058045404286AF47F0AC26B9AD9C1E3C102
+:10063000DB57F352056AFB568E02941A0252690286
+:100640001D7D941E06524802065A9426981E065294
+:100650004C02065A9826981E065260020A7C98267A
+:1006600006526E02237D096A1D7F0125004D247DFF
+:10067000D19A286A177F04627AC2029B8F00D8053C
+:10068000017D8D00A00506526E02107D096A0A7F69
+:100690000120F97C286A067F0000004D0D7DFAC11B
+:1006A000DB57C19A070004620C6AFF9A286AFA7F36
+:1006B00004627AC258045404286AF47F0AC2BE9ABB
+:1006C000016E0B612F7E0B622D7E0B632B7E0C0D5A
+:1006D0001704170417049D04081DCC05017C0C0D9C
+:1006E000D16A000F4207C86FDD6F1C7F8E009D002E
+:1006F00001680B67177ED56B04080278C86F120774
+:10070000117C0B670F7E04080278C86F12070A7C01
+:10071000DD6F087FD169010FC86FDD6F037F0101B5
+:0E0720000004129B0700FF680C680002129B89
+:00000001FF


commit 870291e6b0019ff0a9a135f2641c7801b36a80ef
Author: Nicolin Chen <nicoleotsuka@gmail.com>
Date:   Thu Sep 4 21:42:35 2014 -0700

    firmware: imx: sdma v2
    
    In the upstream kernel, i.MX6 series uses SDMA firmware V2. However,
    we actually don't have a strict version control internally. So this
    patch just simply hacks the firmware to change the version number to
    V2.
    
    Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>

diff --git a/firmware/imx/sdma/sdma-imx6q.bin.ihex b/firmware/imx/sdma/sdma-imx6q.bin.ihex
index 2e561f0..ceb114b 100644
--- a/firmware/imx/sdma/sdma-imx6q.bin.ihex
+++ b/firmware/imx/sdma/sdma-imx6q.bin.ihex
@@ -1,4 +1,4 @@
-:1000000053444D4101000000010000001C000000AD
+:1000000053444D4102000000010000001C000000AC
 :1000100026000000B40000007A0600008202000002
 :10002000FFFFFFFF00000000FFFFFFFFFFFFFFFFDC
 :10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 11:36 AM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Thu, Oct 29, 2015 at 08:54:00AM -0700, Caleb Crome wrote:
>
>> The 35 and 36 are for Dual fifo mode only, and no current system (with
>> fsl_ssi.c anyway) uses dual fifo mode.  How do I know?  Because the
>> it's definitely broken in the fsl_ssi.c.  I was just about to report
>> that bug.
>
> Broken? Where?

Sorry, my bad, the only broken part was my understanding :-)  I
discovered that a few minutes after I posted the comment.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Thu, Oct 29, 2015 at 04:37:35PM +0100, Roberto Fichera wrote:

> Regarding my SSI problem, I was able to keep the DMA working for few second once before
> it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for rx

DMA only stops when getting terminate_all() executed or FIFO doesn't
reach the watermark so that no newer DMA request would be issued.

> I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA
> has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with

Guessing? It'd weird that SPBA would ease the issue here as I was told
by the IC team that SSI and SAI in SoloX don't require SPBA clock IIRC.

> and without SSI DMA support, but this end with a full system freeze. The ISR was never changed
> in my fsl_ssi.c.

You mentioned that clock status from the Codec chip shows the bit clock
stops but now it's related to DMA? I think you should first figure out
where the problem locates as Caleb's problem is different from yours.

As I mentioned, you may need to confirm that if the bit clock generation
is stopped. DMA surely won't work when the bit clock ends as SSI may
no longer consume the data FIFO so the watermark would never be reached
again.

Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Thu, Oct 29, 2015 at 07:55:59AM -0700, Caleb Crome wrote:

> >> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space
> >> left, the largest safe burst size could be 14 (7 * 2) actually.

> > Oh, does this depend on the data size?  I'm using 16-bit data, so I
> > guess the bursts are measured in 2 byte units?  Does this mean that
> > the burst size should be dynamically adjusted depending on word size
> > (I guess done in hw_params)?

You don't need to do that. It's already been taken care in the DMA
code.

> Okay, so wm=8 and maxburst=14 definitely does not work at all,.  wm=8,
> maxburst=8 works okay, but still not perfect.

Make sure you are using Dual FIFO configurations for both SDMA and
SSI. You can refer to my change below (I've tested it with a two-
channel test case being played in 44.1KHz 16-bit):

diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index b8a5056..f4c7308 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -307,7 +307,7 @@
 					clocks = <&clks IMX6SX_CLK_SSI1_IPG>,
 						 <&clks IMX6SX_CLK_SSI1>;
 					clock-names = "ipg", "baud";
-					dmas = <&sdma 37 1 0>, <&sdma 38 1 0>;
+					dmas = <&sdma 37 22 0>, <&sdma 38 22 0>;
 					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
@@ -321,7 +321,7 @@
 					clocks = <&clks IMX6SX_CLK_SSI2_IPG>,
 						 <&clks IMX6SX_CLK_SSI2>;
 					clock-names = "ipg", "baud";
-					dmas = <&sdma 41 1 0>, <&sdma 42 1 0>;
+					dmas = <&sdma 41 22 0>, <&sdma 42 22 0>;
 					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
@@ -335,7 +335,7 @@
 					clocks = <&clks IMX6SX_CLK_SSI3_IPG>,
 						 <&clks IMX6SX_CLK_SSI3>;
 					clock-names = "ipg", "baud";
-					dmas = <&sdma 45 1 0>, <&sdma 46 1 0>;
+					dmas = <&sdma 45 22 0>, <&sdma 46 22 0>;
 					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 674abf7..7cfe661 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1002,8 +1002,8 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
 		wm = ssi_private->fifo_depth;
 
 	regmap_write(regs, CCSR_SSI_SFCSR,
-			CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
-			CCSR_SSI_SFCSR_TFWM1(wm) | CCSR_SSI_SFCSR_RFWM1(wm));
+			CCSR_SSI_SFCSR_TFWM0(8) | CCSR_SSI_SFCSR_RFWM0(8) |
+			CCSR_SSI_SFCSR_TFWM1(8) | CCSR_SSI_SFCSR_RFWM1(8));
 
 	if (ssi_private->use_dual_fifo) {
 		regmap_update_bits(regs, CCSR_SSI_SRCR, CCSR_SSI_SRCR_RFEN1,
@@ -1322,8 +1322,9 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev,
 		/* When using dual fifo mode, we need to keep watermark
 		 * as even numbers due to dma script limitation.
 		 */
-		ssi_private->dma_params_tx.maxburst &= ~0x1;
-		ssi_private->dma_params_rx.maxburst &= ~0x1;
+		dev_info(&pdev->dev, "tunning burst size for Dual FIFO mode\n");
+		ssi_private->dma_params_tx.maxburst = 16;
+		ssi_private->dma_params_rx.maxburst = 16;
 	}
 
 	if (!ssi_private->use_dma) {

And make sure you have the dev_info() printed out in your console.
/* 22 in the DT is to call the Dual FIFO SDMA script */

> It started with:
> 
> frame 0:  00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0
> frame 1:  f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1

If this happens, just try to let SDMA work before SSI starts to
read FIFOs -- enabling TDMAE or RDMAE before enabling TE or RE:

@@ -1093,6 +1093,15 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
 	case SNDRV_PCM_TRIGGER_RESUME:
 	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			regmap_update_bits(regs, CCSR_SSI_SIER,
+					   CCSR_SSI_SIER_TDMAE,
+					   CCSR_SSI_SIER_TDMAE);
+		else
+			regmap_update_bits(regs, CCSR_SSI_SIER,
+					   CCSR_SSI_SIER_RDMAE,
+					   CCSR_SSI_SIER_RDMAE);
+
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
 			fsl_ssi_tx_config(ssi_private, true);
 		else
 			fsl_ssi_rx_config(ssi_private, true);

Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Thu, Oct 29, 2015 at 06:44:12AM -0700, Caleb Crome wrote:
> > Reported by user space? Are you saying that's an ALSA underrun in
> > the user space, not a hardware underrun reported by the IRQ in the
> > driver? They are quite different. ALSA underrun comes from the DMA
> > buffer gets underrun while the other one results from FIFO feeding
> > efficiency. For ALSA underrun, enlarging the playback period size
> > and period number will ease the problem:
 
> Sometimes they happen at the same time.  So, I run aplay, and all is

The 'they' is indicating ALSA underrun + hardware underrun or ALSA
underrun + channel slip? It's not quite logical for a channel slip
resulting from an ALSA underrun as it should restart by calling the
trigger() functions in DAI drivers IIRC.

> fine.  Then the user space app will underrun, and then I look at the
> scope, and the channels have slipped.  So somehow the start/restart
> after the underrun is not always perfect I guess.

> Is there any mechanism for the DMA fifo underruns to be reported back
> to user space?  There certainly should be, because the consequences

No. The release from Freescale official tree has a reset procedure
applied to ESAI underrun but not SSI but I guess you may want to
refer to that.

> are catastrophic, yet the user space app goes on as if everything is
> just great.  Much, much worse than the underrun that is reported (i.e.
> a skip in audio is bad but sometimes tolerable.  A channel slip is
> permanent and absolutely intolerable).

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

STARTUP ISSUE SOLVED (INELEGANTLY)

:-)

On Thu, Oct 29, 2015 at 10:19 AM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Thu, Oct 29, 2015 at 06:44:12AM -0700, Caleb Crome wrote:
>> > Reported by user space? Are you saying that's an ALSA underrun in
>> > the user space, not a hardware underrun reported by the IRQ in the
>> > driver? They are quite different. ALSA underrun comes from the DMA
>> > buffer gets underrun while the other one results from FIFO feeding
>> > efficiency. For ALSA underrun, enlarging the playback period size
>> > and period number will ease the problem:
>
>> Sometimes they happen at the same time.  So, I run aplay, and all is
>
> The 'they' is indicating ALSA underrun + hardware underrun or ALSA
> underrun + channel slip?

Exactly, they tend to come together, but either can come without the other.

> It's not quite logical for a channel slip
> resulting from an ALSA underrun as it should restart by calling the
> trigger() functions in DAI drivers IIRC.

This actually is exactly what I'm seeing now.  I'm seeing the
*startup* happening from the trigger starting up slipped.  So this
does make perfect sense to me.

I am playing a very short ramp.wav file and seeing how often it starts
up 'slipped' with the extra 0.  It started up incorrectly 20 out of
300 trials.  So, the startup is failing 7% of the time.

It occurred to me that perhaps the problem has to do when exactly when
during the frame-sync period the fsl_ssi_trigger function was called.
Perhaps, if it's called near the end or beginning of a frame, somehow
something gets messed up.  (The docs for the SCR register imply some
of this, but it talks about either 2 or 6 bit clocks, so I'd expect
the error rate to be lower than 7% (more like 2.5%).

So, I implemented a really inelegant patch to synchronize the trigger
with the frame sync signal, and I got ZERO errors out of 500 trials!
This seems to have nailed the startup problem!

In addition, I have run about 20 minutes of audio with no slips or
problems, even though there have been aplay underruns.  This is a
major step forward for me :-)

The idea is to enable the SSI before enabling DMA.  Then wait for a
frame sync by polling.  Once I get the frame sync disable the SSI, and
let the trigger function continue.

How should this be done properly?

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 73778c2..8cd8284 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -328,6 +328,41 @@ static void fsl_ssi_rxtx_config(struct
fsl_ssi_private *ssi_private,
     }
 }

+/*
+ * wait for a frame sync.  do this by enabling the SSI,
+ * then waiting for sync to happen, then disabling the SSI
+ * and put it back to the state it was at first
+ */
+static void wait_for_tfs(struct regmap *regs)
+{
+    u32 tfs;
+    u32 scr;
+    int maxcount = 100000;
+    regmap_read(regs, CCSR_SSI_SCR, &scr);
+    regmap_update_bits(regs, CCSR_SSI_SCR, 0x3, 0x3);
+    while(maxcount--) {
+        /* clear TFS bit */
+        regmap_update_bits(regs, CCSR_SSI_SISR, CCSR_SSI_SISR_TFS, 0);
+        regmap_read(regs, CCSR_SSI_SISR, &tfs);
+        if ((tfs & CCSR_SSI_SISR_TFS)==0)
+            break; /* tfs went to 0 */
+    }
+    if (maxcount < 0) {
+        printk(KERN_INFO "timed out 1, sisr = 0x%08x\n", tfs);
+    }
+    maxcount = 100000;
+    while(maxcount--) {
+        /* waiting for tfs to go to 1. */
+        regmap_read(regs, CCSR_SSI_SISR, &tfs);
+        if ((tfs & CCSR_SSI_SISR_TFS))
+            break; /* tfs went to 1 */
+    }
+    if (maxcount < 0) {
+        printk(KERN_INFO "timed out 2\n");
+    }
+    regmap_write(regs, CCSR_SSI_SCR, scr);
+}
+
 /*
  * Calculate the bits that have to be disabled for the current stream that is
  * getting disabled. This keeps the bits enabled that are necessary for the
@@ -360,7 +395,10 @@ static void fsl_ssi_config(struct fsl_ssi_private
*ssi_private, bool enable,
     int nr_active_streams;
     u32 scr_val;
     int keep_active;
-
+    wait_for_tfs(regs); /* synchronize with the start of a frame
+                 * to get done with this function well
+                 * before the end of a frame
+                 */
     regmap_read(regs, CCSR_SSI_SCR, &scr_val);

     nr_active_streams = !!(scr_val & CCSR_SSI_SCR_TE) +
@@ -943,9 +980,9 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
      * size.
      */
     if (ssi_private->use_dma)
-        wm = ssi_private->fifo_depth - 2;
+        wm = 8;
     else
-        wm = ssi_private->fifo_depth;
+        wm = 8;

     regmap_write(regs, CCSR_SSI_SFCSR,
             CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
@@ -1260,8 +1297,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev,
      * We have burstsize be "fifo_depth - 2" to match the SSI
      * watermark setting in fsl_ssi_startup().
      */
-    ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2;
-    ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2;
+    ssi_private->dma_params_tx.maxburst = 8;
+    ssi_private->dma_params_rx.maxburst = 8;
     ssi_private->dma_params_tx.addr = ssi_private->ssi_phys + CCSR_SSI_STX0;
     ssi_private->dma_params_rx.addr = ssi_private->ssi_phys + CCSR_SSI_SRX0;

>
>> fine.  Then the user space app will underrun, and then I look at the
>> scope, and the channels have slipped.  So somehow the start/restart
>> after the underrun is not always perfect I guess.
>
>> Is there any mechanism for the DMA fifo underruns to be reported back
>> to user space?  There certainly should be, because the consequences
>
> No. The release from Freescale official tree has a reset procedure
> applied to ESAI underrun but not SSI but I guess you may want to
> refer to that.

Ooh, that can be a problem.   Maybe I'll take a look.  But for the
moment, it appears that, so far, for now, the system is working.

-Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Thu, Oct 29, 2015 at 12:06:16PM -0700, Caleb Crome wrote:

> This actually is exactly what I'm seeing now.  I'm seeing the
> *startup* happening from the trigger starting up slipped.  So this
> does make perfect sense to me.

I saw your problem in the other reply. And I suggested you to let
DMA work first before SSI gets enabled. As SDMA in that case would
transfer one burst length (16 if you applied my patch I sent you)
and pause before SSI gets enabled. Then SSI would have enough data
to send out without any startup issue.

> It occurred to me that perhaps the problem has to do when exactly when
> during the frame-sync period the fsl_ssi_trigger function was called.
> Perhaps, if it's called near the end or beginning of a frame, somehow

I don't know how you measured if it's before of after. But the frame
should not start until trigger() gets call -- more clearly SSIEN and
TE get enabled. From my point of view, you problem should be caused
by SSI getting enabled without enough data in the FIFO. And that's
what I just described in the previous paragraph and previous reply.

> something gets messed up.  (The docs for the SCR register imply some
> of this, but it talks about either 2 or 6 bit clocks, so I'd expect
> the error rate to be lower than 7% (more like 2.5%).

> In addition, I have run about 20 minutes of audio with no slips or
> problems, even though there have been aplay underruns.  This is a
> major step forward for me :-)

It'd be better to avoid user space ALSA underun as it may skip some
data.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 12:28 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Thu, Oct 29, 2015 at 12:06:16PM -0700, Caleb Crome wrote:
>
>> This actually is exactly what I'm seeing now.  I'm seeing the
>> *startup* happening from the trigger starting up slipped.  So this
>> does make perfect sense to me.
>
> I saw your problem in the other reply. And I suggested you to let
> DMA work first before SSI gets enabled. As SDMA in that case would
> transfer one burst length (16 if you applied my patch I sent you)
> and pause before SSI gets enabled. Then SSI would have enough data
> to send out without any startup issue.

Ah ha, you are exactly right.  The root cause is that TE and SSIE are
enabled at the same regmap write, with no opportunity for delay
between the SSIE and TE.
DMA can only get going if SSIE is enabled, and the only place SSIE
gets enabled is exactly the same line that TE gets enabled.

specifically: regmap_update_bits(regs, CCSR_SSI_SCR, vals->scr, vals->scr);

I've looked over your emails and I don't see the patch that shows a
pause between SSIE enable and TE enable.  (I do see the dual-fifo
example -- thank you!  I'll give that a try -- it may further reduce
stress on the system).

Here is a patch that solves the issue much more elegantly than my previous one:
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 73778c2..0bb5e52 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -435,8 +475,27 @@ static void fsl_ssi_config(struct fsl_ssi_private
*ssi_private, bool enable,

 config_done:
     /* Enabling of subunits is done after configuration */
-    if (enable)
+    if (enable) {
+        /*
+         * don't enable TE/RE and SSIEN at the same time.
+         * enable SSIEN, but delay enabling of TE to
+         * allow time for DMA buffer to fill.
+         */
+        u32 mask = vals->scr & ~CCSR_SSI_SCR_TE;
+        if (mask != vals->scr) {
+            /* enabling TE in this call.  don't enable it
+             * until some delay after SSIE gets
+             * enabled. */
+            if (vals->scr & ~CCSR_SSI_SCR_TE) {
+                regmap_update_bits(regs, CCSR_SSI_SCR,
+                           mask, vals->scr);
+                udelay(50); /* give the DMA a chance
+                         * to fill the TX buffer
+                         * after SSIE is enabled. */
+            }
+        }
         regmap_update_bits(regs, CCSR_SSI_SCR, vals->scr, vals->scr);
+    }
 }


>
>> It occurred to me that perhaps the problem has to do when exactly when
>> during the frame-sync period the fsl_ssi_trigger function was called.
>> Perhaps, if it's called near the end or beginning of a frame, somehow
>
> I don't know how you measured if it's before of after. But the frame
> should not start until trigger() gets call -- more clearly SSIEN and
> TE get enabled. From my point of view, you problem should be caused
> by SSI getting enabled without enough data in the FIFO. And that's
> what I just described in the previous paragraph and previous reply.

Yep, that sure seems to be it.  This patch above never seems to have a
bad start.
Is adding the udelay the best way to put a delay between SSIE and TE enable?
Are there any other mechanisms for that?

Thanks so much for your attention and help!  I think I can finally
move forward with the MX6 on a bunch of projects now :-)

(well, I still have to test Rx and verify full dulex perfection there
too, but this is a great start)

-Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Thu, Oct 29, 2015 at 03:23:41PM -0700, Caleb Crome wrote:

> > I saw your problem in the other reply. And I suggested you to let
> > DMA work first before SSI gets enabled. As SDMA in that case would
> > transfer one burst length (16 if you applied my patch I sent you)
> > and pause before SSI gets enabled. Then SSI would have enough data
> > to send out without any startup issue.
> 
> Ah ha, you are exactly right.  The root cause is that TE and SSIE are
> enabled at the same regmap write, with no opportunity for delay
> between the SSIE and TE.
> DMA can only get going if SSIE is enabled, and the only place SSIE
> gets enabled is exactly the same line that TE gets enabled.

A little difference between your point and mine is that you think
DMA request only starts when SSIE and TDMAE both get set while I
only think about TDMAE. It's hard to say which one is correct as
it depends on the design of IP wrapper but you can fairly test it
with your change below: Mask both TE with SSIE and set them after
the delay. If it doesn't work, yours is the correct one.

> I've looked over your emails and I don't see the patch that shows a

You may need to open an offline email that I sent you with patches
in its attachment. I can see it via Gmail anyway.

> pause between SSIE enable and TE enable.  (I do see the dual-fifo
> example -- thank you!  I'll give that a try -- it may further reduce
> stress on the system).

I'm sure dual FIFO will get better performance. But the example I
gave you doesn't set RX parameters so well. You may need to fine
tune it later.

> Is adding the udelay the best way to put a delay between SSIE and TE enable?
> Are there any other mechanisms for that?

Having a delay is much safer for you but surely it's not a common
practice that's best all other platforms such as two-channel cases
and those who needs performance.

I encourage you to try to follow one of patches I gave you that
sets TDMAE/RDMAE at the beginning of the trigger(). Surely you may
change it to TDMAE | SSIE after you find out that SSIE is indeed
required. If you are still having trouble, adding a delay would
be nice for you but it may be hard for me to ack it if you want
to merge it in the driver.

Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 3:47 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Thu, Oct 29, 2015 at 03:23:41PM -0700, Caleb Crome wrote:
>
>> > I saw your problem in the other reply. And I suggested you to let
>> > DMA work first before SSI gets enabled. As SDMA in that case would
>> > transfer one burst length (16 if you applied my patch I sent you)
>> > and pause before SSI gets enabled. Then SSI would have enough data
>> > to send out without any startup issue.
>>
>> Ah ha, you are exactly right.  The root cause is that TE and SSIE are
>> enabled at the same regmap write, with no opportunity for delay
>> between the SSIE and TE.
>> DMA can only get going if SSIE is enabled, and the only place SSIE
>> gets enabled is exactly the same line that TE gets enabled.
>
> A little difference between your point and mine is that you think
> DMA request only starts when SSIE and TDMAE both get set while I
> only think about TDMAE. It's hard to say which one is correct as
> it depends on the design of IP wrapper but you can fairly test it
> with your change below: Mask both TE with SSIE and set them after
> the delay. If it doesn't work, yours is the correct one.

Ah, that's one thing that's very clear in the FSL datasheet:  the
FIFOs are ZEROED if SSIE is 0.  This means that even if the DMA were
trying to dump data in before SSIE is enabled, the data would go to
bit heaven.

The docs for TE say, "The normal transmit enable sequence is to write
data to the STX register(s) and then set the TE bit." (page 5145 of
IMX6SDLRM.pdf)

So in the DMA + fifo case the words, "write data to the STX
register(s)" imply that it's actually DMA writing to FIFOs, which then
write the STX register.  So, the sequence must be:  enable SSIE &
TDMAE to allow DMA to write to the fifo, then later enable TE, right?

>
>> I've looked over your emails and I don't see the patch that shows a
>
> You may need to open an offline email that I sent you with patches
> in its attachment. I can see it via Gmail anyway.

Will do.  Thanks.

>
>> pause between SSIE enable and TE enable.  (I do see the dual-fifo
>> example -- thank you!  I'll give that a try -- it may further reduce
>> stress on the system).
>
> I'm sure dual FIFO will get better performance. But the example I
> gave you doesn't set RX parameters so well. You may need to fine
> tune it later.
>
>> Is adding the udelay the best way to put a delay between SSIE and TE enable?
>> Are there any other mechanisms for that?
>
> Having a delay is much safer for you but surely it's not a common
> practice that's best all other platforms such as two-channel cases
> and those who needs performance.
>
> I encourage you to try to follow one of patches I gave you that
> sets TDMAE/RDMAE at the beginning of the trigger(). Surely you may
> change it to TDMAE | SSIE after you find out that SSIE is indeed
> required. If you are still having trouble, adding a delay would
> be nice for you but it may be hard for me to ack it if you want
> to merge it in the driver.

I now I see your patch!  Okay, I'll give that a go, but it's still
just a race condition between the regmap_update_bits with TDMAE (your
patch) verses the regmap_update_bits from fsl_ssi_config. You're just
hoping that a DMA write happens between TDMAE and the end of
fsl_ssi_config where TE is enabled.

Now I think I get it though.  We do TMDAE + SSIEN like your patch,
then a short while loop on SFCSR.TFCNT0.  After the first word gets
written to the fifo, TFCNT0 should go > 0, and then we can release TE.

There may be a better status register to wait on but TFCNT0 seems like
it will do the trick.

What do you think of that solution?  Any better register to wait on?
Would that be acceptable to merge into the driver?

Thanks,
  -Caleb

>
> Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Thu, Oct 29, 2015 at 04:33:26PM -0700, Caleb Crome wrote:

> > A little difference between your point and mine is that you think
> > DMA request only starts when SSIE and TDMAE both get set while I
> > only think about TDMAE. It's hard to say which one is correct as
> > it depends on the design of IP wrapper but you can fairly test it
> > with your change below: Mask both TE with SSIE and set them after
> > the delay. If it doesn't work, yours is the correct one.
> 
> Ah, that's one thing that's very clear in the FSL datasheet:  the
> FIFOs are ZEROED if SSIE is 0.  This means that even if the DMA were
> trying to dump data in before SSIE is enabled, the data would go to
> bit heaven.
> 
> The docs for TE say, "The normal transmit enable sequence is to write
> data to the STX register(s) and then set the TE bit." (page 5145 of
> IMX6SDLRM.pdf)
> 
> So in the DMA + fifo case the words, "write data to the STX
> register(s)" imply that it's actually DMA writing to FIFOs, which then
> write the STX register.  So, the sequence must be:  enable SSIE &
> TDMAE to allow DMA to write to the fifo, then later enable TE, right?

You have the point. If SSIEN is being treated as the reset signal
internally, any write enable signal could be ignored.

> > I encourage you to try to follow one of patches I gave you that
> > sets TDMAE/RDMAE at the beginning of the trigger(). Surely you may
> > change it to TDMAE | SSIE after you find out that SSIE is indeed
> > required. If you are still having trouble, adding a delay would
> > be nice for you but it may be hard for me to ack it if you want
> > to merge it in the driver.
> 
> I now I see your patch!  Okay, I'll give that a go, but it's still
> just a race condition between the regmap_update_bits with TDMAE (your
> patch) verses the regmap_update_bits from fsl_ssi_config. You're just
> hoping that a DMA write happens between TDMAE and the end of
> fsl_ssi_config where TE is enabled.

DMA transaction will be issued once BD is ready (in SDMA driver)
and SSI sends a DMA request. So I'm hoping that the context
latency between the regmap_update_bits() and TE setting should be
enough for DMA to fill the FIFO.

> Now I think I get it though.  We do TMDAE + SSIEN like your patch,
> then a short while loop on SFCSR.TFCNT0.  After the first word gets
> written to the fifo, TFCNT0 should go > 0, and then we can release TE.
> 
> There may be a better status register to wait on but TFCNT0 seems like
> it will do the trick.

Waiting for TFCNT0 sounds reasonable to me as long as the code is
well commented.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[arnaud.mouiche]

Hi,

Le 30/10/2015 02:29, Nicolin Chen a écrit :
> On Thu, Oct 29, 2015 at 04:33:26PM -0700, Caleb Crome wrote:
>
>>> A little difference between your point and mine is that you think
>>> DMA request only starts when SSIE and TDMAE both get set while I
>>> only think about TDMAE. It's hard to say which one is correct as
>>> it depends on the design of IP wrapper but you can fairly test it
>>> with your change below: Mask both TE with SSIE and set them after
>>> the delay. If it doesn't work, yours is the correct one.
>> Ah, that's one thing that's very clear in the FSL datasheet:  the
>> FIFOs are ZEROED if SSIE is 0.  This means that even if the DMA were
>> trying to dump data in before SSIE is enabled, the data would go to
>> bit heaven.
>>
>> The docs for TE say, "The normal transmit enable sequence is to write
>> data to the STX register(s) and then set the TE bit." (page 5145 of
>> IMX6SDLRM.pdf)
>>
>> So in the DMA + fifo case the words, "write data to the STX
>> register(s)" imply that it's actually DMA writing to FIFOs, which then
>> write the STX register.  So, the sequence must be:  enable SSIE &
>> TDMAE to allow DMA to write to the fifo, then later enable TE, right?
> You have the point. If SSIEN is being treated as the reset signal
> internally, any write enable signal could be ignored.
>
>>> I encourage you to try to follow one of patches I gave you that
>>> sets TDMAE/RDMAE at the beginning of the trigger(). Surely you may
>>> change it to TDMAE | SSIE after you find out that SSIE is indeed
>>> required. If you are still having trouble, adding a delay would
>>> be nice for you but it may be hard for me to ack it if you want
>>> to merge it in the driver.
>> I now I see your patch!  Okay, I'll give that a go, but it's still
>> just a race condition between the regmap_update_bits with TDMAE (your
>> patch) verses the regmap_update_bits from fsl_ssi_config. You're just
>> hoping that a DMA write happens between TDMAE and the end of
>> fsl_ssi_config where TE is enabled.
> DMA transaction will be issued once BD is ready (in SDMA driver)
> and SSI sends a DMA request. So I'm hoping that the context
> latency between the regmap_update_bits() and TE setting should be
> enough for DMA to fill the FIFO.
>
>> Now I think I get it though.  We do TMDAE + SSIEN like your patch,
>> then a short while loop on SFCSR.TFCNT0.  After the first word gets
>> written to the fifo, TFCNT0 should go > 0, and then we can release TE.
>>
>> There may be a better status register to wait on but TFCNT0 seems like
>> it will do the trick.
> Waiting for TFCNT0 sounds reasonable to me as long as the code is
> well commented.

At imx50 age, I remember one workaround was to fill the fifo manually, 
writing directly a number of samples (equal to the number of slots for 
one frame to keep the synchronization), and then, enable the TMDAE.
This just allow to not have to wait an undefined period of time for the 
DMA to be ready.
But, on the other hand, if the time to wait the DMA is short enough, it 
should not be an issue.

Regards,
Arnaud

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[arnaud.mouiche]

Hi again,

Le 30/10/2015 09:29, arnaud.mouiche@invoxia.com a écrit :
> Hi,
>
> Le 30/10/2015 02:29, Nicolin Chen a écrit :
>> On Thu, Oct 29, 2015 at 04:33:26PM -0700, Caleb Crome wrote:
>>
>>>> A little difference between your point and mine is that you think
>>>> DMA request only starts when SSIE and TDMAE both get set while I
>>>> only think about TDMAE. It's hard to say which one is correct as
>>>> it depends on the design of IP wrapper but you can fairly test it
>>>> with your change below: Mask both TE with SSIE and set them after
>>>> the delay. If it doesn't work, yours is the correct one.
>>> Ah, that's one thing that's very clear in the FSL datasheet: the
>>> FIFOs are ZEROED if SSIE is 0.  This means that even if the DMA were
>>> trying to dump data in before SSIE is enabled, the data would go to
>>> bit heaven.
>>>
>>> The docs for TE say, "The normal transmit enable sequence is to write
>>> data to the STX register(s) and then set the TE bit." (page 5145 of
>>> IMX6SDLRM.pdf)
>>>
>>> So in the DMA + fifo case the words, "write data to the STX
>>> register(s)" imply that it's actually DMA writing to FIFOs, which then
>>> write the STX register.  So, the sequence must be:  enable SSIE &
>>> TDMAE to allow DMA to write to the fifo, then later enable TE, right?
>> You have the point. If SSIEN is being treated as the reset signal
>> internally, any write enable signal could be ignored.
>>
>>>> I encourage you to try to follow one of patches I gave you that
>>>> sets TDMAE/RDMAE at the beginning of the trigger(). Surely you may
>>>> change it to TDMAE | SSIE after you find out that SSIE is indeed
>>>> required. If you are still having trouble, adding a delay would
>>>> be nice for you but it may be hard for me to ack it if you want
>>>> to merge it in the driver.
>>> I now I see your patch!  Okay, I'll give that a go, but it's still
>>> just a race condition between the regmap_update_bits with TDMAE (your
>>> patch) verses the regmap_update_bits from fsl_ssi_config. You're just
>>> hoping that a DMA write happens between TDMAE and the end of
>>> fsl_ssi_config where TE is enabled.
>> DMA transaction will be issued once BD is ready (in SDMA driver)
>> and SSI sends a DMA request. So I'm hoping that the context
>> latency between the regmap_update_bits() and TE setting should be
>> enough for DMA to fill the FIFO.
>>
>>> Now I think I get it though.  We do TMDAE + SSIEN like your patch,
>>> then a short while loop on SFCSR.TFCNT0.  After the first word gets
>>> written to the fifo, TFCNT0 should go > 0, and then we can release TE.
>>>
>>> There may be a better status register to wait on but TFCNT0 seems like
>>> it will do the trick.
>> Waiting for TFCNT0 sounds reasonable to me as long as the code is
>> well commented.
>
> At imx50 age, I remember one workaround was to fill the fifo manually, 
> writing directly a number of samples (equal to the number of slots for 
> one frame to keep the synchronization), and then, enable the TMDAE.
> This just allow to not have to wait an undefined period of time for 
> the DMA to be ready.
> But, on the other hand, if the time to wait the DMA is short enough, 
> it should not be an issue.
>
> Regards,
> Arnaud
>
In the same idea, they were other similar issues to deal with concerning 
the RX and TX fifo.

1) Still some samples in the TX fifo when stoping/ re-starting the TX, 
while RX stream is going on.
Since we can't reset the TX fifo content without disabling SSIEN, 
possible samples filled by the TX DMA are still there when the TX stream 
stops. And when we start it again, they introduce a random 
de-synchronization of the output.
The workaround for this case was to add additional zero samples in the 
fifo manually to reach a multiple of the frame size.
But I would prefer a way to empty manually the fifo instead. If 
Freescale can help us to find another way as they know the internal of 
the SSI...

2) the same for RX fifo, if the RX stream is stopped/-restarted, while 
TX stream is not stopped.
We may still have some samples in the RX fifo, and those fifo must be 
removed before starting the RX again.
This was more simple in this case, since we only need to read the RX 
register manually until the fifo is empty, before enabling the DMA.

Obviously, disabling the SSIEN completely to start on good basis is not 
possible since we will lose a random number of samples already present 
in the fifo corresponding to the stream we don't want to stop, and this 
number of samples may not be a multiple of slots.

Arnaud

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

Add Shengjiu.

On Fri, Oct 30, 2015 at 09:45:32AM +0100, arnaud.mouiche@invoxia.com wrote:

> >At imx50 age, I remember one workaround was to fill the fifo
> >manually, writing directly a number of samples (equal to the
> >number of slots for one frame to keep the synchronization), and
> >then, enable the TMDAE.
> >This just allow to not have to wait an undefined period of time
> >for the DMA to be ready.
> >But, on the other hand, if the time to wait the DMA is short
> >enough, it should not be an issue.

> In the same idea, they were other similar issues to deal with
> concerning the RX and TX fifo.
> 
> 1) Still some samples in the TX fifo when stoping/ re-starting the
> TX, while RX stream is going on.
> Since we can't reset the TX fifo content without disabling SSIEN,
> possible samples filled by the TX DMA are still there when the TX
> stream stops. And when we start it again, they introduce a random
> de-synchronization of the output.
> The workaround for this case was to add additional zero samples in
> the fifo manually to reach a multiple of the frame size.
> But I would prefer a way to empty manually the fifo instead. If
> Freescale can help us to find another way as they know the internal
> of the SSI...
> 
> 2) the same for RX fifo, if the RX stream is stopped/-restarted,
> while TX stream is not stopped.
> We may still have some samples in the RX fifo, and those fifo must
> be removed before starting the RX again.
> This was more simple in this case, since we only need to read the RX
> register manually until the fifo is empty, before enabling the DMA.
> 
> Obviously, disabling the SSIEN completely to start on good basis is
> not possible since we will lose a random number of samples already
> present in the fifo corresponding to the stream we don't want to
> stop, and this number of samples may not be a multiple of slots.

You are right. Since SSI doesn't have separate FIFO reset bits
for TX and RX respectively. These could be issues.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Fri, Oct 30, 2015 at 09:29:02AM +0100, arnaud.mouiche@invoxia.com wrote:

> At imx50 age, I remember one workaround was to fill the fifo
> manually, writing directly a number of samples (equal to the number
> of slots for one frame to keep the synchronization), and then,
> enable the TMDAE.
> This just allow to not have to wait an undefined period of time for
> the DMA to be ready.
> But, on the other hand, if the time to wait the DMA is short enough,
> it should not be an issue.

Nice input. This reminds me of the zero-filling step inside the
ESAI startup procedure:

	case SNDRV_PCM_TRIGGER_START:
	case SNDRV_PCM_TRIGGER_RESUME:
	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
		regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
				   ESAI_xFCR_xFEN_MASK, ESAI_xFCR_xFEN);

		/* Write initial words reqiured by ESAI as normal procedure */
		for (i = 0; tx && i < channels; i++)
			regmap_write(esai_priv->regmap, REG_ESAI_ETDR, 0x0);

		regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
				   tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
				   tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
		break;

It's exactly the same thing to prevent underrun. This might be
a reasonable alternative option due to no polling overhead and
timeout handling.

Thanks
Nicolin

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Fri, Oct 30, 2015 at 8:49 AM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Fri, Oct 30, 2015 at 09:29:02AM +0100, arnaud.mouiche@invoxia.com wrote:
>
>> At imx50 age, I remember one workaround was to fill the fifo
>> manually, writing directly a number of samples (equal to the number
>> of slots for one frame to keep the synchronization), and then,
>> enable the TMDAE.
>> This just allow to not have to wait an undefined period of time for
>> the DMA to be ready.
>> But, on the other hand, if the time to wait the DMA is short enough,
>> it should not be an issue.
>
> Nice input. This reminds me of the zero-filling step inside the
> ESAI startup procedure:
>
>         case SNDRV_PCM_TRIGGER_START:
>         case SNDRV_PCM_TRIGGER_RESUME:
>         case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>                 regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
>                                    ESAI_xFCR_xFEN_MASK, ESAI_xFCR_xFEN);
>
>                 /* Write initial words reqiured by ESAI as normal procedure */
>                 for (i = 0; tx && i < channels; i++)
>                         regmap_write(esai_priv->regmap, REG_ESAI_ETDR, 0x0);
>
>                 regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
>                                    tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
>                                    tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
>                 break;
>
> It's exactly the same thing to prevent underrun. This might be
> a reasonable alternative option due to no polling overhead and
> timeout handling.
>
> Thanks
> Nicolin

Interesting, but in the SSI case, the # channels can easily be larger
than the fifo size.  For example, I'm using 16 channels, and the fifo
size is only 15.  Of course, with the dual fifo enabled, then this
restriction is eased to a maximum # of slots of 30.

I'll do a quick check this morning with Nicolin's suggested patch, and
see how many loops it needs to poll before the fifo gets a word.  My
suspicion is that Nicolin's hunch is correct: that is,  that the
context switch provides enough time for the DMA to push a word.

Will check back shortly.

Then, we'll have the problem that Arnaud bring up -- when starting the
Rx after Tx, we will have fresh new problems.  In fact, I'm 100% sure
we will -- I already see it with a portaudio program that must bring
up tx and rx separately.  I think I'll start a new thread for that
problem once this one is put to bed.

-Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 6:29 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Thu, Oct 29, 2015 at 04:33:26PM -0700, Caleb Crome wrote:
>
>> > A little difference between your point and mine is that you think
>> > DMA request only starts when SSIE and TDMAE both get set while I
>> > only think about TDMAE. It's hard to say which one is correct as
>> > it depends on the design of IP wrapper but you can fairly test it
>> > with your change below: Mask both TE with SSIE and set them after
>> > the delay. If it doesn't work, yours is the correct one.
>>
>> Ah, that's one thing that's very clear in the FSL datasheet:  the
>> FIFOs are ZEROED if SSIE is 0.  This means that even if the DMA were
>> trying to dump data in before SSIE is enabled, the data would go to
>> bit heaven.
>>
>> The docs for TE say, "The normal transmit enable sequence is to write
>> data to the STX register(s) and then set the TE bit." (page 5145 of
>> IMX6SDLRM.pdf)
>>
>> So in the DMA + fifo case the words, "write data to the STX
>> register(s)" imply that it's actually DMA writing to FIFOs, which then
>> write the STX register.  So, the sequence must be:  enable SSIE &
>> TDMAE to allow DMA to write to the fifo, then later enable TE, right?
>
> You have the point. If SSIEN is being treated as the reset signal
> internally, any write enable signal could be ignored.
>
>> > I encourage you to try to follow one of patches I gave you that
>> > sets TDMAE/RDMAE at the beginning of the trigger(). Surely you may
>> > change it to TDMAE | SSIE after you find out that SSIE is indeed
>> > required. If you are still having trouble, adding a delay would
>> > be nice for you but it may be hard for me to ack it if you want
>> > to merge it in the driver.
>>
>> I now I see your patch!  Okay, I'll give that a go, but it's still
>> just a race condition between the regmap_update_bits with TDMAE (your
>> patch) verses the regmap_update_bits from fsl_ssi_config. You're just
>> hoping that a DMA write happens between TDMAE and the end of
>> fsl_ssi_config where TE is enabled.
>
> DMA transaction will be issued once BD is ready (in SDMA driver)
> and SSI sends a DMA request. So I'm hoping that the context
> latency between the regmap_update_bits() and TE setting should be
> enough for DMA to fill the FIFO.
>
>> Now I think I get it though.  We do TMDAE + SSIEN like your patch,
>> then a short while loop on SFCSR.TFCNT0.  After the first word gets
>> written to the fifo, TFCNT0 should go > 0, and then we can release TE.
>>
>> There may be a better status register to wait on but TFCNT0 seems like
>> it will do the trick.
>
> Waiting for TFCNT0 sounds reasonable to me as long as the code is
> well commented.

Okay, so I tried out your patch and it has 2 separate issues:  the
first related to missing samples (even when I enabled the SSIEN), and
the second relating to the dual fifo.
So, first the missing samples.

**********************
** Problem 1 *******
**********************
When I enable your patch in single fifo mode we get maxburst lost
samples at the beginning of the stream.  The important bit is below.
It doesn't matter if the SSIEN comes before or after the TDMAE, the
samples are lost.  Surely because something in the fsl_ssi_config
clears the fifo.  I didn't look into that yet.
--------------------------- snip -------------------
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 73778c2..9d414e8 100644
@@ -1039,6 +1070,20 @@ static int fsl_ssi_trigger(struct
snd_pcm_substream *substream, int cmd,
     case SNDRV_PCM_TRIGGER_START:
     case SNDRV_PCM_TRIGGER_RESUME:
     case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+        /* eanble SSI */
+        regmap_update_bits(regs, CCSR_SSI_SCR,
+                   CCSR_SSI_SCR_SSIEN,
+                   CCSR_SSI_SCR_SSIEN);
+        /* and enable DMA to start data pumping */
+        if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+            regmap_update_bits(regs, CCSR_SSI_SIER,
+                       CCSR_SSI_SIER_TDMAE,
+                       CCSR_SSI_SIER_TDMAE);
+        else
+            regmap_update_bits(regs, CCSR_SSI_SIER,
+                       CCSR_SSI_SIER_RDMAE,
+                       CCSR_SSI_SIER_RDMAE);
+
         if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
             fsl_ssi_tx_config(ssi_private, true);
         else

--------------------------- snip -------------------

If instead, I do the SSIEN at the bottom of the fsl_ssi_configure
function like this, it works perfectly (in single fifo mode)

--------------------------- snip -------------------
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -435,8 +435,49 @@ static void fsl_ssi_config(struct fsl_ssi_private
*ssi_private, bool enable,

 config_done:
     /* Enabling of subunits is done after configuration */
-    if (enable)
+    if (enable) {
+        /* eanble SSI */
+        regmap_update_bits(regs, CCSR_SSI_SCR,
+                   CCSR_SSI_SCR_SSIEN,
+                   CCSR_SSI_SCR_SSIEN);
+        /*
+         * We must wait here until the DMA actually manages to
+         * get a word into the Tx FIFO.  Only if starting a Tx
+         * stream.
+         * In tests on an MX6 at 1GHz clock speed, the do
+         * loop below never iterated at all (i.e. it dropped
+         * through without repeating ever.  which means that
+         * the DMA has had time to get some words into the TX
+         * buffer. In fact, the tfcnt0 was always 13, so it
+         * was quite full by the time it reached this point,
+         * so this do loop should never be a bottleneck.  If
+         * max iterations is hit, then something might be
+         * wrong.  report it in that case.
+         */
+        int tfcnt0 = 0;
+        int tfcnt1 = 1;
+        int max_iterations = 1000;
+        if (vals->scr & CCSR_SSI_SCR_TE) {
+            u32 sfcsr;
+            do {
+                regmap_read(regs, CCSR_SSI_SFCSR, &sfcsr);
+                tfcnt0 = CCSR_SSI_SFCSR_TFCNT0(sfcsr);
+                tfcnt1 = CCSR_SSI_SFCSR_TFCNT0(sfcsr);
+            } while(max_iterations-- && (tfcnt0 == 0) && (tfcnt1 == 0));
+        }
+        if (max_iterations <= 0) {
+            /*
+             * The DMA definitely should have stuck at
+             * least a word into the FIFO by now.  Report
+             * an error, but continue on blindly anyway,
+             * even though the SSI might not start right.
+             */
+            struct platform_device *pdev = ssi_private->pdev;
+            dev_err(&pdev->dev, "max_iterations reached when"
+                "starting SSI Tx\n");
+        }
         regmap_update_bits(regs, CCSR_SSI_SCR, vals->scr, vals->scr);
+    }
 }
--------------------------- snip -------------------

When all is fixed, the data comes in perfect order:
(most significant nibble is channel # from wav file, least significant
12 bits are frame number).
(hope that lines don't wrap at 79 characters...)
0000,1000,2000,3000,4000,5000,6000,7000,8000,9000,a000,b000,c000,d000,e000,f000
0001,1001,2001,3001,4001,5001,6001,7001,8001,9001,a001,b001,c001,d001,e001,f001
0002,1002,2002,3002,4002,5002,6002,7002,8002,9002,a002,b002,c002,d002,e002,f002
0003,1003,2003,3003,4003,5003,6003,7003,8003,9003,a003,b003,c003,d003,e003,f003
...
00fd,10fd,20fd,30fd,40fd,50fd,60fd,70fd,80fd,90fd,a0fd,b0fd,c0fd,d0fd,e0fd,f0fd
00fe,10fe,20fe,30fe,40fe,50fe,60fe,70fe,80fe,90fe,a0fe,b0fe,c0fe,d0fe,e0fe,f0fe
00ff,10ff,20ff,30ff,40ff,50ff,60ff,70ff,80ff,90ff,a0ff,b0ff,c0ff,d0ff,e0ff,f0ff
and all zeros after that.

FYI, this is a 256 frame, 16 channel sound file for doing this test.

**********************
** Problem 2 *******
**********************
When the dual fifo mode is enabled, the data comes in the following order:
0000,1000,2000,3000,4000,5000,6000,7000,8000,9000,a000,b000,c000,d000,e000,f000
0001,1001,2001,3001,4001,5001,6001,7001,8001,9001,a001,b001,c001,d001,e001,1002
0002,3002,2002,5002,4002,7002,6002,9002,8002,b002,a002,d002,c002,f002,e002,1003
0003,3003,2003,5003,4003,7003,6003,9003,8003,b003,a003,d003,c003,f003,e003,1004

Strange, right?  Frame 0 is perfect, however after the first frame,
the data gets scrambled and from then on is wrong.
The pattern stays consistent after frame 2.


Looks like I need to stick with single fifo for now.

So, bottom line is:  single fifo seems to work perfectly with my
proposed fix above.  Dual fifo doesn't seem to work.

-caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Fri, Oct 30, 2015 at 3:04 PM, Caleb Crome <caleb@crome.org> wrote:
> On Thu, Oct 29, 2015 at 6:29 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>> On Thu, Oct 29, 2015 at 04:33:26PM -0700, Caleb Crome wrote:
>>
>> Waiting for TFCNT0 sounds reasonable to me as long as the code is
>> well commented.
>
> Okay, so I tried out your patch and it has 2 separate issues:  the
> first related to missing samples (even when I enabled the SSIEN), and
> the second relating to the dual fifo.
> So, first the missing samples.
>
>
> **********************
> ** Problem 2 *******
> **********************
> When the dual fifo mode is enabled, the data comes in the following order:
> 0000,1000,2000,3000,4000,5000,6000,7000,8000,9000,a000,b000,c000,d000,e000,f000
> 0001,1001,2001,3001,4001,5001,6001,7001,8001,9001,a001,b001,c001,d001,e001,1002
> 0002,3002,2002,5002,4002,7002,6002,9002,8002,b002,a002,d002,c002,f002,e002,1003
> 0003,3003,2003,5003,4003,7003,6003,9003,8003,b003,a003,d003,c003,f003,e003,1004
>
> Strange, right?  Frame 0 is perfect, however after the first frame,
> the data gets scrambled and from then on is wrong.
> The pattern stays consistent after frame 2.
>
>
> Looks like I need to stick with single fifo for now.
>
> So, bottom line is:  single fifo seems to work perfectly with my
> proposed fix above.  Dual fifo doesn't seem to work.
>

I realized the problem with the dual fifo mode:  it's that you had set
the maxburst to 16 in your patch.  I guess this must be the maxburst
to a single fifo maybe?  When I set the fual fifo maxburst back to 8,
I get perfection again!

So, now bottom line is:  both single and dual ffio modes work :-)

So, with this patch (I'll send separately as a proper patch), Tx will
work perfectly.

Next thing to tackle is:  doing starts/stops on Tx/Rx in different orders:

So far, I've only verified:
TxStart - TxEnd

Next is:
RxStart - RxEnd

And the combinations:
TxStart - RxStart - TxEnd - RxEnd
TxStart - RxStart - RxEnd - TxEnd
RxStart - TxStart - RxEnd - TxEnd
RxStart - TxStart - TxEnd - RxEnd

Maybe the rest won't be as difficult :-/


> -caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Fri, Oct 30, 2015 at 03:35:17PM -0700, Caleb Crome wrote:

> > **********************
> > ** Problem 2 *******
> > **********************

> I realized the problem with the dual fifo mode:  it's that you had set
> the maxburst to 16 in your patch.  I guess this must be the maxburst
> to a single fifo maybe?  When I set the fual fifo maxburst back to 8,
> I get perfection again!

I actually set 16 for dual FIFO and tested with 2-channel playback.
Since you have dual FIFO right now, burst 8 doesn't hurt a lot as
SPBA should be a pretty dedicated bus from SDMA point of view. As
long as you don't have too many SPBA modules working with SDMA. It
should work for you.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Fri, Oct 30, 2015 at 6:32 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Fri, Oct 30, 2015 at 03:35:17PM -0700, Caleb Crome wrote:
>
>> > **********************
>> > ** Problem 2 *******
>> > **********************
>
>> I realized the problem with the dual fifo mode:  it's that you had set
>> the maxburst to 16 in your patch.  I guess this must be the maxburst
>> to a single fifo maybe?  When I set the fual fifo maxburst back to 8,
>> I get perfection again!
>
> I actually set 16 for dual FIFO and tested with 2-channel playback.
> Since you have dual FIFO right now, burst 8 doesn't hurt a lot as
> SPBA should be a pretty dedicated bus from SDMA point of view. As
> long as you don't have too many SPBA modules working with SDMA. It
> should work for you.

But did check for bit perfect playback from start to end of your file?
 Or simply that it sounded right?  it appears that with maxburst=16,
after about 30 samples, the data plays out without further slipping.
This would appear 'working' without careful analysis because it could
slip an even number of samples and each channel would end up in the
right slot after a few frames.  maxbust=16 *definitely* does not work
for me.

-Caleb


> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Fri, Oct 30, 2015 at 03:04:37PM -0700, Caleb Crome wrote:
 
> **********************
> ** Problem 1 *******
> **********************
> When I enable your patch in single fifo mode we get maxburst lost
> samples at the beginning of the stream.  The important bit is below.
> It doesn't matter if the SSIEN comes before or after the TDMAE, the
> samples are lost.  Surely because something in the fsl_ssi_config
> clears the fifo.  I didn't look into that yet.

The config function has gone way complicated than I realized.
But you may need to dig a little bit to make a perfect point
to insert your change as it might break other platforms: AC97
and old i.MX and MPC.

> --------------------------- snip -------------------
> 
> If instead, I do the SSIEN at the bottom of the fsl_ssi_configure
> function like this, it works perfectly (in single fifo mode)
> 
> --------------------------- snip -------------------
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -435,8 +435,49 @@ static void fsl_ssi_config(struct fsl_ssi_private
> *ssi_private, bool enable,
> 
>  config_done:
>      /* Enabling of subunits is done after configuration */
> -    if (enable)
> +    if (enable) {
> +        /* eanble SSI */
> +        regmap_update_bits(regs, CCSR_SSI_SCR,
> +                   CCSR_SSI_SCR_SSIEN,
> +                   CCSR_SSI_SCR_SSIEN);
> +        /*
> +         * We must wait here until the DMA actually manages to
> +         * get a word into the Tx FIFO.  Only if starting a Tx
> +         * stream.
> +         * In tests on an MX6 at 1GHz clock speed, the do
> +         * loop below never iterated at all (i.e. it dropped
> +         * through without repeating ever.  which means that
> +         * the DMA has had time to get some words into the TX
> +         * buffer. In fact, the tfcnt0 was always 13, so it
> +         * was quite full by the time it reached this point,
> +         * so this do loop should never be a bottleneck.  If
> +         * max iterations is hit, then something might be
> +         * wrong.  report it in that case.
> +         */
> +        int tfcnt0 = 0;
> +        int tfcnt1 = 1;
> +        int max_iterations = 1000;
> +        if (vals->scr & CCSR_SSI_SCR_TE) {
> +            u32 sfcsr;
> +            do {
> +                regmap_read(regs, CCSR_SSI_SFCSR, &sfcsr);
> +                tfcnt0 = CCSR_SSI_SFCSR_TFCNT0(sfcsr);
> +                tfcnt1 = CCSR_SSI_SFCSR_TFCNT0(sfcsr);
> +            } while(max_iterations-- && (tfcnt0 == 0) && (tfcnt1 == 0));
> +        }
> +        if (max_iterations <= 0) {
> +            /*
> +             * The DMA definitely should have stuck at
> +             * least a word into the FIFO by now.  Report
> +             * an error, but continue on blindly anyway,
> +             * even though the SSI might not start right.
> +             */
> +            struct platform_device *pdev = ssi_private->pdev;
> +            dev_err(&pdev->dev, "max_iterations reached when"
> +                "starting SSI Tx\n");
> +        }

Looks like polling is the only way to safely kick off. It's okay.
But I would like to see how the change will be after merging the
simultaneous TE/RE work around. It may need go a long way with
other platform users.

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Fri, Oct 30, 2015 at 6:48 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> On Fri, Oct 30, 2015 at 03:04:37PM -0700, Caleb Crome wrote:
>
>> **********************
>> ** Problem 1 *******
>> **********************
>> When I enable your patch in single fifo mode we get maxburst lost
>> samples at the beginning of the stream.  The important bit is below.
>> It doesn't matter if the SSIEN comes before or after the TDMAE, the
>> samples are lost.  Surely because something in the fsl_ssi_config
>> clears the fifo.  I didn't look into that yet.
>
> The config function has gone way complicated than I realized.

I know!  It's quite complex and has taken me some time to pretty much
understand.

> But you may need to dig a little bit to make a perfect point
> to insert your change as it might break other platforms: AC97
> and old i.MX and MPC.

The simple change to first enable SSIE, then TX should not cause any
issues I think.  The current code enables TE and SSIE at the same
time, which is clearly against what the datasheet says to do.  I
believe the end of the fsl_ssi_config file in fact is the right place
to do it, regardless of platform or format.  (As long as the fifo &
dima are enabled).

>



>> --------------------------- snip -------------------
>>
>> If instead, I do the SSIEN at the bottom of the fsl_ssi_configure
>> function like this, it works perfectly (in single fifo mode)
>>
>> --------------------------- snip -------------------
>> +++ b/sound/soc/fsl/fsl_ssi.c
>> @@ -435,8 +435,49 @@ static void fsl_ssi_config(struct fsl_ssi_private
>> *ssi_private, bool enable,
>>
>>  config_done:
>>      /* Enabling of subunits is done after configuration */
>> -    if (enable)
>> +    if (enable) {
>> +        /* eanble SSI */
>> +        regmap_update_bits(regs, CCSR_SSI_SCR,
>> +                   CCSR_SSI_SCR_SSIEN,
>> +                   CCSR_SSI_SCR_SSIEN);
>> +        /*
>> +         * We must wait here until the DMA actually manages to
>> +         * get a word into the Tx FIFO.  Only if starting a Tx
>> +         * stream.
>> +         * In tests on an MX6 at 1GHz clock speed, the do
>> +         * loop below never iterated at all (i.e. it dropped
>> +         * through without repeating ever.  which means that
>> +         * the DMA has had time to get some words into the TX
>> +         * buffer. In fact, the tfcnt0 was always 13, so it
>> +         * was quite full by the time it reached this point,
>> +         * so this do loop should never be a bottleneck.  If
>> +         * max iterations is hit, then something might be
>> +         * wrong.  report it in that case.
>> +         */
>> +        int tfcnt0 = 0;
>> +        int tfcnt1 = 1;
>> +        int max_iterations = 1000;
>> +        if (vals->scr & CCSR_SSI_SCR_TE) {
>> +            u32 sfcsr;
>> +            do {
>> +                regmap_read(regs, CCSR_SSI_SFCSR, &sfcsr);
>> +                tfcnt0 = CCSR_SSI_SFCSR_TFCNT0(sfcsr);
>> +                tfcnt1 = CCSR_SSI_SFCSR_TFCNT0(sfcsr);
>> +            } while(max_iterations-- && (tfcnt0 == 0) && (tfcnt1 == 0));
>> +        }
>> +        if (max_iterations <= 0) {
>> +            /*
>> +             * The DMA definitely should have stuck at
>> +             * least a word into the FIFO by now.  Report
>> +             * an error, but continue on blindly anyway,
>> +             * even though the SSI might not start right.
>> +             */
>> +            struct platform_device *pdev = ssi_private->pdev;
>> +            dev_err(&pdev->dev, "max_iterations reached when"
>> +                "starting SSI Tx\n");
>> +        }
>
> Looks like polling is the only way to safely kick off. It's okay.

'polling' is a strong word because it never actually loops :-)
Perhaps 'checking' is a better word.

> But I would like to see how the change will be after merging the
> simultaneous TE/RE work around.

I'm not sure I understand this statement.  What's the simultaneous
TE/RE work around?  It appears that the trigger function *only* does
either one or the other, and not simultaneously. Is there a patch in
the works to make tx/rx happen simultaneously?

-Caleb

Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen]

On Sat, Oct 31, 2015 at 09:22:54AM -0700, Caleb Crome wrote:
 
> > But I would like to see how the change will be after merging the
> > simultaneous TE/RE work around.
> 
> I'm not sure I understand this statement.  What's the simultaneous
> TE/RE work around?  It appears that the trigger function *only* does
> either one or the other, and not simultaneously. Is there a patch in
> the works to make tx/rx happen simultaneously?

I mean those problems Arnaud mentioned.