[alsa-devel] [PATCH] ASoC: OMAP: Don't try to set unsupported OMAP_DMA_DATA_BURST_16 on OMAP1
Wednesday 21 October 2009 20:09:54 Mark Brown napisał(a):
This is fine by me but I'd like a proper changelog
Yes, sir.
---------------------- 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-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);
On Wed, 21 Oct 2009 20:35:40 +0200 Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
- 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);
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.
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; }
On Wed, 21 Oct 2009 23:10:03 +0200 Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
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
Acked-by: Jarkko Nikula jhnikula@gmail.com
On Wed, Oct 21, 2009 at 11:10:03PM +0200, Janusz Krzysztofik wrote:
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.
Applied, thanks. For ease of use with tools like git am it's nicer if you can include text like the above which shouldn't be in the actual commit log after the --- (where the diffstat ends up).
Thursday 22 October 2009 12:50:40 Mark Brown napisał(a):
On Wed, Oct 21, 2009 at 11:10:03PM +0200, Janusz Krzysztofik wrote:
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.
Applied, thanks. For ease of use with tools like git am it's nicer if you can include text like the above which shouldn't be in the actual commit log after the --- (where the diffstat ends up).
Mark, Jarkko,
Shouldn't this one go into 2.6.32 as a fix? It corrects the problem of ASoC not working on OMAP1 at all. I can't see it in -rc6.
Thanks, Janusz
On Thu, Nov 05, 2009 at 07:03:43PM +0100, Janusz Krzysztofik wrote:
Shouldn't this one go into 2.6.32 as a fix? It corrects the problem of ASoC not working on OMAP1 at all. I can't see it in -rc6.
Please say in your patch if something is intended for anything other than the development release. The patch has been applied, but for 2.6.33. I'll cherry pick it over.
participants (3)
-
Janusz Krzysztofik -
Jarkko Nikula -
Mark Brown