diff mbox series

[3/7] drm/i915: Signal fence completion from i915_request_wait

Message ID 20190619112341.9082-3-chris@chris-wilson.co.uk (mailing list archive)
State New, archived
Headers show
Series [1/7] drm/i915/gtt: Defer address space cleanup to an RCU worker | expand

Commit Message

Chris Wilson June 19, 2019, 11:23 a.m. UTC
With the upcoming change to automanaged i915_active, the intent is that
whenever we wait on the set of active fences, they are signaled and
collected.  The requirement is that all successful returns from
i915_request_wait() signal the fence, so fixup the one remaining path
where we may return before the interrupt has been run.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_request.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Tvrtko Ursulin June 19, 2019, 2:27 p.m. UTC | #1
On 19/06/2019 12:23, Chris Wilson wrote:
> With the upcoming change to automanaged i915_active, the intent is that
> whenever we wait on the set of active fences, they are signaled and
> collected.  The requirement is that all successful returns from
> i915_request_wait() signal the fence, so fixup the one remaining path
> where we may return before the interrupt has been run.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_request.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 0c2b53b8a3d1..8d59c35bd22f 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1451,8 +1451,10 @@ long i915_request_wait(struct i915_request *rq,
>   	for (;;) {
>   		set_current_state(state);
>   
> -		if (i915_request_completed(rq))
> +		if (i915_request_completed(rq)) {
> +			dma_fence_signal(&rq->fence);
>   			break;
> +		}
>   
>   		if (signal_pending_state(state, current)) {
>   			timeout = -ERESTARTSYS;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Patch is fine, but I have to say commit message scares me a bit. Where 
are we adding such subtle fragility that wait has to exit with fence 
signaled? Is it just some specific i915_request_wait call site or all of 
them?

Regards,

Tvrtko
Chris Wilson June 19, 2019, 2:35 p.m. UTC | #2
Quoting Tvrtko Ursulin (2019-06-19 15:27:21)
> 
> On 19/06/2019 12:23, Chris Wilson wrote:
> > With the upcoming change to automanaged i915_active, the intent is that
> > whenever we wait on the set of active fences, they are signaled and
> > collected.  The requirement is that all successful returns from
> > i915_request_wait() signal the fence, so fixup the one remaining path
> > where we may return before the interrupt has been run.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_request.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index 0c2b53b8a3d1..8d59c35bd22f 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1451,8 +1451,10 @@ long i915_request_wait(struct i915_request *rq,
> >       for (;;) {
> >               set_current_state(state);
> >   
> > -             if (i915_request_completed(rq))
> > +             if (i915_request_completed(rq)) {
> > +                     dma_fence_signal(&rq->fence);
> >                       break;
> > +             }
> >   
> >               if (signal_pending_state(state, current)) {
> >                       timeout = -ERESTARTSYS;
> > 
> 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Patch is fine, but I have to say commit message scares me a bit. Where 
> are we adding such subtle fragility that wait has to exit with fence 
> signaled? Is it just some specific i915_request_wait call site or all of 
> them?

dma_fence_wait_default already implies that the fence is signaled prior
to its return, so in terms of the bigger picture I can argue this bring
us into line.

In the scenarios I've been fixing it's basically making sure that
i915_gem_wait_for_idle() does guarantee that we idle, which involves
some assurance that the request are retired, and uses
i915_request_wait() directly for the most part.
-Chris
diff mbox series

Patch

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 0c2b53b8a3d1..8d59c35bd22f 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1451,8 +1451,10 @@  long i915_request_wait(struct i915_request *rq,
 	for (;;) {
 		set_current_state(state);
 
-		if (i915_request_completed(rq))
+		if (i915_request_completed(rq)) {
+			dma_fence_signal(&rq->fence);
 			break;
+		}
 
 		if (signal_pending_state(state, current)) {
 			timeout = -ERESTARTSYS;