Hi Tvrtko and Matt,
[...]
> -#define I915_MAX_TILES 4
> - struct intel_gt *gts[I915_MAX_TILES];
> +#define I915_MAX_GTS 4
> + struct intel_gt *gts[I915_MAX_GTS];
let's call it MAX_GTS already in patch 5 so that we can avoid a
rename.
BTW, out of the scope of this patch but if we can read the number
of tiles, why don't we make this dynamic? We already have a
"dynamic" version for_each_gt() in probe_gts().
[...]
>
> struct {
> struct i915_gem_contexts {
> @@ -1724,6 +1726,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>
> #define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
> #define HAS_LMEM(i915) HAS_REGION(i915, REGION_LMEM)
> +#define HAS_REMOTE_TILES(dev_priv) (INTEL_INFO(dev_priv)->has_remote_tiles)
s/dev_priv/i915
[...]
> +static const struct intel_gt_definition xehp_sdv_gts[] = {
> + {
> + .type = GT_TILE,
> + .name = "Remote Tile GT",
> + .mapping_base = SZ_16M,
> + .engine_mask = XE_HP_SDV_ENGINES,
> +
> + },
> + {
> + .type = GT_TILE,
> + .name = "Remote Tile GT",
> + .mapping_base = SZ_16M * 2,
> + .engine_mask = XE_HP_SDV_ENGINES,
> +
> + },
> + {
> + .type = GT_TILE,
> + .name = "Remote Tile GT",
why don't we call it "Remote Tile GT <N>" or similar?
[...]
Andi
