Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Patelczyk <maciej.patelczyk@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
	Matt Roper <matthew.d.roper@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Koby Elbaz <kelbaz@habana.ai>
Subject: Re: [PATCH] drm/xe: Remove unused "mmio_ext" code
Date: Thu, 9 Jan 2025 09:32:51 +0100	[thread overview]
Message-ID: <56a714bb-fe4e-44f4-a0b3-774fed63ecd9@intel.com> (raw)
In-Reply-To: <5tnfpuj3qv3vqy6ydpbqttz5rf4cfssldw7bgpmmgbduojdztp@lpacc4xzoemi>

On 8.01.2025 04:39, Lucas De Marchi wrote:

> On Mon, Jan 06, 2025 at 03:43:13PM -0800, Matt Roper wrote:
>> The "mmio_ext" and 'REG_EXT" code is currently unused on any existing
>> platform.  Going forward, this also isn't the design we want to use for
>> any future platforms/features either, so we should just go ahead and
>> remove the dead code to avoid confusion.
>>
>> mmio_ext was originally added in an attempt to hack around the early
>> (mis)design of the Xe driver, which used xe_gt as the target for all
>> register MMIO access, even those completely unrelated to the GT subunit
>> of the hardware.  With the introduction of commit 34953ee349dd ("drm/xe:
>> Create dedicated xe_mmio structure") and its follow-up patches, that
>> misdesign has been corrected and access to register MMIO regions
>> specific to hardware units is now done through xe_mmio structures which
>> encapsulate an iomap, region size, and some other metadata.
>>
>> Although all of the registers used by the driver today happen to fall
>> within one specific PCI BAR region, and thus re-use a single device-wide
>> iomap, there's no requirement that this stay true for future platforms
>> or features.  I.e., if a future platform adds a new 'foo' hardware unit
>> that exists at a different area in the BAR, or even in a completely
>> different BAR, then that would be handled by doing a separate iomap of
>> that unit's register region and wrapping it in its own 'struct xe_mmio
>> foo_regs' structure.  The pointer to the new 'foo_regs' could be placed
>> within the xe_device, xe_tile, xe_gt, etc., according to where the new
>> hardware unit falls within the current hardware hierarchy.
>>
>> This effectively reverts the following commits, although parts of these
>> commits had already vanished or changed with the earlier xe_mmio
>> refactor work:
>>
>> - commit 399a13323f0d ("drm/xe: add 28-bit address support in struct
>>   xe_reg")
>> - commit fdef72e02e20 ("drm/xe: add a flag to bypass multi-tile config
>>   from MTCFG reg")
>> - commit 866b2b176434 ("drm/xe: add MMIO extension support flags")
>> - commit ef29b390c734 ("drm/xe: map MMIO BAR according to the num of
>>   tiles in device desc")
>> - commit a4e2f3a299ea ("drm/xe: refactor xe_mmio_probe_tiles to support
>>   MMIO extension")
>>
>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> Cc: Koby Elbaz <kelbaz@habana.ai>
>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>
> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>, but let's wait
> a day or 2 to give a chance for others to take another look.
>
> Koby, can you ack this?
>
> thanks
> Lucas De Marchi


Also looked from EU Debugger perspective 
(https://patchwork.freedesktop.org/series/142295/).

Just wanted to double check we don't rely on mmio_ext there. We don't. Good.

Acked-by: Maciej Patelczyk <maciej.patelczyk@intel.com>


Regards,

Maciej


  reply	other threads:[~2025-01-09  8:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-06 23:43 [PATCH] drm/xe: Remove unused "mmio_ext" code Matt Roper
2025-01-07  0:18 ` ✓ CI.Patch_applied: success for " Patchwork
2025-01-07  0:18 ` ✓ CI.checkpatch: " Patchwork
2025-01-07  0:19 ` ✓ CI.KUnit: " Patchwork
2025-01-07  0:38 ` ✓ CI.Build: " Patchwork
2025-01-07  0:40 ` ✓ CI.Hooks: " Patchwork
2025-01-07  0:41 ` ✓ CI.checksparse: " Patchwork
2025-01-07  1:07 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-08  3:07 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-14 20:23   ` Matt Roper
2025-01-08  3:39 ` [PATCH] " Lucas De Marchi
2025-01-09  8:32   ` Maciej Patelczyk [this message]
2025-01-09 16:13 ` Summers, Stuart
2025-01-15  9:46 ` Levi, Ilia
2025-01-21 16:39   ` Matt Roper

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=56a714bb-fe4e-44f4-a0b3-774fed63ecd9@intel.com \
    --to=maciej.patelczyk@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kelbaz@habana.ai \
    --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