All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Summers, Stuart" <stuart.summers@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Yang,  Fei" <fei.yang@intel.com>
Cc: "Brost, Matthew" <matthew.brost@intel.com>
Subject: Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
Date: Tue, 17 Mar 2026 23:28:14 +0000	[thread overview]
Message-ID: <6a481f4d814c4247dcb62929b72e153ab7905cc7.camel@intel.com> (raw)
In-Reply-To: <20260317232133.4106716-1-fei.yang@intel.com>

On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
> From: Fei Yang <fei.yang@intel.com>
> 
> Hardware requires the software to poll the valid bit and make sure
> it's
> cleared before issuing a new TLB invalidation request.
> 
> Signed-off-by: Fei Yang <fei.yang@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> index ced58f46f846..4c2f87db3167 100644
> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval
> *tlb_inval, u32 seqno)
>         struct xe_guc *guc = tlb_inval->private;
>         struct xe_gt *gt = guc_to_gt(guc);
>         struct xe_device *xe = guc_to_xe(guc);
> +       int ret;
>  
>         /*
>          * Returning -ECANCELED in this function is squashed at the
> caller and
> @@ -85,11 +86,25 @@ static int send_tlb_inval_ggtt(struct
> xe_tlb_inval *tlb_inval, u32 seqno)
>  
>                 CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
>                 if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe)
> >= 20) {
> +                       /* Wait 1-second for the valid bit to be
> cleared */
> +                       ret = xe_mmio_wait32(mmio,
> PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> +                                            0, 1000 * USEC_PER_MSEC,
> NULL, false);
> +                       if (ret) {
> +                               pr_info("TLB INVAL cancelled due to
> uncleared valid bit\n");
> +                               return -ECANCELED;
> +                       }

Is there a reason we aren't waiting after the write to make sure the
invalidation completed? It seems like we should be serializing these
and at least making sure hardware completes the request rather than
just sending and hoping for the best.

Thanks,
Stuart

>                         xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
>                                         PVC_GUC_TLB_INV_DESC1_INVALID
> ATE);
>                         xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
>                                         PVC_GUC_TLB_INV_DESC0_VALID);
>                 } else {
> +                       /* Wait 1-second for the valid bit to be
> cleared */
> +                       ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR,
> GUC_TLB_INV_CR_INVALIDATE,
> +                                            0, 1000 * USEC_PER_MSEC,
> NULL, false);
> +                       if (ret) {
> +                               pr_info("TLB INVAL cancelled due to
> uncleared valid bit\n");
> +                               return -ECANCELED;
> +                       }
>                         xe_mmio_write32(mmio, GUC_TLB_INV_CR,
>                                         GUC_TLB_INV_CR_INVALIDATE);
>                 }


  parent reply	other threads:[~2026-03-17 23:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17 23:21 [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval fei.yang
2026-03-17 23:24 ` ✗ CI.checkpatch: warning for " Patchwork
2026-03-17 23:25 ` ✓ CI.KUnit: success " Patchwork
2026-03-17 23:28 ` Summers, Stuart [this message]
2026-03-22  5:35   ` [PATCH] " Matthew Brost
2026-03-24 20:39     ` Yang, Fei
2026-03-24 20:53       ` Matthew Brost
2026-03-24 20:58         ` Matthew Brost
2026-03-24 21:10           ` Summers, Stuart
2026-03-24 23:36             ` Matthew Brost
2026-03-25 18:37               ` Summers, Stuart
2026-03-25 22:00                 ` Matthew Brost
2026-03-25 22:25                   ` Summers, Stuart
2026-03-25 22:38                     ` Matthew Brost
2026-03-25 22:43                       ` Summers, Stuart
2026-03-26  0:54                         ` Matthew Brost
2026-03-18  0:08 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-03-19 12:33 ` ✓ Xe.CI.FULL: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2026-04-04  6:22 [PATCH] " fei.yang
2026-04-06 18:59 ` Matthew Brost
2026-04-06 21:01 ` Matt Roper
2026-04-18  0:03 fei.yang
2026-04-20 19:58 ` Summers, Stuart
2026-04-22  2:40 ` Matthew Brost
2026-04-22  2:49   ` Matthew Brost

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=6a481f4d814c4247dcb62929b72e153ab7905cc7.camel@intel.com \
    --to=stuart.summers@intel.com \
    --cc=fei.yang@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@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.