All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Kuehling <felix.kuehling@amd.com>
To: Alex Deucher <alexdeucher@gmail.com>,
	"Lazar, Lijo" <Lijo.Lazar@amd.com>,
	 Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags
Date: Thu, 4 Feb 2021 10:14:19 -0500	[thread overview]
Message-ID: <b153dea1-2c64-5607-028f-855c1c86fea7@amd.com> (raw)
In-Reply-To: <CADnq5_NH0ezDtVhOE-teJZBZNdDV22is1jVkaKxe7pcof8-qbg@mail.gmail.com>


Am 2021-02-04 um 9:37 a.m. schrieb Alex Deucher:
> On Wed, Feb 3, 2021 at 2:56 AM Lazar, Lijo <Lijo.Lazar@amd.com> wrote:
>> [AMD Public Use]
>>
>>
>> -----Original Message-----
>> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Alex Deucher
>> Sent: Tuesday, February 2, 2021 10:48 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>
>> Subject: [PATCH 2/2] drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags
>>
>> Once the device has runtime suspended, we don't need to power it back up again for system suspend.  Likewise for resume, we don't to power up the device again on resume only to power it back off again via runtime pm because it's still idle.
>>
>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> index b4780182f990..b78847fa769b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> @@ -206,6 +206,12 @@ int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags)
>>                 if (amdgpu_device_supports_atpx(dev) &&
>>                     !amdgpu_is_atpx_hybrid())
>>                         dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NO_DIRECT_COMPLETE);
>> +               /* we want direct complete for BOCO */
>> +               if ((amdgpu_device_supports_atpx(dev) &&
>> +                   amdgpu_is_atpx_hybrid()) ||
>> +                   amdgpu_device_supports_boco(dev))
>> +                       dev_pm_set_driver_flags(dev->dev, DPM_FLAG_SMART_SUSPEND |
>> +                                               DPM_FLAG_MAY_SKIP_RESUME);
>>
>> Device runtime suspend callback does -
>>         amdgpu_device_suspend(drm_dev, false)
>>
>> System suspend callback does -
>>         amdgpu_device_suspend(drm_dev, true)
>>
>> One of the effects of this flag is for KFD to decide whether to evict all processes. It is done during system suspend but not during runtime device suspend. Will that have an impact if  the system suspend routine is skipped in this way?
> + Rajneesh
>
> Can you comment on this?  Idea of this patch is to not wake the device
> for system suspend and resume if it's already in runtime suspend.
KFD only allows runtime suspend when there are no processes using the
GPU. Therefore it should be safe (in theory) to skip process eviction if
you're already in runtime suspend. Just make sure all the suspend/resume
calls into KFD are paired up correctly. If you skip suspend but then
later call resume anyway, it will likely cause problems.

For testing this, I'd suggest running some KFD application (e.g. kfdtest
or an OpenCL app with ROCm-based OpenCL) before suspend, then suspend,
then run the app again after resume to make sure KFD is still good.

Regards,
  Felix


>
> Alex
>
>> Thanks,
>> Lijo
>>
>>                 pm_runtime_use_autosuspend(dev->dev);
>>                 pm_runtime_set_autosuspend_delay(dev->dev, 5000);
>>                 pm_runtime_allow(dev->dev);
>> --
>> 2.29.2
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2021-02-04 15:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02 17:17 [PATCH 1/2] drm/amdgpu: add a dev_pm_ops prepare callback (v2) Alex Deucher
2021-02-02 17:17 ` [PATCH 2/2] drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags Alex Deucher
2021-02-03  4:44   ` Quan, Evan
2021-02-03  7:56   ` Lazar, Lijo
2021-02-04 14:37     ` Alex Deucher
2021-02-04 15:14       ` Felix Kuehling [this message]
2021-02-05  5:59         ` Bhardwaj, Rajneesh
2021-02-04 10:20   ` Michal Rostecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b153dea1-2c64-5607-028f-855c1c86fea7@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Lijo.Lazar@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=rajneesh.bhardwaj@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.