diff mbox series

[v11] drm/xe/vsec: Support BMG devices

Message ID 20240812200422.444078-1-michael.j.ruhl@intel.com (mailing list archive)
State Changes Requested, archived
Headers show
Series [v11] drm/xe/vsec: Support BMG devices | expand

Commit Message

Michael J. Ruhl Aug. 12, 2024, 8:04 p.m. UTC
The Battlemage (BMG) discrete graphics card supports
the Platform, Monitoring Technology (PMT) feature
directly on the primary PCI device.

Utilize the PMT callback API to add support for the BMG
devices.

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
---

v10:
  Use the mutex guard feature
  Use the xe_pm_runtime_get_if_active() return value correctly
  Add r/b from Ilpo
  Deferred DG2 patches for the future
v11:
  add include for cleanup.h
  
 drivers/gpu/drm/xe/Makefile          |   1 +
 drivers/gpu/drm/xe/xe_device.c       |   5 +
 drivers/gpu/drm/xe/xe_device_types.h |   6 +
 drivers/gpu/drm/xe/xe_vsec.c         | 222 +++++++++++++++++++++++++++
 drivers/gpu/drm/xe/xe_vsec.h         |  13 ++
 5 files changed, 247 insertions(+)
 create mode 100644 drivers/gpu/drm/xe/xe_vsec.c
 create mode 100644 drivers/gpu/drm/xe/xe_vsec.h

Comments

Andy Shevchenko Aug. 13, 2024, 2:11 p.m. UTC | #1
On Mon, Aug 12, 2024 at 04:04:22PM -0400, Michael J. Ruhl wrote:
> The Battlemage (BMG) discrete graphics card supports
> the Platform, Monitoring Technology (PMT) feature
> directly on the primary PCI device.
> 
> Utilize the PMT callback API to add support for the BMG
> devices.

...

> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/cleanup.h>
> +#include <linux/intel_vsec.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/pci.h>

...

> +#define SOC_BASE		0x280000
> +
> +#define BMG_PMT_BASE		0xDB000
> +#define BMG_DISCOVERY_OFFSET	(SOC_BASE + BMG_PMT_BASE)

> +#define BMG_TELEMETRY_BASE	0xE0000
> +#define BMG_TELEMETRY_OFFSET	(SOC_BASE + BMG_TELEMETRY_BASE)

This looks like double indirection.
Wouldn't suffix _BASE_OFFSET be better for PMT and TELEMETRY cases?

...

> +#define BMG_DEVICE_ID 0xE2F8

Is this defined in any specification? I mean is the format the same as PCI device ID?

...

> +#define GFX_BAR			0

Do you need a separate definition for this?

...

> +enum record_id {
> +	PUNIT,
> +	OOBMSM_0,
> +	OOBMSM_1

Trailing comma?

> +};
> +
> +enum capability {
> +	CRASHLOG,
> +	TELEMETRY,
> +	WATCHER

Ditto?

> +};

...

> +	switch (record_id) {
> +	case PUNIT:
> +		*index = 0;
> +		if (cap_type == TELEMETRY)
> +			*offset = PUNIT_TELEMETRY_OFFSET;
> +		else
> +			*offset = PUNIT_WATCHER_OFFSET;
> +		break;
> +
> +	case OOBMSM_0:
> +		*index = 1;
> +		if (cap_type == WATCHER)
> +			*offset = OOBMSM_0_WATCHER_OFFSET;
> +		break;
> +
> +	case OOBMSM_1:
> +		*index = 1;
> +		if (cap_type == TELEMETRY)
> +			*offset = OOBMSM_1_TELEMETRY_OFFSET;
> +		break;

default case?

> +	}

...

