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

[Alexander Goins]

>> +	/* 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.

Thanks,
Alex