February 2014 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ALSA: hda - Improve loopback path lookups for AD1983
by Takashi Iwai 05 Feb '14

05 Feb '14

AD1983 has flexible loopback routes and the generic parser would take wrong path confusingly instead of taking individual paths via NID 0x0c and 0x0d. For avoiding it, limit the connections at these widgets so that the parser can think more straightforwardly. This fixes the regression of the missing line-in loopback on Dell machine. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70011 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_analog.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c index 195cd62cdce5..df3652ad15ef 100644 --- a/sound/pci/hda/patch_analog.c +++ b/sound/pci/hda/patch_analog.c @@ -491,6 +491,8 @@ static int ad1983_add_spdif_mux_ctl(struct hda_codec *codec) static int patch_ad1983(struct hda_codec *codec) { struct ad198x_spec *spec; + static hda_nid_t conn_0c[] = { 0x08 }; + static hda_nid_t conn_0d[] = { 0x09 }; int err; err = alloc_ad_spec(codec); @@ -501,6 +503,11 @@ static int patch_ad1983(struct hda_codec *codec) spec->gen.mixer_nid = 0x0e; spec->gen.beep_nid = 0x10; set_beep_amp(spec, 0x10, 0, HDA_OUTPUT); + + /* limit the loopback routes not to confuse the parser */ + snd_hda_override_conn_list(codec, 0x0c, ARRAY_SIZE(conn_0c), conn_0c); + snd_hda_override_conn_list(codec, 0x0d, ARRAY_SIZE(conn_0d), conn_0d); + err = ad198x_parse_auto_config(codec, false); if (err < 0) goto error; -- 1.8.5.2

1 0

[alsa-devel] [PATCH] ALSA: hda - Add missing mixer widget for AD1983
by Takashi Iwai 05 Feb '14

05 Feb '14

The mixer widget on AD1983 at NID 0x0e was missing in the commit [f2f8be43c5c9: ALSA: hda - Add aamix NID to AD codecs]. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70011 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_analog.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c index 50b2427f19ca..195cd62cdce5 100644 --- a/sound/pci/hda/patch_analog.c +++ b/sound/pci/hda/patch_analog.c @@ -498,6 +498,7 @@ static int patch_ad1983(struct hda_codec *codec) return err; spec = codec->spec; + spec->gen.mixer_nid = 0x0e; spec->gen.beep_nid = 0x10; set_beep_amp(spec, 0x10, 0, HDA_OUTPUT); err = ad198x_parse_auto_config(codec, false); -- 1.8.5.2

1 0

[alsa-devel] [PATCH] ALSA: hda/realtek - Avoid invalid COEFs for ALC271X
by Takashi Iwai 05 Feb '14

05 Feb '14

We've seen often problems after suspend/resume on Acer Aspire One AO725 with ALC271X codec as reported in kernel bugzilla, and it turned out that some COEFs doesn't work and triggers the codec communication stall. Since these magic COEF setups are specific to ALC269VB for some PLL configurations, the machine works even without these manual adjustment. So, let's simply avoid applying them for ALC271X. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 56a8f1876603..e16a71e586f0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4427,6 +4427,9 @@ static void alc269_fill_coef(struct hda_codec *codec) if (spec->codec_variant != ALC269_TYPE_ALC269VB) return; + /* ALC271X doesn't seem to support these COEFs (bko#52181) */ + if (!strcmp(codec->chip_name, "ALC271X")) + return; if ((alc_get_coef0(codec) & 0x00ff) < 0x015) { alc_write_coef_idx(codec, 0xf, 0x960b); -- 1.8.5.2

1 0

[alsa-devel] DMA screams on MSP
by Linus Walleij 04 Feb '14

04 Feb '14

Hi Lee, I get this in my bootlog nowadays (v3.14-rc1): [ 2.713897] dma dma0chan29: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.725158] dma dma0chan30: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.737457] dma dma0chan31: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.750793] dma dma0chan32: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.762145] dma dma0chan33: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.773376] dma dma0chan34: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.784606] dma dma0chan35: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.795837] dma dma0chan36: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.807067] dma dma0chan37: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.818298] dma dma0chan38: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.829528] dma dma0chan39: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.840728] dma dma0chan40: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.851959] dma dma0chan41: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 2.863189] dma dma0chan42: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels (...) [ 5.315887] dma dma0chan252: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 5.327209] dma dma0chan253: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 5.338531] dma dma0chan254: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels [ 5.349853] dma dma0chan255: [d40_validate_conf] Invalid device type (14) physical channel exeeds available physical channels (I patched dma40 to state the exact cause instead of just "invalid device type".) Like something (I guess ALSA SoC?) is trying real hard to get physical channel 14, but I can't seem to figure out what is going on. I will try to see if this also appears on the Snowball but I guess so? Any hints appreciated... Yours, Linus Walleij

