[PATCH v1 8/8] drm/i915/fbc: handle dirty rect coords for the first frame

[Ville Syrjälä]

On Sun, Feb 16, 2025 at 08:16:44PM +0000, Govindapillai, Vinod wrote:
> Hi Ville,
> 
> During some testing I noticed that for the very first frame while enabling we wouldnt have executed
> the intel_fbc_prepare_dirty_rect() as fbc_state->plane will be NULL. So we will end-up programming
> wrong values for the first frame. And for the very first frame after the boot it will be completely
> bogus! Added this patch to the list and if you could Ack this, then I can squash this patch to the
> fbc dirty rect patch (patch 6) in the list
> 
> Br
> Vinod
> 
> 
> On Sun, 2025-02-16 at 22:09 +0200, Vinod Govindapillai wrote:
> > During enablig FBC, for the very first frame, the prepare dirty
> > rect routine wouldnt have executed as at that time the plane
> > reference in the fbc_state would be NULL. So this could make
> > driver program some invalid entries as the damage area. Though
> > fbc hw ignores the dirty rect values programmed for the first
> > frame after enabling FBC, driver must ensure that valid dirty
> > rect coords are programmed. So ensure that for the first frame
> > prepare dirty rect is called at the time enabling FBC.
> > 
> > Signed-off-by: Vinod Govindapillai <vinod.govindapillai at intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_fbc.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 6222eea4b1ce..21fd57c7f163 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -1230,6 +1230,8 @@ intel_fbc_dirty_rect_update(struct intel_dsb *dsb, struct intel_fbc *fbc)
> >  
> >  	lockdep_assert_held(&fbc->lock);
> >  
> > +	drm_WARN_ON(display->drm, fbc_dirty_rect->y2 == 0);
> > +
> >  	intel_de_write_dsb(display, dsb, XE3_FBC_DIRTY_RECT(fbc->id),
> >  			   FBC_DIRTY_RECT_START_LINE(fbc_dirty_rect->y1) |
> >  			   FBC_DIRTY_RECT_END_LINE(fbc_dirty_rect->y2 - 1));
> > @@ -1313,6 +1315,13 @@ static void intel_fbc_update_state(struct intel_atomic_state *state,
> >  	WARN_ON(plane_state->no_fbc_reason);
> >  	WARN_ON(fbc_state->plane && fbc_state->plane != plane);
> >  
> > +	/*
> > +	 * For the very first frame while enabling FBC, ensure that we have a
> > +	 * valid dirty rect coords.
> > +	 */
> > +	if (HAS_FBC_DIRTY_RECT(display) && !fbc_state->plane)
> > +		__intel_fbc_prepare_dirty_rect(plane_state);

I don't think this will do quite the right thing when
using the DSB for the commit.

I think to make it more correct we'd have to do somethig like this
perhaps:
- invalidate fbc_state->dirty rect in intel_fbc_prepare_dirty_rect()
  if we are going to call __intel_fbc_disable() later, which
  I think would happen for
  'crtc_needs_modeset() || !intel_fbc_is_ok()'
- probably invalidate fbc_state->dirty_rect in
  __intel_fbc_disable() as well for good measure (in case we call
  it outside the normal commit path, ie. due to underruns).
- program some kind of valid dirty rectangle directly from
  __intel_fbc_enable()
- skip the dirty rectangle programming in
  intel_fbc_dirty_rect_update_noarm() if the dirty rectangle
  is invalid

That way we reprogram the dirty rect from noarm only if FBC
is guaranteed to stay on its current plane, and we should
end up programming it the same way regardless of whether we
use DSB or MMIO for the commit.

> > +
> >  	fbc_state->plane = plane;
> >  
> >  	/* FBC1 compression interval: arbitrary choice of 1 second */
> 

-- 
Ville Syrjälä
Intel