1. 10 4月, 2012 1 次提交
    • B
      drm/i915: ring irq cleanups · e2a1e2f0
      Ben Widawsky 提交于
      - gen6 put/get only need one argument
          rflags and gflags are always the same (see above explanation)
      - remove a couple redundantly defined IRQs
      - reordered some lines to make things go in descending order
      
      Every ring has its own interrupts, enables, masks, and status bits that
      are fed into the main interrupt enable/mask/status registers. At one
      point in time it seemed like a good idea to make our functions support
      the notion that each interrupt may have a different bit position in the
      corresponding register (blitter parser error may be bit n in IMR, but
      bit m in blitter IMR). It turned out though that the HW designers did us
      a solid on Gen6+ and this unfortunate situation has been avoided. This
      allows our interrupt code to be cleaned up a bit.
      
      I jammed this into one commit because there should be no functional
      change with this commit, and staging it into multiple commits was
      unnecessarily artificial IMO.
      
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet:
      - fixed up merged conflict with vlv changes.
      - added GEN6 to GT blitter bit, we only use it on gen6+.
      - added a comment to both ring irq bits and GT irq bits that on gen6+
        these alias.
      - added comment that GT_BSD_USER_INTERRUPT is ilk-only.
      - I've got confused a bit that we still use GT_USER_INTERRUPT on ivb
        for the render ring - but this goes back to ilk where we have only
        gt interrupt bits and so we be equally confusing if changed.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e2a1e2f0
  2. 29 3月, 2012 1 次提交
  3. 21 3月, 2012 1 次提交
    • D
      drm/i915: bind objects to the global gtt only when needed · 74898d7e
      Daniel Vetter 提交于
      And track the existence of such a binding similar to the aliasing
      ppgtt case. Speeds up binding/unbinding in the common case where we
      only need a ppgtt binding (which is accessed in a cpu coherent fashion
      by the gpu) and no gloabl gtt binding (which needs uc writes for the
      ptes).
      
      This patch just puts the required tracking in place.
      
      v2: Check that global gtt mappings exist in the error_state capture
      code (with Chris Wilson's llc reloc patches batchbuffers are no longer
      relocated as mappable in all situations, so this matters). Suggested
      by Chris Wilson.
      
      v3: Adapted to Chris' latest llc-reloc patches.
      
      v4: Fix a bug in the i915 error state capture code noticed by Chris
      Wilson.
      Reviewed-and-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      74898d7e
  4. 19 3月, 2012 1 次提交
  5. 15 2月, 2012 2 次提交
  6. 13 2月, 2012 1 次提交
  7. 09 2月, 2012 1 次提交
    • D
      drm/i915: dump even more into the error_state · 7e3b8737
      Daniel Vetter 提交于
      Chris Wilson and me have again stared at funny error states and it's
      been pretty clear from the start that something was seriously amiss.
      The seqnos last seen by the cpu were a few hundred behind those that
      the gpu could have possibly emitted last before it died ...
      
      Chris now tracked it down (hopefully, definit verdict's still out),
      but in hindsight we'd have found the bug by simply dumping the cpu
      side tracking of the ring head and tail registers.
      
      Fix this and prevent an identical time-waster in the future.
      
      Because the hangs always involved semaphores in one way or another,
      we've tried to dump the mbox registers, but couldn't find any
      inconsistencies. Still, dump them too.
      Reviewed-and-wanted-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7e3b8737
  8. 01 2月, 2012 1 次提交
  9. 30 1月, 2012 5 次提交
  10. 26 1月, 2012 1 次提交
  11. 20 1月, 2012 1 次提交
  12. 04 1月, 2012 1 次提交
  13. 20 12月, 2011 2 次提交
  14. 04 11月, 2011 1 次提交
  15. 21 10月, 2011 2 次提交
    • D
      drm/i915: close PM interrupt masking races in the rps work func · a9e2641d
      Daniel Vetter 提交于
      This patch closes the following race:
      
      We get a PM interrupt A, mask it, set dev_priv->iir = PM_A and kick of the
      work item. Scheduler isn't grumpy, so the work queue takes rps_lock,
      grabs pm_iir = dev_priv->pm_iir and pm_imr = READ(PMIMR). Note that
      pm_imr == pm_iir because we've just masked the interrupt we've got.
      
      Now hw sends out PM interrupt B (not masked), we process it and mask
      it.  Later on the irq handler also clears PMIIR.
      
      Then the work item proceeds and at the end clears PMIMR. Because
      (local) pm_imr == pm_iir we have
              pm_imr & ~pm_iir == 0
      so all interrupts are enabled.
      
      Hardware is still interrupt-happy, and sends out a new PM interrupt B.
      PMIMR doesn't mask B (it does not mask anything), PMIIR is cleared, so
      we get it and hit the WARN in the interrupt handler (because
      dev_priv->pm_iir == PM_B).
      
      That's why I've moved the
              WRITE(PMIMR, 0)
      up under the protection of the rps_lock. And write an uncoditional 0
      to PMIMR, because that's what we'll do anyway.
      
      This races looks much more likely because we can arbitrarily extend
      the window by grabing dev->struct mutex right after the irq handler
      has processed the first PM_B interrupt.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      a9e2641d
    • D
      drm/i915: close PM interrupt masking races in the irq handler · 4fb066ab
      Daniel Vetter 提交于
      Quoting Chris Wilson's more concise description:
      
      "Ah I think I see the problem. As you point out we only mask the current
      interrupt received, so that if we have a task pending (and so IMR != 0) we
      actually unmask the pending interrupt and so could receive it again before the
      tasklet is finally kicked off by the grumpy scheduler."
      
      We need the hw to issue PM interrupts A, B, A while the scheduler is hating us
      and refuses to run the rps work item. On receiving PM interrupt A we hit the
      WARN because
      
      dev_priv->pm_iir == PM_A | PM_B
      
      Also add a posting read as suggested by Chris to ensure proper ordering of the
      writes to PMIMR and PMIIR. Just in case somebody weakens write ordering.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      4fb066ab
  16. 01 10月, 2011 2 次提交
  17. 20 9月, 2011 1 次提交
  18. 16 8月, 2011 1 次提交
  19. 29 7月, 2011 1 次提交
  20. 26 7月, 2011 1 次提交
    • K
      drm/i915: Hold mode_config->mutex during hotplug processing · a65e34c7
      Keith Packard 提交于
      Hotplug detection is a mode setting operation and must hold the
      struct_mutex or risk colliding with other mode setting operations.
      
      In particular, the display port hotplug function attempts to re-train
      the link if the monitor is supposed to be running when plugged back
      in. If that happens while mode setting is underway, the link will get
      scrambled, leaving it in an inconsistent state.
      
      This is a special case -- usually the driver mode setting entry points
      are covered by the upper level DRM code, but in this case the function
      is invoked as a work function not under the control of DRM.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Cc: stable@kernel.org
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a65e34c7
  21. 02 7月, 2011 1 次提交
  22. 30 6月, 2011 2 次提交
  23. 22 6月, 2011 1 次提交
  24. 18 6月, 2011 1 次提交
    • D
      drm/i915: Fix gen6 (SNB) missed BLT ring interrupts. · 498e720b
      Daniel J Blueman 提交于
      The failure appeared in dmesg as:
      
      [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
      ring idle [waiting on 35064155, at 35064155], missed IRQ?
      
      This works around that problem on by making the blitter command
      streamer write interrupt state to the Hardware Status Page when a
      MI_USER_INTERRUPT command is decoded, which appears to force the seqno
      out to memory before the interrupt happens.
      
      v1->v2: Moved to prior interrupt handler installation and RMW flags as
      per feedback.
      v2->v3: Removed RMW of flags (by anholt)
      
      Cc: stable@kernel.org
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1]
      Tested-by: Eric Anholt <eric@anholt.net> [v1,v3]
      	   (incidence of the bug with a testcase went from avg 2/1000 to
      	   0/12651 in the latest test run (plus more for v1))
      Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
      Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1]
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394Signed-off-by: NDave Airlie <airlied@redhat.com>
      498e720b
  25. 05 6月, 2011 1 次提交
  26. 19 5月, 2011 1 次提交
  27. 14 5月, 2011 3 次提交
  28. 11 5月, 2011 2 次提交
新手
引导
客服 返回
顶部