November 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 1/2] ALSA: hda - Force buffer alignment for Haswell HDMI controllers
by Takashi Iwai 06 Nov '13

06 Nov '13

Haswell HDMI audio controllers seem to get stuck when unaligned buffer size is used. Let's enable the buffer alignment for the corresponding entries. Since AZX_DCAPS_INTEL_PCH contains AZX_DCAPS_BUFSIZE that disables the buffer alignment forcibly, define AZX_DCAPS_INTEL_HASWELL and put the necessary AZX_DCAPS bits there. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60769 Reported-by: Alexander E. Patrakov <patrakov(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index d6dcec768594..9cbd1259a5be 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -613,6 +613,11 @@ enum { #define AZX_DCAPS_INTEL_PCH \ (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME) +#define AZX_DCAPS_INTEL_HASWELL \ + (AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_ALIGN_BUFSIZE | \ + AZX_DCAPS_COUNT_LPIB_DELAY | AZX_DCAPS_PM_RUNTIME | \ + AZX_DCAPS_I915_POWERWELL) + /* quirks for ATI SB / AMD Hudson */ #define AZX_DCAPS_PRESET_ATI_SB \ (AZX_DCAPS_ATI_SNOOP | AZX_DCAPS_NO_TCSEL | \ @@ -3992,14 +3997,11 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH }, /* Haswell */ { PCI_DEVICE(0x8086, 0x0a0c), - .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH | - AZX_DCAPS_I915_POWERWELL }, + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_HASWELL }, { PCI_DEVICE(0x8086, 0x0c0c), - .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH | - AZX_DCAPS_I915_POWERWELL }, + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_HASWELL }, { PCI_DEVICE(0x8086, 0x0d0c), - .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH | - AZX_DCAPS_I915_POWERWELL }, + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_HASWELL }, /* 5 Series/3400 */ { PCI_DEVICE(0x8086, 0x3b56), .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_NOPM }, -- 1.8.4.2

2 4

Re: [alsa-devel] channel map for intel8x0
by Takashi Iwai 06 Nov '13

06 Nov '13

At Wed, 6 Nov 2013 10:45:32 +0800, Raymond Yau wrote: > > \ > > > > > > > > > > > > Refer to patch ALSA: Implement channel maps for standard onboard > > AC97 > > > > > > drivers > > > > > > > > > > > > e36e3b86c78cee9c7435eb33e0ef8a788193e812< > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/p… > > > > > > > > > > > > > > > > > > It seem that channal map is not working when testing with > > > > > > alsa-lib/test/chmap.c with the emulated intel8x0 inside virtualbox > > > > > > > > > > What doesn't work actually? The lack of chmap for the capture? > > > > > Please give a bit more explanations about your problem. > > > > > > > > > > > > > > /alsa-lib/test$ ./chmap -Dhw:0,0 query > > > > Cannot query maps > > > > > > OK. An untested fix patch is below. > > > > Let me know if the patch worked. Then I'll apply it with Cc to > > stable. > > > > > > thanks, > > > > Takashi > > > > > > > Meanwhile, most of drivers don't provide the chmap for the capture > > > direction just because they are up to two channels, and obviously it's > > > only FL/FR. The chmap support has been added for drivers of consumer > > > cards that are capable of multi channels. > > > > > > > only playback channel map is added in the emulated ICH controller , no > channel map for capture As I already mentioned, the chmaps have been added only for multi channel playback. Others are only two channels, so no chmap is added. > Does it mean that no playback channel map for the other controller ali5455 > SIS7012 ? It is supported. Takashi

1 1

[alsa-devel] [PATCH 0/5] Let's kill BUG*()
by Takashi Iwai 05 Nov '13

05 Nov '13

Hi, this is a series of trivial patches to kill BUG() and BUG_ON() in sound/* (except for ASoC codes, which will follow later). Basically BUG() and BUG_ON() are usless for drivers like sound drivers, because they stop the whole operation intentionally by calling panic(). In this patch series, they are replaced with WARN_ON(), snd_BUG() or something else more soft ones. [PATCH 1/5] ALSA: ctxfi: Use WARN_ON() instead of BUG_ON() [PATCH 2/5] ALSA: ps3: Use WARN_ON() instead of BUG_ON() [PATCH 3/5] ALSA: sparc/cs4231: Use WARN_ON() instead of BUG_ON() [PATCH 4/5] ALSA: mips/ad1843: Use WARN_ON() instead of BUG_ON() [PATCH 5/5] ALSA: pxa2xx: Replace BUG() with snd_BUG() Takashi

1 5

Re: [alsa-devel] channel map for intel8x0
by Takashi Iwai 05 Nov '13

05 Nov '13

At Mon, 4 Nov 2013 14:52:43 +0800, Raymond Yau wrote: > > [1 <text/plain; UTF-8 (7bit)>] > Refer to patch ALSA: Implement channel maps for standard onboard AC97 > drivers > > e36e3b86c78cee9c7435eb33e0ef8a788193e812<https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/p…> > > It seem that channal map is not working when testing with > alsa-lib/test/chmap.c with the emulated intel8x0 inside virtualbox What doesn't work actually? The lack of chmap for the capture? Please give a bit more explanations about your problem. thanks, Takashi > is the channel map support on device 0 > > - if (rec->ac97_idx == ICHD_PCMOUT && rec->playback_ops) > +if (device == 0 && rec->playback_ops) { > > > how about channel map for capture device ? > [2 <text/html; UTF-8 (quoted-printable)>] >

2 3

[alsa-devel] snd-hda-intel with ALC880 on a ASUS W5A since patch 67b6ec3196da235317ff1b9474f17379b78f3294
by nb 05 Nov '13

05 Nov '13

Hi, Going from kernel 3.2 to kernel 3.10, I met a sound problem. It completely stopped. Neither speakers nor headphones (jack) work. Following Jonathan Woith advice, I have narrowed down the kernel version which caused the problem using a kernel git bisect (it took me 3 days long!). The patch causing the problem is: 67b6ec3196da235317ff1b9474f17379b78f3294 ALSA: hda/realtek - Drop all ALC880 static quirks I hope I haven't made a mistake. 29e3fdcc84e5da04cb7e6a36fee0a772c91d3b28 seems to be good and 67b6ec3196da235317ff1b9474f17379b78f3294 seems to be bad. You can find attached: - alsa-info output of non working kernel (3.11) - alsa-info output of working kernel (3.2) Can you please help me? I have tried at alsa-users forum but with no success. If you need more informations, please let me know. Regards nb

1 0

[alsa-devel] [PATCH] ALSA: hda - Enable Thinkpad mute/micmute LEDs for Realtek
by David Henningsson 05 Nov '13

05 Nov '13

Same as we already have for Conexant. Right now it's only enabled for one machine. Tested-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 83 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 81 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 01bf812..02071a5 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -829,7 +829,11 @@ static inline void alc_shutup(struct hda_codec *codec) snd_hda_shutup_pins(codec); } -#define alc_free snd_hda_gen_free +static void alc_free(struct hda_codec *codec) +{ + snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_FREE); + snd_hda_gen_free(codec); +} #ifdef CONFIG_PM static void alc_power_eapd(struct hda_codec *codec) @@ -3527,6 +3531,74 @@ static void alc290_fixup_mono_speakers(struct hda_codec *codec, snd_hda_override_wcaps(codec, 0x03, 0); } +#if IS_ENABLED(CONFIG_THINKPAD_ACPI) + +#include <linux/thinkpad_acpi.h> + +static int (*led_set_func)(int, bool); + +static void update_tpacpi_mute_led(void *private_data, int enabled) +{ + if (led_set_func) + led_set_func(TPACPI_LED_MUTE, !enabled); +} + +static void update_tpacpi_micmute_led(struct hda_codec *codec, + struct snd_ctl_elem_value *ucontrol) +{ + if (!ucontrol || !led_set_func) + return; + if (strcmp("Capture Switch", ucontrol->id.name) == 0 && ucontrol->id.index == 0) { + /* TODO: How do I verify if it's a mono or stereo here? */ + bool val = ucontrol->value.integer.value[0] || ucontrol->value.integer.value[1]; + led_set_func(TPACPI_LED_MICMUTE, !val); + } +} + +static void alc_fixup_thinkpad_acpi(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + bool removefunc = false; + + if (action == HDA_FIXUP_ACT_PROBE) { + if (!led_set_func) + led_set_func = symbol_request(tpacpi_led_set); + if (!led_set_func) { + snd_printk(KERN_WARNING "Failed to find thinkpad-acpi symbol tpacpi_led_set\n"); + return; + } + + removefunc = true; + if (led_set_func(TPACPI_LED_MUTE, false) >= 0) { + spec->gen.vmaster_mute.hook = update_tpacpi_mute_led; + removefunc = false; + } + if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0) { + if (spec->gen.num_adc_nids > 1) + snd_printdd("Skipping micmute LED control due to several ADCs"); + else { + spec->gen.cap_sync_hook = update_tpacpi_micmute_led; + removefunc = false; + } + } + } + + if (led_set_func && (action == HDA_FIXUP_ACT_FREE || removefunc)) { + symbol_put(tpacpi_led_set); + led_set_func = NULL; + } +} + +#else + +static void alc_fixup_thinkpad_acpi(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ +} + +#endif + enum { ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, @@ -3570,6 +3642,7 @@ enum { ALC282_FIXUP_ASUS_TX300, ALC283_FIXUP_INT_MIC, ALC290_FIXUP_MONO_SPEAKERS, + ALC269_FIXUP_THINKPAD_ACPI, }; static const struct hda_fixup alc269_fixups[] = { @@ -3867,6 +3940,12 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_DELL3_MIC_NO_PRESENCE, }, + [ALC269_FIXUP_THINKPAD_ACPI] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_thinkpad_acpi, + .chained = true, + .chain_id = ALC269_FIXUP_LIMIT_INT_MIC_BOOST + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -3950,7 +4029,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x2208, "Thinkpad T431s", ALC269_FIXUP_LENOVO_DOCK), SND_PCI_QUIRK(0x17aa, 0x220c, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x17aa, 0x2212, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), - SND_PCI_QUIRK(0x17aa, 0x2214, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x17aa, 0x2214, "Thinkpad", ALC269_FIXUP_THINKPAD_ACPI), SND_PCI_QUIRK(0x17aa, 0x2215, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x17aa, 0x5013, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x17aa, 0x501a, "Thinkpad", ALC283_FIXUP_INT_MIC), -- 1.7.9.5

