All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ander Conselvan De Oliveira <conselvan2@gmail.com>
To: "Konduru, Chandra" <chandra.konduru@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 05/19] drm/i915: Update dummy connector atomic state with current config
Date: Fri, 20 Mar 2015 08:41:18 +0200	[thread overview]
Message-ID: <1426833678.2316.13.camel@gmail.com> (raw)
In-Reply-To: <76A9B330A4D78C4D99CB292C4CC06C0E36F7D9DB@fmsmsx101.amr.corp.intel.com>

On Thu, 2015-03-19 at 20:55 +0000, Konduru, Chandra wrote:
> 
> > -----Original Message-----
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH 05/19] drm/i915: Update dummy connector atomic state with
> > current config
> > 
> > Keep that state updated so that we can write code that depends on it on the
> > follow up patches.
> > 
> > v2: Fix BUG() due to stale connector_state->crtc value. (Chandra)
> > Signed-off-by: Ander Conselvan de Oliveira
> > <ander.conselvan.de.oliveira@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 41 ++++++++++++++++++++++++++++----
> > ----
> >  1 file changed, 32 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 62b9021..abdbd0c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10114,6 +10114,27 @@ static void
> > intel_modeset_update_staged_output_state(struct drm_device *dev)
> >  	}
> >  }
> > 
> > +/* Transitional helper to copy current connector/encoder state to
> > + * connector->state. This is needed so that code that is partially
> > + * converted to atomic does the right thing.
> > + */
> > +static void intel_modeset_update_connector_atomic_state(struct
> > +drm_device *dev) {
> > +	struct intel_connector *connector;
> > +
> > +	for_each_intel_connector(dev, connector) {
> > +		if (connector->base.encoder) {
> > +			connector->base.state->best_encoder =
> > +				connector->base.encoder;
> > +			connector->base.state->crtc =
> > +				connector->base.encoder->crtc;
> > +		} else {
> > +			connector->base.state->best_encoder = NULL;
> > +			connector->base.state->crtc = NULL;
> > +		}
> > +	}
> > +}
> > +
> >  /**
> >   * intel_modeset_commit_output_state
> >   *
> > @@ -10137,6 +10158,8 @@ static void
> > intel_modeset_commit_output_state(struct drm_device *dev)
> >  		crtc->base.state->enable = crtc->new_enabled;
> >  		crtc->base.enabled = crtc->new_enabled;
> >  	}
> > +
> > +	intel_modeset_update_connector_atomic_state(dev);
> >  }
> > 
> >  static void
> > @@ -12876,15 +12899,13 @@ static void intel_setup_outputs(struct
> > drm_device *dev)
> >  	 * be removed since we'll be setting up real connector state, which
> >  	 * will contain Intel-specific properties.
> >  	 */
> > -	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> > -		list_for_each_entry(connector,
> > -				    &dev->mode_config.connector_list,
> > -				    head) {
> > -			if (!WARN_ON(connector->state)) {
> > -				connector->state =
> > -					kzalloc(sizeof(*connector->state),
> > -						GFP_KERNEL);
> > -			}
> > +	/* FIXME: need to update the comment above. */
> 
> Can you fix the comment instead of adding another FIXME to fix it later?

Oh, I added that FIXME as a note to myself and then let it slip through.
I'll fix and resend.

> 
> > +	list_for_each_entry(connector,
> > +			    &dev->mode_config.connector_list,
> > +			    head) {
> > +		if (!WARN_ON(connector->state)) {
> 
> In intel_modeset_stage_output_state() there is a call to setup
> connector state:
> 	connector_state = drm_atomic_get_connector_state(state, &connector->base);
> Is that call is covering modeset via crtc_set_config() but not during init flow, so 
> doing it here?  
> If that is the case, we probably know that connector->state
> is never being set, so why have WARN_ON()?

The purpose of that WARN_ON is to remind us to remove this whole loop
when we implement connector_states with connector properties. Matt added
this here to avoid a NULL pointer dereference when using nuclear page
flip, but it should go away and be part of connector initialization.

Ander


> As lower level compute code is already 
> > +			connector->state = kzalloc(sizeof(*connector->state),
> > +						   GFP_KERNEL);
> >  		}
> >  	}
> > 
> > @@ -13937,6 +13958,8 @@ void intel_modeset_setup_hw_state(struct
> > drm_device *dev,
> >  				       "[setup_hw_state]");
> >  	}
> > 
> > +	intel_modeset_update_connector_atomic_state(dev);
> > +
> >  	for (i = 0; i < dev_priv->num_shared_dpll; i++) {
> >  		struct intel_shared_dpll *pll = &dev_priv->shared_dplls[i];
> > 
> > --
> > 2.1.0
> 


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

  reply	other threads:[~2015-03-20  6:41 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13  9:48 [PATCH v2 00/19] Remove depencies on staged config for atomic transition Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 01/19] drm/i915: Add intel_atomic_get_crtc_state() helper function Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 02/19] drm/i915: Pass acquire ctx also to intel_release_load_detect_pipe() Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 03/19] drm/i915: Allocate a drm_atomic_state for the legacy modeset code Ander Conselvan de Oliveira
2015-03-17  6:46   ` [PATCH v3] " Ander Conselvan de Oliveira
2015-03-18  7:57     ` [PATCH v4] " Ander Conselvan de Oliveira
2015-03-18 23:57       ` Konduru, Chandra
2015-03-19  7:50         ` Ander Conselvan De Oliveira
2015-03-19 21:08   ` [PATCH 03/19] " Konduru, Chandra
2015-03-20  7:00     ` Ander Conselvan De Oliveira
2015-03-22 16:28       ` Konduru, Chandra
2015-03-13  9:48 ` [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc is being disabled Ander Conselvan de Oliveira
     [not found]   ` <76A9B330A4D78C4D99CB292C4CC06C0E36F7B41B@fmsmsx101.amr.corp.intel.com>
2015-03-19  7:52     ` Ander Conselvan De Oliveira
2015-03-19 23:23       ` Konduru, Chandra
2015-03-20  8:40         ` Ander Conselvan De Oliveira
2015-03-20  9:51           ` Daniel Vetter
2015-03-20 10:06             ` Ander Conselvan De Oliveira
2015-03-20 10:39               ` Daniel Vetter
2015-03-22 16:46           ` Konduru, Chandra
2015-03-13  9:48 ` [PATCH 05/19] drm/i915: Update dummy connector atomic state with current config Ander Conselvan de Oliveira
2015-03-19 20:55   ` Konduru, Chandra
2015-03-20  6:41     ` Ander Conselvan De Oliveira [this message]
2015-03-13  9:48 ` [PATCH 06/19] drm/i915: Implement connector state duplication Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 07/19] drm/i915: Copy the staged connector config to the legacy atomic state Ander Conselvan de Oliveira
     [not found]   ` <76A9B330A4D78C4D99CB292C4CC06C0E36F7B6F0@fmsmsx101.amr.corp.intel.com>
2015-03-19  7:52     ` Ander Conselvan De Oliveira
2015-03-19 15:15       ` Daniel Vetter
2015-03-13  9:48 ` [PATCH 08/19] drm/i915: Don't use encoder->new_crtc in intel_modeset_pipe_config() Ander Conselvan de Oliveira
2015-03-19  0:44   ` Konduru, Chandra
2015-03-19  7:52     ` Ander Conselvan De Oliveira
2015-03-13  9:48 ` [PATCH 09/19] drm/i915: Don't use encoder->new_crtc in compute_baseline_pipe_bpp() Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 10/19] drm/i915: Don't depend on encoder->new_crtc in intel_dp_compute_config() Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 11/19] drm/i915: Don't depend on encoder->new_crtc in intel_hdmi_compute_config Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 12/19] drm/i915: Use atomic state in intel_ddi_crtc_get_new_encoder() Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 13/19] drm/i915: Don't use staged config in intel_dp_mst_compute_config() Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 14/19] drm/i915: Don't use encoder->new_crtc in intel_lvds_compute_config() Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 15/19] drm/i915: Pass an atomic state to modeset_global_resources() functions Ander Conselvan de Oliveira
2015-03-13  9:48 ` [PATCH 16/19] drm/i915: Check lane sharing between pipes B & C using atomic state Ander Conselvan de Oliveira
2015-03-19 20:58   ` Konduru, Chandra
2015-03-20  6:46     ` Conselvan De Oliveira, Ander
2015-03-22 16:20       ` Konduru, Chandra
2015-03-23  7:33         ` Ander Conselvan De Oliveira
2015-03-23 16:57           ` Konduru, Chandra
2015-03-13  9:49 ` [PATCH 17/19] drm/i915: Convert intel_pipe_will_have_type() to " Ander Conselvan de Oliveira
2015-03-19 19:24   ` Konduru, Chandra
2015-03-20  6:28     ` Ander Conselvan De Oliveira
2015-03-22 16:14       ` Konduru, Chandra
2015-03-13  9:49 ` [PATCH 18/19] drm/i915: Don't look at staged config crtc when changing DRRS state Ander Conselvan de Oliveira
2015-03-13  9:49 ` [PATCH 19/19] drm/i915: Remove usage of encoder->new_crtc from clock computations Ander Conselvan de Oliveira
2015-03-14  0:29   ` shuang.he
2015-03-19 20:39   ` Konduru, Chandra
2015-03-18 23:57 ` [PATCH v2 00/19] Remove depencies on staged config for atomic transition Konduru, Chandra
2015-03-19 15:20   ` Daniel Vetter

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=1426833678.2316.13.camel@gmail.com \
    --to=conselvan2@gmail.com \
    --cc=chandra.konduru@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.