[alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1

Jarkko Nikula jhnikula at gmail.com
Wed Oct 21 09:16:37 CEST 2009


Hi

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.


-- 
Jarkko


More information about the Alsa-devel mailing list