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
next prev parent 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