Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/7] drm/i915/display: Refactor intel_commit_modeset_disables()
Date: Wed, 27 Nov 2019 21:11:52 +0200	[thread overview]
Message-ID: <20191127191152.GM1208@intel.com> (raw)
In-Reply-To: <179a6918f894feb8753674ea419f3e50fae775e8.camel@intel.com>

On Tue, Nov 26, 2019 at 10:03:08PM +0000, Souza, Jose wrote:
> On Tue, 2019-11-26 at 21:40 +0200, Ville Syrjälä wrote:
> > On Fri, Nov 22, 2019 at 04:54:53PM -0800, José Roberto de Souza
> > wrote:
> > > Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
> > > reverted the order that pipes gets disabled because of TGL
> > > master/slave relationship between transcoders in MST mode.
> > > 
> > > But as stated in a comment in skl_commit_modeset_enables() the
> > > enabling order is not always crescent, possibly causing previously
> > > selected slave transcoder being enabled before master so another
> > > approach will be needed to select a transcoder to master in MST
> > > mode.
> > > It will be similar to the approach taken in port sync.
> > > 
> > > But instead of implement something like
> > > intel_trans_port_sync_modeset_disables() to MST lets simply it and
> > > iterate over all pipes 2 times, the first one disabling any slave
> > > and
> > > then disabling everything else.
> > > The MST bits will be added in another patch.
> > > 
> > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 79 ++++++--------
> > > ------
> > >  1 file changed, 22 insertions(+), 57 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 53dc310a5f6d..1b1fbb6d8acc 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -14443,53 +14443,16 @@ static void
> > > intel_old_crtc_state_disables(struct intel_atomic_state *state,
> > >  		dev_priv->display.initial_watermarks(state, crtc);
> > >  }
> > >  
> > > -static void intel_trans_port_sync_modeset_disables(struct
> > > intel_atomic_state *state,
> > > -						   struct intel_crtc
> > > *crtc,
> > > -						   struct
> > > intel_crtc_state *old_crtc_state,
> > > -						   struct
> > > intel_crtc_state *new_crtc_state)
> > > -{
> > > -	struct intel_crtc *slave_crtc =
> > > intel_get_slave_crtc(new_crtc_state);
> > > -	struct intel_crtc_state *new_slave_crtc_state =
> > > -		intel_atomic_get_new_crtc_state(state, slave_crtc);
> > > -	struct intel_crtc_state *old_slave_crtc_state =
> > > -		intel_atomic_get_old_crtc_state(state, slave_crtc);
> > > -
> > > -	WARN_ON(!slave_crtc || !new_slave_crtc_state ||
> > > -		!old_slave_crtc_state);
> > > -
> > > -	/* Disable Slave first */
> > > -	intel_pre_plane_update(old_slave_crtc_state,
> > > new_slave_crtc_state);
> > > -	if (old_slave_crtc_state->hw.active)
> > > -		intel_old_crtc_state_disables(state,
> > > -					      old_slave_crtc_state,
> > > -					      new_slave_crtc_state,
> > > -					      slave_crtc);
> > > -
> > > -	/* Disable Master */
> > > -	intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > > -	if (old_crtc_state->hw.active)
> > > -		intel_old_crtc_state_disables(state,
> > > -					      old_crtc_state,
> > > -					      new_crtc_state,
> > > -					      crtc);
> > > -}
> > > -
> > >  static void intel_commit_modeset_disables(struct
> > > intel_atomic_state *state)
> > >  {
> > >  	struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> > >  	struct intel_crtc *crtc;
> > >  	int i;
> > >  
> > > -	/*
> > > -	 * Disable CRTC/pipes in reverse order because some
> > > features(MST in
> > > -	 * TGL+) requires master and slave relationship between pipes,
> > > so it
> > > -	 * should always pick the lowest pipe as master as it will be
> > > enabled
> > > -	 * first and disable in the reverse order so the master will be
> > > the
> > > -	 * last one to be disabled.
> > > -	 */
> > > -	for_each_oldnew_intel_crtc_in_state_reverse(state, crtc,
> > > old_crtc_state,
> > > -						    new_crtc_state, i)
> > > {
> > > -		if (!needs_modeset(new_crtc_state))
> > > +	/* Only disable port sync slaves */
> > > +	for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > old_crtc_state,
> > > +					    new_crtc_state, i) {
> > > +		if (!needs_modeset(new_crtc_state) || !crtc->active)
> > 
> > What's the deal with these crtc->active checks?
> 
> With just one loop we were using "old_crtc_state->hw.active" but as we
> should not modify the computed state in this phase and
> intel_old_crtc_state_disables() sets crtc->active = false, using it
> instead.

You should never use it. We should aim towards eliminating it. I don't
think we're far off now.

> 
> > 
> > >  			continue;
> > >  
> > >  		/* In case of Transcoder port Sync master slave CRTCs
> > > can be
> > > @@ -14497,23 +14460,25 @@ static void
> > > intel_commit_modeset_disables(struct intel_atomic_state *state)
> > >  		 * slave CRTCs are disabled first and then master CRTC
> > > since
> > >  		 * Slave vblanks are masked till Master Vblanks.
> > >  		 */
> > > -		if (is_trans_port_sync_mode(new_crtc_state)) {
> > > -			if (is_trans_port_sync_master(new_crtc_state))
> > > -				intel_trans_port_sync_modeset_disables(
> > > state,
> > > -								       
> > > crtc,
> > > -								       
> > > old_crtc_state,
> > > -								       
> > > new_crtc_state);
> > > -			else
> > > -				continue;
> > > -		} else {
> > > -			intel_pre_plane_update(old_crtc_state,
> > > new_crtc_state);
> > > +		if (!is_trans_port_sync_mode(new_crtc_state))
> > > +			continue;
> > > +		if (is_trans_port_sync_master(new_crtc_state))
> > > +			continue;
> > 
> > We don't have is_trans_sync_slave()?
> 
> We don't.

Maybe add it?

> 
> > 
> > >  
> > > -			if (old_crtc_state->hw.active)
> > > -				intel_old_crtc_state_disables(state,
> > > -							      old_crtc_
> > > state,
> > > -							      new_crtc_
> > > state,
> > > -							      crtc);
> > > -		}
> > > +		intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > > +		intel_old_crtc_state_disables(state, old_crtc_state,
> > > +					      new_crtc_state, crtc);
> > > +	}
> > > +
> > > +	/* Disable everything else left on */
> > > +	for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > old_crtc_state,
> > > +					    new_crtc_state, i) {
> > > +		if (!needs_modeset(new_crtc_state) || !crtc->active)
> > > +			continue;
> > > +
> > > +		intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > > +		intel_old_crtc_state_disables(state, old_crtc_state,
> > > +					      new_crtc_state, crtc);
> > 
> > Pondering if there's any chance of some odd fail if we have two ports
> > running in port sync mode. That will now lead to
> > disable_slave(0)->disable_slave(1)->disable_master(0)-
> > >disable_master(1)...
> 
> Thoughts Manasi?
> 
> > 
> > >  	}
> > >  }
> > >  
> > > -- 
> > > 2.24.0

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915/display: Refactor intel_commit_modeset_disables()
Date: Wed, 27 Nov 2019 21:11:52 +0200	[thread overview]
Message-ID: <20191127191152.GM1208@intel.com> (raw)
Message-ID: <20191127191152.WUHVzREFGcmPb85-_vzbX7W77yIcjVHjxeS0qqVTuDE@z> (raw)
In-Reply-To: <179a6918f894feb8753674ea419f3e50fae775e8.camel@intel.com>

