1. 27 Oct, 2022 18 commits
  2. 26 Oct, 2022 4 commits
  3. 24 Oct, 2022 8 commits
  4. 21 Oct, 2022 1 commit
  5. 20 Oct, 2022 4 commits
  6. 19 Oct, 2022 1 commit
  7. 18 Oct, 2022 1 commit
  8. 17 Oct, 2022 3 commits
    • Daniele Ceraolo Spurio's avatar
      drm/i915/huc: bump timeout for delayed load and reduce print verbosity · 21f213e6
      Daniele Ceraolo Spurio authored
      We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
      binding completing later than we expected. HuC is still loaded when the
      bind occurs, but in the meantime i915 has started allowing submission to
      the VCS engines even if HuC is not there.
      In most of the cases I've observed, the timeout was due to the
      init/resume of another driver between i915 and mei hitting errors and
      thus adding an extra delay, but HuC was still loaded before userspace
      could submit, because the whole resume process time was increased by the
      delays.
      
      Given that there is no upper bound to the delay that can be introduced
      by other drivers, I've reached the following compromise with the media
      team:
      
      1) i915 is going to bump the timeout to 5s, to reduce the probability
      of reaching it. We still expect HuC to be loaded before userspace
      starts submitting, so increasing the timeout should have no impact on
      normal operations, but in case something weird happens we don't want to
      stall video submissions for too long.
      
      2) The media driver will cope with the failing submissions that manage
      to go through between i915 init/resume complete and HuC loading, if any
      ever happen. This could cause a small corruption of video playback
      immediately after a resume (we should be safe on boot because the media
      driver polls the HUC_STATUS ioctl before starting submissions).
      
      Since we're accepting the timeout as a valid outcome, I'm also reducing
      the print verbosity from error to notice.
      
      v2: use separate prints for MEI GSC and MEI PXP init timeouts (John)
      v3: add MISSING_CASE to the if-else chain (John)
      
      References: https://gitlab.freedesktop.org/drm/intel/-/issues/7033
      Fixes: 27536e03 ("drm/i915/huc: track delayed HuC load with a fence")
      Signed-off-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Tony Ye <tony.ye@intel.com>
      Cc: John Harrison <john.c.harrison@intel.com>
      Reviewed-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20221013203245.1801788-1-daniele.ceraolospurio@intel.com
      21f213e6
    • Matt Roper's avatar
      drm/i915/xelpmp: Add multicast steering for media GT · a7ec65fc
      Matt Roper authored
      MTL's media IP (Xe_LPM+) only has a single type of steering ("OAADDRM")
      which selects between media slice 0 and media slice 1.  We'll always
      steer to media slice 0 unless it is fused off (which is the case when
      VD0, VE0, and SFC0 are all reported as unavailable).
      
      Bspec: 67789
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarBalasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-15-matthew.d.roper@intel.com
      a7ec65fc
    • Matt Roper's avatar
      drm/i915/xelpg: Add multicast steering · f32898c9
      Matt Roper authored
      MTL's graphics IP (Xe_LPG) once again changes the multicast register
      types and steering details.  Key changes from past platforms:
       * The number of instances of some MCR types (NODE, OAAL2, and GAM) vary
         according to the MTL subplatform and cannot be read from fuse
         registers.  However steering to instance #0 will always provided a
         non-terminated value, so we can lump these all into a single
         "instance0" table.
       * The MCR steering register (and its bitfields) has changed.
      
      Unlike past platforms, we will be explicitly steering all types of MCR
      accesses, including those for "SLICE" and "DSS" ranges; we no longer
      rely on implicit steering.  On previous platforms, various
      hardware/firmware agents that needed to access registers typically had
      their own steering control registers, allowing them to perform multicast
      steering without clobbering the CPU/kernel steering.  Starting with MTL,
      more of these agents now share a single steering register (0xFD4) and it
      is no longer safe for us to assume that the value will remain unchanged
      from how we initialized it during startup.  There is also a slight
      chance of race conditions between the driver and a hardware/firmware
      agent, so the hardware provides a semaphore register that can be used to
      coordinate access to the steering register.  Support for the semaphore
      register will be introduced in a future patch.
      
      v2:
       - Use Xe_LPG terminology instead of "MTL 3D" since it's the IP version
         we're matching on now rather than the platform.
       - Don't combine l3bank and mslice masks into a union.  It's not related
         to the other changes here and we might still need both of them on
         some future platform.
       - Separate debug dumping of steering settings to a separate helper
         function.  (Tvrtko)
       - Update debug dumping to include DSS ranges (and future-proof it so
         that any new ranges added on future platforms will also be dumped).
       - Restore MULTICAST bit at the end of rw_with_mcr_steering_fw() if we
         cleared it.  Also force the MULTICAST bit to true at the beginning of
         multicast writes just to be safe.  (Bala)
      
      Bspec: 67788, 67112
      Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
      Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarBalasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20221014230239.1023689-14-matthew.d.roper@intel.com
      f32898c9