All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org,
	Vivek Kasireddy <vivek.kasireddy@intel.com>
Subject: Re: [PATCH 2/4] drm/i915: Lookup CRTC for plane directly
Date: Thu, 9 Apr 2015 07:36:47 -0700	[thread overview]
Message-ID: <20150409143647.GM11603@intel.com> (raw)
In-Reply-To: <20150409124405.GJ12038@phenom.ffwll.local>

On Thu, Apr 09, 2015 at 02:44:05PM +0200, Daniel Vetter wrote:
> On Wed, Apr 08, 2015 at 06:56:52PM -0700, Matt Roper wrote:
> > Various places in the atomic plane code obtain the CRTC via
> > plane_state->crtc.  But plane_state->crtc is NULL when disabling the
> > plane, so the code will fall back to looking at the old CRTC value in
> > plane->crtc in that case.  This isn't going to work when we start
> > supporting non-blocking flips (since the legacy plane->crtc pointer will
> > already be updated to its new value before the asynchronous workqueue
> > task runs the plane commit function).  The code is also fragile in
> > general (we have to be careful when doing stuff like updating properties
> > on a disabled plane).  Since Intel hardware has a fixed plane to pipe
> > mapping, let's just lookup the CRTC via that fixed mapping and avoid
> > future mistakes.
> > 
> > Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
> > Reported-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> 
> Because I'm a lazy reviewer ... does cocci agree that you've spotted all
> the drm_plane->crtc references?
> -Daniel

According to

        @@ struct drm_plane *P; @@
        * P->crtc

We have four remaining uses of drm_plane->crtc in the driver.  Two of
them are just updating it to properly mirror the value of
plane->state->crtc (e.g., in the load detect code), so those are good.
The other two uses are in intel_plane_restore(), which is intentionally
looking at what's already been committed and isn't in danger of being
used in the non-blocking/async code flow.  So I think we're okay now.


Matt

