[Intel-gfx] [PATCH 5/5] drm/i915: Wait for object idle without locks in atomic_commit.

[Maarten Lankhorst]

Op 02-11-15 om 14:46 schreef Chris Wilson:
> On Mon, Nov 02, 2015 at 02:13:48PM +0100, Maarten Lankhorst wrote:
>> Op 29-10-15 om 01:30 schreef Matt Roper:
>>> On Wed, Sep 23, 2015 at 01:27:12PM +0200, Maarten Lankhorst wrote:
>>>> diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
>>>> index 444542696a2c..1b18cc6bdbd6 100644
>>>> --- a/drivers/gpu/drm/i915/intel_overlay.c
>>>> +++ b/drivers/gpu/drm/i915/intel_overlay.c
>>>> @@ -749,7 +749,11 @@ static int intel_overlay_do_put_image(struct intel_overlay *overlay,
>>>>  	if (ret != 0)
>>>>  		return ret;
>>>>  
>>>> -	ret = i915_gem_object_pin_to_display_plane(new_bo, 0, NULL, NULL,
>>>> +	ret = i915_gem_object_wait_rendering(new_bo, true);
>>> Again, I'm not super familiar with GEM internals...can this be a
>>> behavior change from the previous code?  Originally the pin_to_display
>>> plane function would have passed (obj->base.pending_write_domain == 0)
>>> as the second parameter here (readonly), but you're unconditionally
>>> passing true.  Can there not be pending writes against this object?
>> I don't think it would be important in the case of overlays. But maybe I should
>> just replace it with a call to i915_gem_object_sync and wait for full object idle.
> Technically it removes a call to set-cache, acquiring a GGTT offset and
> pinning it, and a final set-to-gtt. 
>
> Quite a major and broken change.
> -Chris
>
No? pin_to_display_plane is called immediately below in this patch, it's just not shown here in the comments because it was about using wait_rendering.