[AMD Official Use Only]
They key here is that smart suspend seems to have a dependency on
pm_suspend_via_firmware().
So if you have an APU doing S2I or Intel SOC doing S2I it will always return 0.
Can we drop that dependency of pm_suspend_via_firmware for it perhaps?
> I don't think smart
I don't think smart suspend works as expected. I asked Raphael about
it several times, but he never got around to following up with me. I
think that is probably the preferred way to go, but the tricky part is
that the dGPUs have integrated bridges and audio and usb and all of
that probably needs
I remember Alex adding a patch for smart suspend such that it skips the suspend
call if runtime pm suspended.
In summary, the resume doesn't work with/without reset?
Thanks,
Lijo
From: Limonciello, Mario
Sent: Wednesday, January 26, 2022 8:47:05 PM
To: Lazar,
[Public]
Right -from an API perspective both amdgpu_acpi_is_s0ix_active and
amdgpu_acpi_is_s3_active are only in suspend ops.
But so coming back to the 4th patch (and the associated bug), what is supposed
to happen with a dGPU on an Intel system that does s2i?
For AMD APU w/ dGPU in the system
Talking from generic API perspective - S3 is considered active for dGPU only if
it's going to non-S0 state. If called from anywhere else than suspend op, this
should return false.
Thanks,
Lijo
From: Limonciello, Mario
Sent: Wednesday, January 26, 2022 8:37:28
[Public]
That was intentional - shouldn't dGPU always be going through S3 path currently?
From: Lazar, Lijo
Sent: Wednesday, January 26, 2022 09:06
To: Limonciello, Mario ;
amd-gfx@lists.freedesktop.org
Cc: Liang, Prike ; Limonciello, Mario
Subject: Re: [PATCH v5 2/4] drm/amd: add support to
[Public]
Returns true for dGPU always. Better to keep the whole check under something
like this.
if (pm_suspend_target_state != PM_SUSPEND_ON)
Thanks,
Lijo
From: amd-gfx on behalf of Mario
Limonciello
Sent: Wednesday, January 26, 2022 9:39:42 AM
To:
