9 Nov
2015
9 Nov
'15
9:42 p.m.
- /* 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