From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/8] drm/i915/skl: Move the per-latency maximum test earlier
Date: Wed, 29 Oct 2014 18:53:34 +0200 [thread overview]
Message-ID: <20141029165334.GB10649@intel.com> (raw)
In-Reply-To: <1413304266-32127-4-git-send-email-damien.lespiau@intel.com>
On Tue, Oct 14, 2014 at 05:31:01PM +0100, Damien Lespiau wrote:
> To align with the ilk WM code and because it makes sense to test against
> the upper bounds as soon as possible, let's move the maximum checks from
> skl_compute_wm_results() to skl_compute_plane_wm().
>
> This has the nice benefit to be done in come common plane code and so
> remove the duplication we had between the regular planes and the cursor.
>
> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
> ---
> drivers/gpu/drm/i915/intel_pm.c | 14 +++-----------
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 475a3d4..65df074 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3361,6 +3361,9 @@ static bool skl_compute_plane_wm(struct skl_pipe_wm_parameters *p,
> *res_blocks = DIV_ROUND_UP(result_bytes, 512) + 1;
> *res_lines = DIV_ROUND_UP(result_bytes, plane_bytes_per_line);
>
> + if (*res_blocks > ddb_allocation || *res_lines > 31)
> + return false;
> +
Unless I completely misread things we would still stick the computed *res
values into the register which still risks an overflow there. The ILK
code leaves the enrtire wm struct zeroed if any value can't fit in the
register (well apart from fbc_wm which is handled in a special way).
My impression is that we could just zero the values here any time we see
that they might exceed the limits. And I think we don't especially have
to care about the register max vs. current ddb allocation max
distinction on SKL like we do on ILK. Although if we did make that
distinction, and I've not thought it really though yet, maybe we can
skip recomputing some plane watermarks when the only thing changing for
the plane is the DDB allocation. We'd just have to re-evaluate the state
of the wm level enable bit when we're about to blast the watermarks into
the register. But maybe that would just complicate the code too much. I
guess it's better left as a potential future optimization.
> return true;
> }
>
> @@ -3422,17 +3425,11 @@ static void skl_compute_wm_results(struct drm_device *dev,
> enum pipe pipe = intel_crtc->pipe;
>
> for (level = 0; level <= max_level; level++) {
> - uint16_t ddb_blocks;
> uint32_t temp;
> int i;
>
> for (i = 0; i < intel_num_planes(intel_crtc); i++) {
> temp = 0;
> - ddb_blocks = skl_ddb_entry_size(&r->ddb.plane[pipe][i]);
> -
> - if ((p_wm->wm[level].plane_res_b[i] > ddb_blocks) ||
> - (p_wm->wm[level].plane_res_l[i] > 31))
> - p_wm->wm[level].plane_en[i] = false;
>
> temp |= p_wm->wm[level].plane_res_l[i] <<
> PLANE_WM_LINES_SHIFT;
> @@ -3447,11 +3444,6 @@ static void skl_compute_wm_results(struct drm_device *dev,
> }
>
> temp = 0;
> - ddb_blocks = skl_ddb_entry_size(&r->ddb.cursor[pipe]);
> -
> - if ((p_wm->wm[level].cursor_res_b > ddb_blocks) ||
> - (p_wm->wm[level].cursor_res_l > 31))
> - p_wm->wm[level].cursor_en = false;
>
> temp |= p_wm->wm[level].cursor_res_l << PLANE_WM_LINES_SHIFT;
> temp |= p_wm->wm[level].cursor_res_b;
> --
> 1.8.3.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-10-29 16:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 16:30 [PATCH 0/8] SKL WM fixups Damien Lespiau
2014-10-14 16:30 ` [PATCH 1/8] drm/i915/skl: Make 'end' of the DDB allocation entry exclusive Damien Lespiau
2014-10-29 15:32 ` Ville Syrjälä
2014-10-14 16:31 ` [PATCH 2/8] drm/i915/skl: Use a more descriptive parameter name in skl_compute_plane_wm() Damien Lespiau
2014-10-14 16:31 ` [PATCH 3/8] drm/i915/skl: Move the per-latency maximum test earlier Damien Lespiau
2014-10-29 16:53 ` Ville Syrjälä [this message]
2014-11-03 14:26 ` [PATCH 1/8 v2] drm/i915/skl: Make 'end' of the DDB allocation entry exclusive Damien Lespiau
2014-11-03 15:21 ` [PATCH 3/8 v2] drm/i915/skl: Make res_blocks/lines intermediate values 32 bits Damien Lespiau
2014-10-14 16:31 ` [PATCH 4/8] drm/i915/skl: Reduce the number of holes in struct skl_wm_level Damien Lespiau
2014-10-14 16:31 ` [PATCH 5/8] drm/i915/skl: Move all the WM compute functions in one place Damien Lespiau
2014-10-14 16:31 ` [PATCH 6/8] drm/i915/skl: Rework when the transition WMs are computed Damien Lespiau
2014-10-14 16:31 ` [PATCH 7/8] drm/i915/skl: Correctly align skl_compute_plane_wm() arguments Damien Lespiau
2014-10-14 16:31 ` [PATCH 8/8] drm/i915/skl: Reduce the indentation level in skl_write_wm_values() Damien Lespiau
2014-10-29 17:22 ` [PATCH 0/8] SKL WM fixups Ville Syrjälä
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=20141029165334.GB10649@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=damien.lespiau@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox