diff mbox series

[1/2] drm/i915: Fix g4x+ sprite dotclock limit for upscaling

Message ID 20200206201204.31704-1-ville.syrjala@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series [1/2] drm/i915: Fix g4x+ sprite dotclock limit for upscaling | expand

Commit Message

Ville Syrjala Feb. 6, 2020, 8:12 p.m. UTC
From: Ville Syrjälä <ville.syrjala@linux.intel.com>

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@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_sprite.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

Jani Nikula Sept. 11, 2020, 6:03 p.m. UTC | #1
On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> 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@linux.intel.com>
> ---
>  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@intel.com>


>  
>  	/* Decimation steps at 2x,4x,8x,16x */
>  	decimate = ilog2(hscale >> 16);
Ville Syrjala Sept. 14, 2020, 1:48 p.m. UTC | #2
On Fri, Sep 11, 2020 at 09:03:36PM +0300, Jani Nikula wrote:
> On Thu, 06 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > 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@linux.intel.com>
> > ---
> >  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.

In theory it can use any arbitrary precision. There are a few
functions which do assume .0 or .16 though.

> 
> 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.

Yeah, should not happen since we've already done this
same calculation (+check for <0) earlier. I've occasionally
pondered about stashing the h/vscale from that first check
into the plane state so we wouldn't have to redo it here.
But I never found sufficient motivation to actually do it.

> 
> All in all,
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Ta.

> 
> 
> >  
> >  	/* Decimation steps at 2x,4x,8x,16x */
> >  	decimate = ilog2(hscale >> 16);
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
diff mbox series

Patch

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);
 
 	/* Decimation steps at 2x,4x,8x,16x */
 	decimate = ilog2(hscale >> 16);