[alsa-devel] [PATCH] Re: Calling omap_pcm_prepare() results in BUG() on OMAP1
jkrzyszt at tis.icnet.pl
Wed Oct 21 16:36:49 CEST 2009
I'm resending, this time CCing Mark as I should.
Wednesday 21 October 2009 09:16:37 Jarkko Nikula napisał(a):
> On Wed, 21 Oct 2009 05:11:06 +0200
> Janusz Krzysztofik <jkrzyszt at tis.icnet.pl> wrote:
> > Hi,
> > After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c,
> > omap_pcm_prepare() unconditionally calls:
> > omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16);
> > omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16);
> > AFAICS, current implementation of those two functions found in
> > arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1
> > at all, so they both end with BUG() on that machine. That seems to result
> > in ASoC being completely unusable, at least on my OMAP5910 based Amstrad
> > Delta.
> Thanks for reporting the issue. Nobody didn't realize when those calls
> were added that indeed they will end up to BUG() in
> arch/arm/plat-omap/dma.c on OMAP1.
> > Is calling BUG() for OMAP1 from those functions intentional?
> > If not intentional, can those be corrected by simply putting break;
> > before defalut:?
> I'd let it on as it is as it will point out immediately invalid
> argument for OMAP1 and those functions do not have return value.
> > If intentional, can those function calls be conditionally omited, at
> > least for OMAP1510, in sound/soc/omap/omap-pcm.c?
> Yep, just put cpu_class_is_omap1() test in sound/soc/omap/omap-pcm.c
> since we should not try to set unsupported burst size for OMAP1.
Here you are.
Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
--- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16
+++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.000000000
@@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p
+ if (cpu_class_is_omap1())
+ return 0;
More information about the Alsa-devel