linux_dsm_epyc7002/drivers/gpu/drm
Jiri Kosina c12aba5aa0 drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.

It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.

Typically this results in the spurious interrupt source getting
disabled:

[    9.636345] irq 16: nobody cared (try booting with the "irqpoll" option)
[    9.637915] Pid: 4157, comm: ifup Tainted: GF            3.9.0-rc2-00341-g0863702 #422
[    9.639484] Call Trace:
[    9.640731]  <IRQ>  [<ffffffff8109b40d>] __report_bad_irq+0x1d/0xc7
[    9.640731]  [<ffffffff8109b7db>] note_interrupt+0x15b/0x1e8
[    9.640731]  [<ffffffff810999f7>] handle_irq_event_percpu+0x1bf/0x214
[    9.640731]  [<ffffffff81099a88>] handle_irq_event+0x3c/0x5c
[    9.640731]  [<ffffffff8109c139>] handle_fasteoi_irq+0x7a/0xb0
[    9.640731]  [<ffffffff8100400e>] handle_irq+0x1a/0x24
[    9.640731]  [<ffffffff81003d17>] do_IRQ+0x48/0xaf
[    9.640731]  [<ffffffff8142f1ea>] common_interrupt+0x6a/0x6a
[    9.640731]  <EOI>  [<ffffffff8142f952>] ? system_call_fastpath+0x16/0x1b
[    9.640731] handlers:
[    9.640731] [<ffffffffa000d771>] usb_hcd_irq [usbcore]
[    9.640731] [<ffffffffa0306189>] yenta_interrupt [yenta_socket]
[    9.640731] Disabling IRQ #16

The really curious thing is now that irq 16 is _not_ the interrupt for
the i915 driver when using MSI, but it _is_ the interrupt when not
using MSI. So by all indications it seems like gmbus is able to
generate a legacy (shared) interrupt in MSI mode on some
configurations. I've tried to reproduce this and the differentiating
thing seems to be that on unaffected systems no other device uses irq
16 (which seems to be the non-MSI intel gfx interrupt on all gm45).

I have no idea how that even can happen.

To avoid tempting this elephant into a rage, just disable gmbus
interrupt support on gen 4.

v2: Improve the commit message with exact details of what's going on.
Also add a comment in the code to warn against this particular
elephant in the room.

v3: Move the comment explaing how gen4 blows up next to the definition
of HAS_GMBUS_IRQ to keep the code-flow straight. Suggested by Chris
Wilson.

Signed-off-by: Jiri Kosina <jkosina@suse.cz> (v1)
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://lkml.org/lkml/2013/3/8/325
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-20 00:03:16 +01:00
..
ast
cirrus
exynos
gma500
i2c
i810
i915 drm/i915: stop using GMBUS IRQs on Gen4 chips 2013-03-20 00:03:16 +01:00
mga
mgag200 drm/mgag200: Bug fix: Renesas board now selects native resolution. 2013-03-08 08:31:49 +10:00
nouveau drm/nv50-: prevent some races between modesetting and page flipping 2013-03-04 11:46:35 +10:00
omapdrm
r128
radeon drm/radeon: don't check mipmap alignment if MIP_ADDRESS is FMASK 2013-03-07 12:58:59 -05:00
savage
shmobile
sis
tdfx
tegra drm/tegra: drop "select DRM_HDMI" 2013-03-08 08:36:01 +10:00
tilcdc
ttm
udl
via
vmwgfx
ati_pcigart.c
drm_agpsupport.c
drm_auth.c
drm_buffer.c
drm_bufs.c
drm_cache.c
drm_context.c
drm_crtc_helper.c
drm_crtc.c
drm_debugfs.c
drm_dma.c
drm_dp_helper.c
drm_drv.c
drm_edid_load.c
drm_edid.c
drm_encoder_slave.c
drm_fb_cma_helper.c
drm_fb_helper.c
drm_fops.c
drm_gem_cma_helper.c
drm_gem.c
drm_global.c
drm_hashtab.c
drm_info.c
drm_ioc32.c
drm_ioctl.c
drm_irq.c
drm_lock.c
drm_memory.c
drm_mm.c
drm_modes.c
drm_pci.c
drm_platform.c
drm_prime.c
drm_proc.c
drm_scatter.c
drm_stub.c
drm_sysfs.c
drm_trace_points.c
drm_trace.h
drm_usb.c
drm_vm.c
Kconfig
Makefile
README.drm

************************************************************
* For the very latest on DRI development, please see:      *
*     http://dri.freedesktop.org/                          *
************************************************************

The Direct Rendering Manager (drm) is a device-independent kernel-level
device driver that provides support for the XFree86 Direct Rendering
Infrastructure (DRI).

The DRM supports the Direct Rendering Infrastructure (DRI) in four major
ways:

    1. The DRM provides synchronized access to the graphics hardware via
       the use of an optimized two-tiered lock.

    2. The DRM enforces the DRI security policy for access to the graphics
       hardware by only allowing authenticated X11 clients access to
       restricted regions of memory.

    3. The DRM provides a generic DMA engine, complete with multiple
       queues and the ability to detect the need for an OpenGL context
       switch.

    4. The DRM is extensible via the use of small device-specific modules
       that rely extensively on the API exported by the DRM module.


Documentation on the DRI is available from:
    http://dri.freedesktop.org/wiki/Documentation
    http://sourceforge.net/project/showfiles.php?group_id=387
    http://dri.sourceforge.net/doc/

For specific information about kernel-level support, see:

    The Direct Rendering Manager, Kernel Support for the Direct Rendering
    Infrastructure
    http://dri.sourceforge.net/doc/drm_low_level.html

    Hardware Locking for the Direct Rendering Infrastructure
    http://dri.sourceforge.net/doc/hardware_locking_low_level.html

    A Security Analysis of the Direct Rendering Infrastructure
    http://dri.sourceforge.net/doc/security_low_level.html