All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ander Conselvan De Oliveira <conselvan2@gmail.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915: Don't check modeset state in the hw state force restore path
Date: Tue, 16 Jun 2015 11:54:01 +0300	[thread overview]
Message-ID: <1434444841.9250.2.camel@gmail.com> (raw)
In-Reply-To: <20150616020046.GK13852@intel.com>

On Mon, 2015-06-15 at 19:00 -0700, Matt Roper wrote:
> On Fri, Jun 12, 2015 at 10:19:40AM +0300, Ander Conselvan de Oliveira wrote:
> > Since the force restore logic will restore the CRTCs state one at a
> > time, it is possible that the state will be inconsistent until the whole
> > operation finishes. A call to intel_modeset_check_state() is done once
> > it's over, so don't check the state multiple times in between. This
> > regression was introduced in:
> > 
> > commit 7f27126ea3db6ade886f18fd39caf0ff0cd1d37f
> > Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> > Date:   Wed Nov 5 14:26:06 2014 -0800
> > 
> >     drm/i915: factor out compute_config from __intel_set_mode v3
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431
> > Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> > Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 21 ++++++++++++---------
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 4e3f302..6ef57e6 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -87,7 +87,8 @@ static void ironlake_pch_clock_get(struct intel_crtc *crtc,
> >  				   struct intel_crtc_state *pipe_config);
> >  
> >  static int intel_set_mode(struct drm_crtc *crtc,
> > -			  struct drm_atomic_state *state);
> > +			  struct drm_atomic_state *state,
> > +			  bool check);
> >  static int intel_framebuffer_init(struct drm_device *dev,
> >  				  struct intel_framebuffer *ifb,
> >  				  struct drm_mode_fb_cmd2 *mode_cmd,
> > @@ -10096,7 +10097,7 @@ retry:
> >  
> >  	drm_mode_copy(&crtc_state->base.mode, mode);
> >  
> > -	if (intel_set_mode(crtc, state)) {
> > +	if (intel_set_mode(crtc, state, true)) {
> >  		DRM_DEBUG_KMS("failed to set mode on load-detect pipe\n");
> >  		if (old->release_fb)
> >  			old->release_fb->funcs->destroy(old->release_fb);
> > @@ -10170,7 +10171,7 @@ void intel_release_load_detect_pipe(struct drm_connector *connector,
> >  		if (ret)
> >  			goto fail;
> >  
> > -		ret = intel_set_mode(crtc, state);
> > +		ret = intel_set_mode(crtc, state, true);
> >  		if (ret)
> >  			goto fail;
> >  
> > @@ -12646,20 +12647,22 @@ static int __intel_set_mode(struct drm_crtc *modeset_crtc,
> >  }
> >  
> >  static int intel_set_mode_with_config(struct drm_crtc *crtc,
> > -				      struct intel_crtc_state *pipe_config)
> > +				      struct intel_crtc_state *pipe_config,
> > +				      bool check)
> 
> This parameter just controls whether you check the state or not in this
> patch, but in patch #2 it also starts having more of a behavioral impact
> (i.e., "don't updated staged output configuration").  I wonder if
> picking a different name for this parameter would help avoid any
> confusion?

Thanks for reviewing! I just sent a v2 with the parameter name changed
to force_restore and the memory leak fixed.

> Otherwise, this patch looks good:
>    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
> 
> Off-topic, but speaking of 'check' I wonder whether we should also
> rename the intel_modeset_check_state function and related functions at
> some point in the future.  Every time I see that name in the code it
> bothers me because I expect it to be related to atomic check (i.e.,
> something that runs before we touch hardware) rather than confirming
> that hardware programming was successful.  It feels more like an
> assert/confirm/verify function to me.

I'm not sure what would be a better name, but I agree the current one is
confusing.

Ander

> 
> Matt
> 
> >  {
> >  	int ret;
> >  
> >  	ret = __intel_set_mode(crtc, pipe_config);
> >  
> > -	if (ret == 0)
> > +	if (ret == 0 && check)
> >  		intel_modeset_check_state(crtc->dev);
> >  
> >  	return ret;
> >  }
> >  
> >  static int intel_set_mode(struct drm_crtc *crtc,
> > -			  struct drm_atomic_state *state)
> > +			  struct drm_atomic_state *state,
> > +			  bool check)
> >  {
> >  	struct intel_crtc_state *pipe_config;
> >  	int ret = 0;
> > @@ -12670,7 +12673,7 @@ static int intel_set_mode(struct drm_crtc *crtc,
> >  		goto out;
> >  	}
> >  
> > -	ret = intel_set_mode_with_config(crtc, pipe_config);
> > +	ret = intel_set_mode_with_config(crtc, pipe_config, check);
> >  	if (ret)
> >  		goto out;
> >  
> > @@ -12747,7 +12750,7 @@ void intel_crtc_restore_mode(struct drm_crtc *crtc)
> >  	intel_modeset_setup_plane_state(state, crtc, &crtc->mode,
> >  					crtc->primary->fb, crtc->x, crtc->y);
> >  
> > -	ret = intel_set_mode(crtc, state);
> > +	ret = intel_set_mode(crtc, state, false);
> >  	if (ret)
> >  		drm_atomic_state_free(state);
> >  }
> > @@ -12947,7 +12950,7 @@ static int intel_crtc_set_config(struct drm_mode_set *set)
> >  
> >  	primary_plane_was_visible = primary_plane_visible(set->crtc);
> >  
> > -	ret = intel_set_mode_with_config(set->crtc, pipe_config);
> > +	ret = intel_set_mode_with_config(set->crtc, pipe_config, true);
> >  
> >  	if (ret == 0 &&
> >  	    pipe_config->base.enable &&
> > -- 
> > 2.1.0
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-06-16  8:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12  7:19 [PATCH 0/3] Couple of bug fixes for drm-intel-next-fixes Ander Conselvan de Oliveira
2015-06-12  7:19 ` [PATCH 1/3] drm/i915: Don't check modeset state in the hw state force restore path Ander Conselvan de Oliveira
2015-06-16  2:00   ` Matt Roper
2015-06-16  8:54     ` Ander Conselvan De Oliveira [this message]
2015-06-12  7:19 ` [PATCH 2/3] drm/i915: Don't update staged config during force restore modesets Ander Conselvan de Oliveira
2015-06-16  2:00   ` Matt Roper
2015-06-12  7:19 ` [PATCH 3/3] drm/i915: Don't set enabled value of all CRTCs when restoring the mode Ander Conselvan de Oliveira
2015-06-16  2:00   ` Matt Roper

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=1434444841.9250.2.camel@gmail.com \
    --to=conselvan2@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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.