All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Shobhit Kumar <shobhit.kumar@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/7] drm/i915/skl+: Use fb size for relative data rate calculation
Date: Thu, 14 Jan 2016 16:16:45 -0800	[thread overview]
Message-ID: <20160115001645.GB13799@intel.com> (raw)
In-Reply-To: <1452772968-24772-3-git-send-email-shobhit.kumar@intel.com>

On Thu, Jan 14, 2016 at 05:32:43PM +0530, Shobhit Kumar wrote:
> From: "Kumar, Mahesh" <mahesh1.kumar@intel.com>
> 
> Use FB size for relative data rate calculation. don't always use

Minor wording nitpick:  it's not really the FB size you're using here
but rather the plane size.  The FB itself may be larger than the plane
and largely offscreen.

> pipe source width & height.
> adjust height & width according to rotation.
> 
> Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 42 ++++++++++++++++++++++++++++++++---------
>  1 file changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 68f21b9..d33c4ff 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2928,24 +2928,33 @@ skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
>  			     int y)
>  {
>  	struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
> +	struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
>  	struct drm_framebuffer *fb = pstate->fb;
> +	uint32_t width = 0, height = 0;
> +
> +	if (drm_rect_width(&intel_pstate->src)) {
> +		width = drm_rect_width(&intel_pstate->src) >> 16;
> +		height = drm_rect_height(&intel_pstate->src) >> 16;
> +	} else {
> +		width = intel_crtc->config->pipe_src_w;
> +		height = intel_crtc->config->pipe_src_h;

The else block would mean the plane is invisible (either off or fully
clipped), right?  Shouldn't our relative data rate be 0 in that case
(instead of max possible)?


> +	}
> +
> +	if (intel_rotation_90_or_270(pstate->rotation))
> +		swap(width, height);
>  
>  	/* for planar format */
>  	if (fb->pixel_format == DRM_FORMAT_NV12) {
>  		if (y)  /* y-plane data rate */
> -			return intel_crtc->config->pipe_src_w *
> -				intel_crtc->config->pipe_src_h *
> +			return width * height *
>  				drm_format_plane_cpp(fb->pixel_format, 0);
>  		else    /* uv-plane data rate */
> -			return (intel_crtc->config->pipe_src_w/2) *
> -				(intel_crtc->config->pipe_src_h/2) *
> +			return (width / 2) * (height / 2) *
>  				drm_format_plane_cpp(fb->pixel_format, 1);
>  	}
>  
>  	/* for packed formats */
> -	return intel_crtc->config->pipe_src_w *
> -		intel_crtc->config->pipe_src_h *
> -		drm_format_plane_cpp(fb->pixel_format, 0);
> +	return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
>  }
>  
>  /*
> @@ -3181,10 +3190,25 @@ static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
>  	uint32_t res_blocks, res_lines;
>  	uint32_t selected_result;
>  	uint8_t bytes_per_pixel;
> +	struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
> +	struct intel_plane_state *intel_pstate = to_intel_plane_state(plane->state);
> +	uint32_t width = 0, height = 0;
>  
>  	if (latency == 0 || !cstate->base.active || !fb)
>  		return false;
>  
> +	if (drm_rect_width(&intel_pstate->src)) {
> +		width = drm_rect_width(&intel_pstate->src) >> 16;
> +		height = drm_rect_height(&intel_pstate->src) >> 16;
> +	} else {
> +		width = intel_crtc->config->pipe_src_w;
> +		height = intel_crtc->config->pipe_src_h;
> +	}

We're already bailing above this on !fb; shouldn't we do the same on a
plane that has a valid fb but is disabled due to being fully clipped
(which I think is the only thing that will trigger the else block here)?


Matt

> +
> +	if (intel_rotation_90_or_270(plane->state->rotation))
> +		swap(width, height);
> +
> +	/* for planar format */
>  	bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ?
>  				drm_format_plane_cpp(fb->pixel_format, 1) :
>  				drm_format_plane_cpp(fb->pixel_format, 0);
> @@ -3193,12 +3217,12 @@ static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
>  				 latency);
>  	method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
>  				 cstate->base.adjusted_mode.crtc_htotal,
> -				 cstate->pipe_src_w,
> +				 width,
>  				 bytes_per_pixel,
>  				 fb->modifier[0],
>  				 latency);
>  
> -	plane_bytes_per_line = cstate->pipe_src_w * bytes_per_pixel;
> +	plane_bytes_per_line = width * bytes_per_pixel;
>  	plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
>  
>  	if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> -- 
> 2.4.3
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-01-15  0:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 12:02 [PATCH 0/7] Misc WM fixes and Arbitrated Display Bandwidth WA for SKL Shobhit Kumar
2016-01-14 12:02 ` [PATCH 1/7] drm/i915/skl+: Use proper bytes_per_pixel during WM calculation Shobhit Kumar
2016-01-14 19:07   ` Matt Roper
2016-01-19  9:56     ` Kumar, Shobhit
2016-01-14 12:02 ` [PATCH 2/7] drm/i915/skl+: Use fb size for relative data rate calculation Shobhit Kumar
2016-01-15  0:16   ` Matt Roper [this message]
2016-01-14 12:02 ` [PATCH 3/7] drm/i915/skl+: calculate ddb minimum allocation Shobhit Kumar
2016-01-15  0:39   ` Matt Roper
2016-01-14 12:02 ` [PATCH 4/7] drm/i915/skl+: calculate plane pixel rate Shobhit Kumar
2016-01-15  0:57   ` Matt Roper
2016-01-14 12:02 ` [PATCH 5/7] drm/i915/skl+: Use scaling amount for plane data rate calculation Shobhit Kumar
2016-01-15  1:15   ` Matt Roper
2016-01-14 12:02 ` [PATCH 6/7] drm/i915: Add support to parse DMI table and get platform memory info Shobhit Kumar
2016-01-15  1:44   ` Matt Roper
2016-01-27 16:04     ` Kumar, Shobhit
2016-01-14 12:02 ` [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW Shobhit Kumar
2016-01-14 15:30   ` kbuild test robot
2016-01-14 17:35     ` Damien Lespiau
2016-01-14 17:25   ` kbuild test robot
2016-01-14 13:20 ` ✗ warning: Fi.CI.BAT Patchwork
2016-01-15  1:48 ` [PATCH 0/7] Misc WM fixes and Arbitrated Display Bandwidth WA for SKL Matt Roper
2016-01-15  5:02   ` Kumar, Shobhit
2016-01-25  4:48     ` Shobhit Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160115001645.GB13799@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=shobhit.kumar@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.