Hi On Wed, 21 Oct 2009 05:11:06 +0200 Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
