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@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. Cc Nicolin, Fabio, Shawn Perhaps you have an idea about this? Regards, Markus > > -Caleb > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
