Wednesday 03 June 2009 07:28:06 Peter Ujfalusi napisał(a):
> Looking at the code at commit: d8376cc482b241701f7606c81ad578b90853e175 on
> l-o the comment about the need for the call the omap_stop_dma puzzled me.
Peter,
It was omap_stop_alsa_sound_dma(), not just omap_stop_dma(), the was needed.
In my opinion, the reason for that was not because it was calling
omap_stop_dma(), but because it was clearing the audio_stream.started flag.
That way, subsequent audio_start_dma_chain() would not jump over
omap_start_dma(). From my experience with the original driver, it worked much
better when calling omap_start_dma() unconditionally from
audio_start_dma_chain() instead of doing this with that
omap_stop_alsa_sound_dma() trick.
> Can you try something like this:
>
> diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
> index 6454e15..2df1792 100644
> --- a/sound/soc/omap/omap-pcm.c
> +++ b/sound/soc/omap/omap-pcm.c
> @@ -67,6 +67,7 @@ static void omap_pcm_dma_irq(int ch, u16 stat, void
> *data) spin_lock_irqsave(&prtd->lock, flags);
> if (prtd->period_index >= 0) {
> if (++prtd->period_index == runtime->periods) {
> + omap_stop_dma(prtd->dma_ch);
> prtd->period_index = 0;
> omap_start_dma(prtd->dma_ch);
> }
> @@ -191,6 +192,7 @@ static int omap_pcm_trigger(struct snd_pcm_substream
> *substream, int cmd)
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_RESUME:
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + omap_stop_dma(prtd->dma_ch);
> prtd->period_index = 0;
> omap_start_dma(prtd->dma_ch);
> break;
Never hurts. Unfortunatelly, it did not help, no single DMA interrupt again.
Thanks,
Janusz
--
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