2 3

[alsa-devel] [PATCH 1/2] devicetree: Add devicetree bindings documentation for the ADAU1977
by Lars-Peter Clausen 04 Feb '14

04 Feb '14

The ADAU1977 is a four channel audio ADC. It can either be connected to an I2C or a SPI bus. Both bindings are described in this document. Other than the standard I2C and SPI bus properties a regulator for the AVDD supply needs to be specified in the bindings. Optionally, if present in the hardware design, a regulator for the DVDD supply and a GPIO connected to the chips reset pin can be specified. The bindings also allow to specify the microphone bias voltage that should be used with the hardware design. Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Ian Campbell <ijc+devicetree(a)hellion.org.uk> Cc: Kumar Gala <galak(a)codeaurora.org> Cc: devicetree(a)vger.kernel.org Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- .../devicetree/bindings/sound/adi,adau1977.txt | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/adi,adau1977.txt diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.txt b/Documentation/devicetree/bindings/sound/adi,adau1977.txt new file mode 100644 index 0000000..3cf03d8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,adau1977.txt @@ -0,0 +1,58 @@ +Analog Devices ADAU1977, ADAU1978, ADAU1979 devicetree bindings + +The ADAU1977 is a four channel audio ADC. It can either be connected to an I2C +or a SPI bus. Both bindings are described in this document. Depending on the bus +type different properties must/can be specified. + +Shared required properties: + - compatible: Must be "adi,adau1977", "adi,adau1978" or adi,adau1979" + - AVDD-supply: A handle to the power supply connected to the AVDD pin + +Shared optional properties: + - DVDD-supply: A handle to the power supply connected to the DVDD pin. If + specified the internal LDO will be disabled. + - reset-gpios: GPIO chip handle and specifier that define which GPIO is + connected to the chips PD/RST pin. If not specified the reset pin is assumed + to be hardwired to VCC. + - adi,micbias: Configures the voltage setting for the MICBIAS pin. If not + specified the default value will be 8.5 Volts. This property is only valid + for the ADAU1977. + Valid values for this property are: + 0: 5.0V + 1: 5.5V + 2: 6.0V + 3: 6.5V + 4: 7.0V + 5: 7.5V + 6: 8.0V + 7: 8.5V + 8: 9.0V + +I2C required properties: + - reg: The I2C address of the chip + +SPI required properties: + - reg: The SPI chipselect signal of the SPI master associated with this chip + - spi-max-frequency: Maximum spi frequency to use. + +Examples: + +&i2c_bus { + adau1977: codec@11 { + compatible = "adi,adau1977"; + reg = <0x11>; + reset-gpios = <&gpio 5 0>; + AVDD-supply = <&codec_avdd_supply>; + DVDD-supply = <&codec_dvdd_supply>; + }; +}; + +&spi_bus { + adau1977: codec@1 { + compatible = "adi,adau1977"; + reg = <0x1>; + spi-max-frequency = <10000000>; + AVDD-supply = <&codec_avdd_supply>; + adi,micbias = <5>; + }; +}; -- 1.8.0

3 8

[alsa-devel] [PATCH 1/2 v2] mfd: wm5102: Update register patch
by Charles Keepax 04 Feb '14

04 Feb '14

Update the register patch based on latest evaluation of the device. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- Changed since v1: - Updated commit message on patch 2 Thanks, Charles drivers/mfd/wm5102-tables.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c index 1e9a4b2..f9b1e96 100644 --- a/drivers/mfd/wm5102-tables.c +++ b/drivers/mfd/wm5102-tables.c @@ -73,6 +73,7 @@ static const struct reg_default wm5102_revb_patch[] = { { 0x171, 0x0000 }, { 0x35E, 0x000C }, { 0x2D4, 0x0000 }, + { 0x4DC, 0x0900 }, { 0x80, 0x0000 }, }; -- 1.7.2.5

3 4

