diff mbox

i915 irq storm mitigation in 3.10

Message ID CAKMK7uGiFaAROx6Nm-MzbFW9Z76brD4cqwCBcTk8Z5f6YOh9HQ@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Daniel Vetter July 25, 2013, 9:58 a.m. UTC
On Thu, Jul 25, 2013 at 9:50 AM, Egbert Eich <eich@suse.com> wrote:
>  > I applied this patch (but not the one you sent on Monday), recompiled
>  > and logged:
>  > uncompressed (8,2M) http://files.hz6.de/kern_20130724.log
>  > bz2 (288 KB) http://files.hz6.de/kern_20130724.log.bz2
>
> These logs show clearly that we are seeing interrupts which
> should be disabled.
> Could it be that we we have either the status or enable bits
> mixed up? Unfortunately the publically available docs for GEN4
> don't show the HOTPLUG_EN and HOTPLUG_STAT registers.
>
> Daniel, could you please help me out here?

I've checked the docs again for gm45 and we seem to have the right
values. But on early gen4 (i.e. i965g/gm) the Bspec has been wrong
about these, so I wouldn't be surprised at all if they're wrong for
the digital ports on gm45, too.

Iirc we've already had a case like that, but there was no real
conclusion (and atm I can't find the bug). Can you pls try the below
patch (on top of Egbert's debug stuff)?



Egbert I think your debug patch has fairly useful information for
debugging the storm code in general, can you please submit a patch
against drm-intel-nightly?

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Comments

Egbert Eich July 25, 2013, 11:18 a.m. UTC | #1
Daniel Vetter writes:
 > 
 > I've checked the docs again for gm45 and we seem to have the right
 > values. But on early gen4 (i.e. i965g/gm) the Bspec has been wrong
 > about these, so I wouldn't be surprised at all if they're wrong for
 > the digital ports on gm45, too.
 > 
 > Iirc we've already had a case like that, but there was no real
 > conclusion (and atm I can't find the bug). Can you pls try the below
 > patch (on top of Egbert's debug stuff)?
 > 
If this doesn't help, lets disable all the digital ports together for
testing.

 > 
 > 
 > Egbert I think your debug patch has fairly useful information for
 > debugging the storm code in general, can you please submit a patch
 > against drm-intel-nightly?
 > 

Will do :)

Cheers,
	Egbert.
Jan Niggemann July 25, 2013, 9:23 p.m. UTC | #2
Hi Daniel,

Am 25.07.2013 11:58, schrieb Daniel Vetter:
> Can you pls try the below
> patch (on top of Egbert's debug stuff)?
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 6caa748..2d4c884 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1925,9 +1925,9 @@
>
>  #define PORT_HOTPLUG_STAT      (dev_priv->info->display_mmio_offset
> + 0x61114)
>  /* HDMI/DP bits are gen4+ */
> -#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 29)
> +#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 29)
>  #define   PORTC_HOTPLUG_LIVE_STATUS               (1 << 28)
> -#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 27)
> +#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 27)
>  #define   PORTD_HOTPLUG_INT_STATUS             (3 << 21)
>  #define   PORTC_HOTPLUG_INT_STATUS             (3 << 19)
>  #define   PORTB_HOTPLUG_INT_STATUS             (3 << 17)
I did, here are the logs:
364K http://files.hz6.de/kern_20130724_2.log
I don't understand what exactly this patch does, but I noticed:
- much less drm debug info, resulting in a much smaller log
- no more noticeable lag on my system (even though a storm was 
detected).
I double checked the latter and the lag seems indeed to be gone...

Jan
Egbert Eich July 26, 2013, 5:11 a.m. UTC | #3
Jan Niggemann writes:
 > Hi Daniel,
 > 
 > Am 25.07.2013 11:58, schrieb Daniel Vetter:
 > > Can you pls try the below
 > > patch (on top of Egbert's debug stuff)?
 > >
 > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
 > > b/drivers/gpu/drm/i915/i915_reg.h
 > > index 6caa748..2d4c884 100644
 > > --- a/drivers/gpu/drm/i915/i915_reg.h
 > > +++ b/drivers/gpu/drm/i915/i915_reg.h
 > > @@ -1925,9 +1925,9 @@
 > >
 > >  #define PORT_HOTPLUG_STAT      (dev_priv->info->display_mmio_offset
 > > + 0x61114)
 > >  /* HDMI/DP bits are gen4+ */
 > > -#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 29)
 > > +#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 29)
 > >  #define   PORTC_HOTPLUG_LIVE_STATUS               (1 << 28)
 > > -#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 27)
 > > +#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 27)
 > >  #define   PORTD_HOTPLUG_INT_STATUS             (3 << 21)
 > >  #define   PORTC_HOTPLUG_INT_STATUS             (3 << 19)
 > >  #define   PORTB_HOTPLUG_INT_STATUS             (3 << 17)
 > I did, here are the logs:
 > 364K http://files.hz6.de/kern_20130724_2.log

I get a 'forbidden' when I try to access this.

 > I don't understand what exactly this patch does, but I noticed:
 > - much less drm debug info, resulting in a much smaller log
 > - no more noticeable lag on my system (even though a storm was 
 > detected).

Ok, so this indicates that the storm detection works now :)

 > I double checked the latter and the lag seems indeed to be gone...

Before we actually masked out individual events it was irrelevant
if the bits were mixed up. Now we need to be correct on these.

Jan, thanks for your help!

Cheers,
	Egbert.
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6caa748..2d4c884 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1925,9 +1925,9 @@ 

 #define PORT_HOTPLUG_STAT      (dev_priv->info->display_mmio_offset + 0x61114)
 /* HDMI/DP bits are gen4+ */
-#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 29)
+#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 29)
 #define   PORTC_HOTPLUG_LIVE_STATUS               (1 << 28)
-#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 27)
+#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 27)
 #define   PORTD_HOTPLUG_INT_STATUS             (3 << 21)
 #define   PORTC_HOTPLUG_INT_STATUS             (3 << 19)
 #define   PORTB_HOTPLUG_INT_STATUS             (3 << 17)