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

[Nicolin Chen <nicoleotsuka@gmail.com>]

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