Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <fei.yang@intel.com>, <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 1/1] drm/xe: TileAddrRange registers are being deprecated.
Date: Wed, 1 Oct 2025 15:31:38 -0700	[thread overview]
Message-ID: <20251001223138.GC5409@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <v6n2utoszshbmafm2feeghgbyte34ackrurhogrvlgqooobd35@rapdbux7fc3k>

On Wed, Oct 01, 2025 at 03:15:14PM -0500, Lucas De Marchi wrote:
> On Tue, Sep 30, 2025 at 04:26:45PM -0700, fei.yang@intel.com wrote:
> > From: Fei Yang <fei.yang@intel.com>
> > 
> > Quoting BSpec: 59353, "The TILEx_ADDR_RANGE registers no longer have any
> > impact on HW behavior. They now function only as scratch registers for
> > communication between SoC FW and the GPU driver, and will eventually be
> > replaced by equivalent registers within SoC MMIO space. At that point,
> > these registers can be deprecated from XeTLB.".
> > While the transition is ongoing, the SGAddrRangeforTile continues to be
> > valid and works on all platforms supported by xe, reading that instead
> > to avoid potential breakage.
> > 
> > BSpec: 59353, 54991
> > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > ---
> > drivers/gpu/drm/xe/regs/xe_gt_regs.h | 3 ++-
> > drivers/gpu/drm/xe/xe_vram.c         | 2 +-
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/xe/regs/xe_gt_regs.h b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> > index 06cb6b02ec64..484598d81cce 100644
> > --- a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> > +++ b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> > @@ -95,10 +95,11 @@
> > 
> > #define XE2_LMEM_CFG				XE_REG(0x48b0)
> > 
> > -#define XEHP_TILE_ADDR_RANGE(_idx)		XE_REG_MCR(0x4900 + (_idx) * 4)
> > #define XEHP_FLAT_CCS_BASE_ADDR			XE_REG_MCR(0x4910)
> > #define XEHP_FLAT_CCS_PTR			REG_GENMASK(31, 8)
> > 
> > +#define XEHP_SG_TILE_ADDR_RANGE(_idx)		XE_REG(0x1083a0 + (_idx) * 4)
> 
> so... this is not a GT reg, it shouldn't be in xe_gt_regs.h

We should also probably move the forcewake get/put from this function
down into get_flat_ccs_offset() since that's the only place we're
actually touching the GT now.


Matt

> No need for arch/platform prefix neither as we will always use it.
> 
> Adding this diff as a fixup:
> 
> 
> diff --git a/drivers/gpu/drm/xe/regs/xe_gt_regs.h b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> index 484598d81cce4..28df6dbbf0d31 100644
> --- a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> +++ b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> @@ -98,8 +98,6 @@
>  #define XEHP_FLAT_CCS_BASE_ADDR			XE_REG_MCR(0x4910)
>  #define XEHP_FLAT_CCS_PTR			REG_GENMASK(31, 8)
> -#define XEHP_SG_TILE_ADDR_RANGE(_idx)		XE_REG(0x1083a0 + (_idx) * 4)
> -
>  #define WM_CHICKEN3				XE_REG_MCR(0x5588, XE_REG_OPTION_MASKED)
>  #define   HIZ_PLANE_COMPRESSION_DIS		REG_BIT(10)
> diff --git a/drivers/gpu/drm/xe/regs/xe_regs.h b/drivers/gpu/drm/xe/regs/xe_regs.h
> index 1926b4044314e..ad93c57edd17c 100644
> --- a/drivers/gpu/drm/xe/regs/xe_regs.h
> +++ b/drivers/gpu/drm/xe/regs/xe_regs.h
> @@ -40,6 +40,8 @@
>  #define STOLEN_RESERVED				XE_REG(0x1082c0)
>  #define   WOPCM_SIZE_MASK			REG_GENMASK64(9, 7)
> +#define SG_TILE_ADDR_RANGE(_idx)		XE_REG(0x1083a0 + (_idx) * 4)
> +
>  #define MTL_RP_STATE_CAP			XE_REG(0x138000)
>  #define MTL_GT_RPA_FREQUENCY			XE_REG(0x138008)
> diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
> index 74cc04412abc5..4c35c41c91c73 100644
> --- a/drivers/gpu/drm/xe/xe_vram.c
> +++ b/drivers/gpu/drm/xe/xe_vram.c
> @@ -255,7 +255,7 @@ static int tile_vram_size(struct xe_tile *tile, u64 *vram_size,
>  		*tile_size = pci_resource_len(to_pci_dev(xe->drm.dev), LMEM_BAR);
>  		*tile_offset = 0;
>  	} else {
> -		reg = xe_mmio_read32(&tile->mmio, XEHP_SG_TILE_ADDR_RANGE(tile->id));
> +		reg = xe_mmio_read32(&tile->mmio, SG_TILE_ADDR_RANGE(tile->id));
>  		*tile_size = (u64)REG_FIELD_GET(GENMASK(14, 8), reg) * SZ_1G;
>  		*tile_offset = (u64)REG_FIELD_GET(GENMASK(7, 1), reg) * SZ_1G;
>  	}
> 
> Lucas De Marchi

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

  reply	other threads:[~2025-10-01 22:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-30 23:26 [PATCH 0/1] drm/xe: TileAddrRange registers are being deprecated fei.yang
2025-09-30 23:26 ` [PATCH 1/1] " fei.yang
2025-10-01 20:15   ` Lucas De Marchi
2025-10-01 22:31     ` Matt Roper [this message]
2025-10-01  0:13 ` ✓ CI.KUnit: success for " Patchwork
2025-10-01  0:54 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-01  3:12 ` ✓ Xe.CI.Full: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2025-09-29 20:12 [PATCH 0/1] " fei.yang
2025-09-29 20:12 ` [PATCH 1/1] " fei.yang
2025-09-30 14:36   ` Lucas De Marchi

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=20251001223138.GC5409@mdroper-desk1.amr.corp.intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=fei.yang@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@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