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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #39 from Maik Freudenberg --- Lukas, unconditionally enabling the nvidia hda shouldn't be done. In my case, having a "3D controlller" meaning a dGPU without outputs this would lead to having a broken HDA device

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #40 from Maik Freudenberg --- Should be easily avoidable by not enabling it when adapter class is PCI_CLASS_DISPLAY_3D -- You are receiving this mail because: You are the assignee for the

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #41 from Lukas Wunner --- (In reply to Maik Freudenberg from comment #39) > Lukas, unconditionally enabling the nvidia hda shouldn't be done. In my > case, having a "3D controller" meaning a dGPU without outputs this

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #42 from Maik Freudenberg --- The hda devices on 3D controller are existing but not completely configured by vendors leading to errors like [ 4790.121207] pci :07:00.1: [10de:0e0f] type 00 class 0x040300 [

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #44 from Ilia Mirkin --- (In reply to Maik Freudenberg from comment #42) > The hda devices on 3D controller are existing but not completely configured > by vendors leading to errors like > [ 4790.121207] pci

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #43 from Lukas Wunner --- (In reply to Maik Freudenberg from comment #42) > The hda devices on 3D controller are existing but not completely configured > by vendors leading to errors like > [ 4790.121207] pci

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #49 from Ilia Mirkin --- (In reply to Maik Freudenberg from comment #47) > There's of course the possibility that some braindead vendor would ship a 3D > class tagged device actually having outputs. This

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #48 from Maik Freudenberg --- (In reply to Denis Lisov from comment #45) > For this hardware, even a plugged in HDMI TV on boot does not cause the > audio device to appear, so the test was done with a PCI early quirk

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #45 from Denis Lisov --- (In reply to Lukas Wunner from comment #37) > Related to this issue, I've just posted v2 of my patch set to use a device > link for power management of GPU-integrated HDA controllers:

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #46 from Maik Freudenberg --- (In reply to Lukas Wunner from comment #43) > Is this a Thunderbolt-attached GPU? Calm down, get back to basics. This is the dmesg when you turn on the hda dev on a 3d class device. Just

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #47 from Maik Freudenberg --- There's of course the possibility that some braindead vendor would ship a 3D class tagged device actually having outputs. From my observations, this would break the prop. driver so this

[Nouveau] [Bug 75464] [nv4e] [vdpau] causes hangs

https://bugs.freedesktop.org/show_bug.cgi?id=75464 --- Comment #3 from Nick Lee --- Causes hangs when I seeking (pressing key left/right in mpv) with this error: 13:16:53.084345 zotac kernel: nouveau :03:00.0: Xwayland[2069]: failed to idle channel 25 [Xwayland[2069]]

[Nouveau] [PATCH v2 4/7] vga_switcheroo: Deduplicate power state tracking

If DRM drivers use runtime PM, they currently notify vga_switcheroo whenever they ->runtime_suspend or ->runtime_resume to update vga_switcheroo's internal power state tracking. That's essentially a duplication of a functionality performed by the PM core as it already tracks the GPU's power state

[Nouveau] [PATCH v2 3/7] vga_switcheroo: Update PCI current_state on power change

When cutting power to a GPU and its integrated HDA controller, their cached current_state should be updated to D3cold to reflect reality. We currently rely on the DRM and HDA drivers to do that, however: - The HDA driver updates the current_state in azx_vs_set_state(), which will no longer be

[Nouveau] [PATCH v2 1/7] PCI: Restore config space on runtime resume despite being unbound

From: Rafael J. Wysocki We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the

[Nouveau] [PATCH v2 2/7] PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public

There are PCI devices which are power-manageable by a nonstandard means, such as a custom ACPI method. One example are discrete GPUs in hybrid graphics laptops, another are Thunderbolt controllers in Macs. Such devices can't be put into D3cold with pci_set_power_state() because

[Nouveau] [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA

Modernize vga_switcheroo by using a device link to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into, v2. Changes since v1: - Replace patch [1/7] to use pci_save_state() / pci_restore_state() for consistency between runtime PM code path of bound and unbound

[Nouveau] [PATCH v2 6/7] vga_switcheroo: Let HDA autosuspend on mux change

When switching the display on muxed machines, we currently force the HDA controller into runtime suspend on the previously used GPU and into runtime active state on the newly used GPU. That's unnecessary if the GPU uses driver power control, we can just let the audio device autosuspend or

[Nouveau] [PATCH v2 7/7] drm/nouveau: Runtime suspend despite HDA being unbound

Commit 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)") prevents runtime suspend of the GPU if its integrated HDA controller is not bound to a driver. The rationale appears to be that probing the HDA fails if the GPU is in D3cold. However we now use a device link to ensure that the GPU is

[Nouveau] [PATCH] mmu: ALIGN_DOWN correct variable

Commit 7110c89bb8852ff8b0f88ce05b332b3fe22bd11e ("mmu: swap out round for ALIGN") replaced two calls to round/rounddown with ALIGN/ALIGN_DOWN, but erroneously applied ALIGN_DOWN to a different variable (addr) and left intended variable (tail) not rounded/ALIGNed. As a result screen corruption, X

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 --- Comment #37 from Lukas Wunner --- Related to this issue, I've just posted v2 of my patch set to use a device link for power management of GPU-integrated HDA controllers:

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

https://bugs.freedesktop.org/show_bug.cgi?id=75985 Lukas Wunner changed: What|Removed |Added CC||lu...@wunner.de ---