Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Markus Pargmann <mpa@pengutronix.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3479 bytes --]

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

-- 
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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]