[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