From: "Summers, Stuart" <stuart.summers@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Souza, Jose" <jose.souza@intel.com>
Cc: "dev@lankhorst.se" <dev@lankhorst.se>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 3/9] drm/xe: Add functions to convert regular address to canonical address and back
Date: Mon, 29 Jan 2024 17:54:28 +0000 [thread overview]
Message-ID: <043020557ea305aa9e75ad2f855ce9c19bc47b09.camel@intel.com> (raw)
In-Reply-To: <a628246a5fc0667208594e4e683c29904e947b2a.camel@intel.com>
On Wed, 2024-01-24 at 15:20 +0000, Souza, Jose wrote:
> On Wed, 2024-01-24 at 15:16 +0000, Summers, Stuart wrote:
> > On Mon, 2024-01-22 at 18:43 +0000, Souza, Jose wrote:
> > > On Mon, 2024-01-22 at 18:38 +0000, Summers, Stuart wrote:
> > > > On Mon, 2024-01-22 at 09:04 -0800, José Roberto de Souza wrote:
> > > > > Some instructions requires canonical address like
> > > > > MI_BATCH_BUFFER_START(UMDs must call xe_exec with a canonical
> > > > > address
> > > > > for Xe2+).
> > > > >
> > > > > So here adding functions to convert regular address to
> > > > > canonical
> > > > > address and back, the first user of this functions will be
> > > > > added
> > > > > in the next patches.
> > > > >
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Cc: Maarten Lankhorst <dev@lankhorst.se>
> > > > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > ---
> > > > > drivers/gpu/drm/xe/xe_device.c | 15 +++++++++++++++
> > > > > drivers/gpu/drm/xe/xe_device.h | 3 +++
> > > > > 2 files changed, 18 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/xe/xe_device.c
> > > > > b/drivers/gpu/drm/xe/xe_device.c
> > > > > index ab417f4f7d2a7..b4cdcf1b2081a 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_device.c
> > > > > +++ b/drivers/gpu/drm/xe/xe_device.c
> > > > > @@ -727,3 +727,18 @@ void xe_device_mem_access_put(struct
> > > > > xe_device
> > > > > *xe)
> > > > >
> > > > > xe_assert(xe, ref >= 0);
> > > > > }
> > > > > +
> > > > > +static inline int highest_address_bit_get(struct xe_device
> > > > > *xe)
> > > > > +{
> > > > > + return xe->info.dma_mask_size > 48 ? 57 : 47;
> > > >
> > > > Why not just xe->info.dma_mask_size - 1?
> > >
> > > We have platforms that set dma_mask_size to 39, 46 and 52 but the
> > > canonical address boundaries is 48bit and 58bit bits.
> >
> > hm.. I feel like it would be more clear to have a canonical size
> > then
> > and then do (canonical_size - 1).
>
> Like this?
>
> static inline int highest_address_bit_get(struct xe_device *xe)
Well, this naming doesn't make sense if we do it this way IMO.
Maybe just va_top() or va_max()?
Or, for instance, in i915 we are using ppgtt_msb:
i915_pci.c: .ppgtt_msb = 47, \
i915_pci.c: .ppgtt_msb = 47, \
i915_pci.c: .ppgtt_msb = 56, \
as a per-platform feature flag.
I think also there was a comment here about avoiding the "inline", were
you planning to address that?
Thanks,
Stuart
> {
> return xe->info.dma_mask_size > 48 ? 58 : 48;
> }
>
> u64 xe_device_canonicalize_addr(struct xe_device *xe, u64 address)
> {
> return sign_extend64(address, highest_address_bit_get(xe) -
> 1);
> }
>
> u64 xe_device_uncanonicalize_addr(struct xe_device *xe, u64 address)
> {
> return address & GENMASK_ULL(highest_address_bit_get(xe) - 1,
> 0);
> }
>
> >
> > Thanks,
> > Stuart
> >
> > >
> > > >
> > > > Thanks,
> > > > Stuart
> > > >
> > > > > +}
> > > > > +
> > > > > +u64 xe_device_canonicalize_addr(struct xe_device *xe, u64
> > > > > address)
> > > > > +{
> > > > > + return sign_extend64(address,
> > > > > highest_address_bit_get(xe));
> > > > > +}
> > > > > +
> > > > > +u64 xe_device_uncanonicalize_addr(struct xe_device *xe, u64
> > > > > address)
> > > > > +{
> > > > > + return address &
> > > > > GENMASK_ULL(highest_address_bit_get(xe),
> > > > > 0);
> > > > > +}
> > > > > diff --git a/drivers/gpu/drm/xe/xe_device.h
> > > > > b/drivers/gpu/drm/xe/xe_device.h
> > > > > index af8ac2e9e2709..ce20f6fe6219a 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_device.h
> > > > > +++ b/drivers/gpu/drm/xe/xe_device.h
> > > > > @@ -175,4 +175,7 @@ static inline bool
> > > > > xe_device_has_memirq(struct
> > > > > xe_device *xe)
> > > > >
> > > > > u32 xe_device_ccs_bytes(struct xe_device *xe, u64 size);
> > > > >
> > > > > +u64 xe_device_canonicalize_addr(struct xe_device *xe, u64
> > > > > address);
> > > > > +u64 xe_device_uncanonicalize_addr(struct xe_device *xe, u64
> > > > > address);
> > > > > +
> > > > > #endif
> > > >
> > >
> >
>
next prev parent reply other threads:[~2024-01-29 17:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 17:04 [PATCH 1/9] drm/xe: Remove double new line in devcoredump José Roberto de Souza
2024-01-22 17:04 ` [PATCH 2/9] drm/xe: Change devcoredump functions parameters to xe_sched_job José Roberto de Souza
2024-01-22 18:39 ` Summers, Stuart
2024-01-22 17:04 ` [PATCH 3/9] drm/xe: Add functions to convert regular address to canonical address and back José Roberto de Souza
2024-01-22 18:38 ` Summers, Stuart
2024-01-22 18:43 ` Souza, Jose
2024-01-24 15:16 ` Summers, Stuart
2024-01-24 15:20 ` Souza, Jose
2024-01-29 17:54 ` Summers, Stuart [this message]
2024-01-23 17:48 ` Jani Nikula
2024-01-22 17:04 ` [PATCH 4/9] drm/xe: Add batch buffer addresses to devcoredump José Roberto de Souza
2024-01-22 20:13 ` Rodrigo Vivi
2024-01-22 17:04 ` [PATCH 5/9] drm/xe: Nuke xe from xe_devcoredump José Roberto de Souza
2024-01-22 20:11 ` Rodrigo Vivi
2024-01-22 20:26 ` Souza, Jose
2024-01-22 20:40 ` Rodrigo Vivi
2024-01-22 17:04 ` [PATCH 6/9] drm/xe: Stash GMD_ID value in xe_gt José Roberto de Souza
2024-01-22 17:04 ` [PATCH 7/9] drm/xe: Print more device information in devcoredump José Roberto de Souza
2024-01-22 20:18 ` Rodrigo Vivi
2024-01-22 21:12 ` Souza, Jose
2024-01-22 17:04 ` [PATCH 8/9] drm/xe: Print registers spread in 2 u32 as u64 José Roberto de Souza
2024-01-22 20:14 ` Rodrigo Vivi
2024-01-22 17:04 ` [PATCH 9/9] drm/xe: Remove addional spaces in devcoredump HW Engines section José Roberto de Souza
2024-01-22 20:18 ` Rodrigo Vivi
2024-01-22 17:32 ` ✓ CI.Patch_applied: success for series starting with [1/9] drm/xe: Remove double new line in devcoredump Patchwork
2024-01-22 17:32 ` ✗ CI.checkpatch: warning " Patchwork
2024-01-22 17:33 ` ✓ CI.KUnit: success " Patchwork
2024-01-22 17:40 ` ✓ CI.Build: " Patchwork
2024-01-22 17:41 ` ✗ CI.Hooks: failure " Patchwork
2024-01-22 17:42 ` ✓ CI.checksparse: success " Patchwork
2024-01-22 18:05 ` ✓ CI.BAT: " Patchwork
2024-01-22 18:28 ` [PATCH 1/9] " Summers, Stuart
2024-01-22 18:40 ` Souza, Jose
2024-01-22 20:20 ` Rodrigo Vivi
2024-01-24 15:17 ` Summers, Stuart
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=043020557ea305aa9e75ad2f855ce9c19bc47b09.camel@intel.com \
--to=stuart.summers@intel.com \
--cc=dev@lankhorst.se \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.