All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [RFC 2/4] drm/xe/multi_queue: Refactor CGP_SYNC send path
Date: Thu, 23 Apr 2026 14:32:03 -0700	[thread overview]
Message-ID: <aeqP01OXUXVRiDou@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260423024954.1665095-8-niranjana.vishwanathapura@intel.com>

On Wed, Apr 22, 2026 at 07:49:54PM -0700, Niranjana Vishwanathapura wrote:
> Factor the repeated CGP_SYNC action build-and-send sequence into a new
> helper guc_exec_queue_send_cgp_sync(). Drop the redundant guc parameter
> from __register_exec_queue_group() since it can be derived via
> exec_queue_to_guc(q). Remove xe_guc_exec_queue_group_add() which is now
> identical to the helper and replace its call site directly.
> 
> No functional change.
> 
> Assisted-by: GitHub Copilot:claude-sonnet-4.6
> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>

Reviewed-by: Matthew Brost <matthew.brost@intel.com>

> ---
>  drivers/gpu/drm/xe/xe_guc_submit.c | 65 +++++++++++-------------------
>  1 file changed, 23 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index 104e65913dff..4171eff4e8ad 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -852,10 +852,27 @@ static void xe_guc_exec_queue_group_cgp_sync(struct xe_guc *guc,
>  	xe_guc_ct_send(&guc->ct, action, len, G2H_LEN_DW_MULTI_QUEUE_CONTEXT, 1);
>  }
>  
> -static void __register_exec_queue_group(struct xe_guc *guc,
> -					struct xe_exec_queue *q,
> +static void guc_exec_queue_send_cgp_sync(struct xe_exec_queue *q)
> +{
> +#define MAX_MULTI_QUEUE_CGP_SYNC_SIZE	(2)
> +	struct xe_guc *guc = exec_queue_to_guc(q);
> +	struct xe_exec_queue_group *group = q->multi_queue.group;
> +	u32 action[MAX_MULTI_QUEUE_CGP_SYNC_SIZE];
> +	int len = 0;
> +
> +	action[len++] = XE_GUC_ACTION_MULTI_QUEUE_CONTEXT_CGP_SYNC;
> +	action[len++] = group->primary->guc->id;
> +
> +	xe_gt_assert(guc_to_gt(guc), len <= MAX_MULTI_QUEUE_CGP_SYNC_SIZE);
> +#undef MAX_MULTI_QUEUE_CGP_SYNC_SIZE
> +
> +	xe_guc_exec_queue_group_cgp_sync(guc, q, action, len);
> +}
> +
> +static void __register_exec_queue_group(struct xe_exec_queue *q,
>  					struct guc_ctxt_registration_info *info)
>  {
> +	struct xe_guc *guc = exec_queue_to_guc(q);
>  #define MAX_MULTI_QUEUE_REG_SIZE	(8)
>  	u32 action[MAX_MULTI_QUEUE_REG_SIZE];
>  	int len = 0;
> @@ -880,29 +897,6 @@ static void __register_exec_queue_group(struct xe_guc *guc,
>  	xe_guc_exec_queue_group_cgp_sync(guc, q, action, len);
>  }
>  
> -static void xe_guc_exec_queue_group_add(struct xe_guc *guc,
> -					struct xe_exec_queue *q)
> -{
> -#define MAX_MULTI_QUEUE_CGP_SYNC_SIZE  (2)
> -	u32 action[MAX_MULTI_QUEUE_CGP_SYNC_SIZE];
> -	int len = 0;
> -
> -	xe_gt_assert(guc_to_gt(guc), xe_exec_queue_is_multi_queue_secondary(q));
> -
> -	action[len++] = XE_GUC_ACTION_MULTI_QUEUE_CONTEXT_CGP_SYNC;
> -	action[len++] = q->multi_queue.group->primary->guc->id;
> -
> -	xe_gt_assert(guc_to_gt(guc), len <= MAX_MULTI_QUEUE_CGP_SYNC_SIZE);
> -#undef MAX_MULTI_QUEUE_CGP_SYNC_SIZE
> -
> -	/*
> -	 * The above XE_GUC_ACTION_MULTI_QUEUE_CONTEXT_CGP_SYNC do expect a
> -	 * XE_GUC_ACTION_NOTIFY_MULTI_QUEUE_CONTEXT_CGP_SYNC_DONE response
> -	 * from guc.
> -	 */
> -	xe_guc_exec_queue_group_cgp_sync(guc, q, action, len);
> -}
> -
>  static void __register_mlrc_exec_queue(struct xe_guc *guc,
>  				       struct xe_exec_queue *q,
>  				       struct guc_ctxt_registration_info *info)
> @@ -1028,7 +1022,7 @@ static void register_exec_queue(struct xe_exec_queue *q, int ctx_type)
>  	set_exec_queue_registered(q);
>  	trace_xe_exec_queue_register(q);
>  	if (xe_exec_queue_is_multi_queue_primary(q))
> -		__register_exec_queue_group(guc, q, &info);
> +		__register_exec_queue_group(q, &info);
>  	else if (xe_exec_queue_is_parallel(q))
>  		__register_mlrc_exec_queue(guc, q, &info);
>  	else if (!xe_exec_queue_is_multi_queue_secondary(q))
> @@ -1038,7 +1032,7 @@ static void register_exec_queue(struct xe_exec_queue *q, int ctx_type)
>  		init_policies(guc, q);
>  
>  	if (xe_exec_queue_is_multi_queue_secondary(q))
> -		xe_guc_exec_queue_group_add(guc, q);
> +		guc_exec_queue_send_cgp_sync(q);
>  }
>  
>  static u32 wq_space_until_wrap(struct xe_exec_queue *q)
> @@ -1887,21 +1881,8 @@ static void __guc_exec_queue_process_msg_set_multi_queue_priority(struct xe_sche
>  {
>  	struct xe_exec_queue *q = msg->private_data;
>  
> -	if (guc_exec_queue_allowed_to_change_state(q)) {
> -#define MAX_MULTI_QUEUE_CGP_SYNC_SIZE        (2)
> -		struct xe_guc *guc = exec_queue_to_guc(q);
> -		struct xe_exec_queue_group *group = q->multi_queue.group;
> -		u32 action[MAX_MULTI_QUEUE_CGP_SYNC_SIZE];
> -		int len = 0;
> -
> -		action[len++] = XE_GUC_ACTION_MULTI_QUEUE_CONTEXT_CGP_SYNC;
> -		action[len++] = group->primary->guc->id;
> -
> -		xe_gt_assert(guc_to_gt(guc), len <= MAX_MULTI_QUEUE_CGP_SYNC_SIZE);
> -#undef MAX_MULTI_QUEUE_CGP_SYNC_SIZE
> -
> -		xe_guc_exec_queue_group_cgp_sync(guc, q, action, len);
> -	}
> +	if (guc_exec_queue_allowed_to_change_state(q))
> +		guc_exec_queue_send_cgp_sync(q);
>  
>  	kfree(msg);
>  }
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-04-23 21:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23  2:49 [RFC 0/4] drm/xe/multi_queue: Handle lost message during VF migration Niranjana Vishwanathapura
2026-04-23  2:49 ` [RFC 1/4] drm/xe/multi_queue: Remove redundant assignment in guc_exec_queue_run_job Niranjana Vishwanathapura
2026-04-23 21:30   ` Matthew Brost
2026-04-23  2:49 ` [RFC 2/4] drm/xe/multi_queue: Refactor CGP_SYNC send path Niranjana Vishwanathapura
2026-04-23 21:32   ` Matthew Brost [this message]
2026-04-23  2:49 ` [RFC 3/4] drm/xe/multi_queue: Handle VF recovery in CGP_SYNC and queue registration paths Niranjana Vishwanathapura
2026-04-23 21:45   ` Matthew Brost
2026-04-23  2:49 ` [RFC 4/4] drm/xe/multi_queue: Add needs_cgp_sync mechanism for VF post-migration recovery Niranjana Vishwanathapura
2026-04-23 21:44   ` Matthew Brost
2026-04-23  2:55 ` ✗ CI.checkpatch: warning for drm/xe/multi_queue: Handle lost message during VF migration Patchwork
2026-04-23  2:57 ` ✓ CI.KUnit: success " Patchwork
2026-04-23  3:44 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-23 13:29 ` ✗ Xe.CI.FULL: failure " 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=aeqP01OXUXVRiDou@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=niranjana.vishwanathapura@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.