1. 15 6月, 2018 9 次提交
  2. 14 6月, 2018 10 次提交
  3. 13 6月, 2018 4 次提交
  4. 12 6月, 2018 12 次提交
  5. 11 6月, 2018 5 次提交
    • C
      drm/i915: Wrap around the tail offset before setting ring->tail · 41d37680
      Chris Wilson 提交于
      The HW only accepts offsets within ring->size, and fails peculiarly if
      the RING_HEAD or RING_TAIL is set to ring->size. Therefore whenever we
      set ring->head/ring->tail we want to make sure it is within value (using
      intel_ring_wrap()).
      
      v2: Double check execlists as well
      v3: Remove redundancy with assert_ring_tail_valid()
      v4: Just assert in intel_ring_reset() rather than be over-defensive.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v2
      Link: https://patchwork.freedesktop.org/patch/msgid/20180611110845.31890-2-chris@chris-wilson.co.uk
      41d37680
    • C
      drm/i915/ringbuffer: Fix context restore upon reset · b3ee09a4
      Chris Wilson 提交于
      The discovery with trying to enable full-ppgtt was that we were
      completely failing to the load both the mm and context following the
      reset. Although we were performing mmio to set the PP_DIR (per-process
      GTT) and CCID (context), these were taking no effect (the assumption was
      that this would trigger reload of the context and restore the page
      tables). It was not until we performed the LRI + MI_SET_CONTEXT in a
      following context switch would anything occur.
      
      Since we are then required to reset the context image and PP_DIR using
      CS commands, we place those commands into every batch. The hardware
      should recognise the no-ops and eliminate the expensive context loads,
      but we still have to pay the cost of using cross-powerwell register
      writes. In practice, this has no effect on actual context switch times,
      and only adds a few hundred nanoseconds to no-op switches. We can improve
      the latter by eliminating the w/a around known no-op switches, but there
      is an ulterior motive to keeping them.
      
      Always emitting the context switch at the beginning of the request (and
      relying on HW to skip unneeded switches) does have one key advantage.
      Should we implement request reordering on Haswell, we will not know in
      advance what the previous executing context was on the GPU and so we
      would not be able to elide the MI_SET_CONTEXT commands ourselves and
      always have to emit them. Having our hand forced now actually prepares
      us for later.
      
      Now since that context and mm follow the request, we no longer (and not
      for a long time since requests took over!) require a trace point to tell
      when we write the switch into the ring, since it is always. (This is
      even more important when you remember that simply writing into the ring
      bears no relation to the current mm.)
      
      v2: Sandybridge has to agree to use LRI as well.
      
      Testcase: igt/drv_selftests/live_hangcheck
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180611110845.31890-1-chris@chris-wilson.co.uk
      b3ee09a4
    • C
      drm/i915/ringbuffer: Brute force context restore · 1fc719d1
      Chris Wilson 提交于
      An issue encountered with switching mm on gen7 is that the GPU likes to
      hang (with the VS unit busy) when told to force restore the current
      context. We can simply workaround this by substituting the
      MI_FORCE_RESTORE flag with a round-trip through the kernel_context,
      forcing the context to be saved and restored; thereby reloading the
      PP_DIR registers and updating the modified page directory!
      
      v2: Undo attempted optimisation in caller (Tvrtko)
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180611104808.24295-1-chris@chris-wilson.co.uk
      1fc719d1
    • I
      drm/i915/skl: Add warn about unsupported CDCLK rates · 602a9de5
      Imre Deak 提交于
      While checking workarounds related to the CDCLK PLL, I noticed that the
      DMC firmware bits for WA#1183 are missing for SKL. After that I
      clarified with HW people that it's not needed on SKL, since it doesn't
      support eDP1.4 which would be the only thing requiring the problematic
      CDCLK clock rates. So in theory we shouldn't ever choose these
      frequencies, but add an assert in any case for catching such cases and
      for documentation.
      
      v2:
      - Move the check to skl_set_cdclk and warn whenever using the
        corresponding VCO freq. (Ville)
      
      v3:
      - Actually check for the platform. (Ville)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180608144137.7943-1-imre.deak@intel.com
      602a9de5
    • M
      drm/i915/perf: fix gen11 engine class shift · 2b9a8203
      Michel Thierry 提交于
      Use the correct engine class shift value while storing the ctx hw id.
      Fixes the copy+paste error from commit 61d5676b ("drm/i915/perf: fix
      ctx_id read with GuC & ICL").
      
      Apologies for not spotting this in the original review, the
      specific_ctx_id_mask is correct, only the specific_ctx_id had this
      problem.
      
      v2: Just use the upper 32 bits of lrc_desc (Chris)
      v3: If we use the lrc_desc, we must apply the ctx_id_mask too (Lionel)
      
      Fixes: 61d5676b ("drm/i915/perf: fix ctx_id read with GuC & ICL")
      Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180604233250.609-2-michel.thierry@intel.com
      2b9a8203