>> +/* 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 aga
>Could you put the wait inside prepare_plane_fb?
Yeah, that works, and it gets rid of the need to loop over the planes. I wait
on the fence before taking out the struct_mutex lock like so:
@@ -13369,6 +13345,13 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (!obj)
5_gem_object *obj = intel_fb->obj;
Given that, would it be okay for me to do the same?
Thanks,
Alex
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, November 13, 2015 2:46 AM
To: Daniel Stone
Cc: Alexander Goins; dri-devel; Daniel Vetter; Maarten L
Okay, implemented these suggestions. Will send out v4 patch set once the
crtc->primary->fb thing is cleared up.
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, November 13, 2015 2:08 AM
To: Alexander Goins
Cc: dri-devel at lists.freedeskt
, November 16, 2015 7:16 AM
To: Alexander Goins
Cc: Chris Wilson; dri-devel at lists.freedesktop.org
Subject: Re: [PATCH i915 v2 1/2] i915: wait for fences in mmio_flip()
On Mon, Nov 09, 2015 at 09:42:05PM +, Alexander Goins wrote:
> >> + /* For framebuffer backed by dmabuf, wait
Now that the wait happens before marking page flip active, I guess there's no
reason not to.
Thanks,
Alex
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, November 20, 2015 3:31 AM
To: Alexander Goins
Cc: dri-devel at lists.freedeskto
Alright, will do.
Thanks,
Alex
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, November 20, 2015 12:21 AM
To: Alexander Goins
Cc: dri-devel at lists.freedesktop.org; daniel at fooishbar.org; daniel at
ffwll.ch
Thanks for the quick feedback, Daniel!
>This looks really strange - you force-complete the fence already attached
>(which might be from any driver attached to this dma-buf)?
>The creator of the fence is supposed to complete it when whatever async
>operation that is scheduled and which is using t
