From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 568B9C432C0 for ; Wed, 27 Nov 2019 16:18:57 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D2FE420665 for ; Wed, 27 Nov 2019 16:18:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="GT1KY2Ao" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D2FE420665 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatomb.cc Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 25C9D16FB; Wed, 27 Nov 2019 17:18:05 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 25C9D16FB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1574871535; bh=W1hKSz0OP2TRcLNpNlWWbAsbUR78bHtiszJi8WolA3I=; h=Date:From:To:References:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=GT1KY2AoCt4R64r2NFt8p++r9qya/yyqsJ55NokuDMzZML9BKsv3GEdRPcTZOrJIm AsqL+Y1vwYb8tVpMs6AY6ssn9wELAq8/sGj6PaRNHHT3tmpNI8MycM13ZZmR2UXgNi 3J4xxoZmu/VbTXvXTw5Lro2gx8SBC+vEOBINg8so= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id AD480F8013B; Wed, 27 Nov 2019 17:18:04 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A11D6F8014D; Wed, 27 Nov 2019 17:18:02 +0100 (CET) Received: from mail1.xn--80adja5bqm.su (xn--80adja5bqm.su [45.62.210.217]) by alsa1.perex.cz (Postfix) with ESMTP id 636ECF80109 for ; Wed, 27 Nov 2019 17:17:58 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 636ECF80109 Received: by mail1.xn--80adja5bqm.su (Postfix, from userid 1000) id 46C3D20C5462; Wed, 27 Nov 2019 17:17:57 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mail1.xn--80adja5bqm.su 46C3D20C5462 Date: Wed, 27 Nov 2019 17:17:57 +0100 From: Sergey 'Jin' Bostandzhyan To: Takashi Iwai Message-Id: <20191127161757.GC7065@xn--80adja5bqm.su> References: <20190720165435.GA5855@xn--80adja5bqm.su> <20190819195714.GA2737@xn--80adja5bqm.su> <20190822203031.GA22363@xn--80adja5bqm.su> <20190829103805.GA1525@xn--80adja5bqm.su> <20190830114510.GA10027@xn--80adja5bqm.su> <20191125173902.GA27981@xn--80adja5bqm.su> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Surround speaker connection on Acer 8951G X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi Takashi, On Wed, Nov 27, 2019 at 12:28:59PM +0100, Takashi Iwai wrote: > > sorry - it's me again about the Acer 8951G LFE speaker. > > > > On Fri, Aug 30, 2019 at 01:45:10PM +0200, Sergey 'Jin' Bostandzhyan wrote: > > > > > The below HDA_FIXUP_VERBS does the trick, so I do have all 6 speakers working, > > > > > finally! > > > > > > > > > > {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x02} > > > > > > > > Actually this must be paired with the corresponding bit of GPIO_DATA, > > > > too. Is the bit 0x02 of GPIO_DATA set or cleared? Usually setting it > > > > turns on the amp, but sometimes inverted. > > > > > > If I understood everything correctly, then the bit is set, meaning that the > > > GPIO signal is configured as output. I'll be honest, I exported the > > > hda-analyzer setting as a python script (nice feature btw) and deducted the > > > fixup verb setting from there (relevant part of the hda-analyzer export below): > > > > > > def set(nid, verb, param): > > > verb = (nid << 24) | (verb << 8) | param > > > res = ioctl(FD, IOCTL_VERB_WRITE, struct.pack('II', verb, 0)) > > > > > > set(0x01, 0x717, 0x02) # 0x01071702 (SET_GPIO_DIRECTION) > > > > it seems I indeed missed something here regarding GPIO_DATA, I really am > > not sure what the influence is, but after updating to Fedora 31 my LFE > > stopped working, even with the self compiled 5.4-rc8 kernel which I am running > > now (all the time before I was on Fedora 29 and I just backported my patch to > > 5.2.x and compiled the modules outside the tree after being done with the > > patch submission). > > > > So ultimately, it seems I now need to do the following in my fixup > > (original commit was 00066e9733f629e536f6b7957de2ce11a85fe15a): > > > > --- a/sound/pci/hda/patch_realtek.c > > +++ b/sound/pci/hda/patch_realtek.c > > @@ -8875,7 +8875,7 @@ static const struct hda_fixup alc662_fixups[] = { > > .v.verbs = (const struct hda_verb[]) { > > {0x01, AC_VERB_SET_GPIO_MASK, 0x02}, > > {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x02}, > > - {0x01, AC_VERB_SET_GPIO_DATA, 0x00}, > > + {0x01, AC_VERB_SET_GPIO_DATA, 0x02}, > > { } > > }, > > .chained = true, > > That makes more sense. Usually GPIO pin is off as default, and the > driver needs to turn it up manually for a special usage. > > > My question is: could something on the outside have influence on that? I am > > really very, very sure that I have tested LFE on kernel 5.4-rc before > > submitting the original patch and it has been working as submitted. > > Why did the behavior change now? What else could I have missed? > > Maybe the chip kept the GPIO pin on after warm boot from Windows or > such? This is unlikely as I do not have Windows or any other OS installed on this system. I dug through the thread and found the following: > > > set(0x01, 0x717, 0x02) # 0x01071702 (SET_GPIO_DIRECTION) > > > > This needs the paired SET_GPIO_DATA for a proper operation. Your > > analysis implicit assumes some default value that is already set by > > the hardware. > >If I understand it correctly, then "some value" is zero on my hardware: > > # hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x02 > nid = 0x1, verb = 0xf15, param = 0x2 > value = 0x0 > > Meanwhile I also figured out that /proc/asound/card0/codec#0 is > providing this info as well: > > IO[1]: enable=0, dir=1, wake=0, sticky=0, data=0, unsol=0 > > So the value seems to be 0 and I can add an explicit SET_GPIO_DATA verb quirk > to set it in addition to SET_GPIO_DIRECTION, right? You then helped me, explaining how I could properly initialize it, which I incorporated in the original patch. So we did check that and I am positive that the LFE did work back then, which really confuses me now. > Please make sure that which value actually is on and which is off. > You can change the GPIO bit dynamically via hda-verb, so you can check > whether the speaker works or not at each flip. OK, so the starting point (now with my local update to the driver): # hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x02 nid = 0x1, verb = 0xf15, param = 0x2 value = 0x2 >From /proc/asound/card0/codec#0: State of AFG node 0x01: Power states: D0 D1 D2 D3 CLKSTOP Power: setting=D0, actual=D0 GPIO: io=2, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 Pulse profile "Analog Surround 5.1 Output + Analog Stereo Input" is active, speaker test (via the pulse/sound applet UI) delives audible noise on the LFE. I'm flipping data in hda-analyzer now and rechecking afterwards: # hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x02 nid = 0x1, verb = 0xf15, param = 0x2 value = 0x0 And: State of AFG node 0x01: Power states: D0 D1 D2 D3 CLKSTOP Power: setting=D0, actual=D0 GPIO: io=2, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 LFE is no longer audible in speaker test. Reenabling again, this time I just used hda-verb directly: # hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02 nid = 0x1, verb = 0x715, param = 0x2 value = 0x0 And checking: # hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0x02 nid = 0x1, verb = 0xf15, param = 0x2 value = 0x2 LFE becomes audible again. Now, if that would help, I could try to install Fedora 29 on some external harddrive and reproduce my summer setup, to confirm that it has been working with data pin disabled. Alltough I am certain that it was the case, because I retested this several times prior to submitting the patch. Question is, if we would learn something from that? How should I proceed? Just submit an update to have the data pin active on init or is this weirdness worth debugging? Thanks, Jin _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel