* [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
@ 2018-02-02 15:34 Chris Wilson
2018-02-02 16:03 ` Ville Syrjälä
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Chris Wilson @ 2018-02-02 15:34 UTC (permalink / raw)
To: intel-gfx
As we ourselves cancel interrupts during reset by clearing the GTIIR, it
is possible for the master IIR to indicate a pending IRQ for which we
have already cleared from the GTIIR. In this case, the DRM_ERROR are
intended and should not be flagged as an error.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
---
drivers/gpu/drm/i915/i915_irq.c | 35 +++++++++--------------------------
1 file changed, 9 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 252feff2892d..b886bd459acc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1413,37 +1413,25 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
tasklet_hi_schedule(&execlists->tasklet);
}
-static irqreturn_t gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
- u32 master_ctl,
- u32 gt_iir[4])
+static void gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
+ u32 master_ctl, u32 gt_iir[4])
{
- irqreturn_t ret = IRQ_NONE;
-
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
gt_iir[0] = I915_READ_FW(GEN8_GT_IIR(0));
- if (gt_iir[0]) {
+ if (gt_iir[0])
I915_WRITE_FW(GEN8_GT_IIR(0), gt_iir[0]);
- ret = IRQ_HANDLED;
- } else
- DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
gt_iir[1] = I915_READ_FW(GEN8_GT_IIR(1));
- if (gt_iir[1]) {
+ if (gt_iir[1])
I915_WRITE_FW(GEN8_GT_IIR(1), gt_iir[1]);
- ret = IRQ_HANDLED;
- } else
- DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
if (master_ctl & GEN8_GT_VECS_IRQ) {
gt_iir[3] = I915_READ_FW(GEN8_GT_IIR(3));
- if (gt_iir[3]) {
+ if (gt_iir[3])
I915_WRITE_FW(GEN8_GT_IIR(3), gt_iir[3]);
- ret = IRQ_HANDLED;
- } else
- DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
@@ -1453,12 +1441,8 @@ static irqreturn_t gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
I915_WRITE_FW(GEN8_GT_IIR(2),
gt_iir[2] & (dev_priv->pm_rps_events |
dev_priv->pm_guc_events));
- ret = IRQ_HANDLED;
- } else
- DRM_ERROR("The master control interrupt lied (PM)!\n");
+ }
}
-
- return ret;
}
static void gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
@@ -2695,7 +2679,6 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
struct drm_i915_private *dev_priv = to_i915(dev);
u32 master_ctl;
u32 gt_iir[4] = {};
- irqreturn_t ret;
if (!intel_irqs_enabled(dev_priv))
return IRQ_NONE;
@@ -2711,16 +2694,16 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
disable_rpm_wakeref_asserts(dev_priv);
/* Find, clear, then process each source of interrupt */
- ret = gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
+ gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
gen8_gt_irq_handler(dev_priv, gt_iir);
- ret |= gen8_de_irq_handler(dev_priv, master_ctl);
+ gen8_de_irq_handler(dev_priv, master_ctl);
I915_WRITE_FW(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
POSTING_READ_FW(GEN8_MASTER_IRQ);
enable_rpm_wakeref_asserts(dev_priv);
- return ret;
+ return IRQ_HANDLED;
}
struct wedge_me {
--
2.15.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
2018-02-02 15:34 [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts Chris Wilson
@ 2018-02-02 16:03 ` Ville Syrjälä
2018-02-02 17:31 ` Chris Wilson
2018-02-02 16:52 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-02-02 20:28 ` ✗ Fi.CI.IGT: warning " Patchwork
2 siblings, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2018-02-02 16:03 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Fri, Feb 02, 2018 at 03:34:48PM +0000, Chris Wilson wrote:
> As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> is possible for the master IIR to indicate a pending IRQ for which we
> have already cleared from the GTIIR. In this case, the DRM_ERROR are
> intended and should not be flagged as an error.
I guess an alternative would be to not clear IIR and use
sychronize_irq() instead as needed. But I suppose that doesn't
really provide any real benefits.
One concern is that we will now claim that all interrupts are handled,
and thus couldn't detect spurious interrupts. But one might hope that
MSI and whanot has made those a thing of the past.
I never checked what the kernel's threshold was for disabling the
interrupt line on spurious interrupts. I have occasionally thought about
it though as I too have realized that the IIR clearing could result in
the interrupt handler having nothing to do.
So yeah, not quite sure which is best, always claiming IRQ_HANDLED or
only when we had some IIR bits to clear. Maybe just return IRQ_HANDLED
always for all MSI capable platforms?
Ramblings aside, I think this should be safe enough:
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 35 +++++++++--------------------------
> 1 file changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 252feff2892d..b886bd459acc 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1413,37 +1413,25 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
> tasklet_hi_schedule(&execlists->tasklet);
> }
>
> -static irqreturn_t gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
> - u32 master_ctl,
> - u32 gt_iir[4])
> +static void gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
> + u32 master_ctl, u32 gt_iir[4])
> {
> - irqreturn_t ret = IRQ_NONE;
> -
> if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
> gt_iir[0] = I915_READ_FW(GEN8_GT_IIR(0));
> - if (gt_iir[0]) {
> + if (gt_iir[0])
> I915_WRITE_FW(GEN8_GT_IIR(0), gt_iir[0]);
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (GT0)!\n");
> }
>
> if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
> gt_iir[1] = I915_READ_FW(GEN8_GT_IIR(1));
> - if (gt_iir[1]) {
> + if (gt_iir[1])
> I915_WRITE_FW(GEN8_GT_IIR(1), gt_iir[1]);
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (GT1)!\n");
> }
>
> if (master_ctl & GEN8_GT_VECS_IRQ) {
> gt_iir[3] = I915_READ_FW(GEN8_GT_IIR(3));
> - if (gt_iir[3]) {
> + if (gt_iir[3])
> I915_WRITE_FW(GEN8_GT_IIR(3), gt_iir[3]);
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (GT3)!\n");
> }
>
> if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
> @@ -1453,12 +1441,8 @@ static irqreturn_t gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
> I915_WRITE_FW(GEN8_GT_IIR(2),
> gt_iir[2] & (dev_priv->pm_rps_events |
> dev_priv->pm_guc_events));
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (PM)!\n");
> + }
> }
> -
> - return ret;
> }
>
> static void gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
> @@ -2695,7 +2679,6 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
> struct drm_i915_private *dev_priv = to_i915(dev);
> u32 master_ctl;
> u32 gt_iir[4] = {};
> - irqreturn_t ret;
>
> if (!intel_irqs_enabled(dev_priv))
> return IRQ_NONE;
> @@ -2711,16 +2694,16 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
> disable_rpm_wakeref_asserts(dev_priv);
>
> /* Find, clear, then process each source of interrupt */
> - ret = gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
> + gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
> gen8_gt_irq_handler(dev_priv, gt_iir);
> - ret |= gen8_de_irq_handler(dev_priv, master_ctl);
> + gen8_de_irq_handler(dev_priv, master_ctl);
>
> I915_WRITE_FW(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
> POSTING_READ_FW(GEN8_MASTER_IRQ);
>
> enable_rpm_wakeref_asserts(dev_priv);
>
> - return ret;
> + return IRQ_HANDLED;
> }
>
> struct wedge_me {
> --
> 2.15.1
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
2018-02-02 16:03 ` Ville Syrjälä
@ 2018-02-02 17:31 ` Chris Wilson
2018-02-02 17:44 ` Ville Syrjälä
0 siblings, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2018-02-02 17:31 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
Quoting Ville Syrjälä (2018-02-02 16:03:36)
> On Fri, Feb 02, 2018 at 03:34:48PM +0000, Chris Wilson wrote:
> > As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> > is possible for the master IIR to indicate a pending IRQ for which we
> > have already cleared from the GTIIR. In this case, the DRM_ERROR are
> > intended and should not be flagged as an error.
>
> I guess an alternative would be to not clear IIR and use
> sychronize_irq() instead as needed. But I suppose that doesn't
> really provide any real benefits.
>
> One concern is that we will now claim that all interrupts are handled,
> and thus couldn't detect spurious interrupts. But one might hope that
> MSI and whanot has made those a thing of the past.
We only say handled if the master IIR holds an interrupt, so not
entirely lost. At present, we say IRQ_NONE even though the master IIR
did raise the interrupt which seems wrong.
> I never checked what the kernel's threshold was for disabling the
> interrupt line on spurious interrupts. I have occasionally thought about
> it though as I too have realized that the IIR clearing could result in
> the interrupt handler having nothing to do.
>
> So yeah, not quite sure which is best, always claiming IRQ_HANDLED or
> only when we had some IIR bits to clear. Maybe just return IRQ_HANDLED
> always for all MSI capable platforms?
I think we're okay with just using the master IIR for IRQ_NONE /
IRQ_HANDLED as that is the interrupt generator aiui. If the child
sources disagree that's another issue, but as far as the kernel is
concerned i915 did generate and handle an interrupt.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
2018-02-02 17:31 ` Chris Wilson
@ 2018-02-02 17:44 ` Ville Syrjälä
2018-02-02 20:34 ` Chris Wilson
0 siblings, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2018-02-02 17:44 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Fri, Feb 02, 2018 at 05:31:57PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-02 16:03:36)
> > On Fri, Feb 02, 2018 at 03:34:48PM +0000, Chris Wilson wrote:
> > > As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> > > is possible for the master IIR to indicate a pending IRQ for which we
> > > have already cleared from the GTIIR. In this case, the DRM_ERROR are
> > > intended and should not be flagged as an error.
> >
> > I guess an alternative would be to not clear IIR and use
> > sychronize_irq() instead as needed. But I suppose that doesn't
> > really provide any real benefits.
> >
> > One concern is that we will now claim that all interrupts are handled,
> > and thus couldn't detect spurious interrupts. But one might hope that
> > MSI and whanot has made those a thing of the past.
>
> We only say handled if the master IIR holds an interrupt, so not
> entirely lost. At present, we say IRQ_NONE even though the master IIR
> did raise the interrupt which seems wrong.
>
> > I never checked what the kernel's threshold was for disabling the
> > interrupt line on spurious interrupts. I have occasionally thought about
> > it though as I too have realized that the IIR clearing could result in
> > the interrupt handler having nothing to do.
> >
> > So yeah, not quite sure which is best, always claiming IRQ_HANDLED or
> > only when we had some IIR bits to clear. Maybe just return IRQ_HANDLED
> > always for all MSI capable platforms?
>
> I think we're okay with just using the master IIR for IRQ_NONE /
> IRQ_HANDLED as that is the interrupt generator aiui. If the child
> sources disagree that's another issue, but as far as the kernel is
> concerned i915 did generate and handle an interrupt.
I think that might be the usual way it goes. I guess the IIR clearing is
racing with the MASTER_IRQ read as AFAIK the MASTER_IRQ status bits aren't
latched or anything (since we don't have to clear them). So I believe this
still leaves open a small window where even the MASTER_IRQ has cleared
itself by the time the irq handler gets around to reading it. So that
would look like a genuine spurious interrupt even though the GPU did
raise it for a reason.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
2018-02-02 17:44 ` Ville Syrjälä
@ 2018-02-02 20:34 ` Chris Wilson
0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2018-02-02 20:34 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
Quoting Ville Syrjälä (2018-02-02 17:44:58)
> On Fri, Feb 02, 2018 at 05:31:57PM +0000, Chris Wilson wrote:
> > I think we're okay with just using the master IIR for IRQ_NONE /
> > IRQ_HANDLED as that is the interrupt generator aiui. If the child
> > sources disagree that's another issue, but as far as the kernel is
> > concerned i915 did generate and handle an interrupt.
>
> I think that might be the usual way it goes. I guess the IIR clearing is
> racing with the MASTER_IRQ read as AFAIK the MASTER_IRQ status bits aren't
> latched or anything (since we don't have to clear them). So I believe this
> still leaves open a small window where even the MASTER_IRQ has cleared
> itself by the time the irq handler gets around to reading it. So that
> would look like a genuine spurious interrupt even though the GPU did
> raise it for a reason.
I've committed ourselves (for the time being at least) to always
returning IRQ_HANDLED if the master IIR reports an interrupt. Hopefully
I won't regret it :)
Thanks,
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
2018-02-02 15:34 [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts Chris Wilson
2018-02-02 16:03 ` Ville Syrjälä
@ 2018-02-02 16:52 ` Patchwork
2018-02-02 20:28 ` ✗ Fi.CI.IGT: warning " Patchwork
2 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2018-02-02 16:52 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
URL : https://patchwork.freedesktop.org/series/37558/
State : success
== Summary ==
Series 37558v1 drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
https://patchwork.freedesktop.org/api/1.0/series/37558/revisions/1/mbox/
Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
incomplete -> PASS (fi-bdw-5557u) fdo#104162
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162
fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:419s
fi-bdw-gvtdvm total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s
fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s
fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:487s
fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s
fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:485s
fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:481s
fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:464s
fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:452s
fi-cfl-s2 total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:560s
fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:412s
fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:280s
fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:515s
fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:389s
fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s
fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:408s
fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:450s
fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:409s
fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:453s
fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:503s
fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:452s
fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:500s
fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:580s
fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:426s
fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:503s
fi-skl-6700hq total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:521s
fi-skl-6700k2 total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:490s
fi-skl-6770hq total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:492s
fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:414s
fi-skl-gvtdvm total:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:426s
fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:523s
fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:393s
Blacklisted hosts:
fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:472s
bde4e003ce549b8225142843e0d5aee19dd37d13 drm-tip: 2018y-02m-02d-15h-03m-15s UTC integration manifest
eb952eea6b1e drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7864/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread* ✗ Fi.CI.IGT: warning for drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
2018-02-02 15:34 [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts Chris Wilson
2018-02-02 16:03 ` Ville Syrjälä
2018-02-02 16:52 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2018-02-02 20:28 ` Patchwork
2 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2018-02-02 20:28 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
URL : https://patchwork.freedesktop.org/series/37558/
State : warning
== Summary ==
Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
fail -> PASS (shard-hsw)
Subgroup plain-flip-ts-check:
fail -> PASS (shard-hsw) fdo#100368
Test perf:
Subgroup enable-disable:
fail -> PASS (shard-apl) fdo#103715
Subgroup blocking:
fail -> PASS (shard-hsw) fdo#102252
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-fullscreen:
pass -> SKIP (shard-snb) fdo#101623
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-left-edge:
pass -> SKIP (shard-snb)
Test kms_cursor_legacy:
Subgroup nonblocking-modeset-vs-cursor-atomic:
pass -> SKIP (shard-snb)
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
shard-apl total:2795 pass:1725 dwarn:1 dfail:0 fail:19 skip:1049 time:12012s
shard-hsw total:2800 pass:1710 dwarn:1 dfail:0 fail:11 skip:1076 time:10873s
shard-snb total:2836 pass:1325 dwarn:1 dfail:0 fail:10 skip:1500 time:6402s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7864/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-02-02 20:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-02-02 15:34 [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts Chris Wilson
2018-02-02 16:03 ` Ville Syrjälä
2018-02-02 17:31 ` Chris Wilson
2018-02-02 17:44 ` Ville Syrjälä
2018-02-02 20:34 ` Chris Wilson
2018-02-02 16:52 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-02-02 20:28 ` ✗ Fi.CI.IGT: warning " Patchwork
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.