From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "Harrison, John C" <john.c.harrison@intel.com>,
"Intel-GFX@Lists.FreeDesktop.Org"
<Intel-GFX@Lists.FreeDesktop.Org>
Cc: "Vivekanandan,
Balasubramani" <balasubramani.vivekanandan@intel.com>,
"Nikula, Jani" <jani.nikula@intel.com>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"DRI-Devel@Lists.FreeDesktop.Org"
<DRI-Devel@Lists.FreeDesktop.Org>,
"Roper, Matthew D" <matthew.d.roper@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/guc: Don't capture Gen8 regs on Xe devices
Date: Tue, 25 Apr 2023 17:55:58 +0000 [thread overview]
Message-ID: <97546a0ca475345fd18f8d80fafa5f7a11e34101.camel@intel.com> (raw)
In-Reply-To: <20230406222617.790484-2-John.C.Harrison@Intel.com>
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> A pair of pre-Xe registers were being included in the Xe capture list.
> GuC was rejecting those as being invalid and logging errors about
> them. So, stop doing it.
>
alan:snip
> #define COMMON_GEN9BASE_GLOBAL \
> - { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
> - { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }, \
> { ERROR_GEN6, 0, 0, "ERROR_GEN6" }, \
> { DONE_REG, 0, 0, "DONE_REG" }, \
> { HSW_GTT_CACHE_EN, 0, 0, "HSW_GTT_CACHE_EN" }
>
> +#define GEN9_GLOBAL \
> + { GEN8_FAULT_TLB_DATA0, 0, 0, "GEN8_FAULT_TLB_DATA0" }, \
> + { GEN8_FAULT_TLB_DATA1, 0, 0, "GEN8_FAULT_TLB_DATA1" }
> +
> #define COMMON_GEN12BASE_GLOBAL \
> { GEN12_FAULT_TLB_DATA0, 0, 0, "GEN12_FAULT_TLB_DATA0" }, \
> { GEN12_FAULT_TLB_DATA1, 0, 0, "GEN12_FAULT_TLB_DATA1" }, \
> @@ -142,6 +144,7 @@ static const struct __guc_mmio_reg_descr xe_lpd_gsc_inst_regs[] = {
> static const struct __guc_mmio_reg_descr default_global_regs[] = {
> COMMON_BASE_GLOBAL,
> COMMON_GEN9BASE_GLOBAL,
> + GEN9_GLOBAL,
> };
>
alan: splitting out a couple registers from COMMON_GEN9BASE_GLOBAL into GEN9_GLOBAL
doesn't seem to communicate the intent of fix for this patch. This is more of a naming,
thing and i am not sure what counter-proposal will work well in terms of readibility.
One idea: perhaps we rename "COMMON_GEN9BASE_GLOBAL" to "COMMON_GEN9PLUS_BASE_GLOBAL"
and rename GEN9_GLOBAL to COMMON_GEN9LEGACY_GLOBAL. so we would have two gen9-global
with a clear distinction in naming where one is "GEN9PLUS" and the other is "GEN9LEGACY".
But since this is a list-naming thing, i am okay either above change... OR...
keeping the same but with the condition of adding a comment under
COMMON_GEN9BASE_GLOBAL and GEN9_GLOBAL names that explain the differences where one
is gen9-legacy and the other is gen9-and-future that carries over to beyond Gen9.
(side note: coding style wise, is it possible to add the comment right under the #define
line as opposed to under the entire list?)
(conditional) Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
next prev parent reply other threads:[~2023-04-25 17:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 22:26 [Intel-gfx] [PATCH 0/5] Improvements to GuC error capture list processing John.C.Harrison
2023-04-06 22:26 ` [Intel-gfx] [PATCH 1/5] drm/i915/guc: Don't capture Gen8 regs on Xe devices John.C.Harrison
2023-04-25 17:55 ` Teres Alexis, Alan Previn [this message]
2023-04-26 17:22 ` John Harrison
2023-04-26 17:23 ` John Harrison
2023-04-26 21:14 ` Teres Alexis, Alan Previn
2023-04-28 18:21 ` John Harrison
2023-04-06 22:26 ` [Intel-gfx] [PATCH 2/5] drm/i915/guc: Capture list clean up - 1 John.C.Harrison
2023-04-25 18:28 ` Teres Alexis, Alan Previn
2023-04-06 22:26 ` [Intel-gfx] [PATCH 3/5] drm/i915/guc: Capture list clean up - 2 John.C.Harrison
2023-04-25 18:54 ` Teres Alexis, Alan Previn
2023-04-26 18:01 ` John Harrison
2023-04-06 22:26 ` [Intel-gfx] [PATCH 4/5] drm/i915/guc: Capture list clean up - 3 John.C.Harrison
2023-04-25 19:05 ` Teres Alexis, Alan Previn
2023-04-26 17:29 ` John Harrison
2023-04-26 17:37 ` John Harrison
2023-04-26 18:24 ` [Intel-gfx] [PATCH 6/6] drm/i915/guc: Capture list clean up - 5 John.C.Harrison
2023-04-26 21:16 ` Teres Alexis, Alan Previn
2023-04-06 22:26 ` [Intel-gfx] [PATCH 5/5] drm/i915/guc: Capture list clean up - 4 John.C.Harrison
2023-04-25 19:10 ` Teres Alexis, Alan Previn
2023-04-06 23:09 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Improvements to GuC error capture list processing Patchwork
2023-04-06 23:35 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-07 11:47 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=97546a0ca475345fd18f8d80fafa5f7a11e34101.camel@intel.com \
--to=alan.previn.teres.alexis@intel.com \
--cc=DRI-Devel@Lists.FreeDesktop.Org \
--cc=Intel-GFX@Lists.FreeDesktop.Org \
--cc=balasubramani.vivekanandan@intel.com \
--cc=jani.nikula@intel.com \
--cc=john.c.harrison@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@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