[PATCH 0/5] i915: SSEU handling updates

[Matt Roper]

This series makes a handful of updates to i915's internal handling of
slice/subslice/EU (SSEU) data to handle recent platforms like Xe_HP in a
more natural manner and to prepare for some additional upcoming
platforms we have in the pipeline (the first of which I'll probably
start sending patches for in the next week or two).  One key idea of
this series is that although we have a fixed ABI to convey SSEU data to
userspace (i.e., multiple u8[] arrays with data stored at different
strides), we don't need to use this cumbersome format for the driver's
own internal storage.  As long as we can convert into the uapi form
properly when responding to the I915_QUERY ioctl, it's preferable to use
an internal storage format that's easier for the driver to work with.
Doing so can also save us some storage space on modern platforms since
we don't always need to replicate a bunch of data that's architecturally
guaranteed to be identical.

Another key point here is that Xe_HP platforms today have subslice (DSS)
masks that are 32 bits, which maxes out the storage of a u32.  On future
platforms the architecture design is going to start spreading their DSS
masks over multiple 32-bit fuse registers.  So even for platforms where
the total number of DSS doesn't actually go up, we're going to need
larger storage than just a u32 to express the mask properly.  To
accomodate this, we start storing our subslice mask in a new typedef
that can be processed by the linux/bitmap.h operations.

Finally, since no userspace for Xe_HP or beyond is using the legacy
I915_GETPARAM ioctl lookups for I915_PARAM_SLICE_MASK and
I915_PARAM_SUBSLICE_MASK (since they've migrated to the more flexible
I915_QUERY ioctl that can return more than a simple u32 value), we take
the opportunity to officially drop support for those GETPARAM lookups on
modern platforms.  Maintaining support for these GETPARAM lookups don't
make sense for a number of reasons:

 * Traditional slices no longer exist, and newer ideas like gslices,
   cslices, mslices, etc. aren't something userspace needs to query
   since it can be inferred from other information.
 * The GETPARAM ioctl doesn't have a way to distinguish between geometry
   subslice masks and compute subslice masks, which are distinct on
   Xe_HP and beyond.
 * The I915_GETPARAM ioctl is limited to returning a 32-bit value, so
   when subslice masks begin to exceed 32-bits, it simply can't return
   the entire mask.
 * The GETPARAM ioctl doesn't have a way to give sensible information
   for multi-tile devices.


Cc: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>

Matt Roper (5):
  drm/i915/sseu: Don't try to store EU mask internally in UAPI format
  drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
  drm/i915/xehp: Use separate sseu init function
  drm/i915/sseu: Simplify gen11+ SSEU handling
  drm/i915/sseu: Disassociate internal subslice mask representation from
    uapi

 drivers/gpu/drm/i915/gem/i915_gem_context.c  |   4 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c    |   2 +-
 drivers/gpu/drm/i915/gt/intel_gt.c           |  14 +-
 drivers/gpu/drm/i915/gt/intel_sseu.c         | 371 +++++++++++--------
 drivers/gpu/drm/i915/gt/intel_sseu.h         |  69 ++--
 drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c |  28 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c  |  28 +-
 drivers/gpu/drm/i915/i915_getparam.c         |  10 +-
 drivers/gpu/drm/i915/i915_query.c            |  16 +-
 9 files changed, 323 insertions(+), 219 deletions(-)

-- 
2.35.1