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

Wed Mar 20 20:52:11 UTC 2024

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.

> 
> Stan
> 
> > > > > > 7. decrease cdclk, mbus joining is unchanged
> > > > > >   7.1 update dbuf tracker value
> > > > > >   7.2 reprogram cdclk
> > > > 
> > > > The whole state dance between dbuf and cdclk states
> > > > is rather annoying since it needs careful sequencing.
> > > > But perhaps there is no better way to deal with this.
> > > > 
> > > > And one thing that should be fixed at least are the
> > > > redundant intel_atomic_lock_global_state() calls in 
> > > > intel_cdclk_state_set_joined_mbus() and
> > > > intel_dbuf_state_set_mdclk_cdclk_ratio().
> > > 
> > > Why are they redundant?
> > > I think we should involve Gustavo here probably, since
> > > that was his recent changes.
> > 
> > Locking is needed when the state changes. Those things don't check
> > if anything changed.
> > 
> > > 
> > > > 
> > > > I was actually pondering about an earlier discussion we
> > > > had wrt. potentially having some kind of need_lock/need_serialize 
> > > > funcs for each global obj. We could perhaps have those as vfuncs
> > > > in the global obj and have it do the right thing automagically
> > > > at the end of atomic_check(), without the need to sprinke any
> > > > lock()/serialize() calls anywhere else. The downside would be
> > > > that we take the locks much later, so it could in theory cause
> > > > more -DEADLK retries. But dunno how much that would matter.
> > > > 
> > > > -- 
> > > > Ville Syrjälä
> > > > Intel
> > 
> > -- 
> > Ville Syrjälä
> > Intel

-- 
Ville Syrjälä
Intel