On 4/10/21 1:48 PM, Roy Spliet wrote:
Op 10-04-2021 om 20:23 schreef Lukas Wunner:
On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
Can I ask someone with more
technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm
about
the possible challenges of nouveau taking matters into its own hand
rather
than keeping this PCI quirk around?
It sounds to me like the HDA is not powered if no cable is plugged in.
What is reponsible then for powering it up or down, firmware code on
the GPU or in the host's BIOS?
Sometimes the BIOS, but definitely unconditionally the PCI quirk code:
https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
(CC Aaron Plattner)
My basic understanding is that the audio function stops responding
whenever the graphics function is powered off. So the requirement here
is that the audio driver can't try to talk to the audio function while
the graphics function is asleep, and must trigger a graphics function
wakeup before trying to communicate with the audio function. I think
there are also requirements about the audio function needing to be awake
when the graphics driver is updating the ELD, but I'm not sure.
This is harder on Windows because the audio driver lives in its own
little world doing its own thing but on Linux we can do better.
Ideally, we should try to find out how to control HDA power from the
operating system rather than trying to cooperate with whatever firmware
is doing. If we have that capability, the OS should power the HDA up
and down as it sees fit.
After system boot, I don't think there's any firmware involved, but I'm
not super familiar with the low-level details and it's possible the
situation changed since I last looked at it.
I think the problem with having nouveau write this quirk is that the
kernel will need to re-probe the PCI device to notice that it has
suddenly become a multi-function device with an audio function, and
hotplug the audio driver. I originally looked into trying to do that but
it was tricky because the PCI subsystem didn't really have a mechanism
for a single-function device to become a multi-function device on the
fly and it seemed easier to enable it early on during bus enumeration.
That way the kernel sees both functions all the time without anything
else having to be special about this configuration.
-- Aaron
Thanks,
Lukas
