January 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/3] Add device tree support of audio (ALC5632) on PAZ00 board and enable headphones autodetection.
by Leon Romanovsky 25 Jan '12

25 Jan '12

The following patchset is going to add device tree support of audio (ALC5632) on PAZ00 board and enable headphones autodetection. Leon Romanovsky (3): ARM: dt: tegra: Enable device tree audio on PAZ00 board. ARM: tegra: Enable the headphone detection gpio on PAZ00 board. ASoC: dt: tegra: Enable headphone autodetection on PAZ00 board. .../devicetree/bindings/sound/alc5632.txt | 24 ++++ .../bindings/sound/tegra-audio-alc5632.txt | 55 ++++++++++ arch/arm/boot/dts/tegra-paz00.dts | 30 ++++- arch/arm/mach-tegra/board-paz00-pinmux.c | 1 + arch/arm/mach-tegra/board-paz00.h | 3 + sound/soc/tegra/tegra_alc5632.c | 114 ++++++++++++++++++-- 6 files changed, 212 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/alc5632.txt create mode 100644 Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt -- 1.7.3.4

1 0

Re: [alsa-devel] soc-dsp programming model for loopbacks
by Mark Brown 25 Jan '12

25 Jan '12

On Tue, Jan 24, 2012 at 01:36:18PM -0800, Pierre-Louis Bossart wrote: > Now if the FM radio routing is handled with a digital loopback on the > application processor audio dsp (omap-abe, Intel SST, etc), then soc-dsp > will need to be used. And for a simple FM playback, I need to Note that the use of soc-dsp isn't required for on-SoC DSPs - it really depends on how the hardware looks. If the DSP external format is very strongly tied to the format used to DMA to and from main memory (or other interfaces) then soc-dsp is what you need, if the DSP is able to rewrite formats more flexibly then it should be more direct to model it as a CODEC device with whatever number of DAIs and routing between them.

2 4

[alsa-devel] [PATCH] ASoC: wm5100: Fix microphone configuration
by Mark Brown 25 Jan '12

25 Jan '12

