1. 29 10月, 2016 4 次提交
  2. 24 10月, 2016 1 次提交
  3. 14 10月, 2016 2 次提交
  4. 19 8月, 2016 2 次提交
  5. 15 8月, 2016 2 次提交
  6. 05 8月, 2016 5 次提交
  7. 04 8月, 2016 3 次提交
  8. 20 7月, 2016 3 次提交
  9. 04 7月, 2016 1 次提交
  10. 17 5月, 2016 1 次提交
  11. 11 5月, 2016 1 次提交
  12. 04 5月, 2016 1 次提交
  13. 18 11月, 2015 1 次提交
  14. 30 7月, 2015 1 次提交
    • C
      drm/i915: Declare the swizzling unknown for L-shaped configurations · 5eb3e5a5
      Chris Wilson 提交于
      The old style of memory interleaving swizzled upto the end of the
      first even bank of memory, and then used the remainder as unswizzled on
      the unpaired bank - i.e. swizzling is not constant for all memory. This
      causes problems when we try to migrate memory and so the kernel prevents
      migration at all when we detect L-shaped inconsistent swizzling.
      However, this issue also extends to userspace who try to manually detile
      into memory as the swizzling for an individual page is unknown (it
      depends on its physical address only known to the kernel), userspace
      cannot correctly swizzle.
      
      Note that this is a new attempt for the previously merged one,
      reverted in
      
      commit d82c0ba6
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Jul 14 12:29:27 2015 +0200
      
          Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"
      
      This is cc: stable since we need it to fix up troubles with wc cpu
      mmaps that userspace recently started to use widely.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [danvet: Add note about previous (failed attempt).]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5eb3e5a5
  15. 27 7月, 2015 2 次提交
  16. 14 7月, 2015 1 次提交
  17. 09 7月, 2015 1 次提交
    • C
      drm/i915: Declare the swizzling unknown for L-shaped configurations · 19ee835c
      Chris Wilson 提交于
      The old style of memory interleaving swizzled upto the end of the
      first even bank of memory, and then used the remainder as unswizzled on
      the unpaired bank - i.e. swizzling is not constant for all memory. This
      causes problems when we try to migrate memory and so the kernel prevents
      migration at all when we detect L-shaped inconsistent swizzling.
      However, this issue also extends to userspace who try to manually detile
      into memory as the swizzling for an individual page is unknown (it
      depends on its physical address only known to the kernel), userspace
      cannot correctly swizzle objects.
      
      v2: Mark the global swizzling as unknown rather than adjust the value
      reported to userspace.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      19ee835c
  18. 16 4月, 2015 1 次提交
  19. 24 2月, 2015 1 次提交
  20. 03 12月, 2014 1 次提交
  21. 20 11月, 2014 1 次提交
  22. 11 11月, 2014 1 次提交
    • C
      drm/i915: Fix obj->map_and_fenceable across tiling changes · e9d784d5
      Chris Wilson 提交于
      As obj->map_and_fenceable computation has changed to only be set when
      the object is bound inside the global GTT (and is suitable aligned to a
      fence region) we need to accommodate those changes when the tiling is
      adjusted. The easiest solution is to unbind from the global GTT if we
      are currently fenceable, but will not be after the tiling change.
      
      The bug has been exposed by
      
      commit f8fcadba218fe6d23b2e353fea1cf0a4be4c9454
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Oct 31 13:53:52 2014 +0000
      
          drm/i915: Only mark as map-and-fenceable when bound into the GGTT
      
      which tried to fix an oversight from
      
      commit e6a84468
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Mon Aug 11 12:00:12 2014 +0200
      
          drm/i915: Force CPU relocations if not GTT mapped
      
      which changed the handling of obj->map_and_fenceable.
      
      Note that the alignment check is a vestige from our attempts to reduce
      the alignment requirements of tiled but unfenced buffers on
      gen2/3. Also, that was when unbinding from the GTT meant UC writes and
      clflushing, so we went to great pains to avoid such.
      
      That leaves the actual bug of setting map_and_fenceable to true if we're
      not bound to ggtt, which violates the change introduced in the above
      patch. Unbinding in that case really looks like the simplest and safest
      option, we have to do it anyway.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85896
      Testcase: igt/gem_concurrent_blit/gttX*
      Tested-by: huax.lu@intel.com
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: NValtteri Rantala <valtteri.rantala@intel.com>
      [Jani: amend commit message per input from Daniel and bisect result from
      Valtteri]
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      e9d784d5
  23. 08 11月, 2014 1 次提交
  24. 24 10月, 2014 1 次提交
    • J
      drm/i915: preserve swizzle settings if necessary v4 · d9ceb816
      Jesse Barnes 提交于
      Some machines (like MBAs) might use a tiled framebuffer but not enable
      display swizzling at boot time.  We want to preserve that configuration
      if possible to prevent a boot time mode set.  On IVB+ it shouldn't
      affect performance anyway since the memory controller does internal
      swizzling anyway.
      
      For most other configs we'll be able to enable swizzling at boot time,
      since the initial framebuffer won't be tiled, thus we won't see any
      corruption when we enable it.
      
      v2: preserve swizzling if BIOS had it set (Daniel)
      v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel)
          check display swizzle setting in detect_bit_6_swizzle (Daniel)
          use gen6 as cutoff point (Daniel)
      v4: fixup swizzle preserve again, had wrong init order (Daniel)
      Reported-by: NKristian Høgsberg <hoegsberg@gmail.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d9ceb816
  25. 03 9月, 2014 1 次提交
    • D
      drm/i915/bdw: Let the memory controller do all the swizzling · be292e15
      Damien Lespiau 提交于
      Previously, it was possible for the GPU memory accesses to be swizzled
      to try to optimize the fetches for tiled buffers. This swizzling was on
      top of what the memory controller in the uncore already does.
      
      With broadwell, we drop that GPU side swizzling, and the corresponding
      initialization in 3 units (GAM, GT, DE). All those bits are reserved, as
      specs put it:
      
        Before Gen8, there was a historical configuration control field to
        swizzle address bit[6] for in X/Y tiling modes. This was set in three
        different places: TILECTL[1:0], ARB_MODE[5:4], and
        DISP_ARB_CTL[14:13]"
      
        For Gen8 the swizzle fields are all reserved, and the CPU's memory
        controller performs all address swizzling modifications.
      
      This also means that user space doesn't have to manually swizzle when
      accessing tiled buffers from the CPU, and so we always return
      I915_BIT_6_SWIZZLE_NONE from i915_gem_detect_bit_6_swizzle(), which
      short-circuits the initialization of the registers mentionned above in
      i915_gem_init_swizzling().
      
      v2: Refine the explanation a bit more (Daniel)
      v3: Make it BDW+ specific (Steve)
      
      Cc: Steve Aarnio <steve.j.aarnio@linux.intel.com>
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      [danvet: Keep the actual code to set the tiling bits for now, in case
      some bios escaped to the wild that uses this - we'd need it for
      fastboot.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      be292e15