All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH 11/12] drm/xe/gsc: Define GSCCS for MTL
Date: Mon, 13 Nov 2023 12:23:34 -0800	[thread overview]
Message-ID: <fb742073-a0df-4406-9e81-e27d049244e7@intel.com> (raw)
In-Reply-To: <20231027222928.1981633-12-daniele.ceraolospurio@intel.com>

On 10/27/2023 15:29, Daniele Ceraolo Spurio wrote:
> Add the GSCCS to the media_xelpmp engine list. Note that since the
> GSCCS is only used with the GSC FW, we can consider it disabled if we
> don't have the FW available.
>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
> ---
>   drivers/gpu/drm/xe/xe_hw_engine.c | 20 ++++++++++++++++++++
>   drivers/gpu/drm/xe/xe_pci.c       |  2 +-
>   2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_hw_engine.c b/drivers/gpu/drm/xe/xe_hw_engine.c
> index b5b084590888..142783177e45 100644
> --- a/drivers/gpu/drm/xe/xe_hw_engine.c
> +++ b/drivers/gpu/drm/xe/xe_hw_engine.c
> @@ -26,6 +26,7 @@
>   #include "xe_rtp.h"
>   #include "xe_sched_job.h"
>   #include "xe_tuning.h"
> +#include "xe_uc_fw.h"
>   #include "xe_wa.h"
>   
>   #define MAX_MMIO_BASES 3
> @@ -610,6 +611,24 @@ static void read_compute_fuses(struct xe_gt *gt)
>   		read_compute_fuses_from_dss(gt);
>   }
>   
> +static void check_gsc_availability(struct xe_gt *gt)
> +{
> +	struct xe_device *xe = gt_to_xe(gt);
> +
> +	if (!(gt->info.engine_mask & BIT(XE_HW_ENGINE_GSCCS0)))
> +		return;
> +
> +	/*
> +	 * The GSCCS is only used to communicate with the GSC FW, so if we don't
> +	 * have the FW there is nothing we need the engine for and can therefore
> +	 * skip its initialization.
Is that correct? Is this testing against a firmware image being 
available on the system or against a firmware blob being defined for the 
platform?

If the firmware is not available but was defined then presumably that 
means that any feature that is reliant upon GSC is going to be broken - 
HDCP, PXP, etc. It seems like that should warrant more than a drm_info 
level message.

On the other hand, if the check is about whether a firmware blob is 
defined for this platform then surely this code path wouldn't even be 
taken in the first place? This can only be reached if actually trying to 
load a firmware file at all, can't it?

John.

> +	 */
> +	if (!xe_uc_fw_is_available(&gt->uc.gsc.fw)) {
> +		gt->info.engine_mask &= ~BIT(XE_HW_ENGINE_GSCCS0);
> +		drm_info(&xe->drm, "gsccs disabled due to lack of FW\n");
> +	}
> +}
> +
>   int xe_hw_engines_init_early(struct xe_gt *gt)
>   {
>   	int i;
> @@ -617,6 +636,7 @@ int xe_hw_engines_init_early(struct xe_gt *gt)
>   	read_media_fuses(gt);
>   	read_copy_fuses(gt);
>   	read_compute_fuses(gt);
> +	check_gsc_availability(gt);
>   
>   	BUILD_BUG_ON(XE_HW_ENGINE_PREEMPT_TIMEOUT < XE_HW_ENGINE_PREEMPT_TIMEOUT_MIN);
>   	BUILD_BUG_ON(XE_HW_ENGINE_PREEMPT_TIMEOUT > XE_HW_ENGINE_PREEMPT_TIMEOUT_MAX);
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 2fae45b9d88e..c09b51735ee4 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -197,7 +197,7 @@ static const struct xe_media_desc media_xelpmp = {
>   	.name = "Xe_LPM+",
>   	.hw_engine_mask =
>   		BIT(XE_HW_ENGINE_VCS0) | BIT(XE_HW_ENGINE_VCS2) |
> -		BIT(XE_HW_ENGINE_VECS0),	/* TODO: add GSC0 */
> +		BIT(XE_HW_ENGINE_VECS0) | BIT(XE_HW_ENGINE_GSCCS0)
>   };
>   
>   static const struct xe_media_desc media_xe2 = {


  reply	other threads:[~2023-11-13 20:23 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-27 22:29 [Intel-xe] [PATCH 00/12] GSC FW loading Daniele Ceraolo Spurio
2023-10-27 22:29 ` [Intel-xe] [PATCH 01/12] drm/xe: implement driver initiated function-reset Daniele Ceraolo Spurio
2023-11-07 23:46   ` John Harrison
2023-11-08 18:14     ` Daniele Ceraolo Spurio
2023-10-27 22:29 ` [Intel-xe] [PATCH 02/12] fixup! drm/xe/guc: Report submission version of GuC firmware Daniele Ceraolo Spurio
2023-10-31 14:09   ` Andrzej Hajda
2023-10-31 19:00     ` Daniele Ceraolo Spurio
2023-11-07 23:07   ` John Harrison
2023-11-07 23:24     ` Daniele Ceraolo Spurio
2023-11-07 23:38       ` John Harrison
2023-11-09 19:59         ` Daniele Ceraolo Spurio
2023-10-27 22:29 ` [Intel-xe] [PATCH 03/12] drm/xe/uc: Rework uC version tracking Daniele Ceraolo Spurio
2023-11-07 23:20   ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 04/12] drm/xe/gsc: Introduce GSC FW Daniele Ceraolo Spurio
2023-11-07 23:26   ` John Harrison
2023-11-07 23:32     ` Daniele Ceraolo Spurio
2023-11-07 23:52       ` John Harrison
2023-11-07 23:59         ` Daniele Ceraolo Spurio
2023-10-27 22:29 ` [Intel-xe] [PATCH 05/12] drm/xe/gsc: Parse GSC FW header Daniele Ceraolo Spurio
2023-11-07 23:45   ` John Harrison
2023-11-07 23:57     ` Daniele Ceraolo Spurio
2023-11-08  0:42       ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 06/12] drm/xe/gsc: GSC FW load Daniele Ceraolo Spurio
2023-11-08 22:17   ` John Harrison
2023-11-08 22:23     ` Daniele Ceraolo Spurio
2023-11-08 22:29       ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 07/12] drm/xe/gsc: Implement WA 14015076503 Daniele Ceraolo Spurio
2023-11-08 22:22   ` John Harrison
2023-11-08 22:35     ` Daniele Ceraolo Spurio
2023-11-08 22:40       ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 08/12] drm/xe/gsc: Trigger a driver flr to cleanup the GSC on unload Daniele Ceraolo Spurio
2023-11-08 22:24   ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 09/12] drm/xe/gsc: Add an interface for GSC packet submissions Daniele Ceraolo Spurio
2023-10-31  8:08   ` Kandpal, Suraj
2023-10-31 19:29     ` Daniele Ceraolo Spurio
2023-11-08  8:25       ` Kandpal, Suraj
2023-11-13 19:59   ` John Harrison
2023-11-13 21:19     ` Daniele Ceraolo Spurio
2023-11-14 19:32       ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 10/12] drm/xe/gsc: Query GSC compatibility version Daniele Ceraolo Spurio
2023-11-13 20:10   ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 11/12] drm/xe/gsc: Define GSCCS for MTL Daniele Ceraolo Spurio
2023-11-13 20:23   ` John Harrison [this message]
2023-11-13 21:32     ` Daniele Ceraolo Spurio
2023-11-14 19:39       ` John Harrison
2023-10-27 22:29 ` [Intel-xe] [PATCH 12/12] drm/xe/gsc: Define GSC FW " Daniele Ceraolo Spurio
2023-11-13 20:26   ` John Harrison
2023-11-13 21:33     ` Daniele Ceraolo Spurio
2023-10-27 22:32 ` [Intel-xe] ✓ CI.Patch_applied: success for GSC FW loading Patchwork
2023-10-27 22:32 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-11-13 20:29   ` John Harrison
2023-10-27 22:33 ` [Intel-xe] ✗ CI.KUnit: failure " Patchwork
2023-11-13 20:30   ` John Harrison
2023-11-13 21:13     ` Daniele Ceraolo Spurio
2023-11-13 16:05 ` [Intel-xe] [PATCH 00/12] " Lucas De Marchi
2023-11-13 16:09   ` Daniele Ceraolo Spurio

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=fb742073-a0df-4406-9e81-e27d049244e7@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    /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.