1. 30 6月, 2011 1 次提交
    • K
      drm/i915: Hold struct_mutex during i915_save_state/i915_restore_state · d70bed19
      Keith Packard 提交于
      Lots of register access in these functions, some of which requires the
      struct mutex.
      
      These functions now hold the struct mutex across the calls to
      i915_save_display and i915_restore_display, and so the internal mutex
      calls in those functions have been removed. To ensure that no-one else
      was calling them (and hence violating the new required locking
      invarient), those functions have been made static.
      
      gen6_enable_rps locks the struct mutex, and so i915_restore_state
      unlocks the mutex around calls to that function.
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      d70bed19
  2. 29 6月, 2011 2 次提交
    • C
      drm/i915: Use chipset-specific irq installers · f01c22fd
      Chris Wilson 提交于
      Konstantin Belousov pointed out that 4697995b replaced the generic
      i915_driver_irq_*install() functions with chipset specific routines
      accessible only through driver->irq_*install(). So update the sanity
      check in i915_request_wait() to match.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      f01c22fd
    • 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
  3. 28 6月, 2011 3 次提交
    • H
      drm/i915: more struct_mutex locking · ecbec53b
      Hugh Dickins 提交于
      When auditing the locking in i915_gem.c (for a prospective change which
      I then abandoned), I noticed two places where struct_mutex is not held
      across GEM object manipulations that would usually require it.
      
      Since one is in initial setup and the other in driver unload, I'm
      guessing the mutex is not required for either; but post a patch in case
      it is.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ecbec53b
    • H
      drm/i915: use shmem_truncate_range · e2377fe0
      Hugh Dickins 提交于
      The interface to ->truncate_range is changing very slightly: once "tmpfs:
      take control of its truncate_range" has been applied, this can be applied.
       For now there is only a slight inefficiency while this remains unapplied,
      but it will soon become essential for managing shmem's use of swap.
      
      Change i915_gem_object_truncate() to use shmem_truncate_range() directly:
      which should also spare i915 later change if we switch from
      inode_operations->truncate_range to file_operations->fallocate.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e2377fe0
    • H
      drm/i915: use shmem_read_mapping_page · 5949eac4
      Hugh Dickins 提交于
      Soon tmpfs will stop supporting ->readpage and read_cache_page_gfp(): once
      "tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
      be applied to ease the transition.
      
      Make i915_gem_object_get_pages_gtt() use shmem_read_mapping_page_gfp() in
      the one place it's needed; elsewhere use shmem_read_mapping_page(), with
      the mapping's gfp_mask properly initialized.
      
      Forget about __GFP_COLD: since tmpfs initializes its pages with memset,
      asking for a cold page is counter-productive.
      
      Include linux/shmem_fs.h also in drm_gem.c: with shmem_file_setup() now
      declared there too, we shall remove the prototype from linux/mm.h later.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5949eac4
  4. 27 6月, 2011 2 次提交
  5. 23 6月, 2011 1 次提交
  6. 22 6月, 2011 3 次提交
  7. 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
  8. 17 6月, 2011 1 次提交
  9. 14 6月, 2011 1 次提交
  10. 05 6月, 2011 11 次提交
  11. 25 5月, 2011 1 次提交
  12. 19 5月, 2011 1 次提交
  13. 18 5月, 2011 4 次提交
  14. 17 5月, 2011 2 次提交
  15. 16 5月, 2011 1 次提交
  16. 14 5月, 2011 5 次提交