1. 20 1月, 2012 1 次提交
    • D
      drm/i915: protect force_wake_(get|put) with the gt_lock · 9f1f46a4
      Daniel Vetter 提交于
      The problem this patch solves is that the forcewake accounting
      necessary for register reads is protected by dev->struct_mutex. But the
      hangcheck and error_capture code need to access registers without
      grabbing this mutex because we hold it while waiting for the gpu.
      So a new lock is required. Because currently the error_state capture
      is called from the error irq handler and the hangcheck code runs from
      a timer, it needs to be an irqsafe spinlock (note that the registers
      used by the irq handler (neglecting the error handling part) only uses
      registers that don't need the forcewake dance).
      
      We could tune this down to a normal spinlock when we rework the
      error_state capture and hangcheck code to run from a workqueue.  But
      we don't have any read in a fastpath that needs forcewake, so I've
      decided to not care much about overhead.
      
      This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
      snb on recent kernels - something must have slightly changed the
      timings. On previous kernels it only trigger a WARN about the broken
      locking.
      
      v2: Drop the previous patch for the register writes.
      
      v3: Improve the commit message per Chris Wilson's suggestions.
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      9f1f46a4
  2. 14 1月, 2012 1 次提交
  3. 04 1月, 2012 1 次提交
    • K
      drm/i915: Clean up multi-threaded forcewake patch · c7dffff7
      Keith Packard 提交于
      We learned that the ECOBUS register was inside the GT power well, and
      so *did* need force wake to be read, so it gets removed from the list
      of 'doesn't need force wake' registers.
      
      That means the code reading ECOBUS after forcing the mt_force_wake
      function to be called needs to use I915_READ_NOTRACE; it doesn't need
      to do more force wake fun as it's already done it manually.
      
      This also adds a comment explaining why the MT forcewake testing code
      only needs to call mt_forcewake_get/put and not disable RC6 manually
      -- the ECOBUS read will return 0 if the device is in RC6 and isn't
      using MT forcewake, causing the test to work correctly.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      c7dffff7
  4. 17 12月, 2011 2 次提交
  5. 24 11月, 2011 1 次提交
  6. 11 11月, 2011 2 次提交
  7. 01 11月, 2011 1 次提交
  8. 29 10月, 2011 1 次提交
  9. 21 10月, 2011 1 次提交
    • A
      i915: Move i915_read/write out of line · f7000883
      Andi Kleen 提交于
      With the tracing code in there they are far too big to inline.
      
      .text savings compared to a non force inline kernel:
      
      i915_restore_display                        4393   12036   +7643
      i915_save_display                           4295   11459   +7164
      i915_handle_error                           2979    6666   +3687
      i915_driver_irq_handler                     2923    5086   +2163
      i915_ringbuffer_info                         458    1661   +1203
      i915_save_vga                                  -    1200   +1200
      i915_driver_irq_uninstall                    453    1624   +1171
      i915_driver_irq_postinstall                  913    2078   +1165
      ironlake_enable_drps                         719    1872   +1153
      i915_restore_vga                               -    1142   +1142
      intel_display_capture_error_state            784    2030   +1246
      intel_init_emon                              719    2016   +1297
      
      and more ...
      
      [AK: these are older numbers, with the new SNB forcewake checks
      it will be even worse]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      f7000883
  10. 29 9月, 2011 1 次提交
  11. 28 9月, 2011 1 次提交
  12. 22 9月, 2011 1 次提交
  13. 20 9月, 2011 1 次提交
  14. 30 8月, 2011 1 次提交
  15. 05 8月, 2011 1 次提交
  16. 04 8月, 2011 1 次提交
  17. 14 7月, 2011 3 次提交
  18. 12 7月, 2011 1 次提交
  19. 09 7月, 2011 1 次提交
  20. 08 7月, 2011 1 次提交
  21. 30 6月, 2011 2 次提交
  22. 29 6月, 2011 1 次提交
    • B
      drm/i915: forcewake fix after reset · 25732821
      Ben Widawsky 提交于
      The failure is as follows:
      
      1. Userspace gets forcewake lock, lock count >=1
      2. GPU hang/reset occurs (forcewake bit is reset)
      3. count is now incorrect
      
      The failure can only occur when using the forcewake userspace lock.
      
      This has the unfortunate consequence of messing up the driver as well as
      userspace, unless userspace closes the debugfs file, the kernel will
      never end up waking the GT since the refcount will be > 1.
      
      The solution is to try to recover the correct forcewake state based on
      the refcount. There is a period of time where userspace reads/writes may
      occur after the reset, before the GT has been forcewaked. The interface
      was never designed to be a perfect solution for userspace reads/writes,
      and the kernel portion is fixed by this patch.
      Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      25732821
  23. 18 5月, 2011 2 次提交
  24. 16 5月, 2011 1 次提交
  25. 14 5月, 2011 4 次提交
  26. 11 5月, 2011 1 次提交
  27. 07 3月, 2011 1 次提交
  28. 06 3月, 2011 1 次提交
  29. 22 2月, 2011 1 次提交
  30. 10 2月, 2011 1 次提交
  31. 07 2月, 2011 1 次提交