[Bug 75985] [NVC1] HDMI audio device only visible after rescan

[bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org]

[-- Attachment #1.1: Type: text/plain, Size: 2378 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=75985

--- Comment #69 from Daniel Drake <dan-LrsmPHowOvpd3aXB8m+yKQ@public.gmane.org> ---
Thanks for the efforts here. I have tested the switcheroo_devlink_v2 branch
plus patches:

 [PATCH 1/3] PCI: Expose Nvidia HDA controllers 
 [PATCH 2/3] PCI: Apply quirks on runtime resume despite being unbound
 [PATCH 3/3] ALSA: hda - Broaden VGA class matching 

on Asus GL502VS with GP104M [GeForce GTX 1070].

The quirk works in that the HDMI audio PCI device now appears. I checked with
and without the quirk, the login screen idle power consumption from
/sys/class/power_supply/BAT0/power_now is 31W-32W in both cases (no difference
observed with the quirk).

However, with no graphics driver loaded, or with nouveau loaded, HDMI audio
does not work at all and the eld files in /proc/asound show that no HDMI
display is connected. If I load the proprietary nvidia driver and then start X,
the eld files change their values to indicate a connected device, and HDMI
audio works. After suspend and resume the HDMI audio continues working.

I also tested GL702VMK with GP106M [GeForce GTX 1060], with the proprietary
nvidia driver, HDMI audio now works and also after suspend/resume.

Also tested Asus UX550GE with GP107M [GeForce GTX 1050 Ti Mobile] with the
proprietary driver. This one could not be worked around with previous userspace
approaches (setpci, remove, rescan) because after remove/rescan the magic bit
had gone back to zero. But this new kernel approach works, the magic bit gets
stuck on and HDMI audio works. Also tested suspend/resume and it still works.

Results look good, but I have 2 concerns:
 1. The proprietary nvidia driver does something special on these platforms to
make the HDMI audio work after it has appeared. nouveau does not do this, so
this will not fix HDMI audio for nouveau users on some platforms, something
else is needed too.
 2. Do we understand why the underlying nvidia/windows design is like this in
the first place? I previously confirmed that Windows dynamically
enables/disables this magic bit based on presence of a HDMI display - i.e.
Windows does not do the approach being considered here which makes it
always-on. Is there a good reason for this that we're missing?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3138 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau