Wednesday 21 October 2009 09:16:37 Jarkko Nikula napisał(a):

Hi

On Wed, 21 Oct 2009 05:11:06 +0200

Janusz Krzysztofik jkrzyszt@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@tis.icnet.pl

--- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.000000000 +0200 @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ);

+ if (cpu_class_is_omap1()) + return 0; + 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);