Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Vivekanandan, Balasubramani" <balasubramani.vivekanandan@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH 06/11] drm/xe/xe2hpg: Determine flat ccs offset for vram
Date: Fri, 5 Apr 2024 15:18:32 +0530	[thread overview]
Message-ID: <Zg_I3KaYBoM78zAb@bvivekan-mobl2> (raw)
In-Reply-To: <Zgz6Si0AaY2A8x8c@bvivekan-mobl2>

On 03.04.2024 12:23, Vivekanandan, Balasubramani wrote:
> On 02.04.2024 07:30, Matt Roper wrote:
> > On Tue, Apr 02, 2024 at 06:17:19PM +0530, Balasubramani Vivekanandan wrote:
> > > From: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> > > 
> > > on Xe2 dgfx platform determine the offset using Flat CCS size
> > > bitfield of XE2_FLAT_CCS_BASE_RANGE_[UPPER/LOWER] mcr registers.
> > > 
> > > Bspec: 68023
> > > 
> > > Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> > > Signed-off-by: Akshata Jahagirdar <akshata.jahagirdar@intel.com>
> > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/regs/xe_gt_regs.h |  5 ++++
> > >  drivers/gpu/drm/xe/xe_mmio.c         | 39 ++++++++++++++++++++++++++--
> > >  2 files changed, 42 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 d5b21f03beaa..ea75c1f0ebd0 100644
> > > --- a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> > > +++ b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> > > @@ -69,6 +69,7 @@
> > >  
> > >  #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 WM_CHICKEN3				XE_REG_MCR(0x5588, XE_REG_OPTION_MASKED)
> > >  #define   HIZ_PLANE_COMPRESSION_DIS		REG_BIT(10)
> > > @@ -141,6 +142,10 @@
> > >  
> > >  #define XE2_FLAT_CCS_BASE_RANGE_LOWER		XE_REG_MCR(0x8800)
> > >  #define   XE2_FLAT_CCS_ENABLE			REG_BIT(0)
> > > +#define XE2_FLAT_CCS_BASE_LOWER_ADDR_MASK	REG_GENMASK(31, 6)
> > > +
> > > +#define XE2_FLAT_CCS_BASE_RANGE_UPPER		XE_REG_MCR(0x8804)
> > > +#define XE2_FLAT_CCS_BASE_UPPER_ADDR_MASK	REG_GENMASK(7, 0)
> > >  
> > >  #define GSCPSMI_BASE				XE_REG(0x880c)
> > >  
> > > diff --git a/drivers/gpu/drm/xe/xe_mmio.c b/drivers/gpu/drm/xe/xe_mmio.c
> > > index 5d13fc7cb9d2..49a32b03fcf8 100644
> > > --- a/drivers/gpu/drm/xe/xe_mmio.c
> > > +++ b/drivers/gpu/drm/xe/xe_mmio.c
> > > @@ -163,6 +163,42 @@ static int xe_determine_lmem_bar_size(struct xe_device *xe)
> > >  	return 0;
> > >  }
> > >  
> > > +static inline u64 get_flat_ccs_offset(struct xe_gt *gt, u64 *tile_size)
> > 
> > It doesn't seem to be necessary to pass by reference for tile_size.
> Correct, I will change it.
> > 
> > > +{
> > > +	struct xe_device *xe = gt_to_xe(gt);
> > > +	u64 offset;
> > > +	u32 reg;
> > > +
> > > +	if (GRAPHICS_VER(xe) >= 20) {
> > > +		u64 ccs_size = *tile_size / 512;
> > 
> > This value only gets used for the assertion below, but should we be 
> > taking the value from 0x8804[23:14] rather than deriving it from
> > TILE_ADDR_RANGE?
> The intention of the assertion is to verify if the flatccs base address
> provided by XE2_FLAT_CCS_BASE_RANGE_* register pair results in flatccs
> size which exactly matches the tile_size/512. In other words, it is
> validating the XE2_FLAT_CCS_BASE_RANGE_* content. 
> Therefore getting the flat_Css size from the
> XE2_FLAT_CCS_BASE_RANGE_UPPER(0x8804) itself doesn't seem to be the
> right approach to me.
> 
> > 
> > > +		u64 offset_hi, offset_lo;
> > > +		u32 nodes, num_enabled;
> > > +
> > > +		reg = xe_mmio_read32(gt, MIRROR_FUSE3);
> > > +		nodes = REG_FIELD_GET(XE2_NODE_ENABLE_MASK, reg);
> > > +		num_enabled = hweight32(nodes); /* Number of enabled l3 nodes */
> > > +
> > > +		reg = xe_gt_mcr_unicast_read_any(gt, XE2_FLAT_CCS_BASE_RANGE_LOWER);
> > > +		offset_lo = REG_FIELD_GET(XE2_FLAT_CCS_BASE_LOWER_ADDR_MASK, reg);
> > 
> > This register also appears to have a general "enable" bit for FlatCCS in
> > bit(0).  Should we be reading that to make sure FlatCCS hasn't been
> > fused off or disabled by the IFWI?
> yes, makes sense. I will update the patch.

While reworking on this change, I found that driver is already reading
this setting in the function xe_device_set_has_flat_ccs and updating the
flag has_flat_ccs.

Regards,
Bala

> 
> Regards,
> Bala
> 
> > 
> > 
> > Matt
> > 
> > > +
> > > +		reg = xe_gt_mcr_unicast_read_any(gt, XE2_FLAT_CCS_BASE_RANGE_UPPER);
> > > +		offset_hi = REG_FIELD_GET(XE2_FLAT_CCS_BASE_UPPER_ADDR_MASK, reg);
> > > +
> > > +		offset = offset_hi << 32; /* HW view bits 39:32 */
> > > +		offset |= offset_lo << 6; /* HW view bits 31:6 */
> > > +		offset *= num_enabled; /* convert to SW view */
> > > +
> > > +		/* We don't expect any holes */
> > > +		xe_assert_msg(xe, offset == (xe_mmio_read64_2x32(gt, GSMBASE) - ccs_size),
> > > +			      "Hole between CCS and GSM.\n");
> > > +	} else {
> > > +		reg = xe_gt_mcr_unicast_read_any(gt, XEHP_FLAT_CCS_BASE_ADDR);
> > > +		offset = (u64)REG_FIELD_GET(XEHP_FLAT_CCS_PTR, reg) * SZ_64K;
> > > +	}
> > > +
> > > +	return offset;
> > > +}
> > > +
> > >  /**
> > >   * xe_mmio_tile_vram_size() - Collect vram size and offset information
> > >   * @tile: tile to get info for
> > > @@ -207,8 +243,7 @@ static int xe_mmio_tile_vram_size(struct xe_tile *tile, u64 *vram_size,
> > >  
> > >  	/* minus device usage */
> > >  	if (xe->info.has_flat_ccs) {
> > > -		reg = xe_gt_mcr_unicast_read_any(gt, XEHP_FLAT_CCS_BASE_ADDR);
> > > -		offset = (u64)REG_FIELD_GET(GENMASK(31, 8), reg) * SZ_64K;
> > > +		offset = get_flat_ccs_offset(gt, tile_size);
> > >  	} else {
> > >  		offset = xe_mmio_read64_2x32(gt, GSMBASE);
> > >  	}
> > > -- 
> > > 2.25.1
> > > 
> > 
> > -- 
> > Matt Roper
> > Graphics Software Engineer
> > Linux GPU Platform Enablement
> > Intel Corporation

  reply	other threads:[~2024-04-05  9:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02 12:47 [PATCH 00/11] Add Battlemage support Balasubramani Vivekanandan
2024-04-02 12:47 ` [PATCH 01/11] drm/xe/xe2: Recognize Xe2_HPG IP Balasubramani Vivekanandan
2024-04-02 13:21   ` Lucas De Marchi
2024-04-02 12:47 ` [PATCH 02/11] drm/xe/xe2: Recognize Xe2_HPM IP Balasubramani Vivekanandan
2024-04-02 13:22   ` Lucas De Marchi
2024-04-02 12:47 ` [PATCH 03/11] drm/xe/bmg: Add BMG platform definition Balasubramani Vivekanandan
2024-04-02 13:26   ` Lucas De Marchi
2024-04-02 12:47 ` [PATCH 04/11] drm/xe/bmg: Add BMG mocs table Balasubramani Vivekanandan
2024-04-02 13:52   ` Matt Roper
2024-04-02 12:47 ` [PATCH 05/11] drm/xe/bmg: Program an additional discrete-specific PAT setting Balasubramani Vivekanandan
2024-04-02 12:47 ` [PATCH 06/11] drm/xe/xe2hpg: Determine flat ccs offset for vram Balasubramani Vivekanandan
2024-04-02 14:30   ` Matt Roper
2024-04-03  6:53     ` Vivekanandan, Balasubramani
2024-04-05  9:48       ` Vivekanandan, Balasubramani [this message]
2024-04-02 12:47 ` [PATCH 07/11] drm/xe/xe2hpg: Remove extra allocation of CCS pages for dgfx Balasubramani Vivekanandan
2024-04-02 14:40   ` Matt Roper
2024-04-02 12:47 ` [PATCH 08/11] drm/xe/xe2hpg: Limit chunk size to 4MiB for vram Balasubramani Vivekanandan
2024-04-04  0:06   ` Matt Roper
2024-04-06  2:28     ` Jahagirdar, Akshata
2024-04-02 12:47 ` [PATCH 09/11] drm/xe/xe2hpg: Add initial GT workarounds Balasubramani Vivekanandan
2024-04-02 15:45   ` Matt Roper
2024-04-02 19:14     ` Matt Roper
2024-04-02 12:47 ` [PATCH 10/11] drm/xe/xe2hpg: Introduce performance tuning changes for Xe2_HPG Balasubramani Vivekanandan
2024-04-02 15:55   ` Matt Roper
2024-04-02 12:47 ` [PATCH 11/11] drm/xe/xe2hpm: Add initial set of workarounds Balasubramani Vivekanandan
2024-04-02 16:07   ` Matt Roper
2024-04-02 12:53 ` ✓ CI.Patch_applied: success for Add Battlemage support Patchwork
2024-04-02 12:53 ` ✗ CI.checkpatch: warning " Patchwork
2024-04-02 12:54 ` ✓ CI.KUnit: success " Patchwork
2024-04-02 13:05 ` ✓ CI.Build: " Patchwork
2024-04-02 13:08 ` ✓ CI.Hooks: " Patchwork
2024-04-02 13:09 ` ✓ CI.checksparse: " Patchwork
2024-04-02 13:46 ` ✓ CI.BAT: " 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=Zg_I3KaYBoM78zAb@bvivekan-mobl2 \
    --to=balasubramani.vivekanandan@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --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