All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Nareshkumar Gollakoti <naresh.kumar.g@intel.com>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v1 2/2] drm/xe: Mutual exclusivity between CCS-mode and PF
Date: Thu, 15 Jan 2026 23:50:25 +0100	[thread overview]
Message-ID: <6e156a0c-ff1d-4fdf-a7c8-b0e09341a230@intel.com> (raw)
In-Reply-To: <20251128171030.2774942-6-naresh.kumar.g@intel.com>



On 11/28/2025 6:10 PM, Nareshkumar Gollakoti wrote:
> Due to SLA agreement between PF and VFs,the alternate CCS-mode
> cannot be changed when VFs are already enabled.
> Similarly, enabling VFs is not permitted when the alternate
> CCS-mode is active.
> 
> Signed-off-by: Nareshkumar Gollakoti <naresh.kumar.g@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_gt_ccs_mode.c | 59 ++++++++++++++++++++++-------
>  drivers/gpu/drm/xe/xe_gt_ccs_mode.h | 12 ++++++
>  2 files changed, 57 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_gt_ccs_mode.c b/drivers/gpu/drm/xe/xe_gt_ccs_mode.c
> index e146e00b0ca2..6652c468e1be 100644
> --- a/drivers/gpu/drm/xe/xe_gt_ccs_mode.c
> +++ b/drivers/gpu/drm/xe/xe_gt_ccs_mode.c
> @@ -13,6 +13,7 @@
>  #include "xe_gt_sysfs.h"
>  #include "xe_mmio.h"
>  #include "xe_sriov.h"
> +#include "xe_sriov_pf.h"
>  
>  static void __xe_gt_apply_ccs_mode(struct xe_gt *gt, u32 num_engines)
>  {
> @@ -108,6 +109,36 @@ ccs_mode_show(struct device *kdev,
>  	return sysfs_emit(buf, "%u\n", gt->ccs_mode);
>  }
>  
> +static int gt_prepare_ccs_mode_enabling(struct xe_gt *gt)
> +{
> +	struct xe_device *xe = gt_to_xe(gt);
> +
> +	if (!IS_SRIOV_PF(xe))
> +		return 0;
> +
> +	/*
> +	 * We can't change CCS-mode when VFs are already enabled
> +	 * and we must prevent enabling VFs when alternate
> +	 * CCS-mode is active

nit: as it might be little hard to understand below logic, maybe add:

	 * Try to lockdown the PF only if CCS is still in default mode,
	 * will unlock PF after CCS is changed to the default mode again.

> +	 */
> +	if (xe_gt_ccs_mode_default(gt))
> +		return xe_sriov_pf_lockdown(xe);
> +
> +	return 0;
> +}
> +
> +static void gt_finish_ccs_mode_enabling(struct xe_gt *gt)
> +{
> +	struct xe_device *xe = gt_to_xe(gt);
> +
> +	if (!IS_SRIOV_PF(xe))
> +		return;
> +
> +	/* Allow enabling VFs, if CCS-mode changed to default mode */
> +	if (xe_gt_ccs_mode_default(gt))
> +		xe_sriov_pf_end_lockdown(xe);
> +}
> +
>  static ssize_t
>  ccs_mode_store(struct device *kdev, struct device_attribute *attr,
>  	       const char *buff, size_t count)
> @@ -117,12 +148,6 @@ ccs_mode_store(struct device *kdev, struct device_attribute *attr,
>  	u32 num_engines, num_slices;
>  	int ret;
>  
> -	if (IS_SRIOV(xe)) {
> -		xe_gt_dbg(gt, "Can't change compute mode when running as %s\n",
> -			  xe_sriov_mode_to_string(xe_device_sriov_mode(xe)));
> -		return -EOPNOTSUPP;
> -	}
> -
>  	ret = kstrtou32(buff, 0, &num_engines);
>  	if (ret)
>  		return ret;
> @@ -139,21 +164,27 @@ ccs_mode_store(struct device *kdev, struct device_attribute *attr,
>  	}
>  
>  	/* CCS mode can only be updated when there are no drm clients */
> -	mutex_lock(&xe->drm.filelist_mutex);
> +	guard(mutex)(&xe->drm.filelist_mutex);
>  	if (!list_empty(&xe->drm.filelist)) {
> -		mutex_unlock(&xe->drm.filelist_mutex);
>  		xe_gt_dbg(gt, "Rejecting compute mode change as there are active drm clients\n");
>  		return -EBUSY;
>  	}
>  
> -	if (gt->ccs_mode != num_engines) {
> -		xe_gt_info(gt, "Setting compute mode to %d\n", num_engines);
> -		gt->ccs_mode = num_engines;
> -		xe_gt_record_user_engines(gt);
> -		xe_gt_reset(gt);
> +	if (gt->ccs_mode == num_engines)> +		return count;
> +
> +	ret = gt_prepare_ccs_mode_enabling(gt);
> +	if (ret) {
> +		xe_gt_dbg(gt, "Rejecting compute mode change as VFs are enabled\n");

maybe this should be closer to the xe_sriov_pf_lockdown() call ?
or 'prepare' helper should be named differently ?
as here it is hard to match 'prepare_ccs_mode_enabling' name with VFs ...

> +		return ret;
>  	}

or make coding more straight:

	/*
	 * Changing default CCS mode is only allowed when there
	 * are no VFs. Try to lockdown PF to find out.
	 */
	if (xe_gt_ccs_mode_default(gt) && IS_SRIOV_PF(xe)) {
		ret = xe_sriov_pf_lockdown(xe);
		if (ret) {
			xe_gt_dbg(gt, "Can't change CCS mode: VFs are enabled\n");
			return ret;
		}
	}

>  
> -	mutex_unlock(&xe->drm.filelist_mutex);
> +	xe_gt_info(gt, "Setting compute mode to %d\n", num_engines);
> +	gt->ccs_mode = num_engines;
> +	xe_gt_record_user_engines(gt);
> +	xe_gt_reset(gt);
> +
> +	gt_finish_ccs_mode_enabling(gt);

and here:

	/* We may end PF lockdown once CCS mode is default again */
	if (xe_gt_ccs_mode_default(gt) && IS_SRIOV_PF(xe))
		xe_sriov_pf_end_lockdown(xe);

>  
>  	return count;
>  }
> diff --git a/drivers/gpu/drm/xe/xe_gt_ccs_mode.h b/drivers/gpu/drm/xe/xe_gt_ccs_mode.h
> index f8779852cf0d..53a595b0882c 100644
> --- a/drivers/gpu/drm/xe/xe_gt_ccs_mode.h
> +++ b/drivers/gpu/drm/xe/xe_gt_ccs_mode.h
> @@ -20,5 +20,17 @@ static inline bool xe_gt_ccs_mode_enabled(const struct xe_gt *gt)
>  	return hweight32(CCS_MASK(gt)) > 1;
>  }
>  
> +/**
> + * xe_gt_ccs_mode_default() - Check if CCS mode is default (single CCS mode)
> + * @gt: GT structure
> + *
> + * Return: %true if actual CCS mode is single mode, or
> + *         %false otherwise (CCS in alternate/multi mode)
> + */
> +static inline bool xe_gt_ccs_mode_default(struct xe_gt *gt)

if you don't plan to use this helper in other places than ccs_mode.c,
then just make it as a simple static helper in ccs_mode.c

> +{
> +	return gt->ccs_mode == 1;
> +}
> +
>  #endif
>  

otherwise LGTM


  reply	other threads:[~2026-01-15 22:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 14:28 [PATCH V5] drm/xe/: Mutual Exclusivity b/w Multi CCS Mode & SRIOV VF Provisioning Nareshkumar Gollakoti
2025-10-15 23:59 ` ✓ CI.KUnit: success for drm/xe/: Mutual Exclusivity b/w Multi CCS Mode & SRIOV VF Provisioning (rev6) Patchwork
2025-10-16  0:59 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-16 18:21 ` ✗ Xe.CI.Full: failure " Patchwork
2025-11-25 16:57 ` [V7 PATCH] drm/xe/xe_gt_ccs_mode:Mutual Exclusivity b/w Multi CCS Mode & SRIOV VF Provisioning Nareshkumar Gollakoti
2025-11-25 19:13   ` Michal Wajdeczko
2025-11-26 12:21     ` Kumar G, Naresh
2025-11-27 16:10   ` [V8 PATCH] drm/xe: Mutual exclusivity between CCS-mode and PF Nareshkumar Gollakoti
2025-11-27 17:02     ` Michal Wajdeczko
2025-11-26  1:13 ` ✓ CI.KUnit: success for drm/xe/: Mutual Exclusivity b/w Multi CCS Mode & SRIOV VF Provisioning (rev7) Patchwork
2025-11-26  2:18 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-11-26  4:48 ` ✗ Xe.CI.Full: " Patchwork
2025-11-27 16:25 ` ✓ CI.KUnit: success for drm/xe/: Mutual Exclusivity b/w Multi CCS Mode & SRIOV VF Provisioning (rev8) Patchwork
2025-11-27 17:29 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-27 19:17 ` ✗ Xe.CI.Full: failure " Patchwork
2025-11-28 12:38 ` [V9 PATCH] drm/xe: Mutual exclusivity between CCS-mode and PF Nareshkumar Gollakoti
2025-11-28 13:21   ` Michal Wajdeczko
2025-11-28 17:10   ` [PATCH v1 0/2] " Nareshkumar Gollakoti
2025-11-28 17:10     ` [PATCH v1 1/2] drm/xe: Fix Prevent VFs from exposing the CCS mode sysfs file Nareshkumar Gollakoti
2026-01-15 21:53       ` Michal Wajdeczko
2025-11-28 17:10     ` [PATCH v1 2/2] drm/xe: Mutual exclusivity between CCS-mode and PF Nareshkumar Gollakoti
2026-01-15 22:50       ` Michal Wajdeczko [this message]
2025-11-28 17:16   ` [PATCH v1 0/2] drm/xe:Mutual " Nareshkumar Gollakoti
2025-11-28 17:16     ` [PATCH v1 1/2] drm/xe: Fix Prevent VFs from exposing the CCS mode sysfs file Nareshkumar Gollakoti
2025-11-28 12:58 ` ✓ CI.KUnit: success for drm/xe/: Mutual Exclusivity b/w Multi CCS Mode & SRIOV VF Provisioning (rev9) Patchwork
2025-11-28 14:14 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-28 15:49 ` ✗ Xe.CI.Full: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2025-11-28 17:18 [PATCH v1 0/2] drm/xe:Mutual exclusivity between CCS-mode and PF Nareshkumar Gollakoti
2025-11-28 17:18 ` [PATCH v1 2/2] drm/xe: Mutual " Nareshkumar Gollakoti
2025-12-03  8:52   ` K V P, Satyanarayana
2025-12-03 12:13     ` Michal Wajdeczko
2025-12-03 12:43     ` Kumar G, Naresh

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=6e156a0c-ff1d-4fdf-a7c8-b0e09341a230@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=naresh.kumar.g@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.