> +static int xe_pmt_telem_read(struct pci_dev *pdev, u32 guid, u64 *data, u32 count)
> +{
> +	struct xe_device *xe = pdev_to_xe_device(pdev);
> +	void __iomem *telem_addr = xe->mmio.regs + BMG_TELEMETRY_OFFSET;
> +	u32 mem_region;
> +	u32 offset;
> +	int ret;
> +
> +	ret = guid_decode(guid, &mem_region, &offset);
> +	if (ret)
> +		return ret;
> +
> +	telem_addr += offset;
> +
> +	guard(mutex)(&xe->pmt.lock);
> +
> +	/* indicate that we are not at an appropriate power level */
> +	if (!xe_pm_runtime_get_if_active(xe))
> +		return -ENODATA;
> +
> +	/* set SoC re-mapper index register based on GUID memory region */
> +	xe_mmio_rmw32(xe->tiles[0].primary_gt, SG_REMAP_INDEX1, SG_REMAP_BITS,
> +		      FIELD_PREP(SG_REMAP_BITS, mem_region));
> +
> +	memcpy_fromio(data, telem_addr, count);

> +	ret = count;
> +	xe_pm_runtime_put(xe);

Does this have a side effect on count? If yes, a comment, if no, you may return
count directly.

> +	return ret;
> +}
Michael J. Ruhl Aug. 13, 2024, 2:29 p.m. UTC | #2
> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Sent: Tuesday, August 13, 2024 10:11 AM
> To: Ruhl, Michael J <michael.j.ruhl@intel.com>
> Cc: intel-xe@lists.freedesktop.org; platform-driver-x86@vger.kernel.org;
> david.e.box@linux.intel.com; ilpo.jarvinen@linux.intel.com; Brost, Matthew
> <matthew.brost@intel.com>; hdegoede@redhat.com; Vivi, Rodrigo
> <rodrigo.vivi@intel.com>
> Subject: Re: [PATCH v11] drm/xe/vsec: Support BMG devices
> 
> On Mon, Aug 12, 2024 at 04:04:22PM -0400, Michael J. Ruhl wrote:
> > The Battlemage (BMG) discrete graphics card supports the Platform,
> > Monitoring Technology (PMT) feature directly on the primary PCI
> > device.
> >
> > Utilize the PMT callback API to add support for the BMG devices.
> 
> ...
> 
> > +#include <linux/bitfield.h>
> > +#include <linux/bits.h>
> > +#include <linux/cleanup.h>
> > +#include <linux/intel_vsec.h>
> > +#include <linux/module.h>
> > +#include <linux/mutex.h>
> > +#include <linux/pci.h>
> 
> ...
> 
> > +#define SOC_BASE		0x280000
> > +
> > +#define BMG_PMT_BASE		0xDB000
> > +#define BMG_DISCOVERY_OFFSET	(SOC_BASE + BMG_PMT_BASE)
> 
> > +#define BMG_TELEMETRY_BASE	0xE0000
> > +#define BMG_TELEMETRY_OFFSET	(SOC_BASE + BMG_TELEMETRY_BASE)
> 
> This looks like double indirection.
> Wouldn't suffix _BASE_OFFSET be better for PMT and TELEMETRY cases?

I am not sure I understand.

Are  you saying rename BMG_PMT_BASE to BMG_PMT_BASE_OFFSET?

> 
> ...
> 
> > +#define BMG_DEVICE_ID 0xE2F8
> 
> Is this defined in any specification? I mean is the format the same as PCI device
> ID?

I think that this is defined in BMG PMT yaml definition.  It is provide in the PMT discovery
data, so it is defined by the specific device. 


> ...
> 
> > +#define GFX_BAR			0
> 
> Do you need a separate definition for this?

Guess not.  Will remove. 
Andy Shevchenko Aug. 14, 2024, 1:56 p.m. UTC | #3
On Tue, Aug 13, 2024 at 02:29:27PM +0000, Ruhl, Michael J wrote:
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Sent: Tuesday, August 13, 2024 10:11 AM
> > On Mon, Aug 12, 2024 at 04:04:22PM -0400, Michael J. Ruhl wrote:

...

> > > +#define SOC_BASE		0x280000
> > > +
> > > +#define BMG_PMT_BASE		0xDB000
> > > +#define BMG_DISCOVERY_OFFSET	(SOC_BASE + BMG_PMT_BASE)
> > 
> > > +#define BMG_TELEMETRY_BASE	0xE0000
> > > +#define BMG_TELEMETRY_OFFSET	(SOC_BASE + BMG_TELEMETRY_BASE)
> > 
> > This looks like double indirection.
> > Wouldn't suffix _BASE_OFFSET be better for PMT and TELEMETRY cases?
> 
> I am not sure I understand.
> 
> Are  you saying rename BMG_PMT_BASE to BMG_PMT_BASE_OFFSET?

Yes. Same for BMG_TELEMETRY_.

...

> > > +#define BMG_DEVICE_ID 0xE2F8
> > 
> > Is this defined in any specification? I mean is the format the same as PCI device
> > ID?
> 
> I think that this is defined in BMG PMT yaml definition.  It is provide in
> the PMT discovery data, so it is defined by the specific device. 

Is there any documentation / specification about this?
Can it be UUID or 64-bit number or other format?
_Where_ is this being specified?

...

> > > +	switch (record_id) {
> > > +	case PUNIT:
> > > +		*index = 0;
> > > +		if (cap_type == TELEMETRY)
> > > +			*offset = PUNIT_TELEMETRY_OFFSET;
> > > +		else
> > > +			*offset = PUNIT_WATCHER_OFFSET;
> > > +		break;
> > > +
> > > +	case OOBMSM_0:
> > > +		*index = 1;
> > > +		if (cap_type == WATCHER)
> > > +			*offset = OOBMSM_0_WATCHER_OFFSET;
> > > +		break;
> > > +
> > > +	case OOBMSM_1:
> > > +		*index = 1;
> > > +		if (cap_type == TELEMETRY)
> > > +			*offset = OOBMSM_1_TELEMETRY_OFFSET;
> > > +		break;
> > 
> > default case?
> 
> I validate the record_id and cap_type values at the beginning of the function,
> so default would be redundant.
> 
> The goal was to validate, then set data.
> 
> So adding the default will remove the record_id check from the if.  Do you prefer
> that path?

Yes.

> > > +	}
Michael J. Ruhl Aug. 14, 2024, 4:49 p.m. UTC | #4
> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Sent: Wednesday, August 14, 2024 9:56 AM
> To: Ruhl, Michael J <michael.j.ruhl@intel.com>
> Cc: intel-xe@lists.freedesktop.org; platform-driver-x86@vger.kernel.org;
> david.e.box@linux.intel.com; ilpo.jarvinen@linux.intel.com; Brost, Matthew
> <matthew.brost@intel.com>; hdegoede@redhat.com; Vivi, Rodrigo
> <rodrigo.vivi@intel.com>
> Subject: Re: [PATCH v11] drm/xe/vsec: Support BMG devices
> 
> On Tue, Aug 13, 2024 at 02:29:27PM +0000, Ruhl, Michael J wrote:
> > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Sent: Tuesday, August 13, 2024 10:11 AM On Mon, Aug 12, 2024 at
> > > 04:04:22PM -0400, Michael J. Ruhl wrote:
> 
> ...
> 
> > > > +#define SOC_BASE		0x280000
> > > > +
> > > > +#define BMG_PMT_BASE		0xDB000
> > > > +#define BMG_DISCOVERY_OFFSET	(SOC_BASE +
> BMG_PMT_BASE)
> > >
> > > > +#define BMG_TELEMETRY_BASE	0xE0000
> > > > +#define BMG_TELEMETRY_OFFSET	(SOC_BASE +
> BMG_TELEMETRY_BASE)
> > >
> > > This looks like double indirection.
> > > Wouldn't suffix _BASE_OFFSET be better for PMT and TELEMETRY cases?
> >
> > I am not sure I understand.
> >
> > Are  you saying rename BMG_PMT_BASE to BMG_PMT_BASE_OFFSET?
> 
> Yes. Same for BMG_TELEMETRY_.

