1. 16 12月, 2014 1 次提交
  2. 15 12月, 2014 3 次提交
    • T
      drm/i915: Documentation for multiple GGTT views · 45f8f69a
      Tvrtko Ursulin 提交于
      A short section describing background, implementation and intended usage.
      
      v2:
          * Align section name between template and DOC comment. (Michel Thierry)
      
      For: VIZ-4544
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      45f8f69a
    • T
      drm/i915: Infrastructure for supporting different GGTT views per object · fe14d5f4
      Tvrtko Ursulin 提交于
      Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
      to map objects into the same address space multiple times.
      
      Added a GGTT view concept and linked it with the VMA to distinguish between
      multiple instances per address space.
      
      New objects and GEM functions which do not take this new view as a parameter
      assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the
      previous behaviour.
      
      This now means that objects can have multiple VMA entries so the code which
      assumed there will only be one also had to be modified.
      
      Alternative GGTT views are supposed to borrow DMA addresses from obj->pages
      which is DMA mapped on first VMA instantiation and unmapped on the last one
      going away.
      
      v2:
          * Removed per view special casing in i915_gem_ggtt_prepare /
            finish_object in favour of creating and destroying DMA mappings
            on first VMA instantiation and last VMA destruction. (Daniel Vetter)
          * Simplified i915_vma_unbind which does not need to count the GGTT views.
            (Daniel Vetter)
          * Also moved obj->map_and_fenceable reset under the same check.
          * Checkpatch cleanups.
      
      v3:
          * Only retire objects once the last VMA is unbound.
      
      v4:
          * Keep scatter-gather table for alternative views persistent for the
            lifetime of the VMA.
          * Propagate binding errors to callers and handle appropriately.
      
      v5:
          * Explicitly look for normal GGTT view in i915_gem_obj_bound to align
            usage in i915_gem_object_ggtt_unpin. (Michel Thierry)
          * Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry)
          * Removed stray semi-colon in i915_gem_object_set_cache_level.
      
      For: VIZ-4544
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      [danvet: Drop hunk from i915_gem_shrink since it's just prettification
      but upsets a __must_check warning.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      fe14d5f4
    • D
      drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON · 5f77eeb0
      Daniel Vetter 提交于
      Faster feedback to errors is always better. This is inspired by the
      addition to WARN_ONs to mask/enable helpers for registers to make sure
      callers have the arguments ordered correctly: Pretty much always the
      arguments are static.
      
      We use WARN_ON(1) a lot in default switch statements though where we
      should always handle all cases. So add a new macro specifically for
      that.
      
      The idea to use __builtin_constant_p is from Chris Wilson.
      
      v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
      Dave. My first attempt used __cond as the temp var, which is the same
      used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
      sprinkle i915 into the name.
      
      Also use a temporary variable to only evaluate the condition once,
      suggested by Damien.
      
      v3: It's crazy but apparently 32bit gcc can't compile out the
      BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
      why, but until clue grows just disable this nifty idea on 32bit
      builds. Reported by 0-day builder.
      
      v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
      Now reported by Imre.
      
      v5: Chris suggested to add the case to MISSING_CASE for speedier
      debug.
      
      v6: Even some gcc 4.9 versions don't see through the maze, so give up
      for now. Keep the skeleton and MISSING_CASE stuff though.
      
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      5f77eeb0
  3. 04 12月, 2014 1 次提交
  4. 20 11月, 2014 1 次提交
  5. 15 11月, 2014 2 次提交
  6. 14 11月, 2014 2 次提交
  7. 08 11月, 2014 1 次提交
  8. 07 11月, 2014 1 次提交
    • R
      drm/i915: Disable caches for Global GTT. · d6a8b72e
      Rodrigo Vivi 提交于
      Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
      So the only way to avoid screen corruptions is setting PAT 0 to Uncached.
      
      MOCS can still be used though. But if userspace is trusting PTE for
      cache selection the safest thing to do is to let caches disabled.
      
      BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry,
      so RTL will always use the value corresponding to pat_sel = 000"
      
      - System agent ggtt writes (i.e. cpu gtt mmaps) already work before
      this patch, i.e. the same uncached + snooping access like on gen6/7
      seems to be in effect.
      - So this just fixes blitter/render access. Again it looks like it's
      not just uncached access, but uncached + snooping. So we can still
      hold onto all our assumptions wrt cpu clflushing on LLC machines.
      
      v2: Cleaner patch as suggested by Chris.
      v3: Add Daniel's comment
      
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: James Ausmus <james.ausmus@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Stable@vger.kernel.org
      Tested-by: NJames Ausmus <james.ausmus@intel.com>
      Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      d6a8b72e
  9. 04 11月, 2014 1 次提交
  10. 24 10月, 2014 1 次提交
  11. 29 9月, 2014 1 次提交
  12. 24 9月, 2014 3 次提交
  13. 19 9月, 2014 3 次提交
  14. 03 9月, 2014 3 次提交
  15. 20 8月, 2014 1 次提交
    • O
      drm/i915/bdw: Don't write PDP in the legacy way when using LRCs · b7c71823
      Oscar Mateo 提交于
      This is mostly for correctness so that we know we are running the LR
      context correctly (this is, the PDPs are contained inside the context
      object).
      
      v2: Move the check to inside the enable PPGTT function. The switch
      happens in two places: the legacy context switch (that we won't hit
      when Execlists are enabled) and the PPGTT enable, which unfortunately
      we need. This would look much nicer if the ppgtt->enable was part of
      the ring init, where it logically belongs.
      
      v3: Move the check to the start of the enable PPGTT function.  None
      of the legacy PPGTT enabling is required when using LRCs as the
      PPGTT is enabled in the context descriptor and the PDPs are written
      in the LRC.
      
      v4: Clarify comment based on review feedback.
      Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
      Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      [danvet: Resolve conflicts with ppgtt_enable rework.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b7c71823
  16. 13 8月, 2014 8 次提交
  17. 12 8月, 2014 2 次提交
    • D
      drm/i915: Some cleanups for the ppgtt lifetime handling · ee960be7
      Daniel Vetter 提交于
      So when reviewing Michel's patch I've noticed a few things and cleaned
      them up:
      - The early checks in ppgtt_release are now redundant: The inactive
        list should always be empty now, so we can ditch these checks. Even
        for the aliasing ppgtt (though that's a different confusion) since
        we tear that down after all the objects are gone.
      - The ppgtt handling functions are splattered all over. Consolidate
        them in i915_gem_gtt.c, give them OCD prefixes and add wrappers for
        get/put.
      - There was a bit a confusion in ppgtt_release about whether it cares
        about the active or inactive list. It should care about them both,
        so augment the WARNINGs to check for both.
      
      There's still create_vm_for_ctx left to do, put that is blocked on the
      removal of ppgtt->ctx. Once that's done we can rename it to
      i915_ppgtt_create and move it to its siblings for handling ppgtts.
      
      v2: Move the ppgtt checks into the inline get/put functions as
      suggested by Chris.
      
      v3: Inline the now redundant ppgtt local variable.
      
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ee960be7
    • M
      drm/i915: vma/ppgtt lifetime rules · b9d06dd9
      Michel Thierry 提交于
      VMAs should take a reference of the address space they use.
      
      Now, when the fd is closed, it will release the ref that the context was
      holding, but it will still be referenced by any vmas that are still
      active.
      
      ppgtt_release() should then only be called when the last thing referencing
      it releases the ref, and it can just call the base cleanup and free the
      ppgtt.
      
      Note that with this we will extend the lifetime of ppgtts which
      contain shared objects. But all the non-shared objects will get
      removed as soon as they drop of the active list and for the shared
      ones the shrinker can eventually reap them. Since we currently can't
      evict ppgtt pagetables either I don't think that temporary leak is
      important.
      Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
      [danvet: Add note about potential ppgtt leak with this approach.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b9d06dd9
  18. 08 8月, 2014 1 次提交
  19. 07 8月, 2014 1 次提交
  20. 11 7月, 2014 1 次提交
  21. 17 6月, 2014 1 次提交
    • A
      drm/i915: Added write-enable pte bit supportt · 24f3a8cf
      Akash Goel 提交于
      This adds support for a write-enable bit in the entry of GTT.
      This is handled via a read-only flag in the GEM buffer object which
      is then used to see how to set the bit when writing the GTT entries.
      Currently by default the Batch buffer & Ring buffers are marked as read only.
      
      v2: Moved the pte override code for read-only bit to 'byt_pte_encode'. (Chris)
          Fixed the issue of leaving 'gt_old_ro' as unused. (Chris)
      
      v3: Removed the 'gt_old_ro' field, now setting RO bit only for Ring Buffers(Daniel).
      
      v4: Added a new 'flags' parameter to all the pte(gen6) encode & insert_entries functions,
          in lieu of overloading the cache_level enum (Daniel).
      
      v5: Removed the superfluous VLV check & changed the definition location of PTE_READ_ONLY flag (Imre)
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NAkash Goel <akash.goel@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      24f3a8cf
  22. 14 6月, 2014 1 次提交