On Wed, Nov 7, 2012 at 2:43 PM, Ben Guthro <b...@guthro.net> wrote: >> >> >> There seems to be a mismatch for these IRQ delivery - or at least exhibits >> the behavior similar to such a problem. >> > > I was mistaken here. The i8042 IRQ would just start up the IRQ handling - but > the i915 driver always thinks it has pending work, and schedules it. > It seems that the hotplug mask is not getting cleared in pch_iir (in > i915_irq.c) > > Manually clearing this bit with > pch_iir = pch_iir ^ hotplug_mask; > in the ironlake_irq_handler() function > > seems to resolve the issue - making it so I don't get the flurry of hotplug > work bogging down the system. > ...but is this disabling hotplug detection entirely? > >
The attached patch seems to resolve the issue of the interrupt storm
after S3 for this Ibex Peak PCH system.
Could someone comment on whether this will have any unintended side effects?
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 32e1bda..d8f2f79 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -802,8 +802,13 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
/* check event from PCH */
if (de_iir & DE_PCH_EVENT) {
- if (pch_iir & hotplug_mask)
+ if (pch_iir & hotplug_mask) {
queue_work(dev_priv->wq, &dev_priv->hotplug_work);
+
+ if (!HAS_PCH_CPT(dev))
+ pch_iir = pch_iir ^ SDE_HOTPLUG_MASK;
+ }
+
if (HAS_PCH_CPT(dev))
cpt_irq_handler(dev, pch_iir);
else
hotplug.patch
Description: Binary data
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
