Re: [PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain() to use DSB_WAIT_FOR_VBLANK

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Jul 05, 2024 at 04:09:43PM +0000, Manna, Animesh wrote:
> 
> 
> > -----Original Message-----
> > From: Manna, Animesh
> > Sent: Friday, July 5, 2024 9:29 PM
> > To: Ville Syrjala <ville.syrjala@linux.intel.com>; intel-
> > gfx@lists.freedesktop.org
> > Subject: RE: [PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain() to use
> > DSB_WAIT_FOR_VBLANK
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of
> > Ville
> > > Syrjala
> > > Sent: Tuesday, June 25, 2024 12:40 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [PATCH 11/14] drm/i915/dsb: Allow intel_dsb_chain() to use
> > > DSB_WAIT_FOR_VBLANK
> > >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > Allow intel_dsb_chain() to start the chained DSB
> > > at start of the undelaye vblank. This is slightly
> > > more involved than simply setting the bit as we
> > > must use the DEwake mechanism to eliminate pkgC
> > > latency.
> > >
> > > And DSB_ENABLE_DEWAKE itself is problematic in that
> > > it allows us to configure just a single scanline,
> > > and if the current scanline is already past that
> > > DSB_ENABLE_DEWAKE won't do anything, rendering the
> > > whole thing moot.
> > >
> > > The current workaround involves checking the pipe's current
> > > scanline with the CPU, and if it looks like we're about to
> > > miss the configured DEwake scanline we set DSB_FORCE_DEWAKE
> > > to immediately assert DEwake. This is somewhat racy since the
> > > hardware is making progress all the while we're checking it on
> > > the CPU.
> > >
> > > We can make things less racy by chaining two DSBs and handling
> > > the DSB_FORCE_DEWAKE stuff entirely without CPU involvement:
> > > 1. CPU starts the first DSB immediately
> > > 2. First DSB configures the second DSB, including its dewake_scanline
> > > 3. First DSB starts the second w/ DSB_WAIT_FOR_VBLANK
> > > 4. First DSB asserts DSB_FORCE_DEWAKE
> > > 5. First DSB waits until we're outside the dewake_scanline-vblank_start
> > >    window
> > > 6. First DSB deasserts DSB_FORCE_DEWAKE
> > >
> > > That will guarantee that the we are fully awake when the second
> > > DSB starts to actually execute.
> > >
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dsb.c | 43 +++++++++++++++++++++---
> > >  drivers/gpu/drm/i915/display/intel_dsb.h |  3 +-
> > >  2 files changed, 40 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > > index 4c0519c41f16..cf710f0bf430 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > > @@ -130,8 +130,8 @@ static int dsb_vtotal(struct intel_atomic_state
> > *state,
> > >  		return intel_mode_vtotal(&crtc_state->hw.adjusted_mode);
> > >  }
> > >
> > > -static int dsb_dewake_scanline(struct intel_atomic_state *state,
> > > -			       struct intel_crtc *crtc)
> > > +static int dsb_dewake_scanline_start(struct intel_atomic_state *state,
> > > +				     struct intel_crtc *crtc)
> > >  {
> > >  	const struct intel_crtc_state *crtc_state =
> > > pre_commit_crtc_state(state, crtc);
> > >  	struct drm_i915_private *i915 = to_i915(state->base.dev);
> > > @@ -141,6 +141,14 @@ static int dsb_dewake_scanline(struct
> > > intel_atomic_state *state,
> > >  		intel_usecs_to_scanlines(&crtc_state->hw.adjusted_mode,
> > > latency);
> > >  }
> > >
> > > +static int dsb_dewake_scanline_end(struct intel_atomic_state *state,
> > > +				   struct intel_crtc *crtc)
> > > +{
> > > +	const struct intel_crtc_state *crtc_state =
> > > pre_commit_crtc_state(state, crtc);
> > > +
> > > +	return intel_mode_vdisplay(&crtc_state->hw.adjusted_mode);
> > > +}
> > > +
> > >  static int dsb_scanline_to_hw(struct intel_atomic_state *state,
> > >  			      struct intel_crtc *crtc, int scanline)
> > >  {
> > > @@ -529,19 +537,44 @@ static void _intel_dsb_chain(struct
> > > intel_atomic_state *state,
> > >  			    dsb_error_int_status(display) |
> > > DSB_PROG_INT_STATUS |
> > >  			    dsb_error_int_en(display));
> > >
> > > +	if (ctrl & DSB_WAIT_FOR_VBLANK) {
> > > +		int dewake_scanline = dsb_dewake_scanline_start(state,
> > > crtc);
> > > +		int hw_dewake_scanline = dsb_scanline_to_hw(state, crtc,
> > > dewake_scanline);
> > > +
> > > +		intel_dsb_reg_write(dsb, DSB_PMCTRL(pipe, chained_dsb-
> > > >id),
> > > +				    DSB_ENABLE_DEWAKE |
> > > +
> > > DSB_SCANLINE_FOR_DEWAKE(hw_dewake_scanline));
> 
> One quick check: As per bspec DSB_PMCTRL  can be updated only before the DSB_CTRL register is programmed to enable the DSB engine. Here programming is done later, not sure if it causes any negative impact.

It seems to say that in a bunch of places, and then contradicts itself
in other places where it says to reprogram the registers from the DSB
commands themselves. A lot of the interesting bits are spread around
on byte boundaries, which implies they are very much meant to be
updated using DSB register writes with byte enables.

Anyways, I've not observed any behavioural differences when updating
this stuff before/after the DSB enable bit has been set. And IIRC some
DSB registers even stop working when the DSB is disabled (might have
been the head/tail pointers at least, not sure about the rest).
I do know DSB_PMCTRL_2 at least is accesible when the DSB is not
enabled, so technically we could reoder some of this at least. But
we'd need to double check the behaviour of each register to be sure
that it still works.

-- 
Ville Syrjälä
Intel