Got it. I will update.
 
> ...
> 
> > > > +#define BMG_DEVICE_ID 0xE2F8
> > >
> > > Is this defined in any specification? I mean is the format the same
> > > as PCI device ID?
> >
> > I think that this is defined in BMG PMT yaml definition.  It is
> > provide in the PMT discovery data, so it is defined by the specific device.
> 
> Is there any documentation / specification about this?
> Can it be UUID or 64-bit number or other format?
> _Where_ is this being specified?

The GUID is defined by the YAML file associated with the PMT device.  In this
case 16 bits are a device ID.

From the cover letter of the PMT patch set (Intel Platform Monitoring Technology):

-
The GUID uniquely identifies the register space of any monitor data exposed
by the capability. The GUID is associated with an XML file from the vendor
that describes the mapping of the register space along with properties of the
monitor data.
--

I was told that this was the value to use for this specific device/feature.

It is specified internally.  Not sure if there is any "documentation" available beyond
that.

> ...
> 
> > > > +	switch (record_id) {
> > > > +	case PUNIT:
> > > > +		*index = 0;
> > > > +		if (cap_type == TELEMETRY)
> > > > +			*offset = PUNIT_TELEMETRY_OFFSET;
> > > > +		else
> > > > +			*offset = PUNIT_WATCHER_OFFSET;
> > > > +		break;
> > > > +
> > > > +	case OOBMSM_0:
> > > > +		*index = 1;
> > > > +		if (cap_type == WATCHER)
> > > > +			*offset = OOBMSM_0_WATCHER_OFFSET;
> > > > +		break;
> > > > +
> > > > +	case OOBMSM_1:
> > > > +		*index = 1;
> > > > +		if (cap_type == TELEMETRY)
> > > > +			*offset = OOBMSM_1_TELEMETRY_OFFSET;
> > > > +		break;
> > >
> > > default case?
> >
> > I validate the record_id and cap_type values at the beginning of the
> > function, so default would be redundant.
> >
> > The goal was to validate, then set data.
> >
> > So adding the default will remove the record_id check from the if.  Do
> > you prefer that path?
> 
> Yes.

Ok, I will update.

Thanks!

Mike

 
> > > > +	}
> 
> --
> With Best Regards,
> Andy Shevchenko
>
Andy Shevchenko Aug. 14, 2024, 6:41 p.m. UTC | #5
On Wed, Aug 14, 2024 at 04:49:05PM +0000, Ruhl, Michael J wrote:
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Sent: Wednesday, August 14, 2024 9:56 AM
> > On Tue, Aug 13, 2024 at 02:29:27PM +0000, Ruhl, Michael J wrote:
> > > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > Sent: Tuesday, August 13, 2024 10:11 AM On Mon, Aug 12, 2024 at
> > > > 04:04:22PM -0400, Michael J. Ruhl wrote:

...

> > > > > +#define BMG_DEVICE_ID 0xE2F8
> > > >
> > > > Is this defined in any specification? I mean is the format the same
> > > > as PCI device ID?
> > >
> > > I think that this is defined in BMG PMT yaml definition.  It is
> > > provide in the PMT discovery data, so it is defined by the specific device.
> > 
> > Is there any documentation / specification about this?
> > Can it be UUID or 64-bit number or other format?
> > _Where_ is this being specified?
> 
> The GUID is defined by the YAML file associated with the PMT device.  In this
> case 16 bits are a device ID.
> 
> From the cover letter of the PMT patch set (Intel Platform Monitoring Technology):
> 
> -
> The GUID uniquely identifies the register space of any monitor data exposed
> by the capability. The GUID is associated with an XML file from the vendor
> that describes the mapping of the register space along with properties of the
> monitor data.
> --
> 
> I was told that this was the value to use for this specific device/feature.
> 
> It is specified internally.  Not sure if there is any "documentation" available beyond
> that.

