public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* Calling omap_pcm_prepare() results in BUG() on OMAP1
@ 2009-10-21  3:11 Janusz Krzysztofik
  2009-10-21  7:16 ` [alsa-devel] " Jarkko Nikula
  0 siblings, 1 reply; 3+ messages in thread
From: Janusz Krzysztofik @ 2009-10-21  3:11 UTC (permalink / raw)
  To: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org

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.

Is calling BUG() for OMAP1 from those functions intentional?

If not intentional, can those be corrected by simply putting break; before 
defalut:?

If intentional, can those function calls be conditionally omited, at least for 
OMAP1510, in sound/soc/omap/omap-pcm.c?

Thanks,
Janusz

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
  2009-10-21  3:11 Calling omap_pcm_prepare() results in BUG() on OMAP1 Janusz Krzysztofik
@ 2009-10-21  7:16 ` Jarkko Nikula
  2009-10-21 10:38   ` [PATCH] " Janusz Krzysztofik
  0 siblings, 1 reply; 3+ messages in thread
From: Jarkko Nikula @ 2009-10-21  7:16 UTC (permalink / raw)
  To: Janusz Krzysztofik
  Cc: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org

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.


-- 
Jarkko

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH] Re: Calling omap_pcm_prepare() results in BUG() on OMAP1
  2009-10-21  7:16 ` [alsa-devel] " Jarkko Nikula
@ 2009-10-21 10:38   ` Janusz Krzysztofik
  0 siblings, 0 replies; 3+ messages in thread
From: Janusz Krzysztofik @ 2009-10-21 10:38 UTC (permalink / raw)
  To: Jarkko Nikula; +Cc: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org

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);
 

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-10-21 10:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-21  3:11 Calling omap_pcm_prepare() results in BUG() on OMAP1 Janusz Krzysztofik
2009-10-21  7:16 ` [alsa-devel] " Jarkko Nikula
2009-10-21 10:38   ` [PATCH] " Janusz Krzysztofik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox