October 2011 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [RFC 0/3] ASoC: davinci- pcm and McASP error detection
by Ben Gardiner 04 Oct '11

04 Oct '11

Both the EDMA3 and McASP have the ability to report error conditions. In both cases these errors are silently dropped on the floor. I would like very much to get HW errors up the stack to the aplay process using the harware. This is an RFC series demonstrating a first attempt. 1/3 isn't nearly as half-baked as the others. It proposes to return SNDRV_PCM_POS_XRUN from davinci-pcm's pointer() function like is currently done in fsl_dma. The problem I have observed in test is that the stream does not abort; several underruns are reported before aplay finally dies. I would prefer immeadiate death with a reason. 2/3 and 3/3 are a first-strike at registering 'health' callbacks provided by the CPU DAI so that error conditions can be reported back. The health callback is polled on calls to pointer(). This may be too often. Also the current method of registering these callbacks seems wrong -- please help me out here. If there is an established method of bubbling HW errors up to userspace that I completely missed: I am sorry for the noise and would be glad to hear about how to use it with davinci-pcm. Best Regards, Ben Gardiner Ben Gardiner (3): [RFC] ASoC: davinci-pcm: latch EDMA errors [RFC] ASoC: davinci-pcm: add cpu-dai health callbacks [RFC] ASoC: davinci-mcasp: add cpu dai health callback sound/soc/davinci/davinci-mcasp.c | 26 ++++++++++++++++++++++++++ sound/soc/davinci/davinci-pcm.c | 19 +++++++++++++++++-- sound/soc/davinci/davinci-pcm.h | 3 +++ 3 files changed, 46 insertions(+), 2 deletions(-) -- 1.7.4.1

2 8

Re: [alsa-devel] [PATCH 1/2] ASoC: max98088 codec: Catch driver bugs for eq channel name
by Mark Brown 04 Oct '11

04 Oct '11

On Tue, Oct 04, 2011 at 09:55:40AM +1100, Ryan Mallon wrote: > Move the EQ channel names to a separate array and iterate over it in > max98088_get_channel rather than duplicating the hardcoded channel > names. Add an error message if an invalid channel is passed and check > the error in the callers. Applied both, thanks.

1 0

[alsa-devel] [PATCH 1/4] ASoC: wm8711: Use snd_soc_update_bits for read-modify-write
by Axel Lin 04 Oct '11

04 Oct '11

Use snd_soc_update_bits for read-modify-write register access instead of open-coding it using snd_soc_read and snd_soc_write Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- sound/soc/codecs/wm8711.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/wm8711.c b/sound/soc/codecs/wm8711.c index 8457d3c..6ecf1ab 100644 --- a/sound/soc/codecs/wm8711.c +++ b/sound/soc/codecs/wm8711.c @@ -381,10 +381,8 @@ static int wm8711_probe(struct snd_soc_codec *codec) wm8711_set_bias_level(codec, SND_SOC_BIAS_STANDBY); /* Latch the update bits */ - reg = snd_soc_read(codec, WM8711_LOUT1V); - snd_soc_write(codec, WM8711_LOUT1V, reg | 0x0100); - reg = snd_soc_read(codec, WM8711_ROUT1V); - snd_soc_write(codec, WM8711_ROUT1V, reg | 0x0100); + snd_soc_update_bits(codec, WM8711_LOUT1V, 0x0100, 0x0100); + snd_soc_update_bits(codec, WM8711_ROUT1V, 0x0100, 0x0100); snd_soc_add_controls(codec, wm8711_snd_controls, ARRAY_SIZE(wm8711_snd_controls)); -- 1.7.4.1

2 4

[alsa-devel] [PATCH] ASoC: omap-pcm: Fix the no period wakeup implementation
by Peter Ujfalusi 04 Oct '11

04 Oct '11

