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

[Sergey 'Jin' Bostandzhyan <jin@mediatomb.cc>]

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