Is the DMA channel dead?

[CraigMcQueen]

I'm trying out the Freescale Linux kernel imx_2.6.35_maintain branch on i.MX28. I'm seeing a message pop up in the debug console each time I terminate audio recording using arecord:

Is the DMA channel dead?

Any idea why this message is occurring?

[YixingKong]

Craig

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

[CraigMcQueen]

The issue has not been resolved. I already showed the message in the console in my original message. The message that appears is:

Is the DMA channel dead?

This occurs after one of the audio-related Freescale patches. I'd have to re-investigate to see which one. Anyway, I would like to know if anyone else can observe this message appearing every time audio recording stops. It seems to be related to git commit 3ee818d7bc "ENGR40464722-1 MX28 ALSA: wait until the DMA channel finishs".

[leige-b42127]

how did you terminate arecord? 'ctrl +c' or time set for arecord is up?

[CraigMcQueen]

Ctrl-C

[leige-b42127]

if don't use ctrl +c, use '-d x' command, is this issue still  exist?

[CraigMcQueen]

if don't use ctrl +c, use '-d x' command, is this issue still  exist?

Yes.

# arecord -r 32000 -d 10 /tmp/test.wav

Recording WAVE '/tmp/test.wav' : Unsigned 8 bit, Rate 32000 Hz, Mono

Is the DMA channel dead?

[PeterChan · Accepted solution]

Hello Craig,

Does this problem always reproducible?

I tried about above steps and use 'Ctrl + C' to abort the arecord, I only see the message 'Aborted by signal Interrupt...'. My testing is based on clean BSP L2.6.35_1.1.0_130130 + attached 4 patches related to SAIF.

If you are NOT using L2.6.35_1.1.0_130130 and have applied the ENGR40464722 fixes before, you need to revert the change in "ENGR4046722-2 MX28 ALSA: enable the SAIF by toggle the RUN bit". The ENGR4046722-2 change introduced another audio issue and was reverted in L2.6.35_1.1.0_130130.

If the problem still persists, please let me know your BSP code base and the occurrence rate.

Thanks,

Peter

[CraigMcQueen]

We are trying to use the Freescale linux-2.6-mx git repository, branch imx_2.6.35_maintain, but excluding the patches:

• 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 issue is always reproducible. It seems to be related to git commit 3ee818d7bc "ENGR40464722-1 MX28 ALSA: wait until the DMA channel finishs".

[PeterChan]

Hello Craig,

Even if using the branch imx_2.6.35_maintain and excluding the 3 patches, I do not see any "Is the DMA channel dead" message when I abort the arecord by "Ctrl + C".

My both alsa-lib and alsa-utils comes from L2.6.35_1.1.0_130130 and their versions are 1.0.24.1 and 1.0.24.2 respectively.

After this warning message, are you able to start another arecord again?

During arecord, The user abort "Ctrl+C" is handled by signal_handler() at alsa-utils-1.0.24.2/aplay.c. mxs_pcm_close() at linux/sound/soc/mxs/mxs-pcm.c will eventually called which wait for 200 ms for the current DMA chain to complete before releasing the DMA channel. Please try to use a longer delay (larger timeo value) to see if you can get rid of the warning message.

Thanks,

Peter

[matthevern]

Hi Peter,

I had a query about a patch you provided previously for resetting SAIF1 due to recording noise.

SGTL5000 CODEC line-in noise on i.MX28

We have applied the patch except the changes to the file sound/soc/mxs/mxs-pcm.c, which remove the 'Wait untill DMA chain is finished', and reporting of the message 'Is the DMA channel dead', and it also adds a 'mxs_dma_reset' to the mxs_pmc_close call.

This patch doesn't seem to be in the freescale 2.6.35 maintain tree: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain

and I'm wondering if it should be applied or does fix some specific issue ?

In sound/soc/mxs/mxs-dai.c

In the case of S"NDRV_PCM_TRIGGER_PAUSE_PUSH", if the stream is the capture stream then the SAIF 'RUN' bit is cleared. Is this valid behaviour ?

We are finding that at some point our SAIF1 interface halts with the RUN bit cleared, and no DMA interrupts being generated, and I was wondering if

it might be related to this ?

Also, in mxs_saif_probe, there are a series of kind of strange reset behaviour applied to the SAIF ports where

there is a series of repetitive block and clock gate reset CLEAR and SETS applied to the SAIF port, finally setting the RUN bit.

This also doesn't seem to be in the freescale git tree, and I'm wondering if there is a specific issue they are there to address ?

The sound/soc/mxs/mxs-pcm.c file has a mxs_dma_reset applied at the end of of 'mxs_pcm_close'

This behaviour isn't present in the git tree either, having been removed by the commit

3ee818d ENGR40464722-1 MX28 ALSA: wait until the DMA channel finishs

The comment in this commit mentions that resetting the DMA channel here is incorrect ?

Could you shed any light on these issues ?

Thanks,

Matt

[PeterChan]

Hello Matt,

You don't need to apply the MX28_SAIF.patch on SGTL5000 CODEC line-in noise on i.MX28. Please revert it.

If your code is based on L2.6.35_1.1.0_130130, please apply commits ENGR00285446-1, ENGR00285446-2, ENGR00285446-3 & ENGR00285448 for this issue.

Regards,

Peter

[gordanmarkus]

Hello Peter,

I have a question and would highly appreciate your answer.

We have a custom hardware using the i.MX28 with the tlv320aic3204 audio codec and our BSP is based on the Linux 3.10 kernel.

The issue we are experiencing is exactly the same as in the thread SGTL5000 CODEC line-in noise on i.MX28 , there seems to be random occurrences of noisy recording. Currently, I am spending a lot of time debugging the audio codec.

It would be valuable if you and Jack could run through the 3.10 kernel code of mxs-saif (Linux/sound/soc/mxs/mxs-saif.c - Linux Cross Reference - Free Electrons ) and tell me would the following changes and patches accommodated for our kernel be useful (ENGR00285446-1, ENGR00285446-2, ENGR00285446-3).

From what I can see the soft reset is not issued on both SAIFs after modifying a control register.

A response is highly appreciated! Best regards,

Gordan

[YixingKong]

Craig

I am glad to see you are back. Your issue had been branced to an internal group and assigned. Someone will reply you.

Thanks,

Yixing

[alejandrolozan1]

Hi Craig,

Can you share the message you are seeing in the console?

Best Regards,

Alejandro