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