Le 20/10/2015 19:43, Caleb Crome a écrit :
On Tue, Oct 20, 2015 at 12:36 AM, arnaud.mouiche@invoxia.com arnaud.mouiche@invoxia.com 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@freescale.com 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@freescale.com>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