[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