Re: [PATCH] drm/i915: Fix frontbuffer false positve.

[Jani Nikula <jani.nikula@intel.com>]

On Wed, 25 Feb 2015, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Feb 24, 2015 at 01:42:39PM -0800, Matt Roper wrote:
>> On Tue, Feb 24, 2015 at 01:37:54PM -0800, Rodrigo Vivi wrote:
>> > This return 0 without setting atomic bits on fb == crtc->cursor->fb
>> > where causing frontbuffer false positives.
>> > 
>> > According to Daniel:
>> > 
>> > The original regression seems to have been introduced in the original
>> > check/commit split:
>> > 
>> > commit 757f9a3e5b8a812af0c213099a5b31cb423f4d3c
>> > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>> > Date:   Wed Sep 24 14:20:24 2014 -0300
>> > 
>> >     drm/i915: move check of intel_crtc_cursor_set_obj() out
>> > 
>> > Which already cause other trouble, resulting in the check getting moved in
>> > 
>> > commit e391ea882b1a04fb3f559287ac694652a3cd9da9
>> > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>> > Date:   Wed Sep 24 14:20:25 2014 -0300
>> > 
>> >     drm/i915: Fix not checking cursor and object sizes
>> > 
>> > The frontbuffer tracking itself only was broken when we shifted it into
>> > the check/commit logic with:
>> > 
>> > commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68
>> > Author: Matt Roper <matthew.d.roper@intel.com>
>> > Date:   Wed Dec 24 07:59:06 2014 -0800
>> > 
>> >     drm/i915: Refactor work that can sleep out of commit (v7)
>> > 
>> > v2: When putting more debug prints I notice the solution was simpler
>> > than I thought. AMS design is solid, just this return was wrong.
>> > Sorry for the noise.
>> > 
>> > v3: Remove the entire chunck that would probably
>> >     be removed by gcc anyway. (by Daniel)
>> > 
>> > Cc: Jani Nikula <jani.nikula@intel.com>
>> > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>> > Cc: Matt Roper <matthew.d.roper@intel.com>
>> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> 
>> Not sure I understand Daniel's remark about gcc optimization, but the
>> change still looks good to me.
>
> Yeah gcc is not clever enought to optimize this away since we can't tell
> it that fb->modifier is invariant forever once assigned.
>> 
>> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Jani, this one is for 4.0-rc.

Pushed to drm-intel-fixes, thanks for the patch and reviews.

I had to adjust the context for backporting to v4.0-rc1, please check
that drm-intel-fixes makes sense *and* that my merge resolution back to
drm-intel-nightly makes sense. Thanks.

BR,
Jani.


>
> Thanks, Daniel
>
>> 
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c | 3 ---
>> >  1 file changed, 3 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> > index 8ccf033..900dcaa 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -12197,9 +12197,6 @@ intel_check_cursor_plane(struct drm_plane *plane,
>> >  		return -ENOMEM;
>> >  	}
>> >  
>> > -	if (fb == crtc->cursor->fb)
>> > -		return 0;
>> > -
>> >  	if (fb->modifier[0] != DRM_FORMAT_MOD_NONE) {
>> >  		DRM_DEBUG_KMS("cursor cannot be tiled\n");
>> >  		ret = -EINVAL;
>> > -- 
>> > 2.1.0
>> > 
>> 
>> -- 
>> Matt Roper
>> Graphics Software Engineer
>> IoTG Platform Enabling & Development
>> Intel Corporation
>> (916) 356-2795
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx