1. 11 6月, 2013 1 次提交
    • C
      drm/i915: Only slightly increment hangcheck score if we succesfully kick a ring · 9107e9d2
      Chris Wilson 提交于
      After kicking a ring, it should be free to make progress again and so
      should not be accused of being stuck until hangcheck fires once more. In
      order to catch a denial-of-service within a batch or across multiple
      batches, we still do increment the hangcheck score - just not as
      severely so that it takes multiple kicks to fail.
      
      This should address part of Ben's justified criticism of
      
      commit 05407ff8
      Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Date:   Thu May 30 09:04:29 2013 +0300
      
          drm/i915: detect hang using per ring hangcheck_score
      
      "There's also another corner case on the kick. If the seqno = 2
      (though not stuck), and on the 3rd hangcheck, the ring is stuck, and
      we try to kick it... we don't actually try to find out if the kick
      helped."
      
      v2: Make sure we catch DoS attempts with batches full of invalid WAITs.
      v3: Preserve the ability to detect loops by always charging the ring
          if it is busy on the same request.
      v4: Make sure we queue another check if on a new batch
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=65394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9107e9d2
  2. 06 6月, 2013 1 次提交
  3. 03 6月, 2013 3 次提交
  4. 01 6月, 2013 12 次提交
  5. 11 5月, 2013 2 次提交
  6. 30 4月, 2013 2 次提交
  7. 27 4月, 2013 1 次提交
  8. 25 4月, 2013 1 次提交
  9. 24 4月, 2013 1 次提交
    • J
      drm/i915: make sure GPU freq drops to minimum after entering RC6 v4 · 52ceb908
      Jesse Barnes 提交于
      On VLV, the Punit doesn't automatically drop the GPU to it's minimum
      voltage level when entering RC6, so we arm a timer to do it for us from
      the RPS interrupt handler.  It'll generally only fire when we go idle
      (or if for some reason there's a long delay between RPS interrupts), but
      won't be re-armed again until the next RPS event, so shouldn't affect
      power consumption after we go idle and it triggers.
      
      v2: use delayed work instead of timer + work queue combo (Ville)
      v3: fix up delayed work cancel (must be outside lock) (Daniel)
          fix up delayed work handling func for delayed work (Jesse)
      v4: cancel delayed work before RPS shutdown (Jani)
          pass delay not absolute time to mod_delayed_work (Jani)
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      52ceb908
  10. 23 4月, 2013 2 次提交
  11. 19 4月, 2013 2 次提交
    • P
      drm/i915: print Gen5+ CPU/PCH poison interrupts · de032bf4
      Paulo Zanoni 提交于
      This is bad news and shouldn't be happening.
      
      V2: Rebase.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      de032bf4
    • P
      drm/i915: report Gen5+ CPU and PCH FIFO underruns · 8664281b
      Paulo Zanoni 提交于
      In this commit we enable both CPU and PCH FIFO underrun reporting and
      start reporting them. We follow a few rules:
        - after we receive one of these errors, we mask the interrupt, so
          we won't get an "interrupt storm" and we also won't flood dmesg;
        - at each mode set we enable the interrupts again, so we'll see each
          message at most once per mode set;
        - in the specific places where we need to ignore the errors, we
          completely mask the interrupts.
      
      The downside of this patch is that since we're completely disabling
      (masking) the interrupts instead of just not printing error messages,
      we will mask more than just what we want on IVB/HSW CPU interrupts
      (due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So
      when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll
      also be masking PCH FIFO underruns for pipe B, because both are
      reported by SERR_INT, which has to be either completely enabled or
      completely disabled (in othe words, there's no way to disable/enable
      specific bits of GEN7_ERR_INT and SERR_INT).
      
      V2: Rename some functions and variables, downgrade messages to
      DRM_DEBUG_DRIVER and rebase.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8664281b
  12. 18 4月, 2013 8 次提交
  13. 09 4月, 2013 1 次提交
    • B
      drm/i915: Don't touch South Display when PCH_NOP · ab5c608b
      Ben Widawsky 提交于
      Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will
      be bad for CPU" range when we have PCH_NOP.
      
      There is a bit of a hack in init clock gating. We want to do most of the
      clock gating, but the part we skip will hang the system. It could
      probably be abstracted a bit better, but I don't feel it's too
      unsightly.
      
      v2: Use inverse HAS_PCH_NOP check (Jani)
      
      v3: Actually do what I claimed in v2 (spotted by Daniel)
      Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel)
      Move LVDS bail into this patch (Ben)
      
      v4: logical rebase conflict resolution with SDEIIR (Ben)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      
      Brush up patch a bit and resolve conflicts:
      - Adjust PCH_NOP checks due to Egbert's hpd handling rework.
      - Addd a PCH_NOP check in the irq uninstall code.
      - Resolve conflicts with Paulo's SDE irq handling race fix.
      
      v5: Drop the added hunks in the ilk irq handler again, they're bogus.
      OOps.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ab5c608b
  14. 28 3月, 2013 3 次提交