[PATCH i915 v2 1/2] i915: wait for fences in mmio_flip()

[Daniel Vetter]

On Mon, Nov 09, 2015 at 09:42:05PM +0000, Alexander Goins wrote:
> >> +	/* For framebuffer backed by dmabuf, wait for fence */
> >> +	mutex_lock(&dev->object_name_lock);
> 
> >The lock here is unfortunate. I thought once a dmabuf as attached to an object, it persists until the object is destroyed, so afaict the lock here is unnecessary (as it only protects against a userspace race in attaching a dmabuf).
> 
> You're probably right. I'll send out a v3 patch set with the lock removed if there are no other comments.
> 
> >> +	if (pending_flip_obj->base.dma_buf) {
> >> +		reservation_object_wait_timeout_rcu(
> 
> >Side-question, are these fences exclusive or do we track read/write?
> 
> They are exclusive, with the sink X driver using vblank events to
> explicitly request the source X driver to write. If you guys want to
> track read/write I could switch over to shared fences, but for my use
> case only exclusive fences are necessary.

reservations track reads/writes and here we should only wait for the
exclusive fence (i.e. pending writes) and not also for reads. Doing that
would result in piles of unecessary stalls all over. We need a different
wait_timeout call here.

Also fences should always eventually signal (worst case with a hangcheck
fallback that force-signals everything that died in a gpu hang), so I
don't think a timeout is the correct approach.

What we need otoh is that this needs to be interruptible (at least for the
new atomic path).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch