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

[alsa-devel] Enable docking station speaker jack for new Lenovo Thinkpads
by Mario 06 Aug '12

06 Aug '12

Hi all, for new Lenovo Thinkpads (mine T530, will probably affect all new [TXW][45]30 models), the model=thinkpad module option does not enable the speaker jack of the docking station. Sound works perfectly with the laptop, only the docking station needs extra work. I managed to get it work using hda-analyzer. It produced the following diff: Diff for codec 0/0 (0x10ec0269): --- +++ @@ -210,28 +210,28 @@ Unsolicited: tag=0x00, enabled=0 Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 - Amp-Out vals: [0x80 0x80] + Amp-Out vals: [0x00 0x00] Pincap 0x00003734: IN OUT Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE - Pin-ctls: 0x20: IN VREF_HIZ - Unsolicited: tag=0x00, enabled=0 - Power: setting=D0, actual=D0 - Connection: 2 - 0x0c* 0x0d + Pin-ctls: 0x40: OUT VREF_HIZ + Unsolicited: tag=0x00, enabled=0 + Power: setting=D0, actual=D0 + Connection: 2 + 0x0c 0x0d* Node 0x1c [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x1d [Pin Complex] wcaps 0x400400: Mono Pincap 0x00000020: IN Pin Default 0x40138205: [N/A] Speaker at Ext N/A Conn = ATAPI, Color = Purple DefAssociation = 0x0, Sequence = 0x5 Pin-ctls: 0x20: IN Power: setting=D0, actual=D0 Relevent lspci entry: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Chip: Realtek ALC269VC Further alsa-info: http://www.alsa-project.org/db/?f=e297bdda4fd099425516c7c831e28a2c7d8ae6b6 Unfortunately, I failed to create a working hda-verb script. I can change the out-pin with: hda-verb /dev/snd/hwC0D0 0x1b SET_PIN_WIDGET_CONTROL 0x40 but I did not find the command to unmute the channel. Can anyone tell me which options are necessary and can this easily be fixed in the kernel? Also, hda-analyzer showed me two mixer devices, they produce a slightly different sound. I don't know if this is important. Thank you very much! Mario

6 20

Re: [alsa-devel] [PATCH] ASoC: sgtl5000: remove device tree probe match table
by Mark Brown 06 Aug '12

06 Aug '12

On Mon, Aug 06, 2012 at 06:00:31PM +0800, Hui Wang wrote: > The sgtl5000 codec driver is an i2c driver instead of a platform > driver, current of_i2c subsystem will convert an i2c device node > into a traditional i2c device, the of_match_table is not used. No, this is a regression - even though we can take a good guess for I2C devices it is always good to provide a compatible property to avoid ambiguity.

1 0

Re: [alsa-devel] [PATCH] sound: print small buffers via %*ph[C]
by Takashi Iwai 06 Aug '12

06 Aug '12

At Thu, 2 Aug 2012 16:52:41 +0300, Andy Shevchenko wrote: > > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Applied now. Thanks. Takashi > --- > sound/isa/gus/interwave.c | 5 ++--- > sound/usb/6fire/firmware.c | 5 ++--- > 2 files changed, 4 insertions(+), 6 deletions(-) > > diff --git a/sound/isa/gus/interwave.c b/sound/isa/gus/interwave.c > index a76bc8d..3fc8b66 100644 > --- a/sound/isa/gus/interwave.c > +++ b/sound/isa/gus/interwave.c > @@ -443,9 +443,8 @@ static void __devinit snd_interwave_detect_memory(struct snd_gus_card * gus) > for (i = 0; i < 8; ++i) > iwave[i] = snd_gf1_peek(gus, bank_pos + i); > #ifdef CONFIG_SND_DEBUG_ROM > - printk(KERN_DEBUG "ROM at 0x%06x = %02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x\n", bank_pos, > - iwave[0], iwave[1], iwave[2], iwave[3], > - iwave[4], iwave[5], iwave[6], iwave[7]); > + printk(KERN_DEBUG "ROM at 0x%06x = %*phC\n", bank_pos, > + 8, iwave); > #endif > if (strncmp(iwave, "INTRWAVE", 8)) > continue; /* first check */ > diff --git a/sound/usb/6fire/firmware.c b/sound/usb/6fire/firmware.c > index 56ad923..a1d9b07 100644 > --- a/sound/usb/6fire/firmware.c > +++ b/sound/usb/6fire/firmware.c > @@ -346,11 +346,10 @@ static int usb6fire_fw_check(u8 *version) > if (!memcmp(version, known_fw_versions + i, 4)) > return 0; > > - snd_printk(KERN_ERR PREFIX "invalid fimware version in device: " > - "%02x %02x %02x %02x. " > + snd_printk(KERN_ERR PREFIX "invalid fimware version in device: %*ph. " > "please reconnect to power. if this failure " > "still happens, check your firmware installation.", > - version[0], version[1], version[2], version[3]); > + 4, version); > return -EINVAL; > } > > -- > 1.7.10.4 >

1 0

[alsa-devel] multistreaming realtek hda codec
by Raymond Yau 06 Aug '12

06 Aug '12

>I have been trying to get a second codec working on a computer that has two codecs - one for the front speakers, >one for the rear panel line outs. So far I haven't been able to get this working. I received this message from the manufacturer of the board: >"R&D has determined that the ability to have selectable or dual line-out in the current hardware design is >limited by Linux OS kernel. The HDA sound driver did not anticipate and did not include support for two >identical audio codecs (ALC888) in a system - therefore, the 2nd codec cannot be successfully >initialized. To fix this issue, the Linux kernel level sound driver (controls function) would need to be >modified to cover full functional control of the 2nd codec. This modification is very challenging and >involves time, risk, and potential unknown side effects - because we are talking about modifying the >kernel of the Linux OS and different version of kernel may have different structures as well. Do you mean multiple streaming ? The ALC888 series are high-performance 7.1+2 Channel High Definition Audio Codecs providing ten DAC channels that simultaneously support 7.1 sound playback, plus 2 channels of independent stereo sound output (multiple streaming) through the front panel stereo outputs Both via and adi hda codecs support multiple streaming by independent headphone, you just need to assign spec->alt_dac_nid and spec->analog_stream_alt_playback in patch_realtek.c when the hda controller support enough stream and hda codec has a dac for the headphone.

1 0

[alsa-devel] [PATCH 3/3] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data
by Julia Lawall 04 Aug '12

04 Aug '12

From: Julia Lawall <Julia.Lawall(a)lip6.fr> Using kfree to free data allocated with devm_kzalloc causes double frees. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x; @@ x = devm_kzalloc(...) ... ?-kfree(x); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr> --- The kfrees were introduced in b761c0ca. sound/soc/soc-core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index f81c597..86d7a36 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -4136,7 +4136,6 @@ int snd_soc_of_parse_audio_routing(struct snd_soc_card *card, dev_err(card->dev, "Property '%s' index %d could not be read: %d\n", propname, 2 * i, ret); - kfree(routes); return -EINVAL; } ret = of_property_read_string_index(np, propname, @@ -4145,7 +4144,6 @@ int snd_soc_of_parse_audio_routing(struct snd_soc_card *card, dev_err(card->dev, "Property '%s' index %d could not be read: %d\n", propname, (2 * i) + 1, ret); - kfree(routes); return -EINVAL; } }

2 1

Re: [alsa-devel] [PATCH 1/6] ASoC: dapm: If one widget fails, do not force all subsequent widgets to fail too
by Mark Brown 04 Aug '12

04 Aug '12

On Thu, Aug 02, 2012 at 08:45:18AM +0100, Lee Jones wrote: > Over time, the requests for Maintainers have Snowballed (pun intended). My > task now seems to be enabling drivers for Device Tree _and_ fix all > associated driver bugs, including any requested restructuring and API One thing to bear in mind with device tree is that it's all about defining an ABI - it's supposed to be stable and OS agnostic so it puts a lot of pressure on to really address quality problems that become visible in the bindings. This stuff is much less critical with platform data, it's relatively easy to change. > adoption. What you fail to notice is that I am only one person, and hopping > all over the code-base trying to do everyone's bidding is no mean feat. In It's fairly obvious that it's only you, or at least only you posting stuff (I know sometimes there are bigger teams behind people) - the pressure you're under to get something in is very clear. A big part of what I'm saying here is that it would be really helpful if could you slow down a bit, discuss problems more and avoid cutting corners so much. This is likely to save you time overall, you'll have a much higher success rate and you'll get much better feedback if it's clear what's going on and that there's an interest in understanding the issues. If you need to focus on device tree enablement and there are underlying problems in the subsystems you're looking at perhaps you need to push back on whoever's asking you to do the work and say you need the domain experts to pitch in and help you out. > reality I am no more obliged to fix driver bugs than you are. In fact as > the Maintainer of some of these subsystems, perhaps you could even help out > a bit? You're not telling us about the problems you see so it's very difficult for anyone to help you. For example with this patch the only information you've sent is the patch and the fact that you're seeing the error you're ignoring going off on the system you're working with (which I had to ask to find out about...). You've not shown the error message or provided any other hint which would help anyone understand why the error might be occuring and what a good solution to the problem is. Ola's guess seems very likely but nobody's got enough information to confirm that unless there's been some off-list ST/Linaro communication. Obviously with the stuff that's device specific you also have to contend with the fact that you're working on hardware which just isn't all that widely available and quite possibly has closed datasheets. > We are all trying to do good things here. Please try not to be too over- > critical. We all know Mainlining is a good thing. Perhaps less people > would be so frightened of it, thus more people would do it if the reviews > weren't such a ball-ache ( for want of a better expression :) ). This is a two way thing - one of the tools that maintainers have to try to drive up the quality of the code is to push back on poor quality submissions and devote less bandwith to sources of those submissions. It is true that there's a bunch of people who seem to view review as being just an annoying obstacle to be dealt with with the minimum possible effort but in practice all that does is make things more painful for everyone, they do tend to be more noticable because "applied, thanks" doesn't make for a big thread.

2 2

[alsa-devel] Recording sound from microphone isn't good working that playback sound is distortion.
by Xiaoyong Wen 04 Aug '12

04 Aug '12

Hi, alsa-devel Platform: S3C6410, WM9713G codec with AC'97, Linux kernel 2.6.36. ALSL 1.0.23 lib and utils. Test process: 1. aplay WAV file is good working #aplay -D 'hw:0,0' -c 2 /opt/music.wav 2. arecord WAV file from Line in is good working. #arecord -D 'hw:0,0' -r 48000 -f S16_LE -c 2 | aplay -D 'hw:0,0' -c 2 & 3. Recording sound from microphone isn't good working that playback sound is distortion. #arecord -D 'hw:0,0' -r 48000 -f S16_LE -c 2 | aplay -D 'hw:0,0' -c 2 & or #arecord -d 10 -fdat test2.wav I hear the sound is very distortion and low. ~~~~~~~~~~~~~~~~~~~~~~~~~~ If I excute "amixer cset numid=9 3; amixer cset numid=7 31; amixer cset numid=87 on; amixer cset numid=6 31,31" command, and then volume is high. Please help me to fix up this bug, thanks. Best regards. Xiaoyong Wen, <wen_kernel(a)163.com>, 2012-07-31, 14:46:17.

2 1

[alsa-devel] ASoC updates for 3.6
by Mark Brown 03 Aug '12

03 Aug '12

The following changes since commit 15d47763b354256053c390a9b7bc9f2b4f197711: Merge branch 'for-3.5' into for-3.6 (2012-07-23 10:45:07 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.6 for you to fetch changes up to 98d3088e534a2a61f6690b5426909b0c3b57a785: ASoC: core: Fix check before defaulting to regmap (2012-08-02 11:43:45 +0100) (this is a new subkey on my key which I just realised I didn't upload to the server - will do that on Monday.) ---------------------------------------------------------------- ASoC: Additional updates for 3.6 A few updates for issues discovered during the merge window, the main one being the fix for the issues with defaulting to use of regmap without properly checking if there was I/O in place already. ---------------------------------------------------------------- Dong Aisheng (4): ASoC: mxs-saif: fix clock prepare and enable unbalance issue ASoC: mxs-saif: set a base clock rate for EXTMASTER mode work ASoC: sgtl5000: remove unneeded snd_soc_dapm_new_widgets in probe ASoC: sgtl5000: enable VAG_POWER for LINE_IN Fabio Estevam (1): ASoC: mc13783: Provide codec->control_data Guillaume Gardet (1): ASoC: omap: Add missing modules aliases to get sound working on omap devices Lee Jones (2): ASoC: ux500: Include the correct header files ASoC: ab8500: Inform SoC Core that we have our own I/O arrangements Manuel Lauss (1): ASoC: AC97 doesn't use regmap by default Mark Brown (4): ASoC: wm8994: Ensure there are enough BCLKs for four channels ASoC: wm8994: Hold runtime PM reference while handling mic and jack IRQs ASoC: wm8962: Allow VMID time to fully ramp ASoC: core: Fix check before defaulting to regmap Roland Stigge (2): sound: tegra_wm8903: Adjust to of_get_named_gpio() change sound: tegra_alc5632: Adjust to of_get_named_gpio() change sound/soc/codecs/ab8500-codec.c | 4 ++++ sound/soc/codecs/ad1980.c | 1 + sound/soc/codecs/mc13783.c | 2 ++ sound/soc/codecs/sgtl5000.c | 3 +-- sound/soc/codecs/stac9766.c | 1 + sound/soc/codecs/wm8962.c | 3 +++ sound/soc/codecs/wm8994.c | 15 ++++++++++++++- sound/soc/codecs/wm9712.c | 1 + sound/soc/codecs/wm9713.c | 1 + sound/soc/mxs/mxs-saif.c | 24 ++++++++++++++++++++++++ sound/soc/omap/omap-mcbsp.c | 1 + sound/soc/omap/omap-pcm.c | 1 + sound/soc/soc-core.c | 2 +- sound/soc/tegra/tegra_alc5632.c | 2 +- sound/soc/tegra/tegra_wm8903.c | 10 +++++----- sound/soc/ux500/ux500_msp_dai.c | 2 +- sound/soc/ux500/ux500_msp_i2s.c | 2 +- sound/soc/ux500/ux500_msp_i2s.h | 2 +- 18 files changed, 64 insertions(+), 13 deletions(-)

2 5

[alsa-devel] Clock generators in ASoC setups
by Daniel Mack 03 Aug '12

03 Aug '12

Hi Mark and Liam, some board I'm working on feature chips (connected via I2C) that are in charge of generating clocks for both the CPU DAI and the codecs. Previously, I configured them manually in platform specific code, but I wonder if there's a better, more generic way to get the job done, especially with regards to DT driven boards? Thanks, Daniel

2 3

[alsa-devel] [PATCH V4 12/16] ALSA: HDA: Make hda sound card usable for Loongson.
by Huacai Chen 03 Aug '12

03 Aug '12

Lemote A1004(Laptop) and A1205(All-In-One) use Conexant's hda codec, this patch modify patch_conexant.c to add Lemote specific code. Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: Hongliang Tao <taohl(a)lemote.com> Signed-off-by: Hua Yan <yanh(a)lemote.com> Cc: alsa-devel(a)alsa-project.org --- include/linux/pci_ids.h | 2 + sound/pci/hda/patch_conexant.c | 52 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 52 insertions(+), 2 deletions(-) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index fc35260..b28270e 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2918,3 +2918,5 @@ #define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 #define PCI_VENDOR_ID_OCZ 0x1b85 + +#define PCI_VENDOR_ID_LEMOTE 0x1c06 diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 1436118..6bbac39 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -142,6 +142,7 @@ struct conexant_spec { unsigned int thinkpad:1; unsigned int hp_laptop:1; unsigned int asus:1; + unsigned int lemote:1; unsigned int pin_eapd_ctrls:1; unsigned int fixup_stereo_dmic:1; @@ -2280,7 +2281,7 @@ static void cxt5066_automic(struct hda_codec *codec) cxt5066_thinkpad_automic(codec); else if (spec->hp_laptop) cxt5066_hp_laptop_automic(codec); - else if (spec->asus) + else if (spec->asus || spec->lemote) cxt5066_asus_automic(codec); } @@ -2913,6 +2914,32 @@ static const struct hda_verb cxt5066_init_verbs_hp_laptop[] = { { } /* end */ }; +static struct hda_verb cxt5066_init_verbs_lemote[] = { + {0x14, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1: Connection index: 0 */ + {0x19, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | CONEXANT_HP_EVENT}, + {0x1b, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | CONEXANT_MIC_EVENT}, + + /* DAC2: unused */ + {0x11, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE}, + + /* ADC2, ADC3: unused */ + {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, + {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)}, + {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x16, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, + {0x16, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)}, + {0x16, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x16, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + + /* Disable digital microphone port */ + {0x23, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + + /* Disable SPDIF */ + {0x20, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + { } /* end */ +}; + /* initialize jack-sensing, too */ static int cxt5066_init(struct hda_codec *codec) { @@ -2950,6 +2977,8 @@ enum { CXT5066_THINKPAD, /* Lenovo ThinkPad T410s, others? */ CXT5066_ASUS, /* Asus K52JU, Lenovo G560 - Int mic at 0x1a and Ext mic at 0x1b */ CXT5066_HP_LAPTOP, /* HP Laptop */ + CXT5066_LEMOTE_A1004, /* Lemote Laptop A1004 */ + CXT5066_LEMOTE_A1205, /* Lemote All-In-One A1205 */ CXT5066_AUTO, /* BIOS auto-parser */ CXT5066_MODELS }; @@ -2963,6 +2992,8 @@ static const char * const cxt5066_models[CXT5066_MODELS] = { [CXT5066_THINKPAD] = "thinkpad", [CXT5066_ASUS] = "asus", [CXT5066_HP_LAPTOP] = "hp-laptop", + [CXT5066_LEMOTE_A1004] = "lemote-laptop-a1004", + [CXT5066_LEMOTE_A1205] = "lemote-aio-a1205", [CXT5066_AUTO] = "auto", }; @@ -2995,6 +3026,8 @@ static const struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo U350", CXT5066_ASUS), SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo G560", CXT5066_ASUS), SND_PCI_QUIRK(0x17aa, 0x3938, "Lenovo G565", CXT5066_AUTO), + SND_PCI_QUIRK(PCI_VENDOR_ID_LEMOTE, 0x2011, "Lemote A1004", CXT5066_LEMOTE_A1004), + SND_PCI_QUIRK(PCI_VENDOR_ID_LEMOTE, 0x2012, "Lemote A1205", CXT5066_LEMOTE_A1205), SND_PCI_QUIRK(0x1b0a, 0x2092, "CyberpowerPC Gamer Xplorer N57001", CXT5066_AUTO), {} }; @@ -3075,7 +3108,22 @@ static int patch_cxt5066(struct hda_codec *codec) spec->port_d_mode = 0; spec->mic_boost = 3; /* default 30dB gain */ break; - + case CXT5066_LEMOTE_A1004: + case CXT5066_LEMOTE_A1205: + codec->patch_ops.init = cxt5066_init; + codec->patch_ops.unsol_event = cxt5066_unsol_event; + spec->init_verbs[spec->num_init_verbs] = + cxt5066_init_verbs_lemote; + spec->num_init_verbs++; + spec->lemote = 1; + spec->mixers[spec->num_mixers++] = cxt5066_mixer_master; + spec->mixers[spec->num_mixers++] = cxt5066_mixers; + /* no S/PDIF out */ + /* input source automatically selected */ + spec->input_mux = NULL; + spec->port_d_mode = 0; + spec->mic_boost = 3; /* default 30dB gain */ + break; case CXT5066_OLPC_XO_1_5: codec->patch_ops.init = cxt5066_olpc_init; codec->patch_ops.unsol_event = cxt5066_olpc_unsol_event; -- 1.7.7.3

2 3