[alsa-devel] patch 1/1: ASoC, DMA crash with application- resolved
Hi ALSA SOC,
I am using a OMAP3 + TWL4030 combination with ASoC
in the sound/soc/omap/omap-pcm.c DMA channels are being freed after unlinking in the omap_pcm_hw_free function
Which is causing a crash during applications So, stopping the DMA channels before unlinking resolves the issue.
here is the patch that solves the issue
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index e9084fd..679e384 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -116,6 +116,7 @@ static int omap_pcm_hw_free(struct snd_pcm_substream *substream) if (prtd->dma_data == NULL) return 0;
+ omap_stop_dma(prtd->dma_ch); if (!cpu_is_omap1510()) omap_dma_unlink_lch(prtd->dma_ch, prtd->dma_ch); omap_free_dma(prtd->dma_ch);
Is this ok or is there any better way out
On Sun, Dec 21, 2008 at 9:22 AM, naveenkrishna. ch < naveenkrishna.ch@gmail.com> wrote:
Hi ALSA SOC,
I am using a OMAP3 + TWL4030 combination with ASoC
in the sound/soc/omap/omap-pcm.c DMA channels are being freed after unlinking in the omap_pcm_hw_free function
Which is causing a crash during applications So, stopping the DMA channels before unlinking resolves the issue.
here is the patch that solves the issue
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index e9084fd..679e384 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -116,6 +116,7 @@ static int omap_pcm_hw_free(struct snd_pcm_substream *substream) if (prtd->dma_data == NULL) return 0;
omap_stop_dma(prtd->dma_ch); if (!cpu_is_omap1510()) omap_dma_unlink_lch(prtd->dma_ch, prtd->dma_ch); omap_free_dma(prtd->dma_ch);
Is this ok or is there any better way out
This looks a bit familiar, I hope so. Is this from linux-omap, mainline or in-house kernel?
There were similar issues fixed by following two patches in linux-omap. Second one is not yet in mainline, have to confirm with Tony has he queued it now.
commit 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e Author: Jarkko Nikula jarkko.nikula@nokia.com Date: Tue May 13 13:26:03 2008 +0300
ARM: OMAP: DMA: Don't mark channel active in omap_enable_channel_irq
Channel should be marked active only when DMA is really started. Otherwise just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch will cause incorrect dump_stack().
commit 55502f74b56f609a84d8919b9b29390b2e0147ff Author: Jarkko Nikula jarkko.nikula@nokia.com Date: Mon Aug 18 12:28:22 2008 +0300
ARM: OMAP: DMA: Fix uninitialized channel flags
This has similar symptoms than 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e where just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch can cause incorrect dump_stack(). Here it can happen if channel has been used before and the channel flags variable holds old status.
Signed-off-by: Jarkko Nikula jarkko.nikula@nokia.com Signed-off-by: Tony Lindgren tony@atomide.com
Then it's worth to verify also this very recent fix. This is already in mainline and will flow into linux-omap when Tony does the pull.
commit 19b3f31609dc8be3a56c78dcb7da723f10f7009c Author: Stanley Miao stanley.miao@windriver.com Date: Fri Dec 19 22:08:22 2008 +0800
ALSA: Fix a Oops bug in omap soc driver.
There will be a Oops or frequent underrun messages when playing music with omap soc driver, this is because a data region is incorretly sized, other da region will be overwriten when writing to this data region.
Jarkko
On Sun, Dec 21, 2008 at 3:06 PM, Jarkko Nikula jhnikula@gmail.com wrote:
On Sun, Dec 21, 2008 at 9:22 AM, naveenkrishna. ch < naveenkrishna.ch@gmail.com> wrote:
Hi ALSA SOC,
I am using a OMAP3 + TWL4030 combination with ASoC
in the sound/soc/omap/omap-pcm.c DMA channels are being freed after unlinking in the omap_pcm_hw_free function
Which is causing a crash during applications So, stopping the DMA channels before unlinking resolves the issue.
here is the patch that solves the issue
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index e9084fd..679e384 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -116,6 +116,7 @@ static int omap_pcm_hw_free(struct snd_pcm_substream *substream) if (prtd->dma_data == NULL) return 0;
omap_stop_dma(prtd->dma_ch); if (!cpu_is_omap1510()) omap_dma_unlink_lch(prtd->dma_ch, prtd->dma_ch); omap_free_dma(prtd->dma_ch);
Is this ok or is there any better way out
This looks a bit familiar, I hope so. Is this from linux-omap, mainline or in-house kernel?
This is what i have seen in the alsa-kernel
There were similar issues fixed by following two patches in linux-omap. Second one is not yet in mainline, have to confirm with Tony has he queued it now.
commit 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e Author: Jarkko Nikula jarkko.nikula@nokia.com Date: Tue May 13 13:26:03 2008 +0300
ARM: OMAP: DMA: Don't mark channel active in omap_enable_channel_irq Channel should be marked active only when DMA is really started.
Otherwise just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch will cause incorrect dump_stack().
commit 55502f74b56f609a84d8919b9b29390b2e0147ff Author: Jarkko Nikula jarkko.nikula@nokia.com Date: Mon Aug 18 12:28:22 2008 +0300
ARM: OMAP: DMA: Fix uninitialized channel flags This has similar symptoms than 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e where just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch can cause incorrect dump_stack(). Here it can happen if channel has
been used before and the channel flags variable holds old status.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Then it's worth to verify also this very recent fix. This is already in mainline and will flow into linux-omap when Tony does the pull.
commit 19b3f31609dc8be3a56c78dcb7da723f10f7009c Author: Stanley Miao stanley.miao@windriver.com Date: Fri Dec 19 22:08:22 2008 +0800
ALSA: Fix a Oops bug in omap soc driver. There will be a Oops or frequent underrun messages when playing music
with omap soc driver, this is because a data region is incorretly sized, other da region will be overwriten when writing to this data region.
Jarkko
On Sun, Dec 21, 2008 at 11:38 AM, naveenkrishna. ch < naveenkrishna.ch@gmail.com> wrote:
This looks a bit familiar, I hope so. Is this from linux-omap, mainline or in-house kernel?
This is what i have seen in the alsa-kernel
Ok. Does it get fixed if you pick this second patch from linux-omap?
commit 55502f74b56f609a84d8919b9b29390b2e0147ff Author: Jarkko Nikula jarkko.nikula@nokia.com Date: Mon Aug 18 12:28:22 2008 +0300
ARM: OMAP: DMA: Fix uninitialized channel flags
This has similar symptoms than 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e where just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch can cause incorrect dump_stack(). Here it can happen if channel has been used before and the channel flags variable holds old status.
Jarkko
On Sun, Dec 21, 2008 at 3:12 PM, Jarkko Nikula jhnikula@gmail.com wrote:
On Sun, Dec 21, 2008 at 11:38 AM, naveenkrishna. ch < naveenkrishna.ch@gmail.com> wrote:
This looks a bit familiar, I hope so. Is this from linux-omap, mainline or in-house kernel?
This is what i have seen in the alsa-kernel
Ok. Does it get fixed if you pick this second patch from linux-omap?
To solve the DMA crashes i have sent a patch, it worked i dint found any patches related to this issue, I tried it on alsa kernel git...
commit 55502f74b56f609a84d8919b9b29390b2e0147ff Author: Jarkko Nikula jarkko.nikula@nokia.com Date: Mon Aug 18 12:28:22 2008 +0300
ARM: OMAP: DMA: Fix uninitialized channel flags
This has similar symptoms than 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e where just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch can cause incorrect dump_stack(). Here it can happen if channel has been used before and the channel flags variable holds old status.
Jarkko
On Sun, Dec 21, 2008 at 09:37:21PM +0530, naveenkrishna.ch wrote:
To solve the DMA crashes i have sent a patch, it worked i dint found any patches related to this issue, I tried it on alsa kernel git...
Please check with Jarkko's patch applied below - it's not in ALSA git so you'll need to cherry pick it over into Takashi's tree by hand:
commit 55502f74b56f609a84d8919b9b29390b2e0147ff Author: Jarkko Nikula jarkko.nikula@nokia.com Date: Mon Aug 18 12:28:22 2008 +0300
ARM: OMAP: DMA: Fix uninitialized channel flags
On Sun, Dec 21, 2008 at 11:09 PM, Mark Brown broonie@sirena.org.uk wrote:
On Sun, Dec 21, 2008 at 09:37:21PM +0530, naveenkrishna.ch wrote:
To solve the DMA crashes i have sent a patch, it worked i dint found any patches related to this issue, I tried it on alsa kernel git...
Please check with Jarkko's patch applied below - it's not in ALSA git so you'll need to cherry pick it over into Takashi's tree by hand:
Here's link to the patch and it applies into Takashi's tree:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit...
And recent Oops fix (which is in Takashi's tree):
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff_p...
If these two don't help, then I think there must be either race somewhere or bug in stopping of OMAP DMA. Anyway, it's a bug if DMA is still running when executing omap_pcm_hw_free.
If possible, can you post a crash dump and/or use-case how to reproduce the problem? I have TI Beagle board with OMAP3 and TWL4030 so I may be able to reproduce it as well.
Jarkko
At Sun, 21 Dec 2008 15:08:21 +0530, naveenkrishna.ch wrote:
On Sun, Dec 21, 2008 at 3:06 PM, Jarkko Nikula jhnikula@gmail.com wrote:
On Sun, Dec 21, 2008 at 9:22 AM, naveenkrishna. ch < naveenkrishna.ch@gmail.com> wrote:
Hi ALSA SOC,
I am using a OMAP3 + TWL4030 combination with ASoC
in the sound/soc/omap/omap-pcm.c DMA channels are being freed after unlinking in the omap_pcm_hw_free function
Which is causing a crash during applications So, stopping the DMA channels before unlinking resolves the issue.
here is the patch that solves the issue
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index e9084fd..679e384 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -116,6 +116,7 @@ static int omap_pcm_hw_free(struct snd_pcm_substream *substream) if (prtd->dma_data == NULL) return 0;
omap_stop_dma(prtd->dma_ch); if (!cpu_is_omap1510()) omap_dma_unlink_lch(prtd->dma_ch, prtd->dma_ch); omap_free_dma(prtd->dma_ch);
Is this ok or is there any better way out
This looks a bit familiar, I hope so. Is this from linux-omap, mainline or in-house kernel?
This is what i have seen in the alsa-kernel
Check sound git tree. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
Takashi
participants (4)
-
Jarkko Nikula
-
Mark Brown
-
naveenkrishna.ch
-
Takashi Iwai