Re: realtek ALC272 support

[Andres Salomon <dilinger@queued.net>]

On Mon, 04 May 2009 16:18:13 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 4 May 2009 10:03:08 -0400,
> Andres Salomon wrote:
> > 
> > On Mon, 04 May 2009 14:40:45 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Mon, 4 May 2009 08:37:10 -0400,
> > > Andres Salomon wrote:
> > > > 
> > > > On Mon, 04 May 2009 09:02:50 +0200
> > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > 
> > > > > At Thu, 30 Apr 2009 09:51:27 -0400,
> > > > > Andres Salomon wrote:
> > > > > > 
> > > > > > On Thu, 30 Apr 2009 07:34:02 +0200
> > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > 
> > > > > > > At Wed, 29 Apr 2009 13:01:42 -0400,
> > > > > > > Andres Salomon wrote:
> > > > > > > > 
> > > > > > > > On Wed, 29 Apr 2009 15:09:20 +0200
> > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > 
> > > > > > > > > At Wed, 29 Apr 2009 09:02:41 -0400,
> > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > 
> > > > > > > > > > On Wed, 29 Apr 2009 08:33:28 +0200
> > > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > > 
> > > > > > > > > > > At Tue, 28 Apr 2009 18:21:55 -0400,
> > > > > > > > > > > Andres Salomon wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > On Tue, 28 Apr 2009 15:41:08 -0400
> > > > > > > > > > > > Andres Salomon <dilinger@queued.net> wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > On Mon, 27 Apr 2009 18:08:21 +0200
> > > > > > > > > > > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > [...]
> > > > > > > > > > > > > > > > > > > > At Fri, 24 Apr 2009 15:24:15
> > > > > > > > > > > > > > > > > > > > -0400, Andres Salomon wrote:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Hi Kailang,
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > I noticed that your name was
> > > > > > > > > > > > > > > > > > > > > on the ALC272 support patch
> > > > > > > > > > > > > > > > > > > > > for ALSA intel-hda.  This
> > > > > > > > > > > > > > > > > > > > > patch basically sets ALC272
> > > > > > > > > > > > > > > > > > > > > to use (mostly) the same code
> > > > > > > > > > > > > > > > > > > > > as ALC662.  I have two
> > > > > > > > > > > > > > > > > > > > > machines that have ALC272,
> > > > > > > > > > > > > > > > > > > > > and both of them need verb
> > > > > > > > > > > > > > > > > > > > > tables in order to function.
> > > > > > > > > > > > > > > > > > > > > I'm wondering if ALC662
> > > > > > > > > > > > > > > > > > > > > should really be used..
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Here's one -
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=7662834bb9a78d244c6d7ee43358c14c94d249c9
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > This isn't the final version
> > > > > > > > > > > > > > > > > > > > > of the patch (there are
> > > > > > > > > > > > > > > > > > > > > further commits I made in
> > > > > > > > > > > > > > > > > > > > > order to support headphone
> > > > > > > > > > > > > > > > > > > > > mic stuff), but it gives you
> > > > > > > > > > > > > > > > > > > > > an idea of the codec values.
> > > > > > > > > > > > > > > > > > > > > The other is:
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=72ff85641a30dc7ac502e2ea01bf14a04efb4cf1
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > All of these leave me wonder
> > > > > > > > > > > > > > > > > > > > > if there's a specific
> > > > > > > > > > > > > > > > > > > > > patch_alc272 function that
> > > > > > > > > > > > > > > > > > > > > could be written to rid
> > > > > > > > > > > > > > > > > > > > > ourselves of these specific
> > > > > > > > > > > > > > > > > > > > > quirks. Are there machines
> > > > > > > > > > > > > > > > > > > > > with ALC272 that are
> > > > > > > > > > > > > > > > > > > > > functional with the current
> > > > > > > > > > > > > > > > > > > > > ALSA code?
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > [...]
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Could you try sound-unstable tree a bit
> > > > > > > > > > > > > > later again? I found a bug in my patch, and
> > > > > > > > > > > > > > fixed and updated GIT tree now. At least,
> > > > > > > > > > > > > > the headphone plugging should work now.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The mic auto-detection still doesn't work
> > > > > > > > > > > > > > with model=auto, though. So, I'm going to
> > > > > > > > > > > > > > take your patch anyway later.  But I just
> > > > > > > > > > > > > > wanted to be sure that the current tree
> > > > > > > > > > > > > > could work somehow better...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I just updated and tried the current tree;
> > > > > > > > > > > > > still no sound/headphone output.  :(
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Ok, I believe I've made some progress on this.
> > > > > > > > > > > > The problem appears to be related to the
> > > > > > > > > > > > autoconfig handling of the line out nids.  The
> > > > > > > > > > > > current code ends up with something like the
> > > > > > > > > > > > following:
> > > > > > > > > > > > 
> > > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3833: autoconfig:
> > > > > > > > > > > > line_outs=1 (0x17/0x0/0x0/0x0/0x0)
> > > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3837:
> > > > > > > > > > > > speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> > > > > > > > > > > > ALSA sound/pci/hda/hda_codec.c:3841:
> > > > > > > > > > > > hp_outs=1 (0x21/0x0/0x0/0x0/0x0) ALSA
> > > > > > > > > > > > sound/pci/hda/hda_codec.c:3842: mono:
> > > > > > > > > > > > mono_out=0x0 ALSA
> > > > > > > > > > > > sound/pci/hda/hda_codec.c:3853: inputs:
> > > > > > > > > > > > mic=0x18, fmic=0x19, line=0x0, fline=0x0,
> > > > > > > > > > > > cd=0x0, aux=0x0
> > > > > > > > > > > > 
> > > > > > > > > > > > However, NID 0x17 is actually a speaker_out.
> > > > > > > > > > > > The code that checks for line_outs in
> > > > > > > > > > > > snd_hda_parse_pin_def_config() unsets the
> > > > > > > > > > > > speaker_out and uses that NID for a line_out.
> > > > > > > > > > > > For whatever reason, this breaks things (no
> > > > > > > > > > > > sound output, no headphone out).
> > > > > > > > > > > 
> > > > > > > > > > > That's intentional, and the driver checks that
> > > > > > > > > > > case, too. Please check the latest sound git tree
> > > > > > > > > > > and see the kernel message. You should have
> > > > > > > > > > > messages like "realtek: ..."
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Takashi
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > The realtek: lines don't appear to affect NID 0x17
> > > > > > > > > > at all. Instead, they say:
> > > > > > > > > > 
> > > > > > > > > > ALSA sound/pci/hda/patch_realtek.c:1154: realtek: No
> > > > > > > > > > valid SSID, checking pincfg 0x40178e2d for NID 0x1d
> > > > > > > > > > ALSA sound/pci/hda/patch_realtek.c:1170: realtek:
> > > > > > > > > > Enabling init ASM_ID=0x8e2d CODEC_ID=10ec0272 ALSA
> > > > > > > > > > sound/pci/hda/patch_realtek.c:1111: realtek: Enable
> > > > > > > > > > HP auto-muting on NID 0x21
> > > > > > > > > 
> > > > > > > > > Then 0x17 should be toggled when the jack on 0x21 is
> > > > > > > > > detected.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Takashi
> > > > > > > > 
> > > > > > > > But since I get absolutely no sound through headphones
> > > > > > > > or speakers, I can't tell if it's being toggled.  :)
> > > > > > > 
> > > > > > > You can see the 0x17 in the codec proc whether it's
> > > > > > > changed at plugged / unplugged.  The driver should change
> > > > > > > its pin control dynamically.
> > > > > > > 
> > > > > > > > I've noticed:
> > > > > > > >  - in order to get speaker output, 0x17 *must* be
> > > > > > > > defined as the speaker-out, and 0x14 *must* be listed
> > > > > > > > as a line-out pin.
> > > > > > > >  - in order to get headphone output, neither 0x17 nor
> > > > > > > > 0x15 are to be listed as the first line-out pin
> > > > > > > 
> > > > > > > Then it implies that 0x17 has nothing to do with the
> > > > > > > speaker, i.e. a BIOS bug.  0x14 could be the speaker
> > > > > > > output while 0x17 is just a dummy.
> > > > > > > 
> > > > > > >
> > > > > > 
> > > > > > Specifying 0x14 as the speaker-pin doesn't work, either.
> > > > > 
> > > > > How did you test it?
> > > > > 
> > > > > 
> > > > > Takashi
> > > > 
> > > > I had tried manually setting the speaker and line-out pins in
> > > > the autoconfig function.
> > > 
> > > So... how?
> > > 
> > > 
> > > Takashi
> > 
> > 
> > Basically, several variations of:
> 
> Well, that's basically a bad place to modify.
> 
> You can change the pin config and reconfigure the driver dynamically
> via sysfs interface.  (Better use it on 2.6.30, though.)
> See Documentation/sound/alsa/HD-Audio.txt.
> 
> 

Unfortunately, I can no longer test it, as I don't have access to the
hardware anymore.