AnsweredAssumed Answered

Hang in sDMA driver on Linux

Question asked by Matt Campbell on Feb 10, 2016
Latest reply on May 15, 2019 by Paul Katarzis

We are working on a custom design using the iMX6 solo lite that is based off the MCIMX6SLEVK. Our kernel is based off the Freescale 3.14.52_1.0.0ga release. We have an application we are developing using ALSA for audio that is encountering serious issues with hangs that seem to originate in the sDMA driver. When there is an audio under/over flow the sDMA driver enters enters an unrecoverable error state. When examining the driver (drivers/dma/imx-sdma.c) it is unclear to us how the driver could detect error conditions in the sDMA processor/scripts/etc.


It looks like the DMA Request Error Register (SDMAARM_EVTERR) is the mechanism for the sDMA processor to report errors to the ARM core, yet this register is never accessed from the sDMA driver. By manually reading this register we can verify that an error condition for our channel (SSI2) is waiting to be read indicating this was never read by the driver as this register read-to-clear. Additionally, the sDMA driver in Linux is in an inconsistent state where it believes the DMA is in progress (sdmac->status == DMA_IN_PROGRESS), however the SDMA processor has reported an error, and the SDMA script running on the SDMA channel has halted and no further sDMA interrupts are received by the kernel.


The user-facing manifestation of this problem is a permanent audio dropout, followed by occasional messages from ALSA: "capture write error (DMA or IRQ trouble?)".


Strangely when we check the buffer descriptors there is no error reported in error bit. However we cannot investigate this any further as the sDMA scripts and firmware are closed-source. We would appreciate some direction or advice on how how to debug our initial problem and any insight into the architecture of the sDMA driver that may be missing.


One final node, we saw similar behavior on the iMX6 quad (SabreSD board) with SGTL5000 codec.