1. 26 10月, 2022 1 次提交
    • I
      drm/i915/tgl+: Add locking around DKL PHY register accesses · 89cb0ba4
      Imre Deak 提交于
      Accessing the TypeC DKL PHY registers during modeset-commit,
      -verification, DP link-retraining and AUX power well toggling is racy
      due to these code paths being concurrent and the PHY register bank
      selection register (HIP_INDEX_REG) being shared between PHY instances
      (aka TC ports) and the bank selection being not atomic wrt. the actual
      PHY register access.
      
      Add the required locking around each PHY register bank selection->
      register access sequence.
      
      Kudos to Ville for noticing the race conditions.
      
      v2:
      - Add the DKL PHY register accessors to intel_dkl_phy.[ch]. (Jani)
      - Make the DKL_REG_TC_PORT macro independent of PHY internals.
      - Move initing the DKL PHY lock to a more logical place.
      
      v3:
      - Fix parameter reuse in the DKL_REG_TC_PORT definition.
      - Document the usage of phy_lock.
      
      v4:
      - Fix adding TC_PORT_1 offset in the DKL_REG_TC_PORT definition.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: <stable@vger.kernel.org> # v5.5+
      Acked-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20221025114457.2191004-1-imre.deak@intel.com
      89cb0ba4
  2. 11 10月, 2022 2 次提交
  3. 24 9月, 2022 1 次提交
  4. 14 9月, 2022 1 次提交
  5. 09 9月, 2022 1 次提交
  6. 01 9月, 2022 1 次提交
  7. 31 8月, 2022 2 次提交
  8. 29 8月, 2022 4 次提交
  9. 24 8月, 2022 2 次提交
  10. 30 6月, 2022 2 次提交
  11. 27 6月, 2022 2 次提交
  12. 24 6月, 2022 1 次提交
  13. 20 6月, 2022 1 次提交
    • T
      drm/i915: Improve on suspend / resume time with VT-d enabled · 2ef6efa7
      Thomas Hellström 提交于
      When DMAR / VT-d is enabled, the display engine uses overfetching,
      presumably to deal with the increased latency. To avoid display engine
      errors and DMAR faults, as a workaround the GGTT is populated with scatch
      PTEs when VT-d is enabled. However starting with gen10, Write-combined
      writing of scratch PTES is no longer possible and as a result, populating
      the full GGTT with scratch PTEs like on resume becomes very slow as
      uncached access is needed.
      
      Therefore, on integrated GPUs utilize the fact that the PTEs are stored in
      stolen memory which retain content across S3 suspend. Don't clear the PTEs
      on suspend and resume. This improves on resume time with around 100 ms.
      While 100+ms might appear like a short time it's 10% to 20% of total resume
      time and important in some applications.
      
      One notable exception is Intel Rapid Start Technology which may cause
      stolen memory to be lost across what the OS percieves as S3 suspend.
      If IRST is enabled or if we can't detect whether IRST is enabled, retain
      the old workaround, clearing and re-instating PTEs.
      
      As an additional measure, if we detect that the last ggtt pte was lost
      during suspend, print a warning and re-populate the GGTT ptes
      
      On discrete GPUs, the display engine scans out from LMEM which isn't
      subject to DMAR, and presumably the workaround is therefore not needed,
      but that needs to be verified and disabling the workaround for dGPU,
      if possible, will be deferred to a follow-up patch.
      
      v2:
      - Rely on retained ptes to also speed up suspend and resume re-binding.
      - Re-build GGTT ptes if Intel rst is enabled.
      v3:
      - Re-build GGTT ptes also if we can't detect whether Intel rst is enabled,
        and if the guard page PTE and end of GGTT was lost.
      v4:
      - Fix some kerneldoc issues (Matthew Auld), rebase.
      Signed-off-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220617152856.249295-1-thomas.hellstrom@linux.intel.com
      2ef6efa7
  14. 26 5月, 2022 1 次提交
  15. 20 5月, 2022 1 次提交
  16. 16 5月, 2022 1 次提交
  17. 21 4月, 2022 1 次提交
  18. 05 4月, 2022 2 次提交
  19. 30 3月, 2022 1 次提交
  20. 21 3月, 2022 1 次提交
  21. 03 3月, 2022 1 次提交
  22. 19 2月, 2022 1 次提交
  23. 14 2月, 2022 1 次提交
  24. 11 2月, 2022 2 次提交
  25. 10 2月, 2022 1 次提交
  26. 21 1月, 2022 1 次提交
  27. 10 1月, 2022 2 次提交
  28. 09 12月, 2021 1 次提交
  29. 17 11月, 2021 1 次提交