1. 06 Mar, 2013 2 commits
  2. 05 Mar, 2013 3 commits
    • Paulo Zanoni's avatar
      drm/i915: also disable south interrupts when handling them · 44498aea
      Paulo Zanoni authored
      From the docs:
      
        "IIR can queue up to two interrupt events. When the IIR is cleared,
        it will set itself again after one clock if a second event was
        stored."
      
        "Only the rising edge of the PCH Display interrupt will cause the
        North Display IIR (DEIIR) PCH Display Interrupt even bit to be set,
        so all PCH Display Interrupts, including back to back interrupts,
        must be cleared before a new PCH Display interrupt can cause DEIIR
        to be set".
      
      The current code works fine because we don't get many interrupts, but
      if we enable the PCH FIFO underrun interrupts we'll start getting so
      many interrupts that at some point new PCH interrupts won't cause
      DEIIR to be set.
      
      The initial implementation I tried was to turn the code that checks
      SDEIIR into a loop, but we can still get interrupts even after the
      loop is done (and before the irq handler finishes), so we have to
      either disable the interrupts or mask them. In the end I concluded
      that just disabling the PCH interrupts is enough, you don't even need
      the loop, so this is what this patch implements. I've tested it and it
      passes the 2 "PCH FIFO underrun interrupt storms" I can reproduce:
      the "ironlake_crtc_disable" case and the "wrong watermarks" case.
      
      In other words, here's how to reproduce the problem fixed by this
      patch:
        1 - Enable PCH FIFO underrun interrupts (SERR_INT on SNB+)
        2 - Boot the machine
        3 - While booting we'll get tons of PCH FIFO underrun interrupts
        4 - Plug a new monitor
        5 - Run xrandr, notice it won't detect the new monitor
        6 - Read SDEIIR and notice it's not 0 while DEIIR is 0
      
      Q: Can't we just clear DEIIR before SDEIIR?
      A: It doesn't work. SDEIIR has to be completely cleared (including the
      interrupts stored on its back queue) before it can flip DEIIR's bit to
      1 again, and even while you're clearing it you'll be getting more and
      more interrupts.
      
      Q: Why does it work by just disabling+enabling the south interrupts?
      A: Because when we re-enable them, if there's something on the SDEIIR
      register (maybe an interrupt stored on the queue), the re-enabling
      will make DEIIR's bit flip to 1, and since we'll already have
      interrupts enabled we'll get another interrupt, then run our irq
      handler again to process the "back" interrupts.
      
      v2: Even bigger commit message, added code comments.
      
      Note that this fixes missed dp aux irqs which have been reported for
      3.9-rc1. This regression has been introduced by switching to
      irq-driven dp aux transactions with
      
      commit 9ee32fea
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Dec 1 13:53:48 2012 +0100
      
          drm/i915: irq-drive the dp aux communication
      
      References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18588.html
      References: https://lkml.org/lkml/2013/2/26/769Tested-by: default avatarImre Deak <imre.deak@intel.com>
      Reported-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      [danvet: Pimp commit message with references for the dp aux irq
      timeout regression this fixes.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      44498aea
    • Daniel Vetter's avatar
      drm/i915: enable irqs earlier when resuming · 15239099
      Daniel Vetter authored
      We need it to restore the ilk rc6 context, since the gpu wait no
      requires interrupts. But in general having interrupts around should
      help in code sanity, since more and more stuff is interrupt driven.
      
      This regression has been introduced in
      
      commit 3e960501
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Nov 27 16:22:54 2012 +0000
      
          drm/i915: Rearrange code to only have a single method for waiting upon the ring
      
      Like in the driver load code we need to make sure that hotplug
      interrupts don't cause havoc with our modeset state, hence block them
      with the existing infrastructure. Again we ignore races where we might
      loose hotplug interrupts ...
      
      Note that the driver load part of the regression has already been
      fixed in
      
      commit 52d7eced
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Dec 1 21:03:22 2012 +0100
      
          drm/i915: reorder setup sequence to have irqs for output setup
      
      v2: Add a note to the commit message about which patch fixed the
      driver load part of the regression. Stable kernels need to backport
      both patches.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691
      Cc: stable@vger.kernel.org (for 3.8 only, plese backport
      			    52d7eced first)
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Reported-and-Tested-by: default avatarIlya Tumaykin <itumaykin@gmail.com>
      Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      15239099
    • Stéphane Marchesin's avatar
      drm/i915: Increase the RC6p threshold. · 0920a487
      Stéphane Marchesin authored
      This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some
      reason this avoids the gen6_gt_check_fifodbg.isra warnings and
      associated GPU lockups, which makes my ivy bridge machine stable.
      Signed-off-by: default avatarStéphane Marchesin <marcheu@chromium.org>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0920a487
  3. 04 Mar, 2013 1 commit
  4. 03 Mar, 2013 4 commits
  5. 22 Feb, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Revert hdmi HDP pin checks · 202adf4b
      Daniel Vetter authored
      This reverts
      
      commit 8ec22b21
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri May 11 18:01:34 2012 +0100
      
          drm/i915/hdmi: Query the live connector status bit for G4x
      
      and
      
      commit b0ea7d37
      Author: Damien Lespiau <damien.lespiau@intel.com>
      Date:   Thu Dec 13 16:09:00 2012 +0000
      
          drm/i915/hdmi: Read the HPD status before trying to read the EDID
      
      They reliably cause HDMI to not be detected on some systems (like my
      ivb or the bug reporters gm45). To fix up the very slow unplug issues
      we might want to fire up a 2nd detect cycle a few hundred ms after
      each hotplug. But for now at least make displays work again.
      
      I somewhat suspect that this is confined to HDMI connectors, since all
      the machines I have with DP+ outputs work correctly.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52361
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org.kernel.org # for 8ec22b21Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      202adf4b
  6. 21 Feb, 2013 1 commit
  7. 19 Feb, 2013 23 commits
  8. 15 Feb, 2013 5 commits