All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Serialise i915_active_wait() with its retirement
Date: Fri, 29 Nov 2019 11:15:46 +0000	[thread overview]
Message-ID: <375aef03-4aa6-cbbd-3bcd-0eb7a44cc2f4@linux.intel.com> (raw)
In-Reply-To: <20191129093908.631527-1-chris@chris-wilson.co.uk>


On 29/11/2019 09:39, Chris Wilson wrote:
> As the i915_active.retire() may be running on another CPU as we detect
> that the i915_active is idle, we may not wait for the retirement itself.
> Wait for the remote callback by waiting for the retirement worker.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112424
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/i915_active.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
> index 479195ecbc6c..e8630ee33336 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -469,6 +469,7 @@ int i915_active_wait(struct i915_active *ref)
>   	if (wait_var_event_interruptible(ref, i915_active_is_idle(ref)))
>   		return -EINTR;
>   
> +	flush_work(&ref->work);
>   	return 0;
>   }
>   
> 

Hm, but wake_up_war is in the worker so how does wait_var_event wake the 
waiter up before it has been retired?

Regards,

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

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Serialise i915_active_wait() with its retirement
Date: Fri, 29 Nov 2019 11:15:46 +0000	[thread overview]
Message-ID: <375aef03-4aa6-cbbd-3bcd-0eb7a44cc2f4@linux.intel.com> (raw)
Message-ID: <20191129111546.QF855mN1K8zbsMT0adCJcz_4YIsaFiFnPfJpmAQIhyY@z> (raw)
In-Reply-To: <20191129093908.631527-1-chris@chris-wilson.co.uk>


On 29/11/2019 09:39, Chris Wilson wrote:
> As the i915_active.retire() may be running on another CPU as we detect
> that the i915_active is idle, we may not wait for the retirement itself.
> Wait for the remote callback by waiting for the retirement worker.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112424
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/i915_active.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
> index 479195ecbc6c..e8630ee33336 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -469,6 +469,7 @@ int i915_active_wait(struct i915_active *ref)
>   	if (wait_var_event_interruptible(ref, i915_active_is_idle(ref)))
>   		return -EINTR;
>   
> +	flush_work(&ref->work);
>   	return 0;
>   }
>   
> 

Hm, but wake_up_war is in the worker so how does wait_var_event wake the 
waiter up before it has been retired?

Regards,

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

  parent reply	other threads:[~2019-11-29 11:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29  9:39 [PATCH] drm/i915: Serialise i915_active_wait() with its retirement Chris Wilson
2019-11-29  9:39 ` [Intel-gfx] " Chris Wilson
2019-11-29 10:42 ` ✗ Fi.CI.BAT: failure for " Patchwork
2019-11-29 10:42   ` [Intel-gfx] " Patchwork
2019-11-29 11:15 ` Tvrtko Ursulin [this message]
2019-11-29 11:15   ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2019-11-29 11:28   ` Chris Wilson
2019-11-29 11:28     ` [Intel-gfx] " Chris Wilson
2019-11-29 11:38     ` Tvrtko Ursulin
2019-11-29 11:38       ` [Intel-gfx] " Tvrtko Ursulin

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=375aef03-4aa6-cbbd-3bcd-0eb7a44cc2f4@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.