All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@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: Mon, 15 Jun 2015 19:00:46 -0700	[thread overview]
Message-ID: <20150616020046.GK13852@intel.com> (raw)
In-Reply-To: <1434093582-5824-2-git-send-email-ander.conselvan.de.oliveira@intel.com>

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?

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.


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

-- 
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-06-16  2:00 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 [this message]
2015-06-16  8:54     ` Ander Conselvan De Oliveira
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=20150616020046.GK13852@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=ander.conselvan.de.oliveira@intel.com \
    --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 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.