The YAML is *not* the specification. Do we have one that I can access to?
And I asked not about GUID, I asked about ID.
Michael J. Ruhl Aug. 14, 2024, 8:47 p.m. UTC | #6
> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Sent: Wednesday, August 14, 2024 2:41 PM
> To: Ruhl, Michael J <michael.j.ruhl@intel.com>
> Cc: intel-xe@lists.freedesktop.org; platform-driver-x86@vger.kernel.org;
> david.e.box@linux.intel.com; ilpo.jarvinen@linux.intel.com; Brost, Matthew
> <matthew.brost@intel.com>; hdegoede@redhat.com; Vivi, Rodrigo
> <rodrigo.vivi@intel.com>
> Subject: Re: [PATCH v11] drm/xe/vsec: Support BMG devices
> 
> On Wed, Aug 14, 2024 at 04:49:05PM +0000, Ruhl, Michael J wrote:
> > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Sent: Wednesday, August 14, 2024 9:56 AM On Tue, Aug 13, 2024 at
> > > 02:29:27PM +0000, Ruhl, Michael J wrote:
> > > > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > > Sent: Tuesday, August 13, 2024 10:11 AM On Mon, Aug 12, 2024 at
> > > > > 04:04:22PM -0400, Michael J. Ruhl wrote:
> 
> ...
> 
> > > > > > +#define BMG_DEVICE_ID 0xE2F8
> > > > >
> > > > > Is this defined in any specification? I mean is the format the
> > > > > same as PCI device ID?
> > > >
> > > > I think that this is defined in BMG PMT yaml definition.  It is
> > > > provide in the PMT discovery data, so it is defined by the specific device.
> > >
> > > Is there any documentation / specification about this?
> > > Can it be UUID or 64-bit number or other format?
> > > _Where_ is this being specified?
> >
> > The GUID is defined by the YAML file associated with the PMT device.
> > In this case 16 bits are a device ID.
> >
> > From the cover letter of the PMT patch set (Intel Platform Monitoring
> Technology):
> >
> > -
> > The GUID uniquely identifies the register space of any monitor data
> > exposed by the capability. The GUID is associated with an XML file
> > from the vendor that describes the mapping of the register space along
> > with properties of the monitor data.
> > --
> >
> > I was told that this was the value to use for this specific device/feature.
> >
> > It is specified internally.  Not sure if there is any "documentation"
> > available beyond that.
> 
> The YAML is *not* the specification. Do we have one that I can access to?
> And I asked not about GUID, I asked about ID.

Andy,

For the BMG device, the device ID is defined as part PMT GUID, and 
will be defined by the BMG PMT YAML specification.

So this is a vendor defined value.

Need to do some testing, and then I will re-post the patch.

Thanks!

M

> --
> With Best Regards,
> Andy Shevchenko
>
Andy Shevchenko Aug. 15, 2024, 10:55 a.m. UTC | #7
On Wed, Aug 14, 2024 at 08:47:28PM +0000, Ruhl, Michael J wrote:
> > -----Original Message-----
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Sent: Wednesday, August 14, 2024 2:41 PM
> > On Wed, Aug 14, 2024 at 04:49:05PM +0000, Ruhl, Michael J wrote:
> > > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > Sent: Wednesday, August 14, 2024 9:56 AM On Tue, Aug 13, 2024 at
> > > > 02:29:27PM +0000, Ruhl, Michael J wrote:
> > > > > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > > > Sent: Tuesday, August 13, 2024 10:11 AM On Mon, Aug 12, 2024 at
> > > > > > 04:04:22PM -0400, Michael J. Ruhl wrote:

...

