On Thu, 29 Oct 2026, Alex Deucher wrote: > I'm not sure about BACO. In the BOCO case the OEM has a mux on the HPD > pins that redirects them to the EC when the dGPU is powered off. For > BACO it's usually a PCIe add-in board so there is no way to redirect > the HPD pins.
Agreed, and I can't test BACO anyway, so I'll keep it BOCO only in v2 Mario, sorry, I'll leave your BACO suggestion out unless someone has a board that needs it > Mike Lothian does your system have ATIF? This is already code to > handle this. It sounds like it's just registering the wrong ACPI node. > You should be able to use the existing handler. It does, but only on the iGPU: ATIF is in SSDT7 under \_SB.PCI0.GP17.VGA_, and the dGPU node (\_SB.PCI0.GPP0.SWUS.SWDS.VGA_) has none What arrives here isn't an ATIF notification either. _L05 in SSDT9 is just Notify (\_SB.PCI0.GPP0.VGA, 0x81), and that path doesn't exist on this board, so the interpreter aborts the method with AE_NOT_FOUND and no Notify is delivered to anything. I've put the tables and the errors in a bug: https://gitlab.freedesktop.org/drm/amd/-/work_items/6061 What I haven't checked is whether the firmware would flag a dGPU display event in the ATIF SBIOS requests if the Notify did arrive at the right node. If I alias the path so it resolves, I can turn on drm.debug and see whether amdgpu_atif_handler() fires and what request flags come back, and if ATIF_DGPU_DISPLAY_EVENT is set I'll use the existing handler rather than add a new one. I'll report back Mike
