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