On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Even if we're not doing downscaling we should account for > some of the extra dotclock limitations for g4x+ sprites. In > particular we must never exceed the 90% rule, and with RGB > that limits actually drops to 80%. > > So instead of bailing out when upscaling let's clamp the > scaling factor appropriately and go through the rest of > calculation normally. By luck we already did the full > calculations for the 1:1 case. > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c > index 7abeefe8dce5..6e2e22d9bbaa 100644 > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > @@ -1611,8 +1611,7 @@ static int g4x_sprite_min_cdclk(const struct intel_crtc_state *crtc_state, > hscale = drm_rect_calc_hscale(&plane_state->uapi.src, > &plane_state->uapi.dst, > 0, INT_MAX); > - if (hscale < 0x10000) > - return pixel_rate; > + hscale = max(hscale, 0x10000u); It bugs me that drm_rect seems to be used for both integer and 16.16 fixed point and whatnot. It also gives me an uneasy feeling that hscale is uint while drm_rect_calc_hscale() may return -ERANGE... but I guess shouldn't happen. All in all, Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> > > /* Decimation steps at 2x,4x,8x,16x */ > decimate = ilog2(hscale >> 16); -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
