Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Das, Nirmoy" <nirmoy.das@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Chris Wilson <chris.p.wilson@linux.intel.com>,
	Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Clear wedged status upon suspend
Date: Wed, 25 Jan 2023 14:28:23 +0100	[thread overview]
Message-ID: <592aad9f-fb3b-4369-4683-aef49628786a@linux.intel.com> (raw)
In-Reply-To: <Y9Aw3sCGt+s+qGIO@intel.com>

Hi Rodrigo,

On 1/24/2023 8:26 PM, Rodrigo Vivi wrote:
> On Tue, Jan 24, 2023 at 12:07:19PM +0100, Das, Nirmoy wrote:
>> Forgot to add the drm issue a reference.
>>
>> On 1/24/2023 12:05 PM, Nirmoy Das wrote:
>>> From: Chris Wilson <chris.p.wilson@linux.intel.com>
>>>
>>> Currently we use set-wedged on suspend if the workload is not responding
>>> in order to allow a fast suspend (albeit at the cost of discarding the
>>> current userspace). This may leave the device wedged during suspend,
>>> where we may require the device available in order to swapout CPU
>>> inaccessible device memory. Clear any temporary wedged-status after
>>> flushing userspace off the device so we can use the blitter ourselves
>>> inside suspend.
> This seems a very good move. But this explain they unset_wedged part,
> not the removal of the retire_requests. Why don't we need to retire them
> anymore?


Thanks for noticing that. This on me, I missed another patch which moved 
the intel_gt_retire_requests()

inside of intel_gt_set_wedged().

>
> Also, what are the chances of races here? I mean, we are marking
> the gpu as not wedged anymore. Do we have any warranty at this point
> that no further request will arrive?


The assumption was: this is  in single threaded suspend "context" so we 
should be fine but

we just realized that  this is getting called at pm prepare time. Thanks 
for raising this it seem

I need to refactor i915_gem_backup_suspend() as well which should be 
called much later on.


Regards,

Nirmoy

>
> Shouldn't we have a way to differentiate between the totally wedged
> and blocked for user submission?
>
>>> Testcase: igt/gem_eio/in-flight-suspend
>> References: https://gitlab.freedesktop.org/drm/intel/-/issues/7896
>>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com>
>>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/gt/intel_gt_pm.c | 10 ++++------
>>>    1 file changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> index cef3d6f5c34e..74d1dd3793f9 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> @@ -317,19 +317,17 @@ int intel_gt_resume(struct intel_gt *gt)
>>>    static void wait_for_suspend(struct intel_gt *gt)
>>>    {
>>> -	if (!intel_gt_pm_is_awake(gt))
>>> -		return;
>>> -
>>> -	if (intel_gt_wait_for_idle(gt, I915_GT_SUSPEND_IDLE_TIMEOUT) == -ETIME) {
>>> +	if (intel_gt_wait_for_idle(gt, I915_GT_SUSPEND_IDLE_TIMEOUT) == -ETIME)
>>>    		/*
>>>    		 * Forcibly cancel outstanding work and leave
>>>    		 * the gpu quiet.
>>>    		 */
>>>    		intel_gt_set_wedged(gt);
>>> -		intel_gt_retire_requests(gt);
>>> -	}
>>>    	intel_gt_pm_wait_for_idle(gt);
>>> +
>>> +	/* Make the GPU available again for swapout */
>>> +	intel_gt_unset_wedged(gt);
>>>    }
>>>    void intel_gt_suspend_prepare(struct intel_gt *gt)

  reply	other threads:[~2023-01-25 13:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 11:05 [Intel-gfx] [PATCH] drm/i915/gt: Clear wedged status upon suspend Nirmoy Das
2023-01-24 11:07 ` Das, Nirmoy
2023-01-24 19:26   ` Rodrigo Vivi
2023-01-25 13:28     ` Das, Nirmoy [this message]
2023-01-24 19:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-01-24 22:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=592aad9f-fb3b-4369-4683-aef49628786a@linux.intel.com \
    --to=nirmoy.das@linux.intel.com \
    --cc=chris.p.wilson@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=nirmoy.das@intel.com \
    --cc=rodrigo.vivi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox