From owner-freebsd-multimedia@FreeBSD.ORG Sat Jun 4 14:22:55 2011 Return-Path: Delivered-To: multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24E98106566B; Sat, 4 Jun 2011 14:22:55 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 880318FC0A; Sat, 4 Jun 2011 14:22:54 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1QSrkU-0005dp-8M; Sat, 04 Jun 2011 21:22:46 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id p54EPGEg028387; Sat, 4 Jun 2011 21:25:16 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id p54EPBtw028318; Sat, 4 Jun 2011 21:25:11 +0700 (NOVST) (envelope-from danfe) Date: Sat, 4 Jun 2011 21:25:11 +0700 From: Alexey Dokuchaev To: multimedia@freebsd.org Message-ID: <20110604142511.GA2424@regency.nsu.ru> References: <20100731163218.GA39249@regency.nsu.ru> <20110515163619.GA49401@regency.nsu.ru> <20110516032002.GA94798@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110516032002.GA94798@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i Cc: mav@freebsd.org Subject: Re: snd_hda(4) pin routing issues X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 14:22:55 -0000 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