[alsa-devel] [RFC][PATCH] ASoC: OMAP: Fix capture pointer handling for OMAP1510 to work correctly with recent ALSA PCM code
With recent (2.6.34) chnages in PCM handling, capture stopped working on my OMAP1510 based Amstrad Delta videophone.
Using 2.6.34-rc2, I was able to correct the problem in 3 different ways:
1. reverting commit 7b3a177b0d4f92b3431b8dca777313a07533a710, 2. enabling additional jiffies check with echo 4 >/proc/asound/card0/pcm0c0/xrun_debug 3. applying the patch below.
Since I wasn't able to reproduce the problem on my i686 PC, I guess the problem is probably machine specific.
The patch reuses the method for software emulation of missing hardware pointer, already implemented for playback on OMAP1510. It's possible that event if a hardware pointer is available for capture on this machine, its behaviour may be not compatible with what upper layer expects.
If you think the problem may be more general and should be solved differently, on a higher level, I can try to work more on it if you give me a hint.
If the patch gets accepted, I suggest it goes as a fix in the current release cycle.
Created and tested against linux-2.6.34-rc2.
Signed-off-by: Janusz Krzysztofik jkrzyszt@tis.icnet.pl --- --- git/sound/soc/omap/omap-pcm.c.orig 2010-03-25 16:00:13.000000000 +0100 +++ git/sound/soc/omap/omap-pcm.c 2010-03-28 05:16:42.000000000 +0200 @@ -60,12 +60,11 @@ static void omap_pcm_dma_irq(int ch, u16 struct omap_runtime_data *prtd = runtime->private_data; unsigned long flags;
- if ((cpu_is_omap1510()) && - (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)) { + if ((cpu_is_omap1510())) { /* * OMAP1510 doesn't fully support DMA progress counter * and there is no software emulation implemented yet, - * so have to maintain our own playback progress counter + * so have to maintain our own progress counters * that can be used by omap_pcm_pointer() instead. */ spin_lock_irqsave(&prtd->lock, flags); @@ -189,8 +188,7 @@ static int omap_pcm_prepare(struct snd_p dma_params.frame_count = runtime->periods; omap_set_dma_params(prtd->dma_ch, &dma_params);
- if ((cpu_is_omap1510()) && - (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)) + if ((cpu_is_omap1510())) omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ | OMAP_DMA_LAST_IRQ | OMAP_DMA_BLOCK_IRQ); else @@ -248,14 +246,15 @@ static snd_pcm_uframes_t omap_pcm_pointe dma_addr_t ptr; snd_pcm_uframes_t offset;
- if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { + if (cpu_is_omap1510()) { + offset = prtd->period_index * runtime->period_size; + } else if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { ptr = omap_get_dma_dst_pos(prtd->dma_ch); offset = bytes_to_frames(runtime, ptr - runtime->dma_addr); - } else if (!(cpu_is_omap1510())) { + } else { ptr = omap_get_dma_src_pos(prtd->dma_ch); offset = bytes_to_frames(runtime, ptr - runtime->dma_addr); - } else - offset = prtd->period_index * runtime->period_size; + }
if (offset >= runtime->buffer_size) offset = 0;
On Sun, 28 Mar 2010 22:29:29 +0200 Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
With recent (2.6.34) chnages in PCM handling, capture stopped working on my OMAP1510 based Amstrad Delta videophone.
Using 2.6.34-rc2, I was able to correct the problem in 3 different ways:
- reverting commit 7b3a177b0d4f92b3431b8dca777313a07533a710,
- enabling additional jiffies check with echo 4 >/proc/asound/card0/pcm0c0/xrun_debug
- applying the patch below.
Since I wasn't able to reproduce the problem on my i686 PC, I guess the problem is probably machine specific.
The patch reuses the method for software emulation of missing hardware pointer, already implemented for playback on OMAP1510. It's possible that event if a hardware pointer is available for capture on this machine, its behaviour may be not compatible with what upper layer expects.
If you think the problem may be more general and should be solved differently, on a higher level, I can try to work more on it if you give me a hint.
I don't have anything against this patch as it makes the playback/capture code uniform on 1510 but I don't understand why the capture broke now if it was working before.
What I was thinking if there has been always some overruns which were not detected on 2.6.34-rc anymore and that caused somehow the capture not working on 1510. Could you try does a patch below have any effect?
http://mailman.alsa-project.org/pipermail/alsa-devel/2010-March/026487.html
Monday 29 March 2010 10:54:59 Jarkko Nikula napisał(a):
On Sun, 28 Mar 2010 22:29:29 +0200
Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
With recent (2.6.34) chnages in PCM handling, capture stopped working on my OMAP1510 based Amstrad Delta videophone.
Using 2.6.34-rc2, I was able to correct the problem in 3 different ways:
- reverting commit 7b3a177b0d4f92b3431b8dca777313a07533a710,
- enabling additional jiffies check with echo 4 >/proc/asound/card0/pcm0c0/xrun_debug
- applying the patch below.
Since I wasn't able to reproduce the problem on my i686 PC, I guess the problem is probably machine specific.
The patch reuses the method for software emulation of missing hardware pointer, already implemented for playback on OMAP1510. It's possible that event if a hardware pointer is available for capture on this machine, its behaviour may be not compatible with what upper layer expects.
If you think the problem may be more general and should be solved differently, on a higher level, I can try to work more on it if you give me a hint.
I don't have anything against this patch as it makes the playback/capture code uniform on 1510 but I don't understand why the capture broke now if it was working before.
What I was thinking if there has been always some overruns which were not detected on 2.6.34-rc anymore and that caused somehow the capture not working on 1510. Could you try does a patch below have any effect?
http://mailman.alsa-project.org/pipermail/alsa-devel/2010-March/026487.html
Hi Jarrko,
I should have mention that I was already aware of your patch; applied alone, it didn't solve the problem for me. However, when configuring ALSA with debugging turned off, I have to use both patches, yours and mine, in order to get things working.
The most mysterious part of the issue, and most interesting question that I'm not able to find an answer myself for, is why the problem can be corrected by reverting commit 7b3a177b0d4f92b3431b8dca777313a07533a710.
Jaroslav, I'm CCing you, the author of the "magic" commit, in hope you may be able to shed some more light on the issue.
Thanks, Janusz
On Mon, Mar 29, 2010 at 02:14:51PM +0200, Janusz Krzysztofik wrote:
I should have mention that I was already aware of your patch; applied alone, it didn't solve the problem for me. However, when configuring ALSA with debugging turned off, I have to use both patches, yours and mine, in order to get things working.
Any updates on this one?
Thursday 01 April 2010 14:25:21 Mark Brown napisał(a):
On Mon, Mar 29, 2010 at 02:14:51PM +0200, Janusz Krzysztofik wrote:
I should have mention that I was already aware of your patch; applied alone, it didn't solve the problem for me. However, when configuring ALSA with debugging turned off, I have to use both patches, yours and mine, in order to get things working.
Any updates on this one?
Hi Mark,
I can only confirm that using 2.6.34-rc3, already containing Jarkko's patch, I still have to apply mine to get sound working on Amstrad Delta.
However, I still don't understand what happened to capture stream handling that it stopped working for me.
Thanks, Janusz
On Thu, 1 Apr 2010 21:45:49 +0200 Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
Thursday 01 April 2010 14:25:21 Mark Brown napisał(a):
Any updates on this one?
Hi Mark,
I can only confirm that using 2.6.34-rc3, already containing Jarkko's patch, I still have to apply mine to get sound working on Amstrad Delta.
However, I still don't understand what happened to capture stream handling that it stopped working for me.
While I either don't understand the broke I think there's something in the capture DMA pointer which shows up only now. So I'm fine if you Janusz like to get your patch in and can have my ack. Or do you want to debug it further?
Acked-by: Jarkko Nikula jhnikula@gmail.com
On Fri, Apr 02, 2010 at 11:10:36AM +0300, Jarkko Nikula wrote:
Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
However, I still don't understand what happened to capture stream handling that it stopped working for me.
While I either don't understand the broke I think there's something in the capture DMA pointer which shows up only now. So I'm fine if you Janusz like to get your patch in and can have my ack. Or do you want to debug it further?
Acked-by: Jarkko Nikula jhnikula@gmail.com
Personally I don't mind as long as you guys are happy - Janusz?
Friday 02 April 2010 11:36:56 Mark Brown napisał(a):
On Fri, Apr 02, 2010 at 11:10:36AM +0300, Jarkko Nikula wrote:
Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
However, I still don't understand what happened to capture stream handling that it stopped working for me.
While I either don't understand the broke I think there's something in the capture DMA pointer which shows up only now. So I'm fine if you Janusz like to get your patch in and can have my ack. Or do you want to debug it further?
Acked-by: Jarkko Nikula jhnikula@gmail.com
Personally I don't mind as long as you guys are happy - Janusz?
I don't mind either :), please apply.
Thanks, Janusz
On Sun, Mar 28, 2010 at 10:29:29PM +0200, Janusz Krzysztofik wrote:
The patch reuses the method for software emulation of missing hardware pointer, already implemented for playback on OMAP1510. It's possible that event if a hardware pointer is available for capture on this machine, its behaviour may be not compatible with what upper layer expects.
Applied, thanks.
participants (3)
-
Janusz Krzysztofik -
Jarkko Nikula -
Mark Brown