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 |
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; > +}
> -----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.
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. > > > + }
> -----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 >
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.
> -----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 >
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 --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