1. 05 10月, 2017 2 次提交
  2. 29 9月, 2017 1 次提交
  3. 28 9月, 2017 1 次提交
  4. 26 9月, 2017 2 次提交
  5. 25 9月, 2017 2 次提交
  6. 22 9月, 2017 1 次提交
  7. 19 9月, 2017 1 次提交
  8. 15 9月, 2017 1 次提交
  9. 14 9月, 2017 3 次提交
    • Z
      drm/i915: Introduce private PAT management · 4395890a
      Zhi Wang 提交于
      The private PAT management is to support PPAT entry manipulation. Two
      APIs are introduced for dynamically managing PPAT entries: intel_ppat_get
      and intel_ppat_put.
      
      intel_ppat_get will search for an existing PPAT entry which perfectly
      matches the required PPAT value. If not, it will try to allocate a new
      entry if there is any available PPAT indexs, or return a partially
      matched PPAT entry if there is no available PPAT indexes.
      
      intel_ppat_put will put back the PPAT entry which comes from
      intel_ppat_get. If it's dynamically allocated, the reference count will
      be decreased. If the reference count turns into zero, the PPAT index is
      freed again.
      
      Besides, another two callbacks are introduced to support the private PAT
      management framework. One is ppat->update_hw(), which writes the PPAT
      configurations in ppat->entries into HW. Another one is ppat->match, which
      will return a score to show how two PPAT values match with each other.
      
      v17:
      
      - Refine the comparision of score of BDW. (Joonas)
      
      v16:
      
      - Fix a bug in PPAT match function of BDW. (Joonas)
      
      v15:
      
      - Refine some code flow. (Joonas)
      
      v12:
      
      - Fix a problem "not returning the entry of best score". (Zhenyu)
      
      v7:
      
      - Keep all the register writes unchanged in this patch. (Joonas)
      
      v6:
      
      - Address all comments from Chris:
      http://www.spinics.net/lists/intel-gfx/msg136850.html
      
      - Address all comments from Joonas:
      http://www.spinics.net/lists/intel-gfx/msg136845.html
      
      v5:
      
      - Add check and warnnings for those platforms which don't have PPAT.
      
      v3:
      
      - Introduce dirty bitmap for PPAT registers. (Chris)
      - Change the name of the pointer "dev_priv" to "i915". (Chris)
      - intel_ppat_{get, put} returns/takes a const intel_ppat_entry *. (Chris)
      
      v2:
      
      - API re-design. (Chris)
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v7
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      [Joonas: Use BIT() in the enum in bdw_private_pat_match]
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1505392783-4084-1-git-send-email-zhi.a.wang@intel.com
      4395890a
    • J
      drm/i915: Introduce INTEL_GEN_MASK · fe52e597
      Joonas Lahtinen 提交于
      Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable
      within static declarations (unlike compound statements).
      
      v2:
      - s/combound/compound/ (Tvrtko)
      - Fix whitespace (yes, we need automatic checkpatch.pl)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170913115255.13851-1-joonas.lahtinen@linux.intel.com
      fe52e597
    • C
      drm/i915/execlists: Read the context-status HEAD from the HWSP · 767a983a
      Chris Wilson 提交于
      The engine also provides a mirror of the CSB write pointer in the HWSP,
      but not of our read pointer. To take advantage of this we need to
      remember where we read up to on the last interrupt and continue off from
      there. This poses a problem following a reset, as we don't know where
      the hw will start writing from, and due to the use of power contexts we
      cannot perform that query during the reset itself. So we continue the
      current modus operandi of delaying the first read of the context-status
      read/write pointers until after the first interrupt. With this we should
      now have eliminated all uncached mmio reads in handling the
      context-status interrupt, though we still have the uncached mmio writes
      for submitting new work, and many uncached mmio reads in the global
      interrupt handler itself. Still a step in the right direction towards
      reducing our resubmit latency, although it appears lost in the noise!
      
      v2: Cannonlake moved the CSB write index
      v3: Include the sw/hwsp state in debugfs/i915_engine_info
      v4: Also revert to using CSB mmio for GVT-g
      v5: Prevent the compiler reloading tail (Mika)
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Acked-by: NMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-6-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      767a983a
  10. 13 9月, 2017 1 次提交
  11. 12 9月, 2017 5 次提交
  12. 08 9月, 2017 1 次提交
  13. 07 9月, 2017 7 次提交
  14. 04 9月, 2017 1 次提交
  15. 01 9月, 2017 4 次提交
  16. 31 8月, 2017 1 次提交
    • C
      drm/i915: Recreate vmapping even when the object is pinned · 3b24e7e8
      Chris Wilson 提交于
      Sometimes we know we are the only user of the bo, but since we take a
      protective pin_pages early on, an attempt to change the vmap on the
      object is denied because it is busy. i915_gem_object_pin_map() cannot
      tell from our single pin_count if the operation is safe. Instead we must
      pass that information down from the caller in the manner of
      I915_MAP_OVERRIDE.
      
      This issue has existed from the introduction of the mapping, but was
      never noticed as the only place where this conflict might happen is for
      cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
      Until recently there was only a single user (the cmdparser) so no
      conflicts ever occurred. However, we now use it to allocate batches for
      different operations (using MAP_WC on !llc for writes) in addition to the
      existing shadow batch (using MAP_WB for reads).
      
      We could either keep both mappings cached, or use a different write
      mechanism if we detect a MAP_WB already exists (i.e. clflush
      afterwards), but as we haven't seen this issue in the wild (it requires
      hitting the GPU reloc path in addition to the cmdparser) for simplicity
      just allow the mappings to be recreated.
      
      v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
      about all the valid values.
      
      Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing")
      Testcase: igt/gem_lut_handle # byt, completely by accident
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170828104631.8606-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit a575c676)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      3b24e7e8
  17. 29 8月, 2017 1 次提交
    • C
      drm/i915: Recreate vmapping even when the object is pinned · a575c676
      Chris Wilson 提交于
      Sometimes we know we are the only user of the bo, but since we take a
      protective pin_pages early on, an attempt to change the vmap on the
      object is denied because it is busy. i915_gem_object_pin_map() cannot
      tell from our single pin_count if the operation is safe. Instead we must
      pass that information down from the caller in the manner of
      I915_MAP_OVERRIDE.
      
      This issue has existed from the introduction of the mapping, but was
      never noticed as the only place where this conflict might happen is for
      cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
      Until recently there was only a single user (the cmdparser) so no
      conflicts ever occurred. However, we now use it to allocate batches for
      different operations (using MAP_WC on !llc for writes) in addition to the
      existing shadow batch (using MAP_WB for reads).
      
      We could either keep both mappings cached, or use a different write
      mechanism if we detect a MAP_WB already exists (i.e. clflush
      afterwards), but as we haven't seen this issue in the wild (it requires
      hitting the GPU reloc path in addition to the cmdparser) for simplicity
      just allow the mappings to be recreated.
      
      v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
      about all the valid values.
      
      Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing")
      Testcase: igt/gem_lut_handle # byt, completely by accident
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170828104631.8606-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      a575c676
  18. 26 8月, 2017 1 次提交
  19. 25 8月, 2017 1 次提交
  20. 23 8月, 2017 1 次提交
  21. 19 8月, 2017 1 次提交
  22. 18 8月, 2017 1 次提交
    • C
      drm/i915: Replace execbuf vma ht with an idr · d1b48c1e
      Chris Wilson 提交于
      This was the competing idea long ago, but it was only with the rewrite
      of the idr as an radixtree and using the radixtree directly ourselves,
      along with the realisation that we can store the vma directly in the
      radixtree and only need a list for the reverse mapping, that made the
      patch performant enough to displace using a hashtable. Though the vma ht
      is fast and doesn't require any extra allocation (as we can embed the node
      inside the vma), it does require a thread for resizing and serialization
      and will have the occasional slow lookup. That is hairy enough to
      investigate alternatives and favour them if equivalent in peak performance.
      One advantage of allocating an indirection entry is that we can support a
      single shared bo between many clients, something that was done on a
      first-come first-serve basis for shared GGTT vma previously. To offset
      the extra allocations, we create yet another kmem_cache for them.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-5-chris@chris-wilson.co.uk
      d1b48c1e