public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Thu, 30 Apr 2009 09:51:27 -0400	[thread overview]
Message-ID: <20090430095127.7efc63ca@dev.queued.net> (raw)
In-Reply-To: <s5hbpqeln79.wl%tiwai@suse.de>

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.


  reply	other threads:[~2009-04-30 13:52 UTC|newest]

Thread overview: 13+ 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-29  6:33                   ` Takashi Iwai
2009-04-29 13:02                     ` Andres Salomon
2009-04-29 13:09                       ` Takashi Iwai
2009-04-29 17:01                         ` Andres Salomon
2009-04-30  5:34                           ` Takashi Iwai
2009-04-30 13:51                             ` Andres Salomon [this message]
2009-05-04  7:02                               ` Takashi Iwai
2009-05-04 12:37                                 ` Andres Salomon
2009-05-04 12:40                                   ` Takashi Iwai
2009-05-04 14:03                                     ` Andres Salomon
2009-05-04 14:18                                       ` Takashi Iwai
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=20090430095127.7efc63ca@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox