[PATCH 2/4] drm/i915: Break intel_dbuf_mbus_update into 2 separate parts

Fri Mar 22 07:50:12 UTC 2024

On Thu, Mar 21, 2024 at 02:59:13PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 21, 2024 at 02:31:21PM +0200, Lisovskiy, Stanislav wrote:
> > On Thu, Mar 21, 2024 at 02:21:13PM +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 21, 2024 at 11:16:18AM +0200, Lisovskiy, Stanislav wrote:
> > > > On Thu, Mar 21, 2024 at 10:43:10AM +0200, Lisovskiy, Stanislav wrote:
> > > > > On Wed, Mar 20, 2024 at 10:52:11PM +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Mar 20, 2024 at 09:31:07PM +0200, Lisovskiy, Stanislav wrote:
> > > > > > > On Tue, Mar 19, 2024 at 08:22:12PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Tue, Mar 19, 2024 at 11:53:53AM +0200, Lisovskiy, Stanislav wrote:
> > > > > > > > > On Tue, Mar 19, 2024 at 11:11:06AM +0200, Ville Syrjälä wrote:
> > > > > > > > > > On Mon, Mar 18, 2024 at 11:44:21PM +0200, Lisovskiy, Stanislav wrote:
> > > > > > > > > > > On Mon, Mar 18, 2024 at 08:01:41PM +0200, Ville Syrjälä wrote:
> > > > > > > > > > > > On Sun, Mar 17, 2024 at 07:24:14PM +0200, Stanislav Lisovskiy wrote:
> > > > > > > > > > > > > We need to be able to update dbuf min tracker and mdclk ratio
> > > > > > > > > > > > > separately if mbus_join state didn't change, so lets add one
> > > > > > > > > > > > > degree of freedom and make it possible.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >  drivers/gpu/drm/i915/display/skl_watermark.c | 55 ++++++++++++--------
> > > > > > > > > > > > >  1 file changed, 33 insertions(+), 22 deletions(-)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > > > > > > > > > > index 2d3b08c2f8d78..d7d2278fd201c 100644
> > > > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> > > > > > > > > > > > > @@ -3570,16 +3570,38 @@ void intel_dbuf_mdclk_cdclk_ratio_update(struct drm_i915_private *i915, u8 ratio
> > > > > > > > > > > > >  			     DBUF_MIN_TRACKER_STATE_SERVICE(ratio - 1));
> > > > > > > > > > > > >  }
> > > > > > > > > > > > >  
> > > > > > > > > > > > > +static void intel_dbuf_mdclk_min_tracker_update(struct intel_atomic_state *state)
> > > > > > > > > > > > > +{
> > > > > > > > > > > > > +	struct drm_i915_private *i915 = to_i915(state->base.dev);
> > > > > > > > > > > > > +	const struct intel_dbuf_state *old_dbuf_state =
> > > > > > > > > > > > > +		intel_atomic_get_old_dbuf_state(state);
> > > > > > > > > > > > > +	const struct intel_dbuf_state *new_dbuf_state =
> > > > > > > > > > > > > +		intel_atomic_get_new_dbuf_state(state);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +	if (DISPLAY_VER(i915) >= 20 &&
> > > > > > > > > > > > > +	    old_dbuf_state->mdclk_cdclk_ratio != new_dbuf_state->mdclk_cdclk_ratio) {
> > > > > > > > > > > > > +		/*
> > > > > > > > > > > > > +		 * For Xe2LPD and beyond, when there is a change in the ratio
> > > > > > > > > > > > > +		 * between MDCLK and CDCLK, updates to related registers need to
> > > > > > > > > > > > > +		 * happen at a specific point in the CDCLK change sequence. In
> > > > > > > > > > > > > +		 * that case, we defer to the call to
> > > > > > > > > > > > > +		 * intel_dbuf_mdclk_cdclk_ratio_update() to the CDCLK logic.
> > > > > > > > > > > > > +		 */
> > > > > > > > > > > > > +		return;
> > > > > > > > > > > > > +	}
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +	intel_dbuf_mdclk_cdclk_ratio_update(i915, new_dbuf_state->mdclk_cdclk_ratio,
> > > > > > > > > > > > > +					    new_dbuf_state->joined_mbus);
> > > > > > > > > > > > > +}
> > > > > > > > > > > > 
> > > > > > > > > > > > Argh. The hardware is turning into a disaster with all these
> > > > > > > > > > > > links between different units.
> > > > > > > > > > > > 
> > > > > > > > > > > > This whole thing looks rather suspicious as the cdclk changes
> > > > > > > > > > > > and mbus joining changes don't happen in sync.
> > > > > > > > > > > > 
> > > > > > > > > > > > AFAICS the sequence should end up doing more or less like this:
> > > > > > > > > > > > 1. disable pipes
> > > > > > > > > > > > 2. increase cdclk
> > > > > > > > > > > >   2.1 reprogram cdclk
> > > > > > > > > > > >   2.2 update dbuf tracker value
> > > > > > > > > > > > 3. enable mbus joining if necessary
> > > > > > > > > > > >  3.1 update mbus_ctl
> > > > > > > > > > > >  3.2 update dbuf tracker value
> > > > > > > > > > > > 4. reallocate dbuf for planes on active pipes
> > > > > > > > > > > > 5. disable mbus joining if necessary
> > > > > > > > > > > >  5.1 update dbuf tracker value
> > > > > > > > > > > >  5.2 update mbus_ctl
> > > > > > > > > > > > 6. enable pipes
> > > > > > > > > > > > 7. decrease cdclk, mbus joining is unchanged
> > > > > > > > > > > >   7.1 update dbuf tracker value
> > > > > > > > > > > >   7.2 reprogram cdclk
> > > > > > > > > > > > 
> > > > > > > > > > > > So step 2.2 should keep using the old mbus_join valued when
> > > > > > > > > > > > updating the ratio, and steps 3.2,5.1,7.1 should use the new
> > > > > > > > > > > > value. That's assuming there is actually some ordering
> > > > > > > > > > > > requirements between these steps (whch bspec does seem to
> > > > > > > > > > > > imply).
> > > > > > > > > > > 
> > > > > > > > > > > So does it mean, we are missing updating dbuf tracker value
> > > > > > > > > > > in CDCLK programming path?
> > > > > > > > > > 
> > > > > > > > > > I'm saying we need to change it to use the correct (old)
> > > > > > > > > > value of mbus_join in intel_set_cdclk_pre_plane_update().
> > > > > > > 
> > > > > > > Could you elaborate a bit more, why we should keep using old
> > > > > > > mbus_join here? Didn't find anything about that in spec.
> > > > > > > All I see is that it instructs to use the new mdclk:cdclk ratio.
> > > > > > > 
> > > > > > > Or do you just mean that we do it step by step, i.e first
> > > > > > > reprogram CDCLK:MDCLK with old mbus join, then update it if necessary
> > > > > > > as a separate step, to avoid changing both same time?
> > > > > > 
> > > > > > Exactly. IMO the cdclk code should not touch the mbus
> > > > > > joining stuff in MBUS_CTL. That is the responsibility of
> > > > > > the pre/post ddb hooks, which know how to do it safely
> > > > > > wrt. the plane ddb updates.
> > > > > > 
> > > > > > > 
> > > > > > > For decrease step we then need to use new mbus_join state, I suppose?
> > > > > > 
> > > > > > Yes.
> > > > > 
> > > > > Ok, that one sounds clear.
> > > > 
> > > > One technical detail though. 
> > > > intel_set_cdclk_pre_plane_update doesn't pass to intel_set_cdclk neither state
> > > > nor old_cdclk_state. 
> > > > I guess we are not going to change intel_set_cdclk and all the hooks it is calling to propagate the old_cdclk_state or intel_atomic_state.
> > > > So how are we going to get old_cdclk_state->joined_mbus then?
> > > > One option could be to assign new_cdclk_state->joined_mbus = old_cdclk_state->joined_mbus in intel_set_cdclk_pre_plane_update, where we still have visibility to both.
> > > > But it is of course a hack.
> > > > Or should I somehow fetch the actual state from HW/dev_priv?
> > > 
> > > I think the easiest solution for now is to just pass the
> > > correct mbus_join all the way from the top.
> > > 
> > > We can revisit that later if someone comes up with a
> > > better way to do things.
> > 
> > Sounds really weird.. Also I think then we might have to change all the hooks, like bxt_set_cdclk to accept mbus_join as a param,
> > which sounds quite odd.
> 
> I suppose another option is to just make a copy of the cdclk_config
> in intel_set_cdclk_pre_plane_update() and adjust its mbus_join
> appropriately.

Yeah that one seems to be way more attractive.

> 
> -- 
> Ville Syrjälä
> Intel