2 1

[alsa-devel] Microphones not working on Apple macbook Air 1, 1 (Early 2008) under 3.2.0-55-generic-pae Linux
by Nicolo' 05 Nov '13

05 Nov '13

Hello List, from time to time I spend time on this problem. (Of course, it is not related to muting or capturing in alsamixer, or pulseaudio stuff, since that was already tried.) I can't get the mics to work, neither the internal one nor the external; note that the same jack works both for HP and ext MIC, I think it's called TRRS, and it's the same as the one used e.g. on iphones. I tried also with more recent kernels, and playing with hda-jack-retask, but with no success up to now. alsa script result at https://www.dropbox.com/l/HHLkdCW4Shcak8gq2rBSY8 A curious fact, I found this alsa script result http://www.alsa-project.org/db/?f=3ca8243c0626844f0264a3faad0aa72018bc14f4f… a guy running Arch on the same machine, where actually some Mic appears in codec#0: do you think it is relevant? Thanks and best, Nicolo'

1 0

[alsa-devel] message to the list still waiting for approval
by nb 05 Nov '13

05 Nov '13

Hello, Since yesterday I have a message waiting for approval. I've received the following bounce: "Your mail to 'Alsa-devel' with the subject snd-hda-intel with ALC880 on a ASUS W5A since patch 67b6ec3196da235317ff1b9474f17379b78f3294 Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 66980 bytes with a limit of 60 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mailman.alsa-project.org/mailman/confirm/alsa-devel/6f80968d8c7db3d4…" Can someone unlock the message please. Regards nb

1 0

Re: [alsa-devel] [Alsa-user] hdmi sound rerouted?
by Dagg Stompler 05 Nov '13

05 Nov '13

