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