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