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
FIFI_OVERFLOW_IRQ, FIFO_UNDERFLOW_IRQ, DMA_PREQ are all set.
We are running based off freescales 2.6.35 git tree
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain
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
https://community.freescale.com/thread/307611#331003
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
mxs_pcm_close.
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
https://community.freescale.com/message/311756
There is a patch provided on the forum from Peter Chan which addresses an issue which could be similar to what we are seeing
https://community.freescale.com/thread/300291
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 ?
Hi,
I have a similar problem on kernel 4.4 vanilla. A pcm device hangs after some operations to the DMA by plugin and unplugin the USB to a host, for example.
Any information on it?
hi
anyone found a solution for playback DMA hang problem we have this also we are using kernel 2.6.35
thanks
Please revert the patch at https://community.freescale.com/thread/307611#331003 and https://community.freescale.com/thread/300291
and then re-apply
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
The ENGR00285446 patches are the proper solution to resolve the SAIF1 recording issue,
If the noise issues still persists, could you please describe the reproducing steps so that we can follow?
ENGR00285446 DO fix recording issue,but still NOT fix playback "DMA hang" issue.
very big trouble for me now,base on mx28evk hardware,
saif->mclk as mclk of external codec,cant use toggle method...
i have to restart system when sound playback failed,that is too bad.
need help about this issue.
Thanks for this clarification.
Unfortunately I don't have access to the particular hardware any more so I will be unable to attempt to reproduce the issue.