Date: Sat, 4 Jun 2011 21:25:11 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> To: multimedia@freebsd.org Cc: mav@freebsd.org Subject: Re: snd_hda(4) pin routing issues Message-ID: <20110604142511.GA2424@regency.nsu.ru> In-Reply-To: <20110516032002.GA94798@regency.nsu.ru> References: <20100731163218.GA39249@regency.nsu.ru> <20110515163619.GA49401@regency.nsu.ru> <20110516032002.GA94798@regency.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 16, 2011 at 10:20:02AM +0700, Alexey Dokuchaev wrote:
> This is what our snd_hda(4) reports about pins (only pin config,
> association, and sequence numbers quoted for better readability):
>
> nid 8 0x01c5e030 as 3 seq 0
> nid 9 0x01451012 as 1 seq 2
> nid 13 0x02214011 as 1 seq 1
> nid 14 0x01014010 as 1 seq 0
> nid 15 0x01813021 as 2 seq 1
> nid 16 0x02a19020 as 2 seq 0
> nid 17 0x50170013 as 1 seq 3
> nid 18 0x90330022 as 2 seq 2
>
> [But] snd_hda(4) for some reason is unable to establish correct routing:
>
> hdac0: 3 associations found:
> hdac0: Association 0 (1) out:
> hdac0: Pin nid=14 seq=0
> hdac0: Pin nid=13 seq=1
> hdac0: Pin nid=9 seq=2
> hdac0: Association 1 (2) in:
> hdac0: Pin nid=16 seq=0
> hdac0: Pin nid=15 seq=1
> hdac0: Pin nid=18 seq=2
> hdac0: Association 2 (3) in:
> hdac0: Pin nid=8 seq=0
> hdac0: Tracing association 0 (1)
> hdac0: Pin 14 traced to DAC 2
> hdac0: Unable to trace pin 13 seq 1 with min nid 0 <--- WHY?
> hdac0: Unable to trace pin 14 seq 0 with min nid 3 <--- WHY?
> hdac0: Association 0 (1) trace failed
Here is more detailed log for association tracing. Let's see what
happens for pin 14:
hdac0: Tracing association 0 (1)
hdac0: Tracing pin 14 with min nid 0
hdac0: tracing via nid 14
hdac0: tracing via nid 11
hdac0: tracing via nid 7
hdac0: tracing via nid 2
hdac0: nid 2 returned 2
hdac0: tracing via nid 8
hdac0: nid 8 returned 0
hdac0: tracing via nid 10
hdac0: tracing via nid 12
hdac0: tracing via nid 16
hdac0: nid 16 returned 0
hdac0: tracing via nid 15
hdac0: nid 15 returned 0
hdac0: tracing via nid 14
hdac0: nid 14 returned 0
hdac0: tracing via nid 13
hdac0: nid 13 returned 0
hdac0: tracing via nid 18
hdac0: nid 18 returned 0
hdac0: nid 12 returned 0
hdac0: nid 10 returned 0
hdac0: nid 7 returned 2
hdac0: nid 11 returned 2
hdac0: nid 14 returned 2
hdac0: Pin 14 traced to DAC 2
This seems correct and matches the picture [1] of what ALSA does. Now we
move to pin 13:
hdac0: Tracing pin 13 with min nid 0
hdac0: tracing via nid 13
hdac0: tracing via nid 11
hdac0: nid 11 busy by seqmask 1 <--- WTF?!
hdac0: nid 13 returned 0
hdac0: Unable to trace pin 13 seq 1 with min nid 0
Apparently, something is wrong with pin 11. Let's remember this number,
as I will get back to it later. After tracing for pin 13 failed, it
then tried to retrace pin 14, presumably, according to this part of
/sys/dev/sound/pci/hda/hdac.c around line 5159:
% /* Trace this pin taking min nid into account. */
% res = hdac_audio_trace_dac(devinfo, as, i,
% ases[as].pins[i], hpredir, min, 0, 0);
% if (res == 0) {
% /* If we failed - return to previous and redo it. */
hdac0: Tracing pin 14 with min nid 3
hdac0: tracing via nid 14
hdac0: tracing via nid 11
hdac0: tracing via nid 7
hdac0: tracing via nid 2
hdac0: nid 2 returned 0
hdac0: tracing via nid 8
hdac0: nid 8 returned 0
hdac0: tracing via nid 10
hdac0: tracing via nid 12
hdac0: tracing via nid 16
hdac0: nid 16 returned 0
hdac0: tracing via nid 15
hdac0: nid 15 returned 0
hdac0: tracing via nid 14
hdac0: nid 14 returned 0
hdac0: tracing via nid 13
hdac0: nid 13 returned 0
hdac0: tracing via nid 18
hdac0: nid 18 returned 0
hdac0: nid 12 returned 0
hdac0: nid 10 returned 0
hdac0: nid 7 returned 0
hdac0: nid 11 returned 0
hdac0: nid 14 returned 0
hdac0: Unable to trace pin 14 seq 0 with min nid 3
hdac0: Association 0 (1) trace failed
I have some questions about this part: why do we need to retrace pin 14,
if it was already successfully traced? What exactly is "min nid"? Why
pin 14 was traced with min nid 0 the first time, and with min nid 3 the
second time?
Now, let's get back to nid 11, which was "busy by seqmask 1". I digged
my old email from July 2007 [2] on acpi@ about this laptop of mine (I was
running 6.2-STABLE that days and had some ACPI troubles). From attached
verbose dmesg log, however, I can see that snd_hda(4) worked! It was
at revision 20070710_0047 that time. Apparently driver had changed
quite a bit in 2007-2011, so the log is different, but I've noticed some
interesting bits:
Old driver (20070710_0047):
-HDA config/quirks: softpcmvol forcestereo ivref50 ivref80 ivref100 ivref
New driver (20100226_0142):
+FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref
I've tried to add "softpcmvol", did not make any difference, still no
pcm device. Another interesting part in the old driver log is this:
pcm0: HDA_DEBUG: Ctls commit...
pcm0: [ 2] Ctl nid=11 Bind to NONE
pcm0: [ 4] Ctl nid=17 DISABLED
I see no such messages in new driver log, the closest lines are these:
hdac0: Disabling pin nid 17 due to None connectivity.
hdac0: Disabling ctl 4 nid 17 cnid -1 due to disabled widget.
hdac0: Disabling nid 19 due to all it's consumers disabled.
Nothing is said about nid 11 this time, but later it turns out that it
is "busy by seqmask 1". Is there a quirk in new driver to force nid 11
"Bind to NONE" like the old driver did?
Thanks. Feel free to request any additional information.
./danfe
P.S. I'm CCing mav@ this time just to be sure he receives this email.
Given zero interest despite lots of debug information, I start to think
that perhaps I'm asking on the wrong maillist. Should I try stable@ or
web forums instead?
[1] http://193.124.210.26/hda-routing.svg
[2] http://docs.freebsd.org/cgi/mid.cgi?20070721192323.GA38759
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110604142511.GA2424>