On Wed, Oct 21, 2015 at 12:37 PM, Caleb Crome <caleb@xxxxxxxxx> wrote: > On Wed, Oct 21, 2015 at 12:32 AM, arnaud.mouiche@xxxxxxxxxxx > <arnaud.mouiche@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
