1. 03 9月, 2021 1 次提交
  2. 19 8月, 2021 1 次提交
    • M
      drm/i915/dg2: Maintain backward-compatible nested batch behavior · 9e9dfd08
      Matt Roper 提交于
      For tgl+, the per-context setting of MI_MODE[12] determines whether
      the bits of a nested MI_BATCH_BUFFER_START instruction should be
      interpreted in the traditional manner or whether they should
      instead use a new tgl+ meaning that breaks backward compatibility, but
      allows nesting into 3rd-level batchbuffers.  For previous platforms,
      the hardware default for this register bit is to maintain
      backward-compatible behavior unless a context intentionally opts into
      the new behavior; however Xe_HPG flips the hardware default behavior.
      
      From a SW perspective, we want to maintain the backward-compatible
      behavior for userspace, so we'll apply a fake workaround to set it back
      to the legacy behavior on platforms where the hardware default is to
      break compatibility.  At the moment there is no Linux userspace that
      utilizes third-level batchbuffers, so this will avoid userspace from
      needing to make any changes.  using the legacy meaning is the correct
      thing to do.  If/when we have userspace consumers that want to utilize
      third-level batch nesting, we can provide a context parameter to allow
      them to opt-in.
      
      Bspec: 45974, 45718
      Cc: John Harrison <John.C.Harrison@Intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210805163647.801064-9-matthew.d.roper@intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
      9e9dfd08
  3. 13 8月, 2021 1 次提交
  4. 11 8月, 2021 2 次提交
  5. 05 8月, 2021 2 次提交
  6. 04 8月, 2021 3 次提交
  7. 28 7月, 2021 1 次提交
  8. 26 7月, 2021 1 次提交
  9. 24 7月, 2021 3 次提交
  10. 23 7月, 2021 3 次提交
  11. 07 7月, 2021 1 次提交
  12. 09 6月, 2021 1 次提交
  13. 07 6月, 2021 1 次提交
  14. 28 5月, 2021 1 次提交
    • A
      drm/i915: Add Wa_14010733141 · 5b26d57f
      Aditya Swarup 提交于
      The WA requires the following procedure for VDBox SFC reset:
      
      If (MFX-SFC usage is 1) {
      	1.Issue a MFX-SFC forced lock
      	2.Wait for MFX-SFC forced lock ack
      	3.Check the MFX-SFC usage bit
      	If (MFX-SFC usage bit is 1)
      		Reset VDBOX and SFC
      	else
      		Reset VDBOX
      	Release the force lock MFX-SFC
      }
      else if(HCP+SFC usage is 1) {
      	1.Issue a VE-SFC forced lock
      	2.Wait for SFC forced lock ack
      	3.Check the VE-SFC usage bit
      	If (VE-SFC usage bit is 1)
      		Reset VDBOX
      	else
      		Reset VDBOX and SFC
      	Release the force lock VE-SFC.
      }
      else
      	Reset VDBOX
      
      - Restructure: the changes to the original code flow should stay
        relatively minimal; we only need to do an extra HCP check after the
        usual VD-MFX check and, if true, switch the register/bit we're
        performing the lock on.(MattR)
      
      v2:
      - Assign unlock mask using paired_engine->mask instead of using
        BIT(paired_vecs->id). (Daniele)
      
      Bspec: 52890, 53509
      
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: NAditya Swarup <aditya.swarup@intel.com>
      Co-developed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210526094852.286424-2-aditya.swarup@intel.com
      5b26d57f
  15. 27 5月, 2021 2 次提交
  16. 26 5月, 2021 2 次提交
  17. 20 5月, 2021 9 次提交
  18. 15 5月, 2021 5 次提交