On Tue, Nov 26, 2019 at 10:03:08PM +0000, Souza, Jose wrote:
> On Tue, 2019-11-26 at 21:40 +0200, Ville Syrjälä wrote:
> > On Fri, Nov 22, 2019 at 04:54:53PM -0800, José Roberto de Souza
> > wrote:
> > > Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
> > > reverted the order that pipes gets disabled because of TGL
> > > master/slave relationship between transcoders in MST mode.
> > > 
> > > But as stated in a comment in skl_commit_modeset_enables() the
> > > enabling order is not always crescent, possibly causing previously
> > > selected slave transcoder being enabled before master so another
> > > approach will be needed to select a transcoder to master in MST
> > > mode.
> > > It will be similar to the approach taken in port sync.
> > > 
> > > But instead of implement something like
> > > intel_trans_port_sync_modeset_disables() to MST lets simply it and
> > > iterate over all pipes 2 times, the first one disabling any slave
> > > and
> > > then disabling everything else.
> > > The MST bits will be added in another patch.
> > > 
> > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 79 ++++++--------
> > > ------
> > >  1 file changed, 22 insertions(+), 57 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 53dc310a5f6d..1b1fbb6d8acc 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -14443,53 +14443,16 @@ static void
> > > intel_old_crtc_state_disables(struct intel_atomic_state *state,
> > >  		dev_priv->display.initial_watermarks(state, crtc);
> > >  }
> > >  
> > > -static void intel_trans_port_sync_modeset_disables(struct
> > > intel_atomic_state *state,
> > > -						   struct intel_crtc
> > > *crtc,
> > > -						   struct
> > > intel_crtc_state *old_crtc_state,
> > > -						   struct
> > > intel_crtc_state *new_crtc_state)
> > > -{
> > > -	struct intel_crtc *slave_crtc =
> > > intel_get_slave_crtc(new_crtc_state);
> > > -	struct intel_crtc_state *new_slave_crtc_state =
> > > -		intel_atomic_get_new_crtc_state(state, slave_crtc);
> > > -	struct intel_crtc_state *old_slave_crtc_state =
> > > -		intel_atomic_get_old_crtc_state(state, slave_crtc);
> > > -
> > > -	WARN_ON(!slave_crtc || !new_slave_crtc_state ||
> > > -		!old_slave_crtc_state);
> > > -
> > > -	/* Disable Slave first */
> > > -	intel_pre_plane_update(old_slave_crtc_state,
> > > new_slave_crtc_state);
> > > -	if (old_slave_crtc_state->hw.active)
> > > -		intel_old_crtc_state_disables(state,
> > > -					      old_slave_crtc_state,
> > > -					      new_slave_crtc_state,
> > > -					      slave_crtc);
> > > -
> > > -	/* Disable Master */
> > > -	intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > > -	if (old_crtc_state->hw.active)
> > > -		intel_old_crtc_state_disables(state,
> > > -					      old_crtc_state,
> > > -					      new_crtc_state,
> > > -					      crtc);
> > > -}
> > > -
> > >  static void intel_commit_modeset_disables(struct
> > > intel_atomic_state *state)
> > >  {
> > >  	struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> > >  	struct intel_crtc *crtc;
> > >  	int i;
> > >  
> > > -	/*
> > > -	 * Disable CRTC/pipes in reverse order because some
> > > features(MST in
> > > -	 * TGL+) requires master and slave relationship between pipes,
> > > so it
> > > -	 * should always pick the lowest pipe as master as it will be
> > > enabled
> > > -	 * first and disable in the reverse order so the master will be
> > > the
> > > -	 * last one to be disabled.
> > > -	 */
> > > -	for_each_oldnew_intel_crtc_in_state_reverse(state, crtc,
> > > old_crtc_state,
> > > -						    new_crtc_state, i)
> > > {
> > > -		if (!needs_modeset(new_crtc_state))
> > > +	/* Only disable port sync slaves */
> > > +	for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > old_crtc_state,
> > > +					    new_crtc_state, i) {
> > > +		if (!needs_modeset(new_crtc_state) || !crtc->active)
> > 
> > What's the deal with these crtc->active checks?
> 
> With just one loop we were using "old_crtc_state->hw.active" but as we
> should not modify the computed state in this phase and
> intel_old_crtc_state_disables() sets crtc->active = false, using it
> instead.

You should never use it. We should aim towards eliminating it. I don't
think we're far off now.

> 
> > 
> > >  			continue;
> > >  
> > >  		/* In case of Transcoder port Sync master slave CRTCs
> > > can be
> > > @@ -14497,23 +14460,25 @@ static void
> > > intel_commit_modeset_disables(struct intel_atomic_state *state)
> > >  		 * slave CRTCs are disabled first and then master CRTC
> > > since
> > >  		 * Slave vblanks are masked till Master Vblanks.
> > >  		 */
> > > -		if (is_trans_port_sync_mode(new_crtc_state)) {
> > > -			if (is_trans_port_sync_master(new_crtc_state))
> > > -				intel_trans_port_sync_modeset_disables(
> > > state,
> > > -								       
> > > crtc,
> > > -								       
> > > old_crtc_state,
> > > -								       
> > > new_crtc_state);
> > > -			else
> > > -				continue;
> > > -		} else {
> > > -			intel_pre_plane_update(old_crtc_state,
> > > new_crtc_state);
> > > +		if (!is_trans_port_sync_mode(new_crtc_state))
> > > +			continue;
> > > +		if (is_trans_port_sync_master(new_crtc_state))
> > > +			continue;
> > 
> > We don't have is_trans_sync_slave()?
> 
> We don't.

Maybe add it?

> 
> > 
> > >  
> > > -			if (old_crtc_state->hw.active)
> > > -				intel_old_crtc_state_disables(state,
> > > -							      old_crtc_
> > > state,
> > > -							      new_crtc_
> > > state,
> > > -							      crtc);
> > > -		}
> > > +		intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > > +		intel_old_crtc_state_disables(state, old_crtc_state,
> > > +					      new_crtc_state, crtc);
> > > +	}
> > > +
> > > +	/* Disable everything else left on */
> > > +	for_each_oldnew_intel_crtc_in_state(state, crtc,
> > > old_crtc_state,
> > > +					    new_crtc_state, i) {
> > > +		if (!needs_modeset(new_crtc_state) || !crtc->active)
> > > +			continue;
> > > +
> > > +		intel_pre_plane_update(old_crtc_state, new_crtc_state);
> > > +		intel_old_crtc_state_disables(state, old_crtc_state,
> > > +					      new_crtc_state, crtc);
> > 
> > Pondering if there's any chance of some odd fail if we have two ports
> > running in port sync mode. That will now lead to
> > disable_slave(0)->disable_slave(1)->disable_master(0)-
> > >disable_master(1)...
> 
> Thoughts Manasi?
> 
> > 
> > >  	}
> > >  }
> > >  
> > > -- 
> > > 2.24.0

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-11-27 19:11 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23  0:54 [PATCH 1/7] drm/i915/display: Refactor intel_commit_modeset_disables() José Roberto de Souza
2019-11-23  0:54 ` [Intel-gfx] " José Roberto de Souza
2019-11-23  0:54 ` [PATCH 2/7] drm/i915/display: Check the old state to find port sync slave José Roberto de Souza
2019-11-23  0:54   ` [Intel-gfx] " José Roberto de Souza
2019-11-26 19:41   ` Ville Syrjälä
2019-11-26 19:41     ` [Intel-gfx] " Ville Syrjälä
2019-11-23  0:54 ` [PATCH 3/7] drm/i915/tgl: Select master trasconder for MST stream José Roberto de Souza
2019-11-23  0:54   ` [Intel-gfx] " José Roberto de Souza
2019-11-26 20:05   ` Ville Syrjälä
2019-11-26 20:05     ` [Intel-gfx] " Ville Syrjälä
2019-11-26 20:30     ` Souza, Jose
2019-11-26 20:30       ` [Intel-gfx] " Souza, Jose
2019-11-27 19:59       ` Ville Syrjälä
2019-11-27 19:59         ` [Intel-gfx] " Ville Syrjälä
2019-11-28  1:14         ` Souza, Jose
2019-11-28  1:14           ` [Intel-gfx] " Souza, Jose
2019-11-28 12:06           ` Ville Syrjälä
2019-11-28 12:06             ` [Intel-gfx] " Ville Syrjälä
2019-12-02 22:03             ` Souza, Jose
2019-12-02 22:03               ` [Intel-gfx] " Souza, Jose
2019-12-03 12:47               ` Ville Syrjälä
2019-12-03 22:12                 ` Souza, Jose
2019-12-04 10:55                   ` Ville Syrjälä
2019-12-04 18:48                     ` Souza, Jose
2019-12-04 19:03                       ` Ville Syrjälä
2019-11-23  0:54 ` [PATCH 4/7] drm/i915/dp: Power down sink before disable pipe/transcoder clock José Roberto de Souza
2019-11-23  0:54   ` [Intel-gfx] " José Roberto de Souza
2019-11-26 20:15   ` Ville Syrjälä
2019-11-26 20:15     ` [Intel-gfx] " Ville Syrjälä
2019-11-26 22:12     ` Souza, Jose
2019-11-26 22:12       ` [Intel-gfx] " Souza, Jose
2019-11-27 19:24       ` Ville Syrjälä
2019-11-27 19:24         ` [Intel-gfx] " Ville Syrjälä
2019-11-28  1:08         ` Souza, Jose
2019-11-28  1:08           ` [Intel-gfx] " Souza, Jose
2019-11-28 18:30           ` Ville Syrjälä
2019-11-28 18:30             ` [Intel-gfx] " Ville Syrjälä
2019-11-23  0:54 ` [PATCH 5/7] drm/i915/display/mst: Move DPMS_OFF call to post_disable José Roberto de Souza
2019-11-23  0:54   ` [Intel-gfx] " José Roberto de Souza
2019-11-28 18:31   ` Ville Syrjälä
2019-11-28 18:31     ` [Intel-gfx] " Ville Syrjälä
2019-11-23  0:54 ` [PATCH 6/7] drm/i915/display/tgl: Fix the order of the step to turn transcoder clock off José Roberto de Souza
2019-11-23  0:54   ` [Intel-gfx] " José Roberto de Souza
2019-11-28 18:40   ` Ville Syrjälä
2019-11-28 18:40     ` [Intel-gfx] " Ville Syrjälä
2019-12-03 23:29     ` Souza, Jose
2019-12-04 10:56       ` Ville Syrjälä
2019-11-23  0:54 ` [PATCH 7/7] drm/display/dp: Fix MST disable sequences José Roberto de Souza
2019-11-23  0:54   ` [Intel-gfx] " José Roberto de Souza
2019-11-23  1:28 ` ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915/display: Refactor intel_commit_modeset_disables() Patchwork
2019-11-23  1:28   ` [Intel-gfx] " Patchwork
2019-11-24  7:11 ` ✓ Fi.CI.IGT: " Patchwork
2019-11-24  7:11   ` [Intel-gfx] " Patchwork
2019-11-26 19:40 ` [PATCH 1/7] " Ville Syrjälä
2019-11-26 19:40   ` [Intel-gfx] " Ville Syrjälä
2019-11-26 22:03   ` Souza, Jose
2019-11-26 22:03     ` [Intel-gfx] " Souza, Jose
2019-11-26 22:49     ` Matt Roper
2019-11-26 22:49       ` [Intel-gfx] " Matt Roper
2019-11-26 23:03       ` Souza, Jose
2019-11-26 23:03         ` [Intel-gfx] " Souza, Jose
2019-11-27 18:49       ` Lucas De Marchi
2019-11-27 18:49         ` [Intel-gfx] " Lucas De Marchi
2019-11-27 19:11     ` Ville Syrjälä [this message]
2019-11-27 19:11       ` Ville Syrjälä

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=20191127191152.GM1208@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jose.souza@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox