All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state
Date: Thu, 30 Apr 2020 13:47:02 +0300	[thread overview]
Message-ID: <20200430104702.GA31341@intel.com> (raw)
In-Reply-To: <20200430103217.GR6112@intel.com>

On Thu, Apr 30, 2020 at 01:32:17PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 30, 2020 at 01:05:15PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Apr 30, 2020 at 12:21:04PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 23, 2020 at 10:58:56AM +0300, Stanislav Lisovskiy wrote:
> > > > We need to calculate SAGV mask also in a non-modeset
> > > > commit, however currently active_pipes are only calculated
> > > > for modesets in global atomic state, thus now we will be
> > > > tracking those also in bw_state in order to be able to
> > > > properly access global data.
> > > > 
> > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_bw.h |  3 +++
> > > >  drivers/gpu/drm/i915/intel_pm.c         | 15 ++++++++++-----
> > > >  2 files changed, 13 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > index d6df91058223..898b4a85ccab 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > > @@ -26,6 +26,9 @@ struct intel_bw_state {
> > > >  
> > > >  	unsigned int data_rate[I915_MAX_PIPES];
> > > >  	u8 num_active_planes[I915_MAX_PIPES];
> > > > +
> > > > +	/* bitmask of active pipes */
> > > > +	u8 active_pipes;
> > > >  };
> > > >  
> > > >  #define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 7e15cf3368ad..f7249bca3f6f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -3874,6 +3874,7 @@ static int intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > >  	struct intel_bw_state *new_bw_state = NULL;
> > > >  	const struct intel_bw_state *old_bw_state = NULL;
> > > >  	int i;
> > > > +	bool active_pipes_calculated = false;
> > > >  
> > > >  	for_each_new_intel_crtc_in_state(state, crtc,
> > > >  					 new_crtc_state, i) {
> > > > @@ -3883,6 +3884,12 @@ static int intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > >  
> > > >  		old_bw_state = intel_atomic_get_old_bw_state(state);
> > > >  
> > > > +		if (!active_pipes_calculated) {
> > > > +			state->active_pipes = new_bw_state->active_pipes =
> > > 
> > > I don't think we should touch state->active_pipes here.
> > 
> > Well, that was my question actually here as well. I understand that changing
> > state->active_pipes here feels like some unneeded side effect, however having
> > state->active_pipes and bw_state->active_pipes going out of sync doesn't sound
> > very attractive to me either. That is why I don't like this idea of duplication
> > at all - having constant need to sync those state, bw_state, cdclk_state, because
> > they all might have different active_pipes now.
> 
> Having an out of date active_pipes anywhere would be a bug in that
> specific code. Also state->active_pipes is definitely going the way of
> the dodo soon.
> 
> > 
> > > 
> > > > +				intel_calc_active_pipes(state, old_bw_state->active_pipes);
> > > > +			active_pipes_calculated = true;
> > > > +		}
> > > 
> > > I'd do this after the loop so we don't need this extra boolean. As far
> > > as the active_pipes check in intel_crtc_can_enable_sagv(), I think we
> > > can pull it out into intel_compute_sagv_mask() so that we do the check
> > > after computing the mask. And of course change it to use
> > > bw_state->active_pipes instead.
> > 
> > intel_crtc_can_enable_sagv is called per crtc - so can't just pull it out, 
> > will have to have to cycles then - one will compute bw_state->active_pipes,
> > and another pipe_sagv_mask.
> 
> Hmm. Actually I think what we should probably do is keep the
> active_pipes check in intel_can_enable_sagv(). Ie something like this:
> 
> intel_can_enable_sagv(bw_state) {
> 	if (active_pipes && !is_power_of_2(active_pipes))
> 	    	return false;
> 	return sagv_reject != 0;
> }

I need active_pipes check here for skl code only, as it disables SAGV for multipipe
scenarios. Adding this here would generalize it for other platforms and we
don't want that for ICL+.

In fact that is the only reason I need active pipes here - otherwise I think
it was even your comment that we actually don't need those here at all,
as we just iterate through crtcs in state - pretty clearly remember we discussed
this. Just same way how it's done in intel bw check and other places.

Stan

> 
> compute_sagv() {
> 	for_each_crtc() {
> 		if (crtc_can_sagv())
> 			sagv_reject &= ~pipe;
> 		else
> 			sagv_reject |= pipe;
> 	}
> 	
> 	active_pipes = calc_active_pipes();
> 
> 	... lock/serialize etc.
> }
> 
> That way we don't have to update sagv_reject at all based on
> active_pipes. I think that even makes more sense since the
> active_pipes check is a global thing and not tied to any specific
> crtc.
> 
> We can then make the check conditional on pre-icl (or whatever we want)
> in a later patch. And finally we can remove it altogether in a separate
> patch, since I don't think we should have to do it on any platform.
> 
> > 
> > > 
> > > We're also going to need to lock_global_state() if bw_state->active_pipes
> > > mask changes.
> > 
> > Ohh.. right.
> > 
> > 
> > Stan
> > 
> > > 
> > > > +
> > > >  		if (intel_crtc_can_enable_sagv(new_crtc_state))
> > > >  			new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
> > > >  		else
> > > > @@ -5911,11 +5918,9 @@ skl_compute_wm(struct intel_atomic_state *state)
> > > >  	if (ret)
> > > >  		return ret;
> > > >  
> > > > -	if (state->modeset) {
> > > > -		ret = intel_compute_sagv_mask(state);
> > > > -		if (ret)
> > > > -			return ret;
> > > > -	}
> > > > +	ret = intel_compute_sagv_mask(state);
> > > > +	if (ret)
> > > > +		return ret;
> > > 
> > > We also need to remove the state->modeset checks around
> > > sagv_{pre,post}_update().
> > > 
> > > >  
> > > >  	/*
> > > >  	 * skl_compute_ddb() will have adjusted the final watermarks
> > > > -- 
> > > > 2.24.1.485.gad05a3d8e5
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel
> 
> -- 
> Ville Syrjälä
> Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-04-30 10:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23  7:58 [Intel-gfx] [PATCH v26 0/9] SAGV support for Gen12+ Stanislav Lisovskiy
2020-04-23  7:58 ` [Intel-gfx] [PATCH v26 1/9] drm/i915: Introduce skl_plane_wm_level accessor Stanislav Lisovskiy
2020-04-23  7:58 ` [Intel-gfx] [PATCH v26 2/9] drm/i915: Use bw state for per crtc SAGV evaluation Stanislav Lisovskiy
2020-04-30  9:09   ` Ville Syrjälä
2020-04-30  9:13     ` Lisovskiy, Stanislav
2020-04-30  9:25       ` Ville Syrjälä
2020-04-30  9:52         ` Lisovskiy, Stanislav
2020-04-30 10:08           ` Ville Syrjälä
2020-04-30 10:14             ` Lisovskiy, Stanislav
2020-04-30 10:37               ` Ville Syrjälä
2020-04-30 19:17   ` Stanislav Lisovskiy
2020-04-23  7:58 ` [Intel-gfx] [PATCH v26 3/9] drm/i915: Track active_pipes in bw_state Stanislav Lisovskiy
2020-04-30  9:21   ` Ville Syrjälä
2020-04-30 10:05     ` Lisovskiy, Stanislav
2020-04-30 10:32       ` Ville Syrjälä
2020-04-30 10:47         ` Lisovskiy, Stanislav [this message]
2020-04-30 10:55           ` Ville Syrjälä
2020-04-30 11:07             ` Lisovskiy, Stanislav
2020-04-30 11:22               ` Ville Syrjälä
2020-04-30 11:29                 ` Lisovskiy, Stanislav
2020-04-30 11:40                   ` Ville Syrjälä
2020-04-30 11:48                     ` Lisovskiy, Stanislav
2020-04-30 19:20   ` Stanislav Lisovskiy
2020-04-30 19:56   ` Stanislav Lisovskiy
2020-04-23  7:58 ` [Intel-gfx] [PATCH v26 4/9] drm/i915: Separate icl and skl SAGV checking Stanislav Lisovskiy
2020-04-30 19:59   ` Stanislav Lisovskiy
2020-04-23  7:58 ` [Intel-gfx] [PATCH v26 5/9] drm/i915: Add TGL+ SAGV support Stanislav Lisovskiy
2020-04-30 20:00   ` Stanislav Lisovskiy
2020-04-23  7:58 ` [Intel-gfx] [PATCH v26 6/9] drm/i915: Added required new PCode commands Stanislav Lisovskiy
2020-05-04 16:12   ` Ville Syrjälä
2020-05-05  7:21   ` Stanislav Lisovskiy
2020-04-23  7:59 ` [Intel-gfx] [PATCH v26 7/9] drm/i915: Rename bw_state to new_bw_state Stanislav Lisovskiy
2020-04-23  7:59 ` [Intel-gfx] [PATCH v26 8/9] drm/i915: Restrict qgv points which don't have enough bandwidth Stanislav Lisovskiy
2020-05-05  7:23   ` Stanislav Lisovskiy
2020-04-23  7:59 ` [Intel-gfx] [PATCH v26 9/9] drm/i915: Enable SAGV support for Gen12 Stanislav Lisovskiy
2020-04-23  9:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for SAGV support for Gen12+ (rev27) Patchwork
2020-04-23  9:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-04-23 11:29 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-04-30 22:07 ` [Intel-gfx] ✓ Fi.CI.BAT: success for SAGV support for Gen12+ (rev32) Patchwork
2020-05-01  5:52 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-05-05  8:11 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for SAGV support for Gen12+ (rev34) Patchwork
2020-05-05  8:51   ` Lisovskiy, Stanislav

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=20200430104702.GA31341@intel.com \
    --to=stanislav.lisovskiy@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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.