Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 06/22] drm/xe: Kernel doc GT TLB invalidations
Date: Fri, 17 Feb 2023 11:22:40 -0500	[thread overview]
Message-ID: <Y++p0PVsTCn7DF2y@intel.com> (raw)
In-Reply-To: <Y+rGAG5HWN5pcvVM@mdroper-desk1.amr.corp.intel.com>

On Mon, Feb 13, 2023 at 03:21:36PM -0800, Matt Roper wrote:
> On Fri, Feb 03, 2023 at 03:23:53PM -0500, Rodrigo Vivi wrote:
> > From: Matthew Brost <matthew.brost@intel.com>
> > 
> > Document all exported functions.
> > 
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> >  drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 52 ++++++++++++++++++++-
> >  1 file changed, 51 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c
> > index 23094d364583..1cb4d3a6bc57 100644
> > --- a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c
> > +++ b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c
> > @@ -14,6 +14,15 @@ guc_to_gt(struct xe_guc *guc)
> >  	return container_of(guc, struct xe_gt, uc.guc);
> >  }
> >  
> > +/**
> > + * xe_gt_tlb_invalidation_init - Initialize GT TLB invalidation state
> > + * @gt: graphics tile
> > + *
> > + * Initialize GT TLB invalidation state, purely software initialization, should
> > + * be called once during driver load.
> > + *
> > + * Return: 0 on success, negative error code on error.
> > + */
> >  int xe_gt_tlb_invalidation_init(struct xe_gt *gt)
> >  {
> >  	gt->tlb_invalidation.seqno = 1;
> > @@ -24,7 +33,13 @@ int xe_gt_tlb_invalidation_init(struct xe_gt *gt)
> >  	return 0;
> >  }
> >  
> > -void xe_gt_tlb_invalidation_reset(struct xe_gt *gt)
> > +/**
> > + * xe_gt_tlb_invalidation_reset - Initialize GT TLB invalidation reset
> 
> The description here is confusing.  We're not really "initializing"
> anything here.
> 
> > + * @gt: graphics tile
> > + *
> > + * Signal any pending invalidation fences, should be called during a GT reset
> 
> Is it confirmed that a GDRST-initiated reset implicitly invalidates all
> the engine TLBs (and thus just signalling all the fences is sufficient)?
> Or does the GuC take care of this itself while it is being
> (re)initialized?  I know there are a lot of parts of the GT that don't
> actually get reset when requesting GRDOM_FULL, but it's never been very
> well documented exactly what those are.

Since I'm trying to avoid more rebases with these already reviewed and
merged patches, I created an issue to track the changes needed and to
ensure that you get the answers here:

https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/212

> 
> 
> Matt
> 
> > + */
> > + void xe_gt_tlb_invalidation_reset(struct xe_gt *gt)
> >  {
> >  	struct xe_gt_tlb_invalidation_fence *fence, *next;
> >  
> > @@ -82,6 +97,19 @@ static int send_tlb_invalidation(struct xe_guc *guc,
> >  	return ret;
> >  }
> >  
> > +/**
> > + * xe_gt_tlb_invalidation - Issue a TLB invalidation on this GT
> > + * @gt: graphics tile
> > + * @fence: invalidation fence which will be signal on TLB invalidation
> > + * completion, can be NULL
> > + *
> > + * Issue a full TLB invalidation on the GT. Completion of TLB is asynchronous
> > + * and caller can either use the invalidation fence or seqno +
> > + * xe_gt_tlb_invalidation_wait to wait for completion.
> > + *
> > + * Return: Seqno which can be passed to xe_gt_tlb_invalidation_wait on success,
> > + * negative error code on error.
> > + */
> >  int xe_gt_tlb_invalidation(struct xe_gt *gt,
> >  			   struct xe_gt_tlb_invalidation_fence *fence)
> >  {
> > @@ -100,6 +128,16 @@ static bool tlb_invalidation_seqno_past(struct xe_gt *gt, int seqno)
> >  	return false;
> >  }
> >  
> > +/**
> > + * xe_gt_tlb_invalidation_wait - Wait for TLB to complete
> > + * @gt: graphics tile
> > + * @seqno: seqno to wait which was returned from xe_gt_tlb_invalidation
> > + *
> > + * Wait for 200ms for a TLB invalidation to complete, in practice we always
> > + * should receive the TLB invalidation within 200ms.
> > + *
> > + * Return: 0 on success, -ETIME on TLB invalidation timeout
> > + */
> >  int xe_gt_tlb_invalidation_wait(struct xe_gt *gt, int seqno)
> >  {
> >  	struct xe_device *xe = gt_to_xe(gt);
> > @@ -122,6 +160,18 @@ int xe_gt_tlb_invalidation_wait(struct xe_gt *gt, int seqno)
> >  	return 0;
> >  }
> >  
> > +/**
> > + * xe_guc_tlb_invalidation_done_handler - TLB invalidation done handler
> > + * @guc: guc
> > + * @msg: message indicating TLB invalidation done
> > + * @len: length of message
> > + *
> > + * Parse seqno of TLB invalidation, wake any waiters for seqno, and signal any
> > + * invalidation fences for seqno. Algorithm for this depends on seqno being
> > + * received in-order and asserts this assumption.
> > + *
> > + * Return: 0 on success, -EPROTO for malformed messages.
> > + */
> >  int xe_guc_tlb_invalidation_done_handler(struct xe_guc *guc, u32 *msg, u32 len)
> >  {
> >  	struct xe_gt *gt = guc_to_gt(guc);
> > -- 
> > 2.39.1
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

  reply	other threads:[~2023-02-17 16:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 20:23 [Intel-xe] [PATCH 00/22] TLB Invalidation Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 01/22] drm/xe: Don't process TLB invalidation done in CT fast-path Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 02/22] drm/xe: Break of TLB invalidation into its own file Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 03/22] drm/xe: Move TLB invalidation variable to own sub-structure in GT Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 04/22] drm/xe: Add TLB invalidation fence Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 05/22] drm/xe: Invalidate TLB after unbind is complete Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 06/22] drm/xe: Kernel doc GT TLB invalidations Rodrigo Vivi
2023-02-13 23:21   ` Matt Roper
2023-02-17 16:22     ` Rodrigo Vivi [this message]
2023-02-03 20:23 ` [Intel-xe] [PATCH 07/22] drm/xe: Add TLB invalidation fence ftrace Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 08/22] drm/xe: Fix build for CONFIG_DRM_XE_DEBUG Rodrigo Vivi
2023-02-13 23:22   ` Matt Roper
2023-02-17 16:24     ` Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 09/22] drm/xe: Add TDR for invalidation fence timeout cleanup Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 10/22] drm/xe: Only set VM->asid for platforms that support a ASID Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 11/22] drm/xe: Delete debugfs entry to issue TLB invalidation Rodrigo Vivi
2023-02-03 20:23 ` [Intel-xe] [PATCH 12/22] drm/xe: Add has_range_tlb_invalidation device attribute Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 13/22] drm/xe: Add range based TLB invalidations Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 14/22] drm/xe: Propagate error from bind operations to async fence Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 15/22] drm/xe: Use GuC to do GGTT invalidations for the GuC firmware Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 16/22] drm/xe: Coalesce GGTT invalidations Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 17/22] drm/xe: Lock GGTT on when restoring kernel BOs Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 18/22] drm/xe: Propagate VM unbind error to invalidation fence Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 19/22] drm/xe: Signal invalidation fence immediately if CT send fails Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 20/22] drm/xe: Add has_asid to device info Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 21/22] drm/xe: Add TLB invalidation fence after rebinds issued from execs Rodrigo Vivi
2023-02-03 20:24 ` [Intel-xe] [PATCH 22/22] drm/xe: Drop TLB invalidation from ring operations Rodrigo Vivi
2023-02-06 22:39 ` [Intel-xe] [PATCH 00/22] TLB Invalidation Niranjana Vishwanathapura
2023-02-08 17:27   ` Rodrigo Vivi
2023-02-09  4:54     ` Niranjana Vishwanathapura
2023-02-09  4:59       ` Niranjana Vishwanathapura

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=Y++p0PVsTCn7DF2y@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --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