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

Re: [alsa-devel] [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails
by Tabi Timur-B04825 27 Sep '11

27 Sep '11

Axel Lin wrote: > Call platform_device_put() instead of platform_device_unregister() if > platform_device_add() fails. What's wrong with calling platform_device_unregister()? -- Timur Tabi Linux kernel developer at Freescale

2 1

[alsa-devel] [PATCH] ASoC: Flush Samsung DMA on free
by Mark Brown 27 Sep '11

27 Sep '11

Ever since it was written the Samsung DMA driver has had a TODO in the hw_free() function wondering if we need to flush the DMA buffers. Up until now the answer has been no but with the recent improvements Boojin has done to the DMA infrastructure for the Samsung port the answer has changed to yes for at least S3C6410 systems. If we don't then when we next prepare() the channel the API will get confused trying to run callbacks on the transfers hanging around from the previous time the stream was open and oops. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Kukjin, this should probably get added to your branch assuming it's OK for other CPUs. sound/soc/samsung/dma.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c index 851346f..2d622b6 100644 --- a/sound/soc/samsung/dma.c +++ b/sound/soc/samsung/dma.c @@ -198,10 +198,10 @@ static int dma_hw_free(struct snd_pcm_substream *substream) pr_debug("Entered %s\n", __func__); - /* TODO - do we need to ensure DMA flushed */ snd_pcm_set_runtime_buffer(substream, NULL); if (prtd->params) { + prtd->params->ops->flush(prtd->params->ch); prtd->params->ops->release(prtd->params->ch, prtd->params->client); prtd->params = NULL; -- 1.7.6.3

2 1

Re: [alsa-devel] Questions for dummy codec driver
by Mark Brown 26 Sep '11

26 Sep '11

On Thu, Sep 22, 2011 at 09:42:14AM +0800, Leo Yan wrote: > On our platform, there have some devices (like hdmi/bt) do not need > config from the CODEC driver, they have their own s/w stack and > interface to configure; for the audio driver, just need to set the > I2S/PCM timing for them. So if there have a common dummy codec > driver, then it can meet our requirement well. Otherwise, there will > have some duplicate codes for these dummy codecs. The general thought here has been that for dumb CODECs the boilerplate is sufficiently small and simple to mean that the discoverability from writing a skeletal driver outweighs the cost of having it kicking around - while there is some boilerplate there it's easier for someone to grab and use this code than it is to work out how exactly to translate the datasheets into code each time they encounter the part. However, a sufficiently well written generic driver would maintain that advantage while reducing the duplication.

1 0

Re: [alsa-devel] Adding ELD control to alsa-lib hdmi device
by David Henningsson 26 Sep '11

26 Sep '11

On 09/23/2011 08:46 PM, Pierre-Louis Bossart wrote: > Hi, > Now that I almost done with exposing a read-only ELD control for HDA/HDMI > outputs, I was wondering how to read it from user-land. PulseAudio and > others rely on the 'hdmi' device, and apparently I can't access this new ELD > control, I have to use the 'hw:x,y' details. The hdmi:x(,y) device is only used for pcm. For opening the mixer, hw:x (never hw:x,y - that's pcm only as well) is used as the device string. > I really don't understand much to alsa-lib... Can I expose this new control > through the ALSA configuration files where the hdmi device is defined? Or is > there a way to infer the card and device number actually used by an alsa-lib > plugin? Or do I have to add code to propagate the information from > hardware-level to higher-level plugins? > Thanks for your feedback! I'm not the expert here, but if I were you, I would run amixer -D hw:x contents amixer -D hw:x scontents To see if your controls show up there. If it shows up in scontents, that would be the "simple" mixer interface that PulseAudio uses. If not, using the control api (as being done by "contents") should work. Anyway, reading the source code to amixer would then be the first step towards understanding how to enumerate and read mixer controls. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[alsa-devel] [PATCH] usb-audio: Check for possible chip NULL pointer before clearing probing flag
by Thomas Pfaff 26 Sep '11

26 Sep '11

Before clearing the probing flag in the error exit path, check that the chip pointer is not NULL. Signed-off-by: Thomas Pfaff <tpfaff(a)gmx.net> --- diff -urp a/sound/usb/card.c b/sound/usb/card.c --- a/sound/usb/card.c 2011-09-26 14:58:02.468672118 +0200 +++ b/sound/usb/card.c 2011-09-26 15:00:30.313110086 +0200 @@ -530,9 +530,11 @@ snd_usb_audio_probe(struct usb_device *d return chip; __error: - if (chip && !chip->num_interfaces) - snd_card_free(chip->card); - chip->probing = 0; + if (chip) { + if (!chip->num_interfaces) + snd_card_free(chip->card); + chip->probing = 0; + } mutex_unlock(&register_mutex); __err_val: return NULL;

2 1

[alsa-devel] [PATCH resend 0/4] ASoC: omap-mcpdm/twl6040: Offset cancellation
by Peter Ujfalusi 26 Sep '11

26 Sep '11

Hello, The following series adds support for the McPDM offset cancellation feature. It provides the needed functionality to: - read the HSTRIM values from the twl6040 codec - configure the offset cancellation registers in OMAP-McPDM Rebased batches on top of: git://opensource.wolfsonmicro.com/linux-2.6-asoc, for-3.2 branch No other changes. Mark: I have not added you acks to the patches, since you will be signing them off anyways. Regards, Peter --- Peter Ujfalusi (4): ASoC: twl6040: Read the TRIM values from the chip ASoC: twl6040: Function to fetch the TRIM values ASoC: omap-mcpdm: API to configure offset cancellation ASoC: sdp4430: Configure McPDM offset cancellation sound/soc/codecs/twl6040.c | 16 ++++++++++++++++ sound/soc/codecs/twl6040.h | 13 +++++++++++++ sound/soc/omap/omap-mcpdm.c | 25 +++++++++++++++++++++++++ sound/soc/omap/omap-mcpdm.h | 12 ++++++++++++ sound/soc/omap/sdp4430.c | 10 +++++++++- 5 files changed, 75 insertions(+), 1 deletions(-) -- 1.7.6.1

1 4

[alsa-devel] [PATCH 0/4] ASoC: omap-mcpdm/twl6040: Offset cancellation
by Peter Ujfalusi 26 Sep '11

26 Sep '11

Hello, The following series adds support for the McPDM offset cancellation feature. It provides the needed functionality to: - read the HSTRIM values from the twl6040 codec - configure the offset cancellation registers in OMAP-McPDM Regards, Peter --- Peter Ujfalusi (4): ASoC: twl6040: Read the TRIM values from the chip ASoC: twl6040: Function to fetch the TRIM values ASoC: omap-mcpdm: API to configure offset cancellation ASoC: sdp4430: Configure McPDM offset cancellation sound/soc/codecs/twl6040.c | 16 ++++++++++++++++ sound/soc/codecs/twl6040.h | 13 +++++++++++++ sound/soc/omap/omap-mcpdm.c | 25 +++++++++++++++++++++++++ sound/soc/omap/omap-mcpdm.h | 12 ++++++++++++ sound/soc/omap/sdp4430.c | 10 +++++++++- 5 files changed, 75 insertions(+), 1 deletions(-) -- 1.7.6.1

2 9

[alsa-devel] ASoC updates for 3.1
by Mark Brown 26 Sep '11

26 Sep '11

The following changes since commit 5013951be88e136d9990ef55303276e2779ce8d8: ASoC: Fix trivial build regression in Kirkwood I2S (2011-09-12 11:48:12 +0100) are available in the git repository at: git://opensource.wolfsonmicro.com/linux-2.6-asoc.git for-3.1 A couple of driver fixes and the driver name issue we discussed. Axel Lin (1): ASoC: bf5xx-ad73311: Fix prototype for bf5xx_probe Mark Brown (2): ASoC: Remove bitrotted wm8962_resume() ASoC: Ensure we generate a driver name sound/soc/blackfin/bf5xx-ad73311.c | 2 +- sound/soc/codecs/wm8962.c | 26 -------------------------- sound/soc/soc-core.c | 18 +++++++++++++++--- 3 files changed, 16 insertions(+), 30 deletions(-)

3 3

Re: [alsa-devel] link between HDMI ELD and PCM devices
by David Henningsson 26 Sep '11

26 Sep '11

On 09/21/2011 03:20 PM, Pierre-Louis Bossart wrote: >> This won't work - in the case of several HDMI codecs (common with >> NVidia) there will be more than one "HDMI 0". > > No, the code doesn't use a constant, It's actually four constants, please see generic_hdmi_pcm_names in patch_hdmi.c. But my point is that this restarts from 0 on every codec. > it's assigned in the same way as the > device name. You would have HDMI 0, HDMI 1..4. I don't have this kind of > hardware, it'd be good if someone could verify that the name is indeed > dynamic. On a 3.0 based kernel, here's part of my aplay -l output: card 3: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 7: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 8: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 9: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 >> The solution is to actually find the device number out, like this: >> >> struct hdmi_spec *spec = codec->spec; >> int pcmdev = spec->pcm_rec[pin_idx].device; > > That's what I wanted initially, but this device field is not > used/initialized, and like I said the device assignment comes after the pin > sensing and all the ELD handling A good place to do this is generic_hdmi_build_controls, both because it is normally used to add controls (which is what you do), and because it is triggered after the pcm device is assigned. (A side note to Takashi: for some reason hda-emu has the calls to build_controls and build_pcms switched, compared to the real implementation.) -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

4 6

[alsa-devel] [PATCH] ASoC: sdp4430: Fix string for FM input name
by Peter Ujfalusi 26 Sep '11

26 Sep '11

The name contains invalid valid character (/), which causes problems when trying to create the debugfs directory structure: ASoC: Failed to create Aux/FM Stereo In debugfs file Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/omap/sdp4430.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/omap/sdp4430.c b/sound/soc/omap/sdp4430.c index a951774..d462f1a 100644 --- a/sound/soc/omap/sdp4430.c +++ b/sound/soc/omap/sdp4430.c @@ -88,7 +88,7 @@ static const struct snd_soc_dapm_widget sdp4430_twl6040_dapm_widgets[] = { SND_SOC_DAPM_MIC("Headset Mic", NULL), SND_SOC_DAPM_HP("Headset Stereophone", NULL), SND_SOC_DAPM_SPK("Earphone Spk", NULL), - SND_SOC_DAPM_INPUT("Aux/FM Stereo In"), + SND_SOC_DAPM_INPUT("FM Stereo In"), }; static const struct snd_soc_dapm_route audio_map[] = { @@ -113,8 +113,8 @@ static const struct snd_soc_dapm_route audio_map[] = { {"Earphone Spk", NULL, "EP"}, /* Aux/FM Stereo In: AFML, AFMR */ - {"AFML", NULL, "Aux/FM Stereo In"}, - {"AFMR", NULL, "Aux/FM Stereo In"}, + {"AFML", NULL, "FM Stereo In"}, + {"AFMR", NULL, "FM Stereo In"}, }; static int sdp4430_twl6040_init(struct snd_soc_pcm_runtime *rtd) -- 1.7.6

3 4