On Tue, 10 Apr 2012 20:11:29 +0200 Jiri Slaby <jslaby at suse.cz> wrote:
> On 04/10/2012 06:26 PM, Jesse Barnes wrote: > > So port hotplug is always reporting that port C has a hotplug > > interrupt though... If you write 0x3 back to it does the interrupt > > stop? > > I'm not sure I got it right. This doesn't help: > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -1416,6 +1416,17 @@ static irqreturn_t > i915_driver_irq_handler(DRM_IRQ_ARGS) > iir = new_iir; > } > > + if (ret == IRQ_NONE) { > + u32 hp = I915_READ(PORT_HOTPLUG_STAT); > + if (hp) { > + I915_WRITE(PORT_HOTPLUG_STAT, hp); > + I915_READ(PORT_HOTPLUG_STAT); > + } > + > + if (printk_ratelimit()) > + printk(KERN_DEBUG "%s: %.8x\n", __func__, hp); > + > + } > > return ret; > } Yeah that looks right, you still get 0x300? You could try masking hotplug interrupts altogether. Also, just to sanity check things, can you look at the output of "lspci -s 02.0 -vvv -xxx" and see if the "INTx" field is + or -? If it's +, then the interrupt is definitely coming from an un-acked IRQ source on the gfx device. If it's INTx-, it means something in one of the upper MSI layers isn't getting handled right. -- Jesse Barnes, Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120410/a477ec8a/attachment.pgp>