Wednesday 21 October 2009 21:16:07 Jarkko Nikula napisaĆ(a):
I would have implemented this by "if (!cpu_class_is_omap1()) {..._burst_mode}" for making sure that no new OMAP1 error is introduced in the future if there is need to add some common stuff after those burst_mode calls and probably compiler can better optimize away those burst_mode calls for OMAP1 builds.
Yes, you're right.
--------------------------
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);
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 results in ASoC being completely unusable, at least on my OMAP5910 based Amstrad Delta.
The patch corrects the problem by not calling those two functions when run on OMAP1 class based machines.
Created against linux-2.6.32-rc5. Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzyszt@tis.icnet.pl
--- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-21 21:51:38.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 21:52:59.000000000 +0200 @@ -195,8 +195,12 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ);
- 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); + if (!(cpu_class_is_omap1())) { + 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); + }
return 0; }