[Intel-gfx] ✓ Fi.CI.BAT: success for GuC CTBs changes + a few misc patches
== Series Details ==
Series: GuC CTBs changes + a few misc patches
URL : https://patchwork.freedesktop.org/series/90923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10161 -> Patchwork_20268
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/index.html
Known issues
Here are the changes found in Patchwork_20268 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-cml-s: [PASS][1] -> [DMESG-FAIL][2] ([i915#2291] /
[i915#541])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-cml-s/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-cml-s/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#2782])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-tgl-u2: [PASS][5] -> [FAIL][6] ([i915#2416])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@core_auth@basic-auth:
- fi-kbl-soraka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-kbl-soraka/igt@core_a...@basic-auth.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-kbl-soraka/igt@core_a...@basic-auth.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][9] ([i915#2782] / [i915#2940] /
[i915#3462]) -> [DMESG-FAIL][10] ([i915#3462])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-icl-u2: [DMESG-FAIL][11] ([i915#3462]) -> [INCOMPLETE][12]
([i915#2782] / [i915#3462])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-icl-u2/igt@i915_selftest@l...@execlists.html
- fi-tgl-u2: [INCOMPLETE][13] ([i915#3462]) -> [DMESG-FAIL][14]
([i915#3462])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-icl-u2: [FAIL][15] ([i915#2426] / [i915#2782] / [i915#3363])
-> [FAIL][16] ([i915#2782] / [i915#3363])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-icl-u2/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-icl-u2/igt@run...@aborted.html
- fi-cml-u2: [FAIL][17] ([i915#3363] / [i915#3462]) -> [FAIL][18]
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-cml-u2/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-cml-u2/igt@run...@aborted.html
- fi-bxt-dsi: [FAIL][19] ([i915#3363]) -> [FAIL][20] ([i915#2426] /
[i915#3363])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-bxt-dsi/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-bxt-dsi/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][21] ([i915#2426] / [i915#3363]) -> [FAIL][22]
([i915#3363])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-cfl-guc/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-cfl-guc/igt@run...@aborted.html
- fi-skl-6700k2: [FAIL][23] ([i915#1436] / [i915#3363]) -> [FAIL][24]
([i915#1436] / [i915#2426] / [i915#3363])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-skl-6700k2/igt@run...@aborted.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20268/fi-skl-6700k2/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2291]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GuC CTBs changes + a few misc patches
== Series Details == Series: GuC CTBs changes + a few misc patches URL : https://patchwork.freedesktop.org/series/90923/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GuC CTBs changes + a few misc patches
== Series Details == Series: GuC CTBs changes + a few misc patches URL : https://patchwork.freedesktop.org/series/90923/ State : warning == Summary == $ dim checkpatch origin/drm-tip b995ee93341d drm/i915/guc: skip disabling CTBs before sanitizing the GuC 615b2e145353 drm/i915/guc: use probe_error log for CT enablement failure 64633e8a2c5c drm/i915/guc: enable only the user interrupt when using GuC submission ff1239608127 drm/i915/guc: Remove sample_forcewake h2g action cd4bc4bbb7db drm/i915/guc: Keep strict GuC ABI definitions -:18: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #18: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 476 lines checked 92abfd675d17 drm/i915/guc: Drop guc->interrupts.enabled b4d1bfbad95a drm/i915/guc: Stop using fence/status from CTB descriptor 3fdb982139de drm/i915: Promote ptrdiff() to i915_utils.h b8b55afb041b drm/i915/guc: Only rely on own CTB size 5fd584084741 drm/i915/guc: Don't repeat CTB layout calculations 1ef8d35c354a drm/i915/guc: Replace CTB array with explicit members 29418a3ae1ca drm/i915/guc: Update sizes of CTB buffers 9397ecf1bd5d drm/i915/guc: Relax CTB response timeout 2807c0d82a1f drm/i915/guc: Start protecting access to CTB descriptors -:87: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #87: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h:36: + spinlock_t lock; total: 0 errors, 0 warnings, 1 checks, 61 lines checked ce3277877e1b drm/i915/guc: Ensure H2G buffer updates visible before tail update bd544d24227f drm/i915/guc: Stop using mutex while sending CTB messages 348ce9572410 drm/i915/guc: Don't receive all G2H messages in irq handler 294ee7f74a50 drm/i915/guc: Always copy CT message to new allocation da53d759233e drm/i915/guc: Early initialization of GuC send registers 0a6789a09f83 drm/i915/guc: Use guc_class instead of engine_class in fw interface ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/20] drm/i915/guc: Update sizes of CTB buffers
From: Michal Wajdeczko
Future GuC will require CTB buffers sizes to be multiple of 4K.
Make these changes now as this shouldn't impact us too much.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 60 ---
1 file changed, 32 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 6864819b75a9..916c2b80c841 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -38,6 +38,32 @@ static inline struct drm_device *ct_to_drm(struct
intel_guc_ct *ct)
#define CT_PROBE_ERROR(_ct, _fmt, ...) \
i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+/**
+ * DOC: CTB Blob
+ *
+ * We allocate single blob to hold both CTB descriptors and buffers:
+ *
+ * ++---+--+
+ * | offset | contents | size |
+ * ++===+==+
+ * | 0x | H2G `CTB Descriptor`_ (send) | |
+ * ++---+ 4K |
+ * | 0x0800 | G2H `CTB Descriptor`_ (recv) | |
+ * ++---+--+
+ * | 0x1000 | H2G `CT Buffer`_ (send) | n*4K |
+ * || | |
+ * ++---+--+
+ * | 0x1000 | G2H `CT Buffer`_ (recv) | m*4K |
+ * | + n*4K | | |
+ * ++---+--+
+ *
+ * Size of each `CT Buffer`_ must be multiple of 4K.
+ * As we don't expect too many messages, for now use minimum sizes.
+ */
+#define CTB_DESC_SIZE ALIGN(sizeof(struct guc_ct_buffer_desc), SZ_2K)
+#define CTB_H2G_BUFFER_SIZE(SZ_4K)
+#define CTB_G2H_BUFFER_SIZE(SZ_4K)
+
struct ct_request {
struct list_head link;
u32 fence;
@@ -175,29 +201,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
GEM_BUG_ON(ct->vma);
- /* We allocate 1 page to hold both descriptors and both buffers.
-* ___.
-* |desc (SEND)| :
-* |___| PAGE/4
-* :___:
-* |desc (RECV)| :
-* |___| PAGE/4
-* :___:
-* |cmds (SEND)|
-* | PAGE/4
-* |___|
-* |cmds (RECV)|
-* | PAGE/4
-* |___|
-*
-* Each message can use a maximum of 32 dwords and we don't expect to
-* have more than 1 in flight at any time, so we have enough space.
-* Some logic further ahead will rely on the fact that there is only 1
-* page and that it is always mapped, so if the size is changed the
-* other code will need updating as well.
-*/
-
- blob_size = PAGE_SIZE;
+ blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE +
CTB_G2H_BUFFER_SIZE;
err = intel_guc_allocate_and_map_vma(guc, blob_size, >vma, );
if (unlikely(err)) {
CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
@@ -209,17 +213,17 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
/* store pointers to desc and cmds for send ctb */
desc = blob;
- cmds = blob + PAGE_SIZE / 2;
- cmds_size = PAGE_SIZE / 4;
+ cmds = blob + 2 * CTB_DESC_SIZE;
+ cmds_size = CTB_H2G_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "send",
ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
guc_ct_buffer_init(>ctbs.send, desc, cmds, cmds_size);
/* store pointers to desc and cmds for recv ctb */
- desc = blob + PAGE_SIZE / 4;
- cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
- cmds_size = PAGE_SIZE / 4;
+ desc = blob + CTB_DESC_SIZE;
+ cmds = blob + 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE;
+ cmds_size = CTB_G2H_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "recv",
ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/20] drm/i915/guc: Don't receive all G2H messages in irq handler
From: Michal Wajdeczko
In irq handler try to receive just single G2H message, let other
messages to be received from tasklet.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 67 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +
2 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 372735c7f5e7..4fac9e4bced4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -81,6 +81,7 @@ enum { CTB_SEND = 0, CTB_RECV = 1 };
enum { CTB_OWNER_HOST = 0 };
+static void ct_receive_tasklet_func(struct tasklet_struct *t);
static void ct_incoming_request_worker_func(struct work_struct *w);
/**
@@ -95,6 +96,7 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
INIT_LIST_HEAD(>requests.pending);
INIT_LIST_HEAD(>requests.incoming);
INIT_WORK(>requests.worker, ct_incoming_request_worker_func);
+ tasklet_setup(>receive_tasklet, ct_receive_tasklet_func);
}
static inline const char *guc_ct_buffer_type_to_str(u32 type)
@@ -244,6 +246,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
{
GEM_BUG_ON(ct->enabled);
+ tasklet_kill(>receive_tasklet);
i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
memset(ct, 0, sizeof(*ct));
}
@@ -654,7 +657,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
CT_DEBUG(ct, "received %*ph\n", 4 * len, data);
desc->head = head * 4;
- return 0;
+ return available - len;
corrupted:
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
@@ -690,10 +693,10 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
u32 status;
u32 datalen;
struct ct_request *req;
+ unsigned long flags;
bool found = false;
GEM_BUG_ON(!ct_header_is_response(header));
- GEM_BUG_ON(!in_irq());
/* Response payload shall at least include fence and status */
if (unlikely(len < 2)) {
@@ -713,7 +716,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
- spin_lock(>requests.lock);
+ spin_lock_irqsave(>requests.lock, flags);
list_for_each_entry(req, >requests.pending, link) {
if (unlikely(fence != req->fence)) {
CT_DEBUG(ct, "request %u awaits response\n",
@@ -732,7 +735,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
found = true;
break;
}
- spin_unlock(>requests.lock);
+ spin_unlock_irqrestore(>requests.lock, flags);
if (!found)
CT_ERROR(ct, "Unsolicited response %*ph\n", msgsize, msg);
@@ -846,31 +849,55 @@ static int ct_handle_request(struct intel_guc_ct *ct,
const u32 *msg)
return 0;
}
+static int ct_receive(struct intel_guc_ct *ct)
+{
+ u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(>ctbs.recv.lock, flags);
+ ret = ct_read(ct, msg);
+ spin_unlock_irqrestore(>ctbs.recv.lock, flags);
+ if (ret < 0)
+ return ret;
+
+ if (ct_header_is_response(msg[0]))
+ ct_handle_response(ct, msg);
+ else
+ ct_handle_request(ct, msg);
+
+ return ret;
+}
+
+static void ct_try_receive_message(struct intel_guc_ct *ct)
+{
+ int ret;
+
+ if (GEM_WARN_ON(!ct->enabled))
+ return;
+
+ ret = ct_receive(ct);
+ if (ret > 0)
+ tasklet_hi_schedule(>receive_tasklet);
+}
+
+static void ct_receive_tasklet_func(struct tasklet_struct *t)
+{
+ struct intel_guc_ct *ct = from_tasklet(ct, t, receive_tasklet);
+
+ ct_try_receive_message(ct);
+}
+
/*
* When we're communicating with the GuC over CT, GuC uses events
* to notify us about new messages being posted on the RECV buffer.
*/
void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
{
- u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
- unsigned long flags;
- int err = 0;
-
if (unlikely(!ct->enabled)) {
WARN(1, "Unexpected GuC event received while CT disabled!\n");
return;
}
- do {
- spin_lock_irqsave(>ctbs.recv.lock, flags);
- err = ct_read(ct, msg);
- spin_unlock_irqrestore(>ctbs.recv.lock, flags);
- if (err)
- break;
-
- if (ct_header_is_response(msg[0]))
- err = ct_handle_response(ct, msg);
- else
- err = ct_handle_request(ct, msg);
- } while
[Intel-gfx] [PATCH 16/20] drm/i915/guc: Stop using mutex while sending CTB messages
From: Michal Wajdeczko
We are no longer using descriptor to hold G2H replies and we are
protecting access to the descriptor and command buffer by the
separate spinlock, so we can stop using mutex.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 31f83956bfc3..372735c7f5e7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -562,7 +562,6 @@ static int ct_send(struct intel_guc_ct *ct,
int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
u32 *response_buf, u32 response_buf_size)
{
- struct intel_guc *guc = ct_to_guc(ct);
u32 status = ~0; /* undefined */
int ret;
@@ -571,8 +570,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32
*action, u32 len,
return -ENODEV;
}
- mutex_lock(>send_mutex);
-
ret = ct_send(ct, action, len, response_buf, response_buf_size,
);
if (unlikely(ret < 0)) {
CT_ERROR(ct, "Sending action %#x failed (err=%d status=%#X)\n",
@@ -582,7 +579,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32
*action, u32 len,
action[0], ret, ret);
}
- mutex_unlock(>send_mutex);
return ret;
}
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/20] drm/i915/guc: Early initialization of GuC send registers
From: Michal Wajdeczko
Base offset and count of the GuC scratch registers, used for
sending MMIO messages to GuC, can be initialized earlier with
other GuC members that also depends on platform.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 18da9ed15728..fcfa4fd93841 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -60,15 +60,8 @@ void intel_guc_init_send_regs(struct intel_guc *guc)
enum forcewake_domains fw_domains = 0;
unsigned int i;
- if (INTEL_GEN(gt->i915) >= 11) {
- guc->send_regs.base =
- i915_mmio_reg_offset(GEN11_SOFT_SCRATCH(0));
- guc->send_regs.count = GEN11_SOFT_SCRATCH_COUNT;
- } else {
- guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
- guc->send_regs.count = GUC_MAX_MMIO_MSG_LEN;
- BUILD_BUG_ON(GUC_MAX_MMIO_MSG_LEN > SOFT_SCRATCH_COUNT);
- }
+ GEM_BUG_ON(!guc->send_regs.base);
+ GEM_BUG_ON(!guc->send_regs.count);
for (i = 0; i < guc->send_regs.count; i++) {
fw_domains |= intel_uncore_forcewake_for_reg(gt->uncore,
@@ -172,11 +165,18 @@ void intel_guc_init_early(struct intel_guc *guc)
guc->interrupts.reset = gen11_reset_guc_interrupts;
guc->interrupts.enable = gen11_enable_guc_interrupts;
guc->interrupts.disable = gen11_disable_guc_interrupts;
+ guc->send_regs.base =
+ i915_mmio_reg_offset(GEN11_SOFT_SCRATCH(0));
+ guc->send_regs.count = GEN11_SOFT_SCRATCH_COUNT;
+
} else {
guc->notify_reg = GUC_SEND_INTERRUPT;
guc->interrupts.reset = gen9_reset_guc_interrupts;
guc->interrupts.enable = gen9_enable_guc_interrupts;
guc->interrupts.disable = gen9_disable_guc_interrupts;
+ guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
+ guc->send_regs.count = GUC_MAX_MMIO_MSG_LEN;
+ BUILD_BUG_ON(GUC_MAX_MMIO_MSG_LEN > SOFT_SCRATCH_COUNT);
}
}
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/20] drm/i915: Promote ptrdiff() to i915_utils.h
From: Michal Wajdeczko
Generic helpers should be placed in i915_utils.h.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_utils.h | 5 +
drivers/gpu/drm/i915/i915_vma.h | 5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index f02f52ab5070..5259edacde38 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -201,6 +201,11 @@ __check_struct_size(size_t base, size_t arr, size_t count,
size_t *size)
__T;\
})
+static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
+{
+ return a - b;
+}
+
/*
* container_of_user: Extract the superclass from a pointer to a member.
*
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index dc6926d89626..eca452a9851f 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -151,11 +151,6 @@ static inline void i915_vma_put(struct i915_vma *vma)
i915_gem_object_put(vma->obj);
}
-static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
-{
- return a - b;
-}
-
static inline long
i915_vma_compare(struct i915_vma *vma,
struct i915_address_space *vm,
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/20] drm/i915/guc: Start protecting access to CTB descriptors
From: Michal Wajdeczko
We want to stop using guc.send_mutex while sending CTB messages
so we have to start protecting access to CTB send descriptor.
For completeness protect also CTB receive descriptor.
Add spinlock to struct intel_guc_ct_buffer and start using it.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 --
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index cf1fb09ef766..80976fe40fbf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -89,6 +89,8 @@ static void ct_incoming_request_worker_func(struct
work_struct *w);
*/
void intel_guc_ct_init_early(struct intel_guc_ct *ct)
{
+ spin_lock_init(>ctbs.send.lock);
+ spin_lock_init(>ctbs.recv.lock);
spin_lock_init(>requests.lock);
INIT_LIST_HEAD(>requests.pending);
INIT_LIST_HEAD(>requests.incoming);
@@ -476,17 +478,22 @@ static int ct_send(struct intel_guc_ct *ct,
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
GEM_BUG_ON(!response_buf && response_buf_size);
+ spin_lock_irqsave(>ctbs.send.lock, flags);
+
fence = ct_get_next_fence(ct);
request.fence = fence;
request.status = 0;
request.response_len = response_buf_size;
request.response_buf = response_buf;
- spin_lock_irqsave(>requests.lock, flags);
+ spin_lock(>requests.lock);
list_add_tail(, >requests.pending);
- spin_unlock_irqrestore(>requests.lock, flags);
+ spin_unlock(>requests.lock);
err = ct_write(ct, action, len, fence);
+
+ spin_unlock_irqrestore(>ctbs.send.lock, flags);
+
if (unlikely(err))
goto unlink;
@@ -822,6 +829,7 @@ static int ct_handle_request(struct intel_guc_ct *ct, const
u32 *msg)
void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
{
u32 msg[GUC_CT_MSG_LEN_MASK + 1]; /* one extra dw for the header */
+ unsigned long flags;
int err = 0;
if (unlikely(!ct->enabled)) {
@@ -830,7 +838,9 @@ void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
}
do {
+ spin_lock_irqsave(>ctbs.recv.lock, flags);
err = ct_read(ct, msg);
+ spin_unlock_irqrestore(>ctbs.recv.lock, flags);
if (err)
break;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index fc9486779e87..bc52dc479a14 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -27,11 +27,13 @@ struct intel_guc;
* record (command transport buffer descriptor) and the actual buffer which
* holds the commands.
*
+ * @lock: protects access to the commands buffer and buffer descriptor
* @desc: pointer to the buffer descriptor
* @cmds: pointer to the commands buffer
* @size: size of the commands buffer
*/
struct intel_guc_ct_buffer {
+ spinlock_t lock;
struct guc_ct_buffer_desc *desc;
u32 *cmds;
u32 size;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/20] drm/i915/guc: Use guc_class instead of engine_class in fw interface
From: Daniele Ceraolo Spurio
GuC has its own defines for the engine classes. They're currently
mapping 1:1 to the defines used by the driver, but there is no guarantee
this will continue in the future. Given that we've been caught off-guard
in the past by similar divergences, we can prepare for the changes by
introducing helper functions to convert from engine class to GuC class and
back again.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 20 +---
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 26 +
3 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 3f9a811eb02b..69281b5aba51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -265,6 +265,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
const struct engine_info *info = _engines[id];
struct drm_i915_private *i915 = gt->i915;
struct intel_engine_cs *engine;
+ u8 guc_class;
BUILD_BUG_ON(MAX_ENGINE_CLASS >= BIT(GEN11_ENGINE_CLASS_WIDTH));
BUILD_BUG_ON(MAX_ENGINE_INSTANCE >= BIT(GEN11_ENGINE_INSTANCE_WIDTH));
@@ -293,9 +294,10 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->i915 = i915;
engine->gt = gt;
engine->uncore = gt->uncore;
- engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
engine->hw_id = info->hw_id;
- engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
+ guc_class = engine_class_to_guc_class(info->class);
+ engine->guc_id = MAKE_GUC_ID(guc_class, info->instance);
+ engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
engine->irq_handler = nop_irq_handler;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 17526717368c..efdce309b6f1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -6,6 +6,7 @@
#include "gt/intel_gt.h"
#include "gt/intel_lrc.h"
#include "intel_guc_ads.h"
+#include "intel_guc_fwif.h"
#include "intel_uc.h"
#include "i915_drv.h"
@@ -104,7 +105,7 @@ static void guc_mapping_table_init(struct intel_gt *gt,
GUC_MAX_INSTANCES_PER_CLASS;
for_each_engine(engine, gt, id) {
- u8 guc_class = engine->class;
+ u8 guc_class = engine_class_to_guc_class(engine->class);
system_info->mapping_table[guc_class][engine->instance] =
engine->instance;
@@ -124,7 +125,7 @@ static void __guc_ads_init(struct intel_guc *guc)
struct __guc_ads_blob *blob = guc->ads_blob;
const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
u32 base;
- u8 engine_class;
+ u8 engine_class, guc_class;
/* GuC scheduling policies */
guc_policies_init(>policies);
@@ -140,22 +141,25 @@ static void __guc_ads_init(struct intel_guc *guc)
for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
++engine_class) {
if (engine_class == OTHER_CLASS)
continue;
+
+ guc_class = engine_class_to_guc_class(engine_class);
+
/*
* TODO: Set context pointer to default state to allow
* GuC to re-init guilty contexts after internal reset.
*/
- blob->ads.golden_context_lrca[engine_class] = 0;
- blob->ads.eng_state_size[engine_class] =
+ blob->ads.golden_context_lrca[guc_class] = 0;
+ blob->ads.eng_state_size[guc_class] =
intel_engine_context_size(guc_to_gt(guc),
engine_class) -
skipped_size;
}
/* System info */
- blob->system_info.engine_enabled_masks[RENDER_CLASS] = 1;
- blob->system_info.engine_enabled_masks[COPY_ENGINE_CLASS] = 1;
- blob->system_info.engine_enabled_masks[VIDEO_DECODE_CLASS] =
VDBOX_MASK(gt);
- blob->system_info.engine_enabled_masks[VIDEO_ENHANCEMENT_CLASS] =
VEBOX_MASK(gt);
+ blob->system_info.engine_enabled_masks[GUC_RENDER_CLASS] = 1;
+ blob->system_info.engine_enabled_masks[GUC_BLITTER_CLASS] = 1;
+ blob->system_info.engine_enabled_masks[GUC_VIDEO_CLASS] =
VDBOX_MASK(gt);
+ blob->system_info.engine_enabled_masks[GUC_VIDEOENHANCE_CLASS] =
VEBOX_MASK(gt);
blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_SLICE_ENABLED] =
hweight8(gt->info.sseu.slice_mask);
diff --git
[Intel-gfx] [PATCH 13/20] drm/i915/guc: Relax CTB response timeout
From: Michal Wajdeczko
In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for processing, so we shouldn't assume any more
that GuC will always reply without 10ms.
Use bigger value from CONFIG_DRM_I915_GUC_CTB_TIMEOUT instead.
v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/Kconfig.profile | 10 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 39328567c200..0d5475b5f28a 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -38,6 +38,16 @@ config DRM_I915_USERFAULT_AUTOSUSPEND
May be 0 to disable the extra delay and solely use the device level
runtime pm autosuspend delay tunable.
+config DRM_I915_GUC_CTB_TIMEOUT
+ int "How long to wait for the GuC to make forward progress on CTBs (ms)"
+ default 1500 # milliseconds
+ range 10 6
+ help
+ Configures the default timeout waiting for GuC the to make forward
+ progress on CTBs. e.g. Waiting for a response to a requeset.
+
+ A range of 10 ms to 6 ms is allowed.
+
config DRM_I915_HEARTBEAT_INTERVAL
int "Interval between heartbeat pulses (ms)"
default 2500 # milliseconds
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 916c2b80c841..cf1fb09ef766 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -436,6 +436,7 @@ static int ct_write(struct intel_guc_ct *ct,
*/
static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
{
+ long timeout;
int err;
/*
@@ -443,10 +444,12 @@ static int wait_for_ct_request_update(struct ct_request
*req, u32 *status)
* up to that length of time, then switch to a slower sleep-wait loop.
* No GuC command should ever take longer than 10ms.
*/
+ timeout = CONFIG_DRM_I915_GUC_CTB_TIMEOUT;
+
#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
err = wait_for_us(done, 10);
if (err)
- err = wait_for(done, 10);
+ err = wait_for(done, timeout);
#undef done
if (unlikely(err))
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/20] drm/i915/guc: Replace CTB array with explicit members
From: Michal Wajdeczko
Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 46 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 7 +++-
2 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 34c582105860..6864819b75a9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -168,10 +168,10 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
struct intel_guc *guc = ct_to_guc(ct);
struct guc_ct_buffer_desc *desc;
u32 blob_size;
+ u32 cmds_size;
void *blob;
u32 *cmds;
int err;
- int i;
GEM_BUG_ON(ct->vma);
@@ -207,15 +207,23 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma),
blob_size);
- /* store pointers to desc and cmds */
- for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
- GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+ /* store pointers to desc and cmds for send ctb */
+ desc = blob;
+ cmds = blob + PAGE_SIZE / 2;
+ cmds_size = PAGE_SIZE / 4;
+ CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "send",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
- desc = blob + PAGE_SIZE / 4 * i;
- cmds = blob + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+ guc_ct_buffer_init(>ctbs.send, desc, cmds, cmds_size);
- guc_ct_buffer_init(>ctbs[i], desc, cmds, PAGE_SIZE / 4);
- }
+ /* store pointers to desc and cmds for recv ctb */
+ desc = blob + PAGE_SIZE / 4;
+ cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
+ cmds_size = PAGE_SIZE / 4;
+ CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "recv",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
+
+ guc_ct_buffer_init(>ctbs.recv, desc, cmds, cmds_size);
return 0;
}
@@ -246,7 +254,6 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
u32 base, cmds;
void *blob;
int err;
- int i;
GEM_BUG_ON(ct->enabled);
@@ -257,28 +264,25 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
/* blob should start with send descriptor */
blob = __px_vaddr(ct->vma->obj);
- GEM_BUG_ON(blob != ct->ctbs[CTB_SEND].desc);
+ GEM_BUG_ON(blob != ct->ctbs.send.desc);
/* (re)initialize descriptors */
- for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
- GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+ cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
+ guc_ct_buffer_reset(>ctbs.send, cmds);
- cmds = base + ptrdiff(ct->ctbs[i].cmds, blob);
- CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
-
- guc_ct_buffer_reset(>ctbs[i], cmds);
- }
+ cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
+ guc_ct_buffer_reset(>ctbs.recv, cmds);
/*
* Register both CT buffers starting with RECV buffer.
* Descriptors are in first half of the blob.
*/
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_RECV].desc,
blob),
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
goto err_out;
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_SEND].desc,
blob),
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
INTEL_GUC_CT_BUFFER_TYPE_SEND);
if (unlikely(err))
goto err_deregister;
@@ -341,7 +345,7 @@ static int ct_write(struct intel_guc_ct *ct,
u32 len /* in dwords */,
u32 fence)
{
- struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
+ struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
@@ -557,7 +561,7 @@ static inline bool ct_header_is_response(u32 header)
static int ct_read(struct intel_guc_ct *ct, u32 *data)
{
- struct intel_guc_ct_buffer *ctb = >ctbs[CTB_RECV];
+ struct intel_guc_ct_buffer *ctb = >ctbs.recv;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 4009e2dd0de4..fc9486779e87 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
[Intel-gfx] [PATCH 04/20] drm/i915/guc: Remove sample_forcewake h2g action
From: Rodrigo Vivi
This action is no-op in the GuC side for a few versions already
and it is getting entirely removed soon, in an upcoming version.
Time to remove before we face communication issues.
Cc: Vinay Belgaumkar
Signed-off-by: Rodrigo Vivi
Signed-off-by: Matthew Brost
Acked-by: Michal Wajdeczko
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 16
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 -
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 4
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4
4 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index adae04c47aab..ab2c8fe8cdfa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -469,22 +469,6 @@ int intel_guc_to_host_process_recv_msg(struct intel_guc
*guc,
return 0;
}
-int intel_guc_sample_forcewake(struct intel_guc *guc)
-{
- struct drm_i915_private *dev_priv = guc_to_gt(guc)->i915;
- u32 action[2];
-
- action[0] = INTEL_GUC_ACTION_SAMPLE_FORCEWAKE;
- /* WaRsDisableCoarsePowerGating:skl,cnl */
- if (!HAS_RC6(dev_priv) || NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
- action[1] = 0;
- else
- /* bit 0 and 1 are for Render and Media domain separately */
- action[1] = GUC_FORCEWAKE_RENDER | GUC_FORCEWAKE_MEDIA;
-
- return intel_guc_send(guc, action, ARRAY_SIZE(action));
-}
-
/**
* intel_guc_auth_huc() - Send action to GuC to authenticate HuC ucode
* @guc: intel_guc structure
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index bc2ba7d0626c..c20f3839de12 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -128,7 +128,6 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len,
u32 *response_buf, u32 response_buf_size);
int intel_guc_to_host_process_recv_msg(struct intel_guc *guc,
const u32 *payload, u32 len);
-int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
int intel_guc_resume(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 79c560d9c0b6..0f9afcde1d0b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -302,9 +302,6 @@ struct guc_ct_buffer_desc {
#define GUC_CT_MSG_ACTION_SHIFT16
#define GUC_CT_MSG_ACTION_MASK 0x
-#define GUC_FORCEWAKE_RENDER (1 << 0)
-#define GUC_FORCEWAKE_MEDIA(1 << 1)
-
#define GUC_POWER_UNSPECIFIED 0
#define GUC_POWER_D0 1
#define GUC_POWER_D1 2
@@ -558,7 +555,6 @@ enum intel_guc_action {
INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
- INTEL_GUC_ACTION_SAMPLE_FORCEWAKE = 0x3005,
INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 892c1315ce49..ab0789d66e06 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -502,10 +502,6 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_huc_auth(huc);
- ret = intel_guc_sample_forcewake(guc);
- if (ret)
- goto err_log_capture;
-
if (intel_uc_uses_guc_submission(uc))
intel_guc_submission_enable(guc);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/20] drm/i915/guc: Only rely on own CTB size
From: Michal Wajdeczko
In upcoming GuC firmware, CTB size will be removed from the CTB
descriptor so we must keep it locally for any calculations.
While around, improve some debug messages and helpers.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 55 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +
2 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index d08fa9879921..079e1a160894 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -90,6 +90,24 @@ static void guc_ct_buffer_desc_init(struct
guc_ct_buffer_desc *desc,
desc->owner = CTB_OWNER_HOST;
}
+static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
+{
+ guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
+}
+
+static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
+ struct guc_ct_buffer_desc *desc,
+ u32 *cmds, u32 size)
+{
+ GEM_BUG_ON(size % 4);
+
+ ctb->desc = desc;
+ ctb->cmds = cmds;
+ ctb->size = size;
+
+ guc_ct_buffer_reset(ctb, 0);
+}
+
static int guc_action_register_ct_buffer(struct intel_guc *guc,
u32 desc_addr,
u32 type)
@@ -148,7 +166,10 @@ static int ct_deregister_buffer(struct intel_guc_ct *ct,
u32 type)
int intel_guc_ct_init(struct intel_guc_ct *ct)
{
struct intel_guc *guc = ct_to_guc(ct);
+ struct guc_ct_buffer_desc *desc;
+ u32 blob_size;
void *blob;
+ u32 *cmds;
int err;
int i;
@@ -176,19 +197,24 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
* other code will need updating as well.
*/
- err = intel_guc_allocate_and_map_vma(guc, PAGE_SIZE, >vma, );
+ blob_size = PAGE_SIZE;
+ err = intel_guc_allocate_and_map_vma(guc, blob_size, >vma, );
if (unlikely(err)) {
- CT_ERROR(ct, "Failed to allocate CT channel (err=%d)\n", err);
+ CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
+ blob_size, ERR_PTR(err));
return err;
}
- CT_DEBUG(ct, "vma base=%#x\n", intel_guc_ggtt_offset(guc, ct->vma));
+ CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma),
blob_size);
/* store pointers to desc and cmds */
for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
- ct->ctbs[i].desc = blob + PAGE_SIZE/4 * i;
- ct->ctbs[i].cmds = blob + PAGE_SIZE/4 * i + PAGE_SIZE/2;
+
+ desc = blob + PAGE_SIZE / 4 * i;
+ cmds = blob + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+
+ guc_ct_buffer_init(>ctbs[i], desc, cmds, PAGE_SIZE / 4);
}
return 0;
@@ -217,7 +243,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
int intel_guc_ct_enable(struct intel_guc_ct *ct)
{
struct intel_guc *guc = ct_to_guc(ct);
- u32 base, cmds, size;
+ u32 base, cmds;
int err;
int i;
@@ -232,10 +258,11 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
*/
for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+
cmds = base + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
- size = PAGE_SIZE / 4;
- CT_DEBUG(ct, "%d: addr=%#x size=%u\n", i, cmds, size);
- guc_ct_buffer_desc_init(ct->ctbs[i].desc, cmds, size);
+ CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
+
+ guc_ct_buffer_reset(>ctbs[i], cmds);
}
/*
@@ -259,7 +286,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
err_deregister:
ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
err_out:
- CT_PROBE_ERROR(ct, "Failed to open channel (err=%d)\n", err);
+ CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
return err;
}
@@ -314,7 +341,7 @@ static int ct_write(struct intel_guc_ct *ct,
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
- u32 size = desc->size;
+ u32 size = ctb->size;
u32 used;
u32 header;
u32 *cmds = ctb->cmds;
@@ -323,7 +350,7 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(desc->is_in_error))
return -EPIPE;
- if (unlikely(!IS_ALIGNED(head | tail | size, 4) ||
+ if (unlikely(!IS_ALIGNED(head | tail, 4) ||
(tail | head) >= size))
goto corrupted;
@@ -530,7 +557,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
[Intel-gfx] [PATCH 03/20] drm/i915/guc: enable only the user interrupt when using GuC submission
From: Daniele Ceraolo Spurio
In GuC submission mode the CS is owned by the GuC FW, so all CS status
interrupts are handled by it. We only need the user interrupt as that
signals request completion.
Since we're now starting the engines directly in GuC submission mode
when selected, we can stop switching back and forth between the
execlists and the GuC programming and select directly the correct
interrupt mask.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 18 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 ---
2 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index d29126c458ba..f88c10366e58 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -194,14 +194,18 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
void gen11_gt_irq_postinstall(struct intel_gt *gt)
{
- const u32 irqs =
- GT_CS_MASTER_ERROR_INTERRUPT |
- GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT |
- GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
- const u32 dmask = irqs << 16 | irqs;
- const u32 smask = irqs << 16;
+ u32 irqs = GT_RENDER_USER_INTERRUPT;
+ u32 dmask;
+ u32 smask;
+
+ if (!intel_uc_wants_guc_submission(>uc))
+ irqs |= GT_CS_MASTER_ERROR_INTERRUPT |
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
+
+ dmask = irqs << 16 | irqs;
+ smask = irqs << 16;
BUILD_BUG_ON(irqs & 0x);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 335719f17490..38cda5d599a6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -432,32 +432,6 @@ void intel_guc_submission_fini(struct intel_guc *guc)
}
}
-static void guc_interrupts_capture(struct intel_gt *gt)
-{
- struct intel_uncore *uncore = gt->uncore;
- u32 irqs = GT_CONTEXT_SWITCH_INTERRUPT;
- u32 dmask = irqs << 16 | irqs;
-
- GEM_BUG_ON(INTEL_GEN(gt->i915) < 11);
-
- /* Don't handle the ctx switch interrupt in GuC submission mode */
- intel_uncore_rmw(uncore, GEN11_RENDER_COPY_INTR_ENABLE, dmask, 0);
- intel_uncore_rmw(uncore, GEN11_VCS_VECS_INTR_ENABLE, dmask, 0);
-}
-
-static void guc_interrupts_release(struct intel_gt *gt)
-{
- struct intel_uncore *uncore = gt->uncore;
- u32 irqs = GT_CONTEXT_SWITCH_INTERRUPT;
- u32 dmask = irqs << 16 | irqs;
-
- GEM_BUG_ON(INTEL_GEN(gt->i915) < 11);
-
- /* Handle ctx switch interrupts again */
- intel_uncore_rmw(uncore, GEN11_RENDER_COPY_INTR_ENABLE, 0, dmask);
- intel_uncore_rmw(uncore, GEN11_VCS_VECS_INTR_ENABLE, 0, dmask);
-}
-
static int guc_context_alloc(struct intel_context *ce)
{
return lrc_alloc(ce, ce->engine);
@@ -722,9 +696,6 @@ int intel_guc_submission_setup(struct intel_engine_cs
*engine)
void intel_guc_submission_enable(struct intel_guc *guc)
{
guc_stage_desc_init(guc);
-
- /* Take over from manual control of ELSP (execlists) */
- guc_interrupts_capture(guc_to_gt(guc));
}
void intel_guc_submission_disable(struct intel_guc *guc)
@@ -735,8 +706,6 @@ void intel_guc_submission_disable(struct intel_guc *guc)
/* Note: By the time we're here, GuC may have already been reset */
- guc_interrupts_release(gt);
-
guc_stage_desc_fini(guc);
}
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/20] drm/i915/guc: Always copy CT message to new allocation
From: Michal Wajdeczko
Since most of future CT traffic will be based on G2H requests,
instead of copying incoming CT message to static buffer and then
create new allocation for such request, always copy incoming CT
message to new allocation. Also by doing it while reading CT
header, we can safely fallback if that atomic allocation fails.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: Piotr Piórkowski
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 180 ++
1 file changed, 120 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 4fac9e4bced4..8869f9ebb4c8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -72,8 +72,9 @@ struct ct_request {
u32 *response_buf;
};
-struct ct_incoming_request {
+struct ct_incoming_msg {
struct list_head link;
+ u32 size;
u32 msg[];
};
@@ -600,7 +601,26 @@ static inline bool ct_header_is_response(u32 header)
return !!(header & GUC_CT_MSG_IS_RESPONSE);
}
-static int ct_read(struct intel_guc_ct *ct, u32 *data)
+static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
+{
+ struct ct_incoming_msg *msg;
+
+ msg = kmalloc(sizeof(*msg) + sizeof(u32) * num_dwords, GFP_ATOMIC);
+ if (msg)
+ msg->size = num_dwords;
+ return msg;
+}
+
+static void ct_free_msg(struct ct_incoming_msg *msg)
+{
+ kfree(msg);
+}
+
+/*
+ * Return: number available remaining dwords to read (0 if empty)
+ * or a negative error code on failure
+ */
+static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
{
struct intel_guc_ct_buffer *ctb = >ctbs.recv;
struct guc_ct_buffer_desc *desc = ctb->desc;
@@ -611,6 +631,7 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
s32 available;
unsigned int len;
unsigned int i;
+ u32 header;
if (unlikely(desc->is_in_error))
return -EPIPE;
@@ -626,8 +647,10 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
/* tail == head condition indicates empty */
available = tail - head;
- if (unlikely(available == 0))
- return -ENODATA;
+ if (unlikely(available == 0)) {
+ *msg = NULL;
+ return 0;
+ }
/* beware of buffer wrap case */
if (unlikely(available < 0))
@@ -635,14 +658,14 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
GEM_BUG_ON(available < 0);
- data[0] = cmds[head];
+ header = cmds[head];
head = (head + 1) % size;
/* message len with header */
- len = ct_header_get_len(data[0]) + 1;
+ len = ct_header_get_len(header) + 1;
if (unlikely(len > (u32)available)) {
CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
-4, data,
+4, ,
4 * (head + available - 1 > size ?
size - head : available - 1), [head],
4 * (head + available - 1 > size ?
@@ -650,11 +673,24 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
goto corrupted;
}
+ *msg = ct_alloc_msg(len);
+ if (!*msg) {
+ CT_ERROR(ct, "No memory for message %*ph %*ph %*ph\n",
+4, ,
+4 * (head + available - 1 > size ?
+ size - head : available - 1), [head],
+4 * (head + available - 1 > size ?
+ available - 1 - size + head : 0), [0]);
+ return available;
+ }
+
+ (*msg)->msg[0] = header;
+
for (i = 1; i < len; i++) {
- data[i] = cmds[head];
+ (*msg)->msg[i] = cmds[head];
head = (head + 1) % size;
}
- CT_DEBUG(ct, "received %*ph\n", 4 * len, data);
+ CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
desc->head = head * 4;
return available - len;
@@ -684,33 +720,33 @@ static int ct_read(struct intel_guc_ct *ct, u32 *data)
* ^---len---^
*/
-static int ct_handle_response(struct intel_guc_ct *ct, const u32 *msg)
+static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg
*response)
{
- u32 header = msg[0];
+ u32 header = response->msg[0];
u32 len = ct_header_get_len(header);
- u32 msgsize = (len + 1) * sizeof(u32); /* msg size in bytes w/header */
u32 fence;
u32 status;
u32 datalen;
struct ct_request *req;
unsigned long flags;
bool found = false;
+ int err = 0;
[Intel-gfx] [PATCH 10/20] drm/i915/guc: Don't repeat CTB layout calculations
From: Michal Wajdeczko
We can retrieve offsets to cmds buffers and descriptor from
actual pointers that we already keep locally.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 079e1a160894..34c582105860 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -244,6 +244,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
{
struct intel_guc *guc = ct_to_guc(ct);
u32 base, cmds;
+ void *blob;
int err;
int i;
@@ -251,15 +252,18 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
/* vma should be already allocated and map'ed */
GEM_BUG_ON(!ct->vma);
+ GEM_BUG_ON(!i915_gem_object_has_pinned_pages(ct->vma->obj));
base = intel_guc_ggtt_offset(guc, ct->vma);
- /* (re)initialize descriptors
-* cmds buffers are in the second half of the blob page
-*/
+ /* blob should start with send descriptor */
+ blob = __px_vaddr(ct->vma->obj);
+ GEM_BUG_ON(blob != ct->ctbs[CTB_SEND].desc);
+
+ /* (re)initialize descriptors */
for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
- cmds = base + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+ cmds = base + ptrdiff(ct->ctbs[i].cmds, blob);
CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
guc_ct_buffer_reset(>ctbs[i], cmds);
@@ -269,12 +273,12 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
* Register both CT buffers starting with RECV buffer.
* Descriptors are in first half of the blob.
*/
- err = ct_register_buffer(ct, base + PAGE_SIZE / 4 * CTB_RECV,
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_RECV].desc,
blob),
INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
goto err_out;
- err = ct_register_buffer(ct, base + PAGE_SIZE / 4 * CTB_SEND,
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_SEND].desc,
blob),
INTEL_GUC_CT_BUFFER_TYPE_SEND);
if (unlikely(err))
goto err_deregister;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/20] drm/i915/guc: Ensure H2G buffer updates visible before tail update
Ensure H2G buffer updates are visible before descriptor tail updates by
inserting a barrier between the H2G buffer update and the tail. The
barrier is simple wmb() for SMEM and is register write for LMEM. This is
needed if more than 1 H2G can be inflight at once.
If this barrier is not inserted it is possible the descriptor tail
update is scene by the GuC before H2G buffer update which results in the
GuC reading a corrupt H2G value. This can bring down the H2G channel
among other bad things.
Signed-off-by: Matthew Brost
Cc: Michal Wajdeczko
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 80976fe40fbf..31f83956bfc3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -328,6 +328,28 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
return ++ct->requests.last_fence;
}
+static void write_barrier(struct intel_guc_ct *ct)
+{
+ struct intel_guc *guc = ct_to_guc(ct);
+ struct intel_gt *gt = guc_to_gt(guc);
+
+ if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
+ GEM_BUG_ON(guc->send_regs.fw_domains);
+ /*
+* This register is used by the i915 and GuC for MMIO based
+* communication. Once we are in this code CTBs are the only
+* method the i915 uses to communicate with the GuC so it is
+* safe to write to this register (a value of 0 is NOP for MMIO
+* communication). If we ever start mixing CTBs and MMIOs a new
+* register will have to be chosen.
+*/
+ intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
+ } else {
+ /* wmb() sufficient for a barrier if in smem */
+ wmb();
+ }
+}
+
/**
* DOC: CTB Host to GuC request
*
@@ -411,6 +433,12 @@ static int ct_write(struct intel_guc_ct *ct,
}
GEM_BUG_ON(tail > size);
+ /*
+* make sure H2G buffer update and LRC tail update (if this triggering a
+* submission) are visible before updating the descriptor tail
+*/
+ write_barrier(ct);
+
/* now update desc tail (back in bytes) */
desc->tail = tail * 4;
return 0;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/20] drm/i915/guc: Stop using fence/status from CTB descriptor
From: Michal Wajdeczko
Stop using fence/status from CTB descriptor as future GuC ABI will
no longer support replies over CTB descriptor.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
.../gt/uc/abi/guc_communication_ctb_abi.h | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 72 ++-
2 files changed, 6 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index ebd8c3e0e4bb..d38935f47ecf 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -71,8 +71,8 @@ struct guc_ct_buffer_desc {
u32 head; /* offset updated by GuC*/
u32 tail; /* offset updated by owner */
u32 is_in_error;/* error indicator */
- u32 fence; /* fence updated by GuC */
- u32 status; /* status updated by GuC */
+ u32 reserved1;
+ u32 reserved2;
u32 owner; /* id of the channel owner */
u32 owner_sub_id; /* owner-defined field for extra tracking */
u32 reserved[5];
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 72b48ac9271a..d08fa9879921 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -90,13 +90,6 @@ static void guc_ct_buffer_desc_init(struct
guc_ct_buffer_desc *desc,
desc->owner = CTB_OWNER_HOST;
}
-static void guc_ct_buffer_desc_reset(struct guc_ct_buffer_desc *desc)
-{
- desc->head = 0;
- desc->tail = 0;
- desc->is_in_error = 0;
-}
-
static int guc_action_register_ct_buffer(struct intel_guc *guc,
u32 desc_addr,
u32 type)
@@ -315,8 +308,7 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
static int ct_write(struct intel_guc_ct *ct,
const u32 *action,
u32 len /* in dwords */,
- u32 fence,
- bool want_response)
+ u32 fence)
{
struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
struct guc_ct_buffer_desc *desc = ctb->desc;
@@ -360,8 +352,7 @@ static int ct_write(struct intel_guc_ct *ct,
* DW2+: action data
*/
header = (len << GUC_CT_MSG_LEN_SHIFT) |
-(GUC_CT_MSG_WRITE_FENCE_TO_DESC) |
-(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
+GUC_CT_MSG_SEND_STATUS |
(action[0] << GUC_CT_MSG_ACTION_SHIFT);
CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
@@ -390,56 +381,6 @@ static int ct_write(struct intel_guc_ct *ct,
return -EPIPE;
}
-/**
- * wait_for_ctb_desc_update - Wait for the CT buffer descriptor update.
- * @desc: buffer descriptor
- * @fence: response fence
- * @status:placeholder for status
- *
- * Guc will update CT buffer descriptor with new fence and status
- * after processing the command identified by the fence. Wait for
- * specified fence and then read from the descriptor status of the
- * command.
- *
- * Return:
- * * 0 response received (status is valid)
- * * -ETIMEDOUT no response within hardcoded timeout
- * * -EPROTO no response, CT buffer is in error
- */
-static int wait_for_ctb_desc_update(struct guc_ct_buffer_desc *desc,
- u32 fence,
- u32 *status)
-{
- int err;
-
- /*
-* Fast commands should complete in less than 10us, so sample quickly
-* up to that length of time, then switch to a slower sleep-wait loop.
-* No GuC command should ever take longer than 10ms.
-*/
-#define done (READ_ONCE(desc->fence) == fence)
- err = wait_for_us(done, 10);
- if (err)
- err = wait_for(done, 10);
-#undef done
-
- if (unlikely(err)) {
- DRM_ERROR("CT: fence %u failed; reported fence=%u\n",
- fence, desc->fence);
-
- if (WARN_ON(desc->is_in_error)) {
- /* Something went wrong with the messaging, try to reset
-* the buffer and hope for the best
-*/
- guc_ct_buffer_desc_reset(desc);
- err = -EPROTO;
- }
- }
-
- *status = desc->status;
- return err;
-}
-
/**
* wait_for_ct_request_update - Wait for CT request state update.
* @req: pointer to pending request
@@ -483,8 +424,6 @@ static int ct_send(struct intel_guc_ct *ct,
u32 response_buf_size,
u32 *status)
{
- struct intel_guc_ct_buffer *ctb = >ctbs[CTB_SEND];
- struct guc_ct_buffer_desc *desc = ctb->desc;
struct
[Intel-gfx] [PATCH 05/20] drm/i915/guc: Keep strict GuC ABI definitions
From: Michal Wajdeczko
Our fwif.h file is now mix of strict firmware ABI definitions and
set of our helpers. In anticipation of upcoming changes to the GuC
interface try to keep them separate in smaller maintainable files.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Michał Winiarski
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 51 +
.../gt/uc/abi/guc_communication_ctb_abi.h | 106 +
.../gt/uc/abi/guc_communication_mmio_abi.h| 52 +
.../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 14 ++
.../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 21 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 203 +-
6 files changed, 250 insertions(+), 197 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
new file mode 100644
index ..90efef8a73e4
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2014-2021 Intel Corporation
+ */
+
+#ifndef _ABI_GUC_ACTIONS_ABI_H
+#define _ABI_GUC_ACTIONS_ABI_H
+
+enum intel_guc_action {
+ INTEL_GUC_ACTION_DEFAULT = 0x0,
+ INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
+ INTEL_GUC_ACTION_REQUEST_ENGINE_RESET = 0x3,
+ INTEL_GUC_ACTION_ALLOCATE_DOORBELL = 0x10,
+ INTEL_GUC_ACTION_DEALLOCATE_DOORBELL = 0x20,
+ INTEL_GUC_ACTION_LOG_BUFFER_FILE_FLUSH_COMPLETE = 0x30,
+ INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x40,
+ INTEL_GUC_ACTION_FORCE_LOG_BUFFER_FLUSH = 0x302,
+ INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
+ INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
+ INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
+ INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
+ INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
+ INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
+ INTEL_GUC_ACTION_LIMIT
+};
+
+enum intel_guc_preempt_options {
+ INTEL_GUC_PREEMPT_OPTION_DROP_WORK_Q = 0x4,
+ INTEL_GUC_PREEMPT_OPTION_DROP_SUBMIT_Q = 0x8,
+};
+
+enum intel_guc_report_status {
+ INTEL_GUC_REPORT_STATUS_UNKNOWN = 0x0,
+ INTEL_GUC_REPORT_STATUS_ACKED = 0x1,
+ INTEL_GUC_REPORT_STATUS_ERROR = 0x2,
+ INTEL_GUC_REPORT_STATUS_COMPLETE = 0x4,
+};
+
+enum intel_guc_sleep_state_status {
+ INTEL_GUC_SLEEP_STATE_SUCCESS = 0x1,
+ INTEL_GUC_SLEEP_STATE_PREEMPT_TO_IDLE_FAILED = 0x2,
+ INTEL_GUC_SLEEP_STATE_ENGINE_RESET_FAILED = 0x3
+#define INTEL_GUC_SLEEP_STATE_INVALID_MASK 0x8000
+};
+
+#define GUC_LOG_CONTROL_LOGGING_ENABLED(1 << 0)
+#define GUC_LOG_CONTROL_VERBOSITY_SHIFT4
+#define GUC_LOG_CONTROL_VERBOSITY_MASK (0xF << GUC_LOG_CONTROL_VERBOSITY_SHIFT)
+#define GUC_LOG_CONTROL_DEFAULT_LOGGING(1 << 8)
+
+#endif /* _ABI_GUC_ACTIONS_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
new file mode 100644
index ..ebd8c3e0e4bb
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2014-2021 Intel Corporation
+ */
+
+#ifndef _ABI_GUC_COMMUNICATION_CTB_ABI_H
+#define _ABI_GUC_COMMUNICATION_CTB_ABI_H
+
+#include
+
+/**
+ * DOC: CTB based communication
+ *
+ * The CTB (command transport buffer) communication between Host and GuC
+ * is based on u32 data stream written to the shared buffer. One buffer can
+ * be used to transmit data only in one direction (one-directional channel).
+ *
+ * Current status of the each buffer is stored in the buffer descriptor.
+ * Buffer descriptor holds tail and head fields that represents active data
+ * stream. The tail field is updated by the data producer (sender), and head
+ * field is updated by the data consumer (receiver)::
+ *
+ * ++
+ * | DESCRIPTOR | +=+++
+ * ++ | | MESSAGE(s) ||
+ * | address|->+=+++
+ * ++
+ * | head | ^-head^
+ * ++
+ * | tail | ^-tail-^
+ * ++
+ * | size | ^---size^
+ * ++
+ *
+ * Each message in data stream starts with the single u32 treated as a header,
+ * followed by optional set of u32 data that makes message specific payload::
+ *
[Intel-gfx] [PATCH 01/20] drm/i915/guc: skip disabling CTBs before sanitizing the GuC
From: Daniele Ceraolo Spurio If we're about to sanitize the GuC, something might have going wrong beforehand, so we should avoid trying to talk to it. Even if GuC is still running fine, the sanitize will reset its internal state and clear the CTB registration, so there is still no need to explicitly do so. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2469 Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Matthew Brost Reviewed-by: Matthew Brost Cc: Michal Wajdeczko Cc: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c index 6abb8f2dc33d..892c1315ce49 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c @@ -504,7 +504,7 @@ static int __uc_init_hw(struct intel_uc *uc) ret = intel_guc_sample_forcewake(guc); if (ret) - goto err_communication; + goto err_log_capture; if (intel_uc_uses_guc_submission(uc)) intel_guc_submission_enable(guc); @@ -529,8 +529,6 @@ static int __uc_init_hw(struct intel_uc *uc) /* * We've failed to load the firmware :( */ -err_communication: - guc_disable_communication(guc); err_log_capture: __uc_capture_load_err_log(uc); err_out: @@ -558,9 +556,6 @@ static void __uc_fini_hw(struct intel_uc *uc) if (intel_uc_uses_guc_submission(uc)) intel_guc_submission_disable(guc); - if (guc_communication_enabled(guc)) - guc_disable_communication(guc); - __uc_sanitize(uc); } @@ -577,7 +572,6 @@ void intel_uc_reset_prepare(struct intel_uc *uc) if (!intel_guc_is_ready(guc)) return; - guc_disable_communication(guc); __uc_sanitize(uc); } -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/20] GuC CTBs changes + a few misc patches
Single series to merge the following series that have been reviewed / passed CI: https://patchwork.freedesktop.org/series/90633/ https://patchwork.freedesktop.org/series/90552/ Signed-off-by: Matthew Brost Daniele Ceraolo Spurio (4): drm/i915/guc: skip disabling CTBs before sanitizing the GuC drm/i915/guc: use probe_error log for CT enablement failure drm/i915/guc: enable only the user interrupt when using GuC submission drm/i915/guc: Use guc_class instead of engine_class in fw interface Matthew Brost (2): drm/i915/guc: Drop guc->interrupts.enabled drm/i915/guc: Ensure H2G buffer updates visible before tail update Michal Wajdeczko (13): drm/i915/guc: Keep strict GuC ABI definitions drm/i915/guc: Stop using fence/status from CTB descriptor drm/i915: Promote ptrdiff() to i915_utils.h drm/i915/guc: Only rely on own CTB size drm/i915/guc: Don't repeat CTB layout calculations drm/i915/guc: Replace CTB array with explicit members drm/i915/guc: Update sizes of CTB buffers drm/i915/guc: Relax CTB response timeout drm/i915/guc: Start protecting access to CTB descriptors drm/i915/guc: Stop using mutex while sending CTB messages drm/i915/guc: Don't receive all G2H messages in irq handler drm/i915/guc: Always copy CT message to new allocation drm/i915/guc: Early initialization of GuC send registers Rodrigo Vivi (1): drm/i915/guc: Remove sample_forcewake h2g action drivers/gpu/drm/i915/Kconfig.profile | 10 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 18 +- .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 51 ++ .../gt/uc/abi/guc_communication_ctb_abi.h | 106 .../gt/uc/abi/guc_communication_mmio_abi.h| 52 ++ .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 14 + .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 21 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 61 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 - drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 20 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 537 +++--- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 14 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 233 ++-- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 - drivers/gpu/drm/i915/i915_utils.h | 5 + drivers/gpu/drm/i915/i915_vma.h | 5 - 18 files changed, 667 insertions(+), 529 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h create mode 100644 drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/20] drm/i915/guc: use probe_error log for CT enablement failure
From: Daniele Ceraolo Spurio
We have a couple of failure injection points in the CT enablement path,
so we need to use i915_probe_error() to select the appropriate log level.
A new macro (CT_PROBE_ERROR) has been added to the set of CT logging
macros to be used in this scenario and upcoming ones.
While adding the new macros, fix the underlying logging mechanics used
by the existing ones (DRM_DEV_* -> drm_*) and move the inlines to
before they're used inside the macros.
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 48 ---
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index fa9e048cc65f..72b48ac9271a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -7,14 +7,36 @@
#include "intel_guc_ct.h"
#include "gt/intel_gt.h"
+static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
+{
+ return container_of(ct, struct intel_guc, ct);
+}
+
+static inline struct intel_gt *ct_to_gt(struct intel_guc_ct *ct)
+{
+ return guc_to_gt(ct_to_guc(ct));
+}
+
+static inline struct drm_i915_private *ct_to_i915(struct intel_guc_ct *ct)
+{
+ return ct_to_gt(ct)->i915;
+}
+
+static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)
+{
+ return _to_i915(ct)->drm;
+}
+
#define CT_ERROR(_ct, _fmt, ...) \
- DRM_DEV_ERROR(ct_to_dev(_ct), "CT: " _fmt, ##__VA_ARGS__)
+ drm_err(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
#ifdef CONFIG_DRM_I915_DEBUG_GUC
#define CT_DEBUG(_ct, _fmt, ...) \
- DRM_DEV_DEBUG_DRIVER(ct_to_dev(_ct), "CT: " _fmt, ##__VA_ARGS__)
+ drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
#else
#define CT_DEBUG(...) do { } while (0)
#endif
+#define CT_PROBE_ERROR(_ct, _fmt, ...) \
+ i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
struct ct_request {
struct list_head link;
@@ -47,26 +69,6 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
INIT_WORK(>requests.worker, ct_incoming_request_worker_func);
}
-static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
-{
- return container_of(ct, struct intel_guc, ct);
-}
-
-static inline struct intel_gt *ct_to_gt(struct intel_guc_ct *ct)
-{
- return guc_to_gt(ct_to_guc(ct));
-}
-
-static inline struct drm_i915_private *ct_to_i915(struct intel_guc_ct *ct)
-{
- return ct_to_gt(ct)->i915;
-}
-
-static inline struct device *ct_to_dev(struct intel_guc_ct *ct)
-{
- return ct_to_i915(ct)->drm.dev;
-}
-
static inline const char *guc_ct_buffer_type_to_str(u32 type)
{
switch (type) {
@@ -264,7 +266,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
err_deregister:
ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
err_out:
- CT_ERROR(ct, "Failed to open open CT channel (err=%d)\n", err);
+ CT_PROBE_ERROR(ct, "Failed to open channel (err=%d)\n", err);
return err;
}
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/20] drm/i915/guc: Drop guc->interrupts.enabled
Drop the variable guc->interrupts.enabled as this variable is just
leading to bugs creeping into the code.
e.g. A full GPU reset disables the GuC interrupts but forgot to clear
guc->interrupts.enabled, guc->interrupts.enabled being true suppresses
interrupts from getting re-enabled and now we are broken.
It is harmless to enable interrupt while already enabled so let's just
delete this variable to avoid bugs like this going forward.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 27 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 -
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index ab2c8fe8cdfa..18da9ed15728 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -96,12 +96,9 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>i915->runtime_pm);
spin_lock_irq(>irq_lock);
- if (!guc->interrupts.enabled) {
- WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
-gt->pm_guc_events);
- guc->interrupts.enabled = true;
- gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
- }
+ WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
+gt->pm_guc_events);
+ gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
spin_unlock_irq(>irq_lock);
}
@@ -112,7 +109,6 @@ static void gen9_disable_guc_interrupts(struct intel_guc
*guc)
assert_rpm_wakelock_held(>i915->runtime_pm);
spin_lock_irq(>irq_lock);
- guc->interrupts.enabled = false;
gen6_gt_pm_disable_irq(gt, gt->pm_guc_events);
@@ -134,18 +130,14 @@ static void gen11_reset_guc_interrupts(struct intel_guc
*guc)
static void gen11_enable_guc_interrupts(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
+ u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
spin_lock_irq(>irq_lock);
- if (!guc->interrupts.enabled) {
- u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
-
- WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
- intel_uncore_write(gt->uncore,
- GEN11_GUC_SG_INTR_ENABLE, events);
- intel_uncore_write(gt->uncore,
- GEN11_GUC_SG_INTR_MASK, ~events);
- guc->interrupts.enabled = true;
- }
+ WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
+ intel_uncore_write(gt->uncore,
+ GEN11_GUC_SG_INTR_ENABLE, events);
+ intel_uncore_write(gt->uncore,
+ GEN11_GUC_SG_INTR_MASK, ~events);
spin_unlock_irq(>irq_lock);
}
@@ -154,7 +146,6 @@ static void gen11_disable_guc_interrupts(struct intel_guc
*guc)
struct intel_gt *gt = guc_to_gt(guc);
spin_lock_irq(>irq_lock);
- guc->interrupts.enabled = false;
intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_MASK, ~0);
intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index c20f3839de12..4abc59f6f3cd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -33,7 +33,6 @@ struct intel_guc {
unsigned int msg_enabled_mask;
struct {
- bool enabled;
void (*reset)(struct intel_guc *guc);
void (*enable)(struct intel_guc *guc);
void (*disable)(struct intel_guc *guc);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Thu, Jun 3, 2021 at 5:48 AM Matthew Brost wrote:
>
> On Wed, Jun 02, 2021 at 08:57:02PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin
> > wrote:
> > > On 25/05/2021 17:45, Matthew Brost wrote:
> > > > On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote:
> > > >> * Context pinning code with it's magical two adds, subtract and
> > > >> cmpxchg is
> > > >> dodgy as well.
> > > >
> > > > Daniele tried to remove this and it proved quite difficult + created
> > > > even more races in the backend code. This was prior to the pre-pin and
> > > > post-unpin code which makes this even more difficult to fix as I believe
> > > > these functions would need to be removed first. Not saying we can't
> > > > revisit this someday but I personally really like it - it is a clever
> > > > way to avoid reentering the pin / unpin code while asynchronous things
> > > > are happening rather than some complex locking scheme. Lastly, this code
> > > > has proved incredibly stable as I don't think we've had to fix a single
> > > > thing in this area since we've been using this code internally.
> > >
> > > Pretty much same as above. The code like:
> > >
> > > static inline void __intel_context_unpin(struct intel_context *ce)
> > > {
> > > if (!ce->ops->sched_disable) {
> > > __intel_context_do_unpin(ce, 1);
> > > } else {
> > > while (!atomic_add_unless(>pin_count, -1, 1)) {
> > > if (atomic_cmpxchg(>pin_count, 1, 2) == 1) {
> > > ce->ops->sched_disable(ce);
> > > break;
> > > }
> > > }
> > > }
> > > }
> > >
> > > That's pretty much impenetrable for me and the only thing I can think of
> > > here is **ALARM** must be broken! See what others think..
>
> Yea, probably should add a comment:
>
> /*
> * If the context has the sched_disable function, it isn't safe to unpin
> * until this function completes. This function is allowed to complete
> * asynchronously too. To avoid this function from being entered twice
> * and move ownership of the unpin to this function's completion, adjust
> * the pin count to 2 before it is entered. When this function completes
> * the context can call intel_context_sched_unpin which decrements the
> * pin count by 2 potentially resulting in an unpin.
> *
> * A while loop is needed to ensure the atomicity of the pin count. e.g.
> * The below if / else statement has a race:
> *
> * if (atomic_cmpxchg(>pin_count, 1, 2) == 1)
> * ce->ops->sched_disable(ce);
> * else
> * atomic_dec(ce, 1);
> *
> * Two threads could simultaneously fail the if clause resulting in the
> * pin_count going to 0 with scheduling enabled + the context pinned.
> */
>
> >
> > pin_count is a hand-rolled mutex, except not actually a real one, and
> > it's absolutely hiliarous in it's various incarnations (there's one
> > each on i915_vm, vma, obj and probably a few more).
> >
> > Not the worst one I've seen by far in the code we've merged already.
> > Minimally this needs a comment here and in the struct next to
> > @pin_count to explain where all this is abused, which would already
> > make it better than most of the in-tree ones.
> >
> > As part of the ttm conversion we have a plan to sunset the "pin_count
> > as a lock" stuff, depending how bad that goes we might need to split
> > up the task for each struct that has such a pin_count.
> >
>
> Didn't know that with the TTM rework this value might go away. If that
> is truely the direction I don't see the point in reworking this now. It
> 100% works and with a comment I think it can be understood what it is
> doing.
Well not go away, but things will change. Currently the various
->pin_count sprinkled all over the place have essentially two uses
- pinning stuff long term (scanout, ctxs, anything that stays pinned
after the ioctl is done essentially)
- short-term lock-like construct
There's going to be two changes:
- The short-term pins will be replaced by dma_resv_lock/unlock pairs
- the locking rules for long-term pins will change, because we'll
require that you must hold dma_resv_lock for unpinning. So no more
atomic_t, also no more races for final unpins vs cleanup work
Also now that you've explained the why for this dance, especially the
async part: Since the new unpin will hold dma_resv_lock, we can
create dma_fence for tracking async completion which then the
next operation can wait on.
The awkward state we have right now is that there's a lot of places
where we require the unpin to be done locklessly with these atomic
tricks, so there's going to be quite some surgery involved all over
the code.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Wed, Jun 02, 2021 at 04:27:18PM +0100, Tvrtko Ursulin wrote: > > On 25/05/2021 17:45, Matthew Brost wrote: > > On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote: > > > > > > On 06/05/2021 20:13, Matthew Brost wrote: > > > > Basic GuC submission support. This is the first bullet point in the > > > > upstreaming plan covered in the following RFC [1]. > > > > > > > > At a very high level the GuC is a piece of firmware which sits between > > > > the i915 and the GPU. It offloads some of the scheduling of contexts > > > > from the i915 and programs the GPU to submit contexts. The i915 > > > > communicates with the GuC and the GuC communicates with the GPU. > > > > > > > > GuC submission will be disabled by default on all current upstream > > > > platforms behind a module parameter - enable_guc. A value of 3 will > > > > enable submission and HuC loading via the GuC. GuC submission should > > > > work on all gen11+ platforms assuming the GuC firmware is present. > > > > > > > > This is a huge series and it is completely unrealistic to merge all of > > > > these patches at once. Fortunately I believe we can break down the > > > > series into different merges: > > > > > > > > 1. Merge Chris Wilson's patches. These have already been reviewed > > > > upstream and I fully agree with these patches as a precursor to GuC > > > > submission. > > > > > > > > 2. Update to GuC 60.1.2. These are largely Michal's patches. > > > > > > > > 3. Turn on GuC/HuC auto mode by default. > > > > > > > > 4. Additional patches needed to support GuC submission. This is any > > > > patch not covered by 1-3 in the first 34 patches. e.g. 'Engine relative > > > > MMIO' > > > > > > > > 5. GuC submission support. Patches number 35+. These all don't have to > > > > merge at once though as we don't actually allow GuC submission until the > > > > last patch of this series. > > > > > > For the GuC backend/submission part only - it seems to me none of my > > > review > > > comments I made in December 2019 have been implemented. At that point I > > > > I wouldn't say none of the fixes have done, lots have just not > > everything you wanted. > > > > > stated, and this was all internally at the time mind you, that I do not > > > think the series is ready and there were several high level issues that > > > would need to be sorted out. I don't think I gave my ack or r-b back then > > > and the promise was a few things would be worked on post (internal) merge. > > > That was supposed to include upstream refactoring to enable GuC better > > > slotting in as a backed. Fast forward a year and a half later and the only > > > progress we had in this area has been deleted. > > > > > > From the top of my head, and having glanced the series as posted: > > > > > > * Self-churn factor in the series is too high. > > > > Not sure what you mean by this? The patches have been reworked > > internally too much? > > No, I meant series adds and removes, changes the same code a bit much which > makes it harder to review. It is much easier when the flow is logical and > typical, where it starts with refactoring, generalising, building > infrastructure and then plugging bits in, than it is to review patches which > add stuff which then get removed or changed significantly a few patches down > the line. > This has been part of the internal churn but most of this should go away as it gets posted / merged in smaller sets of patches. > > > * Patch ordering issues. > > > > We are going to clean up some of the ordering as these 97 patches are > > posted in smaller mergeable series but at the end of the day this is a > > bit of a bikeshed. GuC submission can't be turned until patch 97 so IMO > > it really isn't all that big of a deal the order of which patches before > > that land as we are not breaking anything. > > Yes some leeway for ordering is fine. > > > > * GuC context state machine is way too dodgy to have any confidence it > > > can > > > be read and race conditions understood. > > > > I know you don't really like the state machine but no other real way to > > not have DoS on resources and no real way to fairly distribute guc_ids > > without it. I know you have had other suggestions here but none of your > > suggestions either will work or they are no less complicated in the end. > > > > For what it is worth, the state machine will get simplified when we hook > > into the DRM scheduler as won't have to deal with submitting from IRQ > > contexts in the backend or having more than 1 request in the backend at > > a time. > > Dunno. A mix of self-churn, locks, inconsistent naming, verbosity and magic > makes it super hard to review. States in functions like guc_context_ban, > guc_context_sched_disable, guc_context_block, .. I find it impossible to > follow what's going on. Some under lock, some outside, jumps, returns, add > magic two .. Perhaps it is just me so wait and see what other reviewers will > think. > No doubt it
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Wed, Jun 02, 2021 at 08:57:02PM +0200, Daniel Vetter wrote:
> On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin
> wrote:
> > On 25/05/2021 17:45, Matthew Brost wrote:
> > > On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote:
> > >> * Context pinning code with it's magical two adds, subtract and
> > >> cmpxchg is
> > >> dodgy as well.
> > >
> > > Daniele tried to remove this and it proved quite difficult + created
> > > even more races in the backend code. This was prior to the pre-pin and
> > > post-unpin code which makes this even more difficult to fix as I believe
> > > these functions would need to be removed first. Not saying we can't
> > > revisit this someday but I personally really like it - it is a clever
> > > way to avoid reentering the pin / unpin code while asynchronous things
> > > are happening rather than some complex locking scheme. Lastly, this code
> > > has proved incredibly stable as I don't think we've had to fix a single
> > > thing in this area since we've been using this code internally.
> >
> > Pretty much same as above. The code like:
> >
> > static inline void __intel_context_unpin(struct intel_context *ce)
> > {
> > if (!ce->ops->sched_disable) {
> > __intel_context_do_unpin(ce, 1);
> > } else {
> > while (!atomic_add_unless(>pin_count, -1, 1)) {
> > if (atomic_cmpxchg(>pin_count, 1, 2) == 1) {
> > ce->ops->sched_disable(ce);
> > break;
> > }
> > }
> > }
> > }
> >
> > That's pretty much impenetrable for me and the only thing I can think of
> > here is **ALARM** must be broken! See what others think..
Yea, probably should add a comment:
/*
* If the context has the sched_disable function, it isn't safe to unpin
* until this function completes. This function is allowed to complete
* asynchronously too. To avoid this function from being entered twice
* and move ownership of the unpin to this function's completion, adjust
* the pin count to 2 before it is entered. When this function completes
* the context can call intel_context_sched_unpin which decrements the
* pin count by 2 potentially resulting in an unpin.
*
* A while loop is needed to ensure the atomicity of the pin count. e.g.
* The below if / else statement has a race:
*
* if (atomic_cmpxchg(>pin_count, 1, 2) == 1)
* ce->ops->sched_disable(ce);
* else
* atomic_dec(ce, 1);
*
* Two threads could simultaneously fail the if clause resulting in the
* pin_count going to 0 with scheduling enabled + the context pinned.
*/
>
> pin_count is a hand-rolled mutex, except not actually a real one, and
> it's absolutely hiliarous in it's various incarnations (there's one
> each on i915_vm, vma, obj and probably a few more).
>
> Not the worst one I've seen by far in the code we've merged already.
> Minimally this needs a comment here and in the struct next to
> @pin_count to explain where all this is abused, which would already
> make it better than most of the in-tree ones.
>
> As part of the ttm conversion we have a plan to sunset the "pin_count
> as a lock" stuff, depending how bad that goes we might need to split
> up the task for each struct that has such a pin_count.
>
Didn't know that with the TTM rework this value might go away. If that
is truely the direction I don't see the point in reworking this now. It
100% works and with a comment I think it can be understood what it is
doing.
Matt
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/21] Add Support for Plane Color Lut and CSC features
On 2021-06-02 4:22 p.m., Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, June 2, 2021 2:59 PM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, >> Bhanuprakash ; Harry Wentland >> >> Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features >> >> On Tue, 1 Jun 2021 16:21:57 +0530 >> Uma Shankar wrote: >> >>> This is how a typical display color hardware pipeline looks like: >>> +---+ >>> |RAM| >>> | +--++-++-+ | >>> | | FB 1 || FB 2 || FB N| | >>> | +--++-++-+ | >>> +---+ >>>| Plane Color Hardware Block | >>> ++ >>> | +---v-+ +---v---+ +---v--+ | >>> | | Plane A | | Plane B | | Plane N | | >>> | | DeGamma | | Degamma | | Degamma | | >>> | +---+-+ +---+---+ +---+--+ | >>> | | | || >>> | +---v-+ +---v---+ +---v--+ | >>> | |Plane A | | Plane B | | Plane N | | >>> | |CSC/CTM | | CSC/CTM | | CSC/CTM | | >>> | +---+-+ ++--+ ++-+ | >>> | | | | | >>> | +---v-+ +v--+ +v-+ | >>> | | Plane A | | Plane B | | Plane N | | >>> | | Gamma | | Gamma | | Gamma| | >>> | +---+-+ ++--+ ++-+ | >>> | | | | | >>> ++ >>> +--v--v---v---| >>> || || >>> || Pipe Blender|| >>> +++ >>> ||| >>> |+---v--+ | >>> || Pipe DeGamma| | >>> || | | >>> |+---+--+ | >>> ||Pipe Color | >>> |+---v--+ Hardware| >>> || Pipe CSC/CTM| | >>> || | | >>> |+---+--+ | >>> ||| >>> |+---v--+ | >>> || Pipe Gamma | | >>> || | | >>> |+---+--+ | >>> ||| >>> +-+ >>> | >>> v >>>Pipe Output >> >> Hi, >> >> this is an excellent picture. I have long been wanting schematics like that >> in the DRM >> UAPI documentation. Another note on that: >> https://lists.freedesktop.org/archives/dri-devel/2021-May/307310.html>>> >> But the schematic for DRM UAPI documentation needs to be written in terms of >> the >> abstract KMS pipeline with property names spelled out, like in what Ville >> sketched in >> that email. > > Sure Pekka, I can add that. > >>> This patch series adds properties for plane color features. It adds >>> properties for degamma used to linearize data and CSC used for gamut >>> conversion. It also includes Gamma support used to again non-linearize >>> data as per panel supported color space. These can be utilize by user >>> space to convert planes from one format to another, one color space to >>> another etc. >> >> This is very much welcome! >> >> There is also the thread: >> https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html>>> >> Everything mentioned will interact with each other by changing what the >> abstract >> KMS pixel pipeline does. I think you and Harry should probably look at each >> others' >> suggestions and see how to fit them all into a single abstract KMS pipeline. >> >> People are adding new pieces into KMS left and right, and I fear we lose >> sight of how >> everything will actually work together when all KMS properties are supposed >> to be >> generic and potentially present simultaneously. This is why I would very >> much like to >> have that *whole* abstract KMS pipeline documented with *everything*. >> Otherwise >> it is coming really hard fast to figure out how generic userspace should use >> all these >> KMS properties together. >> >> Or if there cannot be a single abstract KMS pipeline, then sure, have >> multiple, as long >> as they are documented and how userspace will know which pipeline it is >> dealing >> with, and what things are mutually exclusive so we can avoid writing >> userspace code >> for combinations that will never exist. > > This is a good suggestion to
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Introduce i915_sched_engine object
On Mon, May 31, 2021 at 10:31:53AM +0200, Daniel Vetter wrote: > On Thu, May 27, 2021 at 4:19 PM Matthew Brost wrote: > > > > On Thu, May 27, 2021 at 10:41:10AM +0100, Tvrtko Ursulin wrote: > > > > > > On 26/05/2021 21:03, Matthew Brost wrote: > > > > Introduce i915_sched_engine object which is lower level data structure > > > > that i915_scheduler / generic code can operate on without touching > > > > execlist specific structures. This allows additional submission backends > > > > to be added without breaking the layering. > > > > > > > > This is a bit of detour to integrating the i915 with the DRM scheduler > > > > but this object will still exist when the DRM scheduler lands in the > > > > i915. It will however look a bit different. It will encapsulate the > > > > drm_gpu_scheduler object plus and common variables (to the backends) > > > > related to scheduling. Regardless this is a step in the right direction. > > > > > > It looks like pretty much the same concept Chris implemented in > > > upstream(*) before they got removed. Both series move the scheduling > > > lists into a new object, be it i915_sched, or i915_sched_engine. There > > > probably are some differences but without looking much deeper it is hard > > > to say if they are important. > > > > > > Were you aware of this series and were there any technical objections to > > > it? > > > > > > > I haven't dug to deep into the series but yes, I am aware of this series. I > > merged my series to internal while Chris had this inflight upstream. They do > > have similar concepts of i915_sched_engine object. > > Imo both of them are a detour since it's not drm/scheduler, but also > we need one and this one here is the one we have so I'm not seeing the > point of repainting that bikeshed in different colors. Imo much better > if we just land this and then head as straight as possible towards > drm/scheduler as the interface. > Agree. > Now a bit of polish here might be good, but in entirely different ways: > - I think splitting the patch into the purely mechanical code movement > and addition of the new callbacks would be good. Should slice really > well I hope, so not much work. > This patch is basically find / replace in the sense it moves existing variables + vfuncs from one structure to another. It does add a few wrappers so not to touch the new structures variables but nothing else beyond that. IMO there really isn't a logical split point. > - Proper kerneldoc for at least anything new around datastructures. > That means a) check the header is pulled in somewhere suitable in > i915.rst b) minimal fixes for any warnings it throws c) then do right > in anything new. Especially with datastructure stuff like > locking/lifetime rules or rules around callbacks and these big ticket > items are important to document and cross reference, and I think the > pain for doing a)) for these is worth it. > I'll add some kerenl doc in my next post of this patch. Matt > > > Because there do appear to be some extra advantages in the dropped work, > > > like consolidating finding of active request and moving some other bits > > > to be backend agnostic. > > > > > > > After briefly looking at this series most of Chris's changes are not > > relevent if > > we move to DRM scheduler. All of the the below series [1] and internal is > > based > > this code not Chris's. I don't see the point revisiting Chris's old patches > > when > > the goal is to merge GuC submission quickly, rework it is place as needed, > > and > > the long term goal is to move to the DRM scheduler. > > Agreed. > > Cheers, Daniel > > > > > Matt > > > > [1] https://patchwork.freedesktop.org/series/89844/ > > > > > Regards, > > > > > > Tvrtko > > > > > > > > > *) Approx list: > > > > > > 564c84ac5dee drm/i915: Move finding the current active request to the > > > scheduler > > > f06f5161eba3 drm/i915: Move submit_request to i915_sched_engine > > > 38a40d211075 drm/i915/gt: Only kick the scheduler on timeslice/preemption > > > change > > > 4f08e41b51e2 drm/i915: Move tasklet from execlists to sched > > > 5d814ae56fdd drm/i915: Move scheduler queue > > > 4d4da5ab8b3c drm/i915: Move common active lists from engine to > > > i915_scheduler > > > 4a5c90b6f7a8 drm/i915: Wrap access to intel_engine.active > > > 34cab8ee986f drm/i915/gt: Pull all execlists scheduler initialisation > > > together > > > c968d4d87cf4 drm/i915: Extract the ability to defer and rerun a request > > > later > > > 746cafc44205 drm/i915: Extract request suspension from the execlists > > > 3d473f1476d8 drm/i915: Extract request rewinding from execlists > > > d353a704a6db drm/i915: Extract request submission from execlists > > > ea848ef93075 drm/i915: Replace engine->schedule() with a known request > > > operation > > > > > > > > > > > Cc: Daniel Vetter > > > > Cc: Daniele Ceraolo Spurio > > > > Signed-off-by: Matthew Brost > > > > --- > > > > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 +- > > >
Re: [Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree
Hi all, On Thu, 3 Jun 2021 12:48:47 +1000 Stephen Rothwell wrote: > > diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > index bcfd4a8d0288,1923f035713a.. > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > @@@ -657,11 -657,10 +658,11 @@@ void amdgpu_vm_move_to_lru_tail(struct > if (!bo->parent) > continue; > > -ttm_bo_move_to_lru_tail(>tbo, >tbo.mem, > +ttm_bo_move_to_lru_tail(>tbo, bo->tbo.resource, > >lru_bulk_move); > - if (bo->shadow) > - ttm_bo_move_to_lru_tail(>shadow->tbo, > + if (shadow) > -ttm_bo_move_to_lru_tail(>tbo, >tbo.mem, > ++ttm_bo_move_to_lru_tail(>tbo, > +bo->shadow->tbo.resource, that line should have been shadow->tbo.resource, I have fixed it up in my resolution. -- Cheers, Stephen Rothwell pgpFbmnGdAfSD.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree
Hi all,
Today's linux-next merge of the amdgpu tree got conflicts in:
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
between commit:
d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
from the drm-misc tree and commits:
b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG BOs")
2a675640bc2d ("drm/amdgpu: move shadow bo validation to VM code")
59276f056fb7 ("drm/amdgpu: switch to amdgpu_bo_vm for vm code")
19a1d9350be6 ("drm/amdgpu: flush gart changes after all BO recovery")
from the amdgpu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 663aa7d2e2ea,86259435803e..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@@ -459,10 -479,11 +461,11 @@@ static int amdgpu_bo_move(struct ttm_bu
{
struct amdgpu_device *adev;
struct amdgpu_bo *abo;
- struct ttm_resource *old_mem = >mem;
+ struct ttm_resource *old_mem = bo->resource;
int r;
- if (new_mem->mem_type == TTM_PL_TT) {
+ if (new_mem->mem_type == TTM_PL_TT ||
+ new_mem->mem_type == AMDGPU_PL_PREEMPT) {
r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, new_mem);
if (r)
return r;
@@@ -989,8 -1012,9 +995,9 @@@ int amdgpu_ttm_alloc_gart(struct ttm_bu
return r;
}
+ amdgpu_gart_invalidate_tlb(adev);
- ttm_resource_free(bo, >mem);
- bo->mem = tmp;
+ ttm_resource_free(bo, bo->resource);
+ ttm_bo_assign_mem(bo, );
}
return 0;
@@@ -1348,7 -1373,16 +1356,16 @@@ static bool amdgpu_ttm_bo_eviction_valu
}
}
- switch (bo->mem.mem_type) {
+ switch (bo->resource->mem_type) {
+ case AMDGPU_PL_PREEMPT:
+ /* Preemptible BOs don't own system resources managed by the
+* driver (pages, VRAM, GART space). They point to resources
+* owned by someone else (e.g. pageable memory in user mode
+* or a DMABuf). They are used in a preemptible context so we
+* can guarantee no deadlocks and good QoS in case of MMU
+* notifiers or DMABuf move notifiers from the resource owner.
+*/
+ return false;
case TTM_PL_TT:
if (amdgpu_bo_is_amdgpu_bo(bo) &&
amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
@@@ -1767,8 -1809,13 +1791,9 @@@ void amdgpu_ttm_fini(struct amdgpu_devi
amdgpu_bo_free_kernel(>mman.discovery_memory, NULL, NULL);
amdgpu_ttm_fw_reserve_vram_fini(adev);
- if (adev->mman.aper_base_kaddr)
- iounmap(adev->mman.aper_base_kaddr);
- adev->mman.aper_base_kaddr = NULL;
-
amdgpu_vram_mgr_fini(adev);
amdgpu_gtt_mgr_fini(adev);
+ amdgpu_preempt_mgr_fini(adev);
ttm_range_man_fini(>mman.bdev, AMDGPU_PL_GDS);
ttm_range_man_fini(>mman.bdev, AMDGPU_PL_GWS);
ttm_range_man_fini(>mman.bdev, AMDGPU_PL_OA);
@@@ -1919,7 -2010,12 +1944,12 @@@ int amdgpu_fill_buffer(struct amdgpu_b
return -EINVAL;
}
- if (bo->tbo.mem.mem_type == AMDGPU_PL_PREEMPT) {
++ if (bo->tbo.resource->mem_type == AMDGPU_PL_PREEMPT) {
+ DRM_ERROR("Trying to clear preemptible memory.\n");
+ return -EINVAL;
+ }
+
- if (bo->tbo.mem.mem_type == TTM_PL_TT) {
+ if (bo->tbo.resource->mem_type == TTM_PL_TT) {
r = amdgpu_ttm_alloc_gart(>tbo);
if (r)
return r;
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index bcfd4a8d0288,1923f035713a..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@@ -657,11 -657,10 +658,11 @@@ void amdgpu_vm_move_to_lru_tail(struct
if (!bo->parent)
continue;
- ttm_bo_move_to_lru_tail(>tbo, >tbo.mem,
+ ttm_bo_move_to_lru_tail(>tbo, bo->tbo.resource,
>lru_bulk_move);
- if (bo->shadow)
- ttm_bo_move_to_lru_tail(>shadow->tbo,
+ if (shadow)
- ttm_bo_move_to_lru_tail(>tbo, >tbo.mem,
++ ttm_bo_move_to_lru_tail(>tbo,
+ bo->shadow->tbo.resource,
>lru_bulk_move);
}
Re: [Intel-gfx] [PATCH v4 06/17] drm/i915/pxp: Implement funcs to create the TEE channel
On Mon, 2021-05-24 at 22:47 -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (default) session.
>
> v2: fix locking, don't pollute dev_priv (Chris)
>
> v3: wait for mei PXP component to be bound.
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio <
> daniele.ceraolospu...@intel.com>
> Cc: Chris Wilson
> Reviewed-by: Rodrigo Vivi #v2
> ---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 13
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 87
> ++
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 14
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 3 +
> 5 files changed, 119 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index efd950122e40..0dfff52fea24 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -275,7 +275,8 @@ i915-y += i915_perf.o
>
> # Protected execution platform (PXP) support
> i915-$(CONFIG_DRM_I915_PXP) += \
> - pxp/intel_pxp.o
> + pxp/intel_pxp.o \
> + pxp/intel_pxp_tee.o
>
> # Post-mortem debug and GPU hang state capture
> i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 3255c6da34e8..5df2a09c9e4b 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -3,6 +3,7 @@
> * Copyright(c) 2020 Intel Corporation.
> */
> #include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
> #include "gt/intel_context.h"
> #include "i915_drv.h"
>
> @@ -50,7 +51,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
> if (ret)
> return;
>
> + ret = intel_pxp_tee_component_init(pxp);
> + if (ret)
> + goto out_context;
> +
> drm_info(>i915->drm, "Protected Xe Path (PXP) protected
> content support initialized\n");
> +
> + return;
> +
> +out_context:
> + destroy_vcs_context(pxp);
> }
>
> void intel_pxp_fini(struct intel_pxp *pxp)
> @@ -58,5 +68,8 @@ void intel_pxp_fini(struct intel_pxp *pxp)
> if (!intel_pxp_is_enabled(pxp))
> return;
>
> + intel_pxp_tee_component_fini(pxp);
> +
> destroy_vcs_context(pxp);
> +
> }
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> new file mode 100644
> index ..4ed234d8584f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -0,0 +1,87 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include
> +#include "drm/i915_pxp_tee_interface.h"
> +#include "drm/i915_component.h"
> +#include "i915_drv.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_tee.h"
> +
> +static inline struct intel_pxp *i915_dev_to_pxp(struct device
> *i915_kdev)
> +{
> + return _to_i915(i915_kdev)->gt.pxp;
> +}
> +
> +/**
> + * i915_pxp_tee_component_bind - bind function to pass the function
> pointers to pxp_tee
> + * @i915_kdev: pointer to i915 kernel device
> + * @tee_kdev: pointer to tee kernel device
> + * @data: pointer to pxp_tee_master containing the function pointers
> + *
> + * This bind function is called during the system boot or resume
> from system sleep.
> + *
> + * Return: return 0 if successful.
> + */
> +static int i915_pxp_tee_component_bind(struct device *i915_kdev,
> +struct device *tee_kdev, void
> *data)
> +{
> + struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> +
> + pxp->pxp_component = data;
> + pxp->pxp_component->tee_dev = tee_kdev;
> +
> + return 0;
> +}
> +
> +static void i915_pxp_tee_component_unbind(struct device *i915_kdev,
> + struct device *tee_kdev, void
> *data)
> +{
> + struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
> +
> + pxp->pxp_component = NULL;
> +}
> +
> +static const struct component_ops i915_pxp_tee_component_ops = {
> + .bind = i915_pxp_tee_component_bind,
> + .unbind = i915_pxp_tee_component_unbind,
> +};
> +
> +int intel_pxp_tee_component_init(struct intel_pxp *pxp)
> +{
> + int ret;
> + struct intel_gt *gt = pxp_to_gt(pxp);
> + struct drm_i915_private *i915 = gt->i915;
> +
> + ret = component_add_typed(i915->drm.dev,
> _pxp_tee_component_ops,
> + I915_COMPONENT_PXP);
> + if (ret < 0) {
> + drm_err(>drm, "Failed to add PXP component
> (%d)\n", ret);
> + return ret;
> + }
> +
> + /*
> + * Adding the component does not guarantee that it will bind
> properly,
> + * so make sure to wait
Re: [Intel-gfx] [PATCH 24/29] drm/i915/gem: Delay context creation
On Mon, May 31, 2021 at 4:50 AM Daniel Vetter wrote:
>
> On Thu, May 27, 2021 at 11:26:45AM -0500, Jason Ekstrand wrote:
> > The current context uAPI allows for two methods of setting context
> > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
> > former is allowed to be called at any time while the later happens as
> > part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
> > settable via the other. While some params are fairly simple and setting
> > them on a live context is harmless such the context priority, others are
>
> such _as_ the
Done.
> > far trickier such as the VM or the set of engines. In order to swap out
> > the VM, for instance, we have to delay until all current in-flight work
> > is complete, swap in the new VM, and then continue. This leads to a
> > plethora of potential race conditions we'd really rather avoid.
> >
> > In previous patches, we added a i915_gem_proto_context struct which is
> > capable of storing and tracking all such create parameters. This commit
> > delays the creation of the actual context until after the client is done
> > configuring it with SET_CONTEXT_PARAM. From the perspective of the
> > client, it has the same u32 context ID the whole time. From the
> > perspective of i915, however, it's an i915_gem_proto_context right up
> > until the point where we attempt to do something which the proto-context
> > can't handle at which point the real context gets created.
>
> s/ at which point/. Then/
>
> At least feels a bit like a run-on sentence :-)
Done.
> > This is accomplished via a little xarray dance. When GEM_CONTEXT_CREATE
> > is called, we create a proto-context, reserve a slot in context_xa but
> > leave it NULL, the proto-context in the corresponding slot in
> > proto_context_xa. Then, whenever we go to look up a context, we first
> > check context_xa. If it's there, we return the i915_gem_context and
> > we're done. If it's not, we look in proto_context_xa and, if we find it
> > there, we create the actual context and kill the proto-context.
> >
> > In order for this dance to work properly, everything which ever touches
> > a proto-context is guarded by drm_i915_file_private::proto_context_lock,
> > including context creation. Yes, this means context creation now takes
> > a giant global lock but it can't really be helped and that should never
> > be on any driver's fast-path anyway.
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 211 ++
> > drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 54 +
> > .../gpu/drm/i915/gem/selftests/mock_context.c | 5 +-
> > drivers/gpu/drm/i915/i915_drv.h | 24 +-
> > 5 files changed, 239 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 8288af0d33245..f7c83730ee07f 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -298,6 +298,42 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > return err;
> > }
> >
> > +static int proto_context_register_locked(struct drm_i915_file_private
> > *fpriv,
> > + struct i915_gem_proto_context *pc,
> > + u32 *id)
> > +{
> > + int ret;
> > + void *old;
> > +
> > + lockdep_assert_held(>proto_context_lock);
> > +
> > + ret = xa_alloc(>context_xa, id, NULL, xa_limit_32b,
> > GFP_KERNEL);
> > + if (ret)
> > + return ret;
> > +
> > + old = xa_store(>proto_context_xa, *id, pc, GFP_KERNEL);
> > + if (xa_is_err(old)) {
> > + xa_erase(>context_xa, *id);
> > + return xa_err(old);
> > + }
> > + GEM_BUG_ON(old);
>
> I'd go with WARN_ON here. We just leak, and BUG_ON kills the box.
> GEM_BUG_ON is for the additional gem consistency checks which are too
> expensive to have enabled in production. Registering a proto context isn't
> one of these things.
Done.
> > +
> > + return 0;
> > +}
> > +
> > +static int proto_context_register(struct drm_i915_file_private *fpriv,
> > + struct i915_gem_proto_context *pc,
> > + u32 *id)
> > +{
> > + int ret;
> > +
> > + mutex_lock(>proto_context_lock);
> > + ret = proto_context_register_locked(fpriv, pc, id);
> > + mutex_unlock(>proto_context_lock);
> > +
> > + return ret;
> > +}
> > +
> > static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
> > struct i915_gem_proto_context *pc,
> > const struct drm_i915_gem_context_param *args)
> > @@ -1448,12 +1484,12 @@ void i915_gem_init__contexts(struct
> > drm_i915_private *i915)
> > init_contexts(>gem.contexts);
> > }
> >
Re: [Intel-gfx] [PATCH 21/29] drm/i915/gem: Use the proto-context to handle create parameters (v2)
On Mon, May 31, 2021 at 4:12 AM Daniel Vetter wrote:
>
> On Thu, May 27, 2021 at 11:26:42AM -0500, Jason Ekstrand wrote:
> > This means that the proto-context needs to grow support for engine
> > configuration information as well as setparam logic. Fortunately, we'll
> > be deleting a lot of setparam logic on the primary context shortly so it
> > will hopefully balance out.
> >
> > There's an extra bit of fun here when it comes to setting SSEU and the
> > way it interacts with PARAM_ENGINES. Unfortunately, thanks to
> > SET_CONTEXT_PARAM and not being allowed to pick the order in which we
> > handle certain parameters, we have think about those interactions.
> >
> > v2 (Daniel Vetter):
> > - Add a proto_context_free_user_engines helper
> > - Comment on SSEU in the commit message
> > - Use proto_context_set_persistence in set_proto_ctx_param
> >
> > Signed-off-by: Jason Ekstrand
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 552 +-
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 58 ++
> > 2 files changed, 588 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index cf7c281977a3e..d68c111bc824a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -191,10 +191,24 @@ static int validate_priority(struct drm_i915_private
> > *i915,
> > return 0;
> > }
> >
> > +static void proto_context_free_user_engines(struct i915_gem_proto_context
> > *pc)
> > +{
> > + int i;
> > +
> > + if (pc->user_engines) {
> > + for (i = 0; i < pc->num_user_engines; i++)
> > + kfree(pc->user_engines[i].siblings);
> > + kfree(pc->user_engines);
> > + }
> > + pc->user_engines = NULL;
> > + pc->num_user_engines = -1;
> > +}
> > +
> > static void proto_context_close(struct i915_gem_proto_context *pc)
> > {
> > if (pc->vm)
> > i915_vm_put(pc->vm);
> > + proto_context_free_user_engines(pc);
> > kfree(pc);
> > }
> >
> > @@ -211,7 +225,7 @@ static int proto_context_set_persistence(struct
> > drm_i915_private *i915,
> > if (!i915->params.enable_hangcheck)
> > return -EINVAL;
> >
> > - __set_bit(UCONTEXT_PERSISTENCE, >user_flags);
> > + pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
> > } else {
> > /* To cancel a context we use "preempt-to-idle" */
> > if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
> > @@ -233,7 +247,7 @@ static int proto_context_set_persistence(struct
> > drm_i915_private *i915,
> > if (!intel_has_reset_engine(>gt))
> > return -ENODEV;
> >
> > - __clear_bit(UCONTEXT_PERSISTENCE, >user_flags);
> > + pc->user_flags &= ~BIT(UCONTEXT_PERSISTENCE);
>
> Squashed into wrong patch I think. Also the one right above.
>
> > }
> >
> > return 0;
> > @@ -248,6 +262,9 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > if (!pc)
> > return ERR_PTR(-ENOMEM);
> >
> > + pc->num_user_engines = -1;
> > + pc->user_engines = NULL;
>
> If you go with my proto_context_reset_user_engines() suggestion below you
> could use that here too. It's overkill, but it makes the code a bit
> clearer in what it does I think.
>
> > +
> > if (HAS_FULL_PPGTT(i915)) {
> > struct i915_ppgtt *ppgtt;
> >
> > @@ -261,9 +278,8 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > pc->vm = >vm;
> > }
> >
> > - pc->user_flags = 0;
> > - __set_bit(UCONTEXT_BANNABLE, >user_flags);
> > - __set_bit(UCONTEXT_RECOVERABLE, >user_flags);
> > + pc->user_flags = BIT(UCONTEXT_BANNABLE) |
> > + BIT(UCONTEXT_RECOVERABLE);
>
> Same here.
>
> > proto_context_set_persistence(i915, pc, true);
> > pc->sched.priority = I915_PRIORITY_NORMAL;
> >
> > @@ -282,6 +298,429 @@ proto_context_create(struct drm_i915_private *i915,
> > unsigned int flags)
> > return err;
> > }
> >
> > +static int set_proto_ctx_vm(struct drm_i915_file_private *fpriv,
> > + struct i915_gem_proto_context *pc,
> > + const struct drm_i915_gem_context_param *args)
> > +{
> > + struct i915_address_space *vm;
> > +
> > + if (args->size)
> > + return -EINVAL;
> > +
> > + if (!pc->vm)
>
> I got confused by this and then realized it's checking for
> HAS_FULL_PPGTT(). I wonder whether we should lock this down more with
> runtime checks, or at least have a comment that ctx->vm is only set for
> HAS_FULL_PPGTT.
Yeah, this is a bit horrible. Really, though, if !HAS_FULL_PPGTT(),
then userspace should never be able to get a VM handle and
gem_vm_lookup will fail later. But I think having the
[Intel-gfx] ✓ Fi.CI.IGT: success for Finish conversion to GRAPHICS_VER (rev2)
== Series Details == Series: Finish conversion to GRAPHICS_VER (rev2) URL : https://patchwork.freedesktop.org/series/90693/ State : success == Summary == CI Bug Log - changes from CI_DRM_10161_full -> Patchwork_20267_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20267_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-kbl1/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-snb2/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#198]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-skl8/igt@gem_...@in-flight-suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-skl9/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][8] ([i915#3354]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-tglb2/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-kbl2/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][17] ([i915#2389]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-apl8/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][18] ([i915#2389]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-apl3/igt@gem_huc_c...@huc-copy.html - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-kbl4/igt@gem_huc_c...@huc-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-apl7/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@sync-overlap: - shard-glk: [PASS][22] -> [DMESG-WARN][23] ([i915#118] / [i915#95]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-glk1/igt@gem_userptr_bl...@sync-overlap.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/shard-glk2/igt@gem_userptr_bl...@sync-overlap.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN -> [FAIL][24] ([i915#3318]) [24]:
Re: [Intel-gfx] [PATCH 18/29] drm/i915/gem: Optionally set SSEU in intel_context_set_gem
On Mon, May 31, 2021 at 3:48 AM Daniel Vetter wrote:
>
> On Thu, May 27, 2021 at 11:26:39AM -0500, Jason Ekstrand wrote:
> > For now this is a no-op because everyone passes in a null SSEU but it
> > lets us get some of the error handling and selftest refactoring plumbed
> > through.
> >
> > Signed-off-by: Jason Ekstrand
>
> I've reviewed this one already in the previous round, did you change
> anything that means I should re-review this here?
Nope. Just lost the RB tag. Added.
--Jason
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
> > .../gpu/drm/i915/gem/selftests/mock_context.c | 6 ++-
> > 2 files changed, 36 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f8f3f514b4265..d247fb223aac7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -320,9 +320,12 @@ context_get_vm_rcu(struct i915_gem_context *ctx)
> > } while (1);
> > }
> >
> > -static void intel_context_set_gem(struct intel_context *ce,
> > - struct i915_gem_context *ctx)
> > +static int intel_context_set_gem(struct intel_context *ce,
> > + struct i915_gem_context *ctx,
> > + struct intel_sseu sseu)
> > {
> > + int ret = 0;
> > +
> > GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
> > RCU_INIT_POINTER(ce->gem_context, ctx);
> >
> > @@ -349,6 +352,12 @@ static void intel_context_set_gem(struct intel_context
> > *ce,
> >
> > intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
> > }
> > +
> > + /* A valid SSEU has no zero fields */
> > + if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
> > + ret = intel_context_reconfigure_sseu(ce, sseu);
> > +
> > + return ret;
> > }
> >
> > static void __free_engines(struct i915_gem_engines *e, unsigned int count)
> > @@ -416,7 +425,8 @@ static struct i915_gem_engines *alloc_engines(unsigned
> > int count)
> > return e;
> > }
> >
> > -static struct i915_gem_engines *default_engines(struct i915_gem_context
> > *ctx)
> > +static struct i915_gem_engines *default_engines(struct i915_gem_context
> > *ctx,
> > + struct intel_sseu rcs_sseu)
> > {
> > const struct intel_gt *gt = >i915->gt;
> > struct intel_engine_cs *engine;
> > @@ -429,6 +439,8 @@ static struct i915_gem_engines *default_engines(struct
> > i915_gem_context *ctx)
> >
> > for_each_engine(engine, gt, id) {
> > struct intel_context *ce;
> > + struct intel_sseu sseu = {};
> > + int ret;
> >
> > if (engine->legacy_idx == INVALID_ENGINE)
> > continue;
> > @@ -442,10 +454,18 @@ static struct i915_gem_engines
> > *default_engines(struct i915_gem_context *ctx)
> > goto free_engines;
> > }
> >
> > - intel_context_set_gem(ce, ctx);
> > -
> > e->engines[engine->legacy_idx] = ce;
> > e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
> > +
> > + if (engine->class == RENDER_CLASS)
> > + sseu = rcs_sseu;
> > +
> > + ret = intel_context_set_gem(ce, ctx, sseu);
> > + if (ret) {
> > + err = ERR_PTR(ret);
> > + goto free_engines;
> > + }
> > +
> > }
> >
> > return e;
> > @@ -759,6 +779,7 @@ __create_context(struct drm_i915_private *i915,
> > {
> > struct i915_gem_context *ctx;
> > struct i915_gem_engines *e;
> > + struct intel_sseu null_sseu = {};
> > int err;
> > int i;
> >
> > @@ -776,7 +797,7 @@ __create_context(struct drm_i915_private *i915,
> > INIT_LIST_HEAD(>stale.engines);
> >
> > mutex_init(>engines_mutex);
> > - e = default_engines(ctx);
> > + e = default_engines(ctx, null_sseu);
> > if (IS_ERR(e)) {
> > err = PTR_ERR(e);
> > goto err_free;
> > @@ -1543,6 +1564,7 @@ set_engines__load_balance(struct i915_user_extension
> > __user *base, void *data)
> > struct intel_engine_cs *stack[16];
> > struct intel_engine_cs **siblings;
> > struct intel_context *ce;
> > + struct intel_sseu null_sseu = {};
> > u16 num_siblings, idx;
> > unsigned int n;
> > int err;
> > @@ -1615,7 +1637,7 @@ set_engines__load_balance(struct i915_user_extension
> > __user *base, void *data)
> > goto out_siblings;
> > }
> >
> > - intel_context_set_gem(ce, set->ctx);
> > + intel_context_set_gem(ce, set->ctx, null_sseu);
> >
> > if (cmpxchg(>engines->engines[idx], NULL, ce)) {
> > intel_context_put(ce);
> > @@ -1723,6 +1745,7 @@ set_engines(struct i915_gem_context
Re: [Intel-gfx] [PATCH 16/27] drm/i915/gem: Add an intermediate proto_context struct
On Tue, May 4, 2021 at 11:13 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:37AM -0500, Jason Ekstrand wrote:
> > The current context uAPI allows for two methods of setting context
> > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
> > former is allowed to be called at any time while the later happens as
> > part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
> > settable via the other. While some params are fairly simple and setting
> > them on a live context is harmless such the context priority, others are
> > far trickier such as the VM or the set of engines. In order to swap out
> > the VM, for instance, we have to delay until all current in-flight work
> > is complete, swap in the new VM, and then continue. This leads to a
> > plethora of potential race conditions we'd really rather avoid.
> >
> > Unfortunately, both methods of setting the VM and engine set are in
> > active use today so we can't simply disallow setting the VM or engine
> > set vial SET_CONTEXT_PARAM. In order to work around this wart, this
> > commit adds a proto-context struct which contains all the context create
> > parameters.
> >
> > Signed-off-by: Jason Ekstrand
>
> Per-patch changelog pls.
Done.
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 145 ++
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
> > .../gpu/drm/i915/gem/selftests/mock_context.c | 16 +-
> > 3 files changed, 153 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 4835991898ac9..10bd1b6dd1774 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -191,6 +191,97 @@ static int validate_priority(struct drm_i915_private
> > *i915,
> > return 0;
> > }
> >
> > +static void proto_context_close(struct i915_gem_proto_context *pc)
> > +{
> > + if (pc->vm)
> > + i915_vm_put(pc->vm);
> > + kfree(pc);
> > +}
> > +
> > +static int proto_context_set_persistence(struct drm_i915_private *i915,
> > + struct i915_gem_proto_context *pc,
> > + bool persist)
> > +{
> > + if (persist) {
> > + /*
> > + * Only contexts that are short-lived [that will expire or be
> > + * reset] are allowed to survive past termination. We require
> > + * hangcheck to ensure that the persistent requests are
> > healthy.
> > + */
> > + if (!i915->params.enable_hangcheck)
> > + return -EINVAL;
> > +
> > + __set_bit(UCONTEXT_PERSISTENCE, >user_flags);
>
> Ok so I looked, and the reason __set_bit and friends is for endless
> bitfields, i.e. where user_flags is an actually dynamically sized array.
>
> Given that this is complete overkill I think fully open-coding the bitops
> is the right bikeshed color choice. So
I've fixed it now. I had fixed it in the last version but it ended up
squashed into the wrong patch. :-(
> user_flags &= UCONTEXT_PERSISTENCE;
>
> > + } else {
> > + /* To cancel a context we use "preempt-to-idle" */
> > + if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
> > + return -ENODEV;
> > +
> > + /*
> > + * If the cancel fails, we then need to reset, cleanly!
> > + *
> > + * If the per-engine reset fails, all hope is lost! We resort
> > + * to a full GPU reset in that unlikely case, but
> > realistically
> > + * if the engine could not reset, the full reset does not fare
> > + * much better. The damage has been done.
> > + *
> > + * However, if we cannot reset an engine by itself, we cannot
> > + * cleanup a hanging persistent context without causing
> > + * colateral damage, and we should not pretend we can by
> > + * exposing the interface.
> > + */
> > + if (!intel_has_reset_engine(>gt))
> > + return -ENODEV;
> > +
> > + __clear_bit(UCONTEXT_PERSISTENCE, >user_flags);
>
> user_flags &= ~UCONTEXT_PERSISTENCE;
>
> Similar for all the others.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct i915_gem_proto_context *
> > +proto_context_create(struct drm_i915_private *i915, unsigned int flags)
> > +{
> > + struct i915_gem_proto_context *pc, *err;
> > +
> > + pc = kzalloc(sizeof(*pc), GFP_KERNEL);
> > + if (!pc)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + if (HAS_FULL_PPGTT(i915)) {
> > + struct i915_ppgtt *ppgtt;
> > +
> > + ppgtt = i915_ppgtt_create(>gt);
> > + if (IS_ERR(ppgtt)) {
> > + drm_dbg(>drm,
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Get rid of fence error propagation
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10161_full -> Patchwork_20265_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20265_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20265_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20265_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-spin@bcs0: - shard-apl: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-apl3/igt@gem_exec_reloc@basic-s...@bcs0.html * igt@gem_exec_schedule@deep@bcs0: - shard-kbl: [PASS][2] -> [FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-kbl1/igt@gem_exec_schedule@d...@bcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-kbl7/igt@gem_exec_schedule@d...@bcs0.html - shard-skl: [PASS][4] -> [FAIL][5] +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-skl6/igt@gem_exec_schedule@d...@bcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-skl2/igt@gem_exec_schedule@d...@bcs0.html - shard-glk: [PASS][6] -> [FAIL][7] +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-glk6/igt@gem_exec_schedule@d...@bcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-glk6/igt@gem_exec_schedule@d...@bcs0.html - shard-apl: [PASS][8] -> [FAIL][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-apl7/igt@gem_exec_schedule@d...@bcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-apl1/igt@gem_exec_schedule@d...@bcs0.html Known issues Here are the changes found in Patchwork_20265_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +7 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-kbl2/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) +6 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-snb5/igt@gem_ctx_persiste...@smoketest.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +456 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-snb7/igt@gem_ctx_sha...@q-in-order.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][14] ([i915#3354]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-tglb5/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-iclb: [PASS][19] -> [FAIL][20] ([i915#2842]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#2842]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#2849]) [23]:
Re: [Intel-gfx] [PATCH 16/29] drm/i915/gem: Add an intermediate proto_context struct
On Mon, May 31, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Thu, May 27, 2021 at 11:26:37AM -0500, Jason Ekstrand wrote:
> > The current context uAPI allows for two methods of setting context
> > parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
> > former is allowed to be called at any time while the later happens as
> > part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
> > settable via the other. While some params are fairly simple and setting
> > them on a live context is harmless such the context priority, others are
> > far trickier such as the VM or the set of engines. In order to swap out
> > the VM, for instance, we have to delay until all current in-flight work
> > is complete, swap in the new VM, and then continue. This leads to a
> > plethora of potential race conditions we'd really rather avoid.
> >
> > Unfortunately, both methods of setting the VM and engine set are in
>
>^the
>
> At least my English parser jumped there a bit and got confused :-)
I believe what I wrote was correct but I'm happy to tweak it if it
helps others' parsers.
> > active use today so we can't simply disallow setting the VM or engine
> > set vial SET_CONTEXT_PARAM. In order to work around this wart, this
> > commit adds a proto-context struct which contains all the context create
> > parameters.
> >
> > Signed-off-by: Jason Ekstrand
>
> I also looked at my review from the previous round and I think we have a
> few opens there that haven't been addressed here. Would be nice to check
> that out too and my reply there if you're disagreeing and want to paint
> the shed differently :-)
Ok, I'll try to dig it up. I miss GitLab and it's "resolve
discussion" button so much
> I've found a few other things needing polish below on top of the earlier
> bits.
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 145 ++
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
> > .../gpu/drm/i915/gem/selftests/mock_context.c | 16 +-
> > 3 files changed, 153 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index fc471243aa769..10bff488444b6 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -191,6 +191,97 @@ static int validate_priority(struct drm_i915_private
> > *i915,
> > return 0;
> > }
> >
> > +static void proto_context_close(struct i915_gem_proto_context *pc)
> > +{
> > + if (pc->vm)
> > + i915_vm_put(pc->vm);
> > + kfree(pc);
> > +}
> > +
> > +static int proto_context_set_persistence(struct drm_i915_private *i915,
> > + struct i915_gem_proto_context *pc,
> > + bool persist)
> > +{
> > + if (persist) {
> > + /*
> > + * Only contexts that are short-lived [that will expire or be
> > + * reset] are allowed to survive past termination. We require
> > + * hangcheck to ensure that the persistent requests are
> > healthy.
> > + */
> > + if (!i915->params.enable_hangcheck)
> > + return -EINVAL;
> > +
> > + __set_bit(UCONTEXT_PERSISTENCE, >user_flags);
> > + } else {
> > + /* To cancel a context we use "preempt-to-idle" */
> > + if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
> > + return -ENODEV;
> > +
> > + /*
> > + * If the cancel fails, we then need to reset, cleanly!
> > + *
> > + * If the per-engine reset fails, all hope is lost! We resort
> > + * to a full GPU reset in that unlikely case, but
> > realistically
> > + * if the engine could not reset, the full reset does not fare
> > + * much better. The damage has been done.
> > + *
> > + * However, if we cannot reset an engine by itself, we cannot
> > + * cleanup a hanging persistent context without causing
> > + * colateral damage, and we should not pretend we can by
> > + * exposing the interface.
> > + */
> > + if (!intel_has_reset_engine(>gt))
> > + return -ENODEV;
> > +
> > + __clear_bit(UCONTEXT_PERSISTENCE, >user_flags);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct i915_gem_proto_context *
> > +proto_context_create(struct drm_i915_private *i915, unsigned int flags)
> > +{
> > + struct i915_gem_proto_context *pc, *err;
> > +
> > + pc = kzalloc(sizeof(*pc), GFP_KERNEL);
> > + if (!pc)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + if (HAS_FULL_PPGTT(i915)) {
> > + struct i915_ppgtt *ppgtt;
> > +
> > + ppgtt =
Re: [Intel-gfx] [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, June 2, 2021 3:04 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem,
> Bhanuprakash
> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range
> attributes
>
> On Tue, 1 Jun 2021 16:21:58 +0530
> Uma Shankar wrote:
>
> > Existing LUT precision structure is having only 16 bit precision. This
> > is not enough for upcoming enhanced hardwares and advance usecases
> > like HDR processing. Hence added a new structure with 32 bit precision
> > values.
> >
> > This also defines a new structure to define color lut ranges, along
> > with related macro definitions and enums. This will help describe
> > multi segmented lut ranges in the hardware.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > include/uapi/drm/drm_mode.h | 58
> > +
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 9b6722d45f36..d0ce48d2e732 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -819,6 +819,64 @@ struct hdr_output_metadata {
> > };
> > };
> >
> > +/*
> > + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means
> the LUT
> > + * can be used for either purpose, but not simultaneously. To expose
> > + * modes that support gamma and degamma simultaneously the gamma mode
> > + * must declare distinct DRM_MODE_LUT_GAMMA and
> DRM_MODE_LUT_DEGAMMA
> > + * ranges.
> > + */
> > +/* LUT is for gamma (after CTM) */
> > +#define DRM_MODE_LUT_GAMMA BIT(0)
> > +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
> > +BIT(1)
> > +/* linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(2)
> > +/*
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> > +/* the curve must be non-decreasing */ #define
> > +DRM_MODE_LUT_NON_DECREASING BIT(4)
> > +/* the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> > +/* the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > +enum lut_type {
>
> Unprefixed type name in UAPI headers is probably not a good idea.
Ok, will rename these.
> > + LUT_TYPE_DEGAMMA = 0,
> > + LUT_TYPE_GAMMA = 1,
> > +};
>
> All the above stuff seems to be the same in your other patch series'
> patch "[PATCH 1/9] drm: Add gamma mode property". Is this series replacing the
> series "[PATCH 0/9] Enhance pipe color support for multi segmented luts" or
> what
> does this mean?
The concept and idea is similar and the range definition is also common. But
this series
focuses on plane color management while the other one is for pipe/crtc color
features.
Hence separated and floated them as unique series for review.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > +
> > +/*
> > + * Creating 64 bit palette entries for better data
> > + * precision. This will be required for HDR and
> > + * similar color processing usecases.
> > + */
> > +struct drm_color_lut_ext {
> > + /*
> > +* Data is U32.32 fixed point format.
> > +*/
> > + __u64 red;
> > + __u64 green;
> > + __u64 blue;
> > + __u64 reserved;
> > +};
> > +
> > #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
> > DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
> > DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/21] Add Support for Plane Color Lut and CSC features
> -Original Message- > From: Pekka Paalanen > Sent: Wednesday, June 2, 2021 2:59 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, > Bhanuprakash ; Harry Wentland > > Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features > > On Tue, 1 Jun 2021 16:21:57 +0530 > Uma Shankar wrote: > > > This is how a typical display color hardware pipeline looks like: > > +---+ > > |RAM| > > | +--++-++-+ | > > | | FB 1 || FB 2 || FB N| | > > | +--++-++-+ | > > +---+ > >| Plane Color Hardware Block | > > ++ > > | +---v-+ +---v---+ +---v--+ | > > | | Plane A | | Plane B | | Plane N | | > > | | DeGamma | | Degamma | | Degamma | | > > | +---+-+ +---+---+ +---+--+ | > > | | | || > > | +---v-+ +---v---+ +---v--+ | > > | |Plane A | | Plane B | | Plane N | | > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > | +---v-+ +v--+ +v-+ | > > | | Plane A | | Plane B | | Plane N | | > > | | Gamma | | Gamma | | Gamma| | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > ++ > > +--v--v---v---| > > || || > > || Pipe Blender|| > > +++ > > ||| > > |+---v--+ | > > || Pipe DeGamma| | > > || | | > > |+---+--+ | > > ||Pipe Color | > > |+---v--+ Hardware| > > || Pipe CSC/CTM| | > > || | | > > |+---+--+ | > > ||| > > |+---v--+ | > > || Pipe Gamma | | > > || | | > > |+---+--+ | > > ||| > > +-+ > > | > > v > >Pipe Output > > Hi, > > this is an excellent picture. I have long been wanting schematics like that > in the DRM > UAPI documentation. Another note on that: > https://lists.freedesktop.org/archives/dri-devel/2021-May/307310.html > > But the schematic for DRM UAPI documentation needs to be written in terms of > the > abstract KMS pipeline with property names spelled out, like in what Ville > sketched in > that email. Sure Pekka, I can add that. > > This patch series adds properties for plane color features. It adds > > properties for degamma used to linearize data and CSC used for gamut > > conversion. It also includes Gamma support used to again non-linearize > > data as per panel supported color space. These can be utilize by user > > space to convert planes from one format to another, one color space to > > another etc. > > This is very much welcome! > > There is also the thread: > https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html > > Everything mentioned will interact with each other by changing what the > abstract > KMS pixel pipeline does. I think you and Harry should probably look at each > others' > suggestions and see how to fit them all into a single abstract KMS pipeline. > > People are adding new pieces into KMS left and right, and I fear we lose > sight of how > everything will actually work together when all KMS properties are supposed > to be > generic and potentially present simultaneously. This is why I would very much > like to > have that *whole* abstract KMS pipeline documented with *everything*. > Otherwise > it is coming really hard fast to figure out how generic userspace should use > all these > KMS properties together. > > Or if there cannot be a single abstract KMS pipeline, then sure, have > multiple, as long > as they are documented and how userspace will know which pipeline it is > dealing > with, and what things are mutually exclusive so we can avoid writing > userspace code > for combinations that will never exist. This is a good suggestion to have the whole pipeline and properties documented along with the exact usages. We may end with 2
Re: [Intel-gfx] [PATCH 1/9] drm: Add gamma mode property
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, June 2, 2021 2:40 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem,
> Bhanuprakash
> Subject: Re: [PATCH 1/9] drm: Add gamma mode property
>
> On Tue, 1 Jun 2021 16:11:27 +0530
> Uma Shankar wrote:
>
> > Add a gamma mode property to enable various kind of gamma modes
> > supported by platforms like: Interpolated, Split, Multi Segmented,
> > Logarithmic etc. Userspace can get this property and should be able to
> > get the platform capabilities wrt various gamma modes possible and the
> > possible ranges.
> >
> > It can select one of the modes exposed as blob_id as an enum and set
> > the respective mode.
> >
> > It can then create the LUT and send it to driver using already
> > available GAMMA_LUT property as blob.
> >
> > Note: This is based on design by Ville and is being carried forward
> > based on his original idea.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 5 +++
> > drivers/gpu/drm/drm_color_mgmt.c | 75 +++
> > include/drm/drm_color_mgmt.h | 8
> > include/drm/drm_crtc.h| 14 ++
> > include/uapi/drm/drm_mode.h | 43 ++
> > 5 files changed, 145 insertions(+)
> >
>
> ...
>
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 13eeba2a750a..b1eead03ebe8 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -262,6 +262,13 @@ struct drm_crtc_state {
> > */
> > struct drm_property_blob *mode_blob;
> >
> > + /**
> > +* @gamma_mode: This is a blob_id and exposes the platform capabilities
> > +* wrt to various gamma modes and the respective lut ranges. This also
> > +* helps user select a gamma mode amongst the supported ones.
> > +*/
> > + u32 gamma_mode;
> > +
> > /**
> > * @degamma_lut:
> > *
> > @@ -1096,6 +1103,13 @@ struct drm_crtc {
> > */
> > struct drm_property *scaling_filter_property;
> >
> > + /**
> > +* @gamma_mode_property: Optional CRTC property to enumerate and
> > +* select the mode of the crtc gamma/degmama LUTs. This also exposes
> > +* the lut ranges of the various supported gamma modes to userspace.
> > +*/
> > + struct drm_property *gamma_mode_property;
> > +
> > /**
> > * @state:
> > *
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 9b6722d45f36..d7758d351936 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -819,6 +819,49 @@ struct hdr_output_metadata {
> > };
> > };
> >
> > +/*
> > + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means
> the LUT
> > + * can be used for either purpose, but not simultaneously. To expose
> > + * modes that support gamma and degamma simultaneously the gamma mode
> > + * must declare distinct DRM_MODE_LUT_GAMMA and
> DRM_MODE_LUT_DEGAMMA
> > + * ranges.
> > + */
> > +/* LUT is for gamma (after CTM) */
> > +#define DRM_MODE_LUT_GAMMA BIT(0)
> > +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
> > +BIT(1)
> > +/* linearly interpolate between the points */ #define
> > +DRM_MODE_LUT_INTERPOLATE BIT(2)
> > +/*
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> > +/* the curve must be non-decreasing */ #define
> > +DRM_MODE_LUT_NON_DECREASING BIT(4)
> > +/* the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> > +/* the same curve (red) is used for blue and green channels as well
> > +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > +enum lut_type {
> > + LUT_TYPE_DEGAMMA = 0,
> > + LUT_TYPE_GAMMA = 1,
> > +};
> > +
> > #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
> > DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
> > DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>
> Hi,
>
> where is the UAPI documentation for this new GAMMA_MODE?
> As a userspace dev, I have no idea what to do with the above based on what's
> written here.
Got that, I will add more details on the UAPI usage to make things a bit
clearer.
> Also, reading the description of DRM_CLIENT_CAP_ADVANCE_GAMMA_MODES in
> patch 5/9, what difference does it make whether userspace sets or does not
> set that
> cap? I don't understand the implications from the description.
The reason we have this Client caps is to have it co-exist with legacy crtc
color properties.
The idea is that driver will
Re: [Intel-gfx] [PATCH 5/9] drm: Add Client Cap for advance gamma mode
> -Original Message-
> From: Pekka Paalanen
> Sent: Wednesday, June 2, 2021 2:33 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem,
> Bhanuprakash
> Subject: Re: [PATCH 5/9] drm: Add Client Cap for advance gamma mode
>
> On Tue, 1 Jun 2021 16:11:31 +0530
> Uma Shankar wrote:
>
> > Introduced a client cap for advance cap mode capability. Userspace
>
> Typo: "cap mode" should be "gamma mode"?
Yeah, will fix this.
> > should set this to get to be able to use the new gamma_mode property.
> >
> > If this is not set, driver will work in legacy mode.
> >
> > Note: This is suggested by Ville and based on his idea, the new gamma
> > mode handling is designed.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
> > drivers/gpu/drm/drm_ioctl.c | 5 +
> > include/drm/drm_atomic.h | 1 +
> > include/drm/drm_crtc.h| 8
> > include/drm/drm_file.h| 8
> > include/uapi/drm/drm.h| 8
> > 6 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a5470a0ebbe6..7ee35bc14455 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -1036,6 +1036,8 @@ int drm_atomic_set_property(struct drm_atomic_state
> *state,
> > break;
> > }
> >
> > + crtc_state->advance_gamma_mode_active =
> > + state->advance_gamma_mode_active;
> > ret = drm_atomic_crtc_set_property(crtc,
> > crtc_state, prop, prop_value);
> > break;
> > @@ -1372,6 +1374,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > drm_modeset_acquire_init(,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > state->acquire_ctx =
> > state->allow_modeset = !!(arg->flags &
> > DRM_MODE_ATOMIC_ALLOW_MODESET);
> > + state->advance_gamma_mode_active =
> > +file_priv->advance_gamma_mode_active;
> >
> > retry:
> > copied_objs = 0;
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 53d314103a37..d51f72213882 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -361,6 +361,11 @@ drm_setclientcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> > return -EINVAL;
> > file_priv->writeback_connectors = req->value;
> > break;
> > + case DRM_CLIENT_CAP_ADVANCE_GAMMA_MODES:
> > + if (req->value > 1)
> > + return -EINVAL;
> > + file_priv->advance_gamma_mode_active = req->value;
> > + break;
> > default:
> > return -EINVAL;
> > }
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index
> > ac5a28eff2c8..5a398a249c80 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -379,6 +379,7 @@ struct drm_atomic_state {
> > * states.
> > */
> > bool duplicated : 1;
> > + bool advance_gamma_mode_active : 1;
>
> "advance" is a verb. Did you mean "advanced"?
Right, will rename it.
>
> > struct __drm_planes_state *planes;
> > struct __drm_crtcs_state *crtcs;
> > int num_connector;
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 5a594f134a81..f4339fbad086 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -170,6 +170,11 @@ struct drm_crtc_state {
> > */
> > bool color_mgmt_changed : 1;
> >
> > + /**
> > +* This is to indicate advance gamma mode support
> > +*/
> > + bool advance_gamma_mode_active : 1;
>
> Same here.
>
> > +
> > /**
> > * @no_vblank:
> > *
> > @@ -1036,6 +1041,9 @@ struct drm_crtc {
> > */
> > bool enabled;
> >
> > + /** To handle advance gamma mode support */
> > + bool advance_gamma_mode_active : 1;
>
> Same here.
>
> > +
> > /**
> > * @mode:
> > *
> > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h index
> > b81b3bfb08c8..4af3e1a2a158 100644
> > --- a/include/drm/drm_file.h
> > +++ b/include/drm/drm_file.h
> > @@ -201,6 +201,14 @@ struct drm_file {
> > */
> > bool writeback_connectors;
> >
> > + /**
> > +* This is to enable advance gamma modes using
> > +* gamma_mode property
> > +*
> > +* True if client understands advance gamma
> > +*/
> > + bool advance_gamma_mode_active : 1;
>
> Same here.
>
> > +
> > /**
> > * @was_master:
> > *
> > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index
> > 67b94bc3c885..661efdf0c969 100644
> > --- a/include/uapi/drm/drm.h
> > +++ b/include/uapi/drm/drm.h
> > @@ -816,6 +816,14 @@ struct drm_get_cap {
> > */
> > #define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS5
> >
> > +/**
> > + * Add support for advance gamma mode UAPI
> >
[Intel-gfx] ✓ Fi.CI.BAT: success for Finish conversion to GRAPHICS_VER (rev2)
== Series Details ==
Series: Finish conversion to GRAPHICS_VER (rev2)
URL : https://patchwork.freedesktop.org/series/90693/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10161 -> Patchwork_20267
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/index.html
Known issues
Here are the changes found in Patchwork_20267 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([i915#2782])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@core_auth@basic-auth:
- fi-kbl-soraka: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-kbl-soraka/igt@core_a...@basic-auth.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/fi-kbl-soraka/igt@core_a...@basic-auth.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-cfl-8109u: [INCOMPLETE][5] ([i915#3462]) -> [DMESG-FAIL][6]
([i915#3462])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-cfl-8109u: [FAIL][7] ([i915#3363]) -> [FAIL][8] ([i915#2426] /
[i915#3363])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-cfl-8109u/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/fi-cfl-8109u/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][9] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][10] ([i915#1436] / [i915#3363])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-kbl-guc/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/fi-kbl-guc/igt@run...@aborted.html
- fi-cml-s: [FAIL][11] ([i915#3363] / [i915#3462]) -> [FAIL][12]
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-cml-s/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/fi-cml-s/igt@run...@aborted.html
- fi-kbl-7567u: [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][14] ([i915#1436] / [i915#3363])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-kbl-7567u/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20267/fi-kbl-7567u/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
[i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
[i915#3537]: https://gitlab.freedesktop.org/drm/intel/issues/3537
Participating hosts (46 -> 42)
--
Additional (1): fi-tgl-1115g4
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10161 -> Patchwork_20267
CI-20190529: 20190529
CI_DRM_10161: 6ce32fba8fd6caa0cd3ea578b35f76d188ebb155 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6098: 1fbc1e7d602f96a7f4e2b95057eef994656b8e74 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_20267: 9b9588997cc1ab0a4a721da8423f9df309d81a58 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9b9588997cc1 drm/i915/display: replace IS_GEN() in commented code
ec1b90386e0e drm/i915: Add remaining conversions to GRAPHICS_VER
d643dfea6a80 drm/i915: replace IS_GEN and friends with GRAPHICS_VER
20ae50b78d4f drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER
dfbb5b2242e5 drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER
01c557094c93 drm/i915/gt: Add remaining conversions to GRAPHICS_VER
6ec9c3d188bc drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER
== Logs ==
For more details see:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Finish conversion to GRAPHICS_VER (rev2)
== Series Details == Series: Finish conversion to GRAPHICS_VER (rev2) URL : https://patchwork.freedesktop.org/series/90693/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Finish conversion to GRAPHICS_VER (rev2)
== Series Details == Series: Finish conversion to GRAPHICS_VER (rev2) URL : https://patchwork.freedesktop.org/series/90693/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6ec9c3d188bc drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER -:2330: WARNING:LONG_LINE: line length of 112 exceeds 100 columns #2330: FILE: drivers/gpu/drm/i915/gt/selftest_llc.c:47: + intel_gpu_freq(rps, gpu_freq * (GRAPHICS_VER(i915) >= 9 ? GEN9_FREQ_SCALER : 1)), -:2339: WARNING:LONG_LINE: line length of 112 exceeds 100 columns #2339: FILE: drivers/gpu/drm/i915/gt/selftest_llc.c:57: + intel_gpu_freq(rps, gpu_freq * (GRAPHICS_VER(i915) >= 9 ? GEN9_FREQ_SCALER : 1)), total: 0 errors, 2 warnings, 0 checks, 2260 lines checked 01c557094c93 drm/i915/gt: Add remaining conversions to GRAPHICS_VER dfbb5b2242e5 drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER 20ae50b78d4f drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER d643dfea6a80 drm/i915: replace IS_GEN and friends with GRAPHICS_VER -:154: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #154: FILE: drivers/gpu/drm/i915/i915_debugfs.c:500: + (gt_perf_status & (GRAPHICS_VER(dev_priv) >= 9 ? 0x1ff00 : 0xff00)) >> 8); total: 0 errors, 1 warnings, 0 checks, 1352 lines checked ec1b90386e0e drm/i915: Add remaining conversions to GRAPHICS_VER -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #24: FILE: drivers/gpu/drm/i915/i915_drv.h:1572: +#define IS_GEN9_LP(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv)) -:25: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #25: FILE: drivers/gpu/drm/i915/i915_drv.h:1573: +#define IS_GEN9_BC(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && !IS_LP(dev_priv)) -:60: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #60: FILE: drivers/gpu/drm/i915/i915_drv.h:1640: +#define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \ IS_GEMINILAKE(dev_priv) || \ IS_KABYLAKE(dev_priv)) -:70: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #70: FILE: drivers/gpu/drm/i915/i915_drv.h:1647: +#define HAS_128_BYTE_Y_TILING(dev_priv) (GRAPHICS_VER(dev_priv) != 2 && \ +!(IS_I915G(dev_priv) || IS_I915GM(dev_priv))) -:79: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #79: FILE: drivers/gpu/drm/i915/i915_drv.h:1654: +#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && GRAPHICS_VER(dev_priv) >= 7) total: 0 errors, 0 warnings, 5 checks, 207 lines checked 9b9588997cc1 drm/i915/display: replace IS_GEN() in commented code ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/7] drm/i915: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_cmd_parser.c| 10 +--
drivers/gpu/drm/i915/i915_debugfs.c | 32
drivers/gpu/drm/i915/i915_drv.c | 20 ++---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 80 +--
drivers/gpu/drm/i915/i915_irq.c | 34
drivers/gpu/drm/i915/i915_perf.c | 44 +-
drivers/gpu/drm/i915/i915_pmu.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 4 +-
drivers/gpu/drm/i915/i915_suspend.c | 16 ++--
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 22 ++---
drivers/gpu/drm/i915/intel_dram.c | 14 ++--
drivers/gpu/drm/i915/intel_pch.c | 10 +--
drivers/gpu/drm/i915/intel_pm.c | 14 ++--
drivers/gpu/drm/i915/intel_sideband.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 26 +++---
drivers/gpu/drm/i915/intel_wopcm.c| 10 +--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_perf.c| 6 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 8 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 12 +--
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +-
24 files changed, 193 insertions(+), 193 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5b4b2bd46e7c..3992c25a191d 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -946,8 +946,8 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
int cmd_table_count;
int ret;
- if (!IS_GEN(engine->i915, 7) && !(IS_GEN(engine->i915, 9) &&
- engine->class == COPY_ENGINE_CLASS))
+ if (GRAPHICS_VER(engine->i915) != 7 && !(GRAPHICS_VER(engine->i915) ==
9 &&
+engine->class ==
COPY_ENGINE_CLASS))
return 0;
switch (engine->class) {
@@ -977,7 +977,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
break;
case COPY_ENGINE_CLASS:
engine->get_cmd_length_mask = gen7_blt_get_cmd_length_mask;
- if (IS_GEN(engine->i915, 9)) {
+ if (GRAPHICS_VER(engine->i915) == 9) {
cmd_tables = gen9_blt_cmd_table;
cmd_table_count = ARRAY_SIZE(gen9_blt_cmd_table);
engine->get_cmd_length_mask =
@@ -993,7 +993,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
cmd_table_count = ARRAY_SIZE(gen7_blt_cmd_table);
}
- if (IS_GEN(engine->i915, 9)) {
+ if (GRAPHICS_VER(engine->i915) == 9) {
engine->reg_tables = gen9_blt_reg_tables;
engine->reg_table_count =
ARRAY_SIZE(gen9_blt_reg_tables);
@@ -1537,7 +1537,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs
*engine,
if (IS_HASWELL(engine->i915))
flags = MI_BATCH_NON_SECURE_HSW;
- GEM_BUG_ON(!IS_GEN_RANGE(engine->i915, 6, 7));
+ GEM_BUG_ON(!IS_GRAPHICS_VER(engine->i915, 6,
7));
__gen6_emit_bb_start(batch_end,
batch_addr,
flags);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a4d8a836bd57..0529576f069c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -361,7 +361,7 @@
[Intel-gfx] [PATCH v2 3/7] drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 8
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 16
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 12 ++--
.../drm/i915/gem/selftests/i915_gem_client_blt.c | 10 +-
.../drm/i915/gem/selftests/i915_gem_coherency.c | 4 ++--
.../drm/i915/gem/selftests/i915_gem_context.c| 16
.../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +++---
.../gpu/drm/i915/gem/selftests/igt_gem_utils.c | 10 +-
11 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 188dee13e017..7720b8c22c81 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1190,7 +1190,7 @@ static void set_ppgtt_barrier(void *data)
{
struct i915_address_space *old = data;
- if (INTEL_GEN(old->i915) < 8)
+ if (GRAPHICS_VER(old->i915) < 8)
gen6_ppgtt_unpin_all(i915_vm_to_ppgtt(old));
i915_vm_close(old);
@@ -1436,7 +1436,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
context->max_eus_per_subslice = user->max_eus_per_subslice;
/* Part specific restrictions. */
- if (IS_GEN(i915, 11)) {
+ if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
unsigned int req_s = hweight8(context->slice_mask);
@@ -1503,7 +1503,7 @@ static int set_sseu(struct i915_gem_context *ctx,
if (args->size < sizeof(user_sseu))
return -EINVAL;
- if (!IS_GEN(i915, 11))
+ if (GRAPHICS_VER(i915) != 11)
return -ENODEV;
if (copy_from_user(_sseu, u64_to_user_ptr(args->value),
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 297143511f99..24c0582e46fb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -500,7 +500,7 @@ eb_validate_vma(struct i915_execbuffer *eb,
* also covers all platforms with local memory.
*/
if (entry->relocation_count &&
- INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+ GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
return -EINVAL;
if (unlikely(entry->flags & eb->invalid_flags))
@@ -1439,7 +1439,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
{
- return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
+ return engine->class != VIDEO_DECODE_CLASS ||
GRAPHICS_VER(engine->i915) != 6;
}
static u32 *reloc_gpu(struct i915_execbuffer *eb,
@@ -1671,7 +1671,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
* batchbuffers.
*/
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
- IS_GEN(eb->i915, 6)) {
+ GRAPHICS_VER(eb->i915) == 6) {
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
@@ -2332,7 +2332,7 @@ static int i915_reset_gen7_sol_offsets(struct
i915_request *rq)
u32 *cs;
int i;
- if (!IS_GEN(rq->engine->i915, 7) || rq->engine->id != RCS0) {
+ if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {
drm_dbg(>engine->i915->drm, "sol reset is gen7/rcs
[Intel-gfx] [PATCH v2 7/7] drm/i915/display: replace IS_GEN() in commented code
Since we are replacing IS_GEN() with GRAPHICS_VER(), make sure we take
care of the comments as well.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_tv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
b/drivers/gpu/drm/i915/display/intel_tv.c
index ce73ebdfc669..aa52af7891f0 100644
--- a/drivers/gpu/drm/i915/display/intel_tv.c
+++ b/drivers/gpu/drm/i915/display/intel_tv.c
@@ -1307,7 +1307,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
* the active portion. Hence following this formula seems
* more trouble that it's worth.
*
-* if (IS_GEN(dev_priv, 4)) {
+* if (GRAPHICS_VER(dev_priv) == 4) {
* num = cdclk * (tv_mode->oversample >> !tv_mode->progressive);
* den = tv_mode->clock;
* } else {
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/7] drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Cc: intel-gvt-...@lists.freedesktop.org
Cc: Zhenyu Wang
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 8
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
drivers/gpu/drm/i915/gvt/fb_decoder.c | 10 +-
drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
drivers/gpu/drm/i915/gvt/handlers.c | 6 +++---
drivers/gpu/drm/i915/gvt/interrupt.c| 2 +-
drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-
drivers/gpu/drm/i915/gvt/scheduler.c| 4 ++--
drivers/gpu/drm/i915/gvt/vgpu.c | 4 ++--
9 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index ca9c9e27a43d..c4118b808268 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1006,7 +1006,7 @@ static int cmd_reg_handler(struct parser_exec_state *s,
* update reg values in it into vregs, so LRIs in workload with
* inhibit context will restore with correct values
*/
- if (IS_GEN(s->engine->i915, 9) &&
+ if (GRAPHICS_VER(s->engine->i915) == 9 &&
intel_gvt_mmio_is_sr_in_ctx(gvt, offset) &&
!strncmp(cmd, "lri", 3)) {
intel_gvt_hypervisor_read_gpa(s->vgpu,
@@ -1390,7 +1390,7 @@ static int gen8_check_mi_display_flip(struct
parser_exec_state *s,
if (!info->async_flip)
return 0;
- if (INTEL_GEN(s->engine->i915) >= 9) {
+ if (GRAPHICS_VER(s->engine->i915) >= 9) {
stride = vgpu_vreg_t(s->vgpu, info->stride_reg) & GENMASK(9, 0);
tile = (vgpu_vreg_t(s->vgpu, info->ctrl_reg) &
GENMASK(12, 10)) >> 10;
@@ -1418,7 +1418,7 @@ static int gen8_update_plane_mmio_from_mi_display_flip(
set_mask_bits(_vreg_t(vgpu, info->surf_reg), GENMASK(31, 12),
info->surf_val << 12);
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
set_mask_bits(_vreg_t(vgpu, info->stride_reg), GENMASK(9,
0),
info->stride_val);
set_mask_bits(_vreg_t(vgpu, info->ctrl_reg), GENMASK(12,
10),
@@ -1446,7 +1446,7 @@ static int decode_mi_display_flip(struct
parser_exec_state *s,
{
if (IS_BROADWELL(s->engine->i915))
return gen8_decode_mi_display_flip(s, info);
- if (INTEL_GEN(s->engine->i915) >= 9)
+ if (GRAPHICS_VER(s->engine->i915) >= 9)
return skl_decode_mi_display_flip(s, info);
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index d4f883f35b95..8e65cd8258b9 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -223,7 +223,7 @@ static struct drm_i915_gem_object *vgpu_create_gem(struct
drm_device *dev,
obj->read_domains = I915_GEM_DOMAIN_GTT;
obj->write_domain = 0;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
unsigned int tiling_mode = 0;
unsigned int stride = 0;
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
index 0889ad8291b0..11a8baba6822 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -151,7 +151,7 @@ static u32 intel_vgpu_get_stride(struct intel_vgpu *vgpu,
int pipe,
u32 stride_reg = vgpu_vreg_t(vgpu, DSPSTRIDE(pipe)) & stride_mask;
u32 stride = stride_reg;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
switch (tiled) {
case PLANE_CTL_TILED_LINEAR:
stride = stride_reg * 64;
@@ -215,7 +215,7 @@ int intel_vgpu_decode_primary_plane(struct intel_vgpu *vgpu,
if (!plane->enabled)
return -ENODEV;
- if (INTEL_GEN(dev_priv) >= 9) {
+
[Intel-gfx] [PATCH v2 0/7] Finish conversion to GRAPHICS_VER
Latest version of previous series "drm/i915: Extend GEN renames to the rest of the driver" (https://patchwork.freedesktop.org/series/88825/) dropped one patch converting all the instances of IS_GEN() and INTEL_GEN() to GRAPHICS_VER() due to the patches changing the meaning of the macros IS_GRAPHICS_VER/GRAPHICS_VER and removal of IS_GRAPHICS_RANGE(). I couldn't find a way to convince coccinelle to fix all places, so I just did it manually in separate commits the places that were not updated. Finish the conversion splitting the changes so it can go to the different branches (drm-intel-gt-next and drm-intel-next). I also split the gvt changes, but I think it would be easeir to take this directly on drm-intel-next. Also, please do not apply this series as I have other series I'd like to rebase on top before landing it. v2: update commit messages with the proper semantic patch (Matt Roper) and regenerate the patches to also convert changes that got added in between. Cc: intel-gvt-...@lists.freedesktop.org Cc: Zhenyu Wang Lucas De Marchi (7): drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER drm/i915/gt: Add remaining conversions to GRAPHICS_VER drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER drm/i915: replace IS_GEN and friends with GRAPHICS_VER drm/i915: Add remaining conversions to GRAPHICS_VER drm/i915/display: replace IS_GEN() in commented code drivers/gpu/drm/i915/display/intel_tv.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 +-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- .../gpu/drm/i915/gem/i915_gem_object_blt.c| 8 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 16 ++-- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 12 +-- .../i915/gem/selftests/i915_gem_client_blt.c | 10 +-- .../i915/gem/selftests/i915_gem_coherency.c | 4 +- .../drm/i915/gem/selftests/i915_gem_context.c | 16 ++-- .../drm/i915/gem/selftests/i915_gem_mman.c| 14 ++-- .../drm/i915/gem/selftests/igt_gem_utils.c| 10 +-- drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 40 +- drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 ++--- drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 +- .../drm/i915/gt/intel_execlists_submission.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 34 drivers/gpu/drm/i915/gt/intel_gt.c| 27 --- .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 +-- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +- drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_llc.c | 6 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +-- drivers/gpu/drm/i915/gt/intel_mocs.c | 8 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++-- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c | 14 ++-- .../gpu/drm/i915/gt/intel_ring_submission.c | 64 +++ drivers/gpu/drm/i915/gt/intel_rps.c | 60 +++--- drivers/gpu/drm/i915/gt/intel_sseu.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +++ drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 6 +- drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +- drivers/gpu/drm/i915/gt/selftest_llc.c| 4 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 +- drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +- drivers/gpu/drm/i915/gt/selftest_rc6.c| 4 +- .../drm/i915/gt/selftest_ring_submission.c| 6 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++-- drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +- drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +- drivers/gpu/drm/i915/gvt/fb_decoder.c | 10 +-- drivers/gpu/drm/i915/gvt/gtt.c| 4 +-
[Intel-gfx] [PATCH v2 6/7] drm/i915: Add remaining conversions to GRAPHICS_VER
For some reason coccinelle misses a few cases in header files with calls to INTEL_GEN()/IS_GEN(). Do a manual conversion for those. Signed-off-by: Lucas De Marchi Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/i915_drv.h | 35 - drivers/gpu/drm/i915/i915_reg.h | 26 2 files changed, 30 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 1cdd64116fce..64af94bdf497 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1568,9 +1568,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, (IS_ALDERLAKE_P(__i915) && \ IS_GT_STEP(__i915, since, until)) -#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) -#define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv)) -#define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv)) +#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) +#define IS_GEN9_LP(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv)) +#define IS_GEN9_BC(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && !IS_LP(dev_priv)) #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id)) #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id) @@ -1590,12 +1590,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, * The Gen7 cmdparser copies the scanned buffer to the ggtt for execution * All later gens can run the final buffer from the ppgtt */ -#define CMDPARSER_USES_GGTT(dev_priv) IS_GEN(dev_priv, 7) +#define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7) #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) #define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop) #define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb) -#define HAS_SECURE_BATCHES(dev_priv) (INTEL_GEN(dev_priv) < 6) +#define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6) #define HAS_WT(dev_priv) HAS_EDRAM(dev_priv) #define HWS_NEEDS_PHYSICAL(dev_priv) (INTEL_INFO(dev_priv)->hws_needs_physical) @@ -1628,7 +1628,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || IS_I845G(dev_priv)) #define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv) \ - (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9)) + (IS_BROADWELL(dev_priv) || GRAPHICS_VER(dev_priv) == 9) /* WaRsDisableCoarsePowerGating:skl,cnl */ #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \ @@ -1636,23 +1636,22 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, IS_SKL_GT3(dev_priv) ||\ IS_SKL_GT4(dev_priv)) -#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4) -#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \ +#define HAS_GMBUS_IRQ(dev_priv) (GRAPHICS_VER(dev_priv) >= 4) +#define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \ IS_GEMINILAKE(dev_priv) || \ IS_KABYLAKE(dev_priv)) /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte * rows, which changed the alignment requirements and fence programming. */ -#define HAS_128_BYTE_Y_TILING(dev_priv) (!IS_GEN(dev_priv, 2) && \ -!(IS_I915G(dev_priv) || \ -IS_I915GM(dev_priv))) +#define HAS_128_BYTE_Y_TILING(dev_priv) (GRAPHICS_VER(dev_priv) != 2 && \ +!(IS_I915G(dev_priv) || IS_I915GM(dev_priv))) #define SUPPORTS_TV(dev_priv) (INTEL_INFO(dev_priv)->display.supports_tv) #define I915_HAS_HOTPLUG(dev_priv) (INTEL_INFO(dev_priv)->display.has_hotplug) -#define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2) +#define HAS_FW_BLC(dev_priv) (GRAPHICS_VER(dev_priv) > 2) #define HAS_FBC(dev_priv) (INTEL_INFO(dev_priv)->display.has_fbc) -#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && INTEL_GEN(dev_priv) >= 7) +#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && GRAPHICS_VER(dev_priv) >= 7) #define HAS_IPS(dev_priv) (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv)) @@ -1663,7 +1662,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr) #define HAS_PSR_HW_TRACKING(dev_priv) \ (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking) -#define HAS_PSR2_SEL_FETCH(dev_priv)(INTEL_GEN(dev_priv) >= 12) +#define HAS_PSR2_SEL_FETCH(dev_priv)(GRAPHICS_VER(dev_priv) >= 12) #define HAS_TRANSCODER(dev_priv, trans) ((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0) #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)->has_rc6) @@ -1674,7 +1673,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_DMC(dev_priv)
[Intel-gfx] [PATCH v2 2/7] drm/i915/gt: Add remaining conversions to GRAPHICS_VER
For some reason coccinelle misses a few cases in gt with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 0389bceebd06..4270b5a34a83 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -230,7 +230,7 @@ static int drpc_show(struct seq_file *m, void *unused)
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
err = vlv_drpc(m);
- else if (INTEL_GEN(i915) >= 6)
+ else if (GRAPHICS_VER(i915) >= 6)
err = gen6_drpc(m);
else
err = ilk_drpc(m);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9ef349cd5cea..e113f93b3274 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -606,10 +606,10 @@ intel_engine_has_relative_mmio(const struct
intel_engine_cs * const engine)
}
#define instdone_has_slice(dev_priv___, sseu___, slice___) \
- ((IS_GEN(dev_priv___, 7) ? 1 : ((sseu___)->slice_mask)) & BIT(slice___))
+ ((GRAPHICS_VER(dev_priv___) == 7 ? 1 : ((sseu___)->slice_mask)) &
BIT(slice___))
#define instdone_has_subslice(dev_priv__, sseu__, slice__, subslice__) \
- (IS_GEN(dev_priv__, 7) ? (1 & BIT(subslice__)) : \
+ (GRAPHICS_VER(dev_priv__) == 7 ? (1 & BIT(subslice__)) : \
intel_sseu_has_subslice(sseu__, 0, subslice__))
#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
index 51780282d872..714fe8495775 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
@@ -248,7 +248,7 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
struct sseu_dev_info sseu;
intel_wakeref_t wakeref;
- if (INTEL_GEN(i915) < 8)
+ if (GRAPHICS_VER(i915) < 8)
return -ENODEV;
seq_puts(m, "SSEU Device Info\n");
@@ -265,9 +265,9 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
cherryview_sseu_device_status(gt, );
else if (IS_BROADWELL(i915))
bdw_sseu_device_status(gt, );
- else if (IS_GEN(i915, 9))
+ else if (GRAPHICS_VER(i915) == 9)
gen9_sseu_device_status(gt, );
- else if (INTEL_GEN(i915) >= 10)
+ else if (GRAPHICS_VER(i915) >= 10)
gen10_sseu_device_status(gt, );
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/7] drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 38 +--
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 +++
.../drm/i915/gt/intel_execlists_submission.c | 18 ++---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 ++---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 34 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 27
.../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 ++--
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +-
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++--
drivers/gpu/drm/i915/gt/intel_llc.c | 6 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 46 ++---
drivers/gpu/drm/i915/gt/intel_mocs.c | 8 +--
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +-
drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 14 ++--
.../gpu/drm/i915/gt/intel_ring_submission.c | 64 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 60 -
drivers/gpu/drm/i915/gt/intel_sseu.c | 14 ++--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +--
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 6 +-
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_llc.c| 4 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 +--
drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_rc6.c| 4 +-
.../drm/i915/gt/selftest_ring_submission.c| 6 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 +--
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
44 files changed, 324 insertions(+), 323 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index d4f4452ce5ed..0389bceebd06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -85,14 +85,14 @@ static int gen6_drpc(struct seq_file *m)
gt_core_status = intel_uncore_read_fw(uncore, GEN6_GT_CORE_STATUS);
rcctl1 = intel_uncore_read(uncore, GEN6_RC_CONTROL);
- if (INTEL_GEN(i915) >= 9) {
+ if (GRAPHICS_VER(i915) >= 9) {
gen9_powergate_enable =
intel_uncore_read(uncore, GEN9_PG_ENABLE);
gen9_powergate_status =
intel_uncore_read(uncore, GEN9_PWRGT_DOMAIN_STATUS);
}
- if (INTEL_GEN(i915) <= 7)
+ if (GRAPHICS_VER(i915) <= 7)
sandybridge_pcode_read(i915, GEN6_PCODE_READ_RC6VIDS,
, NULL);
@@ -100,7 +100,7 @@ static int gen6_drpc(struct seq_file *m)
yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
seq_printf(m, "RC6 Enabled: %s\n",
yesno(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
- if (INTEL_GEN(i915) >= 9) {
+ if (GRAPHICS_VER(i915) >= 9) {
seq_printf(m, "Render Well Gating Enabled: %s\n",
Re: [Intel-gfx] [PATCH v4 02/17] mei: pxp: export pavp client to me client bus
On Mon, May 24, 2021 at 10:47:48PM -0700, Daniele Ceraolo Spurio wrote:
> From: Vitaly Lubart
>
> Export PAVP client to work with i915 driver,
> for binding it uses kernel component framework.
>
> Signed-off-by: Vitaly Lubart
> Signed-off-by: Tomas Winkler
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/misc/mei/Kconfig | 2 +
> drivers/misc/mei/Makefile | 1 +
> drivers/misc/mei/pxp/Kconfig | 13 ++
> drivers/misc/mei/pxp/Makefile | 7 +
> drivers/misc/mei/pxp/mei_pxp.c | 233 +
> drivers/misc/mei/pxp/mei_pxp.h | 18 +++
> 6 files changed, 274 insertions(+)
> create mode 100644 drivers/misc/mei/pxp/Kconfig
> create mode 100644 drivers/misc/mei/pxp/Makefile
> create mode 100644 drivers/misc/mei/pxp/mei_pxp.c
> create mode 100644 drivers/misc/mei/pxp/mei_pxp.h
>
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
> index f5fd5b786607..0e0bcd0da852 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -47,3 +47,5 @@ config INTEL_MEI_TXE
> Intel Bay Trail
>
> source "drivers/misc/mei/hdcp/Kconfig"
> +source "drivers/misc/mei/pxp/Kconfig"
> +
> diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
> index f1c76f7ee804..d8e5165917f2 100644
> --- a/drivers/misc/mei/Makefile
> +++ b/drivers/misc/mei/Makefile
> @@ -26,3 +26,4 @@ mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
> CFLAGS_mei-trace.o = -I$(src)
>
> obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
> +obj-$(CONFIG_INTEL_MEI_PXP) += pxp/
> diff --git a/drivers/misc/mei/pxp/Kconfig b/drivers/misc/mei/pxp/Kconfig
> new file mode 100644
> index ..4029b96afc04
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Kconfig
> @@ -0,0 +1,13 @@
> +
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
> +#
s> +config INTEL_MEI_PXP
> + tristate "Intel PXP services of ME Interface"
> + select INTEL_MEI_ME
> + depends on DRM_I915
> + help
> + MEI Support for PXP Services on Intel platforms.
> +
> + Enables the ME FW services required for PXP support through
> + I915 display driver of Intel.
> diff --git a/drivers/misc/mei/pxp/Makefile b/drivers/misc/mei/pxp/Makefile
> new file mode 100644
> index ..0329950d5794
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Copyright (c) 2020, Intel Corporation. All rights reserved.
> +#
> +# Makefile - PXP client driver for Intel MEI Bus Driver.
> +
> +obj-$(CONFIG_INTEL_MEI_PXP) += mei_pxp.o
> diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
> new file mode 100644
> index ..cacfbedb640a
> --- /dev/null
> +++ b/drivers/misc/mei/pxp/mei_pxp.c
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +/**
> + * DOC: MEI_PXP Client Driver
> + *
> + * The mei_pxp driver acts as a translation layer between PXP
> + * protocol implementer (I915) and ME FW by translating PXP
> + * negotiation messages to ME FW command payloads and vice versa.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mei_pxp.h"
> +
> +/**
> + * mei_pxp_send_message() - Sends a PXP message to ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @message: a message buffer to send
> + * @size: size of the message
> + * Return: 0 on Success, <0 on Failure
> + */
> +static int
> +mei_pxp_send_message(struct device *dev, const void *message, size_t size)
> +{
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !message)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + /* temporary drop const qualifier till the API is fixed */
> + byte = mei_cldev_send(cldev, (u8 *)message, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * mei_pxp_receive_message() - Receives a PXP message from ME FW.
> + * @dev: device corresponding to the mei_cl_device
> + * @buffer: a message buffer to contain the received message
> + * @size: size of the buffer
> + * Return: bytes sent on Success, <0 on Failure
> + */
> +static int
> +mei_pxp_receive_message(struct device *dev, void *buffer, size_t size)
> +{
> + struct mei_cl_device *cldev;
> + ssize_t byte;
> +
> + if (!dev || !buffer)
> + return -EINVAL;
> +
> + cldev = to_mei_cl_device(dev);
> +
> + byte = mei_cldev_recv(cldev, buffer, size);
> + if (byte < 0) {
> + dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
> + return byte;
> + }
> +
> + return byte;
> +}
> +
> +static const struct i915_pxp_component_ops mei_pxp_ops = {
> + .owner = THIS_MODULE,
> + .send =
Re: [Intel-gfx] [PATCH v4 16/17] drm/i915/pxp: black pixels on pxp disabled
On Mon, May 24, 2021 at 10:48:02PM -0700, Daniele Ceraolo Spurio wrote:
> From: Anshuman Gupta
>
> When protected sufaces has flipped and pxp session is disabled,
> display black pixels by using plane color CTM correction.
>
> v2:
> - Display black pixels in async flip too.
>
> v3:
> - Removed the black pixels logic for async flip. [Ville]
> - Used plane state to force black pixels. [Ville]
>
> v4 (Daniele): update pxp_is_borked check.
>
> Cc: Ville Syrjälä
> Cc: Gaurav Kumar
> Cc: Shankar Uma
> Signed-off-by: Anshuman Gupta
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 13 +-
> .../drm/i915/display/intel_display_types.h| 3 ++
> .../drm/i915/display/skl_universal_plane.c| 36 ++-
> drivers/gpu/drm/i915/i915_reg.h | 46 +++
> 4 files changed, 95 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 88b3272c0b00..44d7a5072090 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -392,6 +392,11 @@ static int bo_has_valid_encryption(const struct
> drm_i915_gem_object *obj)
> intel_pxp_is_active(>gt.pxp);
> }
>
> +static bool pxp_is_borked(const struct drm_i915_gem_object *obj)
> +{
> + return i915_gem_object_is_protected(obj) &&
> !bo_has_valid_encryption(obj);
> +}
> +
> int intel_plane_atomic_check(struct intel_atomic_state *state,
>struct intel_plane *plane)
> {
> @@ -424,10 +429,14 @@ int intel_plane_atomic_check(struct intel_atomic_state
> *state,
> crtc);
>
> fb = new_plane_state->hw.fb;
> - if (fb)
> + if (fb) {
> new_plane_state->decrypt =
> bo_has_valid_encryption(intel_fb_obj(fb));
> - else
> + new_plane_state->force_black = pxp_is_borked(intel_fb_obj(fb));
> +
> + } else {
> new_plane_state->decrypt = old_plane_state->decrypt;
> + new_plane_state->force_black = old_plane_state->force_black;
> + }
>
> new_plane_state->uapi.visible = false;
> if (!new_crtc_state)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 6b5dab9e1c40..88c0b882b844 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -624,6 +624,9 @@ struct intel_plane_state {
> /* Plane pxp decryption state */
> bool decrypt;
>
> + /* Plane state to display black pixels when pxp is borked */
> + bool force_black;
> +
> /* plane control register */
> u32 ctl;
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 2c8e88e8ad83..d4eb43b96ffd 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -975,6 +975,33 @@ static u32 skl_surf_address(const struct
> intel_plane_state *plane_state,
> }
> }
>
> +static void intel_load_plane_csc_black(struct intel_plane *intel_plane)
> +{
> + struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
> + enum pipe pipe = intel_plane->pipe;
> + enum plane_id plane = intel_plane->id;
> + u16 postoff = 0;
> +
> + drm_dbg_kms(_priv->drm, "plane color CTM to black %s:%d\n",
> + intel_plane->base.name, plane);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0), postoff);
> + intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1), postoff);
> + intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2), postoff);
> +}
> +
> static void
> skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -1088,14 +1115,21 @@ skl_program_plane(struct intel_plane *plane,
>*/
> intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> plane_surf = intel_plane_ggtt_offset(plane_state) + surf_addr;
> + plane_color_ctl = intel_de_read_fw(dev_priv, PLANE_COLOR_CTL(pipe,
>
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin
wrote:
> On 25/05/2021 17:45, Matthew Brost wrote:
> > On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote:
> >> * Context pinning code with it's magical two adds, subtract and cmpxchg
> >> is
> >> dodgy as well.
> >
> > Daniele tried to remove this and it proved quite difficult + created
> > even more races in the backend code. This was prior to the pre-pin and
> > post-unpin code which makes this even more difficult to fix as I believe
> > these functions would need to be removed first. Not saying we can't
> > revisit this someday but I personally really like it - it is a clever
> > way to avoid reentering the pin / unpin code while asynchronous things
> > are happening rather than some complex locking scheme. Lastly, this code
> > has proved incredibly stable as I don't think we've had to fix a single
> > thing in this area since we've been using this code internally.
>
> Pretty much same as above. The code like:
>
> static inline void __intel_context_unpin(struct intel_context *ce)
> {
> if (!ce->ops->sched_disable) {
> __intel_context_do_unpin(ce, 1);
> } else {
> while (!atomic_add_unless(>pin_count, -1, 1)) {
> if (atomic_cmpxchg(>pin_count, 1, 2) == 1) {
> ce->ops->sched_disable(ce);
> break;
> }
> }
> }
> }
>
> That's pretty much impenetrable for me and the only thing I can think of
> here is **ALARM** must be broken! See what others think..
pin_count is a hand-rolled mutex, except not actually a real one, and
it's absolutely hiliarous in it's various incarnations (there's one
each on i915_vm, vma, obj and probably a few more).
Not the worst one I've seen by far in the code we've merged already.
Minimally this needs a comment here and in the struct next to
@pin_count to explain where all this is abused, which would already
make it better than most of the in-tree ones.
As part of the ttm conversion we have a plan to sunset the "pin_count
as a lock" stuff, depending how bad that goes we might need to split
up the task for each struct that has such a pin_count.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/panfrost: Use xarray and helpers for depedency tracking
On Wed, Jun 02, 2021 at 03:06:50PM +0100, Steven Price wrote:
> On 21/05/2021 10:09, Daniel Vetter wrote:
> > More consistency and prep work for the next patch.
> >
> > Aside: I wonder whether we shouldn't just move this entire xarray
> > business into the scheduler so that not everyone has to reinvent the
> > same wheels. Cc'ing some scheduler people for this too.
> >
> > Cc: "Christian König"
> > Cc: Luben Tuikov
> > Cc: Alex Deucher
> > Cc: Lee Jones
> > Cc: Steven Price
> > Cc: Rob Herring
> > Cc: Tomeu Vizoso
> > Cc: Alyssa Rosenzweig
> > Cc: Sumit Semwal
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Signed-off-by: Daniel Vetter
>
> Two comments below, but otherwise looks like a nice cleanup.
Thanks for taking a look.
> > ---
> > drivers/gpu/drm/panfrost/panfrost_drv.c | 41 -
> > drivers/gpu/drm/panfrost/panfrost_job.c | 61 ++---
> > drivers/gpu/drm/panfrost/panfrost_job.h | 8 ++--
> > 3 files changed, 46 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > index ca07098a6141..7977b4752b5c 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > @@ -137,12 +137,6 @@ panfrost_lookup_bos(struct drm_device *dev,
> > if (!job->bo_count)
> > return 0;
> >
> > - job->implicit_fences = kvmalloc_array(job->bo_count,
> > - sizeof(struct dma_fence *),
> > - GFP_KERNEL | __GFP_ZERO);
> > - if (!job->implicit_fences)
> > - return -ENOMEM;
> > -
> > ret = drm_gem_objects_lookup(file_priv,
> > (void __user *)(uintptr_t)args->bo_handles,
> > job->bo_count, >bos);
> > @@ -173,7 +167,7 @@ panfrost_lookup_bos(struct drm_device *dev,
> > }
> >
> > /**
> > - * panfrost_copy_in_sync() - Sets up job->in_fences[] with the sync objects
> > + * panfrost_copy_in_sync() - Sets up job->deps with the sync objects
> > * referenced by the job.
> > * @dev: DRM device
> > * @file_priv: DRM file for this fd
> > @@ -193,22 +187,14 @@ panfrost_copy_in_sync(struct drm_device *dev,
> > {
> > u32 *handles;
> > int ret = 0;
> > - int i;
> > + int i, in_fence_count;
> >
> > - job->in_fence_count = args->in_sync_count;
> > + in_fence_count = args->in_sync_count;
> >
> > - if (!job->in_fence_count)
> > + if (!in_fence_count)
> > return 0;
> >
> > - job->in_fences = kvmalloc_array(job->in_fence_count,
> > - sizeof(struct dma_fence *),
> > - GFP_KERNEL | __GFP_ZERO);
> > - if (!job->in_fences) {
> > - DRM_DEBUG("Failed to allocate job in fences\n");
> > - return -ENOMEM;
> > - }
> > -
> > - handles = kvmalloc_array(job->in_fence_count, sizeof(u32), GFP_KERNEL);
> > + handles = kvmalloc_array(in_fence_count, sizeof(u32), GFP_KERNEL);
> > if (!handles) {
> > ret = -ENOMEM;
> > DRM_DEBUG("Failed to allocate incoming syncobj handles\n");
> > @@ -217,16 +203,23 @@ panfrost_copy_in_sync(struct drm_device *dev,
> >
> > if (copy_from_user(handles,
> >(void __user *)(uintptr_t)args->in_syncs,
> > - job->in_fence_count * sizeof(u32))) {
> > + in_fence_count * sizeof(u32))) {
> > ret = -EFAULT;
> > DRM_DEBUG("Failed to copy in syncobj handles\n");
> > goto fail;
> > }
> >
> > - for (i = 0; i < job->in_fence_count; i++) {
> > + for (i = 0; i < in_fence_count; i++) {
> > + struct dma_fence *fence;
> > +
> > ret = drm_syncobj_find_fence(file_priv, handles[i], 0, 0,
> > ->in_fences[i]);
> > - if (ret == -EINVAL)
> > +);
> > + if (ret)
> > + goto fail;
> > +
> > + ret = drm_gem_fence_array_add(>deps, fence);
> > +
> > + if (ret)
> > goto fail;
> > }
> >
> > @@ -264,6 +257,8 @@ static int panfrost_ioctl_submit(struct drm_device
> > *dev, void *data,
> >
> > kref_init(>refcount);
> >
> > + xa_init_flags(>deps, XA_FLAGS_ALLOC);
> > +
> > job->pfdev = pfdev;
> > job->jc = args->jc;
> > job->requirements = args->requirements;
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> > b/drivers/gpu/drm/panfrost/panfrost_job.c
> > index f5d39ee14ab5..707d912ff64a 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> > @@ -196,14 +196,21 @@ static void panfrost_job_hw_submit(struct
> > panfrost_job *job, int js)
> > job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
> > }
> >
> > -static void
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem/mman: only allow WC for lmem
== Series Details == Series: drm/i915/gem/mman: only allow WC for lmem URL : https://patchwork.freedesktop.org/series/90875/ State : success == Summary == CI Bug Log - changes from CI_DRM_10159_full -> Patchwork_20263_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20263_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-snb6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +6 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-iclb5/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-tglb8/igt@gem_huc_c...@huc-copy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-tglb6/igt@gem_huc_c...@huc-copy.html - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-apl1/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#307]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-skl7/igt@gem_mmap_...@big-copy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-skl10/igt@gem_mmap_...@big-copy.html * igt@gem_mmap_gtt@big-copy-xy: - shard-skl: NOTRUN -> [FAIL][17] ([i915#307]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-skl3/igt@gem_mmap_...@big-copy-xy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-skl: [PASS][18] -> [INCOMPLETE][19] ([i915#198] / [i915#3468]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-skl3/igt@gem_mmap_...@cpuset-basic-small-copy.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-skl7/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][20] ([i915#3468]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-glk: [PASS][21] -> [INCOMPLETE][22] ([i915#2055] / [i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-glk9/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-glk8/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent: - shard-snb: NOTRUN -> [INCOMPLETE][23] ([i915#3468]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20263/shard-snb5/igt@gem_mmap_...@fault-concurrent.html * igt@gem_mmap_gtt@medium-copy-xy: - shard-iclb: [PASS][24] -> [INCOMPLETE][25] ([i915#2502] / [i915#3468]) [24]:
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote: > Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): > > > > On 6/2/21 10:32 AM, Christian König wrote: > > > Uff I'm just waiting for feedback from Philip to merge a large patch > > > set for TTM through drm-misc-next. > > > > > > I'm pretty sure we will run into merge conflicts if you try to push > > > your changes through the Intel tree. > > > > > > Christian. > > > > OK, so what would be the best approach here?, Adding the TTM patches to > > drm-misc-next when your set has landed? > > I think I will send out out my set to Matthew once more for review, then > push the common TTM stuff to drm-misc-next as much as possible. > > Then you should be able to land your stuff to drm-misc-next and rebase on > the end result. > > Just need to note to David that drm-misc-next should be merged to drm-next > before the Intel patches depending on that stuff land as well. Other option (because the backmerges tend to be slow) is a topic branch, and we just eat/resolve the conflicts in both drm-misc-next and drm-intel-gt-next in the merge commit. If it's not too bad (I haven't looked at what exactly we need for the i915 side from ttm in detail). But also often figuring out the topic branch logistics takes longer than just merging to drm-misc-next as the patches get ready. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 15/17] drm/i915/pxp: Add plane decryption support
On Mon, May 24, 2021 at 10:48:01PM -0700, Daniele Ceraolo Spurio wrote:
> From: Anshuman Gupta
>
> Add support to enable/disable PLANE_SURF Decryption Request bit.
> It requires only to enable plane decryption support when following
> condition met.
> 1. PXP session is enabled.
> 2. Buffer object is protected.
>
> v2:
> - Used gen fb obj user_flags instead gem_object_metadata. [Krishna]
>
> v3:
> - intel_pxp_gem_object_status() API changes.
>
> v4: use intel_pxp_is_active (Daniele)
>
> v5: rebase and use the new protected object status checker (Daniele)
>
> v6: used plane state for plane_decryption to handle async flip
> as suggested by Ville.
>
> v7: check pxp session while plane decrypt state computation. [Ville]
> removed pointless code. [Ville]
>
> v8 (Daniele): update PXP check
>
> Cc: Bommu Krishnaiah
> Cc: Huang Sean Z
> Cc: Gaurav Kumar
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c| 16
> drivers/gpu/drm/i915/display/intel_display.c | 4
> .../gpu/drm/i915/display/intel_display_types.h | 3 +++
> .../gpu/drm/i915/display/skl_universal_plane.c | 15 ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 5 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 36f52a1d7552..88b3272c0b00 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -41,6 +41,7 @@
> #include "intel_display_types.h"
> #include "intel_pm.h"
> #include "intel_sprite.h"
> +#include "pxp/intel_pxp.h"
>
> static void intel_plane_state_reset(struct intel_plane_state *plane_state,
> struct intel_plane *plane)
> @@ -383,6 +384,14 @@ intel_crtc_get_plane(struct intel_crtc *crtc, enum
> plane_id plane_id)
> return NULL;
> }
>
> +static int bo_has_valid_encryption(const struct drm_i915_gem_object *obj)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> +
> + return i915_gem_object_has_valid_protection(obj) &&
> +intel_pxp_is_active(>gt.pxp);
> +}
> +
> int intel_plane_atomic_check(struct intel_atomic_state *state,
>struct intel_plane *plane)
> {
> @@ -397,6 +406,7 @@ int intel_plane_atomic_check(struct intel_atomic_state
> *state,
> intel_atomic_get_old_crtc_state(state, crtc);
> struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> + const struct drm_framebuffer *fb;
>
> if (new_crtc_state && new_crtc_state->bigjoiner_slave) {
> struct intel_plane *master_plane =
> @@ -413,6 +423,12 @@ int intel_plane_atomic_check(struct intel_atomic_state
> *state,
> new_master_plane_state,
> crtc);
>
> + fb = new_plane_state->hw.fb;
> + if (fb)
> + new_plane_state->decrypt =
> bo_has_valid_encryption(intel_fb_obj(fb));
> + else
> + new_plane_state->decrypt = old_plane_state->decrypt;
> +
> new_plane_state->uapi.visible = false;
> if (!new_crtc_state)
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0bb2e582c87f..f7f5374114ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -9767,6 +9767,10 @@ static int intel_atomic_check_async(struct
> intel_atomic_state *state)
> drm_dbg_kms(>drm, "Color range cannot be changed
> in async flip\n");
> return -EINVAL;
> }
> +
> + /* plane decryption is allow to change only in synchronous
> flips */
> + if (old_plane_state->decrypt != new_plane_state->decrypt)
> + return -EINVAL;
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ce05475ad560..6b5dab9e1c40 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -621,6 +621,9 @@ struct intel_plane_state {
>
> struct intel_fb_view view;
>
> + /* Plane pxp decryption state */
> + bool decrypt;
> +
> /* plane control register */
> u32 ctl;
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 59e032f3687a..2c8e88e8ad83 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -18,6 +18,7 @@
> #include
Re: [Intel-gfx] [PATCH v4 04/17] drm/i915/gt: Export the pinned context constructor and destructor
On Tue, Jun 01, 2021 at 02:23:00PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/1/2021 1:20 PM, Rodrigo Vivi wrote:
> > On Mon, May 24, 2021 at 10:47:50PM -0700, Daniele Ceraolo Spurio wrote:
> > > From: Chris Wilson
> > >
> > > Allow internal clients to create a pinned context.
> > >
> > > v2 (Daniele): export destructor as well, allow optional usage of custom
> > > vm for maximum flexibility.
> > >
> > > Signed-off-by: Chris Wilson
> > > Signed-off-by: Daniele Ceraolo Spurio
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_engine.h| 10
> > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 29 +++
> > > 2 files changed, 29 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> > > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > > index 47ee8578e511..a64d28aba257 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > > @@ -18,7 +18,9 @@
> > > #include "intel_workarounds.h"
> > > struct drm_printer;
> > > +struct intel_context;
> > > struct intel_gt;
> > > +struct lock_class_key;
> > > /* Early gen2 devices have a cacheline of just 32 bytes, using 64 is
> > > overkill,
> > >* but keeps the logic simple. Indeed, the whole purpose of this macro
> > > is just
> > > @@ -255,6 +257,14 @@ struct i915_request *
> > > intel_engine_find_active_request(struct intel_engine_cs *engine);
> > > u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
> > > +struct intel_context *
> > > +intel_engine_create_pinned_context(struct intel_engine_cs *engine,
> > > +struct i915_address_space *vm,
> > > +unsigned int ring_size,
> > > +unsigned int hwsp,
> > > +struct lock_class_key *key,
> > > +const char *name);
> > > +void intel_engine_destroy_pinned_context(struct intel_context *ce);
> > > void intel_engine_init_active(struct intel_engine_cs *engine,
> > > unsigned int subclass);
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > index eba2da9679a5..8cbf11497e8e 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > @@ -801,11 +801,13 @@ intel_engine_init_active(struct intel_engine_cs
> > > *engine, unsigned int subclass)
> > > #endif
> > > }
> > > -static struct intel_context *
> > > -create_pinned_context(struct intel_engine_cs *engine,
> > > - unsigned int hwsp,
> > > - struct lock_class_key *key,
> > > - const char *name)
> > > +struct intel_context *
> > > +intel_engine_create_pinned_context(struct intel_engine_cs *engine,
> > > +struct i915_address_space *vm,
> > > +unsigned int ring_size,
> > > +unsigned int hwsp,
> > > +struct lock_class_key *key,
> > > +const char *name)
> > > {
> > > struct intel_context *ce;
> > > int err;
> > > @@ -816,6 +818,12 @@ create_pinned_context(struct intel_engine_cs *engine,
> > > __set_bit(CONTEXT_BARRIER_BIT, >flags);
> > > ce->timeline = page_pack_bits(NULL, hwsp);
> > > + ce->ring = __intel_context_ring_size(ring_size);
> > why do we need this now and we didn't need before?
>
> Since we're now exporting the function as a more "official" interface, the
> idea was to provide as much flexibility as possible. The ring size could be
> used if e.g. we decide to use more pxp sessions and therefore need more
> space in the ring to insert instructions. Same for the vm below.
it makes sense. thanks for the explanation.
Reviewed-by: Rodrigo Vivi
>
> Daniele
>
> >
> > > +
> > > + if (vm) {
> > > + i915_vm_put(ce->vm);
> > > + ce->vm = i915_vm_get(vm);
> > > + }
> > same question here...
> >
> > > err = intel_context_pin(ce); /* perma-pin so it is always
> > > available */
> > > if (err) {
> > > @@ -834,7 +842,7 @@ create_pinned_context(struct intel_engine_cs *engine,
> > > return ce;
> > > }
> > > -static void destroy_pinned_context(struct intel_context *ce)
> > > +void intel_engine_destroy_pinned_context(struct intel_context *ce)
> > > {
> > > struct intel_engine_cs *engine = ce->engine;
> > > struct i915_vma *hwsp = engine->status_page.vma;
> > > @@ -854,8 +862,9 @@ create_kernel_context(struct intel_engine_cs *engine)
> > > {
> > > static struct lock_class_key kernel;
> > > - return create_pinned_context(engine, I915_GEM_HWS_SEQNO_ADDR,
> > > - , "kernel_context");
> > > + return intel_engine_create_pinned_context(engine, NULL, SZ_4K,
> > > +
Re: [Intel-gfx] [PATCH v4 12/17] drm/i915/pxp: start the arb session on demand
On Mon, May 24, 2021 at 10:47:58PM -0700, Daniele Ceraolo Spurio wrote:
> Now that we can handle destruction and re-creation of the arb session,
> we can postpone the start of the session to the first submission that
> requires it, to avoid keeping it running with no user.
>
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 8 ++--
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 37 ---
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 2 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 +--
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 10 +
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 3 ++
> 7 files changed, 39 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index a11e9d5767bf..c08e28847064 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2948,9 +2948,11 @@ eb_select_engine(struct i915_execbuffer *eb)
> intel_gt_pm_get(ce->engine->gt);
>
> if (i915_gem_context_uses_protected_content(eb->gem_context)) {
> - err = intel_pxp_wait_for_arb_start(>engine->gt->pxp);
> - if (err)
> - goto err;
> + if (!intel_pxp_is_active(>engine->gt->pxp)) {
> + err = intel_pxp_start(>engine->gt->pxp);
> + if (err)
> + goto err;
> + }
>
> if (i915_gem_context_invalidated(eb->gem_context)) {
> err = -EACCES;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index f713d3423cea..2291c68fd3a0 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -77,6 +77,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
> init_completion(>termination);
> complete_all(>termination);
>
> + mutex_init(>arb_mutex);
> INIT_WORK(>session_work, intel_pxp_session_work);
>
> ret = create_vcs_context(pxp);
> @@ -113,7 +114,7 @@ void intel_pxp_mark_termination_in_progress(struct
> intel_pxp *pxp)
> reinit_completion(>termination);
> }
>
> -static void intel_pxp_queue_termination(struct intel_pxp *pxp)
> +static void pxp_queue_termination(struct intel_pxp *pxp)
> {
> struct intel_gt *gt = pxp_to_gt(pxp);
>
> @@ -132,31 +133,41 @@ static void intel_pxp_queue_termination(struct
> intel_pxp *pxp)
> * the arb session is restarted from the irq work when we receive the
> * termination completion interrupt
> */
> -int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp)
> +int intel_pxp_start(struct intel_pxp *pxp)
> {
> + int ret = 0;
> +
> if (!intel_pxp_is_enabled(pxp))
> - return 0;
> + return -ENODEV;
> +
> + mutex_lock(>arb_mutex);
> +
> + if (pxp->arb_is_valid)
> + goto unlock;
> +
> + pxp_queue_termination(pxp);
>
> if (!wait_for_completion_timeout(>termination,
> - msecs_to_jiffies(100)))
> - return -ETIMEDOUT;
> + msecs_to_jiffies(100))) {
> + ret = -ETIMEDOUT;
> + goto unlock;
> + }
> +
> + /* make sure the compiler doesn't optimize the double access */
> + barrier();
>
> if (!pxp->arb_is_valid)
> - return -EIO;
> + ret = -EIO;
>
> - return 0;
> +unlock:
> + mutex_unlock(>arb_mutex);
> + return ret;
> }
>
> void intel_pxp_init_hw(struct intel_pxp *pxp)
> {
> kcr_pxp_enable(pxp_to_gt(pxp));
> intel_pxp_irq_enable(pxp);
> -
> - /*
> - * the session could've been attacked while we weren't loaded, so
> - * handle it as if it was and re-create it.
> - */
> - intel_pxp_queue_termination(pxp);
> }
>
> void intel_pxp_fini_hw(struct intel_pxp *pxp)
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 91c1a2056309..1f9871e64096 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -32,7 +32,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
> void intel_pxp_fini_hw(struct intel_pxp *pxp);
>
> void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
> -int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp);
> +int intel_pxp_start(struct intel_pxp *pxp);
> void intel_pxp_invalidate(struct intel_pxp *pxp);
> #else
> static inline void intel_pxp_init(struct intel_pxp *pxp)
> @@ -43,7 +43,7 @@ static inline void intel_pxp_fini(struct intel_pxp *pxp)
> {
> }
>
> -static inline int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp)
> +static inline int intel_pxp_start(struct intel_pxp *pxp)
> {
> return 0;
> }
> diff --git
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function (rev2) URL : https://patchwork.freedesktop.org/series/90830/ State : success == Summary == CI Bug Log - changes from CI_DRM_10159_full -> Patchwork_20262_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20262_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][2] -> [FAIL][3] ([i915#2410]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][4] ([i915#3354]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-tglb8/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-iclb: NOTRUN -> [FAIL][6] ([i915#2842]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-iclb8/igt@gem_exec_fair@basic-n...@vecs0.html - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-tglb3/igt@gem_exec_fair@basic-p...@bcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-iclb2/igt@gem_exec_fair@basic-p...@vecs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-iclb4/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-apl2/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#307]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-skl2/igt@gem_mmap_...@big-copy-odd.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-skl9/igt@gem_mmap_...@big-copy-odd.html * igt@gem_mmap_gtt@big-copy-xy: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#307]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-glk6/igt@gem_mmap_...@big-copy-xy.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-glk6/igt@gem_mmap_...@big-copy-xy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-kbl: [PASS][22] -> [INCOMPLETE][23] ([i915#3468]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-kbl3/igt@gem_mmap_...@cpuset-basic-small-copy.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-kbl7/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][24] ([i915#3468]) +1 similar issue [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20262/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Get rid of fence error propagation
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : success == Summary == CI Bug Log - changes from CI_DRM_10161 -> Patchwork_20265 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/index.html Known issues Here are the changes found in Patchwork_20265 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-skl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-skl-guc/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@execlists: - fi-skl-guc: NOTRUN -> [DMESG-FAIL][2] ([i915#3462]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-skl-guc/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#2782]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([i915#1372]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html - fi-skl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_mmap_gtt: - fi-skl-guc: NOTRUN -> [SKIP][9] ([fdo#109271]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-skl-guc/igt@kms_psr@primary_mmap_gtt.html * igt@runner@aborted: - fi-skl-guc: NOTRUN -> [FAIL][10] ([i915#1436] / [i915#2426] / [i915#3363]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-skl-guc/igt@run...@aborted.html Possible fixes * igt@core_auth@basic-auth: - fi-kbl-soraka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-kbl-soraka/igt@core_a...@basic-auth.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-kbl-soraka/igt@core_a...@basic-auth.html Warnings * igt@i915_selftest@live@execlists: - fi-icl-u2: [DMESG-FAIL][13] ([i915#3462]) -> [INCOMPLETE][14] ([i915#2782] / [i915#3462]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-icl-u2/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-icl-u2/igt@i915_selftest@l...@execlists.html - fi-tgl-u2: [INCOMPLETE][15] ([i915#3462]) -> [DMESG-FAIL][16] ([i915#3462]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-tgl-u2/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-tgl-u2/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-icl-u2: [FAIL][17] ([i915#2426] / [i915#2782] / [i915#3363]) -> [FAIL][18] ([i915#2782] / [i915#3363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-icl-u2/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-icl-u2/igt@run...@aborted.html - fi-bxt-dsi: [FAIL][19] ([i915#3363]) -> [FAIL][20] ([i915#2426] / [i915#3363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-bxt-dsi/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-bxt-dsi/igt@run...@aborted.html - fi-cfl-guc: [FAIL][21] ([i915#2426] / [i915#3363]) -> [FAIL][22] ([i915#3363]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-cfl-guc/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-cfl-guc/igt@run...@aborted.html - fi-kbl-7567u: [FAIL][23] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][24] ([i915#1436] / [i915#3363]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10161/fi-kbl-7567u/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20265/fi-kbl-7567u/igt@run...@aborted.html - fi-skl-6700k2: [FAIL][25] ([i915#1436] / [i915#3363]) -> [FAIL][26]
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Move system memory to TTM for discrete
== Series Details == Series: drm/i915: Move system memory to TTM for discrete URL : https://patchwork.freedesktop.org/series/90898/ State : failure == Summary == Applying: drm/i915: Update object placement flags to be mutable Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gem/i915_gem_mman.c M drivers/gpu/drm/i915/gem/i915_gem_object.c M drivers/gpu/drm/i915/gem/i915_gem_object.h M drivers/gpu/drm/i915/gem/i915_gem_object_types.h M drivers/gpu/drm/i915/gem/i915_gem_pages.c A drivers/gpu/drm/i915/gem/i915_gem_ttm.c M drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c CONFLICT (modify/delete): drivers/gpu/drm/i915/gem/i915_gem_ttm.c deleted in HEAD and modified in drm/i915: Update object placement flags to be mutable. Version drm/i915: Update object placement flags to be mutable of drivers/gpu/drm/i915/gem/i915_gem_ttm.c left in tree. Auto-merging drivers/gpu/drm/i915/gem/i915_gem_pages.c Auto-merging drivers/gpu/drm/i915/gem/i915_gem_object_types.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_object_types.h Auto-merging drivers/gpu/drm/i915/gem/i915_gem_object.h Auto-merging drivers/gpu/drm/i915/gem/i915_gem_object.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_object.c Auto-merging drivers/gpu/drm/i915/gem/i915_gem_mman.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_mman.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Update object placement flags to be mutable When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 07/15] drm: Add a prefetching memcpy_from_wc
On 6/1/21 2:27 PM, Jani Nikula wrote: On Tue, 01 Jun 2021, Thomas Hellström wrote: Reading out of write-combining mapped memory is typically very slow since the CPU doesn't prefetch. However some archs have special instructions to do this. So add a best-effort memcpy_from_wc taking dma-buf-map pointer arguments that attempts to use a fast prefetching memcpy and otherwise falls back to ordinary memcopies, taking the iomem tagging into account. The code is largely copied from i915_memcpy_from_wc. Cc: Daniel Vetter Cc: Christian König Suggested-by: Daniel Vetter Signed-off-by: Thomas Hellström Acked-by: Christian König Acked-by: Daniel Vetter --- v7: - Perform a memcpy even if warning with in_interrupt(). Suggested by Christian König. - Fix compilation failure on !X86 (Reported by kernel test robot l...@intel.com) v8: - Skip kerneldoc for drm_memcpy_init_early() - Export drm_memcpy_from_wc() also for non-x86. --- Documentation/gpu/drm-mm.rst | 2 +- drivers/gpu/drm/drm_cache.c | 148 +++ drivers/gpu/drm/drm_drv.c| 2 + include/drm/drm_cache.h | 7 ++ 4 files changed, 158 insertions(+), 1 deletion(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 21be6deadc12..c66058c5bce7 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -469,7 +469,7 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: -DRM Cache Handling +DRM Cache Handling and Fast WC memcpy() == The title underline needs to be as long as the title. BR, Jani. Thanks, Jani. I think Daniel was trying to point this out to me as well with limited success. It's fixed now. /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/ttm: Implement object migration
Implement object migration, needed primarily for dma-buf exports of
objects currently residing in LMEM, until we land p2pdma.
There are no users yet of this code.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 100 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 10 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 7 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 51 -
4 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..1589053ea99e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -475,6 +475,106 @@ bool i915_gem_object_migratable(struct
drm_i915_gem_object *obj)
return obj->mm.n_placements > 1;
}
+bool i915_gem_object_can_migrate_to_region(struct drm_i915_gem_object *obj,
+ struct intel_memory_region *mr,
+ unsigned int *placement_index)
+{
+ unsigned int i;
+ unsigned int num_allowed = obj->mm.n_placements;
+
+ if (!i915_gem_object_evictable(obj))
+ return false;
+
+ if (num_allowed == 0 && mr != obj->mm.region)
+ return false;
+
+ if (num_allowed == 1 && mr != obj->mm.placements[0])
+ return false;
+
+ for (i = 0; i < num_allowed; ++i) {
+ if (mr == obj->mm.placements[i]) {
+ if (placement_index)
+ *placement_index = i;
+ return true;
+ }
+ }
+
+ return false;
+}
+
+/**
+ * i915_gem_object_migrate_to_region_lazy - Lazily migrate an object
+ * @obj: The object to migrate.
+ * @mr: The region to migrate to.
+ *
+ * Check that @obj can migrate to @mr, and update all data necessary to
+ * make that happen on the next get_pages(). We sync and unbind gpu bindings
+ * and put pages. The word "lazy" means that the actual migration blit
+ * is not triggered by this function.
+ *
+ * Return: Zero on success, negative error code on failure.
+ */
+int i915_gem_object_migrate_to_region_lazy(struct drm_i915_gem_object *obj,
+ struct intel_memory_region *mr)
+{
+ unsigned int index;
+ int ret;
+
+ if (obj->mm.region == mr)
+ return 0;
+
+ if (!i915_gem_object_can_migrate_to_region(obj, mr, ))
+ return -EINVAL;
+
+ ret = i915_gem_object_unbind(obj, I915_GEM_OBJECT_UNBIND_ACTIVE);
+ if (ret)
+ return ret;
+
+ ret = __i915_gem_object_put_pages(obj);
+ if (ret)
+ return ret;
+
+ /*
+* The next get_pages() will pick up the new desired placement
+* and migrate.
+*/
+ if (obj->mm.override_region) {
+ intel_memory_region_put(obj->mm.override_region);
+ obj->mm.override_region = NULL;
+ }
+
+ if (index != 0)
+ obj->mm.override_region =
+ intel_memory_region_get(obj->mm.placements[index]);
+
+ return 0;
+}
+
+/**
+ * i915_gem_object_migrate_to_region - Migrate an object
+ * @obj: The object to migrate.
+ * @mr: The region to migrate to.
+ *
+ * Check that @obj can migrate to @mr, and migrate the object.
+ * The caller needs to check that the final region was the
+ * desired one since the object may have ended up elsewhere on
+ * lack of space in the desired region, and if there are other
+ * allowed placements.
+ *
+ * Return: Zero on success, negative error code on failure.
+ */
+int i915_gem_object_migrate_to_region(struct drm_i915_gem_object *obj,
+ struct intel_memory_region *mr)
+{
+ int ret;
+
+ ret = i915_gem_object_migrate_to_region_lazy(obj, mr);
+ if (ret)
+ return ret;
+
+ return i915_gem_object_get_pages(obj);
+}
+
/**
* i915_gem_object_has_struct_page - Whether the object is page-backed
* @obj: The object to query.
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 23e26f6b1db9..dfab5b080c54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -592,6 +592,16 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object
*obj);
bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
+bool i915_gem_object_can_migrate_to_region(struct drm_i915_gem_object *obj,
+ struct intel_memory_region *mr,
+ unsigned int *placement_index);
+
+int i915_gem_object_migrate_to_region_lazy(struct drm_i915_gem_object *obj,
+ struct intel_memory_region *mr);
+
+int i915_gem_object_migrate_to_region(struct
[Intel-gfx] [PATCH 2/5] drm/i915/ttm: Adjust gem flags and caching settings after a move
After a TTM move we need to update the i915 gem flags and caching
settings to reflect the new placement.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 112 +++-
1 file changed, 90 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index ae12a2be11a2..c73c51755c20 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -70,6 +70,17 @@ static struct ttm_placement i915_sys_placement = {
.busy_placement = _sys_placement_flags[1],
};
+static bool gpu_binds_iomem(struct ttm_resource *mem)
+{
+ return (mem->mem_type != TTM_PL_SYSTEM);
+}
+
+static bool cpu_maps_iomem(struct ttm_resource *mem)
+{
+ /* Once / if we support GGTT, this is also false for cached ttm_tts */
+ return (mem->mem_type != TTM_PL_SYSTEM);
+}
+
static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
@@ -175,6 +186,41 @@ static void i915_ttm_free_cached_io_st(struct
drm_i915_gem_object *obj)
obj->ttm.cached_io_st = NULL;
}
+static void
+i915_ttm_adjust_domains_after_cpu_move(struct drm_i915_gem_object *obj)
+{
+ struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+
+ if (cpu_maps_iomem(>mem) || bo->ttm->caching != ttm_cached) {
+ obj->write_domain = I915_GEM_DOMAIN_WC;
+ obj->read_domains = I915_GEM_DOMAIN_WC;
+ } else {
+ obj->write_domain = I915_GEM_DOMAIN_CPU;
+ obj->read_domains = I915_GEM_DOMAIN_CPU;
+ }
+}
+
+static void i915_ttm_adjust_gem_after_move(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+ unsigned int cache_level;
+
+ obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
+
+ obj->mem_flags |= cpu_maps_iomem(>mem) ? I915_BO_FLAG_IOMEM :
+ I915_BO_FLAG_STRUCT_PAGE;
+
+ if ((HAS_LLC(i915) || HAS_SNOOP(i915)) && !gpu_binds_iomem(>mem) &&
+ bo->ttm->caching == ttm_cached) {
+ cache_level = I915_CACHE_LLC;
+ } else {
+ cache_level = I915_CACHE_NONE;
+ }
+
+ i915_gem_object_set_cache_coherency(obj, cache_level);
+}
+
static void i915_ttm_purge(struct drm_i915_gem_object *obj)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
@@ -190,8 +236,10 @@ static void i915_ttm_purge(struct drm_i915_gem_object *obj)
/* TTM's purge interface. Note that we might be reentering. */
ret = ttm_bo_validate(bo, , );
-
if (!ret) {
+ obj->write_domain = 0;
+ obj->read_domains = 0;
+ i915_ttm_adjust_gem_after_move(obj);
i915_ttm_free_cached_io_st(obj);
obj->mm.madv = __I915_MADV_PURGED;
}
@@ -273,12 +321,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
struct ttm_resource *res)
{
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
- struct ttm_resource_manager *man =
- ttm_manager_type(bo->bdev, res->mem_type);
- if (man->use_tt)
+ if (!gpu_binds_iomem(res))
return i915_ttm_tt_get_st(bo->ttm);
+ /*
+* If CPU mapping differs, we need to add the ttm_tt pages to
+* the resulting st. Might make sense for GGTT.
+*/
+ GEM_WARN_ON(!cpu_maps_iomem(res));
return intel_region_ttm_node_to_st(obj->mm.region, res->mm_node);
}
@@ -290,8 +341,6 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool
evict,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct ttm_resource_manager *dst_man =
ttm_manager_type(bo->bdev, dst_mem->mem_type);
- struct ttm_resource_manager *src_man =
- ttm_manager_type(bo->bdev, bo->mem.mem_type);
struct intel_memory_region *dst_reg, *src_reg;
union {
struct ttm_kmap_iter_tt tt;
@@ -332,34 +381,36 @@ static int i915_ttm_move(struct ttm_buffer_object *bo,
bool evict,
if (IS_ERR(dst_st))
return PTR_ERR(dst_st);
- /* If we start mapping GGTT, we can no longer use man::use_tt here. */
- dst_iter = dst_man->use_tt ?
+ dst_iter = !cpu_maps_iomem(dst_mem) ?
ttm_kmap_iter_tt_init(&_dst_iter.tt, bo->ttm) :
ttm_kmap_iter_iomap_init(&_dst_iter.io, _reg->iomap,
dst_st, dst_reg->region.start);
- src_iter = src_man->use_tt ?
+
[Intel-gfx] [PATCH 4/5] drm/i915/ttm: Use TTM for system memory
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate calback. We can then also reuse our
own very elaborate shrinker for that memory.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 22 ++
drivers/gpu/drm/i915/i915_drv.h| 3 ---
drivers/gpu/drm/i915/intel_memory_region.c | 7 ++-
drivers/gpu/drm/i915/intel_memory_region.h | 8
4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 8e1c01168c6d..42e89bf43708 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -755,3 +755,25 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
/* i915 wants -ENXIO when out of memory region space. */
return (ret == -ENOSPC) ? -ENXIO : ret;
}
+
+static const struct intel_memory_region_ops ttm_system_region_ops = {
+ .init_object = __i915_gem_ttm_object_init,
+};
+
+struct intel_memory_region *
+i915_gem_ttm_system_setup(struct drm_i915_private *i915,
+ u16 type, u16 instance)
+{
+ struct intel_memory_region *mr;
+
+ mr = intel_memory_region_create(i915, 0,
+ totalram_pages() << PAGE_SHIFT,
+ PAGE_SIZE, 0,
+ type, instance,
+ _system_region_ops);
+ if (IS_ERR_OR_NULL(mr))
+ return mr;
+
+ intel_memory_region_set_name(mr, "system-ttm");
+ return mr;
+}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 524aaeb0e842..c6cc16ccce36 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1768,9 +1768,6 @@ void i915_gem_cleanup_userptr(struct drm_i915_private
*dev_priv);
void i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
-struct intel_memory_region *i915_gem_shmem_setup(struct drm_i915_private *i915,
-u16 type, u16 instance);
-
static inline void i915_gem_drain_freed_objects(struct drm_i915_private *i915)
{
/*
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index bd27e897d4d0..a42bb36c2aea 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -220,7 +220,12 @@ int intel_memory_regions_hw_probe(struct drm_i915_private
*i915)
instance = intel_region_map[i].instance;
switch (type) {
case INTEL_MEMORY_SYSTEM:
- mem = i915_gem_shmem_setup(i915, type, instance);
+ if (IS_DGFX(i915))
+ mem = i915_gem_ttm_system_setup(i915, type,
+ instance);
+ else
+ mem = i915_gem_shmem_setup(i915, type,
+ instance);
break;
case INTEL_MEMORY_STOLEN_LOCAL:
mem = i915_gem_stolen_lmem_setup(i915, type, instance);
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 7b5fa97c0b59..4d084424b55c 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -142,4 +142,12 @@ void intel_memory_region_unreserve(struct
intel_memory_region *mem);
int intel_memory_region_reserve(struct intel_memory_region *mem,
resource_size_t offset,
resource_size_t size);
+
+struct intel_memory_region *
+i915_gem_ttm_system_setup(struct drm_i915_private *i915,
+ u16 type, u16 instance);
+struct intel_memory_region *
+i915_gem_shmem_setup(struct drm_i915_private *i915,
+u16 type, u16 instance);
+
#endif
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] drm/i915: Move system memory to TTM for discrete
Early implementation of moving system memory for discrete cards over to TTM. We first add the notion of objects being migratable under the object lock to i915 gem, and add some asserts to verify that objects are either locked or pinned when the placement is checked by the gem code. Patch 2 and 3 deals with updating the i915 gem bookkeeping after a TTM move, Patch 4 moves system over from shmem to TTM for discrete and finally the last patch is more to be considered an RFC for migration implementation. Much of this code is not testing covered, so we might have to add some selftests as well. Meanwhile this should not be merged but may well be reviewed. Note that the mock device doesn't consider itself discrete so the TTM system path is not checked by the mock selftests. Also testing if CI can handle base-commit: and prerequisite-patch-id: Thomas Hellström (5): drm/i915: Update object placement flags to be mutable drm/i915/ttm: Adjust gem flags and caching settings after a move drm/i915/ttm: Calculate the object placement at get_pages time drm/i915/ttm: Use TTM for system memory drm/i915/ttm: Implement object migration drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 138 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 24 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 10 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 +++--- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +- .../drm/i915/gem/selftests/huge_gem_object.c | 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 5 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 4 +- .../drm/i915/gem/selftests/i915_gem_phys.c| 3 +- drivers/gpu/drm/i915/i915_drv.h | 3 - drivers/gpu/drm/i915/intel_memory_region.c| 7 +- drivers/gpu/drm/i915/intel_memory_region.h| 8 + drivers/gpu/drm/i915/intel_region_ttm.c | 8 +- drivers/gpu/drm/i915/intel_region_ttm.h | 2 + 19 files changed, 437 insertions(+), 92 deletions(-) base-commit: cd6eb5f605478f2fff85ec7ac39b7cf445d3deb9 prerequisite-patch-id: b3e7766bc492d04a5ace71fd0d4259689f3bd749 prerequisite-patch-id: 7978430e513e204addd7bc9bef63fd3a9ea25d7c prerequisite-patch-id: f6aa8d141b22b8e532f8152e53f9c913f98458df prerequisite-patch-id: 6486c9db619d88a3e9a4ffc01a89bdc722941a67 prerequisite-patch-id: b71878b47e3be71748aacb5d1b3955853bf80de5 prerequisite-patch-id: 1b67c82c32c02dfdb1217f224652276e044fb549 prerequisite-patch-id: 5229db39ec27eb77a8417ed7c9d54af40e0e9f33 prerequisite-patch-id: b66b1893401cc526b4466ea3c427512261d33dfd prerequisite-patch-id: 706521b6f4858cf4d9ecd83102b347e695b96bb7 prerequisite-patch-id: 686dc7cfea6361c4adabc963996dc3d0d41b28b1 prerequisite-patch-id: 7be87140130a9c2d62a190ceafdacdebd51c5196 -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/ttm: Calculate the object placement at get_pages time
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 92 ++---
drivers/gpu/drm/i915/intel_region_ttm.c | 8 ++-
drivers/gpu/drm/i915/intel_region_ttm.h | 2 +
3 files changed, 75 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c73c51755c20..8e1c01168c6d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -24,6 +24,11 @@
#define I915_TTM_PRIO_NO_PAGES 1
#define I915_TTM_PRIO_HAS_PAGES 2
+/*
+ * Size of struct ttm_place vector in on-stack struct ttm_placement allocs
+ */
+#define I915_TTM_MAX_PLACEMENTS 10
+
/**
* struct i915_ttm_tt - TTM page vector with additional private information
* @ttm: The base TTM page vector.
@@ -42,32 +47,18 @@ struct i915_ttm_tt {
struct sg_table *cached_st;
};
-static const struct ttm_place lmem0_sys_placement_flags[] = {
- {
- .fpfn = 0,
- .lpfn = 0,
- .mem_type = I915_PL_LMEM0,
- .flags = 0,
- }, {
- .fpfn = 0,
- .lpfn = 0,
- .mem_type = I915_PL_SYSTEM,
- .flags = 0,
- }
-};
-
-static struct ttm_placement i915_lmem0_placement = {
- .num_placement = 1,
- .placement = _sys_placement_flags[0],
- .num_busy_placement = 1,
- .busy_placement = _sys_placement_flags[0],
+static const struct ttm_place sys_placement_flags = {
+ .fpfn = 0,
+ .lpfn = 0,
+ .mem_type = I915_PL_SYSTEM,
+ .flags = 0,
};
static struct ttm_placement i915_sys_placement = {
.num_placement = 1,
- .placement = _sys_placement_flags[1],
+ .placement = _placement_flags,
.num_busy_placement = 1,
- .busy_placement = _sys_placement_flags[1],
+ .busy_placement = _placement_flags,
};
static bool gpu_binds_iomem(struct ttm_resource *mem)
@@ -83,6 +74,55 @@ static bool cpu_maps_iomem(struct ttm_resource *mem)
static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
+static enum ttm_caching
+i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
+{
+ /*
+* Objects only allowed in system get cached cpu-mappings.
+* Other objects get WC mapping for now. Even if in system.
+*/
+ if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
+ obj->mm.n_placements <= 1)
+ return ttm_cached;
+
+ return ttm_write_combined;
+}
+
+static void
+i915_ttm_place_from_region(const struct intel_memory_region *mr,
+ struct ttm_place *place)
+{
+ memset(place, 0, sizeof(*place));
+ place->mem_type = intel_region_to_ttm_type(mr);
+}
+
+static void
+i915_ttm_placement_from_obj(const struct drm_i915_gem_object *obj,
+ struct ttm_place *requested,
+ struct ttm_place *busy,
+ struct ttm_placement *placement)
+{
+ unsigned int i;
+ unsigned int num_allowed = obj->mm.n_placements;
+
+ placement->num_placement = 1;
+ i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
+ obj->mm.region, requested);
+
+ /* Cache this on object? */
+ placement->num_busy_placement = num_allowed;
+ for (i = 0; i < placement->num_busy_placement; ++i)
+ i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+
+ if (num_allowed == 0) {
+ *busy = *requested;
+ placement->num_busy_placement = 1;
+ }
+
+ placement->placement = requested;
+ placement->busy_placement = busy;
+}
+
static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
{
@@ -100,7 +140,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
man->use_tt)
page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
- ret = ttm_tt_init(_tt->ttm, bo, page_flags, ttm_write_combined);
+ ret = ttm_tt_init(_tt->ttm, bo, page_flags,
+ i915_ttm_select_tt_caching(obj));
if (ret) {
kfree(i915_tt);
return NULL;
@@ -465,10 +506,13 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object
*obj)
.no_wait_gpu = false,
};
struct sg_table *st;
+ struct ttm_place requested, busy[I915_TTM_MAX_PLACEMENTS];
+ struct ttm_placement placement;
int ret;
/* Move to the requested placement. */
- ret = ttm_bo_validate(bo, _lmem0_placement, );
+ i915_ttm_placement_from_obj(obj, , busy, );
+ ret =
[Intel-gfx] [PATCH 1/5] drm/i915: Update object placement flags to be mutable
The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned. The flags
will change during migration under the object lock.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 38 +++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 14 ++-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 20 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 10 +++--
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 +-
.../drm/i915/gem/selftests/huge_gem_object.c | 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 5 +--
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 +-
.../drm/i915/gem/selftests/i915_gem_phys.c| 3 +-
14 files changed, 78 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index ce6b664b10aa..13b217f75055 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -177,8 +177,8 @@ i915_gem_object_create_internal(struct drm_i915_private
*i915,
return ERR_PTR(-ENOMEM);
drm_gem_private_object_init(>drm, >base, size);
- i915_gem_object_init(obj, _gem_object_internal_ops, _class,
-I915_BO_ALLOC_STRUCT_PAGE);
+ i915_gem_object_init(obj, _gem_object_internal_ops, _class,
0);
+ obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
/*
* Mark the object as volatile, such that the pages are marked as
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d1de97e4adfd..171a21ca930c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -683,7 +683,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
if (mmap_type != I915_MMAP_TYPE_GTT &&
!i915_gem_object_has_struct_page(obj) &&
- !i915_gem_object_type_has(obj, I915_GEM_OBJECT_HAS_IOMEM))
+ !i915_gem_object_has_iomem(obj))
return -ENODEV;
mmo = mmap_offset_attach(obj, mmap_type, file);
@@ -707,7 +707,12 @@ __assign_mmap_offset_handle(struct drm_file *file,
if (!obj)
return -ENOENT;
+ err = i915_gem_object_lock_interruptible(obj, NULL);
+ if (err)
+ goto out_put;
err = __assign_mmap_offset(obj, mmap_type, offset, file);
+ i915_gem_object_unlock(obj);
+out_put:
i915_gem_object_put(obj);
return err;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index cf18c430d51f..07e8ff9a8aae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -475,6 +475,44 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object
*obj)
return obj->mm.n_placements > 1;
}
+/**
+ * i915_gem_object_has_struct_page - Whether the object is page-backed
+ * @obj: The object to query.
+ *
+ * This function should only be called while the object is locked or pinned,
+ * otherwise the page backing may change under the caller.
+ *
+ * Return: True if page-backed, false otherwise.
+ */
+bool i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
+{
+#ifdef CONFIG_LOCKDEP
+ if (IS_DGFX(to_i915(obj->base.dev)) &&
+ i915_gem_object_evictable((void __force *)obj))
+ assert_object_held_shared(obj);
+#endif
+ return obj->mem_flags & I915_BO_FLAG_STRUCT_PAGE;
+}
+
+/**
+ * i915_gem_object_has_iomem - Whether the object is iomem-backed
+ * @obj: The object to query.
+ *
+ * This function should only be called while the object is locked or pinned,
+ * otherwise the iomem backing may change under the caller.
+ *
+ * Return: True if iomem-backed, false otherwise.
+ */
+bool i915_gem_object_has_iomem(const struct drm_i915_gem_object *obj)
+{
+#ifdef CONFIG_LOCKDEP
+ if (IS_DGFX(to_i915(obj->base.dev)) &&
+ i915_gem_object_evictable((void __force *)obj))
+ assert_object_held_shared(obj);
+#endif
+ return obj->mem_flags & I915_BO_FLAG_IOMEM;
+}
+
void i915_gem_init__objects(struct drm_i915_private *i915)
{
INIT_WORK(>mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ff59e6c640e6..23e26f6b1db9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Get rid of fence error propagation
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Excess function parameter 'jump_whitelist' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Excess function parameter 'shadow_map' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Excess function parameter 'batch_map' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Function parameter or member 'trampoline' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Excess function parameter 'jump_whitelist' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Excess function parameter 'shadow_map' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1436: warning: Excess function parameter 'batch_map' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Get rid of fence error propagation
== Series Details == Series: drm/i915: Get rid of fence error propagation URL : https://patchwork.freedesktop.org/series/90891/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic
[Intel-gfx] ✓ Fi.CI.IGT: success for Move LMEM (VRAM) management over to TTM (rev6)
== Series Details == Series: Move LMEM (VRAM) management over to TTM (rev6) URL : https://patchwork.freedesktop.org/series/90681/ State : success == Summary == CI Bug Log - changes from CI_DRM_10159_full -> Patchwork_20261_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20261_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-snb5/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([i915#198]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-skl1/igt@gem_ctx_isolation@preservation...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-skl7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +5 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-glk5/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-iclb7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-tglb3/igt@gem_exec_fair@basic-p...@bcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-tglb2/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-glk: NOTRUN -> [FAIL][16] ([i915#2389]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-glk6/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +5 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-kbl7/igt@gem_exec_susp...@basic-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-kbl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-apl: [PASS][19] -> [INCOMPLETE][20] ([i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-apl6/igt@gem_mmap_...@cpuset-basic-small-copy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-apl6/igt@gem_mmap_...@cpuset-basic-small-copy.html - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#198] / [i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10159/shard-skl3/igt@gem_mmap_...@cpuset-basic-small-copy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-skl10/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-apl: NOTRUN -> [INCOMPLETE][23] ([i915#3468]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20261/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-glk: [PASS][24] ->
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Get rid of fence error propagation
== Series Details ==
Series: drm/i915: Get rid of fence error propagation
URL : https://patchwork.freedesktop.org/series/90891/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
18e3ff57e304 drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 686c7c35abc2 ("drm/i915/gem:
Asynchronous cmdparser")'
#6:
This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser"). The
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 0edbb9ba1bfe ("drm/i915: Move
cmd parser pinning to execbuffer")'
#23:
This also reverts most of 0edbb9ba1bfe ("drm/i915: Move cmd parser
total: 2 errors, 0 warnings, 0 checks, 482 lines checked
0f6ab544bc55 drm/i915: Remove allow_alloc from i915_gem_object_get_sg*
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 0edbb9ba1bfe ("drm/i915: Move
cmd parser pinning to execbuffer")'
#6:
This reverts the rest of 0edbb9ba1bfe ("drm/i915: Move cmd parser
total: 1 errors, 0 warnings, 0 checks, 86 lines checked
f9732cd9968a drm/i915: Drop error handling from dma_fence_work
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 49 lines checked
afd44bdaa7c9 Revert "drm/i915: Propagate errors on awaiting already signaled
fences"
-:49: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Ekstrand ' != 'Signed-off-by:
Jason Ekstrand '
total: 0 errors, 1 warnings, 0 checks, 22 lines checked
59562703d27b Revert "drm/i915: Skip over MI_NOOP when parsing"
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a6c5e2aea704 ("drm/i915: Skip
over MI_NOOP when parsing")'
#6:
This reverts a6c5e2aea704 ("drm/i915: Skip over MI_NOOP when parsing").
total: 1 errors, 0 warnings, 0 checks, 83 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] Revert "drm/i915: Skip over MI_NOOP when parsing"
This reverts a6c5e2aea704 ("drm/i915: Skip over MI_NOOP when parsing").
It complicates the batch parsing code a bit and increases indentation
for no reason other than fast-skipping a command that userspace uses
only rarely. Sure, there may be IGT tests that fill batches with NOOPs
but that's not a case we should optimize for in the kernel. We should
optimize for code clarity instead.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 67 +-
1 file changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 056a233f443b4..8d34f05d22b75 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1470,42 +1470,43 @@ int intel_engine_cmd_parser(struct intel_engine_cs
*engine,
* space. Parsing should be faster in some cases this way.
*/
batch_end = cmd + batch_length / sizeof(*batch_end);
- while (*cmd != MI_BATCH_BUFFER_END) {
- u32 length = 1;
-
- if (*cmd != MI_NOOP) { /* MI_NOOP == 0 */
- desc = find_cmd(engine, *cmd, desc, _desc);
- if (!desc) {
- DRM_DEBUG("CMD: Unrecognized command:
0x%08X\n", *cmd);
- ret = -EINVAL;
- break;
- }
+ do {
+ u32 length;
- if (desc->flags & CMD_DESC_FIXED)
- length = desc->length.fixed;
- else
- length = (*cmd & desc->length.mask) +
LENGTH_BIAS;
+ if (*cmd == MI_BATCH_BUFFER_END)
+ break;
- if ((batch_end - cmd) < length) {
- DRM_DEBUG("CMD: Command length exceeds batch
length: 0x%08X length=%u batchlen=%td\n",
- *cmd,
- length,
- batch_end - cmd);
- ret = -EINVAL;
- break;
- }
+ desc = find_cmd(engine, *cmd, desc, _desc);
+ if (!desc) {
+ DRM_DEBUG("CMD: Unrecognized command: 0x%08X\n", *cmd);
+ ret = -EINVAL;
+ break;
+ }
- if (!check_cmd(engine, desc, cmd, length)) {
- ret = -EACCES;
- break;
- }
+ if (desc->flags & CMD_DESC_FIXED)
+ length = desc->length.fixed;
+ else
+ length = (*cmd & desc->length.mask) + LENGTH_BIAS;
- if (cmd_desc_is(desc, MI_BATCH_BUFFER_START)) {
- ret = check_bbstart(cmd, offset, length,
batch_length,
- batch_addr, shadow_addr,
- jump_whitelist);
- break;
- }
+ if ((batch_end - cmd) < length) {
+ DRM_DEBUG("CMD: Command length exceeds batch length:
0x%08X length=%u batchlen=%td\n",
+ *cmd,
+ length,
+ batch_end - cmd);
+ ret = -EINVAL;
+ break;
+ }
+
+ if (!check_cmd(engine, desc, cmd, length)) {
+ ret = -EACCES;
+ break;
+ }
+
+ if (cmd_desc_is(desc, MI_BATCH_BUFFER_START)) {
+ ret = check_bbstart(cmd, offset, length, batch_length,
+ batch_addr, shadow_addr,
+ jump_whitelist);
+ break;
}
if (!IS_ERR_OR_NULL(jump_whitelist))
@@ -1518,7 +1519,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs
*engine,
ret = -EINVAL;
break;
}
- }
+ } while (1);
if (trampoline) {
/*
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Signed-off-by: Jason Ekstrand
Reported-by: Marcin Slusarz
Cc: # v5.6+
Cc: Jason Ekstrand
Cc: Marcin Slusarz
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled
fences")
Signed-off-by: Daniel Vetter
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/i915_request.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 970d8f4986bbe..b796197c07722 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
- i915_sw_fence_set_error_once(>submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
continue;
- }
if (fence->context == rq->fence.context)
continue;
@@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq,
struct dma_fence *fence)
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
- i915_sw_fence_set_error_once(>submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
continue;
- }
/*
* Requests on the same timeline are explicitly ordered, along
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Drop error handling from dma_fence_work
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 +---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 +
drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 3 +--
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index daf9284ef1f54..f0435c6feb68b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -24,13 +24,11 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
}
-static int clflush_work(struct dma_fence_work *base)
+static void clflush_work(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
__do_clflush(clflush->obj);
-
- return 0;
}
static void clflush_release(struct dma_fence_work *base)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index a3a81bb8f2c36..5b33ef23d54c9 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -16,11 +16,8 @@ static void fence_complete(struct dma_fence_work *f)
static void fence_work(struct work_struct *work)
{
struct dma_fence_work *f = container_of(work, typeof(*f), work);
- int err;
- err = f->ops->work(f);
- if (err)
- dma_fence_set_error(>dma, err);
+ f->ops->work(f);
fence_complete(f);
dma_fence_put(>dma);
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index 2c409f11c5c59..d56806918d131 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -17,7 +17,7 @@ struct dma_fence_work;
struct dma_fence_work_ops {
const char *name;
- int (*work)(struct dma_fence_work *f);
+ void (*work)(struct dma_fence_work *f);
void (*release)(struct dma_fence_work *f);
};
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index a6cd0fa628477..03cdaa0f459ba 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -300,14 +300,13 @@ struct i915_vma_work {
unsigned int flags;
};
-static int __vma_bind(struct dma_fence_work *work)
+static void __vma_bind(struct dma_fence_work *work)
{
struct i915_vma_work *vw = container_of(work, typeof(*vw), base);
struct i915_vma *vma = vw->vma;
vma->ops->bind_vma(vw->vm, >stash,
vma, vw->cache_level, vw->flags);
- return 0;
}
static void __vma_release(struct dma_fence_work *work)
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Remove allow_alloc from i915_gem_object_get_sg*
This reverts the rest of 0edbb9ba1bfe ("drm/i915: Move cmd parser
pinning to execbuffer"). Now that the only user of i915_gem_object_get_sg
without allow_alloc has been removed, we can drop the parameter. This
portion of the revert was broken into its own patch to aid review.
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 -
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
3 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 2ebd79537aea9..329d848f3ff6d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -339,22 +339,22 @@ struct scatterlist *
__i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
struct i915_gem_object_page_iter *iter,
unsigned int n,
-unsigned int *offset, bool allow_alloc);
+unsigned int *offset);
static inline struct scatterlist *
i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
unsigned int n,
- unsigned int *offset, bool allow_alloc)
+ unsigned int *offset)
{
- return __i915_gem_object_get_sg(obj, >mm.get_page, n, offset,
allow_alloc);
+ return __i915_gem_object_get_sg(obj, >mm.get_page, n, offset);
}
static inline struct scatterlist *
i915_gem_object_get_sg_dma(struct drm_i915_gem_object *obj,
unsigned int n,
- unsigned int *offset, bool allow_alloc)
+ unsigned int *offset)
{
- return __i915_gem_object_get_sg(obj, >mm.get_dma_page, n, offset,
allow_alloc);
+ return __i915_gem_object_get_sg(obj, >mm.get_dma_page, n, offset);
}
struct page *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 7361971c177dd..19eb1b03ceedc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -466,8 +466,7 @@ struct scatterlist *
__i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
struct i915_gem_object_page_iter *iter,
unsigned int n,
-unsigned int *offset,
-bool allow_alloc)
+unsigned int *offset)
{
const bool dma = iter == >mm.get_dma_page;
struct scatterlist *sg;
@@ -489,9 +488,6 @@ __i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
if (n < READ_ONCE(iter->sg_idx))
goto lookup;
- if (!allow_alloc)
- goto manual_lookup;
-
mutex_lock(>lock);
/* We prefer to reuse the last sg so that repeated lookup of this
@@ -541,16 +537,7 @@ __i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
if (unlikely(n < idx)) /* insertion completed by another thread */
goto lookup;
- goto manual_walk;
-
-manual_lookup:
- idx = 0;
- sg = obj->mm.pages->sgl;
- count = __sg_page_count(sg);
-
-manual_walk:
- /*
-* In case we failed to insert the entry into the radixtree, we need
+ /* In case we failed to insert the entry into the radixtree, we need
* to look beyond the current sg.
*/
while (idx + count <= n) {
@@ -597,7 +584,7 @@ i915_gem_object_get_page(struct drm_i915_gem_object *obj,
unsigned int n)
GEM_BUG_ON(!i915_gem_object_has_struct_page(obj));
- sg = i915_gem_object_get_sg(obj, n, , true);
+ sg = i915_gem_object_get_sg(obj, n, );
return nth_page(sg_page(sg), offset);
}
@@ -623,7 +610,7 @@ i915_gem_object_get_dma_address_len(struct
drm_i915_gem_object *obj,
struct scatterlist *sg;
unsigned int offset;
- sg = i915_gem_object_get_sg_dma(obj, n, , true);
+ sg = i915_gem_object_get_sg_dma(obj, n, );
if (len)
*len = sg_dma_len(sg) - (offset << PAGE_SHIFT);
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 35069ca5d7deb..bd4bcef42d619 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1481,7 +1481,7 @@ intel_partial_pages(const struct i915_ggtt_view *view,
if (ret)
goto err_sg_alloc;
- iter = i915_gem_object_get_sg_dma(obj, view->partial.offset, ,
true);
+ iter = i915_gem_object_get_sg_dma(obj, view->partial.offset, );
GEM_BUG_ON(!iter);
sg = st->sgl;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser"). The
justification for this commit in the git history was a vague comment
about getting it out from under the struct_mutex. While this may
improve perf for some workloads on Gen7 platforms where we rely on the
command parser for features such as indirect rendering, no numbers were
provided to prove such an improvement. It claims to closed two
gitlab/bugzilla issues but with no explanation whatsoever as to why or
what bug it's fixing.
Meanwhile, by moving command parsing off to an async callback, it leaves
us with a problem of what to do on error. When things were synchronous,
EXECBUFFER2 would fail with an error code if parsing failed. When
moving it to async, we needed another way to handle that error and the
solution employed was to set an error on the dma_fence and then trust
that said error gets propagated to the client eventually. Moving back
to synchronous will help us untangle the fence error propagation mess.
This also reverts most of 0edbb9ba1bfe ("drm/i915: Move cmd parser
pinning to execbuffer") which is a refactor of some of our allocation
paths for asynchronous parsing. Now that everything is synchronous, we
don't need it.
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Reviewed-by: Jon Bloomfield
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 227 +-
.../i915/gem/selftests/i915_gem_execbuffer.c | 4 +
drivers/gpu/drm/i915/i915_cmd_parser.c| 132 +-
drivers/gpu/drm/i915/i915_drv.h | 7 +-
4 files changed, 91 insertions(+), 279 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 297143511f99b..a49da4b24d4d4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -25,10 +25,8 @@
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
#include "i915_gem_ioctls.h"
-#include "i915_sw_fence_work.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-#include "i915_memcpy.h"
struct eb_vma {
struct i915_vma *vma;
@@ -1456,6 +1454,10 @@ static u32 *reloc_gpu(struct i915_execbuffer *eb,
int err;
struct intel_engine_cs *engine = eb->engine;
+ /* If we need to copy for the cmdparser, we will stall anyway */
+ if (eb_use_cmdparser(eb))
+ return ERR_PTR(-EWOULDBLOCK);
+
if (!reloc_can_use_engine(engine)) {
engine = engine->gt->engine_class[COPY_ENGINE_CLASS][0];
if (!engine)
@@ -2372,217 +2374,6 @@ shadow_batch_pin(struct i915_execbuffer *eb,
return vma;
}
-struct eb_parse_work {
- struct dma_fence_work base;
- struct intel_engine_cs *engine;
- struct i915_vma *batch;
- struct i915_vma *shadow;
- struct i915_vma *trampoline;
- unsigned long batch_offset;
- unsigned long batch_length;
- unsigned long *jump_whitelist;
- const void *batch_map;
- void *shadow_map;
-};
-
-static int __eb_parse(struct dma_fence_work *work)
-{
- struct eb_parse_work *pw = container_of(work, typeof(*pw), base);
- int ret;
- bool cookie;
-
- cookie = dma_fence_begin_signalling();
- ret = intel_engine_cmd_parser(pw->engine,
- pw->batch,
- pw->batch_offset,
- pw->batch_length,
- pw->shadow,
- pw->jump_whitelist,
- pw->shadow_map,
- pw->batch_map);
- dma_fence_end_signalling(cookie);
-
- return ret;
-}
-
-static void __eb_parse_release(struct dma_fence_work *work)
-{
- struct eb_parse_work *pw = container_of(work, typeof(*pw), base);
-
- if (!IS_ERR_OR_NULL(pw->jump_whitelist))
- kfree(pw->jump_whitelist);
-
- if (pw->batch_map)
- i915_gem_object_unpin_map(pw->batch->obj);
- else
- i915_gem_object_unpin_pages(pw->batch->obj);
-
- i915_gem_object_unpin_map(pw->shadow->obj);
-
- if (pw->trampoline)
- i915_active_release(>trampoline->active);
- i915_active_release(>shadow->active);
- i915_active_release(>batch->active);
-}
-
-static const struct dma_fence_work_ops eb_parse_ops = {
- .name = "eb_parse",
- .work = __eb_parse,
- .release = __eb_parse_release,
-};
-
-static inline int
-__parser_mark_active(struct i915_vma *vma,
-struct intel_timeline *tl,
-struct dma_fence *fence)
-{
- struct intel_gt_buffer_pool_node *node = vma->private;
-
- return i915_active_ref(>active, tl->fence_context, fence);
-}
-
-static int
-parser_mark_active(struct eb_parse_work *pw,
[Intel-gfx] [PATCH 0/5] drm/i915: Get rid of fence error propagation
Fence error propagation is sketchy at best. Instead of explicitly handling fences which might have errors set in the code which is aware of errors, we just kick them down the line and hope that userspace knows what to do when a wait eventually fails. This is sketchy at best because most userspace isn't prepared to handle errors in those places. To make things worse, it allows errors to propagate across processes in unpredictable ways. This is causing hangs in one client to kill X11. Unfortunately, there's no quick path from here to there thanks to the fact that we're now running the command parser asynchronously and relying on fence errors for when it fails. This series first gets rid of asynchronous command parsing and then cleans up from there. There was never any real use-case for asynchronous parsing and the platforms that rely heavily on the command parser are old enough (Gen7) that, when we changed the way the command parser works, it wasn't really a change anyone was asking for anyway. I think we probably want this whole mess back-ported. I'm happy to take suggestions on the strategy there because the history there is a bit annoying and I'm not 100% sure where the Linux release cuts land. In any case, I'm happy to make a version of this series per-release if needed for Greg to back-port. Cc: Daniel Vetter Cc: Jon Bloomfield Jason Ekstrand (5): drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser" drm/i915: Remove allow_alloc from i915_gem_object_get_sg* drm/i915: Drop error handling from dma_fence_work Revert "drm/i915: Propagate errors on awaiting already signaled fences" Revert "drm/i915: Skip over MI_NOOP when parsing" drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 227 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 10 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +- .../i915/gem/selftests/i915_gem_execbuffer.c | 4 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- drivers/gpu/drm/i915/i915_cmd_parser.c| 199 --- drivers/gpu/drm/i915/i915_drv.h | 7 +- drivers/gpu/drm/i915/i915_request.c | 8 +- drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 +- drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 +- drivers/gpu/drm/i915/i915_vma.c | 3 +- 12 files changed, 141 insertions(+), 351 deletions(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/1] drm/i915/dg1: Add HWMON power sensor support
On 6/1/2021 5:42 PM, Dale B Stimson wrote: On 2021-06-01 14:39:11, Sundaresan, Sujaritha wrote: Date: Tue, 1 Jun 2021 14:39:11 -0700 From: "Sundaresan, Sujaritha" To: Dale B Stimson , intel-gfx@lists.freedesktop.org, dri-de...@lists.freedesktop.org CC: Jon Ewins , Jani Nikula Subject: Re: [PATCH v4 1/1] drm/i915/dg1: Add HWMON power sensor support User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 On 5/27/2021 5:44 PM, Dale B Stimson wrote: As part of the System Managemenent Interface (SMI), use the HWMON subsystem to display power utilization. The following standard HWMON power sensors are currently supported (and appropriately scaled): /sys/class/drm/card0/device/hwmon/hwmon - energy1_input - power1_cap - power1_max Some non-standard HWMON power information is also provided, such as enable bits and intervals. Signed-off-by: Dale B Stimson --- .../ABI/testing/sysfs-driver-intel-i915-hwmon | 116 +++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_hwmon.c | 757 ++ drivers/gpu/drm/i915/i915_hwmon.h | 42 + drivers/gpu/drm/i915/i915_reg.h | 52 ++ 8 files changed, 978 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon new file mode 100644 index 0..2ee7c413ca190 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon @@ -0,0 +1,116 @@ +What: /sys/devices/.../hwmon/hwmon/energy1_input +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RO. Energy input of device in microjoules. + + The returned textual representation is an unsigned integer + number that can be stored in 64-bits. Warning: The hardware + register is 32-bits wide and can overflow by wrapping around. + A single wrap-around between calls to read this value can + be detected and will be accounted for in the returned value. + At a power consumption of 1 watt, the 32-bit hardware register + would wrap-around approximately every 3 days. + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit is enabled - true or false. Hi Dale, This attribute should be read-only ? That is correct. The hardware implementation is read-only. Hi Dale, Got it. Then the description should probably be changed to "RO" above. + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit in milliwatts + +The power controller will throttle the operating frequency +if the power averaged over a window (typically seconds) +exceeds this limit. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_max_interval +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: +RW. Sustained power limit interval in milliseconds over +which sustained power is averaged. + +See power1_max_enable power1_max power1_max_interval + + Only supported for particular Intel i915 graphics platforms. + +What: /sys/devices/.../hwmon/hwmon/power1_cap_enable +Date: June 2021 +KernelVersion: 5.14 +Contact:dri-de...@lists.freedesktop.org +Description: + RW. Power burst limit is enabled - true or false + +See power1_cap_enable power1_cap + + Only supported for particular Intel i915 graphics platforms. + +What:
Re: [Intel-gfx] [PATCH] Revert "i915: use io_mapping_map_user"
Adding Jani and Rodrigo since drm-intel-fixes is on them.
-Daniel
On Wed, Jun 2, 2021 at 12:10 PM Matthew Auld
wrote:
>
> On Wed, 2 Jun 2021 at 09:01, Daniel Vetter wrote:
> >
> > On Wed, Jun 2, 2021 at 9:28 AM Matthew Auld
> > wrote:
> > >
> > > On Thu, 27 May 2021 at 19:52, Matthew Auld wrote:
> > > >
> > > > This reverts commit b739f125e4ebd73d10ed30a856574e13649119ed.
> > > >
> > > > We are unfortunately seeing more issues like we did in 293837b9ac8d
> > > > ("Revert "i915: fix remap_io_sg to verify the pgprot""), except this is
> > > > now for the vm_fault_gtt path, where we are now hitting the same
> > > > BUG_ON(!pte_none(*pte)):
> > > >
> > > > [10887.466150] kernel BUG at mm/memory.c:2183!
> > > > [10887.466162] invalid opcode: [#1] PREEMPT SMP PTI
> > > > [10887.466168] CPU: 0 PID: 7775 Comm: ffmpeg Tainted: G U
> > > > 5.13.0-rc3-CI-Nightly #1
> > > > [10887.466174] Hardware name: To Be Filled By O.E.M. To Be Filled By
> > > > O.E.M./J4205-ITX, BIOS P1.40 07/14/2017
> > > > [10887.466177] RIP: 0010:remap_pfn_range_notrack+0x30f/0x440
> > > > [10887.466188] Code: e8 96 d7 e0 ff 84 c0 0f 84 27 01 00 00 48 ba 00 f0
> > > > ff ff ff ff 0f 00 4c 89 e0 48 c1 e0 0c 4d 85 ed 75 96 48 21 d0 31 f6 eb
> > > > a9 <0f> 0b 48 39 37 0f 85 0e 01 00 00 48 8b 0c 24 48 39 4f 08 0f 85 00
> > > > [10887.466193] RSP: 0018:c90006e33c50 EFLAGS: 00010286
> > > > [10887.466198] RAX: 802f RBX: 7f5e0180 RCX:
> > > > 0028
> > > > [10887.466201] RDX: 0001 RSI: ea00 RDI:
> > > >
> > > > [10887.466204] RBP: ea33fea8 R08: 802f R09:
> > > > 8881072256e0
> > > > [10887.466207] R10: c9000b84fff8 R11: 17dab000 R12:
> > > > 00089f9f
> > > > [10887.466210] R13: 802f R14: 7f5e017e4000 R15:
> > > > 88800cffaf20
> > > > [10887.466213] FS: 7f5e04849640() GS:88827800()
> > > > knlGS:
> > > > [10887.466216] CS: 0010 DS: ES: CR0: 80050033
> > > > [10887.466220] CR2: 7fd9b191a2ac CR3: 0001829ac000 CR4:
> > > > 003506f0
> > > > [10887.466223] Call Trace:
> > > > [10887.466233] vm_fault_gtt+0x1ca/0x5d0 [i915]
> > > > [10887.466381] ? ktime_get+0x38/0x90
> > > > [10887.466389] __do_fault+0x37/0x90
> > > > [10887.466395] __handle_mm_fault+0xc46/0x1200
> > > > [10887.466402] handle_mm_fault+0xce/0x2a0
> > > > [10887.466407] do_user_addr_fault+0x1c5/0x660
> > > >
> > > > Reverting this commit is reported to fix the issue.
> > > >
> > > > Reported-by: Eero Tamminen
> > > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/3519
> > > > Fixes: b739f125e4eb ("i915: use io_mapping_map_user")
> > > > Cc: Christoph Hellwig
> > > > Cc: Daniel Vetter
> > > > Signed-off-by: Matthew Auld
> > >
> > > Could someone give an ack for this? There are at least two separate
> > > user reports for this issue.
> >
> > I was assuming Christoph would ack this, but fwiw:
> >
> > Acked-by: Daniel Vetter
>
> Pushed to gt-next. Thanks for the ack Daniel.
>
> >
> > Also adding Joonas to make sure this doesn't miss the -fixes pull
> > request train. Also can't hurt to cc Linus since he reverted the other
> > part of this already in -rc3.
> > -Daniel
> > >
> > > > ---
> > > > drivers/gpu/drm/i915/Kconfig | 1 -
> > > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 9 ++---
> > > > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > > > drivers/gpu/drm/i915/i915_mm.c | 44
> > > > 4 files changed, 52 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> > > > index 93f4d059fc89..1e1cb245fca7 100644
> > > > --- a/drivers/gpu/drm/i915/Kconfig
> > > > +++ b/drivers/gpu/drm/i915/Kconfig
> > > > @@ -20,7 +20,6 @@ config DRM_I915
> > > > select INPUT if ACPI
> > > > select ACPI_VIDEO if ACPI
> > > > select ACPI_BUTTON if ACPI
> > > > - select IO_MAPPING
> > > > select SYNC_FILE
> > > > select IOSF_MBI
> > > > select CRC32
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > index f6fe5cb01438..8598a1c78a4c 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > @@ -367,10 +367,11 @@ static vm_fault_t vm_fault_gtt(struct vm_fault
> > > > *vmf)
> > > > goto err_unpin;
> > > >
> > > > /* Finally, remap it using the new GTT offset */
> > > > - ret = io_mapping_map_user(>iomap, area, area->vm_start +
> > > > - (vma->ggtt_view.partial.offset << PAGE_SHIFT),
> > > > - (ggtt->gmadr.start + vma->node.start) >>
> > > > PAGE_SHIFT,
> > > > - min_t(u64, vma->size, area->vm_end -
> > > > area->vm_start));
> > > > + ret =
Re: [Intel-gfx] [PATCH v4 13/17] drm/i915/pxp: Enable PXP power management
On Mon, May 24, 2021 at 10:47:59PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the
> session state might still be marked as alive after resume. Therefore,
> we should consider the session as dead on suspend and invalidate all the
> objects. The session will be automatically restarted on the first
> protected submission on resume.
>
> v2: runtime suspend also invalidates the keys
> v3: fix return codes, simplify rpm ops (Chris), use the new worker func
> v4: invalidate the objects on suspend, don't re-create the arb sesson on
> resume (delayed to first submission).
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/gt/intel_gt_pm.c| 15 +++-
> drivers/gpu/drm/i915/i915_drv.c | 2 +
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 11 --
> drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 40
> drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 23 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 38 ++-
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 9 +
> 8 files changed, 124 insertions(+), 15 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 29331bbb3e98..9cce0bf9a50f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -278,6 +278,7 @@ i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_irq.o \
> + pxp/intel_pxp_pm.o \
> pxp/intel_pxp_session.o \
> pxp/intel_pxp_tee.o
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index aef3084e8b16..91151a02f7a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -19,6 +19,7 @@
> #include "intel_rc6.h"
> #include "intel_rps.h"
> #include "intel_wakeref.h"
> +#include "pxp/intel_pxp_pm.h"
>
> static void user_forcewake(struct intel_gt *gt, bool suspend)
> {
> @@ -265,6 +266,8 @@ int intel_gt_resume(struct intel_gt *gt)
>
> intel_uc_resume(>uc);
>
> + intel_pxp_resume(>pxp);
> +
> user_forcewake(gt, false);
>
> out_fw:
> @@ -299,6 +302,7 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
> user_forcewake(gt, true);
> wait_for_suspend(gt);
>
> + intel_pxp_suspend(>pxp);
> intel_uc_suspend(>uc);
> }
>
> @@ -349,6 +353,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
>
> void intel_gt_runtime_suspend(struct intel_gt *gt)
> {
> + intel_pxp_suspend(>pxp);
> intel_uc_runtime_suspend(>uc);
>
> GT_TRACE(gt, "\n");
> @@ -356,11 +361,19 @@ void intel_gt_runtime_suspend(struct intel_gt *gt)
>
> int intel_gt_runtime_resume(struct intel_gt *gt)
> {
> + int ret;
> +
> GT_TRACE(gt, "\n");
> intel_gt_init_swizzling(gt);
> intel_ggtt_restore_fences(gt->ggtt);
>
> - return intel_uc_runtime_resume(>uc);
> + ret = intel_uc_runtime_resume(>uc);
> + if (ret)
> + return ret;
> +
> + intel_pxp_resume(>pxp);
> +
> + return 0;
> }
>
> static ktime_t __intel_gt_get_awake_time(const struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 2f06bb7b3ed2..6543e5577709 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -68,6 +68,8 @@
> #include "gt/intel_gt_pm.h"
> #include "gt/intel_rc6.h"
>
> +#include "pxp/intel_pxp_pm.h"
> +
> #include "i915_debugfs.h"
> #include "i915_drv.h"
> #include "i915_ioc32.h"
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> index a230d0034e50..9e5847c653f2 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> @@ -9,6 +9,7 @@
> #include "gt/intel_gt_irq.h"
> #include "i915_irq.h"
> #include "i915_reg.h"
> +#include "intel_runtime_pm.h"
>
> /**
> * intel_pxp_irq_handler - Handles PXP interrupts.
> @@ -62,11 +63,13 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
> struct intel_gt *gt = pxp_to_gt(pxp);
>
> spin_lock_irq(>irq_lock);
> - if (!pxp->irq_enabled) {
> +
> + if (!pxp->irq_enabled)
> WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_KCR));
> - __pxp_set_interrupts(gt, GEN12_PXP_INTERRUPTS);
> - pxp->irq_enabled = true;
> - }
> +
> + __pxp_set_interrupts(gt, GEN12_PXP_INTERRUPTS);
> + pxp->irq_enabled = true;
why?
and if we really need this maybe worth a squash on the other
Re: [Intel-gfx] [PATCH v4 10/17] drm/i915/pxp: Implement PXP irq handler
On Mon, May 24, 2021 at 10:47:56PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> The HW will generate a teardown interrupt when session termination is
> required, which requires i915 to submit a terminating batch. Once the HW
> is done with the termination it will generate another interrupt, at
> which point it is safe to re-create the session.
>
> Since the termination and re-creation flow is something we want to
> trigger from the driver as well, use a common work function that can be
> called both from the irq handler and from the driver set-up flows, which
> has the addded benefit of allowing us to skip any extra locks because
> the work itself serializes the operations.
>
> v2: use struct completion instead of bool (Chris)
> v3: drop locks, clean up functions and improve comments (Chris),
> move to common work function.
> v4: improve comments, simplify wait logic (Rodrigo)
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/gt/intel_gt_irq.c | 7 ++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 66 +++--
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 8 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 97
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 32 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 54 ++-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 8 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 18
> 11 files changed, 281 insertions(+), 16 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0fba97014512..29331bbb3e98 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -277,6 +277,7 @@ i915-y += i915_perf.o
> i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_cmd.o \
> + pxp/intel_pxp_irq.o \
> pxp/intel_pxp_session.o \
> pxp/intel_pxp_tee.o
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index 9fc6c912a4e5..7c4ec8880b1a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -13,6 +13,7 @@
> #include "intel_lrc_reg.h"
> #include "intel_uncore.h"
> #include "intel_rps.h"
> +#include "pxp/intel_pxp_irq.h"
>
> static void guc_irq_handler(struct intel_guc *guc, u16 iir)
> {
> @@ -106,6 +107,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
> instance,
> if (instance == OTHER_GTPM_INSTANCE)
> return gen11_rps_irq_handler(>rps, iir);
>
> + if (instance == OTHER_KCR_INSTANCE)
> + return intel_pxp_irq_handler(>pxp, iir);
> +
> WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
> instance, iir);
> }
> @@ -232,6 +236,9 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK, ~0);
> +
> + intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_ENABLE, 0);
> + intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_MASK, ~0);
> }
>
> void gen11_gt_irq_postinstall(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4dbe79009c0e..297671d78076 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8023,6 +8023,7 @@ enum {
> /* irq instances for OTHER_CLASS */
> #define OTHER_GUC_INSTANCE 0
> #define OTHER_GTPM_INSTANCE 1
> +#define OTHER_KCR_INSTANCE 4
>
> #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index e48debb5ca22..6b0e7170c29b 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -2,7 +2,9 @@
> /*
> * Copyright(c) 2020 Intel Corporation.
> */
> +#include
> #include "intel_pxp.h"
> +#include "intel_pxp_irq.h"
> #include "intel_pxp_session.h"
> #include "intel_pxp_tee.h"
> #include "gt/intel_context.h"
> @@ -66,6 +68,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
> if (!HAS_PXP(gt->i915))
> return;
>
> + /*
> + * we'll use the completion to check if there is a termination pending,
> + * so we start it as completed and we reinit it when a termination
> + * is triggered.
> + */
> + init_completion(>termination);
> + complete_all(>termination);
> +
> +
Re: [Intel-gfx] [PATCH v4 10/17] drm/i915/pxp: Implement PXP irq handler
On Mon, May 24, 2021 at 10:47:56PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> The HW will generate a teardown interrupt when session termination is
> required, which requires i915 to submit a terminating batch. Once the HW
> is done with the termination it will generate another interrupt, at
> which point it is safe to re-create the session.
>
> Since the termination and re-creation flow is something we want to
> trigger from the driver as well, use a common work function that can be
> called both from the irq handler and from the driver set-up flows, which
> has the addded benefit of allowing us to skip any extra locks because
> the work itself serializes the operations.
>
> v2: use struct completion instead of bool (Chris)
> v3: drop locks, clean up functions and improve comments (Chris),
> move to common work function.
> v4: improve comments, simplify wait logic (Rodrigo)
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/gt/intel_gt_irq.c | 7 ++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 66 +++--
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 8 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 97
> drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 32 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 54 ++-
> drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 8 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 18
> 11 files changed, 281 insertions(+), 16 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0fba97014512..29331bbb3e98 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -277,6 +277,7 @@ i915-y += i915_perf.o
> i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_cmd.o \
> + pxp/intel_pxp_irq.o \
> pxp/intel_pxp_session.o \
> pxp/intel_pxp_tee.o
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index 9fc6c912a4e5..7c4ec8880b1a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -13,6 +13,7 @@
> #include "intel_lrc_reg.h"
> #include "intel_uncore.h"
> #include "intel_rps.h"
> +#include "pxp/intel_pxp_irq.h"
>
> static void guc_irq_handler(struct intel_guc *guc, u16 iir)
> {
> @@ -106,6 +107,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
> instance,
> if (instance == OTHER_GTPM_INSTANCE)
> return gen11_rps_irq_handler(>rps, iir);
>
> + if (instance == OTHER_KCR_INSTANCE)
> + return intel_pxp_irq_handler(>pxp, iir);
> +
> WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
> instance, iir);
> }
> @@ -232,6 +236,9 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK, ~0);
> +
> + intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_ENABLE, 0);
> + intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_MASK, ~0);
> }
>
> void gen11_gt_irq_postinstall(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4dbe79009c0e..297671d78076 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8023,6 +8023,7 @@ enum {
> /* irq instances for OTHER_CLASS */
> #define OTHER_GUC_INSTANCE 0
> #define OTHER_GTPM_INSTANCE 1
> +#define OTHER_KCR_INSTANCE 4
>
> #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index e48debb5ca22..6b0e7170c29b 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -2,7 +2,9 @@
> /*
> * Copyright(c) 2020 Intel Corporation.
> */
> +#include
> #include "intel_pxp.h"
> +#include "intel_pxp_irq.h"
> #include "intel_pxp_session.h"
> #include "intel_pxp_tee.h"
> #include "gt/intel_context.h"
> @@ -66,6 +68,16 @@ void intel_pxp_init(struct intel_pxp *pxp)
> if (!HAS_PXP(gt->i915))
> return;
>
> + /*
> + * we'll use the completion to check if there is a termination pending,
> + * so we start it as completed and we reinit it when a termination
> + * is triggered.
> + */
> + init_completion(>termination);
> + complete_all(>termination);
> +
> +
Re: [Intel-gfx] [PATCH 1/7] drm/i915/gt: replace IS_GEN and friends with IS_GRAPHICS_VER
On Tue, Jun 01, 2021 at 11:34:39PM -0700, Lucas De Marchi wrote: > On Tue, Jun 01, 2021 at 01:39:25PM -0700, Matt Roper wrote: > > On Tue, Jun 01, 2021 at 12:13:17PM -0700, Lucas De Marchi wrote: > > > On Tue, Jun 01, 2021 at 10:30:55AM -0700, Matt Roper wrote: > > > > On Tue, Jun 01, 2021 at 10:15:14AM -0700, Lucas De Marchi wrote: > > > > > On Tue, Jun 01, 2021 at 09:58:34AM -0700, Matt Roper wrote: > > > > > > On Thu, May 27, 2021 at 11:16:54AM -0700, Lucas De Marchi wrote: > > > > > > > This was done by the following semantic patch: > > > > > > > > > > > > Is the commit message here out-of-date? The cocci doesn't appear to > > > > > > match the diff anymore. IS_GRAPHICS_VER() is the range macro now > > > > > > and > > > > > > IS_GEN is being replaced with a direct "==" comparison. > > > > > > > > > > not necessarily, it's included in "and friends...". Maybe rewording to > > > > > something like "replace gen-based macros with new ver-based ones" > > > > > would > > > > > make it clearer? > > > > > > > > I mean that running the coccinelle rules below through spatch won't > > > > generate the code diff here; it would generate a completely different > > > > patch (that I don't think would build properly either). > > > > > > oh, ok. I fixed the issues in the .cocci and forgot to update the commit > > > message. Thanks. > > > > > > Lucas De Marchi > > > > Aside from the commit messages needing updated Coccinelle rules, the > > code deltas look correct to me. > > > > Reviewed-by: Matt Roper > > humn... is that to the series or only this commit? Sorry, that was meant for the whole series. Matt > > Lucas De Marchi -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915
On 25/05/2021 17:45, Matthew Brost wrote: On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote: On 06/05/2021 20:13, Matthew Brost wrote: Basic GuC submission support. This is the first bullet point in the upstreaming plan covered in the following RFC [1]. At a very high level the GuC is a piece of firmware which sits between the i915 and the GPU. It offloads some of the scheduling of contexts from the i915 and programs the GPU to submit contexts. The i915 communicates with the GuC and the GuC communicates with the GPU. GuC submission will be disabled by default on all current upstream platforms behind a module parameter - enable_guc. A value of 3 will enable submission and HuC loading via the GuC. GuC submission should work on all gen11+ platforms assuming the GuC firmware is present. This is a huge series and it is completely unrealistic to merge all of these patches at once. Fortunately I believe we can break down the series into different merges: 1. Merge Chris Wilson's patches. These have already been reviewed upstream and I fully agree with these patches as a precursor to GuC submission. 2. Update to GuC 60.1.2. These are largely Michal's patches. 3. Turn on GuC/HuC auto mode by default. 4. Additional patches needed to support GuC submission. This is any patch not covered by 1-3 in the first 34 patches. e.g. 'Engine relative MMIO' 5. GuC submission support. Patches number 35+. These all don't have to merge at once though as we don't actually allow GuC submission until the last patch of this series. For the GuC backend/submission part only - it seems to me none of my review comments I made in December 2019 have been implemented. At that point I I wouldn't say none of the fixes have done, lots have just not everything you wanted. stated, and this was all internally at the time mind you, that I do not think the series is ready and there were several high level issues that would need to be sorted out. I don't think I gave my ack or r-b back then and the promise was a few things would be worked on post (internal) merge. That was supposed to include upstream refactoring to enable GuC better slotting in as a backed. Fast forward a year and a half later and the only progress we had in this area has been deleted. From the top of my head, and having glanced the series as posted: * Self-churn factor in the series is too high. Not sure what you mean by this? The patches have been reworked internally too much? No, I meant series adds and removes, changes the same code a bit much which makes it harder to review. It is much easier when the flow is logical and typical, where it starts with refactoring, generalising, building infrastructure and then plugging bits in, than it is to review patches which add stuff which then get removed or changed significantly a few patches down the line. * Patch ordering issues. We are going to clean up some of the ordering as these 97 patches are posted in smaller mergeable series but at the end of the day this is a bit of a bikeshed. GuC submission can't be turned until patch 97 so IMO it really isn't all that big of a deal the order of which patches before that land as we are not breaking anything. Yes some leeway for ordering is fine. * GuC context state machine is way too dodgy to have any confidence it can be read and race conditions understood. I know you don't really like the state machine but no other real way to not have DoS on resources and no real way to fairly distribute guc_ids without it. I know you have had other suggestions here but none of your suggestions either will work or they are no less complicated in the end. For what it is worth, the state machine will get simplified when we hook into the DRM scheduler as won't have to deal with submitting from IRQ contexts in the backend or having more than 1 request in the backend at a time. Dunno. A mix of self-churn, locks, inconsistent naming, verbosity and magic makes it super hard to review. States in functions like guc_context_ban, guc_context_sched_disable, guc_context_block, .. I find it impossible to follow what's going on. Some under lock, some outside, jumps, returns, add magic two .. Perhaps it is just me so wait and see what other reviewers will think. * Context pinning code with it's magical two adds, subtract and cmpxchg is dodgy as well. Daniele tried to remove this and it proved quite difficult + created even more races in the backend code. This was prior to the pre-pin and post-unpin code which makes this even more difficult to fix as I believe these functions would need to be removed first. Not saying we can't revisit this someday but I personally really like it - it is a clever way to avoid reentering the pin / unpin code while asynchronous things are happening rather than some complex locking scheme. Lastly, this code has proved incredibly stable as I don't think we've had to fix a single thing in this area since we've been
Re: [Intel-gfx] [RFC PATCH 65/97] drm/i915: Reset GPU immediately if submission is disabled
On 06/05/2021 20:14, Matthew Brost wrote:
If submission is disabled by the backend for any reason, reset the GPU
immediately in the heartbeat code.
Okay that's what, but why is also often good to have in commit messages.
Regards,
Tvrtko
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 63 +++
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 4 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 9 +++
drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
drivers/gpu/drm/i915/i915_scheduler.h | 6 ++
drivers/gpu/drm/i915/i915_scheduler_types.h | 3 +
6 files changed, 78 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index b6a305e6a974..a8495364d906 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -70,12 +70,30 @@ static void show_heartbeat(const struct i915_request *rq,
{
struct drm_printer p = drm_debug_printer("heartbeat");
- intel_engine_dump(engine, ,
- "%s heartbeat {seqno:%llx:%lld, prio:%d} not
ticking\n",
- engine->name,
- rq->fence.context,
- rq->fence.seqno,
- rq->sched.attr.priority);
+ if (!rq) {
+ intel_engine_dump(engine, ,
+ "%s heartbeat not ticking\n",
+ engine->name);
+ } else {
+ intel_engine_dump(engine, ,
+ "%s heartbeat {seqno:%llx:%lld, prio:%d} not
ticking\n",
+ engine->name,
+ rq->fence.context,
+ rq->fence.seqno,
+ rq->sched.attr.priority);
+ }
+}
+
+static void
+reset_engine(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ show_heartbeat(rq, engine);
+
+ intel_gt_handle_error(engine->gt, engine->mask,
+ I915_ERROR_CAPTURE,
+ "stopped heartbeat on %s",
+ engine->name);
}
static void heartbeat(struct work_struct *wrk)
@@ -102,6 +120,11 @@ static void heartbeat(struct work_struct *wrk)
if (intel_gt_is_wedged(engine->gt))
goto out;
+ if (i915_sched_engine_disabled(engine->sched_engine)) {
+ reset_engine(engine, engine->heartbeat.systole);
+ goto out;
+ }
+
if (engine->heartbeat.systole) {
long delay = READ_ONCE(engine->props.heartbeat_interval_ms);
@@ -139,13 +162,7 @@ static void heartbeat(struct work_struct *wrk)
engine->sched_engine->schedule(rq, );
local_bh_enable();
} else {
- if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
- show_heartbeat(rq, engine);
-
- intel_gt_handle_error(engine->gt, engine->mask,
- I915_ERROR_CAPTURE,
- "stopped heartbeat on %s",
- engine->name);
+ reset_engine(engine, rq);
}
rq->emitted_jiffies = jiffies;
@@ -194,6 +211,26 @@ void intel_engine_park_heartbeat(struct intel_engine_cs
*engine)
i915_request_put(fetch_and_zero(>heartbeat.systole));
}
+void intel_gt_unpark_heartbeats(struct intel_gt *gt)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, gt, id)
+ if (intel_engine_pm_is_awake(engine))
+ intel_engine_unpark_heartbeat(engine);
+
+}
+
+void intel_gt_park_heartbeats(struct intel_gt *gt)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, gt, id)
+ intel_engine_park_heartbeat(engine);
+}
+
void intel_engine_init_heartbeat(struct intel_engine_cs *engine)
{
INIT_DELAYED_WORK(>heartbeat.work, heartbeat);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
index a488ea3e84a3..5da6d809a87a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -7,6 +7,7 @@
#define INTEL_ENGINE_HEARTBEAT_H
struct intel_engine_cs;
+struct intel_gt;
void intel_engine_init_heartbeat(struct intel_engine_cs *engine);
@@ -16,6 +17,9 @@ int intel_engine_set_heartbeat(struct intel_engine_cs *engine,
void intel_engine_park_heartbeat(struct intel_engine_cs *engine);
void intel_engine_unpark_heartbeat(struct intel_engine_cs
Re: [Intel-gfx] [RFC PATCH 64/97] drm/i915/guc: Reset implementation for new GuC interface
On 06/05/2021 20:14, Matthew Brost wrote:
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a fallback and this code path
is also required if the GuC dies.
With the new GuC interface it is not possible to reset individual
engines - it is only possible to reset the GPU entirely. This patch
forces an entire chip reset if any engine hangs.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 3 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +
.../drm/i915/gt/intel_execlists_submission.c | 40 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 22 +
drivers/gpu/drm/i915/gt/mock_engine.c | 31 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 16 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 580 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 34 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 3 +
drivers/gpu/drm/i915/i915_request.c | 41 +-
drivers/gpu/drm/i915/i915_request.h | 2 +
15 files changed, 643 insertions(+), 174 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index b24a1b7a3f88..2f01437056a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -392,6 +392,9 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
spin_lock_init(>guc_state.lock);
INIT_LIST_HEAD(>guc_state.fences);
+ spin_lock_init(>guc_active.lock);
+ INIT_LIST_HEAD(>guc_active.requests);
+
ce->guc_id = GUC_INVALID_LRC_ID;
INIT_LIST_HEAD(>guc_id_link);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 6945963a31ba..b63c8cf7823b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -165,6 +165,13 @@ struct intel_context {
struct list_head fences;
} guc_state;
+ struct {
+ /** lock: protects everything in guc_active */
+ spinlock_t lock;
+ /** requests: active requests on this context */
+ struct list_head requests;
+ } guc_active;
More accounting, yeah, this is more of that where GuC gives with one
hand and takes away with the other. :(
+
/* GuC scheduling state that does not require a lock. */
atomic_t guc_sched_state_no_lock;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index f7b6eed586ce..b84562b2708b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -432,6 +432,12 @@ struct intel_engine_cs {
*/
void(*release)(struct intel_engine_cs *engine);
+ /*
+* Add / remove request from engine active tracking
+*/
+ void(*add_active_request)(struct i915_request *rq);
+ void(*remove_active_request)(struct i915_request *rq);
+
struct intel_engine_execlists execlists;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 396b1356ea3e..54518b64bdbd 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3117,6 +3117,42 @@ static void execlists_park(struct intel_engine_cs
*engine)
cancel_timer(>execlists.preempt);
}
+static void add_to_engine(struct i915_request *rq)
+{
+ lockdep_assert_held(>engine->sched_engine->lock);
+ list_move_tail(>sched.link, >engine->sched_engine->requests);
+}
+
+static void remove_from_engine(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine, *locked;
+
+ /*
+* Virtual engines complicate acquiring the engine timeline lock,
+* as their rq->engine pointer is not stable until under that
+* engine lock. The simple ploy we use is to take the lock then
+* check that the rq still belongs to the newly locked engine.
+*/
+ locked = READ_ONCE(rq->engine);
+ spin_lock_irq(>sched_engine->lock);
+ while (unlikely(locked != (engine = READ_ONCE(rq->engine {
+ spin_unlock(>sched_engine->lock);
+ spin_lock(>sched_engine->lock);
+ locked = engine;
+ }
Could use i915_request_active_engine although tbf I don't remember why I
did not convert
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3)
== Series Details == Series: drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3) URL : https://patchwork.freedesktop.org/series/90818/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10160 -> Patchwork_20264 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20264 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20264, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20264: ### IGT changes ### Possible regressions * igt@gem_exec_parallel@engines@fds: - fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10160/fi-apl-guc/igt@gem_exec_parallel@engi...@fds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/fi-apl-guc/igt@gem_exec_parallel@engi...@fds.html Known issues Here are the changes found in Patchwork_20264 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@requests: - fi-kbl-soraka: [PASS][3] -> [INCOMPLETE][4] ([i915#2782]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10160/fi-kbl-soraka/igt@i915_selftest@l...@requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/fi-kbl-soraka/igt@i915_selftest@l...@requests.html * igt@kms_frontbuffer_tracking@basic: - fi-tgl-u2: [PASS][5] -> [FAIL][6] ([i915#2416]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10160/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/fi-tgl-u2/igt@kms_frontbuffer_track...@basic.html Warnings * igt@i915_selftest@live@execlists: - fi-icl-u2: [INCOMPLETE][7] ([i915#2782] / [i915#3462]) -> [DMESG-FAIL][8] ([i915#3462]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10160/fi-icl-u2/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/fi-icl-u2/igt@i915_selftest@l...@execlists.html - fi-cml-s: [INCOMPLETE][9] ([i915#3462]) -> [DMESG-FAIL][10] ([i915#3462]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10160/fi-cml-s/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/fi-cml-s/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-icl-u2: [FAIL][11] ([i915#2782] / [i915#3363]) -> [FAIL][12] ([i915#2426] / [i915#2782] / [i915#3363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10160/fi-icl-u2/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/fi-icl-u2/igt@run...@aborted.html - fi-kbl-soraka: [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][14] ([i915#1436] / [i915#3363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10160/fi-kbl-soraka/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/fi-kbl-soraka/igt@run...@aborted.html [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2416]: https://gitlab.freedesktop.org/drm/intel/issues/2416 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363 [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462 Participating hosts (46 -> 40) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10160 -> Patchwork_20264 CI-20190529: 20190529 CI_DRM_10160: b45c894e406d6e822f0fbf9d35ba4c9255707111 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6098: 1fbc1e7d602f96a7f4e2b95057eef994656b8e74 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_20264: 056e7f6133a97a43c5ffea6076524018312bbf26 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 056e7f6133a9 drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20264/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/panfrost: Use xarray and helpers for depedency tracking
On 21/05/2021 10:09, Daniel Vetter wrote:
> More consistency and prep work for the next patch.
>
> Aside: I wonder whether we shouldn't just move this entire xarray
> business into the scheduler so that not everyone has to reinvent the
> same wheels. Cc'ing some scheduler people for this too.
>
> Cc: "Christian König"
> Cc: Luben Tuikov
> Cc: Alex Deucher
> Cc: Lee Jones
> Cc: Steven Price
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Alyssa Rosenzweig
> Cc: Sumit Semwal
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Daniel Vetter
Two comments below, but otherwise looks like a nice cleanup.
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 41 -
> drivers/gpu/drm/panfrost/panfrost_job.c | 61 ++---
> drivers/gpu/drm/panfrost/panfrost_job.h | 8 ++--
> 3 files changed, 46 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index ca07098a6141..7977b4752b5c 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -137,12 +137,6 @@ panfrost_lookup_bos(struct drm_device *dev,
> if (!job->bo_count)
> return 0;
>
> - job->implicit_fences = kvmalloc_array(job->bo_count,
> - sizeof(struct dma_fence *),
> - GFP_KERNEL | __GFP_ZERO);
> - if (!job->implicit_fences)
> - return -ENOMEM;
> -
> ret = drm_gem_objects_lookup(file_priv,
>(void __user *)(uintptr_t)args->bo_handles,
>job->bo_count, >bos);
> @@ -173,7 +167,7 @@ panfrost_lookup_bos(struct drm_device *dev,
> }
>
> /**
> - * panfrost_copy_in_sync() - Sets up job->in_fences[] with the sync objects
> + * panfrost_copy_in_sync() - Sets up job->deps with the sync objects
> * referenced by the job.
> * @dev: DRM device
> * @file_priv: DRM file for this fd
> @@ -193,22 +187,14 @@ panfrost_copy_in_sync(struct drm_device *dev,
> {
> u32 *handles;
> int ret = 0;
> - int i;
> + int i, in_fence_count;
>
> - job->in_fence_count = args->in_sync_count;
> + in_fence_count = args->in_sync_count;
>
> - if (!job->in_fence_count)
> + if (!in_fence_count)
> return 0;
>
> - job->in_fences = kvmalloc_array(job->in_fence_count,
> - sizeof(struct dma_fence *),
> - GFP_KERNEL | __GFP_ZERO);
> - if (!job->in_fences) {
> - DRM_DEBUG("Failed to allocate job in fences\n");
> - return -ENOMEM;
> - }
> -
> - handles = kvmalloc_array(job->in_fence_count, sizeof(u32), GFP_KERNEL);
> + handles = kvmalloc_array(in_fence_count, sizeof(u32), GFP_KERNEL);
> if (!handles) {
> ret = -ENOMEM;
> DRM_DEBUG("Failed to allocate incoming syncobj handles\n");
> @@ -217,16 +203,23 @@ panfrost_copy_in_sync(struct drm_device *dev,
>
> if (copy_from_user(handles,
> (void __user *)(uintptr_t)args->in_syncs,
> -job->in_fence_count * sizeof(u32))) {
> +in_fence_count * sizeof(u32))) {
> ret = -EFAULT;
> DRM_DEBUG("Failed to copy in syncobj handles\n");
> goto fail;
> }
>
> - for (i = 0; i < job->in_fence_count; i++) {
> + for (i = 0; i < in_fence_count; i++) {
> + struct dma_fence *fence;
> +
> ret = drm_syncobj_find_fence(file_priv, handles[i], 0, 0,
> - >in_fences[i]);
> - if (ret == -EINVAL)
> + );
> + if (ret)
> + goto fail;
> +
> + ret = drm_gem_fence_array_add(>deps, fence);
> +
> + if (ret)
> goto fail;
> }
>
> @@ -264,6 +257,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
> void *data,
>
> kref_init(>refcount);
>
> + xa_init_flags(>deps, XA_FLAGS_ALLOC);
> +
> job->pfdev = pfdev;
> job->jc = args->jc;
> job->requirements = args->requirements;
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index f5d39ee14ab5..707d912ff64a 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -196,14 +196,21 @@ static void panfrost_job_hw_submit(struct panfrost_job
> *job, int js)
> job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
> }
>
> -static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
> -int bo_count,
> -struct dma_fence **implicit_fences)
> +static int panfrost_acquire_object_fences(struct
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix incorrect assert about pending power domain async-put work
On Wed, Jun 02, 2021 at 02:35:28PM +0530, Anshuman Gupta wrote:
> On 2021-05-26 at 20:07:28 +0530, Imre Deak wrote:
> > It's possible that an already dequeued put_async_work() will release the
> > reference (*) that was put asynchronously after the dequeue happened.
> > This leaves an async-put work pending, without any reference to release.
> > A subsequent async-put may trigger the
> >
> > drm_WARN_ON(!queue_delayed_work(_domains->async_put_work));
> >
> > warn due to async_put_work() still pending. To avoid the warn, cancel
> > the pending async_put_work() when releasing the reference at (*) above.
>
> Not able to visulize the race here between __intel_display_power_put_async
> and intel_display_power_put_async_work() considering both are protected by
> power_domains->lock.
>
> queue_delayed_work_on() documentation says following about return value.
> "Return: %false if @work was already on a queue, %true otherwise."
> AFAIU from the doc, queue_delayed_work will return false only when
> work was in queue after dequeued put_async_work() it should return true ?
Yes, and so the WARN is triggered when __intel_display_power_put_async()
tries to queue a work when one is already pending in the queue:
1. get(A)
2. put_async(A) -> queues put_async_work()
3. put_async_work() dequeued, blocking on power_domains->lock
4. get(A) -> grab_async_put_ref(), reacquires the ref that was put in 2.
5. put_async(A) -> queues put_async_work()
6. put_async_work() dequeued in 3. unblocks, releases the ref that was put in
5., put_async_work() queued in 5. still pending in the queue, without
any reference to release.
7. get(A)
8. put_async(A) -> tries to queue put_async_work(), but it's already
pending -> WARN triggers.
The patch avoids the WARN in 8 by cancelling the queued work at 6.
> Thanks,
> Anshuman Gupta.
> >
> > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/3421
> > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2289
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_display_power.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 2f7d1664c4738..a95bbf23e6b7c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -2263,6 +2263,12 @@ intel_display_power_put_async_work(struct
> > work_struct *work)
> > fetch_and_zero(_domains->async_put_domains[1]);
> > queue_async_put_domains_work(power_domains,
> > fetch_and_zero(_work_wakeref));
> > + } else {
> > + /*
> > +* Cancel the work that got queued after this one got dequeued,
> > +* since here we released the corresponding async-put reference.
> > +*/
> > + cancel_delayed_work(_domains->async_put_work);
> > }
> >
> > out_verify:
> > --
> > 2.27.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): On 6/2/21 10:32 AM, Christian König wrote: Uff I'm just waiting for feedback from Philip to merge a large patch set for TTM through drm-misc-next. I'm pretty sure we will run into merge conflicts if you try to push your changes through the Intel tree. Christian. OK, so what would be the best approach here?, Adding the TTM patches to drm-misc-next when your set has landed? I think I will send out out my set to Matthew once more for review, then push the common TTM stuff to drm-misc-next as much as possible. Then you should be able to land your stuff to drm-misc-next and rebase on the end result. Just need to note to David that drm-misc-next should be merged to drm-next before the Intel patches depending on that stuff land as well. Christian. Thanks, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3)
== Series Details == Series: drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. (rev3) URL : https://patchwork.freedesktop.org/series/90818/ State : warning == Summary == $ dim checkpatch origin/drm-tip 056e7f6133a9 drm/i915: Only set bind_async_flags when concurrent access wa is not active, v3. -:74: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #74: FILE: drivers/gpu/drm/i915/i915_vma.c:439: + vma->ops->bind_vma(vma->vm, work ? >stash : NULL, vma, cache_level, bind_flags); total: 0 errors, 1 warnings, 0 checks, 44 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 63/97] drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs
On 06/05/2021 20:14, Matthew Brost wrote:
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class when using GuC submission and
direct all physical engine interrupts to this breadcrumbs.
Signed-off-by: Matthew Brost
CC: John Harrison
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 41 +---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 14 +++-
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 7 ++
drivers/gpu/drm/i915/gt/intel_engine.h| 3 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 28 +++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 -
.../drm/i915/gt/intel_execlists_submission.c | 4 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 67 +--
9 files changed, 133 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 38cc42783dfb..2007dc6f6b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -15,28 +15,14 @@
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
-static bool irq_enable(struct intel_engine_cs *engine)
+static bool irq_enable(struct intel_breadcrumbs *b)
{
- if (!engine->irq_enable)
- return false;
-
- /* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
- engine->irq_enable(engine);
- spin_unlock(>gt->irq_lock);
-
- return true;
+ return intel_engine_irq_enable(b->irq_engine);
}
-static void irq_disable(struct intel_engine_cs *engine)
+static void irq_disable(struct intel_breadcrumbs *b)
{
- if (!engine->irq_disable)
- return;
-
- /* Caller disables interrupts */
- spin_lock(>gt->irq_lock);
- engine->irq_disable(engine);
- spin_unlock(>gt->irq_lock);
+ intel_engine_irq_disable(b->irq_engine);
}
static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
@@ -57,7 +43,7 @@ static void __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
WRITE_ONCE(b->irq_armed, true);
/* Requests may have completed before we could enable the interrupt. */
- if (!b->irq_enabled++ && irq_enable(b->irq_engine))
+ if (!b->irq_enabled++ && b->irq_enable(b))
irq_work_queue(>irq_work);
}
@@ -76,7 +62,7 @@ static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
- irq_disable(b->irq_engine);
+ b->irq_disable(b);
WRITE_ONCE(b->irq_armed, false);
intel_gt_pm_put_async(b->irq_engine->gt);
@@ -281,7 +267,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
if (!b)
return NULL;
- b->irq_engine = irq_engine;
+ kref_init(>ref);
spin_lock_init(>signalers_lock);
INIT_LIST_HEAD(>signalers);
@@ -290,6 +276,10 @@ intel_breadcrumbs_create(struct intel_engine_cs
*irq_engine)
spin_lock_init(>irq_lock);
init_irq_work(>irq_work, signal_irq_work);
+ b->irq_engine = irq_engine;
+ b->irq_enable = irq_enable;
+ b->irq_disable = irq_disable;
+
return b;
}
@@ -303,9 +293,9 @@ void intel_breadcrumbs_reset(struct intel_breadcrumbs *b)
spin_lock_irqsave(>irq_lock, flags);
if (b->irq_enabled)
- irq_enable(b->irq_engine);
+ b->irq_enable(b);
else
- irq_disable(b->irq_engine);
+ b->irq_disable(b);
spin_unlock_irqrestore(>irq_lock, flags);
}
@@ -325,11 +315,14 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b)
}
}
-void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
+void intel_breadcrumbs_free(struct kref *kref)
{
+ struct intel_breadcrumbs *b = container_of(kref, typeof(*b), ref);
+
irq_work_sync(>irq_work);
GEM_BUG_ON(!list_empty(>signalers));
GEM_BUG_ON(b->irq_armed);
+
kfree(b);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
index 3ce5ce270b04..72105b74663d 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
@@ -17,7 +17,7 @@ struct intel_breadcrumbs;
struct intel_breadcrumbs *
intel_breadcrumbs_create(struct intel_engine_cs *irq_engine);
-void intel_breadcrumbs_free(struct intel_breadcrumbs *b);
+void intel_breadcrumbs_free(struct kref *kref);
void intel_breadcrumbs_reset(struct intel_breadcrumbs *b);
void __intel_breadcrumbs_park(struct intel_breadcrumbs *b);
@@ -48,4 +48,16 @@ void i915_request_cancel_breadcrumb(struct i915_request
*request);
[Intel-gfx] [PATCH v2 1/1] drm/i915/xelpd: Enabling dithering after the CC1
If the panel is 12bpc then Dithering is not enabled in the Legacy
dithering block , instead its Enabled after the C1 CC1 pipe post
color space conversion.For a 6bpc pannel Dithering is enabled in
Legacy block.
Signed-off-by: Nischal Varide
---
drivers/gpu/drm/i915/display/intel_color.c | 7 +++
drivers/gpu/drm/i915/display/intel_display.c | 7 ++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index dab892d2251b..e11b3dbf0b95 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1574,6 +1574,7 @@ static int glk_color_check(struct intel_crtc_state
*crtc_state)
static u32 icl_gamma_mode(const struct intel_crtc_state *crtc_state)
{
u32 gamma_mode = 0;
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
if (crtc_state->hw.degamma_lut)
gamma_mode |= PRE_CSC_GAMMA_ENABLE;
@@ -1588,6 +1589,12 @@ static u32 icl_gamma_mode(const struct intel_crtc_state
*crtc_state)
else
gamma_mode |= GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED;
+ if (DISPLAY_VER(i915) >= 13) {
+ if (!crtc_state->dither_force_disable &&
+ (crtc_state->pipe_bpp == 36))
+ gamma_mode |= POST_CC1_GAMMA_ENABLE;
+ }
+
return gamma_mode;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index caf0414e0b50..fd3186a5e6ff 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5762,7 +5762,12 @@ static void bdw_set_pipemisc(const struct
intel_crtc_state *crtc_state)
break;
}
- if (crtc_state->dither)
+ /*
+* If 12bpc panel then, Enables dithering after the CC1 pipe
+* post color space conversion and not here
+*/
+
+ if (crtc_state->dither && (crtc_state->pipe_bpp != 36))
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 24307c49085f..fa800a77ea49 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7743,6 +7743,7 @@ enum {
#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
#define PRE_CSC_GAMMA_ENABLE (1 << 31)
#define POST_CSC_GAMMA_ENABLE (1 << 30)
+#define POST_CC1_GAMMA_ENABLE (1 << 26)
#define GAMMA_MODE_MODE_MASK (3 << 0)
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/1] Enabling dithering after the CC1
If the panel is 12bpc then Dithering is not enabled in the Legacy dithering block , instead its Enabled after the C1 CC1 pipe post color space conversion.For a 6bpc pannel Dithering is enabled in Legacy block. This is Version 2 of the patch, after addresing few review comments. Nischal Varide (1): drm/i915/xelpd: Enabling dithering after the CC1 drivers/gpu/drm/i915/display/intel_color.c | 7 +++ drivers/gpu/drm/i915/display/intel_display.c | 7 ++- drivers/gpu/drm/i915/i915_reg.h | 1 + 3 files changed, 14 insertions(+), 1 deletion(-) -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
