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=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 2ADB0C43215 for ; Wed, 27 Nov 2019 11:29:58 +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 AAC4320684 for ; Wed, 27 Nov 2019 11:29:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="SD+KomxY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AAC4320684 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de 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 EB05E16F9; Wed, 27 Nov 2019 12:29:05 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz EB05E16F9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1574854196; bh=6mOb1fvGV8d82Gjc80pP86YDV5HvKOqWm/r4QO1tyt8=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=SD+KomxYcRWgtICJisfvi1gAau+Pv9Sx0cYcwWvguf1JmTGUJaUu5Oq6v7nC2VUuO Ft44VDiHwEOoHaIxCRAORfls8M6H38Px0gUz3X0ns9rhyFgje21UZAO9sCe3q0p+zC hgAsUziWF7OKi8qYXcxjXW9EMuOvd+smeHX+Ry7Q= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 82150F8013B; Wed, 27 Nov 2019 12:29:05 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 0D6C2F8014D; Wed, 27 Nov 2019 12:29:04 +0100 (CET) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 6736FF800CE for ; Wed, 27 Nov 2019 12:28:59 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 6736FF800CE X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7605EAC91; Wed, 27 Nov 2019 11:28:59 +0000 (UTC) Date: Wed, 27 Nov 2019 12:28:59 +0100 Message-ID: From: Takashi Iwai To: Sergey 'Jin' Bostandzhyan In-Reply-To: <20191125173902.GA27981@xn--80adja5bqm.su> References: <20190719111231.GA26592@xn--80adja5bqm.su> <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> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") 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" On Mon, 25 Nov 2019 18:39:02 +0100, Sergey 'Jin' Bostandzhyan wrote: > > Hi Takashi, > > 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? 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. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel