Patchwork Bug 741825 (Broken recording/jack sense on recent ATI/AMD chipsets) - next step

login
register
mail settings
Submitter David Henningsson
Date May 27, 2011, 6:53 a.m.
Message ID <4DDF4A5F.8020700@canonical.com>
Download mbox | patch
Permalink /patch/97657/
State New
Headers show

Comments

David Henningsson - May 27, 2011, 6:53 a.m.
So, as some of you know, I've been working with bug 741825 for a while 
and thanks to our OEM/HWE team we're now quite certain that running an 
upstream snapshot of the alsa driver modules solves the problem. I'm now 
trying to SRU this into Natty.

I'm attaching three fixes which I believe is what's needed to apply on 
top of natty to fix this problem, but I'd like verification. Note that 
nr 2 is to enable the Hudson chipset, which is also baked into this issue.

Testing is easiest done using the following procedure:

1) Start off with a fresh Natty install with nothing but natty-updates 
installed. In particular, make sure the latest ALSA drivers are *not* 
installed (modinfo snd-hda-codec should say 
/lib/modules/2.6.38-8-generic/kernel/sound/pci/hda/snd-hda-codec.ko)

2) Install the attached deb and reboot.

3) Test both internal and external mic. Even though mics should 
autoswitch for the three below (I think), make sure the right mic is 
selected in gnome-volume-control so you control the volume of the right 
input. Testing for a larger period of time doesn't hurt here, e g you 
could leave gnome-volume-control on the input tab, go away a few 
minutes, then come back and notice that the level bar is still moving 
when you speak into the microphone.

4) When the above test is done, also test automute (speaker mutes when 
headphones plugged in). This is something that could start to fail after 
a while which is why this test should be done after the previous test.

5) If the machine does not work, please supply the output of "cat 
/proc/interrupts" and an alsa-info (wiki.ubuntu.com/Audio/AlsaInfo).

If I'd make a wish, I'd like this to be tested on

  * One or two machines with the SB700/SB800 chipset
  * One or two machines with the Hudson chipset
  * One or two machines with an older ATI chipset, as this might impact 
them as well. This is to test for regressions, although I suspect that 
we actually improve the situation for them as well.

Again, thanks for helping out!
Tim Gardner - May 27, 2011, 3:55 p.m.
On 05/26/2011 11:53 PM, David Henningsson wrote:
> So, as some of you know, I've been working with bug 741825 for a while
> and thanks to our OEM/HWE team we're now quite certain that running an
> upstream snapshot of the alsa driver modules solves the problem. I'm now
> trying to SRU this into Natty.
>
> I'm attaching three fixes which I believe is what's needed to apply on
> top of natty to fix this problem, but I'd like verification. Note that
> nr 2 is to enable the Hudson chipset, which is also baked into this issue.
>
> Testing is easiest done using the following procedure:
>
> 1) Start off with a fresh Natty install with nothing but natty-updates
> installed. In particular, make sure the latest ALSA drivers are *not*
> installed (modinfo snd-hda-codec should say
> /lib/modules/2.6.38-8-generic/kernel/sound/pci/hda/snd-hda-codec.ko)
>
> 2) Install the attached deb and reboot.
>
> 3) Test both internal and external mic. Even though mics should
> autoswitch for the three below (I think), make sure the right mic is
> selected in gnome-volume-control so you control the volume of the right
> input. Testing for a larger period of time doesn't hurt here, e g you
> could leave gnome-volume-control on the input tab, go away a few
> minutes, then come back and notice that the level bar is still moving
> when you speak into the microphone.
>
> 4) When the above test is done, also test automute (speaker mutes when
> headphones plugged in). This is something that could start to fail after
> a while which is why this test should be done after the previous test.
>
> 5) If the machine does not work, please supply the output of "cat
> /proc/interrupts" and an alsa-info (wiki.ubuntu.com/Audio/AlsaInfo).
>
> If I'd make a wish, I'd like this to be tested on
>
> * One or two machines with the SB700/SB800 chipset
> * One or two machines with the Hudson chipset
> * One or two machines with an older ATI chipset, as this might impact
> them as well. This is to test for regressions, although I suspect that
> we actually improve the situation for them as well.
>
> Again, thanks for helping out!
>
>

David - these patches all look fine, and appear appropriate for SRU. I'd 
like to see a minor administrative change to the first 2 patches (which 
appear to be clean cherry picks). Please use 'git cherry-pick -x -s' 
when plucking the patch so that it preserves the original SHA1 and also 
applies your s-o-b. The 3rd patch has an appropriate 'backported from 
SHA1' notice in it.

If you're gone for vacation, then whomever applies these patches can 
make those minor changes.

rtg
Tim Gardner - June 20, 2011, 4:25 p.m.
On 05/27/2011 12:53 AM, David Henningsson wrote:
> So, as some of you know, I've been working with bug 741825 for a while
> and thanks to our OEM/HWE team we're now quite certain that running an
> upstream snapshot of the alsa driver modules solves the problem. I'm now
> trying to SRU this into Natty.
>
> I'm attaching three fixes which I believe is what's needed to apply on
> top of natty to fix this problem, but I'd like verification. Note that
> nr 2 is to enable the Hudson chipset, which is also baked into this issue.
>
> Testing is easiest done using the following procedure:
>
> 1) Start off with a fresh Natty install with nothing but natty-updates
> installed. In particular, make sure the latest ALSA drivers are *not*
> installed (modinfo snd-hda-codec should say
> /lib/modules/2.6.38-8-generic/kernel/sound/pci/hda/snd-hda-codec.ko)
>
> 2) Install the attached deb and reboot.
>
> 3) Test both internal and external mic. Even though mics should
> autoswitch for the three below (I think), make sure the right mic is
> selected in gnome-volume-control so you control the volume of the right
> input. Testing for a larger period of time doesn't hurt here, e g you
> could leave gnome-volume-control on the input tab, go away a few
> minutes, then come back and notice that the level bar is still moving
> when you speak into the microphone.
>
> 4) When the above test is done, also test automute (speaker mutes when
> headphones plugged in). This is something that could start to fail after
> a while which is why this test should be done after the previous test.
>
> 5) If the machine does not work, please supply the output of "cat
> /proc/interrupts" and an alsa-info (wiki.ubuntu.com/Audio/AlsaInfo).
>
> If I'd make a wish, I'd like this to be tested on
>
> * One or two machines with the SB700/SB800 chipset
> * One or two machines with the Hudson chipset
> * One or two machines with an older ATI chipset, as this might impact
> them as well. This is to test for regressions, although I suspect that
> we actually improve the situation for them as well.
>
> Again, thanks for helping out!
>
>

Patch

From 1547a9094c11baf60bb19b1e6dcb22778ee05e11 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 26 Apr 2011 15:25:02 +0200
Subject: [PATCH 3/3] ALSA: hda - Enable sync_write workaround for AMD generically

Backport for d507cd668a3f6d07 upstream.

The workaround for AMD chipset via sync_write flag seems needed for
machines with Realtek codecs.  So, it's better to activate it
generically in hda_intel.c from the beginning.

Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/hda_intel.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 5fd012b..c9fb18e 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1449,6 +1449,17 @@  static int __devinit azx_codec_create(struct azx *chip, const char *model)
 		}
 	}
 
+	/* AMD chipsets often cause the communication stalls upon certain
+	 * sequence like the pin-detection.  It seems that forcing the synced
+	 * access works around the stall.  Grrr...
+	 */
+	if (chip->pci->vendor == PCI_VENDOR_ID_AMD ||
+	    chip->pci->vendor == PCI_VENDOR_ID_ATI) {
+		snd_printk(KERN_INFO SFX "Enable sync_write for AMD chipset\n");
+		chip->bus->sync_write = 1;
+		chip->bus->allow_bus_reset = 1;
+	}
+
 	/* Then create codec instances */
 	for (c = 0; c < max_slots; c++) {
 		if ((chip->codec_mask & (1 << c)) & chip->codec_probe_mask) {
-- 
1.7.4.1