| Message ID | 20250216200906.266532-1-vinod.govindapillai@intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | drm/i915/fbc: FBC Dirty rect feature support | expand |
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@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); > + > fbc_state->plane = plane; > > /* FBC1 compression interval: arbitrary choice of 1 second */
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@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 */ >
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); + fbc_state->plane = plane; /* FBC1 compression interval: arbitrary choice of 1 second */
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@intel.com> --- drivers/gpu/drm/i915/display/intel_fbc.c | 9 +++++++++ 1 file changed, 9 insertions(+)