From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 3/3] drm/i915: add support for 5/6 data buffer partitioning on Haswell
Date: Fri, 31 May 2013 16:44:28 +0300 [thread overview]
Message-ID: <20130531134428.GU5004@intel.com> (raw)
In-Reply-To: <1370006361-3060-1-git-send-email-przanoni@gmail.com>
On Fri, May 31, 2013 at 10:19:21AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> Now we compute the results for both 1/2 and 5/6 partitioning and then
> use hsw_find_best_result to choose which one to use.
>
> With this patch, Haswell watermarks support should be in good shape.
> The only improvement we're missing is the case where the primary plane
> is disabled: we always assume it's enabled, so we take it into
> consideration when calculating the watermarks.
>
> v2: - Check the latency when finding the best result
>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
> drivers/gpu/drm/i915/intel_pm.c | 64 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 53 insertions(+), 11 deletions(-)
>
>
> I was going to implement Ville's review, but then I realized we don't check
> whether we're using level 4 or level 3, so now instead of assigning "i" we
> assign the latency, which reflects which level we're using.
Makes sense. For pre-HSW I guess the same code would still work. It would just
have the same latency value for both 1/2 and 5/6, so the code would end
up working the same way as v1 did, which is still OK.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 3ff9ff3..a6eae70 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2335,7 +2335,8 @@ hsw_compute_linetime_wm(struct drm_device *dev, struct drm_crtc *crtc)
> static void hsw_compute_wm_parameters(struct drm_device *dev,
> struct hsw_pipe_wm_parameters *params,
> uint32_t *wm,
> - struct hsw_wm_maximums *lp_max_1_2)
> + struct hsw_wm_maximums *lp_max_1_2,
> + struct hsw_wm_maximums *lp_max_5_6)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *crtc;
> @@ -2391,15 +2392,17 @@ static void hsw_compute_wm_parameters(struct drm_device *dev,
> }
>
> if (pipes_active > 1) {
> - lp_max_1_2->pri = sprites_enabled ? 128 : 256;
> - lp_max_1_2->spr = 128;
> - lp_max_1_2->cur = 64;
> + lp_max_1_2->pri = lp_max_5_6->pri = sprites_enabled ? 128 : 256;
> + lp_max_1_2->spr = lp_max_5_6->spr = 128;
> + lp_max_1_2->cur = lp_max_5_6->cur = 64;
> } else {
> lp_max_1_2->pri = sprites_enabled ? 384 : 768;
> + lp_max_5_6->pri = sprites_enabled ? 128 : 768;
> lp_max_1_2->spr = 384;
> - lp_max_1_2->cur = 255;
> + lp_max_5_6->spr = 640;
> + lp_max_1_2->cur = lp_max_5_6->cur = 255;
> }
> - lp_max_1_2->fbc = 15;
> + lp_max_1_2->fbc = lp_max_5_6->fbc = 15;
> }
>
> static void hsw_compute_wm_results(struct drm_device *dev,
> @@ -2458,6 +2461,32 @@ static void hsw_compute_wm_results(struct drm_device *dev,
> }
> }
>
> +/* Find the result with the highest level enabled. Check for enable_fbc_wm in
> + * case both are at the same level. Prefer r1 in case they're the same. */
> +struct hsw_wm_values *hsw_find_best_result(struct hsw_wm_values *r1,
> + struct hsw_wm_values *r2)
> +{
> + int i, val_r1 = 0, val_r2 = 0;
> +
> + for (i = 0; i < 3; i++) {
> + if (r1->wm_lp[i] & WM3_LP_EN)
> + val_r1 = r1->wm_lp[i] & WM1_LP_LATENCY_MASK;
> + if (r2->wm_lp[i] & WM3_LP_EN)
> + val_r2 = r2->wm_lp[i] & WM1_LP_LATENCY_MASK;
> + }
> +
> + if (val_r1 == val_r2) {
> + if (r2->enable_fbc_wm && !r1->enable_fbc_wm)
> + return r2;
> + else
> + return r1;
> + } else if (val_r1 > val_r2) {
> + return r1;
> + } else {
> + return r2;
> + }
> +}
> +
> /*
> * The spec says we shouldn't write when we don't need, because every write
> * causes WMs to be re-evaluated, expending some power.
> @@ -2558,14 +2587,27 @@ static void hsw_write_wm_values(struct drm_i915_private *dev_priv,
> static void haswell_update_wm(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - struct hsw_wm_maximums lp_max_1_2;
> + struct hsw_wm_maximums lp_max_1_2, lp_max_5_6;
> struct hsw_pipe_wm_parameters params[3];
> - struct hsw_wm_values results;
> + struct hsw_wm_values results_1_2, results_5_6, *best_results;
> uint32_t wm[5];
> + enum hsw_data_buf_partitioning partitioning;
> +
> + hsw_compute_wm_parameters(dev, params, wm, &lp_max_1_2, &lp_max_5_6);
> +
> + hsw_compute_wm_results(dev, params, wm, &lp_max_1_2, &results_1_2);
> + if (lp_max_1_2.pri != lp_max_5_6.pri) {
> + hsw_compute_wm_results(dev, params, wm, &lp_max_5_6,
> + &results_5_6);
> + best_results = hsw_find_best_result(&results_1_2, &results_5_6);
> + } else {
> + best_results = &results_1_2;
> + }
> +
> + partitioning = (best_results == &results_1_2) ?
> + HSW_DATA_BUF_PART_1_2 : HSW_DATA_BUF_PART_5_6;
>
> - hsw_compute_wm_parameters(dev, params, wm, &lp_max_1_2);
> - hsw_compute_wm_results(dev, params, wm, &lp_max_1_2, &results);
> - hsw_write_wm_values(dev_priv, &results, HSW_DATA_BUF_PART_1_2);
> + hsw_write_wm_values(dev_priv, best_results, partitioning);
> }
>
> static void haswell_update_sprite_wm(struct drm_device *dev, int pipe,
> --
> 1.8.1.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-05-31 13:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 14:59 [PATCH 0/5] Haswell watermarks Paulo Zanoni
2013-05-24 14:59 ` [PATCH 1/5] drm/i915: add "enable" argument to intel_update_sprite_watermarks Paulo Zanoni
2013-05-24 16:22 ` Ville Syrjälä
2013-05-24 14:59 ` [PATCH 2/5] drm/i915: add haswell_update_sprite_wm Paulo Zanoni
2013-05-24 17:00 ` Ville Syrjälä
2013-05-24 19:35 ` Daniel Vetter
2013-05-24 14:59 ` [PATCH 3/5] drm/i915: properly set HSW WM_PIPE registers Paulo Zanoni
2013-05-24 16:07 ` Ville Syrjälä
2013-05-24 22:00 ` Paulo Zanoni
2013-05-24 22:02 ` Paulo Zanoni
2013-05-27 11:07 ` Ville Syrjälä
2013-05-27 19:21 ` Paulo Zanoni
2013-05-29 15:39 ` Ville Syrjälä
2013-05-31 13:08 ` [PATCH 1/3] " Paulo Zanoni
2013-05-31 15:03 ` Ville Syrjälä
2013-05-24 14:59 ` [PATCH 4/5] drm/i915: properly set HSW WM_LP watermarks Paulo Zanoni
2013-05-24 16:11 ` Ville Syrjälä
2013-05-24 22:05 ` Paulo Zanoni
2013-05-29 16:06 ` Ville Syrjälä
2013-05-29 16:24 ` Ville Syrjälä
2013-05-31 13:12 ` [PATCH 2/3] " Paulo Zanoni
2013-05-31 13:58 ` Ville Syrjälä
2013-05-31 14:45 ` Paulo Zanoni
2013-05-31 15:05 ` Ville Syrjälä
2013-05-24 14:59 ` [PATCH 5/5] drm/i915: add support for 5/6 data buffer partitioning on Haswell Paulo Zanoni
2013-05-29 16:17 ` Ville Syrjälä
2013-05-31 13:19 ` [PATCH 3/3] " Paulo Zanoni
2013-05-31 13:44 ` Ville Syrjälä [this message]
2013-05-31 15:19 ` Daniel Vetter
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=20130531134428.GU5004@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=przanoni@gmail.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.