From: Paulo Zanoni <paulo.r.zanoni@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/8] drm/i915/skl+: Remove data_rate from watermark struct.
Date: Thu, 20 Oct 2016 15:20:40 -0200 [thread overview]
Message-ID: <1476984040.2597.37.camel@intel.com> (raw)
In-Reply-To: <1476983888.2597.36.camel@intel.com>
Em Qui, 2016-10-20 às 15:18 -0200, Paulo Zanoni escreveu:
> Em Qua, 2016-10-19 às 15:13 -0700, Matt Roper escreveu:
> >
> > On Wed, Oct 12, 2016 at 03:28:15PM +0200, Maarten Lankhorst wrote:
> > >
> > >
> > > It's only used in one function, and can be calculated without
> > > caching it
> > > in the global struct by using
> > > drm_atomic_crtc_state_for_each_plane_state.
> > >
> > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.c
> > > om
> > > >
> > > >
> > > ---
> > > drivers/gpu/drm/i915/intel_drv.h | 4 ----
> > > drivers/gpu/drm/i915/intel_pm.c | 44 +++++++++++++++++++-------
> > > --
> > > ------------
> > > 2 files changed, 21 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index bb468c974e14..888054518f3c 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -502,10 +502,6 @@ struct intel_crtc_wm_state {
> > > struct skl_pipe_wm optimal;
> > > struct skl_ddb_entry ddb;
> > >
> > > - /* cached plane data rate */
> > > - unsigned
> > > plane_data_rate[I915_MAX_PLANES];
> > > - unsigned
> > > plane_y_data_rate[I915_MAX_PLANES];
> > > -
> > > /* minimum block allocation */
> > > uint16_t
> > > minimum_blocks[I915_MAX_PLANES];
> > > uint16_t
> > > minimum_y_blocks[I915_MAX_PLANES];
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index b96a899c899d..97b6202c4097 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3236,12 +3236,13 @@ skl_plane_relative_data_rate(const struct
> > > intel_crtc_state *cstate,
> > > * 3 * 4096 * 8192 * 4 < 2^32
> > > */
> > > static unsigned int
> > > -skl_get_total_relative_data_rate(struct intel_crtc_state
> > > *intel_cstate)
> > > +skl_get_total_relative_data_rate(struct intel_crtc_state
> > > *intel_cstate,
> > > + unsigned *plane_data_rate,
> > > + unsigned *plane_y_data_rate)
> > > {
> > > struct drm_crtc_state *cstate = &intel_cstate->base;
> > > struct drm_atomic_state *state = cstate->state;
> > > struct drm_crtc *crtc = cstate->crtc;
> > > - struct drm_device *dev = crtc->dev;
> > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > struct drm_plane *plane;
> > > const struct intel_plane *intel_plane;
> > > @@ -3263,21 +3264,16 @@ skl_get_total_relative_data_rate(struct
> > > intel_crtc_state *intel_cstate)
> > > /* packed/uv */
> > > rate =
> > > skl_plane_relative_data_rate(intel_cstate,
> > > pstate, 0);
> > > - intel_cstate->wm.skl.plane_data_rate[id] = rate;
> > > + plane_data_rate[id] = rate;
> > > +
> > > + total_data_rate += rate;
> > >
> > > /* y-plane */
> > > rate =
> > > skl_plane_relative_data_rate(intel_cstate,
> > > pstate, 1);
> > > - intel_cstate->wm.skl.plane_y_data_rate[id] =
> > > rate;
> > > - }
> > > -
> > > - /* Calculate CRTC's total data rate from cached values
> > > */
> > > - for_each_intel_plane_on_crtc(dev, intel_crtc,
> > > intel_plane)
> > > {
> > > - int id = skl_wm_plane_id(intel_plane);
> > > + plane_y_data_rate[id] = rate;
> > >
> > > - /* packed/uv */
> > > - total_data_rate += intel_cstate-
> > > >
> > > > wm.skl.plane_data_rate[id];
> > > - total_data_rate += intel_cstate-
> > > >
> > > > wm.skl.plane_y_data_rate[id];
> > > + total_data_rate += rate;
> > > }
> > >
> > > return total_data_rate;
> > > @@ -3366,6 +3362,9 @@ skl_allocate_pipe_ddb(struct
> > > intel_crtc_state
> > > *cstate,
> > > int num_active;
> > > int id, i;
> > >
Also obligatory bikeshed to remove the ugly blank line above :)
> > > + unsigned data_rate[I915_MAX_PLANES] = {};
> > > + unsigned y_data_rate[I915_MAX_PLANES] = {};
> > > +
> >
> > Minor nitpick; if you picked a different names here (e.g.,
> > plane_data_rate[]) then you could leave the local variables farther
> > down
> > named 'data_rate' and 'y_data_rate' which would reduce the diff
> > changes
> > and result in a slightly smaller patch.
> >
> > Whether or not you feel like making that change, killing the
> > caching
> > is
> > good so,
> >
> > Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
> >
> >
> > >
> > >
> > > /* Clear the partitioning for disabled planes. */
> > > memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> > > memset(ddb->y_plane[pipe], 0, sizeof(ddb-
> > > >y_plane[pipe]));
> > > @@ -3425,29 +3424,28 @@ skl_allocate_pipe_ddb(struct
> > > intel_crtc_state *cstate,
> > > *
> > > * FIXME: we may not allocate every single block here.
> > > */
> > > - total_data_rate =
> > > skl_get_total_relative_data_rate(cstate);
> > > + total_data_rate =
> > > skl_get_total_relative_data_rate(cstate,
> > > data_rate, y_data_rate);
> > > if (total_data_rate == 0)
> > > return 0;
> > >
> > > start = alloc->start;
> > > - for_each_intel_plane_on_crtc(dev, intel_crtc,
> > > intel_plane)
> > > {
> > > - unsigned int data_rate, y_data_rate;
> > > + for (id = 0; id < I915_MAX_PLANES; id++) {
>
> Can we please use a different kind of iteration? Although this is
> correct today, history shows that the number of planes increases over
> time and the code may suddenly break when if we ever introduce
> PLANE_D.
>
> Perhaps:
> for_each_intel_plane_on_crtc(...) {
> id = skl_wm_plane_id(intel_plane);
> ...
> }
>
> With that fixed (and, in case you want, Matt's suggestion):
> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> >
> > >
> > > + unsigned rate;
> > > uint16_t plane_blocks, y_plane_blocks = 0;
> > > - int id = skl_wm_plane_id(intel_plane);
> > >
> > > - data_rate = cstate->wm.skl.plane_data_rate[id];
> > > + rate = data_rate[id];
> > >
> > > /*
> > > * allocation for (packed formats) or (uv-plane
> > > part of planar format):
> > > * promote the expression to 64 bits to avoid
> > > overflowing, the
> > > - * result is < available as data_rate /
> > > total_data_rate < 1
> > > + * result is < available as rate /
> > > total_data_rate
> > > < 1
> > > */
> > > plane_blocks = minimum[id];
> > > - plane_blocks += div_u64((uint64_t)alloc_size *
> > > data_rate,
> > > + plane_blocks += div_u64((uint64_t)alloc_size *
> > > rate,
> > > total_data_rate);
> > >
> > > /* Leave disabled planes at (0,0) */
> > > - if (data_rate) {
> > > + if (rate) {
> > > ddb->plane[pipe][id].start = start;
> > > ddb->plane[pipe][id].end = start +
> > > plane_blocks;
> > > }
> > > @@ -3457,13 +3455,13 @@ skl_allocate_pipe_ddb(struct
> > > intel_crtc_state *cstate,
> > > /*
> > > * allocation for y_plane part of planar format:
> > > */
> > > - y_data_rate = cstate-
> > > >
> > > > wm.skl.plane_y_data_rate[id];
> > > + rate = y_data_rate[id];
> > >
> > > y_plane_blocks = y_minimum[id];
> > > - y_plane_blocks += div_u64((uint64_t)alloc_size *
> > > y_data_rate,
> > > + y_plane_blocks += div_u64((uint64_t)alloc_size *
> > > rate,
> > > total_data_rate);
> > >
> > > - if (y_data_rate) {
> > > + if (rate) {
> > > ddb->y_plane[pipe][id].start = start;
> > > ddb->y_plane[pipe][id].end = start +
> > > y_plane_blocks;
> > > }
> > > --
> > > 2.7.4
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-10-20 17:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 13:28 [PATCH 0/8] drm/i915/gen9+: Atomic wm fixes Maarten Lankhorst
2016-10-12 13:28 ` [PATCH 1/8] drm/i915/skl+: Prepare for removing data rate from skl watermark state Maarten Lankhorst
2016-10-19 22:13 ` Matt Roper
2016-10-20 8:14 ` Maarten Lankhorst
2016-10-20 13:11 ` Paulo Zanoni
2016-10-24 7:00 ` Maarten Lankhorst
2016-10-12 13:28 ` [PATCH 2/8] drm/i915/skl+: Remove data_rate from watermark struct Maarten Lankhorst
2016-10-19 22:13 ` Matt Roper
2016-10-20 17:18 ` Paulo Zanoni
2016-10-20 17:20 ` Paulo Zanoni [this message]
2016-10-24 7:09 ` Maarten Lankhorst
2016-10-12 13:28 ` [PATCH 3/8] drm/i915/skl+: Remove minimum block allocation from crtc state Maarten Lankhorst
2016-10-19 22:13 ` Matt Roper
2016-10-20 17:24 ` Paulo Zanoni
2016-10-12 13:28 ` [PATCH 4/8] drm/i915/skl+: Clean up minimum allocations Maarten Lankhorst
2016-10-19 22:55 ` Matt Roper
2016-10-20 17:36 ` Paulo Zanoni
2016-10-12 13:28 ` [PATCH 5/8] drm/i915: Add a atomic evasion step to watermark programming Maarten Lankhorst
2016-10-19 23:15 ` Matt Roper
2016-10-19 23:26 ` Matt Roper
2016-10-20 6:05 ` Maarten Lankhorst
2016-10-20 17:51 ` Paulo Zanoni
2016-10-24 7:13 ` Maarten Lankhorst
2016-10-12 13:28 ` [PATCH 6/8] drm/i915/gen9+: Use the watermarks from crtc_state for everything Maarten Lankhorst
2016-10-20 17:55 ` Matt Roper
2016-10-20 17:59 ` Paulo Zanoni
2016-10-12 13:28 ` [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion Maarten Lankhorst
2016-10-12 17:03 ` Lyude
2016-10-12 17:04 ` Lyude
2016-10-12 17:15 ` Lyude
2016-10-13 7:26 ` Maarten Lankhorst
2016-10-20 18:35 ` Matt Roper
2016-10-24 8:59 ` Maarten Lankhorst
2016-10-20 21:57 ` Matt Roper
2016-11-01 8:38 ` Maarten Lankhorst
2016-10-12 13:28 ` [PATCH 8/8] drm/i915/gen9+: Preserve old allocation from crtc_state Maarten Lankhorst
2016-10-20 22:09 ` Matt Roper
2016-10-24 8:49 ` Maarten Lankhorst
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=1476984040.2597.37.camel@intel.com \
--to=paulo.r.zanoni@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.d.roper@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.