>> + /* 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
