On Tue, Jan 08, 2013 at 10:53:18AM +0000, Chris Wilson wrote: > As we only maintain the list underneath the struct_mutex, we can hold a > 'borrowed' reference to the objects safe in the knowledge that they will > not disappear. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Ok, after our irc discussion I've checked things at this patch looks correct. I still think it's too fancy, and generally I'd like to reduce our reliance on dev->struct_mutex serialization effects, not increase it: Sooner or later we'll have to deal with some form of per-object locking ... Hence I'll punt on this one here. -Daniel > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 18a6ab7..f6bd92c 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -111,7 +111,6 @@ eb_lookup_objects(struct eb_objects *eb, > return -EINVAL; > } > > - drm_gem_object_reference(&obj->base); > list_add_tail(&obj->exec_list, &eb->objects); > > obj->exec_entry = &exec[i]; > @@ -162,7 +161,6 @@ eb_destroy(struct eb_objects *eb) > struct drm_i915_gem_object, > exec_list); > list_del_init(&obj->exec_list); > - drm_gem_object_unreference(&obj->base); > } > kfree(eb); > } > @@ -603,7 +601,6 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev, > struct drm_i915_gem_object, > exec_list); > list_del_init(&obj->exec_list); > - drm_gem_object_unreference(&obj->base); > } > > mutex_unlock(&dev->struct_mutex); > -- > 1.7.10.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
