AnsweredAssumed Answered

i.mx28 No DMA PCM interrupts for SAIF1

Question asked by Matt Hevern on Mar 22, 2015
Latest reply on Jun 21, 2016 by Felipe Tonello
Branched to a new discussion

We are having an occasional and difficult to reproduce issue on i.mx28 and audio.

We have a custom board and identical connections to SGTL5000. We have SAIF0 setup as

playback and SAIF1 as capture.

What seems to happen is after some random (and usually large) number of attemtps to use 'arecord' for example,

the arecord will freeze and there will only be a 44 byte header file written to a file.

The only way we have found to use the capture again is to reboot.

Dumping /proc/interrupts at this time we can see that there are no 'MXS PCM DMA' interrupts

being generated.

Dumping the SAIF registers at this time shows that.

0x80046000: 0x00000806 (SAIF_CTRL)

0x80046010: 0x80010060 (SAIF_STAT)

0x80046020: 0x00000000 (SAIF_DATA)

0x80046030: 0x01010000 (SAIF_VERSION)



The SAIF_CTRL register shows that the RUN bit clear, and SAIF_STAT shows that




We are running based off freescales 2.6.35 git tree

Although we have excluded the 3 SAIF patches previous to the most recent commit, because

we (thought) we found at some point they were causing noise issues for us.

90ce77d ENGR00285446-3 [MX28] SAIF: Bit Shift in SAIF RX Data

1ea685a ENGR00285446-2 [MX28] SAIF: Bit Shift in SAIF RX Data

1ca8992 ENGR00285446-1 [MX28] SAIF: Bit Shift in SAIF RX Data



We also have 1 extra patch from Peter Chan, see

Although it seems that the the sound/soc/mxs/mxs-pcm.c related changes in this

patch weren't applied. This includes a 'mxs_dma_reset' for the dma channel on


Note that in the freescale 2.6.35 git tree mentioned above, this 'mxs_dma_reset' call

isn't present either, and I'm not sure if it should be ?


There seem have some similar issues reported in the past



There is a patch provided on the forum from Peter Chan which addresses an issue which could be similar to what we are seeing

I can see this patch in the git tree

08f0ca6 ENGR40464722-2 MX28 ALSA: enable the SAIF by toggle the RUN bit

This comment in the patch sounds very similar to what we are seeing:

"The origin method to trigger the SAIF may leads to the DMA hang after runs for 10000 loops of "gplay x.mp4".


However later on this patch is backed out

135155e ENGR00241779: Revert "ENGR40464722 ALSA: enable the SAIF by toggle the RUN bit"

With the comment that "The toggle method could not be applied to mx28evk board, because it use

saif->mclk as mclk of external codec:sgtl5000, saif->mclk is available only when run bit setting"


Does this mean that the basic issue still exists ?


Note that an aplay using the playback device (SAIF0) still works fine when the SAIF1 port

has entered this state.

As far as I can see things seem to be pointing towards some sort of problem related to DMA, does anyone

have any further ideas or suggestions on this ?