1. 27 Jun, 2022 7 commits
  2. 23 Jun, 2022 1 commit
  3. 22 Jun, 2022 7 commits
  4. 21 Jun, 2022 1 commit
  5. 20 Jun, 2022 1 commit
    • Thomas Hellström's avatar
      drm/i915: Improve on suspend / resume time with VT-d enabled · 2ef6efa7
      Thomas Hellström authored
      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: default avatarThomas Hellström <thomas.hellstrom@linux.intel.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220617152856.249295-1-thomas.hellstrom@linux.intel.com
      2ef6efa7
  6. 17 Jun, 2022 4 commits
  7. 15 Jun, 2022 1 commit
  8. 14 Jun, 2022 1 commit
  9. 09 Jun, 2022 1 commit
    • Matt Roper's avatar
      drm/i915/pvc: Add register steering · e0d7371b
      Matt Roper authored
      Ponte Vecchio no longer has MSLICE or LNCF steering, but the bspec does
      document several new types of multicast register ranges.  Fortunately,
      most of the different MCR types all provide valid values at instance
      (0,0) so there's no need to read fuse registers and calculate a
      non-terminated instance.  We'll lump all of those range types (BSLICE,
      HALFBSLICE, TILEPSMI, CC, and L3BANK) into a single category called
      "INSTANCE0" to keep things simple.  We'll also perform explicit steering
      for each of these multicast register types, even if the implicit
      steering setup for COMPUTE/DSS ranges would have worked too; this is
      based on guidance from our hardware architects who suggested that we
      move away from implicit steering and start explicitly steer all MCR
      register accesses on modern platforms (we'll work on transitioning
      COMPUTE/DSS to explicit steering in the future).
      
      Note that there's one additional MCR range type defined in the bspec
      (SQIDI) that we don't handle here.  Those ranges use a different
      steering control register that we never touch; since instance 0 is also
      always a valid setting there, we can just ignore those ranges.
      
      Finally, we'll rename the HAS_MSLICES() macro to HAS_MSLICE_STEERING().
      PVC hardware still has units referred to as mslices, but there's no
      register steering based on mslice for this platform.
      
      v2:
       - Rebase on other recent changes
       - Swap two table rows to keep table sorted & easy to read.  (Harish)
      
      Bspec: 67609
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarHarish Chegondi <harish.chegondi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220608170700.4026648-1-matthew.d.roper@intel.com
      e0d7371b
  10. 08 Jun, 2022 4 commits
  11. 07 Jun, 2022 2 commits
  12. 03 Jun, 2022 1 commit
  13. 02 Jun, 2022 7 commits
  14. 31 May, 2022 2 commits