Le 20/10/2015 19:43, Caleb Crome a écrit :
On Tue, Oct 20, 2015 at 12:36 AM, arnaud.mouiche@xxxxxxxxxxx
<arnaud.mouiche@xxxxxxxxxxx> wrote:
Hello Caleb,
I go through all [few] patchs we apply to the 4.0 linux tree (didn't jump to
4.2 yet).
There is one concerning the DMA firmware you can find in the freescale tree,
available at git://git.freescale.com/imx/linux-2.6-imx.git
commit 619bfca89908b90cd6606ed894c180df0c481508
Author: Shawn Guo <shawn.guo@xxxxxxxxxxxxx>
Date: Tue Jul 16 22:53:18 2013 +0800
ENGR00269945: firwmare: imx: add imx6q sdma script
Add imx6q sdma script which will be used by all i.MX6 series.
Signed-off-by: Shawn Guo <shawn.guo@xxxxxxxxxxxxx>
firmware/Makefile | 1 +
firmware/imx/sdma/sdma-imx6q.bin.ihex | 116
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 117 insertions(+)
I don't know how 4.3rcN catch some of the freescale patch. but you may check
if you need to apply this one.
I know there are some other SDMA firmware available all around in this
freescale tree. I didn't find proper release note or documentation. May be
you can test them also.
Arnaud
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.
- 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)
Regards,
Arnaud
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
