All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arun Siluvery <arun.siluvery@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH] drm/i915: Clear pending reset requests during suspend
Date: Tue, 19 Jan 2016 15:04:09 +0000	[thread overview]
Message-ID: <569E5069.4080307@linux.intel.com> (raw)
In-Reply-To: <20160119141343.GF26573@nuc-i3427.alporthouse.com>

On 19/01/2016 14:13, Chris Wilson wrote:
> On Tue, Jan 19, 2016 at 03:04:40PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 19, 2016 at 01:48:05PM +0000, Chris Wilson wrote:
>>> On Tue, Jan 19, 2016 at 01:09:28PM +0100, Daniel Vetter wrote:
>>>> On Thu, Jan 14, 2016 at 10:49:45AM +0000, Arun Siluvery wrote:
>>>>> Pending reset requests are cleared before suspending, they should be picked up
>>>>> after resume when new work is submitted.
>>>>>
>>>>> This is originally added as part of TDR patches for Gen8 from Tomas Elf which
>>>>> are under review, as suggested by Chris this is extracted as a separate patch
>>>>> as it can be useful now.
>>>>>
>>>>> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
>>>>
>>>> Pulling in the discussion we had from irc: Imo the right approach is to
>>>> simply wait for gpu reset to finish it's job. Since that could in turn
>>>> lead to a dead gpu (if we're unlucky and init_hw failed) we'd need to do
>>>> that in a loop around gem_idle. And drop dev->struct_mutex in-between.
>>>> E.g.
>>>>
>>>> while (busy) {
>>>> 	mutex_lock();
>>>> 	gpu_idle();
>>>> 	mutex_unlock();
>>>>
>>>> 	flush_work(reset_work);
>>>> }
>>>
>>> Where does the requirement for gpu_idle come from? If there is a global
>>> reset in progress, it cannot queue a request to flush the work and
>>> waiting on the old results will be skipped. So just wait for the global
>>> reset to complete, i.e. flush_work().
>>
>> Yes, but the global reset might in turn leave a wrecked gpu behind, or at
>> least a non-idle one. Hence another gpu_idle on top, to make sure. If we
>> change init_hw() of engines to be synchronous then we should have at least
>> a WARN_ON(not_idle_but_i_expected_so()); in there ...

gpu_error.work is removed in b8d24a06568368076ebd5a858a011699a97bfa42, 
we are doing reset in hangcheck work itself so I think there is no need 
to flush work.

while (i915_reset_in_progress(gpu_error) &&
        !i915_terminally_wedged(gpu_error)) {
         int ret;

         mutex_lock(&dev->struct_mutex);
         ret = i915_gpu_idle(dev);
         if (ret)
                 DRM_ERROR("GPU is in inconsistent state after reset\n");
         mutex_unlock(&dev->struct_mutex);
}

If the reset is successful we are idle before suspend otherwise in a 
wedged state. is this ok?

regards
Arun

>
> Does it matter on suspend? We test on resume if the GPU is usable, but
> if we wanted to test on suspend then we should do
>
> flush_work();
> if (i915_terminally_wedged())
>     /* oh noes */;
> -Chris
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-01-19 15:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 10:49 [PATCH] drm/i915: Clear pending reset requests during suspend Arun Siluvery
2016-01-14 11:07 ` kbuild test robot
2016-01-14 11:19 ` Chris Wilson
2016-01-14 12:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-19 12:09 ` [PATCH] drm/i915: Clear pending reset requests during suspend Daniel Vetter
2016-01-19 13:48   ` Chris Wilson
2016-01-19 14:04     ` Daniel Vetter
2016-01-19 14:13       ` Chris Wilson
2016-01-19 15:04         ` Arun Siluvery [this message]
2016-01-19 16:42           ` Daniel Vetter
2016-01-19 17:01             ` Arun Siluvery
2016-01-19 17:18               ` Daniel Vetter

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=569E5069.4080307@linux.intel.com \
    --to=arun.siluvery@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@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 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.