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

[alsa-devel] [PATCH] ALSA: hda - Fix 'Beep Playback Switch' with no underlying mute switch
by David Henningsson 14 Aug '12

14 Aug '12

Some conexant devices has no mute capability on their Beep widgets. This patch makes sure we don't try setting mutes on those widgets. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- Another Beep fix. It's not that I'm suddenly obsessed with beeping; it's my automated test tool that finds them :-) I admit "knew->info == snd_hda_mixer_amp_switch_info" and "kctl->private_value = 0x10000" looks a bit hacky, feel free to suggest something more elegant if you wish. Example alsa info: codecs/canonical/cx20590-lenovo-thinkpad-t420-ccert-201102-7230 sound/pci/hda/hda_beep.c | 6 ++++-- sound/pci/hda/patch_conexant.c | 8 +++++++- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_beep.c b/sound/pci/hda/hda_beep.c index d26ae65..3a72543 100644 --- a/sound/pci/hda/hda_beep.c +++ b/sound/pci/hda/hda_beep.c @@ -237,9 +237,9 @@ int snd_hda_mixer_amp_switch_get_beep(struct snd_kcontrol *kcontrol, { struct hda_codec *codec = snd_kcontrol_chip(kcontrol); struct hda_beep *beep = codec->beep; - if (beep && !beep->enabled) { + if (beep && (!get_amp_nid(kcontrol) || !beep->enabled)) { ucontrol->value.integer.value[0] = - ucontrol->value.integer.value[1] = 0; + ucontrol->value.integer.value[1] = beep->enabled; return 0; } return snd_hda_mixer_amp_switch_get(kcontrol, ucontrol); @@ -263,6 +263,8 @@ int snd_hda_mixer_amp_switch_put_beep(struct snd_kcontrol *kcontrol, enable |= *valp; snd_hda_enable_beep_device(codec, enable); } + if (!get_amp_nid(kcontrol)) + return 0; return snd_hda_mixer_amp_switch_put(kcontrol, ucontrol); } EXPORT_SYMBOL_HDA(snd_hda_mixer_amp_switch_put_beep); diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 5e22a8f..fa36c5e 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -537,12 +537,18 @@ static int conexant_build_controls(struct hda_codec *codec) /* create beep controls if needed */ if (spec->beep_amp) { const struct snd_kcontrol_new *knew; + unsigned int caps; + caps = snd_hda_param_read(codec, spec->beep_amp, AC_PAR_AMP_OUT_CAP); + for (knew = cxt_beep_mixer; knew->name; knew++) { struct snd_kcontrol *kctl; kctl = snd_ctl_new1(knew, codec); if (!kctl) return -ENOMEM; - kctl->private_value = spec->beep_amp; + if (knew->info == snd_hda_mixer_amp_switch_info && !(caps & AC_AMPCAP_MUTE)) + kctl->private_value = 0x10000; /* Mono channel, no nid */ + else + kctl->private_value = spec->beep_amp; err = snd_hda_ctl_add(codec, 0, kctl); if (err < 0) return err; -- 1.7.9.5

2 5

[alsa-devel] [PATCH v2 0/9] ARM/ASoC: OMAP McBSP device tree support
by Peter Ujfalusi 14 Aug '12

14 Aug '12

Hello, Changes since v1: - ICLK workaround for the sidetone module has been kept for legacy mode. Intro mail ffrom v1 (updated): in order to be able to add DT support for the McBSP driver which is used on all OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack: - Removing callbacks used by the driver for - clock re-parenting (code moved to sound driver) - FSR/CLKR mux configuration (from now on it need to be done at board level) This mux is board specific and depends on the wiring. - Replaced the cpu_is_omap* checks with future proof check. - The FIFO was not enabled on OMAP2430 SoC It has been tested on BeagleBoard (with legacy and DT boot). The series changes McBSP related files mostly. It would be great if the whole series could go via audio tree (if the patches are OK and it is fine by Tony). For DT booted kernel on OMAP3 proper ICLK woraround need to be implemented. At the moment I don't see this as a stopper since we can not properly boot OMAP3 devices (especially rx51 which is using the ST). Other OMAP revisions does not have ST block so the missing workaround is not going to hurt them. I'm working on a solution which can replace the current workaround with a generic implementation to support DT and non DT booted kernels. Regards, Peter --- Peter Ujfalusi (9): ARM/ASoC: omap-mcbsp: Move OMAP2+ clock parenting code to ASoC driver ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430 ARM: OMAP: board-am3517evm: Configure McBSP1 CLKR/FSR signal source ASoC: am3517evm: Do not configure McBSP1 CLKR/FSR signal muxing ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code ASoC: omap-mcbsp: Remove unused defines ASoC: omap-mcbsp: Remove cpu_is_omap* checks from the code ARM: OMAP2+: McBSP: Do not create legacy devices when booting with DT data ASoC: omap-mcbsp: Add device tree bindings .../devicetree/bindings/sound/omap-mcbsp.txt | 45 +++++++ arch/arm/mach-omap2/board-am3517evm.c | 13 ++ arch/arm/mach-omap2/mcbsp.c | 126 +------------------ arch/arm/plat-omap/include/plat/mcbsp.h | 2 - sound/soc/omap/am3517evm.c | 20 +--- sound/soc/omap/mcbsp.c | 54 ++++----- sound/soc/omap/mcbsp.h | 3 - sound/soc/omap/omap-mcbsp.c | 106 +++++++++++----- sound/soc/omap/omap-mcbsp.h | 20 --- 9 files changed, 162 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/omap-mcbsp.txt -- 1.7.8.6

2 11

[alsa-devel] [PATCH] ASoC: jack: Always notify full jack status
by Mark Brown 13 Aug '12

13 Aug '12

Don't just notify for the bits we've updated, notify the full state of the jack otherwise users might get confused by misleading reports. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-jack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index e19fd6d..9ece60a 100644 --- a/sound/soc/soc-jack.c +++ b/sound/soc/soc-jack.c @@ -98,7 +98,7 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) } /* Report before the DAPM sync to help users updating micbias status */ - blocking_notifier_call_chain(&jack->notifier, status, jack); + blocking_notifier_call_chain(&jack->notifier, jack->status, jack); snd_soc_dapm_sync(dapm); -- 1.7.10.4

1 0

[alsa-devel] Moving hda-analyzer to alsa-tools?
by Takashi Iwai 13 Aug '12

13 Aug '12

Hi Jaroslav, do you have any plan to move hda-analyzer to alsa-tools package? Looking at the recent demand on it, I think it's worth to merge into the common alsa-tools repo, instead of keeping it separately. FWIW, HD-audio specific tools like hda-verb and hdajackretask have been already merged there. thanks, Takashi

1 0

[alsa-devel] [PATCH V5 14/18] ALSA: HDA: Make hda sound card usable for Loongson.
by Huacai Chen 13 Aug '12

13 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: Jie Chen <chenj(a)lemote.com> 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 | 24 ++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 0 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..b7de368 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -4414,6 +4414,8 @@ static const struct hda_codec_ops cx_auto_patch_ops = { enum { CXT_PINCFG_LENOVO_X200, CXT_PINCFG_LENOVO_TP410, + CXT_PINCFG_LEMOTE_A1004, + CXT_PINCFG_LEMOTE_A1205, CXT_FIXUP_STEREO_DMIC, }; @@ -4441,6 +4443,18 @@ static const struct hda_pintbl cxt_pincfg_lenovo_tp410[] = { {} }; +/* Lemote A1004/A1205 with cxt5066 */ +static const struct hda_pintbl cxt_pincfg_lemote[] = { + { 0x1a, 0x90a10020 }, /* Internal mic */ + { 0x1b, 0x03a11020 }, /* External mic */ + { 0x1d, 0x400101f0 }, /* Not used */ + { 0x1e, 0x40a701f0 }, /* Not used */ + { 0x20, 0x404501f0 }, /* Not used */ + { 0x22, 0x404401f0 }, /* Not used */ + { 0x23, 0x40a701f0 }, /* Not used */ + {} +}; + static const struct hda_fixup cxt_fixups[] = { [CXT_PINCFG_LENOVO_X200] = { .type = HDA_FIXUP_PINS, @@ -4450,6 +4464,14 @@ static const struct hda_fixup cxt_fixups[] = { .type = HDA_FIXUP_PINS, .v.pins = cxt_pincfg_lenovo_tp410, }, + [CXT_PINCFG_LEMOTE_A1004] = { + .type = HDA_FIXUP_PINS, + .v.pins = cxt_pincfg_lemote, + }, + [CXT_PINCFG_LEMOTE_A1205] = { + .type = HDA_FIXUP_PINS, + .v.pins = cxt_pincfg_lemote, + }, [CXT_FIXUP_STEREO_DMIC] = { .type = HDA_FIXUP_FUNC, .v.func = cxt_fixup_stereo_dmic, @@ -4467,6 +4489,8 @@ static const struct snd_pci_quirk cxt5066_fixups[] = { SND_PCI_QUIRK(0x17aa, 0x215f, "Lenovo T510", CXT_PINCFG_LENOVO_TP410), SND_PCI_QUIRK(0x17aa, 0x21ce, "Lenovo T420", CXT_PINCFG_LENOVO_TP410), SND_PCI_QUIRK(0x17aa, 0x21cf, "Lenovo T520", CXT_PINCFG_LENOVO_TP410), + SND_PCI_QUIRK(PCI_VENDOR_ID_LEMOTE, 0x2011, "Lemote A1004", CXT_PINCFG_LEMOTE_A1004), + SND_PCI_QUIRK(PCI_VENDOR_ID_LEMOTE, 0x2012, "Lemote A1205", CXT_PINCFG_LEMOTE_A1205), SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC), {} -- 1.7.7.3

2 2

[alsa-devel] ICT Bits for HDMI HBR feature
by Wang, Xingchao 13 Aug '12

13 Aug '12

Hi Takashi, Should we set ICT bits when enable HDMI HBR features? Here's quote from HDA Specification Rev1.0a(page 150). " ICT[3:0] (IEC Coding Type): Programmed according to IEC standards to enable stream types for High Bit Rate Encoding. This is valid only for HDMI and Display port digital Pin Widgets. " Since HDMI HBR already works on some chips, I wonder if they set the bits correctly. Thanks --xingchao

3 3

[alsa-devel] [PATCH 1/3] ALSA: hda - show ICT/KAE control bits
by Wang Xingchao 13 Aug '12

13 Aug '12

Enable two debug options for S/PDIF Converter Control. KAE: Keep Alive Enable; ICT: IEC Coding Type. Signed-off-by: Wang Xingchao <xingchao.wang(a)intel.com> --- sound/pci/hda/hda_codec.h | 4 ++++ sound/pci/hda/hda_proc.c | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index c422d33..141b3b8 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -386,6 +386,10 @@ enum { /* DIGITAL2 bits */ #define AC_DIG2_CC (0x7f<<0) +/* DIGITAL3 bits */ +#define AC_DIG3_ICT (0xf<<0) +#define AC_DIG3_KAE (1<<23) + /* Pin widget control - 8bit */ #define AC_PINCTL_EPT (0x3<<0) #define AC_PINCTL_EPT_NATIVE 0 diff --git a/sound/pci/hda/hda_proc.c b/sound/pci/hda/hda_proc.c index 7e46258..a222aae 100644 --- a/sound/pci/hda/hda_proc.c +++ b/sound/pci/hda/hda_proc.c @@ -419,9 +419,13 @@ static void print_digital_conv(struct snd_info_buffer *buffer, snd_iprintf(buffer, " Pro"); if (digi1 & AC_DIG1_LEVEL) snd_iprintf(buffer, " GenLevel"); + if (digi1 & AC_DIG3_KAE) + snd_iprintf(buffer, " KAE"); snd_iprintf(buffer, "\n"); snd_iprintf(buffer, " Digital category: 0x%x\n", (digi1 >> 8) & AC_DIG2_CC); + snd_iprintf(buffer, " IEC Coding Type: 0x%x\n", + (digi1 >> 16) & AC_DIG3_ICT); } static const char *get_pwr_state(u32 state) -- 1.7.9.5

3 12

[alsa-devel] [PATCH v2] ALSA: hda - show ICT/KAE control bits
by Wang Xingchao 13 Aug '12

13 Aug '12

Enable two debug options for S/PDIF Converter Control. KAE: Keep Alive Enable; ICT: IEC Coding Type. Signed-off-by: Wang Xingchao <xingchao.wang(a)intel.com> --- sound/pci/hda/hda_codec.h | 4 ++++ sound/pci/hda/hda_proc.c | 9 ++++++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index c422d33..afd2af0 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -386,6 +386,10 @@ enum { /* DIGITAL2 bits */ #define AC_DIG2_CC (0x7f<<0) +/* DIGITAL3 bits */ +#define AC_DIG3_ICT (0xf<<0) +#define AC_DIG3_KAE (1<<7) + /* Pin widget control - 8bit */ #define AC_PINCTL_EPT (0x3<<0) #define AC_PINCTL_EPT_NATIVE 0 diff --git a/sound/pci/hda/hda_proc.c b/sound/pci/hda/hda_proc.c index 7e46258..32bb3d9 100644 --- a/sound/pci/hda/hda_proc.c +++ b/sound/pci/hda/hda_proc.c @@ -402,6 +402,9 @@ static void print_digital_conv(struct snd_info_buffer *buffer, { unsigned int digi1 = snd_hda_codec_read(codec, nid, 0, AC_VERB_GET_DIGI_CONVERT_1, 0); + unsigned char digi2 = digi1 >> 8; + unsigned char digi3 = digi1 >> 16; + snd_iprintf(buffer, " Digital:"); if (digi1 & AC_DIG1_ENABLE) snd_iprintf(buffer, " Enabled"); @@ -419,9 +422,13 @@ static void print_digital_conv(struct snd_info_buffer *buffer, snd_iprintf(buffer, " Pro"); if (digi1 & AC_DIG1_LEVEL) snd_iprintf(buffer, " GenLevel"); + if (digi3 & AC_DIG3_KAE) + snd_iprintf(buffer, " KAE"); snd_iprintf(buffer, "\n"); snd_iprintf(buffer, " Digital category: 0x%x\n", - (digi1 >> 8) & AC_DIG2_CC); + digi2 & AC_DIG2_CC); + snd_iprintf(buffer, " IEC Coding Type: 0x%x\n", + digi3 & AC_DIG3_ICT); } static const char *get_pwr_state(u32 state) -- 1.7.9.5

2 1

[alsa-devel] HDA Mono out
by Raymond Yau 13 Aug '12

13 Aug '12

How can the driver differentiate those mono internal chassis speaker of desktop from those subwoofer speaker of laptop? https://launchpadlibrarian.net/34863455/Card0.Codecs.codec.2.txt Node 0x13 [Pin Complex] wcaps 0x40010c: Mono Amp-Out Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x00] Pincap 0x00000010: OUT Pin Default 0x911711f0: [Fixed] Speaker at Int Rear Conn = Analog, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x2d refer to the patch hda: Added mono_out_pin to autoconfig Added a mono_out_pin field to autocfg struct, and code to parse for the mono_out_line. http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=blobdiff;f=soun… does any computer really has the mono jack using the mono pin complex? do pulseaudio classify those mono internal chassis speaker as desktop speaker path or speaker path? http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mix… in patch_analog.c, "mono playback switch" is created in 6stack. 3stack and laptop model. the auto model need to handle the speaker of the laptop implementation but lenovo 3000 workstation contain the internal chassis speaker which hda auto parser put it in speaker_pins instead of mono_out if ((err = ad1988_auto_create_multi_out_ctls(spec, &spec->autocfg)) < 0 || (err = ad1988_auto_create_extra_out(codec, spec->autocfg.speaker_pins[0], "Speaker")) < 0 || (err = ad1988_auto_create_extra_out(codec, spec->autocfg.hp_pins[0], "Headphone")) < 0 || (err = ad1988_auto_create_analog_input_ctls(codec, &spec->autocfg)) < 0) return err; one possible way to fix this bug for lenovo 3000 by checking wcaps of the pin support mono/stereo in ad1988_auto_create_extra_out and create the mono playback switch for the internal chassis speaker instead of the speaker playback volume/switch since mono out pin have to share audio output 0x04 with green jack at rear panel.

2 1

[alsa-devel] Gitcompile for Kernel 3.2?
by Brand, Mark (Mr) (Summerstrand Campus South) 13 Aug '12

13 Aug '12

Hi all, Having cloned alsa-driver and alsa-kmirror, my gitcompile and sudo make install-modules goes smoothly. However, the modules won't load. First errors in dmesg are: [ 24.415466] snd_hwdep: disagrees about version of symbol snd_info_register [ 24.415475] snd_hwdep: Unknown symbol snd_info_register (err -22) [ 24.415489] snd_hwdep: disagrees about version of symbol snd_info_create_module_entry [ 24.415495] snd_hwdep: Unknown symbol snd_info_create_module_entry (err -22) ... and so on. My initial assumption is that kmirror is specific to a 2.6 kernel, while I'm running 3.2, though some of what I've read seems to contradict this. I've tried foregoing kmirror for a full 3.2 kernel source, but that failed on gitcompile. I also tried with kmirror on a 2.6 kernel, but those modules also failed to load. I initially thought my problems stemmed from trying to do this against a lowlatency kernel, but I've subsequently had the same against vanilla Ubuntu kernels. Would someone kindly point me in the right direction? * Is it possible to compile and load a subset of alsa modules without having full kernel sources on hand? * If so, is this restricted to particular kernels (docs seem to suggest 2.6, 3.0 and 3.2 are supported)? * If not, is alsa-driver expected to compile against 3.2 sources as is (mine fails on some of the patching - presumably the make dep step)? * Does the alsa-driver.new.git merge address this, or is development expected to take place in a 2.6 environment? Sorry if any or all of this is incoherent (please help me to clarify), but any pointers would be greatly appreciated. What might be pertinent: Ubuntu 12.04 (kernels 3.2.0 and 2.6.38 tested), gcc 4.6.3, anything else? I am attempting to add device support for a multi-port MIDI interface. I managed to get a working prototype running a year ago, but had to shelve the project due to work pressures. I'd really love to get it back up and submitted. Kind regards, Mark Brand. ________________________________ NOTICE: Please note that this eMail, and the contents thereof, is subject to the standard NMMU eMail disclaimer which may be found at: http://www.nmmu.ac.za/disclaimer/email.htm

2 8