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