1. 04 1月, 2013 20 次提交
  2. 03 1月, 2013 1 次提交
  3. 30 12月, 2012 7 次提交
  4. 23 12月, 2012 8 次提交
  5. 22 12月, 2012 1 次提交
  6. 20 12月, 2012 3 次提交
    • D
      drm/i915: disable shrinker lock stealing for create_mmap_offset · da494d7c
      Daniel Vetter 提交于
      The mmap offset structure is not part of the drm/i915 code, but
      provided by gem helpers. To avoid leaky abstractions (by either
      depending upon implementation details of said helper wrt to
      preallocations, or reimplementing it in our code and so fuzzing
      around in internal details of that helpr) simply disable
      the shrinker lock stealing accross calls into the helper functions.
      
      This should fix igt/gem_tiled_swapping.
      
      v2: Fix cleanup path confusion bemoaned by Chris Wilson.
      Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      da494d7c
    • D
      drm/i915: optionally disable shrinker lock stealing · 677feac2
      Daniel Vetter 提交于
      commit 5774506f
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed Nov 21 13:04:04 2012 +0000
      
          drm/i915: Borrow our struct_mutex for the direct reclaim
      
      added a nice trick to steal the struct_mutex lock in the shrinker if
      it's the current task holding it. But this also caused the requirement
      that every place which allocates memory needs to be careful about the
      gem state of objects, since the shrinker could have pulled the rug out
      from under it. We've usually solved this by carefully preallocating
      things or ensure that buffers are pinned already.
      
      But the shrinker also reaps mmap offset, so allocating those needs to
      be careful, too. Now that code has been factored out into some common
      helpers, so either we have fragile code depending upon the common
      helper not doing something we don't want it to do. Or we need to
      reimplement the mmap offset creation and so also leak implementation
      details into our code.
      
      Since this all results in leaky abstraction, cop out by disabling the
      lock borrowing trick while calling down into the helpers. That way our
      craziness is nicely confined to files in drm/i915.
      
      v2: Split out the change to create_mmap_offset as request by Chris Wilson.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      677feac2
    • D
      drm/i915: fix flags in dma buf exporting · 5b42427f
      Dave Airlie 提交于
      As pointed out by Seung-Woo Kim this should have been
      passing flags like nouveau/radeon have.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5b42427f