public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>,
	"Intel-GFX@Lists.FreeDesktop.Org"
	<Intel-GFX@Lists.FreeDesktop.Org>
Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/guc: Don't capture Gen8 regs on Xe devices
Date: Wed, 26 Apr 2023 10:23:13 -0700	[thread overview]
Message-ID: <0f23e701-8d7d-2fc4-192d-4c0497587a24@intel.com> (raw)
In-Reply-To: <97546a0ca475345fd18f8d80fafa5f7a11e34101.camel@intel.com>

On 4/25/2023 10:55, Teres Alexis, Alan Previn wrote:
> 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>
>
I'm not entirely sure what you are arguing here.

My reading of the original code is that COMMON_GENX_ means the registers 
were introduced on the named device but a are common to later devices. 
Whereas GENX_ means the registers are specific to that device alone. 
That seems a pretty straight forward and simple naming scheme to me.

John.


  parent reply	other threads:[~2023-04-26 17:23 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
2023-04-26 17:22     ` John Harrison
2023-04-26 17:23     ` John Harrison [this message]
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=0f23e701-8d7d-2fc4-192d-4c0497587a24@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=Intel-GFX@Lists.FreeDesktop.Org \
    --cc=alan.previn.teres.alexis@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