> ----- Original Message ----- > From: Takashi Iwai > Sent: 11/05/13 10:49 AM > To: Clemens Ladisch > Subject: Re: [alsa-devel] [Alsa-user] hdmi sound rerouted? > > At Tue, 05 Nov 2013 09:27:10 +0100, > Clemens Ladisch wrote: > > > > Takashi Iwai wrote: > > > You wanted to play back via this HDMI and it didn't work? > > > > The ATI card did not show up as "ATI", but the other ATI card without > > HDMI did: <http://thread.gmane.org/gmane.linux.alsa.user/37732>. > > > > Anyway, let's close this thread: > > > > --8<---------------------------------------------------------------->8-- > > ALSA: hda: add device IDs for AMD Evergreen/Northern Islands HDMI > > > > The device IDs of the AMD Cypress/Juniper/Redwood/Cedar/Cayman/Antilles/ > > Barts/Turks/Caicos HDMI HDA controllers were missing for some reason. > > Add them so that the name shows up properly as "ATI HDMI" instead of > > "Generic", and so that the driver does not try to detect nonexistent > > codecs. > > Well, there is no actual behavior difference between > AZX_DRIVER_ATIHDMI and AZX_DRIVER_GENERIC about AMD HDMI chips. The > codec-probing is pretty same. The only difference in the current code > is the driver name string and the fallback of number of streams, but > the latter is valid only when GCAP register doesn't give proper > values, and it shouldn't happen with a proper chip. > > That being said, the entries weren't added intentionally just because > they aren't needed to be added explicitly. The generic entry suffices > from the functionality POV. > > But it seems that people misunderstand, so I think it's fine to apply > your patch to give a more clear name. > > > Takashi > > > According to Takashi's tests and the lack of complaints, these devices > > work fine without disabling snooping. > > > > Signed-off-by: Clemens Ladisch <clemens(a)ladisch.de> > > > > --- a/sound/pci/hda/hda_intel.c > > +++ b/sound/pci/hda/hda_intel.c > > @@ -4079,6 +4079,22 @@ > > .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > { PCI_DEVICE(0x1002, 0xaa48), > > .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa50), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa58), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa60), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa68), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa80), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa88), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa90), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > + { PCI_DEVICE(0x1002, 0xaa98), > > + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI }, > > { PCI_DEVICE(0x1002, 0x9902), > > .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI }, > > { PCI_DEVICE(0x1002, 0xaaa0), > > I'll apply the patch against 3.12 and will report back if it works.

1 0

[alsa-devel] async between dmaengine_pcm_dma_complete and snd_pcm_release
by Qiao Zhou 05 Nov '13

05 Nov '13

Hi Mark, Liam, Jaroslav, Takashi I met an issue in which kernel panic appears in dmaengine_pcm_dma_complete function on a quad-core system. The dmaengine_pcm_dma_complete is running core0, while snd_pcm_release has already been executed on core1, due to in low memory stress oom killer kills the audio thread to release some memory. snd_pcm_release frees the runtime parameters, and runtime is used in dmaengine_pcm_dma_complete, which is a callback from tasklet in dmaengine. In current audio driver, we can't promise that dmaengine_pcm_dma_complete is not executed after snd_pcm_release on multi cores. Maybe we should add some protection. Do you have any suggestion? I have tried to apply below workaround, which can fix the panic, but I'm not confident it's proper. Need your comment and better suggestion. From d568a88e8f66ee21d44324bdfb48d2a3106cf0d1 Mon Sep 17 00:00:00 2001 From: Qiao Zhou <zhouqiao(a)marvell.com> Date: Wed, 9 Oct 2013 15:24:29 +0800 Subject: [PATCH] ASoC: soc-dmaengine: add mutex to protect runtime param under SMP arch, the dmaengine_pcm_dma_complete callback has the chance to run on one cpu while at the same time, the substream is released on another cpu. thus it may access param which is already freed. we need to add mutes to protect such access, and check PCM availability before using it. Signed-off-by: Qiao Zhou <zhouqiao(a)marvell.com> --- sound/soc/soc-dmaengine-pcm.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c index 111b7d9..5917029 100644 --- a/sound/soc/soc-dmaengine-pcm.c +++ b/sound/soc/soc-dmaengine-pcm.c @@ -125,13 +125,22 @@ EXPORT_SYMBOL_GPL(snd_hwparams_to_dma_slave_config); static void dmaengine_pcm_dma_complete(void *arg) { struct snd_pcm_substream *substream = arg; - struct dmaengine_pcm_runtime_data *prtd = substream_to_prtd(substream); + struct dmaengine_pcm_runtime_data *prtd; + + mutex_lock(&substream->pcm->open_mutex); + if (!substream || !substream->runtime) { + mutex_unlock(&substream->pcm->open_mutex); + return; + } + + prtd = substream_to_prtd(substream); prtd->pos += snd_pcm_lib_period_bytes(substream); if (prtd->pos >= snd_pcm_lib_buffer_bytes(substream)) prtd->pos = 0; snd_pcm_period_elapsed(substream); + mutex_unlock(&substream->pcm->open_mutex); } static int dmaengine_pcm_prepare_and_submit(struct snd_pcm_substream *substream) -- 1.7.0.4 -- Best Regards Qiao

4 18