[PATCH i-g-t 0/7] Future-proof GT ID handling for Xe

[Matt Roper]

Current Intel platforms fall into one of three cases:
 * Single tile, single GT (primary)
 * Multiple tiles, one GT each (primary)
 * Single tile, two GTs (primary+media)

In all three cases, the GTs are always consecutive (0 and 1) and the
GT's uapi ID matches its index in the xe_query GT list.  Future
platforms could potentially have multiple tiles with multiple GTs each,
and/or could introduce new types of GTs.  In either case, it's possible
that there might be "holes" in the set of GT IDs returned by the GT
query (e.g., 0, 2, 3 if a multi-tile platform only media on the second
tile; or 0, 2 if a single-tile platform introduced a new type of GT, but
lacked media).

We need to break IGT's assumption that the uapi ID used to represent a
GT always matches its index in the GT query.  This series shouldn't have
any functional impact on today's Intel platforms; the goal is to just
future-proof the code for new types of platforms that could show up in
the future.  Similar refactoring and cleanup is happening on the xe.ko
side at https://patchwork.freedesktop.org/series/150192/  although this
series does not depend on the kernel work.


Matt Roper (7):
  lib/xe: Track valid GT IDs
  lib/xe: Don't assume GT ID matches location in GT query list
  lib/xe: Populate vram_size[] and visible_vram_size[] by GT ID
  lib/xe: Ensure GT loops iterate over all GTs properly
  tests/intel/xe_query: Look up GT reference clock correctly
  lib/xe: Add xe_dev_max_gt()
  tests/xe: Don't assume max GT ID is num_gt - 1

 lib/xe/xe_query.c        | 78 ++++++++++++++++++++++++++++++----------
 lib/xe/xe_query.h        | 10 ++++--
 lib/xe/xe_util.c         |  7 ++--
 tests/intel/xe_compute.c | 47 ++++++++++++------------
 tests/intel/xe_gt_freq.c |  8 ++---
 tests/intel/xe_query.c   | 13 +++----
 6 files changed, 103 insertions(+), 60 deletions(-)

-- 
2.49.0