[alsa-devel] 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 at crome.org> wrote:
> On Wed, Oct 21, 2015 at 12:32 AM, arnaud.mouiche at invoxia.com
> <arnaud.mouiche at 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