From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
intel-gfx@lists.freedesktop.org,
Paulo Zanoni <paulo.r.zanoni@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH v4] drm/i915: Enable edp psr error interrupts on hsw
Date: Fri, 20 Apr 2018 15:22:37 -0700 [thread overview]
Message-ID: <20180420222237.GO1310@intel.com> (raw)
In-Reply-To: <1523995299.24522.6.camel@dk-H97M-D3H>
On Tue, Apr 17, 2018 at 01:01:39PM -0700, Dhinakaran Pandiyan wrote:
>
>
>
> On Tue, 2018-04-17 at 20:41 +0300, Ville Syrjälä wrote:
> > On Mon, Apr 16, 2018 at 05:43:54PM -0700, Paulo Zanoni wrote:
> > > Em Qui, 2018-04-05 às 15:00 -0700, Dhinakaran Pandiyan escreveu:
> > > > From: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > >
> > > > The definitions for the error register should be valid on bdw/skl
> > > > too,
> > > > but there we haven't even enabled DE_MISC handling yet.
> > > >
> > > > Somewhat confusing the the moved register offset on bdw is only for
> > > > the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> > > > on bdw.
> > > >
> > > > v2: Fixes from Ville.
> > > >
> > > > v3: From DK
> > > > * Rebased on drm-tip
> > > > * Removed BDW IIR bit definition, looks like an unintentional change
> > > > that
> > > > should be in the following patch.
> > > >
> > > > v4: From DK
> > > > * Don't mask REG_WRITE.
> > > >
> > > > References: bspec/11974 [SRD Interrupt Bit Definition DevHSW]
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/i915_irq.c | 34
> > > > ++++++++++++++++++++++++++++++++++
> > > > drivers/gpu/drm/i915/i915_reg.h | 8 ++++++++
> > > > 2 files changed, 42 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 27aee25429b7..c2d3f30778ee 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -2391,6 +2391,26 @@ static void ilk_display_irq_handler(struct
> > > > drm_i915_private *dev_priv,
> > > > ironlake_rps_change_irq_handler(dev_priv);
> > > > }
> > > >
> > > > +static void hsw_edp_psr_irq_handler(struct drm_i915_private
> > > > *dev_priv)
> > > > +{
> > > > + u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > > > +
> > > > + if (edp_psr_iir & EDP_PSR_ERROR)
> > > > + DRM_DEBUG_KMS("PSR error\n");
> > > > +
> > > > + if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > > > + DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > > > + I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > >
> > > Why are we masking it here? During these 2 vblanks it's possible that
> > > something will happen (e.g., frontbuffer writing, cursor moving, page
> > > flipping).
> >
> > The masking was here to avoid seeing a big flood of entry interrupts.
> >
> > > Are we guaranteed to get a POST_EXIT interrupt even if we
> > > give up entering PSR before it is actually entered?
> >
> > No. The exit interrupt only happens if you actually reached PSR.
> >
> > >
> > >
> > > > + }
> > > > +
> > > > + if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > > > + DRM_DEBUG_KMS("PSR exit completed\n");
> > > > + I915_WRITE(EDP_PSR_IMR, 0);
> > > > + }
> > > > +
> > > > + I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > > > +}
> > > > +
> > > > static void ivb_display_irq_handler(struct drm_i915_private
> > > > *dev_priv,
> > > > u32 de_iir)
> > > > {
> > > > @@ -2403,6 +2423,9 @@ static void ivb_display_irq_handler(struct
> > > > drm_i915_private *dev_priv,
> > > > if (de_iir & DE_ERR_INT_IVB)
> > > > ivb_err_int_handler(dev_priv);
> > > >
> > > > + if (de_iir & DE_EDP_PSR_INT_HSW)
> > > > + hsw_edp_psr_irq_handler(dev_priv);
> > > > +
> > > > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > > > dp_aux_irq_handler(dev_priv);
> > > >
> > > > @@ -3260,6 +3283,11 @@ static void ironlake_irq_reset(struct
> > > > drm_device *dev)
> > > > if (IS_GEN7(dev_priv))
> > > > I915_WRITE(GEN7_ERR_INT, 0xffffffff);
> > > >
> > > > + if (IS_HASWELL(dev_priv)) {
> > > > + I915_WRITE(EDP_PSR_IMR, 0xffffffff);
> > > > + I915_WRITE(EDP_PSR_IIR, 0xffffffff);
> > > > + }
> > >
> > > We need another IIR write we do for the other platforms. This is not
> > > cargo cult (as mentioned in previous review emails), this is required
> > > since our hardware is able to store more than one IIR interrupt. Please
> > > do it like we do for the other interrupts.
> >
>
> My reply and the review were specifically about the POSTING_READ(). I
> agree on the second IIR write, but that was not what the original review
> comment was about.
>
> I'm still skeptical about inserting the POSTING_READ() between write's
> There are at commit messages and emails that indicate the
> POSTING_READS() are indeed cargo culted. Let me find more data about
> this and get back.
>
> > I don't remember if the PSR IIR is double buffered or not. I would
> > assumeme it is. It is super easy to verify though if you want to be
> > sure:
> > 1. unmask the interrupt
> > 2. generate at least two interrupts
> > 3. mask the interrupt
> > 4. clear IIR
> > 5. read IIR
> > 6. clear IIR
> > 7. read IIR
> >
> > Step 5 should still show the IIR bit set if the IIR is double buffered.
> > And step 7 it should show it to be clear.
> >
>
> I'll give it a try, thanks!
I'm far behind this week and merging the series was on top of my todo list...
:( sorry for that.
I know that you guys already talked about it and know how to do the follow-up ;)
>
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-04-20 22:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-03 21:24 [PATCH v3 1/4] drm/i915: Enable edp psr error interrupts on hsw Dhinakaran Pandiyan
2018-04-03 21:24 ` [PATCH v3 2/4] drm/i915: Enable edp psr error interrupts on bdw+ Dhinakaran Pandiyan
2018-04-05 20:38 ` Souza, Jose
2018-04-05 21:25 ` Pandiyan, Dhinakaran
2018-04-03 21:24 ` [PATCH v3 3/4] drm/i915/psr: Control PSR interrupts via debugfs Dhinakaran Pandiyan
2018-04-04 0:54 ` Souza, Jose
2018-04-04 23:58 ` Pandiyan, Dhinakaran
2018-04-05 1:37 ` [PATCH v4 " Dhinakaran Pandiyan
2018-04-05 19:42 ` Souza, Jose
2018-04-03 21:24 ` [PATCH v3 4/4] drm/i915/psr: Timestamps for PSR entry and exit interrupts Dhinakaran Pandiyan
2018-04-04 0:56 ` Souza, Jose
2018-04-03 21:50 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts on hsw Patchwork
2018-04-03 22:06 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-04-05 2:03 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2) Patchwork
2018-04-05 2:18 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-05 3:18 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-04-05 20:40 ` [PATCH v3 1/4] drm/i915: Enable edp psr error interrupts on hsw Souza, Jose
2018-04-05 21:42 ` Dhinakaran Pandiyan
2018-04-05 21:44 ` Souza, Jose
2018-04-05 22:00 ` [PATCH v4] " Dhinakaran Pandiyan
2018-04-17 0:43 ` Paulo Zanoni
2018-04-17 17:41 ` Ville Syrjälä
2018-04-17 20:01 ` Dhinakaran Pandiyan
2018-04-20 22:22 ` Rodrigo Vivi [this message]
2018-04-05 22:34 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4] drm/i915: Enable edp psr error interrupts on hsw (rev3) Patchwork
2018-04-05 22:51 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-06 1:50 ` ✗ Fi.CI.IGT: warning " Patchwork
2018-04-10 0:49 ` ✗ Fi.CI.CHECKPATCH: " Patchwork
[not found] ` <20180410175934.GA2303@intel.com>
2018-04-10 18:29 ` Dhinakaran Pandiyan
2018-04-20 21:33 ` Rodrigo Vivi
2018-04-10 1:05 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-10 2:25 ` ✓ Fi.CI.IGT: " Patchwork
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=20180420222237.GO1310@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dhinakaran.pandiyan@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@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.