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
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
FIFI_OVERFLOW_IRQ, FIFO_UNDERFLOW_IRQ, DMA_PREQ are all set.
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 ?