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: Thu, 20 Jun 2019 08:16:41 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1480666761==" 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 --===============1480666761== Content-Type: multipart/alternative; boundary="15610186015.c7D5e3.25955" Content-Transfer-Encoding: 7bit --15610186015.c7D5e3.25955 Date: Thu, 20 Jun 2019 08:16:41 +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 #78 from Lukas Wunner --- (In reply to Daniel Drake from comment #77) > MLTF presumably means multifunction and it's exactly the bit we've been > working with. But I haven't yet managed to get _PS0 to run this code. I g= et > to the GGIV(0x01080001) call, but it returns 0, so the bit doesn't get se= t. >=20 > I tried understanding what GGIV() does but nothing is clear there. It ends > up reading bit 1 from physical memory address 0xfdac0408 which is under: > pci_bus 0000:00: resource 21 [mem 0xfd000000-0xfe7fffff window] > and I can't immediately spot any ACPI code that writes to that address. GGIV is a method name used by many vendors to read a GPIO pin. "Get GPIO In= put Value" or something like that. Quite likely the GPIO pin in question is attached to HPD of an HDMI or DP p= ort. So if an external display is attached, GGIV(0x01080001) should return 1 and= the HDA is exposed, else it's hidden. If the GPIO pin in question is on the PCH then you can download the spec for the PCH from Intel's website to verify that the MMIO space at 0x01080001 is= a GPIO block. The GPIO pin could also be on the Nvidia card itself, in that c= ase physical address 0x01080001 would belong to a resource of the GPU's PCI dev= ice. --=20 You are receiving this mail because: You are the assignee for the bug.= --15610186015.c7D5e3.25955 Date: Thu, 20 Jun 2019 08:16:41 +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 # 78 on bug 75985<= /a> from Lukas Wunner 
(In reply to Daniel Drake from comment #77)
> MLTF presumably means multifunction and it's exa=
ctly the bit we've been
> working with. But I haven't yet managed to get _PS0 to run this code. =
I get
> to the GGIV(0x01080001) call, but it returns 0, so the bit doesn't get=
 set.
>=20
> I tried understanding what GGIV() does but nothing is clear there. It =
ends
> up reading bit 1 from physical memory address 0xfdac0408 which is unde=
r:
> pci_bus 0000:00: resource 21 [mem 0xfd000000-0xfe7fffff window]
> and I can't immediately spot any ACPI code that writes to that address=
.

GGIV is a method name used by many vendors to read a GPIO pin. "Get GP=
IO Input
Value" or something like that.

Quite likely the GPIO pin in question is attached to HPD of an HDMI or DP p=
ort.
So if an external display is attached, GGIV(0x01080001) should return 1 and=
 the
HDA is exposed, else it's hidden.

If the GPIO pin in question is on the PCH then you can download the spec for
the PCH from Intel's website to verify that the MMIO space at 0x01080001 is=
 a
GPIO block. The GPIO pin could also be on the Nvidia card itself, in that c=
ase
physical address 0x01080001 would belong to a resource of the GPU's PCI dev=
ice.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15610186015.c7D5e3.25955-- --===============1480666761== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTm91dmVhdSBt YWlsaW5nIGxpc3QKTm91dmVhdUBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9ub3V2ZWF1 --===============1480666761==--