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@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
