[PATCH 3/3] drm/i915: prepare for multiple gt platforms
Andi Shyti
andi.shyti at linux.intel.com
Wed Nov 17 00:56:31 UTC 2021
Hi,
> On a multi-tile platform, each tile has its own registers + GGTT space,
> and BAR 0 is extended to cover all of them. Probe the tiles
> individually.
>
> Add some basic plumbing to support more than one dynamically allocated
> struct intel_gt. Up to four gts are supported in i915->gts[], with slot
> zero shadowing the existing i915->gt to enable source compatibility with
> legacy driver paths. A for_each_gt macro is added to iterate over the
> GTs and will be used by upcoming patches that convert various parts of
> the driver to be multi-gt aware.
>
> Check how many extra GT tiles are available on the system and setup
> register access for all of them. We can detect how may GT tiles are
> available by reading a register on the root tile. The same register
> returns the tile ID on all tiles.
>
> Bspec: 33407
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> Cc: Matthew Auld <matthew.auld at intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> Cc: Lucas De Marchi <lucas.demarchi at intel.com>
> Cc: Jani Nikula <jani.nikula at linux.intel.com>
> Signed-off-by: Abdiel Janulgue <abdiel.janulgue at gmail.com>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko at intel.com>
> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota at intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper at intel.com>
> Signed-off-by: Andi Shyti <andi.shyti at linux.intel.com>
This whole commit message is a Frankenstein commit.
[...]
> +static int
> +intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
> +{
> + struct drm_i915_private *i915 = gt->i915;
> + unsigned int id = gt->info.id;
> + int ret;
> +
> + if (id) {
> + struct intel_uncore_mmio_debug *mmio_debug;
> + struct intel_uncore *uncore;
> +
> + /* For multi-tile platforms BAR0 must have at least 16MB per tile */
> + if (GEM_WARN_ON(pci_resource_len(to_pci_dev(i915->drm.dev), 0) <
> + (id + 1) * SZ_16M))
> + return -EINVAL;
> +
> + uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
> + if (!gt->uncore)
> + return -ENOMEM;
> +
> + mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
> + if (!mmio_debug) {
> + kfree(uncore);
> + return -ENOMEM;
> + }
> +
> + gt->uncore = uncore;
> + gt->uncore->debug = mmio_debug;
in the series sent by Matt the "mmio_debug" got lost and left
actually unused. I think this was supposed to be its usage.
[...]
> +static unsigned int tile_count(struct drm_i915_private *i915)
> +{
> + u32 mtcfg;
> +
> + /*
> + * We use raw MMIO reads at this point since the
> + * MMIO vfuncs are not setup yet
> + */
> + mtcfg = __raw_uncore_read32(&i915->uncore, XEHPSDV_MTCFG_ADDR);
> + return REG_FIELD_GET(TILE_COUNT, mtcfg) + 1;
> +}
I like this function and I would like to get rid of the MAX_GT
define and initialize some basic info during probe. But this can
be done later.
[...]
> + /*
> + * We always have at least one primary GT on any device
> + * and it has been already initialized early during probe
> + * in i915_driver_probe()
> + */
there was some redundant initialization and I tried to clean up a
bit this path.
[...]
Andi
More information about the Intel-gfx-trybot
mailing list