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 07:25:33 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1368505927==" 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 --===============1368505927== Content-Type: multipart/alternative; boundary="15610155342.cCd01d.18494" Content-Transfer-Encoding: 7bit --15610155342.cCd01d.18494 Date: Thu, 20 Jun 2019 07:25:34 +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 #77 from Daniel Drake --- Created attachment 144596 --> https://bugs.freedesktop.org/attachment.cgi?id=3D144596&action=3Dedit Acer Predator G3-572 acpidump Martin Lopat=C3=A1=C5=99, thanks for the analysis above, sorry I missed tho= se details before! Checking on my Acer Predator G3-572 (acpidump attached here), I can see what you're referring to in SSDT5: OperationRegion (PCNV, SystemMemory, \_SB.PCI0.PEG0.PEGP.EBAS, 0x10= 00) Field (PCNV, AnyAcc, NoLock, Preserve) { Offset (0x488),=20 , 25,=20 MLTF, 1 } Method (_PS0, 0, NotSerialized) // _PS0: Power State 0 { If (DGOS) { If ((\_SB.PCI0.PEG0.PEGP.DPCS !=3D Zero)) { \_SB.PCI0.PEG0.PEGP._ON () DGOS =3D Zero } } ElseIf ((\_SB.PCI0.PEG0.DVID !=3D 0xFFFF)) { If ((GGIV (0x01080001) =3D=3D Zero)) { MLTF =3D Zero } Else { MLTF =3D One \_SB.PCI0.PEG0.PEGP.NASV =3D \_SB.PCI0.PEG0.PEGP.DSSV } } } MLTF presumably means multifunction and it's exactly the bit we've been wor= king 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. I looked for some obvious connection to stuff in _DSM but I can't spot anything. Can you clarify exactly what you saw that links _DSM and _PS0 together, and share your acpidump? 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. --=20 You are receiving this mail because: You are the assignee for the bug.= --15610155342.cCd01d.18494 Date: Thu, 20 Jun 2019 07:25:34 +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 # 77 on bug 75985<= /a> from Daniel Drake 
Created attachment=
 144596 [details]
Acer Predator G3-572 acpidump

Martin Lopat=C3=A1=C5=99, thanks for the analysis above, sorry I missed tho=
se details
before!

Checking on my Acer Predator G3-572 (acpidump attached here), I can see what
you're referring to in SSDT5:

        OperationRegion (PCNV, SystemMemory, \_SB.PCI0.PEG0.PEGP.EBAS, 0x10=
00)
        Field (PCNV, AnyAcc, NoLock, Preserve)
        {
            Offset (0x488),=20
                ,   25,=20
            MLTF,   1
        }

        Method (_PS0, 0, NotSerialized)  // _PS0: Power State 0
        {
            If (DGOS)
            {
                If ((\_SB.PCI0.PEG0.PEGP.DPCS !=3D Zero))
                {
                    \_SB.PCI0.PEG0.PEGP._ON ()
                    DGOS =3D Zero
                }
            }
            ElseIf ((\_SB.PCI0.PEG0.DVID !=3D 0xFFFF))
            {
                If ((GGIV (0x01080001) =3D=3D Zero))
                {
                    MLTF =3D Zero
                }
                Else
                {
                    MLTF =3D One
                    \_SB.PCI0.PEG0.PEGP.NASV =3D \_SB.PCI0.PEG0.PEGP.DSSV
                }
            }
        }

MLTF presumably means multifunction and it's exactly the bit we've been wor=
king
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.

I looked for some obvious connection to stuff in _DSM but I can't spot
anything. Can you clarify exactly what you saw that links _DSM and _PS0
together, and share your acpidump?

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.

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