From: Andi Shyti <andi@etezian.org>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Paulo Zanoni <paulo.r.zanoni@intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>,
Michal Wajdeczko <michal.wajdeczko@intel.com>
Subject: Re: [Intel-gfx] [PATCH v2 11/11] drm/i915/xehpsdv: Initialize multi-tiles
Date: Wed, 13 Oct 2021 01:11:04 +0200 [thread overview]
Message-ID: <YWYWCLe0HLw2CaMB@jack.zhora.eu> (raw)
In-Reply-To: <20211008233310.2034639-1-matthew.d.roper@intel.com>
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
next prev parent reply other threads:[~2021-10-12 23:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 21:56 [Intel-gfx] [PATCH 00/11] i915: Initial multi-tile support Matt Roper
2021-10-08 21:56 ` [Intel-gfx] [PATCH 01/11] drm/i915: rework some irq functions to take intel_gt as argument Matt Roper
2021-10-27 6:22 ` Lucas De Marchi
2021-10-28 14:13 ` Andi Shyti
2021-10-08 21:56 ` [Intel-gfx] [PATCH 02/11] drm/i915: split general MMIO setup from per-GT uncore init Matt Roper
2021-10-27 6:26 ` Lucas De Marchi
2021-10-28 14:17 ` Andi Shyti
2021-10-08 21:56 ` [Intel-gfx] [PATCH 03/11] drm/i915: Restructure probe to handle multi-tile platforms Matt Roper
2021-10-13 12:12 ` Jani Nikula
2021-10-27 6:57 ` Lucas De Marchi
2021-10-27 7:58 ` Jani Nikula
2021-10-08 21:56 ` [Intel-gfx] [PATCH 04/11] drm/i915: Store backpointer to GT in uncore Matt Roper
2021-10-28 14:26 ` Andi Shyti
2021-10-08 21:56 ` [Intel-gfx] [PATCH 05/11] drm/i915: Prepare for multiple gts Matt Roper
2021-10-27 7:01 ` Lucas De Marchi
2021-10-08 21:56 ` [Intel-gfx] [PATCH 06/11] drm/i915: Initial support for per-tile uncore Matt Roper
2021-10-28 15:41 ` Andi Shyti
2021-10-08 21:56 ` [Intel-gfx] [PATCH 07/11] drm/i915/xehp: Determine which tile raised an interrupt Matt Roper
2021-10-08 23:48 ` Matt Roper
2021-10-13 0:55 ` Andi Shyti
2021-10-27 7:13 ` Lucas De Marchi
2021-10-08 21:56 ` [Intel-gfx] [PATCH 08/11] drm/i915/xehp: Make IRQ reset and postinstall multi-tile aware Matt Roper
2021-10-28 16:30 ` Andi Shyti
2021-10-28 23:20 ` Matt Roper
2021-10-29 0:16 ` Andi Shyti
2021-10-08 21:56 ` [Intel-gfx] [PATCH 09/11] drm/i915/guc: Update CT debug macro for multi-tile Matt Roper
2021-10-08 21:56 ` [Intel-gfx] [PATCH 10/11] drm/i915: Release per-gt resources allocated Matt Roper
2021-10-28 16:33 ` Andi Shyti
2021-10-08 21:56 ` [Intel-gfx] [PATCH 11/11] drm/i915/xehpsdv: Initialize multi-tiles Matt Roper
2021-10-08 23:33 ` [Intel-gfx] [PATCH v2 " Matt Roper
2021-10-11 7:51 ` Tvrtko Ursulin
2021-10-12 23:11 ` Andi Shyti [this message]
2021-10-08 22:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Initial multi-tile support Patchwork
2021-10-08 23:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-09 0:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Initial multi-tile support (rev2) Patchwork
2021-10-09 0:36 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-10-09 2:54 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Initial multi-tile support Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YWYWCLe0HLw2CaMB@jack.zhora.eu \
--to=andi@etezian.org \
--cc=andi.shyti@linux.intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=paulo.r.zanoni@intel.com \
--cc=tvrtko.ursulin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox