All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andres Salomon <dilinger@queued.net>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Kailang Yang <kailang@realtek.com>,
	linux-kernel@vger.kernel.org
Subject: Re: realtek ALC272 support
Date: Wed, 29 Apr 2009 13:01:42 -0400	[thread overview]
Message-ID: <20090429130142.54ec0802@dev.queued.net> (raw)
In-Reply-To: <s5h8wljbo8v.wl%tiwai@suse.de>

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.  :)

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

Can you please provide a suggestion for how this is supposed to work?
Note that I only have access to this machine for another day.

WARNING: multiple messages have this Message-ID (diff)
From: Andres Salomon <dilinger@queued.net>
To: Takashi Iwai <tiwai@suse.de>
Cc: Kailang Yang <kailang@realtek.com>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: realtek ALC272 support
Date: Wed, 29 Apr 2009 13:01:42 -0400	[thread overview]
Message-ID: <20090429130142.54ec0802@dev.queued.net> (raw)
In-Reply-To: <s5h8wljbo8v.wl%tiwai@suse.de>

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.  :)

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

Can you please provide a suggestion for how this is supposed to work?
Note that I only have access to this machine for another day.

  reply	other threads:[~2009-04-29 17:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090424152415.10fcebff@dev.queued.net>
     [not found] ` <s5hljpp3z2w.wl%tiwai@suse.de>
     [not found]   ` <20090425101753.1983e6ae@dev.queued.net>
     [not found]     ` <s5hocujwuhb.wl%tiwai@suse.de>
     [not found]       ` <20090427100151.01a46965@dev.queued.net>
     [not found]         ` <s5hprey3yc5.wl%tiwai@suse.de>
     [not found]           ` <20090427120230.74d70f88@dev.queued.net>
     [not found]             ` <s5hbpqi3wqy.wl%tiwai@suse.de>
     [not found]               ` <20090428154108.6ed3136d@dev.queued.net>
2009-04-28 22:21                 ` realtek ALC272 support Andres Salomon
2009-04-28 22:21                   ` Andres Salomon
2009-04-29  6:33                   ` Takashi Iwai
2009-04-29  6:33                     ` Takashi Iwai
2009-04-29 13:02                     ` Andres Salomon
2009-04-29 13:02                       ` Andres Salomon
2009-04-29 13:09                       ` Takashi Iwai
2009-04-29 13:09                         ` Takashi Iwai
2009-04-29 17:01                         ` Andres Salomon [this message]
2009-04-29 17:01                           ` Andres Salomon
2009-04-30  5:34                           ` Takashi Iwai
2009-04-30  5:34                             ` Takashi Iwai
2009-04-30 13:51                             ` Andres Salomon
2009-04-30 13:51                               ` Andres Salomon
2009-05-04  7:02                               ` Takashi Iwai
2009-05-04  7:02                                 ` Takashi Iwai
2009-05-04 12:37                                 ` Andres Salomon
2009-05-04 12:37                                   ` Andres Salomon
2009-05-04 12:40                                   ` Takashi Iwai
2009-05-04 12:40                                     ` Takashi Iwai
2009-05-04 14:03                                     ` Andres Salomon
2009-05-04 14:03                                       ` Andres Salomon
2009-05-04 14:18                                       ` Takashi Iwai
2009-05-04 14:18                                         ` Takashi Iwai
2009-05-04 14:37                                         ` Andres Salomon
2009-05-04 14:37                                           ` Andres Salomon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090429130142.54ec0802@dev.queued.net \
    --to=dilinger@queued.net \
    --cc=alsa-devel@alsa-project.org \
    --cc=kailang@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.