From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org Subject: [Bug 75985] [NVC1] HDMI audio device only visible after rescan Date: Tue, 24 Apr 2018 20:27:10 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1815468783==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Nouveau" To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org List-Id: nouveau.vger.kernel.org --===============1815468783== Content-Type: multipart/alternative; boundary="15246016304.Ed3AF.3392" Content-Transfer-Encoding: 7bit --15246016304.Ed3AF.3392 Date: Tue, 24 Apr 2018 20:27:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D75985 --- Comment #70 from Aaron Plattner --- How the audio and video drivers interact is described a bit in [1]: The aud= io function and the graphics function work hand-in-hand to provide audio suppo= rt. At modeset time, the graphics driver extracts information from the display's EDID and the mode timings and sticks it into registers in the graphics function. These get processed by the hardware and spit out the other side v= ia the "EDID-Like Data" fields in the audio function, described in [2]. I'm not completely sure how this works on Windows, but my understanding is = that the display driver enables or disables the audio function at modeset time, = and Windows handles that as a PCI hot-plug or -unplug, loading or unloading the audio driver as necessary. On Linux, I think the nouveau and nvidia-modeset drivers would need to call into some hypothetical new audio power module to coordinate that, so the kernel can know when to rescan or remove the audio device. [1] https://download.nvidia.com/XFree86/gpu-hdmi-audio-document/#_driver_archit= ecture [2] https://www.intel.com/content/www/us/en/standards/high-definition-audio-spe= cification.html --=20 You are receiving this mail because: You are the assignee for the bug.= --15246016304.Ed3AF.3392 Date: Tue, 24 Apr 2018 20:27:10 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Commen= t # 70 on bug 75985<= /a> from Aaron Plattner
How the audio and video drivers interact is described a bit in=
 [1]: The audio
function and the graphics function work hand-in-hand to provide audio suppo=
rt.
At modeset time, the graphics driver extracts information from the display's
EDID and the mode timings and sticks it into registers in the graphics
function. These get processed by the hardware and spit out the other side v=
ia
the "EDID-Like Data" fields in the audio function, described in [=
2].

I'm not completely sure how this works on Windows, but my understanding is =
that
the display driver enables or disables the audio function at modeset time, =
and
Windows handles that as a PCI hot-plug or -unplug, loading or unloading the
audio driver as necessary. On Linux, I think the nouveau and nvidia-modeset
drivers would need to call into some hypothetical new audio power module to
coordinate that, so the kernel can know when to rescan or remove the audio
device.

[1]
https://download.nvidia.com/XFree86/gpu-hdmi-audio-docum=
ent/#_driver_architecture
[2]
https://www.intel.com/content/www/us/en/standar=
ds/high-definition-audio-specification.html


You are receiving this mail because:
  • You are the assignee for the bug.
= --15246016304.Ed3AF.3392-- --===============1815468783== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTm91dmVhdSBt YWlsaW5nIGxpc3QKTm91dmVhdUBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9ub3V2ZWF1Cg== --===============1815468783==--