Re: [alsa-devel] Surround speaker connection on Acer 8951G

From: Takashi Iwai <tiwai@suse.de>
To: Sergey 'Jin' Bostandzhyan <jin@mediatomb.cc>
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Surround speaker connection on Acer 8951G
Date: Wed, 27 Nov 2019 12:28:59 +0100	[thread overview]
Message-ID: <s5h4kypy2v8.wl-tiwai@suse.de> (raw)
In-Reply-To: <20191125173902.GA27981@xn--80adja5bqm.su>

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