All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ander Conselvan De Oliveira <conselvan2@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 11/11] drm/i915: Don't modeset with old mode when set_crtc fails
Date: Fri, 10 Apr 2015 13:24:53 +0300	[thread overview]
Message-ID: <1428661493.3588.28.camel@gmail.com> (raw)
In-Reply-To: <20150410101214.GJ6092@phenom.ffwll.local>

On Fri, 2015-04-10 at 12:12 +0200, Daniel Vetter wrote:
> On Fri, Apr 10, 2015 at 11:38:40AM +0300, Ander Conselvan de Oliveira wrote:
> > The modeset code is now properly divided in two phases, so that it only
> > changes hardware state if it succeeds, so there's no ill-effect that
> > needs to be undone on failure anymore.
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 48 ------------------------------------
> >  1 file changed, 48 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 06f3b83..84efd7a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12136,33 +12136,9 @@ intel_modeset_stage_output_state(struct drm_device *dev,
> >  	return 0;
> >  }
> >  
> > -static void disable_crtc_nofb(struct intel_crtc *crtc)
> > -{
> > -	struct drm_device *dev = crtc->base.dev;
> > -	struct intel_encoder *encoder;
> > -	struct intel_connector *connector;
> > -
> > -	DRM_DEBUG_KMS("Trying to restore without FB -> disabling pipe %c\n",
> > -		      pipe_name(crtc->pipe));
> > -
> > -	for_each_intel_connector(dev, connector) {
> > -		if (connector->new_encoder &&
> > -		    connector->new_encoder->new_crtc == crtc)
> > -			connector->new_encoder = NULL;
> > -	}
> > -
> > -	for_each_intel_encoder(dev, encoder) {
> > -		if (encoder->new_crtc == crtc)
> > -			encoder->new_crtc = NULL;
> > -	}
> > -
> > -	crtc->new_enabled = false;
> > -}
> > -
> >  static int intel_crtc_set_config(struct drm_mode_set *set)
> >  {
> >  	struct drm_device *dev;
> > -	struct drm_mode_set save_set;
> >  	struct drm_atomic_state *state = NULL;
> >  	struct intel_set_config *config;
> >  	struct intel_crtc_state *pipe_config;
> > @@ -12195,12 +12171,6 @@ static int intel_crtc_set_config(struct drm_mode_set *set)
> >  	if (ret)
> >  		goto out_config;
> >  
> > -	save_set.crtc = set->crtc;
> > -	save_set.mode = &set->crtc->mode;
> > -	save_set.x = set->crtc->x;
> > -	save_set.y = set->crtc->y;
> > -	save_set.fb = set->crtc->primary->fb;
> > -
> >  	state = drm_atomic_state_alloc(dev);
> >  	if (!state) {
> >  		ret = -ENOMEM;
> > @@ -12280,24 +12250,6 @@ static int intel_crtc_set_config(struct drm_mode_set *set)
> >  			      set->crtc->base.id, ret);
> >  fail:
> >  		intel_set_config_restore_state(dev, config);
> > -
> > -		drm_atomic_state_clear(state);
> > -
> > -		/*
> > -		 * HACK: if the pipe was on, but we didn't have a framebuffer,
> > -		 * force the pipe off to avoid oopsing in the modeset code
> > -		 * due to fb==NULL. This should only happen during boot since
> > -		 * we don't yet reconstruct the FB from the hardware state.
> > -		 */
> > -		if (to_intel_crtc(save_set.crtc)->new_enabled && !save_set.fb)
> > -			disable_crtc_nofb(to_intel_crtc(save_set.crtc));
> > -
> > -		/* Try to restore the config */
> > -		if (config->mode_changed &&
> > -		    intel_set_mode(save_set.crtc, save_set.mode,
> > -				   save_set.x, save_set.y, save_set.fb,
> > -				   state))
> > -			DRM_ERROR("failed to restore config after modeset failure\n");
> 
> Hm removing this reminds me that we still have troubles with always
> assuming that there is a primary fb around. Getting rid of all the fb
> pointers in our modeset code looks like a sizeable task too.

I only see the fb argument being used in two places now: the part where
we update the primary plane in __intel_set_mode() and in
compute_baseline_pipe_bpp() called from intel_modeset_pipe_config(). I
think those are easy to solve by adding the plane state. Or are we
talking about something else here?

Ander

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

  reply	other threads:[~2015-04-10 10:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10  8:38 [PATCH 00/11] Small modeset refactoring Ander Conselvan de Oliveira
2015-04-10  8:38 ` [PATCH 01/11] drm/i915: Allocate connector state together with the connectors Ander Conselvan de Oliveira
2015-04-10  8:38 ` [PATCH 02/11] drm/i915: Remove stale comment from __intel_set_mode() Ander Conselvan de Oliveira
2015-04-10  9:37   ` Daniel Vetter
2015-04-10  9:39   ` Daniel Vetter
2015-04-10  8:38 ` [PATCH 03/11] drm/i915: Reset changed flags when duplicating crtc state Ander Conselvan de Oliveira
2015-04-10  9:39   ` Daniel Vetter
2015-04-13 11:07   ` Jani Nikula
2015-04-10  8:38 ` [PATCH 04/11] drm/i915: Add for_each_connector_in_state helper macro Ander Conselvan de Oliveira
2015-04-10  9:42   ` Daniel Vetter
2015-04-10 10:50     ` Ander Conselvan De Oliveira
2015-04-10  8:38 ` [PATCH 05/11] drm/i915: Extract mode_changed computation out of stage_output_config() Ander Conselvan de Oliveira
2015-04-10 10:07   ` Daniel Vetter
2015-04-10  8:38 ` [PATCH 06/11] drm/i915: Add crtc states before calling compute_config() Ander Conselvan de Oliveira
2015-04-10  8:38 ` [PATCH 07/11] drm/i915: Remove all *_pipes flags from modeset Ander Conselvan de Oliveira
2015-04-10  9:54   ` Daniel Vetter
2015-04-10  8:38 ` [PATCH 08/11] drm/i915: Remove saved_mode from __intel_set_mode() Ander Conselvan de Oliveira
2015-04-10  8:38 ` [PATCH 09/11] drm/i915: Move compute part of __intel_set_mode() to separate function Ander Conselvan de Oliveira
2015-04-10  8:38 ` [PATCH 10/11] drm/i915: Simplify error handling in __intel_set_mode() Ander Conselvan de Oliveira
2015-04-10  8:38 ` [PATCH 11/11] drm/i915: Don't modeset with old mode when set_crtc fails Ander Conselvan de Oliveira
2015-04-10 10:12   ` Daniel Vetter
2015-04-10 10:24     ` Ander Conselvan De Oliveira [this message]
2015-04-10 13:27   ` 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=1428661493.3588.28.camel@gmail.com \
    --to=conselvan2@gmail.com \
    --cc=daniel@ffwll.ch \
    --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.