Re: [PATCH 1/2] drm/amdgpu: runtime resume dGPU on ACPI notify from its own node

[Mike Lothian <mike@fireburn.co.uk>]

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