Re: [Nouveau] [PATCH v2] PCI: Expose hidden NVIDIA HDA controllers
On Thu, Jul 11, 2019 at 6:47 AM Bjorn Helgaas wrote: > I applied this (slightly revised as below) to pci/misc and I think we > can still squeeze it in for v5.3. Thanks. Tested briefly and it seems to be working fine! ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] PCI: Expose hidden NVIDIA HDA controllers
On Mon, Jul 08, 2019 at 01:17:44PM +0800, Daniel Drake wrote: > From: Lukas Wunner > > The integrated HDA controller on Nvidia GPUs can be hidden with a bit in > the GPU's config space. Information about this scheme was provided by > NVIDIA on their forums. > > Many laptops now ship with this device hidden, meaning that Linux users > of affected platforms (where the HDMI connector comes off the NVIDIA GPU) > cannot use HDMI audio functionality. > > Some platforms have ACPI DSDT code that will make the device visible if > the HDMI cable was connected at boot time, but this does not handle the > hotplug case, and this limitation has also been confirmed under Windows. > > Avoid this issue by exposing the HDMI audio device on device enumeration > and resume. > > The GPU and HDA controller are two functions of the same PCI device > (VGA class device on function 0 and audio device on function 1). > The multifunction flag in the GPU's Header Type register is cleared when > the HDA controller is hidden and set if it's exposed, so reread the flag > after exposing the HDA. > > According to Ilia Mirkin, the HDA controller is only present on GPUs with > PCI ID values from MCP89's onwards, so do not touch config space on older > GPUs. > > This quirk is limited to NVIDIA PCI devices with the VGA Controller > device class. This is expected to correspond to product configurations > where the NVIDIA GPU has connectors attached. Other products where the > device class is 3D Controller are expected to correspond to configurations > where the NVIDIA GPU is dedicated (dGPU) and has no connectors. > > It's sensible to avoid exposing the HDA controller on dGPU setups, > especially because we've seen cases where the PCI BARs are not set > up correctly by the platform in this case, causing Linux to log > errors if the device is visible. This assumption of device class > accurately corresponding to product configuration is true for 6 of 6 > laptops recently checked at the Endless lab, and there are also signs of > agreement checking the data from 74 previously tested products, however > Ilia Mirkin comments that he's seen cases where it is not true. Anyway, it > looks like this quirk should fix audio support for the majority of > affected users. > > This commit takes inspiration from an earlier patch by Daniel Drake. > > Link: https://devtalk.nvidia.com/default/topic/1024022 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985 > Cc: Aaron Plattner > Cc: Peter Wu > Cc: Ilia Mirkin > Cc: Karol Herbst > Cc: Maik Freudenberg > Signed-off-by: Lukas Wunner > Signed-off-by: Daniel Drake I applied this (slightly revised as below) to pci/misc and I think we can still squeeze it in for v5.3. My revisions: - Don't write the enable bit if it's already set. - Log a note when enabling the HDA. I don't like writing undocumented config bits in *every* current and future NVIDIA GPU, so the note is just a hint that we're doing something slightly risky. - Use "hdr_type & 0x80" to match the other places we set pdev->multifunction. - Remove the commit log parts that don't seem relevant for future maintenance and add the URL to the original posting. Let me know if I broke anything. commit b678f90a1a6f Author: Lukas Wunner Date: Mon Jul 8 13:17:44 2019 +0800 PCI: Enable NVIDIA HDA controllers Many NVIDIA GPUs can be configured as either a single-function video device or a multi-function device with video at function 0 and an HDA audio controller at function 1. The HDA controller can be enabled or disabled by a bit in the function 0 config space. Some BIOSes leave the HDA disabled, which means the HDMI connector from the NVIDIA GPU may not work. Sometimes the BIOS enables the HDA if an HDMI cable is connected at boot time, but that doesn't handle hotplug cases. Enable the HDA controller on device enumeration and resume and re-read the header type, which tells us whether the GPU is a multi-function device. This quirk is limited to NVIDIA PCI devices with the VGA Controller device class. This is expected to correspond to product configurations where the NVIDIA GPU has connectors attached. Other products where the device class is 3D Controller are expected to correspond to configurations where the NVIDIA GPU is dedicated (dGPU) and has no connectors. See original post (URL below) for more details. This commit takes inspiration from an earlier patch by Daniel Drake. Link: https://lore.kernel.org/r/20190708051744.24039-1-dr...@endlessm.com Link: https://devtalk.nvidia.com/default/topic/1024022 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985 Signed-off-by: Lukas Wunner Signed-off-by: Daniel Drake [bhelgaas: commit log, log message, return early if already enabled] Signed-off-by: Bjorn Helgaas Cc: Aaron Plattner Cc: Peter Wu Cc: Ilia
[Nouveau] [Bug 110955] Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
https://bugs.freedesktop.org/show_bug.cgi?id=110955 --- Comment #10 from power.c...@openmail.cc --- Oh almost forget tank you for the quick response to my problem. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 110955] Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
https://bugs.freedesktop.org/show_bug.cgi?id=110955 --- Comment #8 from Ilia Mirkin --- ../src/mesa/main/context.c:2:7: error: invalid suffix "d81f1..2734693" on integer constant index 03d81f1..2734693 100644 Looks like your patch-application skills require some work. You should just be able to build mainline now -- it will have the change in question already. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 110955] Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
https://bugs.freedesktop.org/show_bug.cgi?id=110955 --- Comment #7 from power.c...@openmail.cc --- Created attachment 144755 --> https://bugs.freedesktop.org/attachment.cgi?id=144755=edit Patched with just the latest suggested patch. Tried without getstring.patch instead used the latest suggested patch for context.patch. It error out to, the output is attached. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 110955] Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
https://bugs.freedesktop.org/show_bug.cgi?id=110955 --- Comment #6 from power.c...@openmail.cc --- Created attachment 144754 --> https://bugs.freedesktop.org/attachment.cgi?id=144754=edit patched with both suggested patches I tried to compile with the patches and I get errors, the output of the build is attached. First patched with the getstring.patch and context.patch. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 110955] Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
https://bugs.freedesktop.org/show_bug.cgi?id=110955 --- Comment #5 from Ilia Mirkin --- That patch is missing the actual version... given that this is a NV18, this should be fixed by https://cgit.freedesktop.org/mesa/mesa/commit/?id=0349bc3ce2b399082593ddcf1d28782a4566bc08 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 110955] Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
https://bugs.freedesktop.org/show_bug.cgi?id=110955 --- Comment #4 from power.c...@openmail.cc --- Created attachment 144753 --> https://bugs.freedesktop.org/attachment.cgi?id=144753=edit glxinfo Attached the output of glxinfo, tryed to build mesa from src it was successfull, but havem't patched yet. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 111098] New: xf16-video-nouveau 1.0.16-1 arch fails to resume from blank
https://bugs.freedesktop.org/show_bug.cgi?id=111098 Bug ID: 111098 Summary: xf16-video-nouveau 1.0.16-1 arch fails to resume from blank Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: pa...@matos-sorge.com QA Contact: nouveau@lists.freedesktop.org I have a GM206 video (GTX950) card and moved from the official drivers to nouveau to try them out. It fails to resume from a blank screen. I am on a dual head setup. The card (from lspci -vv) is: 02:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 950] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. GM206 [GeForce GTX 950] Physical Slot: 4 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [420 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 Capabilities: [900 v1] Secondary PCI Express Kernel driver in use: nouveau Kernel modules: nouveau The xorg config I have for dual head is at xorg.conf.d/20-nouveau.conf: # the right one Section "Monitor" Identifier "LG1" # 3840x2160 59.98 Hz (CVT 8.29M9) hsync: 134.18 kHz; pclk: 712.75 MHz Modeline "3840x2160_60.00" 712.75 3840 4160 4576 5312 2160 2163 2168 2237 -hsync +vsync Option "PreferredMode" "3840x2160_60.00" EndSection # the left one Section "Monitor" Identifier "LG2" # 3840x2160 59.98 Hz (CVT 8.29M9) hsync: 134.18 kHz; pclk: 712.75 MHz Modeline "3840x2160_60.00" 712.75 3840 4160 4576 5312 2160 2163 2168 2237 -hsync +vsync Option "PreferredMode" "3840x2160_60.00" Option "RightOf" "LG1" Option "Rotate" "right" EndSection Section "Device" Identifier "nvidia card" Driver "nouveau" Option "DP-2" "LG1" Option "DP-3" "LG2" EndSection Section "Screen" Identifier "screen1" Monitor "LG1" DefaultDepth 24 SubSection "Display" Depth 24 Virtual 2560 2048 EndSubSection Device "nvidia card" EndSection Section "ServerLayout" Identifier "layout1" Screen "screen1" EndSection This config is not necessarily correct (virtual is not properly setup) but it should cause any crashes. journalctl -xb | grep nouveau: Jul 09 18:20:29 andromeda kernel: fb0: switching to nouveaufb from EFI VGA Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: NVIDIA GM206 (126020a1) Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: bios: version 84.06.2f.00.7e Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: fb: 2048 MiB GDDR5 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: bus: MMIO write of 8028 FAULT at 10eb14 [ IBUS ] Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: VRAM: 2048 MiB Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: GART: 1048576 MiB Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: TMDS table version 2.0 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB version 4.1 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 00: 01000f02 00020030 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 01: 02000f00 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 02: 02811f76 04400020 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 03: 02011f72 00020020 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 04: 04822f86 04400010 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 05: 04022f82 00020010 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 06: 04833f96 04400020 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp 07: 04033f92 00020020 Jul 09 18:20:29 andromeda kernel: nouveau :02:00.0: DRM: DCB outp
