intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm: Introduce __setplane_atomic()
Date: Thu, 28 Jun 2018 20:36:49 +0300	[thread overview]
Message-ID: <20180628173649.GP20518@intel.com> (raw)
In-Reply-To: <20180628170510.GX13978@phenom.ffwll.local>

On Thu, Jun 28, 2018 at 07:05:10PM +0200, Daniel Vetter wrote:
> On Thu, Jun 28, 2018 at 04:54:56PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > All the plane->fb/old_fb/crtc dance of __setplane_internal() is
> > pointless on atomic drivers. So let's just introduce a simpler
> > version that skips all that.
> > 
> > Ideally we could also skip the __setplane_check() as
> > drm_atomic_plane_check() already checks for everything, but the
> > legacy cursor/"async" .update_plane() tricks bypass that so
> > we still need to call __setplane_check(). Toss in a FIXME to
> > remind someone to clean this up later.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/drm_plane.c | 68 +++++++++++++++++++++++++++++++++++++--------
> >  1 file changed, 57 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 5c97a0131484..58702340808c 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -649,6 +649,8 @@ static int __setplane_internal(struct drm_plane *plane,
> >  {
> >  	int ret = 0;
> >  
> > +	WARN_ON(plane->state);
> > +
> >  	/* No fb means shut it down */
> >  	if (!fb) {
> >  		plane->old_fb = plane->fb;
> > @@ -673,11 +675,9 @@ static int __setplane_internal(struct drm_plane *plane,
> >  					 crtc_x, crtc_y, crtc_w, crtc_h,
> >  					 src_x, src_y, src_w, src_h, ctx);
> >  	if (!ret) {
> > -		if (!plane->state) {
> > -			plane->crtc = crtc;
> > -			plane->fb = fb;
> > -			drm_framebuffer_get(plane->fb);
> > -		}
> > +		plane->crtc = crtc;
> > +		plane->fb = fb;
> > +		drm_framebuffer_get(plane->fb);
> >  	} else {
> >  		plane->old_fb = NULL;
> >  	}
> > @@ -690,6 +690,41 @@ static int __setplane_internal(struct drm_plane *plane,
> >  	return ret;
> >  }
> >  
> > +static int __setplane_atomic(struct drm_plane *plane,
> > +			     struct drm_crtc *crtc,
> > +			     struct drm_framebuffer *fb,
> > +			     int32_t crtc_x, int32_t crtc_y,
> > +			     uint32_t crtc_w, uint32_t crtc_h,
> > +			     uint32_t src_x, uint32_t src_y,
> > +			     uint32_t src_w, uint32_t src_h,
> > +			     struct drm_modeset_acquire_ctx *ctx)
> > +{
> > +	int ret;
> > +
> > +	WARN_ON(!plane->state);
> > +
> > +	/* No fb means shut it down */
> > +	if (!fb)
> > +		return plane->funcs->disable_plane(plane, ctx);
> > +
> > +	/*
> > +	 * FIXME: This is redundant with drm_atomic_plane_check(),
> > +	 * but the legacy cursor/"async" .update_plane() tricks
> > +	 * don't call that so we still need this here. Should remove
> > +	 * this when all .update_plane() implementations have been
> > +	 * fixed to call drm_atomic_plane_check().
> > +	 */
> > +	ret = __setplane_check(plane, crtc, fb,
> > +			       crtc_x, crtc_y, crtc_w, crtc_h,
> > +			       src_x, src_y, src_w, src_h);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return plane->funcs->update_plane(plane, crtc, fb,
> > +					  crtc_x, crtc_y, crtc_w, crtc_h,
> > +					  src_x, src_y, src_w, src_h, ctx);
> > +}
> > +
> >  static int setplane_internal(struct drm_plane *plane,
> >  			     struct drm_crtc *crtc,
> >  			     struct drm_framebuffer *fb,
> > @@ -707,9 +742,15 @@ static int setplane_internal(struct drm_plane *plane,
> >  	ret = drm_modeset_lock_all_ctx(plane->dev, &ctx);
> >  	if (ret)
> >  		goto fail;
> > -	ret = __setplane_internal(plane, crtc, fb,
> > -				  crtc_x, crtc_y, crtc_w, crtc_h,
> > -				  src_x, src_y, src_w, src_h, &ctx);
> > +
> > +	if (plane->state)
> 
> We're not 100% consistent, but I think this here will make life harder for
> drivers transitioning to atomic. Not many left, but still some.
> 
> Please use drm_drv_uses_atomic_modeset() instead and check instead for
> DRIVER_ATOMIC in your WARN_ON in all the places you're checking for
> ->state in this patch and the next one.

We're already using obj->state as the atomic indicator here,
so this patch itself isn't changing anything.

I guess you're suggesting that we change all the ->state checks
we already have to the uses_atomic() thing instead? And the
aim is to allow drives to add obj->state before actually
implementing atomic fully? To me that feels like asking for
trouble, but who knows, maybe I'm wrong.

> 
> With that fixed, on the series:
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> > +		ret = __setplane_atomic(plane, crtc, fb,
> > +					crtc_x, crtc_y, crtc_w, crtc_h,
> > +					src_x, src_y, src_w, src_h, &ctx);
> > +	else
> > +		ret = __setplane_internal(plane, crtc, fb,
> > +					  crtc_x, crtc_y, crtc_w, crtc_h,
> > +					  src_x, src_y, src_w, src_h, &ctx);
> >  
> >  fail:
> >  	if (ret == -EDEADLK) {
> > @@ -841,9 +882,14 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
> >  		src_h = fb->height << 16;
> >  	}
> >  
> > -	ret = __setplane_internal(plane, crtc, fb,
> > -				  crtc_x, crtc_y, crtc_w, crtc_h,
> > -				  0, 0, src_w, src_h, ctx);
> > +	if (plane->state)
> > +		ret = __setplane_atomic(plane, crtc, fb,
> > +					crtc_x, crtc_y, crtc_w, crtc_h,
> > +					0, 0, src_w, src_h, ctx);
> > +	else
> > +		ret = __setplane_internal(plane, crtc, fb,
> > +					  crtc_x, crtc_y, crtc_w, crtc_h,
> > +					  0, 0, src_w, src_h, ctx);
> >  
> >  	if (fb)
> >  		drm_framebuffer_put(fb);
> > -- 
> > 2.16.4
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-06-28 17:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 13:54 [PATCH 1/3] drm: Extract __setplane_check() Ville Syrjala
2018-06-28 13:54 ` [PATCH 2/3] drm: Introduce __setplane_atomic() Ville Syrjala
2018-06-28 17:05   ` Daniel Vetter
2018-06-28 17:36     ` Ville Syrjälä [this message]
2018-06-28 18:16       ` Daniel Vetter
2018-07-05 18:59   ` [PATCH v2 " Ville Syrjala
2018-06-28 13:54 ` [PATCH 3/3] drm: Skip __drm_mode_set_config_internal() on atomic drivers Ville Syrjala
2018-07-05 19:00   ` [PATCH v2 " Ville Syrjala
2018-06-28 14:52 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm: Extract __setplane_check() Patchwork
2018-06-28 15:09 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-06-28 15:56   ` Ville Syrjälä
2018-06-28 16:53 ` [PATCH 1/3] " Rodrigo Vivi
2018-07-05 23:06 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm: Extract __setplane_check() (rev3) Patchwork
2018-07-05 23:23 ` ✓ Fi.CI.BAT: success " Patchwork
2018-07-06 14:32 ` ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180628173649.GP20518@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).