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

[Mario Limonciello <superm1@kernel.org>]

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