On Fri, Oct 30, 2015 at 06:03:50PM -0700, Alex Goins wrote:
If a buffer is backed by dmabuf, wait on its reservation object's fences before flipping.
Signed-off-by: Alex Goins agoins@nvidia.com
drivers/gpu/drm/i915/intel_display.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b2270d5..1485640 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -44,6 +44,8 @@ #include <drm/drm_plane_helper.h> #include <drm/drm_rect.h> #include <linux/dma_remapping.h> +#include <linux/reservation.h> +#include <linux/dma-buf.h>
/* Primary plane formats for gen <= 3 */ static const uint32_t i8xx_primary_formats[] = { @@ -11170,10 +11172,21 @@ static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc) static void intel_do_mmio_flip(struct intel_crtc *intel_crtc) { struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_gem_object *pending_flip_obj =
intel_crtc->unpin_work->pending_flip_obj;u32 start_vbl_count;
intel_mark_page_flip_active(intel_crtc);
/* 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).
- if (pending_flip_obj->base.dma_buf) {
reservation_object_wait_timeout_rcu(
Side-question, are these fences exclusive or do we track read/write? -Chris