On 10/30/26 02:57, Mike Lothian wrote:
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
No problem.
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
Yeah looking at the tables this does look like a BIOS bug. So quirking
it somewhere feels appropriate.
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