> 
> > ---
> >  drivers/gpu/drm/i915/intel_atomic_plane.c | 12 ++++++------
> >  drivers/gpu/drm/i915/intel_display.c      |  8 ++++----
> >  drivers/gpu/drm/i915/intel_drv.h          |  7 +++++++
> >  drivers/gpu/drm/i915/intel_sprite.c       |  4 ++--
> >  4 files changed, 19 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > index 90c4a82..740d1a6 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > @@ -116,19 +116,19 @@ static int intel_plane_atomic_check(struct drm_plane *plane,
> >  	struct intel_plane_state *intel_state = to_intel_plane_state(state);
> >  	bool active;
> >  
> > -	crtc = crtc ? crtc : plane->crtc;
> > +	crtc = intel_get_crtc_for_drm_plane(plane);
> >  	intel_crtc = to_intel_crtc(crtc);
> >  
> >  	intel_crtc_state = intel_crtc_state_for_plane(intel_state);
> >  	active = intel_crtc_state->base.enable;
> >  
> >  	/*
> > -	 * Both crtc and plane->crtc could be NULL if we're updating a
> > -	 * property while the plane is disabled.  We don't actually have
> > -	 * anything driver-specific we need to test in that case, so
> > -	 * just return success.
> > +	 * Both state->crtc and plane->state->crtc could be NULL if we're
> > +	 * updating a property while the plane is disabled.  We don't actually
> > +	 * have anything driver-specific we need to test in that case, so just
> > +	 * return success.
> >  	 */
> > -	if (!crtc)
> > +	if (!state->crtc && !plane->state->crtc)
> >  		return 0;
> >  
> >  	/*
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 88b0f69..1cf91ad 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12625,7 +12625,7 @@ intel_check_primary_plane(struct drm_plane *plane,
> >  	bool active;
> >  	int ret;
> >  
> > -	crtc = crtc ? crtc : plane->crtc;
> > +	crtc = intel_get_crtc_for_drm_plane(plane);
> >  	intel_crtc = to_intel_crtc(crtc);
> >  
> >  	intel_crtc_state = intel_crtc_state_for_plane(state);
> > @@ -12694,7 +12694,7 @@ intel_commit_primary_plane(struct drm_plane *plane,
> >  	struct drm_rect *src = &state->src;
> >  	bool active;
> >  
> > -	crtc = crtc ? crtc : plane->crtc;
> > +	crtc = intel_get_crtc_for_drm_plane(plane);
> >  	intel_crtc = to_intel_crtc(crtc);
> >  
> >  	intel_crtc_state = intel_crtc_state_for_plane(state);
> > @@ -12916,7 +12916,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
> >  	bool active;
> >  	int ret;
> >  
> > -	crtc = crtc ? crtc : plane->crtc;
> > +	crtc = intel_get_crtc_for_drm_plane(plane);
> >  	intel_crtc = to_intel_crtc(crtc);
> >  
> >  	intel_crtc_state = intel_crtc_state_for_plane(state);
> > @@ -12977,7 +12977,7 @@ intel_commit_cursor_plane(struct drm_plane *plane,
> >  	uint32_t addr;
> >  	bool active;
> >  
> > -	crtc = crtc ? crtc : plane->crtc;
> > +	crtc = intel_get_crtc_for_drm_plane(plane);
> >  	intel_crtc = to_intel_crtc(crtc);
> >  
> >  	intel_crtc_state = intel_crtc_state_for_plane(state);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 71e0152..d5ea24f 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -731,6 +731,13 @@ intel_get_crtc_for_plane(struct drm_device *dev, int plane)
> >  	return dev_priv->plane_to_crtc_mapping[plane];
> >  }
> >  
> > +static inline struct drm_crtc *
> > +intel_get_crtc_for_drm_plane(struct drm_plane *plane)
> > +{
> > +	struct drm_i915_private *dev_priv = to_i915(plane->dev);
> > +	return dev_priv->pipe_to_crtc_mapping[to_intel_plane(plane)->pipe];
> > +}
> > +
> >  struct intel_unpin_work {
> >  	struct work_struct work;
> >  	struct drm_crtc *crtc;
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > index 2016e78..492abcd 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -878,7 +878,7 @@ intel_check_sprite_plane(struct drm_plane *plane,
> >  	int pixel_size;
> >  	bool active;
> >  
> > -	intel_crtc = intel_crtc ? intel_crtc : to_intel_crtc(plane->crtc);
> > +	intel_crtc = to_intel_crtc(intel_get_crtc_for_drm_plane(plane));
> >  
> >  	intel_crtc_state = intel_crtc_state_for_plane(state);
> >  	active = intel_crtc_state->base.enable;
> > @@ -1075,7 +1075,7 @@ intel_commit_sprite_plane(struct drm_plane *plane,
> >  	uint32_t src_x, src_y, src_w, src_h;
> >  	bool active;
> >  
> > -	crtc = crtc ? crtc : plane->crtc;
> > +	crtc = intel_get_crtc_for_drm_plane(plane);
> >  	intel_crtc = to_intel_crtc(crtc);
> >  
> >  	intel_crtc_state = intel_crtc_state_for_plane(state);
> > -- 
> > 1.8.5.1
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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

  reply	other threads:[~2015-04-09 14:36 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-09  1:56 [PATCH 0/4] Misc atomic-related updates Matt Roper
2015-04-09  1:56 ` [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value Matt Roper
2015-04-09 12:42   ` Daniel Vetter
2015-04-09 14:00     ` Matt Roper
2015-04-09 14:45       ` Daniel Vetter
2015-04-09 14:49         ` Matt Roper
2015-04-09 13:18   ` Ville Syrjälä
2015-04-09 14:10     ` Matt Roper
2015-04-09 14:46       ` Ville Syrjälä
2015-04-09 14:54         ` Matt Roper
2015-04-10  7:24           ` Daniel Vetter
2015-04-09  1:56 ` [PATCH 2/4] drm/i915: Lookup CRTC for plane directly Matt Roper
2015-04-09 12:44   ` Daniel Vetter
2015-04-09 14:36     ` Matt Roper [this message]
2015-04-09  1:56 ` [PATCH 3/4] drm/i915: Switch to full atomic helpers for plane updates/disable, take two Matt Roper
2015-04-09 12:46   ` Daniel Vetter
2015-04-09 18:03     ` Matt Roper
2015-04-15  0:48       ` Konduru, Chandra
2015-04-09  1:56 ` [PATCH 4/4] drm/i915: Clear crtc atomic flags at beginning of transaction Matt Roper
2015-04-09 12:48   ` Daniel Vetter
2015-04-09 15:03     ` Matt Roper
2015-04-09 15:51       ` Daniel Vetter
2015-04-09 17:48         ` [PATCH] " Matt Roper
2015-04-10  7:37           ` Daniel Vetter
2015-04-10 20:05           ` shuang.he
2015-04-10  2:36   ` [PATCH 4/4] " shuang.he

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=20150409143647.GM11603@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=vivek.kasireddy@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.