1. 03 8月, 2016 3 次提交
  2. 02 8月, 2016 1 次提交
    • K
      drm/i915: cleanup_plane_fb: also drop reference to current state wait_req · 84978257
      Keith Packard 提交于
      There are two paths into intel_cleanup_plane_fb, the normal completion
      path and the failure path.
      
      In the failure case, intel_cleanup_plane_fb is called before
      drm_atomic_helper_swap_state, so any wait_req reference made in
      intel_prepare_plane_fb will be in old_intel_state->wait_req.
      
      In the normal completion path, drm_atomic_helper_swap_state has
      already been called, so the plane state holding the just-used wait_req
      will not be in old_intel_state->wait_req, rather it will be in the
      state associated with the plane itself.
      
      Clearing this reference ensures that the wait_req will be freed as
      soon as it the related mode setting operation is complete, rather than
      waiting for some future mode setting operation to eventually
      dereference it.
      
      The existing dereference of old_intel_state->wait_req is still
      required as that will hold the wait_req when the mode setting
      operation fails.
      
      cc: Daniel Vetter <daniel.vetter@intel.com>
      cc: David Airlie <airlied@linux.ie>
      cc: intel-gfx@lists.freedesktop.org
      cc: dri-devel@lists.freedesktop.org
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      84978257
  3. 27 7月, 2016 1 次提交
  4. 22 7月, 2016 2 次提交
  5. 20 7月, 2016 6 次提交
  6. 18 7月, 2016 1 次提交
  7. 15 7月, 2016 1 次提交
  8. 14 7月, 2016 1 次提交
    • C
      drm/i915: Defer enabling rc6 til after we submit the first batch/context · b7137e0c
      Chris Wilson 提交于
      Some hardware requires a valid render context before it can initiate
      rc6 power gating of the GPU; the default state of the GPU is not
      sufficient and may lead to undefined behaviour. The first execution of
      any batch will load the "golden render state", at which point it is safe
      to enable rc6. As we do not forcibly load the kernel context at resume,
      we have to hook into the batch submission to be sure that the render
      state is setup before enabling rc6.
      
      However, since we don't enable powersaving until that first batch, we
      queued a delayed task in order to guarantee that the batch is indeed
      submitted.
      
      v2: Rearrange intel_disable_gt_powersave() to match.
      v3: Apply user specified cur_freq (or idle_freq if not set).
      v4: Give in, and supply a delayed work to autoenable rc6
      v5: Mika suggested a couple of better names for delayed_resume_work
      v6: Rebalance rpm_put around the autoenable task
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468397438-21226-7-git-send-email-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      b7137e0c
  9. 08 7月, 2016 1 次提交
  10. 07 7月, 2016 8 次提交
  11. 05 7月, 2016 1 次提交
  12. 04 7月, 2016 3 次提交
  13. 03 7月, 2016 1 次提交
  14. 02 7月, 2016 1 次提交
    • C
      drm/i915: Spin after waking up for an interrupt · f69a02c9
      Chris Wilson 提交于
      When waiting for an interrupt (waiting for the engine to complete some
      work), we know we are the only waiter to be woken on this engine. We also
      know when the GPU has nearly completed our request (or at least started
      processing it), so after being woken and we detect that the GPU is
      active and working on our request, allow us the bottom-half (the first
      waiter who wakes up to handle checking the seqno after the interrupt) to
      spin for a very short while to reduce client latencies.
      
      The impact is minimal, there was an improvement to the realtime-vs-many
      clients case, but exporting the function proves useful later. However,
      it is tempting to adjust irq_seqno_barrier to include the spin. The
      problem is first ensuring that the "start-of-request" seqno is coherent
      as we use that as our basis for judging when it is ok to spin. If we
      could, spinning there could dramatically shorten some sleeps, and allow
      us to make the barriers more conservative to handle missed seqno writes
      on more platforms (all gen7+ are known to have the occasional issue, at
      least).
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-7-git-send-email-chris@chris-wilson.co.uk
      f69a02c9
  15. 30 6月, 2016 9 次提交