[alsa-devel] Strange sound of IDT 82hd206xx6 at font port in AC97 mode
by Randy Li 04 Feb '14

04 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello My mainboard is ECS A780GM-A, the sound chip in it is IDT 82HD206XX6, it shows that below 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) Subsystem: Elitegroup Computer Systems Device 2816 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at f9ff0000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: snd_hda_intel In my bios I don't have a switch to make the font port mode into AC97 or HD Audio. In windows you need to install a driver and set the font port into AC97. In Linux, you can use the font port, but it seems that audio channel is wrong, I can't hear the sound in some part of a film and I can hear the stranger accent of sound in the other part of a film(or a music). But all the 7.1 channel in the back ports can output the sound match my mircophone(all are the same). How to fix the problem? Kernel is 3.4.77 ayaka -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJS7z6nAAoJEPb4VsMIzTziIY0H/1Um6EnDRGIJ+4DLl6h5AgCl Bzcg3haOtFPX4j473TWOOUVqFjesjYqlvWIQaRLorGTNVVwBYRLef/MG4R4DKeti pXa6gu92UrkAxOtCWUE71u/snCkEzfe6py5uRV6ut2fL+FpewujHQYrxpyIlBmro MaWEN6BjMK2qUFCgx3te7ssKa0HEamjzIPa2HWEDKryNB4jTrBLjYEWng3dXESu3 czZIFgMCOIHOsRiaB9P1Z/7NTx0xgHsBOspKMUNS/s4hmP5kQ1cev04qrDCB9c2N /mUMStViGuZ13r8rO527KEsvuXc41Yt3V9b34wLi+FoIGZoKfDn+Y6K/3u63fD0= =y/91 -----END PGP SIGNATURE-----

3 9

[alsa-devel] [PATCH 1/2] mfd: wm5102: Update register patch
by Charles Keepax 03 Feb '14

03 Feb '14

Update the register patch based on latest evaluation of the device. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- drivers/mfd/wm5102-tables.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c index 1e9a4b2..f9b1e96 100644 --- a/drivers/mfd/wm5102-tables.c +++ b/drivers/mfd/wm5102-tables.c @@ -73,6 +73,7 @@ static const struct reg_default wm5102_revb_patch[] = { { 0x171, 0x0000 }, { 0x35E, 0x000C }, { 0x2D4, 0x0000 }, + { 0x4DC, 0x0900 }, { 0x80, 0x0000 }, }; -- 1.7.2.5

3 7

[alsa-devel] [PATCH 1/2] ASoC: h1940_uda1380: Don't modify runtime->hw
by Lars-Peter Clausen 03 Feb '14

03 Feb '14

Individual components are not supposed to modify the runtime->hw struct itself as it is manged by the ASoC core. If a component wants to limit the list of supported rates it should set a rate constraint. The h1940_uda1380 already does this, so it is safe to just remove the code that modifies runtime->hw. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/samsung/h1940_uda1380.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/sound/soc/samsung/h1940_uda1380.c b/sound/soc/samsung/h1940_uda1380.c index ec5cbdd..7a85ce8 100644 --- a/sound/soc/samsung/h1940_uda1380.c +++ b/sound/soc/samsung/h1940_uda1380.c @@ -66,10 +66,6 @@ static int h1940_startup(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; - runtime->hw.rate_min = hw_rates.list[0]; - runtime->hw.rate_max = hw_rates.list[hw_rates.count - 1]; - runtime->hw.rates = SNDRV_PCM_RATE_KNOT; - return snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, &hw_rates); -- 1.8.0

3 3

[alsa-devel] [PATCH 0/3] ASoC: davinci-mcasp: Cleanup patches
by Peter Ujfalusi 03 Feb '14

03 Feb '14

Hi Mark, The first patch in this series is the one which did not applied cleanly from my previous series. The other two is just generic code cleanup patches. Regards, Peter --- Peter Ujfalusi (3): ASoC: davinci-mcasp: Code cleanup in davinci_mcasp_hw_params() ASoC: davinci-mcasp: Rename platform data struct ASoC: davinci-mcasp: Remove long lines from suspend/resume callbacks include/linux/platform_data/davinci_asp.h | 4 +- sound/soc/davinci/davinci-mcasp.c | 86 +++++++++++++++---------------- 2 files changed, 46 insertions(+), 44 deletions(-) -- 1.8.5.3

2 4