After omap_request_dma the BLOCK_IRQ is enabled as default configuration for the channel. If we are requested for no period wakeup, we need to disable the BLOCK_IRQ in order to not receive any interrupts. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/omap/omap-pcm.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 9b5c88a..5e37ec9 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -198,6 +198,14 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) OMAP_DMA_LAST_IRQ | OMAP_DMA_BLOCK_IRQ); else if (!substream->runtime->no_period_wakeup) omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ); + else { + /* + * No period wakeup: + * we need to disable BLOCK_IRQ, which is enabled by the omap + * dma core at request dma time. + */ + omap_disable_dma_irq(prtd->dma_ch, OMAP_DMA_BLOCK_IRQ); + } if (!(cpu_class_is_omap1())) { omap_set_dma_src_burst_mode(prtd->dma_ch, -- 1.7.7

3 3

Re: [alsa-devel] [PATCH 1/3] mfd: Add WM1811 support
by Mark Brown 04 Oct '11

04 Oct '11

On Tue, Oct 04, 2011 at 12:19:02PM +0200, Samuel Ortiz wrote: > On Tue, Sep 27, 2011 at 07:50:05PM +0100, Mark Brown wrote: > > Due to the ASoC cross dependencies it seems like it'll be easier to > > merge this via ASoC - Samuel, does this make sense to you? > It does. > Liam, please add my: > Acked-by: Samuel Ortiz <sameo(a)linux.intel.com> Hrm, actually there's a bit of overlap with "mfd: Add more checks for WM8994 being active during suspend" from your tree. It's only a one line change (adding the WM1811 device ID) so I don't see any problem with just applying that during -rc, or I could cherry-pick that change over now? Anyway, I've applied the patch just now.

1 0

[alsa-devel] ASoC: snd_soc_codec_set_cache_io does not set codec->hw_write callback now
by Axel Lin 04 Oct '11

04 Oct '11

Hi, I just found that after commit be3ea3b9e "SoC: Use new register map API for ASoC generic physical I/O", snd_soc_codec_set_cache_io does not set codec->hw_write any more. It is still used in some drivers. e.g. In wm8988_resume, we call codec->hw_write(codec->control_data, data, 2); For the drivers that is using snd_soc_codec_set_cache_io now, where is the place to set codec->hw_write callback now? Regards, Axel

2 1

[alsa-devel] [patch] ALSA: oss-mixer - use strlcpy() instead strcpy()
by Dan Carpenter 04 Oct '11

04 Oct '11

This is mostly a static checker fix more than anything else. We're copying from a 64 char buffer into a 44 char buffer. The 64 character buffer is str[] in snd_mixer_oss_build_test_all(). The call tree is: snd_mixer_oss_build_test_all() -> snd_mixer_oss_build_test() -> snd_mixer_oss_build_test(). We never actually do fill str[] buffer all the way to 64 characters. The longest string is: sprintf(str, "%s Playback Switch", ptr->name); ptr->name is a 32 character buffer so 32 plus 16 characters for " Playback Switch" still puts us over the 44 limit from "id.name". Most likely ptr->name never gets filled to the limit, but we can't really change the size of that buffer so lets just use strlcpy() here and be safe. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/core/oss/mixer_oss.c b/sound/core/oss/mixer_oss.c index 27ac611..18297f7 100644 --- a/sound/core/oss/mixer_oss.c +++ b/sound/core/oss/mixer_oss.c @@ -500,7 +500,7 @@ static struct snd_kcontrol *snd_mixer_oss_test_id(struct snd_mixer_oss *mixer, c memset(&id, 0, sizeof(id)); id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; - strcpy(id.name, name); + strlcpy(id.name, name, sizeof(id.name)); id.index = index; return snd_ctl_find_id(card, &id); }

2 1

[alsa-devel] Add documentation for codec specific mixer controls of Analog codec
by Raymond Yau 04 Oct '11

04 Oct '11

Analog codecs -------------- * Channel Mode This is an enum control to change the surround-channel setup, appears only when the surround channels are available. It gives the number of channels to be used, "2ch", "4ch" and "6ch". According to the configuration, this also controls the jack-retasking of multi-I/O jacks. * Independent HP When this enum control is enabled, the headphone output is routed from an individual stream (the third PCM such as hw:0,2) instead of the primary stream.

2 1

[alsa-devel] [PATCH] ASoC: Remove needless codec->dapm.bias_level assignment to SND_SOC_BIAS_OFF
by Axel Lin 04 Oct '11

04 Oct '11

This assignment is done by the snd_soc_register_codec so there is no need to redo it in probe function of a codec driver. Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- sound/soc/codecs/sn95031.c | 1 - sound/soc/codecs/wm5100.c | 2 -- sound/soc/codecs/wm8996.c | 1 - 3 files changed, 0 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/sn95031.c b/sound/soc/codecs/sn95031.c index adb85bf..09c4593 100644 --- a/sound/soc/codecs/sn95031.c +++ b/sound/soc/codecs/sn95031.c @@ -827,7 +827,6 @@ static int sn95031_codec_probe(struct snd_soc_codec *codec) { pr_debug("codec_probe called\n"); - codec->dapm.bias_level = SND_SOC_BIAS_OFF; codec->dapm.idle_bias_off = 1; /* PCM interface config diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c index f603989..46afdf86 100644 --- a/sound/soc/codecs/wm5100.c +++ b/sound/soc/codecs/wm5100.c @@ -2285,8 +2285,6 @@ static int wm5100_probe(struct snd_soc_codec *codec) wm5100->codec = codec; - codec->dapm.bias_level = SND_SOC_BIAS_OFF; - ret = snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_I2C); if (ret != 0) { dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret); diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c index b98a8f8..43e46c7 100644 --- a/sound/soc/codecs/wm8996.c +++ b/sound/soc/codecs/wm8996.c @@ -2706,7 +2706,6 @@ static int wm8996_probe(struct snd_soc_codec *codec) init_completion(&wm8996->fll_lock); dapm->idle_bias_off = true; - dapm->bias_level = SND_SOC_BIAS_OFF; ret = snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_I2C); if (ret != 0) { -- 1.7.4.1

3 3

[alsa-devel] Event flood on USB disconnect
by Arun Raghavan 04 Oct '11

04 Oct '11

Hi folks, We're seeing a problem when disconnecting USB headsets in PulseAudio. Steps to reproduce are basically: start PulseAudio, plug in USB device, wait for it to suspend (pcm is closed but mixer is not), disconnect. Fairly often, this results in PA getting killed because the polling thread is realtime and exceeds its rlimit. The problem is not limited to one machine or one USB headset, and I'm running kernel 3.0.4 I'm basically seeing a flood of events on the mixer pollfds (goes as high as 4+ million of them). As far as I can tell, they all contain (POLLERR|POLLNVAL). From a preliminary look at the code this seems to be expected on a card disconnect, but I assume not so often. I'm going to try to handle this by just stopping PA from listening on these fds when I get a (POLLERR|POLLNVAL), but it seems to me that this is a bug in the driver somewhere. Any ideas w.r.t. what might be going wrong or where I should be looking to debug further? Cheers, Arun

4 5