> > > > > > > +#define BMG_DEVICE_ID 0xE2F8
> > > > > >
> > > > > > Is this defined in any specification? I mean is the format the
> > > > > > same as PCI device ID?
> > > > >
> > > > > I think that this is defined in BMG PMT yaml definition.  It is
> > > > > provide in the PMT discovery data, so it is defined by the specific device.
> > > >
> > > > Is there any documentation / specification about this?
> > > > Can it be UUID or 64-bit number or other format?
> > > > _Where_ is this being specified?
> > >
> > > The GUID is defined by the YAML file associated with the PMT device.
> > > In this case 16 bits are a device ID.
> > >
> > > From the cover letter of the PMT patch set (Intel Platform Monitoring
> > Technology):
> > >
> > > -
> > > The GUID uniquely identifies the register space of any monitor data
> > > exposed by the capability. The GUID is associated with an XML file
> > > from the vendor that describes the mapping of the register space along
> > > with properties of the monitor data.
> > > --
> > >
> > > I was told that this was the value to use for this specific device/feature.
> > >
> > > It is specified internally.  Not sure if there is any "documentation"
> > > available beyond that.
> > 
> > The YAML is *not* the specification. Do we have one that I can access to?
> > And I asked not about GUID, I asked about ID.
> 
> Andy,
> 
> For the BMG device, the device ID is defined as part PMT GUID, and 
> will be defined by the BMG PMT YAML specification.
> 
> So this is a vendor defined value.

Okay, thank you for clarification.

> Need to do some testing, and then I will re-post the patch.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 628c245c4822..f4c6761dc2e7 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -129,6 +129,7 @@  xe-y += xe_bb.o \
 	xe_vm.o \
 	xe_vram.o \
 	xe_vram_freq.o \
+	xe_vsec.o \
 	xe_wait_user_fence.o \
 	xe_wa.o \
 	xe_wopcm.o
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 76109415eba6..a7c759c98560 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -53,6 +53,7 @@ 
 #include "xe_ttm_sys_mgr.h"
 #include "xe_vm.h"
 #include "xe_vram.h"
+#include "xe_vsec.h"
 #include "xe_wait_user_fence.h"
 
 static int xe_file_open(struct drm_device *dev, struct drm_file *file)
@@ -317,6 +318,8 @@  struct xe_device *xe_device_create(struct pci_dev *pdev,
 		goto err;
 	}
 
+	drmm_mutex_init(&xe->drm, &xe->pmt.lock);
+
 	err = xe_display_create(xe);
 	if (WARN_ON(err))
 		goto err;
@@ -692,6 +695,8 @@  int xe_device_probe(struct xe_device *xe)
 	for_each_gt(gt, xe, id)
 		xe_gt_sanitize_freq(gt);
 
+	xe_vsec_init(xe);
+
 	return devm_add_action_or_reset(xe->drm.dev, xe_device_sanitize, xe);
 
 err_fini_display:
diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
index 3bca6d344744..448a92148081 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -451,6 +451,12 @@  struct xe_device {
 		struct mutex lock;
 	} d3cold;
 
+	/** @pmt: Support the PMT driver callback interface */
+	struct {
+		/** @pmt.lock: protect access for telemetry data */
+		struct mutex lock;
+	} pmt;
+
 	/**
 	 * @pm_callback_task: Track the active task that is running in either
 	 * the runtime_suspend or runtime_resume callbacks.
diff --git a/drivers/gpu/drm/xe/xe_vsec.c b/drivers/gpu/drm/xe/xe_vsec.c
new file mode 100644
index 000000000000..907203765dec
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_vsec.c
@@ -0,0 +1,222 @@ 
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright © 2022 - 2024 Intel Corporation
+ */
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/intel_vsec.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/pci.h>
+
+#include "xe_device.h"
+#include "xe_device_types.h"
+#include "xe_drv.h"
+#include "xe_mmio.h"
+#include "xe_platform_types.h"
+#include "xe_pm.h"
+#include "xe_vsec.h"
+
+#define SOC_BASE		0x280000
+
+#define BMG_PMT_BASE		0xDB000
+#define BMG_DISCOVERY_OFFSET	(SOC_BASE + BMG_PMT_BASE)
+
+#define BMG_TELEMETRY_BASE	0xE0000
+#define BMG_TELEMETRY_OFFSET	(SOC_BASE + BMG_TELEMETRY_BASE)
+
+#define BMG_DEVICE_ID 0xE2F8
+
+#define GFX_BAR			0
+
+#define SG_REMAP_INDEX1		XE_REG(SOC_BASE + 0x08)
+#define SG_REMAP_BITS		GENMASK(31, 24)
+
+static struct intel_vsec_header bmg_telemetry = {
+	.length = 0x10,
+	.id = VSEC_ID_TELEMETRY,
+	.num_entries = 2,
+	.entry_size = 4,
+	.tbir = GFX_BAR,
+	.offset = BMG_DISCOVERY_OFFSET,
+};
+
+static struct intel_vsec_header *bmg_capabilities[] = {
+	&bmg_telemetry,
+	NULL
+};
+
+enum xe_vsec {
+	XE_VSEC_UNKNOWN = 0,
+	XE_VSEC_BMG,
+};
+
+static struct intel_vsec_platform_info xe_vsec_info[] = {
+	[XE_VSEC_BMG] = {
+		.caps = VSEC_CAP_TELEMETRY,
+		.headers = bmg_capabilities,
+	},
+	{ }
+};
+
+/*
+ * The GUID will have the following bits to decode:
+ *
+ * X(4bits) - {Telemetry space iteration number (0,1,..)}
+ * X(4bits) - Segment (SEGMENT_INDEPENDENT-0, Client-1, Server-2)
+ * X(4bits) - SOC_SKU
+ * XXXX(16bits)– Device ID – changes for each down bin SKU’s
+ * X(2bits) - Capability Type (Crashlog-0, Telemetry Aggregator-1, Watcher-2)
+ * X(2bits) - Record-ID (0-PUNIT, 1-OOBMSM_0, 2-OOBMSM_1)
+ */
+#define GUID_TELEM_ITERATION	GENMASK(3, 0)
+#define GUID_SEGMENT		GENMASK(7, 4)
+#define GUID_SOC_SKU		GENMASK(11, 8)
+#define GUID_DEVICE_ID		GENMASK(27, 12)
+#define GUID_CAP_TYPE		GENMASK(29, 28)
+#define GUID_RECORD_ID		GENMASK(31, 30)
+
+#define PUNIT_TELEMETRY_OFFSET		0x0200
+#define PUNIT_WATCHER_OFFSET		0x14A0
+#define OOBMSM_0_WATCHER_OFFSET		0x18D8
+#define OOBMSM_1_TELEMETRY_OFFSET	0x1000
+
+enum record_id {
+	PUNIT,
+	OOBMSM_0,
+	OOBMSM_1
+};
+
+enum capability {
+	CRASHLOG,
+	TELEMETRY,
+	WATCHER
+};
+
+static int guid_decode(u32 guid, int *index, u32 *offset)
+{
+	u32 record_id = FIELD_GET(GUID_RECORD_ID, guid);
+	u32 cap_type  = FIELD_GET(GUID_CAP_TYPE, guid);
+	u32 device_id = FIELD_GET(GUID_DEVICE_ID, guid);
+
+	if (device_id != BMG_DEVICE_ID)
+		return -ENODEV;
+
+	if (record_id > OOBMSM_1 || cap_type > WATCHER)
+		return -EINVAL;
+
+	*offset = 0;
+
+	if (cap_type == CRASHLOG) {
+		*index = record_id == PUNIT ? 2 : 4;
+		return 0;
+	}
+
+	switch (record_id) {
+	case PUNIT:
+		*index = 0;
+		if (cap_type == TELEMETRY)
+			*offset = PUNIT_TELEMETRY_OFFSET;
+		else
+			*offset = PUNIT_WATCHER_OFFSET;
+		break;
+
+	case OOBMSM_0:
+		*index = 1;
+		if (cap_type == WATCHER)
+			*offset = OOBMSM_0_WATCHER_OFFSET;
+		break;
+
+	case OOBMSM_1:
+		*index = 1;
+		if (cap_type == TELEMETRY)
+			*offset = OOBMSM_1_TELEMETRY_OFFSET;
+		break;
+	}
+
+	return 0;
+}
+
+static int xe_pmt_telem_read(struct pci_dev *pdev, u32 guid, u64 *data, u32 count)
+{
+	struct xe_device *xe = pdev_to_xe_device(pdev);
+	void __iomem *telem_addr = xe->mmio.regs + BMG_TELEMETRY_OFFSET;
+	u32 mem_region;
+	u32 offset;
+	int ret;
+
+	ret = guid_decode(guid, &mem_region, &offset);
+	if (ret)
+		return ret;
+
+	telem_addr += offset;
+
+	guard(mutex)(&xe->pmt.lock);
+
+	/* indicate that we are not at an appropriate power level */
+	if (!xe_pm_runtime_get_if_active(xe))
+		return -ENODATA;
+
+	/* set SoC re-mapper index register based on GUID memory region */
+	xe_mmio_rmw32(xe->tiles[0].primary_gt, SG_REMAP_INDEX1, SG_REMAP_BITS,
+		      FIELD_PREP(SG_REMAP_BITS, mem_region));
+
+	memcpy_fromio(data, telem_addr, count);
+	ret = count;
+	xe_pm_runtime_put(xe);
+
+	return ret;
+}
+
+struct pmt_callbacks xe_pmt_cb = {
+	.read_telem = xe_pmt_telem_read,
+};
+
+static const int vsec_platforms[] = {
+	[XE_BATTLEMAGE] = XE_VSEC_BMG,
+};
+
+static enum xe_vsec get_platform_info(struct xe_device *xe)
+{
+	if (xe->info.platform > XE_BATTLEMAGE)
+		return XE_VSEC_UNKNOWN;
+
+	return vsec_platforms[xe->info.platform];
+}
+
+/**
+ * xe_vsec_init - Initialize resources and add intel_vsec auxiliary
+ * interface
+ * @xe: valid xe instance
+ */
+void xe_vsec_init(struct xe_device *xe)
+{
+	struct intel_vsec_platform_info *info;
+	struct device *dev = xe->drm.dev;
+	struct pci_dev *pdev = to_pci_dev(dev);
+	enum xe_vsec platform;
+
+	platform = get_platform_info(xe);
+	if (platform == XE_VSEC_UNKNOWN)
+		return;
+
+	info = &xe_vsec_info[platform];
+	if (!info->headers)
+		return;
+
+	switch (platform) {
+	case XE_VSEC_BMG:
+		info->priv_data = &xe_pmt_cb;
+		break;
+	default:
+		break;
+	}
+
+	/*
+	 * Register a VSEC. Cleanup is handled using device managed
+	 * resources.
+	 */
+	intel_vsec_register(pdev, info);
+}
+MODULE_IMPORT_NS(INTEL_VSEC);
diff --git a/drivers/gpu/drm/xe/xe_vsec.h b/drivers/gpu/drm/xe/xe_vsec.h
new file mode 100644
index 000000000000..3fd29a21cad6
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_vsec.h
@@ -0,0 +1,13 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright © 2022 - 2024 Intel Corporation
+ */
+
+#ifndef _XE_VSEC_H_
+#define _XE_VSEC_H_
+
+struct xe_device;
+
+void xe_vsec_init(struct xe_device *xe);
+
+#endif