1. 01 Jun, 2020 5 commits
    • Chris Wilson's avatar
      drm/i915: Trim the ironlake+ irq handler · c48a798a
      Chris Wilson authored
      Ever noticed that our interrupt handlers are where we spend most of our
      time on a busy system? In part this is unavoidable as each interrupt
      requires to poll and reset several registers, but we can try and do so as
      efficiently as possible.
      
      Function                                     old     new   delta
      ilk_irq_handler                             2317    2156    -161
      
      v2: Restore the irqreturn_t ret
      
      Function                                     old     new   delta
      ilk_irq_handler.cold                          63      72      +9
      ilk_irq_handler                             2221    2080    -141
      
      A slight improvement in the baseline overnight as well!
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200601140355.20243-1-chris@chris-wilson.co.uk
      c48a798a
    • Ville Syrjälä's avatar
      drm/i915: Fix global state use-after-frees with a refcount · f8c86ffa
      Ville Syrjälä authored
      While the current locking/serialization of the global state
      suffices for protecting the obj->state access and the actual
      hardware reprogramming, we do have a problem with accessing
      the old/new states during nonblocking commits.
      
      The state computation and swap will be protected by the crtc
      locks, but the commit_tails can finish out of order, thus also
      causing the atomic states to be cleaned up out of order. This
      would mean the commit that started first but finished last has
      had its new state freed as the no-longer-needed old state by the
      other commit.
      
      To fix this let's just refcount the states. obj->state amounts
      to one reference, and the intel_atomic_state holds extra references
      to both its new and old global obj states.
      
      Fixes: 0ef1905e ("drm/i915: Introduce better global state handling")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200527200245.13184-1-ville.syrjala@linux.intel.comReviewed-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      f8c86ffa
    • Chris Wilson's avatar
      drm/i915: Relinquish forcewake immediately after manual grouping · 03c10f47
      Chris Wilson authored
      Our forcewake utilisation is split into categories: automatic and
      manual. Around bare register reads, we look up the right forcewake
      domain and automatically acquire and release [upon a timer] the
      forcewake domain. For other access, where we know we require the
      forcewake across a group of register reads, we manually acquire the
      forcewake domain and release it at the end. Again, this currently arms
      the domain timer for a later release.
      
      However, looking at some energy utilisation profiles, we have tried to
      avoid using forcewake [and rely on the natural wake up to post register
      updates] due to that even keep the fw active for a brief period
      contributes to a significant power draw [i.e. when the gpu is sleeping
      with rc6 at high clocks]. But as it turns out, not posting the writes
      immediately also has unintended consequences, such as not reducing the
      clocks and so conserving power while busy.
      
      As a compromise, let us only arm the domain timer for automatic
      forcewake usage around bare register access, but immediately release the
      forcewake when manually acquired by intel_uncore_forcewake_get/_put.
      
      The corollary to this is that we may instead have to take forcewake more
      often, and so incur a latency penalty in doing so. For Sandybridge this
      was significant, and even on the latest machines, taking forcewake at
      interrupt frequency is a huge impact. [So we don't do that anymore!
      Hopefully, this will spare us from still needing the mitigation of the
      timer for steady state execution.]
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200601072446.19548-13-chris@chris-wilson.co.uk
      03c10f47
    • Chris Wilson's avatar
      drm/i915: Handle very early engine initialisation failure · 0b0b2549
      Chris Wilson authored
      If we fail during engine setup, we may leave some engines not yet setup.
      During the error cleanup, we have to be careful not to try and use the
      uninitialise engines before discarding them.
      
      [   16.136152] RIP: 0010:__flush_work+0x198/0x1b0
      [   16.136168] Code: ff ff 8b 0b 48 8b 53 08 83 e1 08 48 0f ba 2b 03 80 c9 f0 e9 63 ff ff ff 0f 0b 48 83 c4 48 44 89 f0 5b 5d 41 5c 41 5d 41 5e c3 <0f> 0b 45 31 f6 e9 62 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f
      [   16.136186] RSP: 0018:ffffc900003bb928 EFLAGS: 00010246
      [   16.136201] RAX: 0000000000000000 RBX: ffff88844f392168 RCX: 0000000000000000
      [   16.136216] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88844f392168
      [   16.136231] RBP: ffff88844f392130 R08: 0000000000000000 R09: 0000000000000001
      [   16.136246] R10: ffff888441e31e40 R11: ffff88845e329c70 R12: ffff88844f796988
      [   16.136261] R13: ffff888441e4fb80 R14: 0000000000000001 R15: ffff88844f790000
      [   16.136388] FS:  00007fecbd208880(0000) GS:ffff88845e380000(0000) knlGS:0000000000000000
      [   16.136405] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   16.136420] CR2: 00007ff3ce748f90 CR3: 0000000457a6a001 CR4: 00000000000606e0
      [   16.136437] Call Trace:
      [   16.136456]  ? try_to_del_timer_sync+0x3a/0x50
      [   16.136529]  intel_wakeref_wait_for_idle+0x87/0xb0 [i915]
      [   16.136606]  ? intel_engines_release+0x68/0xc0 [i915]
      [   16.136680]  intel_engines_release+0x49/0xc0 [i915]
      [   16.136757]  intel_gt_init+0x2f4/0x5e0 [i915]
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200601072446.19548-1-chris@chris-wilson.co.uk
      0b0b2549
    • Kishore Kadiyala's avatar
      drm/i915: Add Plane color encoding support for YCBCR_BT2020 · a0196dd6
      Kishore Kadiyala authored
      Currently the plane property doesn't have support for YCBCR_BT2020,
      which enables the corresponding color conversion mode on plane CSC.
      Enabling the plane property for the planes for GLK & ICL+ platforms.
      Also as per spec, update the Plane Color CSC from YUV601_TO_RGB709
      to YUV601_TO_RGB601.
      
      V2: Enabling support for YCBCT_BT2020 for HDR planes on
          platforms GLK & ICL
      
      V3: Refined the condition check to handle GLK & ICL+ HDR planes
          Also added BT2020 handling in glk_plane_color_ctl.
      
      V4: Combine If-else into single If
      
      V5: Drop the checking for HDR planes and enable YCBCR_BT2020
          for platforms GLK & ICL+.
      
      V6: As per Spec, update PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709
          to PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 as per Ville's
          feedback.
      
      V7: Rebased
      
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Reviewed-by: default avatarUma Shankar <uma.shankar@intel.com>
      Signed-off-by: default avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Signed-off-by: default avatarUma Shankar <uma.shankar@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200601073544.11291-1-kishore.kadiyala@intel.com
      a0196dd6
  2. 29 May, 2020 6 commits
  3. 28 May, 2020 5 commits
  4. 27 May, 2020 5 commits
  5. 26 May, 2020 5 commits
  6. 25 May, 2020 3 commits
  7. 23 May, 2020 1 commit
    • Animesh Manna's avatar
      drm/i915/dsb: Pre allocate and late cleanup of cmd buffer · afeda4f3
      Animesh Manna authored
      Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
      function which also includes pinning and map in cpu domain.
      
      No functional change is dsb write/commit functions.
      
      Now dsb get/put function is removed and ref-count mechanism is
      not needed. Below dsb api added to do respective job mentioned
      below.
      
      intel_dsb_prepare - Allocate, pin and map the buffer.
      intel_dsb_cleanup - Unpin and release the gem object.
      
      RFC: Initial patch for design review.
      v2: included _init() part in _prepare(). [Daniel, Ville]
      v3: dsb_cleanup called after cleanup_planes. [Daniel]
      v4: dsb structure is moved to intel_crtc_state from intel_crtc. [Maarten]
      v5: dsb get/put/ref-count mechanism removed. [Maarten]
      v6: Based on review feedback following changes are added,
      - replaced intel_dsb structure by pointer in intel_crtc_state. [Maarten]
      - passing intel_crtc_state to dsp-api to simplify the code. [Maarten]
      - few dsb functions prototype modified to simplify code.
      v7: added few cosmetic changes suggested by Jani and null check for
      crtc_state in dsb_cleanup removed as suggested by Maarten.
      v8: changed the function parameter to intel_crtc_state* of
      ivb_load_lut_ext_max() from intel_crtc. [Maarten]
      v9: error handling improved in _write() and prepare(). [Maarten]
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@intel.com>
      Signed-off-by: default avatarAnimesh Manna <animesh.manna@intel.com>
      Signed-off-by: default avatarUma Shankar <uma.shankar@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200520130737.11240-1-animesh.manna@intel.com
      afeda4f3
  8. 22 May, 2020 4 commits
  9. 21 May, 2020 6 commits