Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>,
	Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org, Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-xe] [PATCH 11/17] drm/xe: Introduce xe_reg_t
Date: Wed, 19 Apr 2023 22:49:41 +0300	[thread overview]
Message-ID: <87y1mnwt2i.fsf@intel.com> (raw)
In-Reply-To: <20230419173345.GJ2825255@mdroper-desk1.amr.corp.intel.com>

On Wed, 19 Apr 2023, Matt Roper <matthew.d.roper@intel.com> wrote:
> On Wed, Apr 19, 2023 at 12:44:34AM -0700, Lucas De Marchi wrote:
>> Stop using i915 types for register our own xe_reg_t. Differently from
>> i915, this will keep under this will keep under the register definition
>> the knowledge for the different types of registers. For now, the "flags"
>> are mcr and masked, although only the former is being used.
>> 
>> Most of the driver is agnostic to the register differences. Convert the
>> few places that care about that, namely xe_gt_mcr.c, to take the generic
>> type and warn if the wrong register is used.
>
> The disadvantage of this approach is that we don't get the nice
> type-checking that we have in i915 to catch register misuse at build
> time.  Instead we wind up with a bunch of run-time checks that only tell
> you that you used the wrong register semantics after the fact.  Wouldn't
> it be better to keep the strict types and let the compiler find mistakes
> for us at build time?
>
> The only real problem with using strict types is that there are a few
> places where the driver is just trying to refer to registers/offsets
> without actually accessing them (e.g., whitelists, OA register groups,
> etc.) and the strict typing makes it harder to provide a heterogeneous
> list of those registers.  But I still feel the benefits of compile-time
> checking outweighs the extra complexity we wind up with in a handful of
> places.

The history of i915_reg_t is that there were subtle bugs where the
arguments to the register write call were accidentally swapped, they
went unnoticed, and needed lengthy debugging to finally figure out.

This can happen with xe_mmio_write32().

Strong typing for i915_reg_t has positive score 9 on Rusty's API Design
Manifesto [1].


BR,
Jani.


[1] https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html



>
>
> Matt
>
>> 
>> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>> ---
>>  drivers/gpu/drm/xe/regs/xe_reg_defs.h | 15 +++++++++++++++
>>  drivers/gpu/drm/xe/xe_gt_mcr.c        | 22 ++++++++++++++++------
>>  drivers/gpu/drm/xe/xe_gt_mcr.h        |  8 ++++----
>>  drivers/gpu/drm/xe/xe_irq.c           |  2 +-
>>  drivers/gpu/drm/xe/xe_mmio.c          |  2 +-
>>  5 files changed, 37 insertions(+), 12 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/xe/regs/xe_reg_defs.h b/drivers/gpu/drm/xe/regs/xe_reg_defs.h
>> index b5c25e31b889..1e78508c737b 100644
>> --- a/drivers/gpu/drm/xe/regs/xe_reg_defs.h
>> +++ b/drivers/gpu/drm/xe/regs/xe_reg_defs.h
>> @@ -8,4 +8,19 @@
>>  
>>  #include "compat-i915-headers/i915_reg_defs.h"
>>  
>> +typedef union {
>> +	struct {
>> +		u32 reg:30;
>> +		u32 mcr:1;
>> +		u32 masked:1;
>> +	};
>> +	u32 raw;
>> +} xe_reg_t;
>> +
>> +/* TODO: remove these once the register declarations are not using them anymore */
>> +#undef _MMIO
>> +#undef MCR_REG
>> +#define _MMIO(r)	((const xe_reg_t){ .reg = (r) })
>> +#define MCR_REG(r)	((const xe_reg_t){ .reg = (r), .mcr = 1 })
>> +
>>  #endif
>> diff --git a/drivers/gpu/drm/xe/xe_gt_mcr.c b/drivers/gpu/drm/xe/xe_gt_mcr.c
>> index aa04ba5a6dbe..b9631cfd5b81 100644
>> --- a/drivers/gpu/drm/xe/xe_gt_mcr.c
>> +++ b/drivers/gpu/drm/xe/xe_gt_mcr.c
>> @@ -360,11 +360,13 @@ void xe_gt_mcr_set_implicit_defaults(struct xe_gt *gt)
>>   * returned.  Returns false if the caller need not perform any steering
>>   */
>>  static bool xe_gt_mcr_get_nonterminated_steering(struct xe_gt *gt,
>> -						 i915_mcr_reg_t reg,
>> +						 xe_reg_t reg,
>>  						 u8 *group, u8 *instance)
>>  {
>>  	const struct xe_mmio_range *implicit_ranges;
>>  
>> +	drm_WARN_ON(&gt_to_xe(gt)->drm, !reg.mcr);
>> +
>>  	for (int type = 0; type < IMPLICIT_STEERING; type++) {
>>  		if (!gt->steering[type].ranges)
>>  			continue;
>> @@ -436,11 +438,13 @@ static void mcr_unlock(struct xe_gt *gt) {
>>   *
>>   * Caller needs to make sure the relevant forcewake wells are up.
>>   */
>> -static u32 rw_with_mcr_steering(struct xe_gt *gt, i915_mcr_reg_t reg, u8 rw_flag,
>> +static u32 rw_with_mcr_steering(struct xe_gt *gt, xe_reg_t reg, u8 rw_flag,
>>  				int group, int instance, u32 value)
>>  {
>>  	u32 steer_reg, steer_val, val = 0;
>>  
>> +	drm_WARN_ON(&gt_to_xe(gt)->drm, !reg.mcr);
>> +
>>  	lockdep_assert_held(&gt->mcr_lock);
>>  
>>  	if (GRAPHICS_VERx100(gt_to_xe(gt)) >= 1270) {
>> @@ -494,12 +498,14 @@ static u32 rw_with_mcr_steering(struct xe_gt *gt, i915_mcr_reg_t reg, u8 rw_flag
>>   *
>>   * Returns the value from a non-terminated instance of @reg.
>>   */
>> -u32 xe_gt_mcr_unicast_read_any(struct xe_gt *gt, i915_mcr_reg_t reg)
>> +u32 xe_gt_mcr_unicast_read_any(struct xe_gt *gt, xe_reg_t reg)
>>  {
>>  	u8 group, instance;
>>  	u32 val;
>>  	bool steer;
>>  
>> +	drm_WARN_ON(&gt_to_xe(gt)->drm, !reg.mcr);
>> +
>>  	steer = xe_gt_mcr_get_nonterminated_steering(gt, reg, &group, &instance);
>>  
>>  	if (steer) {
>> @@ -525,11 +531,13 @@ u32 xe_gt_mcr_unicast_read_any(struct xe_gt *gt, i915_mcr_reg_t reg)
>>   * group/instance.
>>   */
>>  u32 xe_gt_mcr_unicast_read(struct xe_gt *gt,
>> -			   i915_mcr_reg_t reg,
>> +			   xe_reg_t reg,
>>  			   int group, int instance)
>>  {
>>  	u32 val;
>>  
>> +	drm_WARN_ON(&gt_to_xe(gt)->drm, !reg.mcr);
>> +
>>  	mcr_lock(gt);
>>  	val = rw_with_mcr_steering(gt, reg, MCR_OP_READ, group, instance, 0);
>>  	mcr_unlock(gt);
>> @@ -548,9 +556,11 @@ u32 xe_gt_mcr_unicast_read(struct xe_gt *gt,
>>   * Write an MCR register in unicast mode after steering toward a specific
>>   * group/instance.
>>   */
>> -void xe_gt_mcr_unicast_write(struct xe_gt *gt, i915_mcr_reg_t reg, u32 value,
>> +void xe_gt_mcr_unicast_write(struct xe_gt *gt, xe_reg_t reg, u32 value,
>>  			     int group, int instance)
>>  {
>> +	drm_WARN_ON(&gt_to_xe(gt)->drm, !reg.mcr);
>> +
>>  	mcr_lock(gt);
>>  	rw_with_mcr_steering(gt, reg, MCR_OP_WRITE, group, instance, value);
>>  	mcr_unlock(gt);
>> @@ -564,7 +574,7 @@ void xe_gt_mcr_unicast_write(struct xe_gt *gt, i915_mcr_reg_t reg, u32 value,
>>   *
>>   * Write an MCR register in multicast mode to update all instances.
>>   */
>> -void xe_gt_mcr_multicast_write(struct xe_gt *gt, i915_mcr_reg_t reg, u32 value)
>> +void xe_gt_mcr_multicast_write(struct xe_gt *gt, xe_reg_t reg, u32 value)
>>  {
>>  	/*
>>  	 * Synchronize with any unicast operations.  Once we have exclusive
>> diff --git a/drivers/gpu/drm/xe/xe_gt_mcr.h b/drivers/gpu/drm/xe/xe_gt_mcr.h
>> index 2a6cd38c8cb7..492d9519784a 100644
>> --- a/drivers/gpu/drm/xe/xe_gt_mcr.h
>> +++ b/drivers/gpu/drm/xe/xe_gt_mcr.h
>> @@ -15,13 +15,13 @@ void xe_gt_mcr_init(struct xe_gt *gt);
>>  
>>  void xe_gt_mcr_set_implicit_defaults(struct xe_gt *gt);
>>  
>> -u32 xe_gt_mcr_unicast_read(struct xe_gt *gt, i915_mcr_reg_t reg,
>> +u32 xe_gt_mcr_unicast_read(struct xe_gt *gt, xe_reg_t reg,
>>  			   int group, int instance);
>> -u32 xe_gt_mcr_unicast_read_any(struct xe_gt *gt, i915_mcr_reg_t reg);
>> +u32 xe_gt_mcr_unicast_read_any(struct xe_gt *gt, xe_reg_t reg);
>>  
>> -void xe_gt_mcr_unicast_write(struct xe_gt *gt, i915_mcr_reg_t reg, u32 value,
>> +void xe_gt_mcr_unicast_write(struct xe_gt *gt, xe_reg_t reg, u32 value,
>>  			     int group, int instance);
>> -void xe_gt_mcr_multicast_write(struct xe_gt *gt, i915_mcr_reg_t reg, u32 value);
>> +void xe_gt_mcr_multicast_write(struct xe_gt *gt, xe_reg_t reg, u32 value);
>>  
>>  void xe_gt_mcr_steering_dump(struct xe_gt *gt, struct drm_printer *p);
>>  
>> diff --git a/drivers/gpu/drm/xe/xe_irq.c b/drivers/gpu/drm/xe/xe_irq.c
>> index 13f9f220bca0..8e5f8e7c16c8 100644
>> --- a/drivers/gpu/drm/xe/xe_irq.c
>> +++ b/drivers/gpu/drm/xe/xe_irq.c
>> @@ -27,7 +27,7 @@
>>  #define IIR(offset)				_MMIO(offset + 0x8)
>>  #define IER(offset)				_MMIO(offset + 0xc)
>>  
>> -static void assert_iir_is_zero(struct xe_gt *gt, i915_reg_t reg)
>> +static void assert_iir_is_zero(struct xe_gt *gt, xe_reg_t reg)
>>  {
>>  	u32 val = xe_mmio_read32(gt, reg.reg);
>>  
>> diff --git a/drivers/gpu/drm/xe/xe_mmio.c b/drivers/gpu/drm/xe/xe_mmio.c
>> index a93838e23b7b..1029b9f27988 100644
>> --- a/drivers/gpu/drm/xe/xe_mmio.c
>> +++ b/drivers/gpu/drm/xe/xe_mmio.c
>> @@ -397,7 +397,7 @@ int xe_mmio_init(struct xe_device *xe)
>>  	DRM_XE_MMIO_READ |\
>>  	DRM_XE_MMIO_WRITE)
>>  
>> -static const i915_reg_t mmio_read_whitelist[] = {
>> +static const xe_reg_t mmio_read_whitelist[] = {
>>  	RING_TIMESTAMP(RENDER_RING_BASE),
>>  };
>>  
>> -- 
>> 2.39.0
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center

  parent reply	other threads:[~2023-04-19 19:49 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19  7:44 [Intel-xe] [PATCH 00/17] Cleanup registers and introduce xe_reg_t Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 01/17] drm/xe: Cleanup page-related defines Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 02/17] fixup! drm/i915/display: Remaining changes to make xe compile Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 03/17] fixup! drm/i915/display: Allow fbdev to allocate stolen memory Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 04/17] drm/xe: Rename RC0/RC6 macros Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 05/17] drm/xe: Rename instruction field to avoid confusion Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 06/17] drm/xe/guc: Rename GEN11_SOFT_SCRATCH for clarity Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 07/17] drm/xe/guc: Move GuC registers to regs/ Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 08/17] drm/xe/guc: Convert GuC registers to REG_FIELD/REG_BIT Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 09/17] drm/xe: Drop gen prefixes and suffixes from registers Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 10/17] drm/xe: Use REG_FIELD/REG_BIT for all regs/*.h Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 11/17] drm/xe: Introduce xe_reg_t Lucas De Marchi
2023-04-19 16:06   ` Jani Nikula
2023-04-19 17:17     ` Lucas De Marchi
2023-04-19 19:39       ` Jani Nikula
2023-04-19 20:30         ` Lucas De Marchi
2023-04-19 17:33   ` Matt Roper
2023-04-19 18:49     ` Lucas De Marchi
2023-04-19 19:30       ` Rodrigo Vivi
2023-04-19 20:19         ` Lucas De Marchi
2023-04-19 20:24           ` Matt Roper
2023-04-19 21:09             ` Lucas De Marchi
2023-04-19 23:14               ` Matt Roper
2023-04-19 23:38                 ` Lucas De Marchi
2023-04-19 19:49     ` Jani Nikula [this message]
2023-04-19 20:13       ` Lucas De Marchi
2023-04-19 20:13       ` Matt Roper
2023-04-19 21:24         ` Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 12/17] drm/xe: Clarify register types on PAT programming Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 13/17] drm/xe/rtp: Improve magic macros for RTP tables Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 14/17] drm/xe: Add XE_REG/XE_REG_MCR Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 15/17] drm/xe: Annotate masked registers used by RTP Lucas De Marchi
2023-04-19  7:44 ` [Intel-xe] [PATCH 16/17] drm/xe: Plumb xe_reg_t into WAs, rtp, etc Lucas De Marchi
2023-04-19 16:15   ` Jani Nikula
2023-04-19  7:44 ` [Intel-xe] [PATCH 17/17] drm/xe: Move helper macros to separate header Lucas De Marchi
2023-04-19 16:17   ` Jani Nikula
2023-04-19 17:06     ` Lucas De Marchi
2023-04-19  7:47 ` [Intel-xe] ✓ CI.Patch_applied: success for Cleanup registers and introduce xe_reg_t Patchwork
2023-04-19  7:48 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-04-19  7:52 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-04-19  8:12 ` [Intel-xe] ○ CI.BAT: info " 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=87y1mnwt2i.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=rodrigo.vivi@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