From: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
To: "Nilawar, Badal" <badal.nilawar@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <lucas.demarchi@intel.com>,
<ashutosh.dixit@intel.com>
Subject: Re: [PATCH v2 2/4] drm/xe/soc_remapper: Use SoC remapper herlper from VSEC code
Date: Tue, 2 Dec 2025 12:35:04 -0800 [thread overview]
Message-ID: <aS9NeKJ6Xqp6scG2@soc-5CG1426VCC.clients.intel.com> (raw)
In-Reply-To: <b4ac66ba-850d-4140-bfef-f91399e0540f@intel.com>
On Tue, Dec 02, 2025 at 10:33:28AM +0530, Nilawar, Badal wrote:
>
>On 18-11-2025 02:23, Umesh Nerlige Ramappa wrote:
>>Since different drivers can use SoC remapper, modify VSEC code to
>>access SoC remapper via a helper that would synchronize such accesses.
>>
>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>---
>>v2: (Lucas)
>>- retain comment
>>- s/BITS/MASK/
>>---
>> drivers/gpu/drm/xe/regs/xe_pmt.h | 3 ---
>> drivers/gpu/drm/xe/regs/xe_soc_remapper_regs.h | 13 +++++++++++++
>> drivers/gpu/drm/xe/xe_soc_remapper.c | 18 ++++++++++++++++++
>> drivers/gpu/drm/xe/xe_soc_remapper.h | 1 +
>> drivers/gpu/drm/xe/xe_vsec.c | 4 ++--
>> 5 files changed, 34 insertions(+), 5 deletions(-)
>> create mode 100644 drivers/gpu/drm/xe/regs/xe_soc_remapper_regs.h
>>
>>diff --git a/drivers/gpu/drm/xe/regs/xe_pmt.h b/drivers/gpu/drm/xe/regs/xe_pmt.h
>>index 0f79c0714454..240d57993ea6 100644
>>--- a/drivers/gpu/drm/xe/regs/xe_pmt.h
>>+++ b/drivers/gpu/drm/xe/regs/xe_pmt.h
>>@@ -18,9 +18,6 @@
>> #define BMG_TELEMETRY_BASE_OFFSET 0xE0000
>> #define BMG_TELEMETRY_OFFSET (SOC_BASE + BMG_TELEMETRY_BASE_OFFSET)
>>-#define SG_REMAP_INDEX1 XE_REG(SOC_BASE + 0x08)
>>-#define SG_REMAP_BITS REG_GENMASK(31, 24)
>>-
>> #define BMG_MODS_RESIDENCY_OFFSET (0x4D0)
>> #define BMG_G2_RESIDENCY_OFFSET (0x530)
>> #define BMG_G6_RESIDENCY_OFFSET (0x538)
>>diff --git a/drivers/gpu/drm/xe/regs/xe_soc_remapper_regs.h b/drivers/gpu/drm/xe/regs/xe_soc_remapper_regs.h
>>new file mode 100644
>>index 000000000000..9edf234227a9
>>--- /dev/null
>>+++ b/drivers/gpu/drm/xe/regs/xe_soc_remapper_regs.h
>>@@ -0,0 +1,13 @@
>>+/* SPDX-License-Identifier: MIT */
>>+/*
>>+ * Copyright © 2025 Intel Corporation
>>+ */
>>+#ifndef _XE_SOC_REMAPPER_REGS_H_
>>+#define _XE_SOC_REMAPPER_REGS_H_
>>+
>>+#include "xe_regs.h"
>>+
>>+#define SG_REMAP_INDEX1 XE_REG(SOC_BASE + 0x08)
>>+#define SG_REMAP_TELEM_MASK REG_GENMASK(31, 24)
>>+
>>+#endif
>>diff --git a/drivers/gpu/drm/xe/xe_soc_remapper.c b/drivers/gpu/drm/xe/xe_soc_remapper.c
>>index f5a02abd6ab1..85d37a86117a 100644
>>--- a/drivers/gpu/drm/xe/xe_soc_remapper.c
>>+++ b/drivers/gpu/drm/xe/xe_soc_remapper.c
>>@@ -5,8 +5,26 @@
>> #include <linux/spinlock.h>
>>+#include "regs/xe_soc_remapper_regs.h"
>>+#include "xe_mmio.h"
>> #include "xe_soc_remapper.h"
>>+static void xe_soc_remapper_set_region(struct xe_device *xe, struct xe_reg reg,
>>+ u32 mask, u32 val)
>>+{
>>+ unsigned long flags;
>>+
>>+ spin_lock_irqsave(&xe->soc_remapper.lock, flags);
>>+ xe_mmio_rmw32(xe_root_tile_mmio(xe), reg, mask, val);
>>+ spin_unlock_irqrestore(&xe->soc_remapper.lock, flags);
>>+}
>>+
>>+void xe_soc_remapper_set_telem_region(struct xe_device *xe, u32 index)
>>+{
>>+
>I think need to check index is valid or not.
Checking valid index at this level in the call chain would be
inefficient. Note that we would need to add code to check valid indices
for each IP. If a new platform has other IPs added, then the checks will
increase. Also, other IPs may use a different INDEX register for config,
so that would increase the function footprint for all callers.
I think it's best left to the IP-specific caller to do the checks for
valid indices for that IP. If the usage of this code grows, we can
consider refactoring in future.
>>xe_soc_remapper_set_region(xe, SG_REMAP_INDEX1, SG_REMAP_TELEM_MASK,
>>+ REG_FIELD_PREP(SG_REMAP_TELEM_MASK, index));
>>+}
>
>In next patch we have created wrapper for SC. Instead of introducing
>separate wrappers for each SoC remapper, could we maintain a single
>function, such as:
>
>int xe_soc_remapper_set_region(struct xe_device *xe, enum
>soc_remapper_id id, u32 index)
>{
> switch (id) {
> case TELEM:
> if (xe->info.has_soc_remapper_telem)
> return -ENOTSUPP;
> // Validate index
> reg = SG_REMAP_INDEX1;
> // Calculate mask, val
> break;
>
> case SC:
> if (xe->info.has_soc_remapper_sc)
> return -ENOTSUPP;
> // Validate index
> reg = SG_REMAP_INDEX1;
> // Calculate mask, val
> break;
>
> default:
> return -EINVAL;
> }
>
> spin_lock_irqsave(&xe->soc_remapper.lock, flags);
> xe_mmio_rmw32(xe_root_tile_mmio(xe), reg, mask, val);
> spin_unlock_irqrestore(&xe->soc_remapper.lock, flags);
> return 0;
>}
Same logic as above. We should avoid conditional checks at the lowest
layers and rather have those checks at the topmost layers of callers.
Thanks,
Umesh
>
>Thanks,
>Badal
>
>>+
>> int xe_soc_remapper_init(struct xe_device *xe)
>> {
>> spin_lock_init(&xe->soc_remapper.lock);
>>diff --git a/drivers/gpu/drm/xe/xe_soc_remapper.h b/drivers/gpu/drm/xe/xe_soc_remapper.h
>>index 3cfd44f1fd74..75431b94e66a 100644
>>--- a/drivers/gpu/drm/xe/xe_soc_remapper.h
>>+++ b/drivers/gpu/drm/xe/xe_soc_remapper.h
>>@@ -11,5 +11,6 @@
>> #include "xe_device_types.h"
>> int xe_soc_remapper_init(struct xe_device *xe);
>>+void xe_soc_remapper_set_telem_region(struct xe_device *xe, u32 index);
>> #endif
>>diff --git a/drivers/gpu/drm/xe/xe_vsec.c b/drivers/gpu/drm/xe/xe_vsec.c
>>index 8f23a27871b6..3e217fb75394 100644
>>--- a/drivers/gpu/drm/xe/xe_vsec.c
>>+++ b/drivers/gpu/drm/xe/xe_vsec.c
>>@@ -16,6 +16,7 @@
>> #include "xe_mmio.h"
>> #include "xe_platform_types.h"
>> #include "xe_pm.h"
>>+#include "xe_soc_remapper.h"
>> #include "xe_vsec.h"
>> #include "regs/xe_pmt.h"
>>@@ -163,8 +164,7 @@ int xe_pmt_telem_read(struct pci_dev *pdev, u32 guid, u64 *data, loff_t user_off
>> return -ENODATA;
>> /* set SoC re-mapper index register based on GUID memory region */
>>- xe_mmio_rmw32(xe_root_tile_mmio(xe), SG_REMAP_INDEX1, SG_REMAP_BITS,
>>- REG_FIELD_PREP(SG_REMAP_BITS, mem_region));
>>+ xe_soc_remapper_set_telem_region(xe, mem_region);
>> memcpy_fromio(data, telem_addr, count);
>> xe_pm_runtime_put(xe);
next prev parent reply other threads:[~2025-12-02 20:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 20:53 [PATCH v2 0/4] Add SoC remapper support for system controller Umesh Nerlige Ramappa
2025-11-17 20:53 ` [PATCH v2 1/4] drm/xe/soc_remapper: Initialize SoC remapper during Xe probe Umesh Nerlige Ramappa
2025-11-25 19:14 ` Nilawar, Badal
2025-11-17 20:53 ` [PATCH v2 2/4] drm/xe/soc_remapper: Use SoC remapper herlper from VSEC code Umesh Nerlige Ramappa
2025-12-02 5:03 ` Nilawar, Badal
2025-12-02 20:35 ` Umesh Nerlige Ramappa [this message]
2025-11-17 20:53 ` [PATCH v2 3/4] drm/xe/soc_remapper: Add system controller config for SoC remapper Umesh Nerlige Ramappa
2025-11-17 20:53 ` [PATCH v2 4/4] drm/xe/remapper: Reprogram remapper index on PM resume events Umesh Nerlige Ramappa
2025-11-26 14:46 ` Nilawar, Badal
2025-12-02 21:00 ` Umesh Nerlige Ramappa
2025-11-17 20:59 ` ✗ CI.checkpatch: warning for Add SoC remapper support for system controller (rev2) Patchwork
2025-11-17 21:00 ` ✓ CI.KUnit: success " Patchwork
2025-11-17 21:58 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-17 23:38 ` ✓ Xe.CI.Full: " 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=aS9NeKJ6Xqp6scG2@soc-5CG1426VCC.clients.intel.com \
--to=umesh.nerlige.ramappa@intel.com \
--cc=ashutosh.dixit@intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox