Quoting Ruhl, Michael J (2020-05-08 14:54:50) > >-----Original Message----- > >From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >Sent: Thursday, May 7, 2020 9:57 AM > >To: Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx>; intel- > >gfx@xxxxxxxxxxxxxxxxxxxxx > >Subject: Re: [PATCH 12/15] drm/i915: Replace the hardcoded > >I915_FENCE_TIMEOUT > > > >Quoting Ruhl, Michael J (2020-05-07 14:53:00) > >> > >> > >> >-----Original Message----- > >> >From: Intel-gfx <intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of > >Chris > >> >Wilson > >> >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >> >b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >> >index 3a146aa2593b..d3a86a4d5c04 100644 > >> >--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >> >+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c > >> >@@ -288,8 +288,7 @@ int i915_gem_schedule_fill_pages_blt(struct > >> >drm_i915_gem_object *obj, > >> > > >> > i915_gem_object_lock(obj); > >> > err = i915_sw_fence_await_reservation(&work->wait, > >> >- obj->base.resv, NULL, > >> >- true, I915_FENCE_TIMEOUT, > >> >+ obj->base.resv, NULL, true, 0, > >> > >> Did you miss this one, or is the '0' on purpose? > > > >It should be 0, as it should be only handling internal fences which may > >take as long as required and should not be timed out. > > > >Still this is a placeholder function and should not be taken too > >seriously. > > Assuming that the "placeholder function" is the _fill_pages_blt()... It is. I'm not fond of await_reservation either. That extra 'exclude' parameter belies a weakness of the one-size fits all approach. Just look at the trouble we go to with i915_request_await_dma_fence() to determine the "best" means of waiting on the fence, and then worry about how to fit that into a more generic api. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