We need to write the configuration for each microphone to a different register. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm5100.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c index 0c82f38..51b281b 100644 --- a/sound/soc/codecs/wm5100.c +++ b/sound/soc/codecs/wm5100.c @@ -2610,6 +2610,13 @@ static const struct regmap_config wm5100_regmap = { .cache_type = REGCACHE_RBTREE, }; +static const unsigned int wm5100_mic_ctrl_reg[] = { + WM5100_IN1L_CONTROL, + WM5100_IN2L_CONTROL, + WM5100_IN3L_CONTROL, + WM5100_IN4L_CONTROL, +}; + static __devinit int wm5100_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { @@ -2740,7 +2747,7 @@ static __devinit int wm5100_i2c_probe(struct i2c_client *i2c, } for (i = 0; i < ARRAY_SIZE(wm5100->pdata.in_mode); i++) { - regmap_update_bits(wm5100->regmap, WM5100_IN1L_CONTROL, + regmap_update_bits(wm5100->regmap, wm5100_mic_ctrl_reg[i], WM5100_IN1_MODE_MASK | WM5100_IN1_DMIC_SUP_MASK, (wm5100->pdata.in_mode[i] << -- 1.7.9.rc1

1 0

[alsa-devel] salsa-lib-0.1.2 alsa/pcm_macros.h (on Linux, at least)
by John P. Hartmann 25 Jan '12

25 Jan '12

The salsa macros do not compile with -Wall -Werror. The culprit is the use of "access", which is also a UNIX function. This function is defined unistd.h, which is included by stddef.h. And stddef.h is one of the files mangled into the belly of GCC. So it is a royal mess, and nobody's fault in particular, but could we please have the header file updated, for example to use "Acc" rather than "access" for the parameter? Thanks,

2 1

[alsa-devel] [PATCH] ASoC: wm5100: Make sure we switch to button reporting mode
by Mark Brown 25 Jan '12

25 Jan '12

When we have identified an accessory make sure we've flagged that we've done so in order to make sure we always report buttons and don't continue to polarity flip. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm5100.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c index 6a04ee2..0c82f38 100644 --- a/sound/soc/codecs/wm5100.c +++ b/sound/soc/codecs/wm5100.c @@ -2161,6 +2161,7 @@ static void wm5100_micd_irq(struct wm5100_priv *wm5100) if (wm5100->jack_detecting) { dev_dbg(wm5100->dev, "Microphone detected\n"); wm5100->jack_mic = true; + wm5100->jack_detecting = false; snd_soc_jack_report(wm5100->jack, SND_JACK_HEADSET, SND_JACK_HEADSET | SND_JACK_BTN_0); @@ -2199,6 +2200,7 @@ static void wm5100_micd_irq(struct wm5100_priv *wm5100) SND_JACK_BTN_0); } else if (wm5100->jack_detecting) { dev_dbg(wm5100->dev, "Headphone detected\n"); + wm5100->jack_detecting = false; snd_soc_jack_report(wm5100->jack, SND_JACK_HEADPHONE, SND_JACK_HEADPHONE); -- 1.7.9.rc1

1 0

[alsa-devel] [PATCH] ASoC: soc-pcm: msbits constraint: Drop 8 and 16 bit sample sizes
by Peter Ujfalusi 25 Jan '12

25 Jan '12

As per discussion we can safely ignore the 8 and 16 bit sample sizes when applying the msbits constraint. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- Hi Mark, As we discussed [1] let's remove the 8 and 16 bit size from the array. [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-January/048276.ht… Regards, Peter sound/soc/soc-pcm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 3268901..93be95b 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -68,7 +68,7 @@ static int soc_pcm_apply_symmetry(struct snd_pcm_substream *substream, * like the DAC/ADC resolution to use but there isn't right now. */ static int sample_sizes[] = { - 8, 16, 24, 32, + 24, 32, }; static void soc_pcm_apply_msb(struct snd_pcm_substream *substream, -- 1.7.8.3

2 1

[alsa-devel] ALSA release version 1.0.25
by Jaroslav Kysela 25 Jan '12

25 Jan '12

Hello all, the ALSA release version 1.0.25 is available for download at http://www.alsa-project.org . All packages were updated. The full changelog can be obtained from: http://www.alsa-project.org/main/index.php/Changes_v1.0.24_v1.0.25 Have fun with it, Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.

1 0

[alsa-devel] soc-dsp programming model for loopbacks
by Pierre-Louis Bossart 24 Jan '12

24 Jan '12

Hi, I've been doing some work on audio loopback (FM radio, BT, Modem -> audio codec), and I am somewhat confused by the soc-dsp programming model. Let me take the FM radio example: If the FM radio is directly connected to the audio codec, my understanding is that changing the routing with codec controls will trigger the DAPM logic, which will turn on everything that needs to be on. Very simple, no matter if the FM-codec link is analog or digital. Now if the FM radio routing is handled with a digital loopback on the application processor audio dsp (omap-abe, Intel SST, etc), then soc-dsp will need to be used. And for a simple FM playback, I need to 1. configure the audio codec routing for output selection 2. open a virtual front-end for FM capture 3. configure the DSP routing to link capture front-end to I2S1 backend (FM interface) 4. open a virtual front-end for FM playback 5. configure the DSP routing to link playback front-end to I2S2 backend (codec interface) That seems complicated. To some extent, having the ability to have two back-ends connected together would make more sense, and would simplify the programming model a great deal. User-space code would be similar for loopbacks internal to the codecs or handled on the application processor. This would apply to Bluetooth and modem connections as well. Without this capability, we will end-up with multiple 'virtual' front-ends (6 in my case), making user-space code quite complex. Looking at the current soc-dsp code, I saw that each back-end is supposed to have at least one front-end client, and the impact of my proposal seems fairly important. Before I start looking further into code changes, I wanted to see if my understanding is correct and if there are other ideas to simplify loopbacks. Thanks for your feedback, -Pierre

1 0

[alsa-devel] [PATCH] ASoC: wm8962: Optimise power consumption for IN4 DC measurement usage
by Mark Brown 24 Jan '12

24 Jan '12

When the hardware is configured with one or both of the IN4 inputs used for DC measurement (with no DC blocking capacitor connected) then we can improve power consumption slightly in idle modes by applying a register write sequence. Provide platform data to enable this, implemented using a regmap patch. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/wm8962.h | 6 ++++++ sound/soc/codecs/wm8962.c | 18 ++++++++++++++++++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/include/sound/wm8962.h b/include/sound/wm8962.h index f131cd2..39477a7 100644 --- a/include/sound/wm8962.h +++ b/include/sound/wm8962.h @@ -50,6 +50,12 @@ struct wm8962_pdata { bool irq_edge; bool spk_mono; /* Speaker outputs tied together as mono */ + + /** + * This flag should be set if one or both IN4 inputs is wired + * in a DC measurement configuration. + */ + bool in4_dc_measure; }; #endif diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 9faef60..f1fd630 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -3668,6 +3668,13 @@ static struct snd_soc_codec_driver soc_codec_dev_wm8962 = { .volatile_register = wm8962_soc_volatile, }; +/* Improve power consumption for IN4 DC measurement mode */ +static const struct reg_default wm8962_dc_measure[] = { + { 0xfd, 0x1 }, + { 0xcc, 0x40 }, + { 0xfd, 0 }, +}; + static const struct regmap_config wm8962_regmap = { .reg_bits = 16, .val_bits = 16, @@ -3683,6 +3690,7 @@ static const struct regmap_config wm8962_regmap = { static __devinit int wm8962_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { + struct wm8962_pdata *pdata = dev_get_platdata(&i2c->dev); struct wm8962_priv *wm8962; unsigned int reg; int ret, i; @@ -3761,6 +3769,16 @@ static __devinit int wm8962_i2c_probe(struct i2c_client *i2c, goto err_regmap; } + if (pdata && pdata->in4_dc_measure) { + ret = regmap_register_patch(wm8962->regmap, + wm8962_dc_measure, + ARRAY_SIZE(wm8962_dc_measure)); + if (ret != 0) + dev_err(&i2c->dev, + "Failed to configure for DC mesurement: %d\n", + ret); + } + regcache_cache_only(wm8962->regmap, true); ret = snd_soc_register_codec(&i2c->dev, -- 1.7.9.rc1

1 0

[alsa-devel] default is working, but hw:0,0 is do not...
by Dmitrij K 24 Jan '12

24 Jan '12

Hi all. I have problem with openning a device for playback. this is working code: snd_pcm_open(&handle, "default", SND_PCM_STREAM_PLAYBACK, 0); but this is not working: snd_pcm_open(&handle, "hw:0,0", SND_PCM_STREAM_PLAYBACK, 0); I get this is: Device or resource busy PS: I have been started the `phonon' (KDE sound daemon), and the amarok (audio player). My question: what I need to do for correct open "hw:0,0" for multiply playback ? Thanks. The Best Regards.

2 2