From: Paulo Zanoni <paulo.r.zanoni@intel.com>
To: Mahesh Kumar <mahesh1.kumar@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 8/9] drm/i915/bxt: set chicken bit as IPC y-tile WA
Date: Thu, 22 Sep 2016 08:53:04 -0300 [thread overview]
Message-ID: <1474545184.2593.62.camel@intel.com> (raw)
In-Reply-To: <5b04cb36-c9a0-7d84-a8c7-51a9aa368073@intel.com>
Em Qui, 2016-09-22 às 15:13 +0530, Mahesh Kumar escreveu:
> Hi,
>
>
> On Thursday 22 September 2016 01:53 AM, Paulo Zanoni wrote:
> >
> > Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu:
> > >
> > > From: Mahesh Kumar <mahesh1.kumar@intel.com>
> > >
> > > It implements the WA to enable IDLE_WAKEMEM bit of CHICKEN_DCPR_1
> > > register for Broxton platform. When IPC is enabled & Y-tile is
> > > enabled in any of the enabled plane, above bit should be set.
> > > Without this WA system observes random hang.
> > The previous patch enabled the feature, and now this patch
> > implements a
> > missing workaround for the feature. This is not the appropriate
> > order,
> > since it can mean that the previous patch introduced a bug that was
> > fixed by this patch, and this potentially breaks bisectability. We
> > only
> > enable the feature once we know all its workarounds are enabled and
> > the
> > feature will Just Work*. So, normally, my suggestion would be to
> > either
> > invert the patch order, or just make patches 7 and 8 be a single
> > patch.
> I can invert the order of patches, If below point seems OK.
> >
> >
> > But we have another problem, please see
> > commit 590e8ff04bc0182dce97228e5e352d6413d80456. What's the problem
> > with the current implementation? Why can't we just keep the bit as
> > 1
> > forever?
> mentioned commit is making IDLE_WAKEMEM bit always 1b (masking), but
> it
> is require only in case of y/yf tiling.
> need to check for consequences in keeping this bit always Masked.
> what is your opinion on this? Should not we implement it only in case
> of
> y/yf tiling, when we can do it in our framework?
If there are no bad consequences for keeping the bit as 1 even when
we're not using y/yf tiling, then the simpler solution wins IMHO.
>
> Regards,
> -Mahesh
> >
> >
> >
> > >
> > > Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > > drivers/gpu/drm/i915/i915_reg.h | 3 +++
> > > drivers/gpu/drm/i915/intel_display.c | 50
> > > ++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 55 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 4737a0e..79b9305 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1632,6 +1632,8 @@ struct skl_wm_values {
> > > unsigned dirty_pipes;
> > > /* any WaterMark memory workaround Required */
> > > enum watermark_memory_wa mem_wa;
> > > + /* IPC Y-tiled WA related member */
> > > + u32 y_plane_mask;
> > > struct skl_ddb_allocation ddb;
> > > uint32_t wm_linetime[I915_MAX_PIPES];
> > > uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 75b5b52..210d9b0 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5658,6 +5658,9 @@ enum {
> > > #define PLANE_NV12_BUF_CFG(pipe, plane) \
> > > _MMIO_PLANE(plane, _PLANE_NV12_BUF_CFG_1(pipe),
> > > _PLANE_NV12_BUF_CFG_2(pipe))
> > >
> > > +#define CHICKEN_DCPR_1 _MMIO(0x46430)
> > > +#define IDLE_WAKEMEM_MASK (1 << 13)
> > > +
> > > /* SKL new cursor registers */
> > > #define _CUR_BUF_CFG_A 0x7017c
> > > #define _CUR_BUF_CFG_B 0x7117c
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 5f50f53..ee7f88e 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -12415,6 +12415,8 @@ int
> > > intel_plane_atomic_calc_changes(struct
> > > drm_crtc_state *crtc_state,
> > > bool is_crtc_enabled = crtc_state->active;
> > > bool turn_off, turn_on, visible, was_visible;
> > > struct drm_framebuffer *fb = plane_state->fb;
> > > + struct intel_atomic_state *intel_state =
> > > + to_intel_atomic_state(plane_stat
> > > e-
> > > >
> > > > state);
> > > int ret;
> > >
> > > if (INTEL_GEN(dev) >= 9 && plane->type !=
> > > DRM_PLANE_TYPE_CURSOR) {
> > > @@ -12501,6 +12503,15 @@ int
> > > intel_plane_atomic_calc_changes(struct
> > > drm_crtc_state *crtc_state,
> > > !needs_scaling(old_plane_state))
> > > pipe_config->disable_lp_wm = true;
> > >
> > > + if (fb && (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > > + fb->modifier[0] ==
> > > I915_FORMAT_MOD_Yf_TILED)) {
> > > + intel_state->wm_results.y_plane_mask |=
> > > + (1 <<
> > > drm_plane_index(plane));
> > > + } else {
> > > + intel_state->wm_results.y_plane_mask &=
> > > + ~(1 <<
> > > drm_plane_index(plane));
> > > + }
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -13963,6 +13974,10 @@ static int intel_atomic_check(struct
> > > drm_device *dev,
> > > if (ret)
> > > return ret;
> > >
> > > + /* Copy the Y-tile WA related states */
> > > + intel_state->wm_results.y_plane_mask =
> > > + dev_priv-
> > > >
> > > > wm.skl_results.y_plane_mask;
> > > +
> > > for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > struct intel_crtc_state *pipe_config =
> > > to_intel_crtc_state(crtc_state);
> > > @@ -14204,6 +14219,32 @@ static void intel_update_crtcs(struct
> > > drm_atomic_state *state,
> > > }
> > > }
> > >
> > > +/*
> > > + * GEN9 IPC WA for Y-tiled
> > > + */
> > > +void bxt_set_ipc_wa(struct drm_i915_private *dev_priv, bool
> > > enable)
> > > +{
> > > + u32 val;
> > > +
> > > + if (!IS_BROXTON(dev_priv) || !i915.enable_ipc)
> > > + return;
> > > +
> > > + val = I915_READ(CHICKEN_DCPR_1);
> > > + /*
> > > + * If WA is already enabled or disabled
> > > + * no need to re-enable or disable it.
> > > + */
> > > + if ((enable && (val & IDLE_WAKEMEM_MASK)) ||
> > > + (!enable && !(val & IDLE_WAKEMEM_MASK)))
> > > + return;
> > > +
> > > + if (enable)
> > > + val |= IDLE_WAKEMEM_MASK;
> > > + else
> > > + val &= ~IDLE_WAKEMEM_MASK;
> > > + I915_WRITE(CHICKEN_DCPR_1, val);
> > > +}
> > > +
> > > static void skl_update_crtcs(struct drm_atomic_state *state,
> > > unsigned int *crtc_vblank_mask)
> > > {
> > > @@ -14219,6 +14260,12 @@ static void skl_update_crtcs(struct
> > > drm_atomic_state *state,
> > > enum pipe pipe;
> > >
> > > /*
> > > + * If IPC WA need to be enabled, enable it now
> > > + */
> > > + if (intel_state->wm_results.y_plane_mask)
> > > + bxt_set_ipc_wa(dev_priv, true);
> > > +
> > > + /*
> > > * Whenever the number of active pipes changes, we need
> > > to
> > > make sure we
> > > * update the pipes in the right order so that their
> > > ddb
> > > allocations
> > > * never overlap with eachother inbetween CRTC updates.
> > > Otherwise we'll
> > > @@ -14261,6 +14308,9 @@ static void skl_update_crtcs(struct
> > > drm_atomic_state *state,
> > > progress = true;
> > > }
> > > } while (progress);
> > > +
> > > + if (!intel_state->wm_results.y_plane_mask)
> > > + bxt_set_ipc_wa(dev_priv, false);
> > > }
> > >
> > > static void intel_atomic_commit_tail(struct drm_atomic_state
> > > *state)
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-09-22 13:17 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 8:00 [PATCH v3 0/9] New DDB Algo and WM fixes Kumar, Mahesh
2016-09-09 8:00 ` [PATCH v3 1/9] drm/i915/skl: pass pipe_wm in skl_compute_(wm_level/plane_wm) functions Kumar, Mahesh
2016-09-20 12:17 ` Paulo Zanoni
2016-09-21 13:48 ` Mahesh Kumar
2016-09-21 13:59 ` Paulo Zanoni
2016-09-09 8:00 ` [PATCH v3 2/9] drm/i915/skl+: use linetime latency instead of ddb size Kumar, Mahesh
2016-09-12 8:56 ` Maarten Lankhorst
2016-09-19 18:19 ` Paulo Zanoni
2016-09-19 18:24 ` Zanoni, Paulo R
2016-09-22 8:02 ` Mahesh Kumar
2016-09-09 8:01 ` [PATCH v3 3/9] drm/i915/skl: New ddb allocation algorithm Kumar, Mahesh
2016-09-12 10:50 ` Maarten Lankhorst
2016-09-12 13:11 ` Maarten Lankhorst
2016-09-13 6:21 ` Mahesh Kumar
2016-09-13 12:15 ` [PATCH v4] " Kumar, Mahesh
2016-09-13 12:40 ` Maarten Lankhorst
2016-09-14 12:36 ` Mahesh Kumar
2016-09-19 8:27 ` Maarten Lankhorst
2016-09-19 9:55 ` Maarten Lankhorst
2016-09-21 13:03 ` Mahesh Kumar
2016-09-09 8:01 ` [PATCH v3 4/9] drm/i915: Decode system memory bandwidth Kumar, Mahesh
2016-09-16 8:02 ` Pandiyan, Dhinakaran
2016-09-16 11:35 ` Mahesh Kumar
2016-09-19 20:41 ` Paulo Zanoni
2016-09-09 8:01 ` [PATCH v3 5/9] drm/i915/gen9: WM memory bandwidth related workaround Kumar, Mahesh
2016-09-12 11:02 ` Maarten Lankhorst
2016-09-12 11:12 ` Maarten Lankhorst
2016-09-09 8:01 ` [PATCH v3 6/9] drm/i915/skl+: change WM calc to fixed point 16.16 Kumar, Mahesh
2016-09-21 18:32 ` Paulo Zanoni
2016-09-22 9:25 ` Mahesh Kumar
2016-09-09 8:01 ` [PATCH v3 7/9] drm/i915/bxt: Enable IPC support Kumar, Mahesh
2016-09-21 20:06 ` Paulo Zanoni
2016-09-22 10:14 ` Mahesh Kumar
2016-09-09 8:01 ` [PATCH v3 8/9] drm/i915/bxt: set chicken bit as IPC y-tile WA Kumar, Mahesh
2016-09-21 20:23 ` Paulo Zanoni
2016-09-22 9:43 ` Mahesh Kumar
2016-09-22 11:53 ` Paulo Zanoni [this message]
2016-09-09 8:01 ` [PATCH v3 9/9] drm/i915/bxt: Implement Transition WM Kumar, Mahesh
2016-09-14 11:54 ` [PATCH v4] " Kumar, Mahesh
2016-09-21 20:27 ` Paulo Zanoni
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=1474545184.2593.62.camel@intel.com \
--to=paulo.r.zanoni@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mahesh1.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).