[Intel-gfx] [PATCH v10 13/23] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

2023-01-17 Thread Niranjana Vishwanathapura
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

v2: Add more input validity checks.
v3: batch_address is a VA (not an array) if num_batches=1,
minor cleanup
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()
v5: Remove unwanted krealloc() and address other review comments.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 579 ++
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
 drivers/gpu/drm/i915/i915_driver.c|   1 +
 include/uapi/drm/i915_drm.h   |  61 ++
 5 files changed, 644 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68b209a859f1..b2477e85570c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -155,6 +155,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..49045858a3e9
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,579 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution in vm_bind mode
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * @args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ * @fences: array of execbuf fences (See struct eb_fence)
+ * @num_fences: number of fences in @fences array
+ */
+struct i915_execbuffer {
+   struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer3 *args;
+
+   str

[Intel-gfx] [PATCH v10 08/23] drm/i915/vm_bind: Add support to handle object evictions

2023-01-17 Thread Niranjana Vishwanathapura
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do not
include persistent vmas that are being purged.

v2: Remove unused I915_VMA_PURGED definition.
v3: Properly handle __i915_vma_unbind_async() case.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  6 
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 +++
 drivers/gpu/drm/i915/i915_vma.c   | 28 +++
 drivers/gpu/drm/i915/i915_vma.h   | 10 +++
 drivers/gpu/drm/i915/i915_vma_types.h |  8 ++
 6 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 4f9df4b756d2..dc738677466b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -86,6 +86,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, 
bool release_obj)
 {
lockdep_assert_held(&vma->vm->vm_bind_lock);
 
+   spin_lock(&vma->vm->vm_rebind_lock);
+   if (!list_empty(&vma->vm_rebind_link))
+   list_del_init(&vma->vm_rebind_link);
+   i915_vma_set_purged(vma);
+   spin_unlock(&vma->vm->vm_rebind_lock);
+
list_del_init(&vma->vm_bind_link);
list_del_init(&vma->non_priv_vm_bind_link);
i915_vm_bind_it_remove(vma, &vma->vm->va);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 7ce0237d664f..4f91857dca46 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -291,6 +291,8 @@ void i915_address_space_init(struct i915_address_space *vm, 
int subclass)
INIT_LIST_HEAD(&vm->vm_bound_list);
mutex_init(&vm->vm_bind_lock);
INIT_LIST_HEAD(&vm->non_priv_vm_bind_list);
+   INIT_LIST_HEAD(&vm->vm_rebind_list);
+   spin_lock_init(&vm->vm_rebind_lock);
 }
 
 void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index cb87d0e925c7..dbe6792df3e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -266,6 +266,10 @@ struct i915_address_space {
struct list_head vm_bind_list;
/** @vm_bound_list: List of vm_binding completed */
struct list_head vm_bound_list;
+   /** @vm_rebind_list: list of vmas to be rebinded */
+   struct list_head vm_rebind_list;
+   /** @vm_rebind_lock: protects vm_rebound_list */
+   spinlock_t vm_rebind_lock;
/** @va: tree of persistent vmas */
struct rb_root_cached va;
/** @non_priv_vm_bind_list: list of non-private object mappings */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 30f0c0aca007..353203bd5685 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -243,6 +243,7 @@ vma_create(struct drm_i915_gem_object *obj,
 
INIT_LIST_HEAD(&vma->vm_bind_link);
INIT_LIST_HEAD(&vma->non_priv_vm_bind_link);
+   INIT_LIST_HEAD(&vma->vm_rebind_link);
return vma;
 
 err_unlock:
@@ -1716,6 +1717,14 @@ static void force_unbind(struct i915_vma *vma)
if (!drm_mm_node_allocated(&vma->node))
return;
 
+   /*
+* Persistent vma should have been purged by now.
+* If not, issue a warning and purge it.
+*/
+   if (GEM_WARN_ON(i915_vma_is_persistent(vma) &&
+   !i915_vma_is_purged(vma)))
+   i915_vma_set_purged(vma);
+
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
@@ -2082,6 +2091,16 @@ int __i915_vma_unbind(struct i915_vma *vma)
__i915_vma_evict(vma, false);
 
drm_mm_remove_node(&vma->node); /* pairs with i915_vma_release() */
+
+   if (i915_vma_is_persistent(vma)) {
+   spin_lock(&vma->vm->vm_rebind_lock);
+   if (list_empty(&vma->vm_rebind_link) &&
+   !i915_vma_is_purged(vma))
+   list_add_tail(&vma->vm_rebind_link,
+ &vma->vm->vm_rebind_list);
+   spin_unlock(&vma->vm->vm_rebind_lock);
+   }
+
return 0;
 }
 
@@ -2116,6 +2135,15 @@ static struct dma_fence *__i915_vma_unbind_async(struct 
i915_vma *vma)
 
drm_mm_remove_node(&vma->node); /* pairs with i915_vma_release() */
 
+   if (i915_vma_is_persistent(vma)) {
+   spin_lock(&vma->vm->vm_rebind_lock);
+   if (list_empty(&vma->vm_rebind_link) &&
+   !i915_vma_is_purged(vma))
+   list_add_tail(&vma->vm_rebind_link,
+ &vma->vm->vm_rebi

[Intel-gfx] [PATCH v10 23/23] drm/i915/vm_bind: Support capture of persistent mappings

2023-01-17 Thread Niranjana Vishwanathapura
Support dump capture of persistent mappings upon user request.

Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling. They are synchronously
unbound during eviction so that no additional vma resource
reference taking is required in the submission path. Thus, a
list of persistent vmas requiring capture is maintained instead
of a list of vma resources.

v2: enable with CONFIG_DRM_I915_CAPTURE_ERROR, remove gfp
overwrite, add kernel-doc and expand commit message
v3: Ensure vma->resource is valid during capture

Signed-off-by: Brian Welty 
Signed-off-by: Niranjana Vishwanathapura 
---
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 13 +
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  5 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  7 +++
 drivers/gpu/drm/i915/i915_gem.c   | 14 -
 drivers/gpu/drm/i915/i915_gpu_error.c | 52 ++-
 drivers/gpu/drm/i915/i915_vma.c   |  4 ++
 drivers/gpu/drm/i915/i915_vma_types.h |  4 ++
 include/uapi/drm/i915_drm.h   |  9 +++-
 8 files changed, 104 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..562a67a988f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, 
bool release_obj)
 {
lockdep_assert_held(&vma->vm->vm_bind_lock);
 
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   mutex_lock(&vma->vm->vm_capture_lock);
+   if (!list_empty(&vma->vm_capture_link))
+   list_del_init(&vma->vm_capture_link);
+   mutex_unlock(&vma->vm->vm_capture_lock);
+#endif
spin_lock(&vma->vm->vm_rebind_lock);
if (!list_empty(&vma->vm_rebind_link))
list_del_init(&vma->vm_rebind_link);
@@ -357,6 +363,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space 
*vm,
continue;
}
 
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+   mutex_lock(&vm->vm_capture_lock);
+   list_add_tail(&vma->vm_capture_link, 
&vm->vm_capture_list);
+   mutex_unlock(&vm->vm_capture_lock);
+   }
+#endif
list_add_tail(&vma->vm_bind_link, &vm->vm_bound_list);
i915_vm_bind_it_insert(vma, &vm->va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2e4c9fabf3b8..103ca55222be 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,11 @@ void i915_address_space_init(struct i915_address_space 
*vm, int subclass)
spin_lock_init(&vm->vm_rebind_lock);
spin_lock_init(&vm->userptr_invalidated_lock);
INIT_LIST_HEAD(&vm->userptr_invalidated_list);
+
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   INIT_LIST_HEAD(&vm->vm_capture_list);
+   mutex_init(&vm->vm_capture_lock);
+#endif
 }
 
 void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 620b4e020a9f..7f69e1d4fb5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,13 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private objects */
struct drm_i915_gem_object *root_obj;
 
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   /* @vm_capture_list: list of vm captures */
+   struct list_head vm_capture_list;
+   /* @vm_capture_lock: protects vm_capture_list */
+   struct mutex vm_capture_lock;
+#endif
+
/* Global GTT */
bool is_ggtt:1;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 969581e7106f..d97822f203fc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -143,6 +143,8 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
while (!ret && (vma = list_first_entry_or_null(&obj->vma.list,
   struct i915_vma,
   obj_link))) {
+   bool sync_unbind = true;
+
list_move_tail(&vma->obj_link, &still_in_list);
if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
continue;
@@ -171,8 +173,18 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
 * and destroy the vma from under us.
 */
 
+   /*
+* Synchronously unbind persistent mappings with capture
+* request so that vma->resource is valid in the error capture
+   

[Intel-gfx] [PATCH v10 14/23] drm/i915/vm_bind: Update i915_vma_verify_bind_complete()

2023-01-17 Thread Niranjana Vishwanathapura
Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
and move it out of CONFIG_DRM_I915_DEBUG_GEM.

v2: Fix fence leak

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_vma.c | 22 --
 drivers/gpu/drm/i915/i915_vma.h |  1 +
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 763ead20ad55..804f01b9002d 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -441,12 +441,25 @@ int i915_vma_sync(struct i915_vma *vma)
return i915_vm_sync(vma->vm);
 }
 
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
-static int i915_vma_verify_bind_complete(struct i915_vma *vma)
+/**
+ * i915_vma_verify_bind_complete() - Check for the bind completion of the vma
+ * @vma: vma to check for bind completion
+ *
+ * As the fence reference is obtained under RCU, no locking is required by
+ * the caller.
+ *
+ * Returns: 0 if the vma bind is completed. Error code otherwise.
+ */
+int i915_vma_verify_bind_complete(struct i915_vma *vma)
 {
-   struct dma_fence *fence = i915_active_fence_get(&vma->active.excl);
+   struct dma_fence *fence;
int err;
 
+   /* Ensure vma bind is initiated */
+   if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
+   return -EINVAL;
+
+   fence = i915_active_fence_get(&vma->active.excl);
if (!fence)
return 0;
 
@@ -459,9 +472,6 @@ static int i915_vma_verify_bind_complete(struct i915_vma 
*vma)
 
return err;
 }
-#else
-#define i915_vma_verify_bind_complete(_vma) 0
-#endif
 
 I915_SELFTEST_EXPORT void
 i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res,
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index de1756e4f638..1f25e45a6325 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -487,6 +487,7 @@ void i915_vma_make_purgeable(struct i915_vma *vma);
 
 int i915_vma_wait_for_bind(struct i915_vma *vma);
 int i915_vma_sync(struct i915_vma *vma);
+int i915_vma_verify_bind_complete(struct i915_vma *vma);
 
 /**
  * i915_vma_get_current_resource - Get the current resource of the vma
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 19/23] drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode

2023-01-17 Thread Niranjana Vishwanathapura
Add getparam support for VM_BIND capability version.
Add VM creation time flag to enable vm_bind_mode for the VM.

v2: update kernel-doc
v3: create vm->root_obj only upon I915_VM_CREATE_FLAGS_USE_VM_BIND
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 ++--
 drivers/gpu/drm/i915/gem/i915_gem_context.h |  3 +--
 drivers/gpu/drm/i915/gt/intel_gtt.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_getparam.c|  3 +++
 include/uapi/drm/i915_drm.h | 26 -
 6 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9809c58316c2..ba4aca5ff432 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1809,9 +1809,13 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, 
void *data,
if (!HAS_FULL_PPGTT(i915))
return -ENODEV;
 
-   if (args->flags)
+   if (args->flags & I915_VM_CREATE_FLAGS_UNKNOWN)
return -EINVAL;
 
+   if ((args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) &&
+   !HAS_VM_BIND(i915))
+   return -EOPNOTSUPP;
+
ppgtt = i915_ppgtt_create(to_gt(i915), 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
@@ -1824,15 +1828,32 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, 
void *data,
goto err_put;
}
 
+   if (args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) {
+   struct drm_i915_gem_object *obj;
+
+   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
+   goto err_put;
+   }
+
+   ppgtt->vm.root_obj = obj;
+   }
+
err = xa_alloc(&file_priv->vm_xa, &id, &ppgtt->vm,
   xa_limit_32b, GFP_KERNEL);
if (err)
-   goto err_put;
+   goto err_root_obj_put;
 
GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
args->vm_id = id;
return 0;
 
+err_root_obj_put:
+   if (ppgtt->vm.root_obj) {
+   i915_gem_object_put(ppgtt->vm.root_obj);
+   ppgtt->vm.root_obj = NULL;
+   }
 err_put:
i915_vm_put(&ppgtt->vm);
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e8b41aa8f8c4..b53aef2853cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -150,8 +150,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev, void *data,
  */
 static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
 {
-   /* No support to enable vm_bind mode yet */
-   return false;
+   return !!vm->root_obj;
 }
 
 struct i915_address_space *
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 7045b2114df6..2e4c9fabf3b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -179,6 +179,8 @@ int i915_vm_lock_objects(struct i915_address_space *vm,
 void i915_address_space_fini(struct i915_address_space *vm)
 {
drm_mm_takedown(&vm->mm);
+   if (vm->root_obj)
+   i915_gem_object_put(vm->root_obj);
GEM_BUG_ON(!RB_EMPTY_ROOT(&vm->va.rb_root));
mutex_destroy(&vm->vm_bind_lock);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48fd82722f12..030ad237158b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -972,6 +972,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_LMEMBAR_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
   GRAPHICS_VER_FULL(i915) >= IP_VER(12, 
70))
 
+#define HAS_VM_BIND(i915) (GRAPHICS_VER(i915) >= 12)
+
 /* intel_device_info.c */
 static inline struct intel_device_info *
 mkwrite_device_info(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 61ef2d9cfa62..20c1bf904a65 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -178,6 +178,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_OA_TIMESTAMP_FREQUENCY:
value = i915_perf_oa_timestamp_frequency(i915);
break;
+   case I915_PARAM_VM_BIND_VERSION:
+   value = HAS_VM_BIND(i915);
+   break;
default:
drm_dbg(&i915->drm, "Unknown parameter %d\n", param->param);
return -EINVAL;
diff

[Intel-gfx] [PATCH v10 04/23] drm/i915/vm_bind: Support partially mapped vma resource

2023-01-17 Thread Niranjana Vishwanathapura
As persistent vmas can be partialled mapped to an object,
remove restriction which require vma resource sg table to
be just pointer to object's sg table.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_vma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 34f0e6c923c2..79b2e19a299f 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -2060,8 +2060,7 @@ static struct dma_fence *__i915_vma_unbind_async(struct 
i915_vma *vma)
if (!drm_mm_node_allocated(&vma->node))
return NULL;
 
-   if (i915_vma_is_pinned(vma) ||
-   &vma->obj->mm.rsgt->table != vma->resource->bi.pages)
+   if (i915_vma_is_pinned(vma))
return ERR_PTR(-EAGAIN);
 
/*
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 17/23] drm/i915/vm_bind: userptr dma-resv changes

2023-01-17 Thread Niranjana Vishwanathapura
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions

v2: Do not double add vma to vm->userptr_invalidated_list
v3: Initialize vma->userptr_invalidated_link

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 84 ++-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   | 19 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 15 
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  2 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 +
 drivers/gpu/drm/i915/i915_vma.c   |  1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  2 +
 7 files changed, 125 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 913b1f8bda9f..a1aee477e2df 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -20,6 +20,7 @@
 #include "i915_gem_vm_bind.h"
 #include "i915_trace.h"
 
+#define __EXEC3_USERPTR_USED   BIT_ULL(34)
 #define __EXEC3_HAS_PINBIT_ULL(33)
 #define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
 #define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -144,7 +145,22 @@ static void eb_scoop_unbound_vma_all(struct 
i915_address_space *vm)
 {
struct i915_vma *vma, *vn;
 
-   /**
+#ifdef CONFIG_MMU_NOTIFIER
+   /*
+* Move all invalidated userptr vmas back into vm_bind_list so that
+* they are looked up and revalidated.
+*/
+   spin_lock(&vm->userptr_invalidated_lock);
+   list_for_each_entry_safe(vma, vn, &vm->userptr_invalidated_list,
+userptr_invalidated_link) {
+   list_del_init(&vma->userptr_invalidated_link);
+   if (!list_empty(&vma->vm_bind_link))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bind_list);
+   }
+   spin_unlock(&vm->userptr_invalidated_lock);
+#endif
+
+   /*
 * Move all unbound vmas back into vm_bind_list so that they are
 * revalidated.
 */
@@ -157,10 +173,47 @@ static void eb_scoop_unbound_vma_all(struct 
i915_address_space *vm)
spin_unlock(&vm->vm_rebind_lock);
 }
 
+static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *last_vma = NULL;
+   struct i915_vma *vma;
+   int err;
+
+   lockdep_assert_held(&vm->vm_bind_lock);
+
+   list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link) {
+   if (!i915_gem_object_is_userptr(vma->obj))
+   continue;
+
+   err = i915_gem_object_userptr_submit_init(vma->obj);
+   if (err)
+   return err;
+
+   /*
+* The above submit_init() call does the object unbind and
+* hence adds vma into vm_rebind_list. Remove it from that
+* list as it is already scooped for revalidation.
+*/
+   spin_lock(&vm->vm_rebind_lock);
+   if (!list_empty(&vma->vm_rebind_link))
+   list_del_init(&vma->vm_rebind_link);
+   spin_unlock(&vm->vm_rebind_lock);
+
+   last_vma = vma;
+   }
+
+   if (last_vma)
+   eb->args->flags |= __EXEC3_USERPTR_USED;
+
+   return 0;
+}
+
 static int eb_lookup_vma_all(struct i915_execbuffer *eb)
 {
struct i915_vma *vma;
unsigned int i;
+   int err = 0;
 
for (i = 0; i < eb->num_batches; i++) {
vma = eb_find_vma(eb->context->vm, eb->batch_addresses[i]);
@@ -172,6 +225,10 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
 
eb_scoop_unbound_vma_all(eb->context->vm);
 
+   err = eb_lookup_persistent_userptr_vmas(eb);
+   if (err)
+   return err;
+
return 0;
 }
 
@@ -344,6 +401,29 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
}
}
 
+#ifdef CONFIG_MMU_NOTIFIER
+   /* Check for further userptr invalidations */
+   spin_lock(&vm->userptr_invalidated_lock);
+   if (!list_empty(&vm->userptr_invalidated_list))
+   err = -EAGAIN;
+   spin_unlock(&vm->userptr_invalidated_lock);
+
+   if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
+   read_lock(&eb->i915->mm.notifier_lock);
+   list_for_each_entry(vma, &vm->vm_bind_list, vm_bind_link) {
+   if (!i915_gem_object_is_userptr(vma->obj))
+   continue;
+
+   err = i915_gem_object_userptr_submit_done(vma->obj);
+   if (err)
+   break;
+   }
+   read_unlock(&eb->i915->mm.notifier_lock

[Intel-gfx] [PATCH v10 16/23] drm/i915/vm_bind: Handle persistent vmas in execbuf3

2023-01-17 Thread Niranjana Vishwanathapura
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.

v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
Individualize fences before adding to dma_resv obj.
v4: Fix bind completion check, use PIN_NOEVICT,
use proper lock while checking if vm_rebind_list is empty.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 215 +-
 1 file changed, 214 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 49045858a3e9..913b1f8bda9f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -3,6 +3,7 @@
  * Copyright © 2022 Intel Corporation
  */
 
+#include 
 #include 
 #include 
 
@@ -19,6 +20,7 @@
 #include "i915_gem_vm_bind.h"
 #include "i915_trace.h"
 
+#define __EXEC3_HAS_PINBIT_ULL(33)
 #define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
 #define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
 
@@ -42,7 +44,9 @@
  * execlist. Hence, no support for implicit sync.
  *
  * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
  *
  * The execbuf3 ioctl directly specifies the batch addresses instead of as
  * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -58,6 +62,13 @@
  * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
  * vma lookup table, implicit sync, vma active reference tracking etc., are not
  * applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
  */
 
 /**
@@ -129,6 +140,23 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
 }
 
+static void eb_scoop_unbound_vma_all(struct i915_address_space *vm)
+{
+   struct i915_vma *vma, *vn;
+
+   /**
+* Move all unbound vmas back into vm_bind_list so that they are
+* revalidated.
+*/
+   spin_lock(&vm->vm_rebind_lock);
+   list_for_each_entry_safe(vma, vn, &vm->vm_rebind_list, vm_rebind_link) {
+   list_del_init(&vma->vm_rebind_link);
+   if (!list_empty(&vma->vm_bind_link))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bind_list);
+   }
+   spin_unlock(&vm->vm_rebind_lock);
+}
+
 static int eb_lookup_vma_all(struct i915_execbuffer *eb)
 {
struct i915_vma *vma;
@@ -142,14 +170,108 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
eb->batches[i] = vma;
}
 
+   eb_scoop_unbound_vma_all(eb->context->vm);
+
+   return 0;
+}
+
+static int eb_lock_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma;
+   int err;
+
+   err = i915_gem_object_lock(eb->context->vm->root_obj, &eb->ww);
+   if (err)
+   return err;
+
+   list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+   non_priv_vm_bind_link) {
+   err = i915_gem_object_lock(vma->obj, &eb->ww);
+   if (err)
+   return err;
+   }
+
return 0;
 }
 
+static void eb_release_persistent_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma, *vn;
+
+   lockdep_assert_held(&vm->vm_bind_lock);
+
+   if (!(eb->args->flags & __EXEC3_HAS_PIN))
+   return;
+
+   assert_object_held(vm->root_obj);
+
+   list_for_each_entry_safe(vma, vn, &vm->vm_bind_list, vm_bind_link)
+   if (!i915_vma_verify_bind_complete(vma))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bound_list);
+
+   eb->args->flags &= ~__EXEC3_HAS_PIN;
+}
+
 static void eb_release_vma_all(struct i915_execbuffer *eb)
 {
+   eb_release_persistent_vma_all(eb);
eb_unpin_engine(eb);
 }
 
+static int eb_reserve_fence_for_persistent_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   u64 num_fences = 1;
+   struct i915_vma *vma;
+   int ret;
+
+   /* Reserve enough slots to accommodate composite 

[Intel-gfx] [PATCH v10 12/23] drm/i915/vm_bind: Use common execbuf functions in execbuf path

2023-01-17 Thread Niranjana Vishwanathapura
Update the execbuf path to use common execbuf functions to
reduce code duplication with the newer execbuf3 path.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 513 ++
 1 file changed, 39 insertions(+), 474 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6a7f0227f65f..8b49543f3265 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -28,6 +28,7 @@
 #include "i915_file_private.h"
 #include "i915_gem_clflush.h"
 #include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
 #include "i915_gem_evict.h"
 #include "i915_gem_ioctls.h"
 #include "i915_reg.h"
@@ -236,13 +237,6 @@ enum {
  * the batchbuffer in trusted mode, otherwise the ioctl is rejected.
  */
 
-struct eb_fence {
-   struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
-   struct dma_fence *dma_fence;
-   u64 value;
-   struct dma_fence_chain *chain_fence;
-};
-
 struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -2452,164 +2446,29 @@ static const enum intel_engine_id user_ring_map[] = {
[I915_EXEC_VEBOX]   = VECS0
 };
 
-static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct 
intel_context *ce)
-{
-   struct intel_ring *ring = ce->ring;
-   struct intel_timeline *tl = ce->timeline;
-   struct i915_request *rq;
-
-   /*
-* Completely unscientific finger-in-the-air estimates for suitable
-* maximum user request size (to avoid blocking) and then backoff.
-*/
-   if (intel_ring_update_space(ring) >= PAGE_SIZE)
-   return NULL;
-
-   /*
-* Find a request that after waiting upon, there will be at least half
-* the ring available. The hysteresis allows us to compete for the
-* shared ring and should mean that we sleep less often prior to
-* claiming our resources, but not so long that the ring completely
-* drains before we can submit our next request.
-*/
-   list_for_each_entry(rq, &tl->requests, link) {
-   if (rq->ring != ring)
-   continue;
-
-   if (__intel_ring_space(rq->postfix,
-  ring->emit, ring->size) > ring->size / 2)
-   break;
-   }
-   if (&rq->link == &tl->requests)
-   return NULL; /* weird, we will check again later for real */
-
-   return i915_request_get(rq);
-}
-
-static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context 
*ce,
-  bool throttle)
-{
-   struct intel_timeline *tl;
-   struct i915_request *rq = NULL;
-
-   /*
-* Take a local wakeref for preparing to dispatch the execbuf as
-* we expect to access the hardware fairly frequently in the
-* process, and require the engine to be kept awake between accesses.
-* Upon dispatch, we acquire another prolonged wakeref that we hold
-* until the timeline is idle, which in turn releases the wakeref
-* taken on the engine, and the parent device.
-*/
-   tl = intel_context_timeline_lock(ce);
-   if (IS_ERR(tl))
-   return PTR_ERR(tl);
-
-   intel_context_enter(ce);
-   if (throttle)
-   rq = eb_throttle(eb, ce);
-   intel_context_timeline_unlock(tl);
-
-   if (rq) {
-   bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
-   long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
-
-   if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
- timeout) < 0) {
-   i915_request_put(rq);
-
-   /*
-* Error path, cannot use intel_context_timeline_lock as
-* that is user interruptable and this clean up step
-* must be done.
-*/
-   mutex_lock(&ce->timeline->mutex);
-   intel_context_exit(ce);
-   mutex_unlock(&ce->timeline->mutex);
-
-   if (nonblock)
-   return -EWOULDBLOCK;
-   else
-   return -EINTR;
-   }
-   i915_request_put(rq);
-   }
-
-   return 0;
-}
-
 static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle)
 {
-   struct intel_context *ce = eb->context, *child;
int err;
-   int i = 0, j = 0;
 
GEM_BUG_ON(eb->args->flags & __EXEC_ENGINE_PINNED);
 
-   if (unlikely(intel_context_is_banned(ce)))
-   return -EIO;
-
-   /*
-* Pinning the contexts may g

[Intel-gfx] [PATCH v10 05/23] drm/i915/vm_bind: Add support to create persistent vma

2023-01-17 Thread Niranjana Vishwanathapura
Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.

vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing. ie., multiple
mappings (at different VA) point to the same gtt_view of object.
Skip vma_lookup for persistent vmas to support aliasing.

v2: Remove unused I915_VMA_PERSISTENT definition,
update validity check in i915_vma_compare(),
remove unwanted is_persistent check in release_references().

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_vma.c   | 36 +--
 drivers/gpu/drm/i915/i915_vma.h   | 17 -
 drivers/gpu/drm/i915/i915_vma_types.h |  6 +
 3 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 79b2e19a299f..e43cbb5fa154 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -111,7 +111,8 @@ static void __i915_vma_retire(struct i915_active *ref)
 static struct i915_vma *
 vma_create(struct drm_i915_gem_object *obj,
   struct i915_address_space *vm,
-  const struct i915_gtt_view *view)
+  const struct i915_gtt_view *view,
+  bool skip_lookup_cache)
 {
struct i915_vma *pos = ERR_PTR(-E2BIG);
struct i915_vma *vma;
@@ -198,6 +199,9 @@ vma_create(struct drm_i915_gem_object *obj,
__set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(vma));
}
 
+   if (skip_lookup_cache)
+   goto skip_rb_insert;
+
rb = NULL;
p = &obj->vma.tree.rb_node;
while (*p) {
@@ -222,6 +226,7 @@ vma_create(struct drm_i915_gem_object *obj,
rb_link_node(&vma->obj_node, rb, p);
rb_insert_color(&vma->obj_node, &obj->vma.tree);
 
+skip_rb_insert:
if (i915_vma_is_ggtt(vma))
/*
 * We put the GGTT vma at the start of the vma-list, followed
@@ -301,7 +306,34 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
 
/* vma_create() will resolve the race if another creates the vma */
if (unlikely(!vma))
-   vma = vma_create(obj, vm, view);
+   vma = vma_create(obj, vm, view, false);
+
+   GEM_BUG_ON(!IS_ERR(vma) && i915_vma_compare(vma, vm, view));
+   return vma;
+}
+
+/**
+ * i915_vma_create_persistent - create a persistent VMA
+ * @obj: parent &struct drm_i915_gem_object to be mapped
+ * @vm: address space in which the mapping is located
+ * @view: additional mapping requirements
+ *
+ * Creates a persistent vma.
+ *
+ * Returns the vma, or an error pointer.
+ */
+struct i915_vma *
+i915_vma_create_persistent(struct drm_i915_gem_object *obj,
+  struct i915_address_space *vm,
+  const struct i915_gtt_view *view)
+{
+   struct i915_vma *vma;
+
+   GEM_BUG_ON(!kref_read(&vm->ref));
+
+   vma = vma_create(obj, vm, view, true);
+   if (!IS_ERR(vma))
+   i915_vma_set_persistent(vma);
 
GEM_BUG_ON(!IS_ERR(vma) && i915_vma_compare(vma, vm, view));
return vma;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index ed5c9d682a1b..dd9951a41ff3 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -44,6 +44,10 @@ struct i915_vma *
 i915_vma_instance(struct drm_i915_gem_object *obj,
  struct i915_address_space *vm,
  const struct i915_gtt_view *view);
+struct i915_vma *
+i915_vma_create_persistent(struct drm_i915_gem_object *obj,
+  struct i915_address_space *vm,
+  const struct i915_gtt_view *view);
 
 void i915_vma_unpin_and_release(struct i915_vma **p_vma, unsigned int flags);
 #define I915_VMA_RELEASE_MAP BIT(0)
@@ -185,6 +189,16 @@ static inline u32 i915_ggtt_pin_bias(struct i915_vma *vma)
return i915_vm_to_ggtt(vma->vm)->pin_bias;
 }
 
+static inline bool i915_vma_is_persistent(const struct i915_vma *vma)
+{
+   return test_bit(I915_VMA_PERSISTENT_BIT, __i915_vma_flags(vma));
+}
+
+static inline void i915_vma_set_persistent(struct i915_vma *vma)
+{
+   set_bit(I915_VMA_PERSISTENT_BIT, __i915_vma_flags(vma));
+}
+
 static inline struct i915_vma *i915_vma_get(struct i915_vma *vma)
 {
i915_gem_object_get(vma->obj);
@@ -211,7 +225,8 @@ i915_vma_compare(struct i915_vma *vma,
 {
ptrdiff_t cmp;
 
-   GEM_BUG_ON(view && !i915_is_ggtt_or_dpt(vm));
+   GEM_BUG_ON(view && !(i915_is_ggtt_or_dpt(vm) ||
+i915_vma_is_persistent(vma)));
 
cmp = ptrdiff(vma->vm, vm);
if (cmp)
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h 
b/drivers/gpu/drm/i915/i915_vma_types.h
index 77fda2244d16..be1cd76304cb 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i9

[Intel-gfx] [PATCH v10 10/23] drm/i915/vm_bind: Add out fence support

2023-01-17 Thread Niranjana Vishwanathapura
Add support for handling out fence for vm_bind call.

v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.
v4: Return error if I915_TIMELINE_FENCE_WAIT fence flag is set.
Wait for bind to complete iff I915_TIMELINE_FENCE_SIGNAL is
not specified.
v5: Ensure __I915_TIMELINE_FENCE_UNKNOWN_FLAGS are not set.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  4 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 98 ++-
 drivers/gpu/drm/i915/i915_vma.c   |  7 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  7 ++
 include/uapi/drm/i915_drm.h   | 58 ++-
 5 files changed, 165 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 36262a6357b5..b70e900e35ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -8,6 +8,7 @@
 
 #include 
 
+struct dma_fence;
 struct drm_device;
 struct drm_file;
 struct i915_address_space;
@@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void 
*data,
 
 void i915_gem_vm_unbind_all(struct i915_address_space *vm);
 
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+  struct dma_fence * const fence);
+
 #endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index dc738677466b..fd1d82ce99e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -7,6 +7,8 @@
 
 #include 
 
+#include 
+
 #include "gem/i915_gem_context.h"
 #include "gem/i915_gem_vm_bind.h"
 
@@ -101,6 +103,77 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, 
bool release_obj)
i915_gem_object_put(vma->obj);
 }
 
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,
+ u32 handle, u64 point)
+{
+   struct drm_syncobj *syncobj;
+
+   syncobj = drm_syncobj_find(file, handle);
+   if (!syncobj) {
+   drm_dbg(&vma->vm->i915->drm,
+   "Invalid syncobj handle provided\n");
+   return -ENOENT;
+   }
+
+   /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+   if (point) {
+   vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+   if (!vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_put(syncobj);
+   return -ENOMEM;
+   }
+   } else {
+   vma->vm_bind_fence.chain_fence = NULL;
+   }
+   vma->vm_bind_fence.syncobj = syncobj;
+   vma->vm_bind_fence.value = point;
+
+   return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+   if (!vma->vm_bind_fence.syncobj)
+   return;
+
+   drm_syncobj_put(vma->vm_bind_fence.syncobj);
+   dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+   vma->vm_bind_fence.syncobj = NULL;
+}
+
+/**
+ * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
+ * @vma: vma mapping requiring signaling
+ * @fence: fence to be added
+ *
+ * Associate specified @fence with the @vma's syncobj to be
+ * signaled after the @fence work completes.
+ */
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+  struct dma_fence * const fence)
+{
+   struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+   if (!syncobj)
+   return;
+
+   if (vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+   /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+   vma->vm_bind_fence.chain_fence = NULL;
+   } else {
+   drm_syncobj_replace_fence(syncobj, fence);
+   }
+}
+
 static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
  struct drm_i915_gem_vm_unbind *va)
 {
@@ -206,6 +279,11 @@ static int i915_gem_vm_bind_obj(struct i915_address_space 
*vm,
if (!va->length || !IS_ALIGNED(va->start, I915_GTT_PAGE_SIZE))
ret = -EINVAL;
 
+   /* In fences are not supported */
+   if ((va->fence.flags & I915_TIMELINE_FENCE_WAIT) ||
+   (va->fence.flags & __I915_TIMELINE_FENCE_UNKNOWN_FLAGS))
+   ret = -EINVAL;
+
obj = i915_gem_object_lookup(file, va->handle);
if (!obj)
return -ENOENT;
@@ -238,6 +316,13 @@ static int i9

[Intel-gfx] [PATCH v10 21/23] drm/i915/vm_bind: Async vm_unbind support

2023-01-17 Thread Niranjana Vishwanathapura
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.

No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.

v2: use i915_vma_destroy_async in vm_unbind ioctl
v3: Add force_unbind function variants

Reviewed-by: Matthew Auld 
Reviewed-by: Andi Shyti 
Signed-off-by: Niranjana Vishwanathapura 
---
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  2 +-
 drivers/gpu/drm/i915/i915_vma.c   | 49 ++-
 drivers/gpu/drm/i915/i915_vma.h   |  1 +
 include/uapi/drm/i915_drm.h   |  3 +-
 4 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 1cc0b8a4e0e7..78e7c0642c5f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct i915_address_space 
*vm,
 */
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
-   i915_vma_destroy(vma);
+   i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
 
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 59462812ef4e..5b9ae5ebf55c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
 #include "i915_vma.h"
 #include "i915_vma_resource.h"
 
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
 static inline void assert_vma_held_evict(const struct i915_vma *vma)
 {
/*
@@ -1746,7 +1748,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
 }
 
-static void force_unbind(struct i915_vma *vma)
+static void __force_unbind(struct i915_vma *vma, bool async)
 {
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1760,10 +1762,26 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
 
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
-   WARN_ON(__i915_vma_unbind(vma));
+   if (async) {
+   struct dma_fence *fence;
+
+   fence = __i915_vma_unbind_async(vma);
+   if (IS_ERR_OR_NULL(fence)) {
+   async = false;
+   } else {
+   dma_resv_add_fence(vma->obj->base.resv, fence,
+  DMA_RESV_USAGE_READ);
+   dma_fence_put(fence);
+   }
+   }
+
+   if (!async)
+   WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
 }
 
+#define force_unbind(vma)  __force_unbind((vma), false)
+
 static void release_references(struct i915_vma *vma, struct intel_gt *gt,
   bool vm_ddestroy)
 {
@@ -1842,6 +1860,33 @@ void i915_vma_destroy(struct i915_vma *vma)
release_references(vma, gt, vm_ddestroy);
 }
 
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+   bool vm_ddestroy, async = vma->obj->mm.rsgt;
+   struct intel_gt *gt;
+
+   if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+   async = false;
+
+   mutex_lock(&vma->vm->mutex);
+   /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+   if (async && i915_active_wait(&vma->active))
+   async = false;
+
+   __force_unbind(vma, async);
+   list_del_init(&vma->vm_link);
+   vm_ddestroy = vma->vm_ddestroy;
+   vma->vm_ddestroy = false;
+
+   /* vma->vm may be freed when releasing vma->vm->mutex. */
+   gt = vma->vm->gt;
+   mutex_unlock(&vma->vm->mutex);
+   release_references(vma, gt, vm_ddestroy);
+}
+
 void i915_vma_parked(struct intel_gt *gt)
 {
struct i915_vma *vma, *next;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index d6c05227fb04..8033f5c96efc 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -319,6 +319,7 @@ void i915_vma_reopen(struct i915_vma *vma);
 
 void i915_vma_destroy_locked(struct i915_vma *vma);
 void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
 
 #define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3f27001a2c8d..b9167f950327 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3970,7 +3970,8 @@ struct drm_i915_gem_vm_bind {
  * any error.
  *
  * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
- * are not ordered.
+ * are not ordered. Furthermore, parts of the VM_UNBIN

[Intel-gfx] [PATCH v10 22/23] drm/i915/vm_bind: Properly build persistent map sg table

2023-01-17 Thread Niranjana Vishwanathapura
Properly build the sg table for persistent mapping which can
be partial map of the underlying object. Ensure the sg pages
are properly set for page backed regions. The dump capture
support requires this for page backed regions.

v2: Remove redundant sg_mark_end() call

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_vma.c | 113 +++-
 1 file changed, 112 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 5b9ae5ebf55c..2f0994f0ed42 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1328,6 +1328,113 @@ intel_partial_pages(const struct i915_gtt_view *view,
return ERR_PTR(ret);
 }
 
+static unsigned int
+intel_copy_dma_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+   struct scatterlist *dst_sg, *src_sg;
+   unsigned int i, len, nents = 0;
+
+   dst_sg = dst_st->sgl;
+   for_each_sgtable_dma_sg(src_st, src_sg, i) {
+   if (sg_dma_len(src_sg) <= offset) {
+   offset -= sg_dma_len(src_sg);
+   continue;
+   }
+
+   nents++;
+   len = min(sg_dma_len(src_sg) - offset, length);
+   if (!dry_run) {
+   sg_dma_address(dst_sg) = sg_dma_address(src_sg) + 
offset;
+   sg_dma_len(dst_sg) = len;
+   dst_sg = sg_next(dst_sg);
+   }
+
+   length -= len;
+   offset = 0;
+   if (!length)
+   break;
+   }
+   WARN_ON_ONCE(length);
+
+   return nents;
+}
+
+static unsigned int
+intel_copy_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+   struct scatterlist *dst_sg, *src_sg;
+   unsigned int i, len, nents = 0;
+
+   dst_sg = dst_st->sgl;
+   for_each_sgtable_sg(src_st, src_sg, i) {
+   if (src_sg->length <= offset) {
+   offset -= src_sg->length;
+   continue;
+   }
+
+   nents++;
+   len = min(src_sg->length - offset, length);
+   if (!dry_run) {
+   unsigned long pfn;
+
+   pfn = page_to_pfn(sg_page(src_sg)) + offset / PAGE_SIZE;
+   sg_set_page(dst_sg, pfn_to_page(pfn), len, 0);
+   dst_sg = sg_next(dst_sg);
+   }
+
+   length -= len;
+   offset = 0;
+   if (!length)
+   break;
+   }
+   WARN_ON_ONCE(length);
+
+   return nents;
+}
+
+static noinline struct sg_table *
+intel_persistent_partial_pages(const struct i915_gtt_view *view,
+  struct drm_i915_gem_object *obj)
+{
+   u64 offset = view->partial.offset << PAGE_SHIFT;
+   struct sg_table *st, *obj_st = obj->mm.pages;
+   u64 length = view->partial.size << PAGE_SHIFT;
+   unsigned int nents;
+   int ret = -ENOMEM;
+
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (!st)
+   goto err_st_alloc;
+
+   /* Get required sg_table size */
+   nents = intel_copy_dma_sg(obj_st, st, offset, length, true);
+   if (i915_gem_object_has_struct_page(obj)) {
+   unsigned int pg_nents;
+
+   pg_nents = intel_copy_sg(obj_st, st, offset, length, true);
+   if (nents < pg_nents)
+   nents = pg_nents;
+   }
+
+   ret = sg_alloc_table(st, nents, GFP_KERNEL);
+   if (ret)
+   goto err_sg_alloc;
+
+   /* Build sg_table for specified  section */
+   intel_copy_dma_sg(obj_st, st, offset, length, false);
+   if (i915_gem_object_has_struct_page(obj))
+   intel_copy_sg(obj_st, st, offset, length, false);
+
+   return st;
+
+err_sg_alloc:
+   kfree(st);
+err_st_alloc:
+   return ERR_PTR(ret);
+}
+
 static int
 __i915_vma_get_pages(struct i915_vma *vma)
 {
@@ -1360,7 +1467,11 @@ __i915_vma_get_pages(struct i915_vma *vma)
break;
 
case I915_GTT_VIEW_PARTIAL:
-   pages = intel_partial_pages(&vma->gtt_view, vma->obj);
+   if (i915_vma_is_persistent(vma))
+   pages = intel_persistent_partial_pages(&vma->gtt_view,
+  vma->obj);
+   else
+   pages = intel_partial_pages(&vma->gtt_view, vma->obj);
break;
}
 
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 15/23] drm/i915/vm_bind: Expose i915_request_await_bind()

2023-01-17 Thread Niranjana Vishwanathapura
Rename __i915_request_await_bind() as i915_request_await_bind()
and make it non-static as it will be used in execbuf3 ioctl path.

v2: add documentation

Reviewed-by: Matthew Auld 
Reviewed-by: Andi Shyti 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_vma.c |  8 +---
 drivers/gpu/drm/i915/i915_vma.h | 16 
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 804f01b9002d..8fc93f20f70d 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1923,18 +1923,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(&vma->obj->userfault_link);
 }
 
-static int
-__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
-{
-   return __i915_request_await_exclusive(rq, &vma->active);
-}
-
 static int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request 
*rq)
 {
int err;
 
/* Wait for the vma to be bound before we start! */
-   err = __i915_request_await_bind(rq, vma);
+   err = i915_request_await_bind(rq, vma);
if (err)
return err;
 
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 1f25e45a6325..d6c05227fb04 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -55,6 +55,22 @@ void i915_vma_unpin_and_release(struct i915_vma **p_vma, 
unsigned int flags);
 #define __EXEC_OBJECT_NO_RESERVE BIT(31)
 #define __EXEC_OBJECT_NO_REQUEST_AWAIT BIT(30)
 
+/**
+ * i915_request_await_bind() - Setup request to wait for a vma bind completion
+ * @rq: the request which should wait
+ * @vma: vma whose binding @rq should wait to complete
+ *
+ * Setup the request @rq to asynchronously wait for @vma bind to complete
+ * before starting execution.
+ *
+ * Returns 0 on success, error code on failure.
+ */
+static inline int
+i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
+{
+   return __i915_request_await_exclusive(rq, &vma->active);
+}
+
 int __must_check _i915_vma_move_to_active(struct i915_vma *vma,
  struct i915_request *rq,
  struct dma_fence *fence,
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 20/23] drm/i915/vm_bind: Render VM_BIND documentation

2023-01-17 Thread Niranjana Vishwanathapura
Update i915 documentation to include VM_BIND changes
and render all VM_BIND related documentation.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/i915.rst | 78 --
 1 file changed, 59 insertions(+), 19 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 60ea21734902..01429a8f0d6c 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -283,15 +283,18 @@ An Intel GPU has multiple engines. There are several 
engine types.
 
 The Intel GPU family is a family of integrated GPU's using Unified
 Memory Access. For having the GPU "do work", user space will feed the
-GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`
-or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will
-instruct the GPU to perform work (for example rendering) and that work
-needs memory from which to read and memory to which to write. All memory
-is encapsulated within GEM buffer objects (usually created with the ioctl
-`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU
-to create will also list all GEM buffer objects that the batchbuffer reads
-and/or writes. For implementation details of memory management see
-`GEM BO Management Implementation Details`_.
+GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`,
+`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` or `DRM_IOCTL_I915_GEM_EXECBUFFER3`.
+Most such batchbuffers will instruct the GPU to perform work (for example
+rendering) and that work needs memory from which to read and memory to
+which to write. All memory is encapsulated within GEM buffer objects
+(usually created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). In vm_bind mode
+(see `VM_BIND mode`_), the batch buffer and all the GEM buffer objects that
+it reads and/or writes should be bound with vm_bind ioctl before submitting
+the batch buffer to GPU. In legacy (non-VM_BIND) mode, an ioctl providing a
+batchbuffer for the GPU to create will also list all GEM buffer objects that
+the batchbuffer reads and/or writes. For implementation details of memory
+management see `GEM BO Management Implementation Details`_.
 
 The i915 driver allows user space to create a context via the ioctl
 `DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit
@@ -309,8 +312,9 @@ In addition to the ordering guarantees, the kernel will 
restore GPU
 state via HW context when commands are issued to a context, this saves
 user space the need to restore (most of atleast) the GPU state at the
 start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer
-work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1)
-to identify what context to use with the command.
+work can pass that ID (drm_i915_gem_execbuffer3::ctx_id, or in the lower
+bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use
+with the command.
 
 The GPU has its own memory management and address space. The kernel
 driver maintains the memory translation table for the GPU. For older
@@ -318,14 +322,14 @@ GPUs (i.e. those before Gen8), there is a single global 
such translation
 table, a global Graphics Translation Table (GTT). For newer generation
 GPUs each context has its own translation table, called Per-Process
 Graphics Translation Table (PPGTT). Of important note, is that although
-PPGTT is named per-process it is actually per context. When user space
-submits a batchbuffer, the kernel walks the list of GEM buffer objects
-used by the batchbuffer and guarantees that not only is the memory of
-each such GEM buffer object resident but it is also present in the
-(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT,
-then it is given an address. Two consequences of this are: the kernel
-needs to edit the batchbuffer submitted to write the correct value of
-the GPU address when a GEM BO is assigned a GPU address and the kernel
+PPGTT is named per-process it is actually per context. In legacy
+(non-vm_bind) mode, when user space submits a batchbuffer, the kernel walks
+the list of GEM buffer objects used by the batchbuffer and guarantees that
+not only is the memory of each such GEM buffer object resident but it is
+also present in the (PP)GTT. If the GEM buffer object is not yet placed in
+the (PP)GTT, then it is given an address. Two consequences of this are: the
+kernel needs to edit the batchbuffer submitted to write the correct value
+of the GPU address when a GEM BO is assigned a GPU address and the kernel
 might evict a different GEM BO from the (PP)GTT to make address room
 for another GEM BO. Consequently, the ioctls submitting a batchbuffer
 for execution also include a list of all locations within buffers that
@@ -407,6 +411,15 @@ objects, which has the goal to make space in gpu virtual 
address spaces.
 .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
:internal:
 
+VM_BIND mode
+
+
+.

[Intel-gfx] [PATCH v10 01/23] drm/i915/vm_bind: Expose vm lookup function

2023-01-17 Thread Niranjana Vishwanathapura
Make i915_gem_vm_lookup() function non-static as it will be
used by the vm_bind feature.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
 drivers/gpu/drm/i915/gem/i915_gem_context.h |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 46e71f62fcec..b90901ad6866 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -346,7 +346,16 @@ static int proto_context_register(struct 
drm_i915_file_private *fpriv,
return ret;
 }
 
-static struct i915_address_space *
+/**
+ * i915_gem_vm_lookup() - looks up for the VM reference given the vm id
+ * @file_priv: the private data associated with the user's file
+ * @id: the VM id
+ *
+ * Finds the VM reference associated to a specific id.
+ *
+ * Returns the VM pointer on success, NULL in case of failure.
+ */
+struct i915_address_space *
 i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
 {
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e5b0f66ea1fe..899fa8f1e0fe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -139,6 +139,9 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev, 
void *data,
 int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file);
 
+struct i915_address_space *
+i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
+
 struct i915_gem_context *
 i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id);
 
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 18/23] drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts

2023-01-17 Thread Niranjana Vishwanathapura
Only support vm_bind mode with non-recoverable contexts.
With new vm_bind mode with eb3 submission path, we need not
support older recoverable contexts.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fb4d2dab5053..9809c58316c2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1617,6 +1617,12 @@ i915_gem_create_context(struct drm_i915_private *i915,
INIT_LIST_HEAD(&ctx->stale.engines);
 
if (pc->vm) {
+   /* Only non-recoverable contexts are allowed in vm_bind mode */
+   if (i915_gem_vm_is_vm_bind_mode(pc->vm) &&
+   (pc->user_flags & BIT(UCONTEXT_RECOVERABLE))) {
+   err = -EINVAL;
+   goto err_ctx;
+   }
vm = i915_vm_get(pc->vm);
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 07/23] drm/i915/vm_bind: Support for VM private BOs

2023-01-17 Thread Niranjana Vishwanathapura
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the execbuf path.

VM private BOs can be only mapped on specified VM and cannot be dmabuf
exported. Also, they are supported only in vm_bind mode.

v2: Pad struct drm_i915_gem_create_ext_vm_private for 64bit alignment,
add input validity checks.
v3: Create root_obj only for ppgtt.
v4: Fix releasing of obj->priv_root. Do not create vm->root_obj yet.
Allow vm private object creation only in vm_bind mode.
Replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode().

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  1 +
 drivers/gpu/drm/i915/gem/i915_gem_create.c| 54 ++-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  6 +++
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  4 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  3 ++
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  6 +++
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  9 
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  1 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
 drivers/gpu/drm/i915/i915_vma.c   |  1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  2 +
 include/uapi/drm/i915_drm.h   | 33 
 12 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b90901ad6866..fb4d2dab5053 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -83,6 +83,7 @@
 
 #include "i915_file_private.h"
 #include "i915_gem_context.h"
+#include "i915_gem_internal.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 86469710bd59..717403c79226 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
 #include "pxp/intel_pxp.h"
 
 #include "i915_drv.h"
+#include "i915_gem_context.h"
 #include "i915_gem_create.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
@@ -251,6 +252,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   u32 vm_id;
 };
 
 static void repr_placements(char *buf, size_t size,
@@ -400,9 +402,32 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
 
+static int ext_set_vm_private(struct i915_user_extension __user *base,
+ void *data)
+{
+   struct drm_i915_gem_create_ext_vm_private ext;
+   struct create_ext *ext_data = data;
+
+   if (copy_from_user(&ext, base, sizeof(ext)))
+   return -EFAULT;
+
+   /* Reserved fields must be 0 */
+   if (ext.rsvd)
+   return -EINVAL;
+
+   /* vm_id 0 is reserved */
+   if (!ext.vm_id)
+   return -ENOENT;
+
+   ext_data->vm_id = ext.vm_id;
+
+   return 0;
+}
+
 static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+   [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
 };
 
 /**
@@ -418,6 +443,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create_ext *args = data;
struct create_ext ext_data = { .i915 = i915 };
+   struct i915_address_space *vm = NULL;
struct drm_i915_gem_object *obj;
int ret;
 
@@ -431,6 +457,17 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (ret)
return ret;
 
+   if (ext_data.vm_id) {
+   vm = i915_gem_vm_lookup(file->driver_priv, ext_data.vm_id);
+   if (unlikely(!vm))
+   return -ENOENT;
+
+   if (!i915_gem_vm_is_vm_bind_mode(vm)) {
+   ret = -EINVAL;
+   goto vm_put;
+   }
+   }
+
if (!ext_data.n_placements) {
ext_data.placements[0] =
intel_memory_region_by_type(i915, INTEL_MEMORY_SYSTEM);
@@ -457,8 +494,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.placements,
ext_data.n_placements,
ext_data.flags);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
+   if (IS_ERR(obj)) {
+   ret = PTR_E

[Intel-gfx] [PATCH v10 11/23] drm/i915/vm_bind: Abstract out common execbuf functions

2023-01-17 Thread Niranjana Vishwanathapura
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Abstract out the common execbuf functionalities into a
separate file where possible, thus allowing code sharing.

v2: Use drm_dbg instead of DRM_DEBUG

Reviewed-by: Andi Shyti 
Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++
 .../drm/i915/gem/i915_gem_execbuffer_common.h |  76 ++
 3 files changed, 748 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index fc3ed0aea034..68b209a859f1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -153,6 +153,7 @@ gem-y += \
gem/i915_gem_create.o \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
+   gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
new file mode 100644
index ..fb1364f08a61
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
@@ -0,0 +1,671 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_gem_execbuffer_common.h"
+
+#define __EXEC_COMMON_FENCE_WAIT   BIT(0)
+#define __EXEC_COMMON_FENCE_SIGNAL BIT(1)
+
+static struct i915_request *eb_throttle(struct intel_context *ce)
+{
+   struct intel_ring *ring = ce->ring;
+   struct intel_timeline *tl = ce->timeline;
+   struct i915_request *rq;
+
+   /*
+* Completely unscientific finger-in-the-air estimates for suitable
+* maximum user request size (to avoid blocking) and then backoff.
+*/
+   if (intel_ring_update_space(ring) >= PAGE_SIZE)
+   return NULL;
+
+   /*
+* Find a request that after waiting upon, there will be at least half
+* the ring available. The hysteresis allows us to compete for the
+* shared ring and should mean that we sleep less often prior to
+* claiming our resources, but not so long that the ring completely
+* drains before we can submit our next request.
+*/
+   list_for_each_entry(rq, &tl->requests, link) {
+   if (rq->ring != ring)
+   continue;
+
+   if (__intel_ring_space(rq->postfix,
+  ring->emit, ring->size) > ring->size / 2)
+   break;
+   }
+   if (&rq->link == &tl->requests)
+   return NULL; /* weird, we will check again later for real */
+
+   return i915_request_get(rq);
+}
+
+static int eb_pin_timeline(struct intel_context *ce, bool throttle,
+  bool nonblock)
+{
+   struct intel_timeline *tl;
+   struct i915_request *rq = NULL;
+
+   /*
+* Take a local wakeref for preparing to dispatch the execbuf as
+* we expect to access the hardware fairly frequently in the
+* process, and require the engine to be kept awake between accesses.
+* Upon dispatch, we acquire another prolonged wakeref that we hold
+* until the timeline is idle, which in turn releases the wakeref
+* taken on the engine, and the parent device.
+*/
+   tl = intel_context_timeline_lock(ce);
+   if (IS_ERR(tl))
+   return PTR_ERR(tl);
+
+   intel_context_enter(ce);
+   if (throttle)
+   rq = eb_throttle(ce);
+   intel_context_timeline_unlock(tl);
+
+   if (rq) {
+   long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
+
+   if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
+ timeout) < 0) {
+   i915_request_put(rq);
+
+   /*
+* Error path, cannot use intel_context_timeline_lock as
+* that is user interruptable and this clean up step
+* must be done.
+*/
+   mutex_lock(&ce->timeline->mutex);
+   intel_context_exit(ce);
+   mutex_unlock(&ce->timeline->mutex);
+
+   if (nonblock)
+   return -EWOULDBLOCK;
+   else
+   return -EINTR;
+   }
+   i915_request_put(rq);
+   }
+
+   return 0;
+}
+
+/**
+ * i915_eb_pin_engine() - Pin the

[Intel-gfx] [PATCH v10 03/23] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()

2023-01-17 Thread Niranjana Vishwanathapura
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 18 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  2 ++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 005a7f842784..86469710bd59 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -15,10 +15,18 @@
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
 
-static u32 object_max_page_size(struct intel_memory_region **placements,
-   unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the regions
+ * @placements:  list of regions
+ * @n_placements: number of the placements
+ *
+ * Returns the largest of min_page_size of the @placements,
+ * or I915_GTT_PAGE_SIZE_4K if @n_placements is 0.
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
 {
-   u32 max_page_size = 0;
+   u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
 
for (i = 0; i < n_placements; i++) {
@@ -28,7 +36,6 @@ static u32 object_max_page_size(struct intel_memory_region 
**placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
 
-   GEM_BUG_ON(!max_page_size);
return max_page_size;
 }
 
@@ -99,7 +106,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private 
*i915, u64 size,
 
i915_gem_flush_free_objects(i915);
 
-   size = round_up(size, object_max_page_size(placements, n_placements));
+   size = round_up(size, i915_gem_object_max_page_size(placements,
+   n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3db53769864c..5455ca0eabe9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
 }
 
 void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements);
 
 void i915_objects_module_exit(void);
 int i915_objects_module_init(void);
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 02/23] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()

2023-01-17 Thread Niranjana Vishwanathapura
Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_sw_fence.c | 28 +---
 drivers/gpu/drm/i915/i915_sw_fence.h | 23 +--
 2 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index cc2a8821d22a..ae06d35db056 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "i915_sw_fence.h"
 #include "i915_selftest.h"
@@ -569,11 +568,26 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence 
*fence,
return ret;
 }
 
-int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
-   struct dma_resv *resv,
-   bool write,
-   unsigned long timeout,
-   gfp_t gfp)
+/**
+ * __i915_sw_fence_await_reservation() - Setup a fence to wait on a dma-resv
+ * object with specified usage.
+ * @fence: the fence that needs to wait
+ * @resv: dma-resv object
+ * @usage: dma_resv_usage (See enum dma_resv_usage)
+ * @timeout: how long to wait in jiffies
+ * @gfp: allocation mode
+ *
+ * Setup the @fence to asynchronously wait on dma-resv object @resv for
+ * @usage to complete before signaling.
+ *
+ * Returns 0 if there is nothing to wait on, -ve error code upon error
+ * and >0 upon successfully setting up the wait.
+ */
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp)
 {
struct dma_resv_iter cursor;
struct dma_fence *f;
@@ -582,7 +596,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence 
*fence,
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
 
-   dma_resv_iter_begin(&cursor, resv, dma_resv_usage_rw(write));
+   dma_resv_iter_begin(&cursor, resv, usage);
dma_resv_for_each_fence_unlocked(&cursor, f) {
pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
gfp);
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h 
b/drivers/gpu/drm/i915/i915_sw_fence.h
index f752bfc7c6e1..9c4859dc4c0d 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -10,13 +10,13 @@
 #define _I915_SW_FENCE_H_
 
 #include 
+#include 
 #include 
 #include 
 #include  /* for NOTIFY_DONE */
 #include 
 
 struct completion;
-struct dma_resv;
 struct i915_sw_fence;
 
 enum i915_sw_fence_notify {
@@ -89,11 +89,22 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence 
*fence,
  unsigned long timeout,
  gfp_t gfp);
 
-int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
-   struct dma_resv *resv,
-   bool write,
-   unsigned long timeout,
-   gfp_t gfp);
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp);
+
+static inline int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ bool write,
+ unsigned long timeout,
+ gfp_t gfp)
+{
+   return __i915_sw_fence_await_reservation(fence, resv,
+dma_resv_usage_rw(write),
+timeout, gfp);
+}
 
 bool i915_sw_fence_await(struct i915_sw_fence *fence);
 void i915_sw_fence_complete(struct i915_sw_fence *fence);
-- 
2.21.0.rc0.32.g243a4c7e27



[Intel-gfx] [PATCH v10 09/23] drm/i915/vm_bind: Support persistent vma activeness tracking

2023-01-17 Thread Niranjana Vishwanathapura
Do not use i915_vma activeness tracking for persistent vmas.

As persistent vmas are part of working set for each execbuf
submission on that address space (VM), a persistent vma is
active if the VM active. As vm->root_obj->base.resv will be
updated for each submission on that VM, it correctly
represent whether the VM is active or not.

Add i915_vm_is_active() and i915_vm_sync() functions based
on vm->root_obj->base.resv with DMA_RESV_USAGE_BOOKKEEP
usage. dma-resv fence list will be updated with this usage
during each submission with this VM in the new execbuf3
ioctl path.

Update i915_vma_is_active(), i915_vma_sync() and the
__i915_vma_unbind_async() functions to properly handle
persistent vmas.

v2: Ensure lvalue of dma_resv_wait_timeout() call is long.
v3: Do not await for purged vmas to become idle during
async unbind

Reviewed-by: Andi Shyti 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  3 +++
 drivers/gpu/drm/i915/i915_vma.c | 28 +
 drivers/gpu/drm/i915/i915_vma.h | 25 +-
 4 files changed, 83 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7bd1861ddbdf..1d8506548d4a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -25,6 +25,45 @@
 #include "i915_trace.h"
 #include "i915_vgpu.h"
 
+/**
+ * i915_vm_sync() - Wait until address space is not in use
+ * @vm: address space
+ *
+ * Waits until all requests using the address space are complete.
+ *
+ * Returns: 0 if success, -ve err code upon failure
+ */
+int i915_vm_sync(struct i915_address_space *vm)
+{
+   long ret;
+
+   /* Wait for all requests under this vm to finish */
+   ret = dma_resv_wait_timeout(vm->root_obj->base.resv,
+   DMA_RESV_USAGE_BOOKKEEP, false,
+   MAX_SCHEDULE_TIMEOUT);
+   if (ret < 0)
+   return ret;
+   else if (ret > 0)
+   return 0;
+   else
+   return -ETIMEDOUT;
+}
+
+/**
+ * i915_vm_is_active() - Check if address space is being used
+ * @vm: address space
+ *
+ * Check if any request using the specified address space is
+ * active.
+ *
+ * Returns: true if address space is active, false otherwise.
+ */
+bool i915_vm_is_active(const struct i915_address_space *vm)
+{
+   return !dma_resv_test_signaled(vm->root_obj->base.resv,
+  DMA_RESV_USAGE_BOOKKEEP);
+}
+
 int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object *obj,
   struct sg_table *pages)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 243419783052..e62b52c74586 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -52,4 +52,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
 
 #define PIN_OFFSET_MASKI915_GTT_PAGE_MASK
 
+int i915_vm_sync(struct i915_address_space *vm);
+bool i915_vm_is_active(const struct i915_address_space *vm);
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 353203bd5685..b44fd5f73b64 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -422,6 +422,24 @@ int i915_vma_wait_for_bind(struct i915_vma *vma)
return err;
 }
 
+/**
+ * i915_vma_sync() - Wait for the vma to be idle
+ * @vma: vma to be tested
+ *
+ * Returns 0 on success and error code on failure
+ */
+int i915_vma_sync(struct i915_vma *vma)
+{
+   int ret;
+
+   /* Wait for the asynchronous bindings and pending GPU reads */
+   ret = i915_active_wait(&vma->active);
+   if (ret || !i915_vma_is_persistent(vma) || i915_vma_is_purged(vma))
+   return ret;
+
+   return i915_vm_sync(vma->vm);
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
 static int i915_vma_verify_bind_complete(struct i915_vma *vma)
 {
@@ -1917,6 +1935,8 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
int err;
 
assert_object_held(obj);
+   if (i915_vma_is_persistent(vma))
+   return -EINVAL;
 
GEM_BUG_ON(!vma->pages);
 
@@ -2131,6 +2151,14 @@ static struct dma_fence *__i915_vma_unbind_async(struct 
i915_vma *vma)
return ERR_PTR(-EBUSY);
}
 
+   if (i915_vma_is_persistent(vma) && !i915_vma_is_purged(vma) &&
+   __i915_sw_fence_await_reservation(&vma->resource->chain,
+ vma->vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP,
+ i915_fence_timeout(vma->vm->i915),
+ GFP_NOWAIT | __GFP_NOWARN) < 0)
+   return ERR_PTR(-EBUSY);
+
fence = __i915_vma_evict(vma, true)

[Intel-gfx] [PATCH v10 06/23] drm/i915/vm_bind: Implement bind and unbind of object

2023-01-17 Thread Niranjana Vishwanathapura
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

v2: On older platforms ctx->vm is not set, check for it.
In vm_bind call, add vma to vm_bind_list.
Add more input validity checks.
Update some documentation.
v3: In vm_bind call, add vma to vm_bound_list as user can
request a fence and pass to execbuf3 as input fence.
Remove short term pinning with PIN_VALIDATE flag.
v4: Replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode().
v5: Ensure all reserved fields are 0, use PIN_NOEVICT.
v6: Add reserved fields to drm_i915_gem_vm_bind.

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_context.h   |  15 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 330 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   9 +
 drivers/gpu/drm/i915/i915_driver.c|   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 105 ++
 11 files changed, 519 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f47f00b162a4..fc3ed0aea034 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -171,6 +171,7 @@ gem-y += \
gem/i915_gem_ttm_move.o \
gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
+   gem/i915_gem_vm_bind_object.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 899fa8f1e0fe..e8b41aa8f8c4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -139,6 +139,21 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
 int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file);
 
+/**
+ * i915_gem_vm_is_vm_bind_mode() - Check if address space is in vm_bind mode
+ * @vm: the address space
+ *
+ * Returns:
+ * true: @vm is in vm_bind mode; allows only vm_bind method of binding.
+ * false: @vm is not in vm_bind mode; allows only legacy execbuff method
+ *of binding.
+ */
+static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
+{
+   /* No support to enable vm_bind mode yet */
+   return false;
+}
+
 struct i915_address_space *
 i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 192bb3f10733..6456f15448bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -785,6 +785,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
 
+   if (ctx->vm && i915_gem_vm_is_vm_bind_mode(ctx->vm)) {
+   i915_gem_context_put(ctx);
+   return -EOPNOTSUPP;
+   }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
new file mode 100644
index ..5064aba9ab87
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@

[Intel-gfx] [PATCH v10 00/23] drm/i915/vm_bind: Add VM_BIND functionality

2023-01-17 Thread Niranjana Vishwanathapura
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
buffer objects (BOs) or sections of a BOs at specified GPU virtual
addresses on a specified address space (VM). Multiple mappings can map
to the same physical pages of an object (aliasing). These mappings (also
referred to as persistent mappings) will be persistent across multiple
GPU submissions (execbuf calls) issued by the UMD, without user having
to provide a list of all required mappings during each submission (as
required by older execbuf mode).

This patch series support VM_BIND version 1, as described by the param
I915_PARAM_VM_BIND_VERSION.

Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in
vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any execlist support and all the
legacy support like relocations etc., are removed.

NOTEs:
* It is based on below VM_BIND design+uapi rfc.
  Documentation/gpu/rfc/i915_vm_bind.rst

* The IGT RFC series is posted as,
  [PATCH i-g-t v10 0/19] vm_bind: Add VM_BIND validation support

v2: Address various review comments
v3: Address review comments and other fixes
v4: Remove vm_unbind out fence uapi which is not supported yet,
replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()
v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to
non-recoverable faults
v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind,
add new patch for async vm_unbind support
v7: Rebased, minor cleanups as per review feedback
v8: Rebased, add capture support
v9: Address capture support feedback from v8
v10: Properly handle vma->resource for mappings with capture request

Test-with: 20230118071350.17498-1-niranjana.vishwanathap...@intel.com

Signed-off-by: Niranjana Vishwanathapura 

Niranjana Vishwanathapura (23):
  drm/i915/vm_bind: Expose vm lookup function
  drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()
  drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
  drm/i915/vm_bind: Support partially mapped vma resource
  drm/i915/vm_bind: Add support to create persistent vma
  drm/i915/vm_bind: Implement bind and unbind of object
  drm/i915/vm_bind: Support for VM private BOs
  drm/i915/vm_bind: Add support to handle object evictions
  drm/i915/vm_bind: Support persistent vma activeness tracking
  drm/i915/vm_bind: Add out fence support
  drm/i915/vm_bind: Abstract out common execbuf functions
  drm/i915/vm_bind: Use common execbuf functions in execbuf path
  drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
  drm/i915/vm_bind: Update i915_vma_verify_bind_complete()
  drm/i915/vm_bind: Expose i915_request_await_bind()
  drm/i915/vm_bind: Handle persistent vmas in execbuf3
  drm/i915/vm_bind: userptr dma-resv changes
  drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts
  drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode
  drm/i915/vm_bind: Render VM_BIND documentation
  drm/i915/vm_bind: Async vm_unbind support
  drm/i915/vm_bind: Properly build persistent map sg table
  drm/i915/vm_bind: Support capture of persistent mappings

 Documentation/gpu/i915.rst|  78 +-
 drivers/gpu/drm/i915/Makefile |   3 +
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  43 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.h   |  17 +
 drivers/gpu/drm/i915/gem/i915_gem_create.c|  72 +-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|   6 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 522 +--
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 872 ++
 .../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++
 .../drm/i915/gem/i915_gem_execbuffer_common.h |  76 ++
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   3 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   2 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   6 +
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  19 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  30 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 463 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  22 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  28 +
 drivers/gpu/drm/i915/i915_driver.c|   4 +
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_gem.c   |  14 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  39 +
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   3 +
 drivers/gpu/drm/i915/i915_getparam.c  |   3 +
 drivers/gpu/drm/i915/i915_gpu_error.c |  52 +-
 drivers/gpu/drm/i915/i915_sw_fence.c  |  28 +-
 drivers/gpu/drm/i915/i915_sw_fence.h  |  23 +-
 drivers/gpu/drm/i915/i915_vma.c   | 301 +-
 drivers/gpu/drm/i915/i915_vma.h   |  70 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  43 +
 include/uapi/drm/i915_drm.h   | 281 +-
 32 files changed, 3245 insertions(+), 553 d

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: move snps_phy_failed_calibration to display sub-struct under snps

2023-01-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: move snps_phy_failed_calibration 
to display sub-struct under snps
URL   : https://patchwork.freedesktop.org/series/112933/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12592_full -> Patchwork_112933v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/index.html

Participating hosts (13 -> 11)
--

  Additional (1): shard-rkl0 
  Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_112933v1_full:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-dg1-18/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-dg1-14/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html

  
Known issues


  Here are the changes found in Patchwork_112933v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#644])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gen9_exec_parse@allowed-single:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#5566] / 
[i915#716])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-glk7/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2346])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-glk3/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html

  * igt@perf@oa-exponents:
- shard-glk:  [PASS][11] -> [INCOMPLETE][12] ([i915#5213])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk6/igt@p...@oa-exponents.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-glk9/igt@p...@oa-exponents.html

  * igt@runner@aborted:
- shard-glk:  NOTRUN -> ([FAIL][13], [FAIL][14]) ([i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-glk7/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-glk9/igt@run...@aborted.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-rkl-5/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@drm_read@short-buffer-block:
- {shard-rkl}:[SKIP][17] ([i915#4098]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-5/igt@drm_r...@short-buffer-block.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-rkl-6/igt@drm_r...@short-buffer-block.html

  * igt@fbdev@eof:
- {shard-rkl}:[SKIP][19] ([i915#2582]) -> [PASS][20] +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-3/igt@fb...@eof.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-rkl-6/igt@fb...@eof.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22] +3 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 for VDSC

2023-01-17 Thread Patchwork
== Series Details ==

Series: Enable YCbCr420 for VDSC
URL   : https://patchwork.freedesktop.org/series/112993/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12596 -> Patchwork_112993v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/index.html

Participating hosts (44 -> 43)
--

  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_112993v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][1] ([i915#7793])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
- fi-skl-6600u:   [PASS][2] -> [FAIL][3] ([fdo#103375])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12596/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6600u:   [PASS][4] -> [DMESG-FAIL][5] ([i915#5334])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12596/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050:   [PASS][6] -> [FAIL][7] ([i915#6298])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12596/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem:
- {bat-adln-1}:   [DMESG-WARN][8] ([i915#2867]) -> [PASS][9] +9 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12596/bat-adln-1/igt@i915_selftest@l...@gem.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/bat-adln-1/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@hangcheck:
- {bat-dg2-8}:[INCOMPLETE][10] ([i915#7834]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12596/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][12] ([i915#6257]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12596/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/bat-rpls-2/igt@i915_selftest@l...@requests.html

  
 Warnings 

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   [INCOMPLETE][14] ([i915#4817]) -> [FAIL][15] 
([fdo#103375])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12596/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112993v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
  [i915#7793]: https://gitlab.freedesktop.org/drm/intel/issues/7793
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7834]: https://gitlab.freedesktop.org/drm/intel/issues/7834


Build changes
-

  * Linux: CI_DRM_12596 -> Patchwork_112993v1

  CI-20190529: 20190529
  CI_DRM_12596: 0a0ee61784df01ac098a92bd43673ee30c629f13 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7121: aa16e81259f59734230d441905b9d0f605e4a4b5 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112993v1: 0a0ee61784df01ac098a92bd43673ee30c629f13 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

d0975aa09876 drm

Re: [Intel-gfx] [PATCH v9 23/23] drm/i915/vm_bind: Support capture of persistent mappings

2023-01-17 Thread Niranjana Vishwanathapura

On Tue, Dec 13, 2022 at 12:03:07PM +, Matthew Auld wrote:

On 12/12/2022 23:15, Niranjana Vishwanathapura wrote:

Support dump capture of persistent mappings upon user request.

Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling, thus not adding any
additional latency to the submission path.

A list of persistent vmas requiring capture is maintained
instead of a list of vma resources. This allows for no
additional handling around eviction.

v2: enable with CONFIG_DRM_I915_CAPTURE_ERROR, remove gfp
overwrite, add kernel-doc and expand commit message

Signed-off-by: Brian Welty 
Signed-off-by: Niranjana Vishwanathapura 
---
 .../gpu/drm/i915/gem/i915_gem_vm_bind_object.c | 13 +
 drivers/gpu/drm/i915/gt/intel_gtt.c|  5 +
 drivers/gpu/drm/i915/gt/intel_gtt.h|  7 +++
 drivers/gpu/drm/i915/i915_gpu_error.c  | 18 +-
 drivers/gpu/drm/i915/i915_vma.c|  4 
 drivers/gpu/drm/i915/i915_vma_types.h  |  4 
 include/uapi/drm/i915_drm.h|  9 +++--
 7 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..562a67a988f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, 
bool release_obj)
 {
lockdep_assert_held(&vma->vm->vm_bind_lock);
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   mutex_lock(&vma->vm->vm_capture_lock);
+   if (!list_empty(&vma->vm_capture_link))
+   list_del_init(&vma->vm_capture_link);
+   mutex_unlock(&vma->vm->vm_capture_lock);
+#endif
spin_lock(&vma->vm->vm_rebind_lock);
if (!list_empty(&vma->vm_rebind_link))
list_del_init(&vma->vm_rebind_link);
@@ -357,6 +363,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space 
*vm,
continue;
}
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+   mutex_lock(&vm->vm_capture_lock);
+   list_add_tail(&vma->vm_capture_link, 
&vm->vm_capture_list);
+   mutex_unlock(&vm->vm_capture_lock);
+   }
+#endif
list_add_tail(&vma->vm_bind_link, &vm->vm_bound_list);
i915_vm_bind_it_insert(vma, &vm->va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2e4c9fabf3b8..103ca55222be 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,11 @@ void i915_address_space_init(struct i915_address_space 
*vm, int subclass)
spin_lock_init(&vm->vm_rebind_lock);
spin_lock_init(&vm->userptr_invalidated_lock);
INIT_LIST_HEAD(&vm->userptr_invalidated_list);
+
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   INIT_LIST_HEAD(&vm->vm_capture_list);
+   mutex_init(&vm->vm_capture_lock);
+#endif
 }
 void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 620b4e020a9f..7f69e1d4fb5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,13 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private objects */
struct drm_i915_gem_object *root_obj;
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+   /* @vm_capture_list: list of vm captures */
+   struct list_head vm_capture_list;
+   /* @vm_capture_lock: protects vm_capture_list */
+   struct mutex vm_capture_lock;
+#endif
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64..76b2834ce958 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1460,6 +1460,22 @@ capture_vma(struct intel_engine_capture_vma *next,
return next;
 }
+static struct intel_engine_capture_vma *
+capture_user_vm(struct intel_engine_capture_vma *capture,
+   struct i915_address_space *vm, gfp_t gfp)
+{
+   struct i915_vma *vma;
+
+   mutex_lock(&vm->vm_capture_lock);
+   /* vma->resource must be valid here as persistent vmas are bound */
+   list_for_each_entry(vma, &vm->vm_capture_list, vm_capture_link)
+   capture = capture_vma_snapshot(capture, vma->resource,


Thinking some more on this, I don't think we can actually do this. The 
vma->resource at this stage could be complete nonsense (could even be 
NULL?), if you consider piplelined migrations. For example if we async 
evict something, the obje

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable YCbCr420 for VDSC

2023-01-17 Thread Patchwork
== Series Details ==

Series: Enable YCbCr420 for VDSC
URL   : https://patchwork.freedesktop.org/series/112993/
State : warning

== Summary ==

Error: dim checkpatch failed
744170a1110d drm/dp_helper: Add helper to check if the sink supports given 
format with DSC
17cba7d62236 drm/i915/dp: Check if DSC supports the given output_format
98689fb69bc8 drm/i915: Adding the new registers for DSC
0d3a34008e55 drm/i915: Enable YCbCr420 for VDSC
-:199: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_row' - possible 
side-effects?
#199: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420)  do { \
+   if (bpc == (_bpc)) {\
+   if (_is_420)\
+   return 
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+   else\
+   return 
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+   }   \
 } while (0)

-:199: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_col' - possible 
side-effects?
#199: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420)  do { \
+   if (bpc == (_bpc)) {\
+   if (_is_420)\
+   return 
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+   else\
+   return 
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+   }   \
 } while (0)

total: 0 errors, 0 warnings, 2 checks, 228 lines checked
219616799a62 drm/i915: Fill in native_420 field
2fcd5e2628ea drm/i915/vdsc: Check slice design requirement




[Intel-gfx] [PATCH v8 6/6] drm/i915/vdsc: Check slice design requirement

2023-01-17 Thread Suraj Kandpal
Add function to check if slice design requirements are being
met as defined in Bspec: 49259 in the section
Slice Design Requirement

--v7
-remove full bspec link [Jani]
-rename intel_dsc_check_slice_design_req to
intel_dsc_slice_dimensions_valid [Jani]

--v8
-fix condition to check if slice width and height are
of two
-fix minimum pixel in slice condition

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 32 +++
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 13ad853e24eb..6ebefc195e83 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -447,6 +447,29 @@ calculate_rc_params(struct rc_parameters *rc,
}
 }
 
+static int intel_dsc_slice_dimensions_valid(struct intel_crtc_state 
*pipe_config,
+   struct drm_dsc_config *vdsc_cfg)
+{
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_RGB ||
+   pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
+   if (vdsc_cfg->slice_height > 4095)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height * vdsc_cfg->slice_width >= 15000)
+   return -EINVAL;
+   } else if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+   if (vdsc_cfg->slice_width % 2)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height % 2)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height > 4094)
+   return -EINVAL;
+   if (vdsc_cfg->slice_height * vdsc_cfg->slice_width >= 3)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int intel_dsc_compute_params(struct intel_crtc_state *pipe_config)
 {
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
@@ -455,11 +478,20 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
const struct rc_parameters *rc_params;
struct rc_parameters *rc = NULL;
+   int err;
u8 i = 0;
 
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
 pipe_config->dsc.slice_count);
+
+   err = intel_dsc_slice_dimensions_valid(pipe_config, vdsc_cfg);
+
+   if (err) {
+   drm_dbg_kms(&dev_priv->drm, "Slice dimension requirements not 
met\n");
+   return err;
+   }
+
/*
 * According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb 
is 0
 * else 1
-- 
2.25.1



[Intel-gfx] [PATCH v8 5/6] drm/i915: Fill in native_420 field

2023-01-17 Thread Suraj Kandpal
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.

---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420 is true

---v3
-adding display version check to solve igt issue

--v7
-remove is_pipe_dsc check as its always true for D14 [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/icl_dsi.c|  2 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  3 -
 drivers/gpu/drm/i915/display/intel_vdsc.c | 72 ++-
 3 files changed, 69 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ae14c794c4bc..ff9e15dd7595 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1626,8 +1626,6 @@ static int gen11_dsi_dsc_compute_config(struct 
intel_encoder *encoder,
if (crtc_state->dsc.slice_count > 1)
crtc_state->dsc.dsc_split = true;
 
-   vdsc_cfg->convert_rgb = true;
-
/* FIXME: initialize from VBT */
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6e531872ff38..2adac42e585d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1459,9 +1459,6 @@ static int intel_dp_dsc_compute_params(struct 
intel_encoder *encoder,
min(intel_dp_source_dsc_version_minor(intel_dp),
intel_dp_sink_dsc_version_minor(intel_dp));
 
-   vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP 
- DP_DSC_SUPPORT] &
-   DP_DSC_RGB;
-
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
if (!line_buf_depth) {
drm_dbg_kms(&i915->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ed16f63d6355..13ad853e24eb 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -460,14 +460,47 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
 pipe_config->dsc.slice_count);
-
-   /* Gen 11 does not support YCbCr */
+   /*
+* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb 
is 0
+* else 1
+*/
+   vdsc_cfg->convert_rgb = !(pipe_config->output_format == 
INTEL_OUTPUT_FORMAT_YCBCR420 ||
+ pipe_config->output_format == 
INTEL_OUTPUT_FORMAT_YCBCR444);
+
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   vdsc_cfg->native_420 = true;
+   /* We do not support YcBCr422 as of now */
+   vdsc_cfg->native_422 = false;
+   /* Gen 11 does not support YCbCr422 */
vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
 
/* Gen 11 only supports integral values of bpp */
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+   /*
+* According to DSC 1.2 specs if native_420 is set:
+* -We need to double the current bpp.
+* -second_line_bpg_offset is 12 in general and equal to 
2*(slice_height-1) if slice
+* height < 8.
+* -second_line_offset_adj is 512 as shown by emperical values to yeild 
best chroma
+* preservation in second line.
+* -nsl_bpg_offset is calculated as second_line_offset/slice_height -1 
then rounded
+* up to 16 fractional bits, we left shift second line offset by 11 to 
preserve 11
+* fractional bits.
+*/
+   if (vdsc_cfg->native_420) {
+   vdsc_cfg->bits_per_pixel <<= 1;
+   if (vdsc_cfg->slice_height >= 8)
+   vdsc_cfg->second_line_bpg_offset = 12;
+   else
+   vdsc_cfg->second_line_bpg_offset =
+   2 * (vdsc_cfg->slice_height - 1);
+   vdsc_cfg->second_line_offset_adj = 512;
+   vdsc_cfg->nsl_bpg_offset = 
DIV_ROUND_UP(vdsc_cfg->second_line_bpg_offset << 11,
+   vdsc_cfg->slice_height 
- 1);
+   }
+
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
 
for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
@@ -594,8 +627,13 @@ static void intel_dsc_pps_configure(const struct 
intel_crtc_state *crtc_state)
DSC_VER_MIN_SHIFT |
vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
-   if (vdsc_cfg->dsc_version_minor == 2)
+   

[Intel-gfx] [PATCH v8 4/6] drm/i915: Enable YCbCr420 for VDSC

2023-01-17 Thread Suraj Kandpal
Implementation of VDSC for YCbCr420.
Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c
(Derived from C-Model, which is given along with DSC1.2a Spec from Vesa)
intel_lookup_range_min/max_qp functons need to take into account the
output format. Based on that appropriate qp table need to be chosen.
Other rc_parameters need to be set where currently values for 444 format
is hardcoded in calculate_rc_parameters( ).
vdsc_cfg struct needs to be filled with output format information, where
these are hardcoded for 444 format.
Bspec: 49259

Signed-off-by: Suraj Kandpal 
Reviewed-by: Vandita Kulkarni 
---
 .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
 .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c |   4 +-
 3 files changed, 180 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c 
b/drivers/gpu/drm/i915/display/intel_qp_tables.c
index 6f8e4ec5c0fb..6e86c0971d24 100644
--- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
+++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
@@ -17,6 +17,15 @@
 /* from BPP 6 to 36 in steps of 0.5 */
 #define RC_RANGE_QP444_12BPC_MAX_NUM_BPP   61
 
+/* from BPP 6 to 24 in steps of 0.5 */
+#define RC_RANGE_QP420_8BPC_MAX_NUM_BPP17
+
+/* from BPP 6 to 30 in steps of 0.5 */
+#define RC_RANGE_QP420_10BPC_MAX_NUM_BPP   23
+
+/* from BPP 6 to 36 in steps of 0.5 */
+#define RC_RANGE_QP420_12BPC_MAX_NUM_BPP   29
+
 /*
  * These qp tables are as per the C model
  * and it has the rows pointing to bpps which increment
@@ -283,26 +292,182 @@ static const u8 
rc_range_maxqp444_12bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_12BPC
  11, 11, 10, 10, 10, 10, 10, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 6, 6, 5, 
5, 4 }
 };
 
-#define PARAM_TABLE(_minmax, _bpc, _row, _col)  do { \
-   if (bpc == (_bpc)) \
-   return rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+static const u8 
rc_range_minqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 0 },
+   { 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 1, 1 },
+   { 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 1, 1 },
+   { 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 2, 2, 1 },
+   { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 3, 3, 2, 1 },
+   { 9, 8, 8, 7, 7, 7, 7, 7, 7, 6, 5, 5, 4, 3, 3, 3, 2 },
+   { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3 }
+};
+
+static const u8 
rc_range_maxqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+   { 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+   { 5, 5, 5, 5, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 6, 6, 6, 6, 6, 5, 4, 3, 2, 2, 2, 1, 1, 1, 1, 0, 0 },
+   { 7, 7, 7, 7, 7, 5, 4, 3, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 2, 2, 2, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1 },
+   { 8, 8, 8, 8, 8, 7, 6, 5, 4, 4, 4, 3, 3, 2, 2, 2, 1 },
+   { 9, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
+   { 10, 10, 9, 9, 9, 8, 7, 6, 5, 5, 5, 4, 4, 3, 3, 2, 2 },
+   { 10, 10, 10, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 2, 2 },
+   { 11, 11, 10, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4, 3, 3, 2 },
+   { 11, 11, 11, 10, 9, 9, 9, 8, 7, 7, 6, 5, 5, 4, 4, 3, 2 },
+   { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 4, 4, 4, 3 },
+   { 14, 13, 13, 12, 11, 11, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4 }
+};
+
+static const u8 
rc_range_minqp420_10bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_10BPC_MAX_NUM_BPP] = 
{
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0 },
+   { 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0 },
+   { 7, 7, 7, 7, 7, 6, 5, 5, 5, 5, 5, 4, 3, 3, 2, 2, 1, 1, 1, 1, 1, 0, 0 },
+   { 7, 7, 7, 7, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 3, 2, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 6, 5, 4, 4, 4, 3, 2, 2, 2, 1, 1, 1, 0 },
+   { 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 2, 1, 1 },
+   { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 5, 5, 4, 4, 3,

[Intel-gfx] [PATCH v8 3/6] drm/i915: Adding the new registers for DSC

2023-01-17 Thread Suraj Kandpal
Adding new DSC register which are introducted MTL onwards

Signed-off-by: Suraj Kandpal 
Reviewed-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/i915_reg.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8b2cf980f323..69a645ce0fe8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7766,6 +7766,8 @@ enum skl_power_gate {
 #define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe) _MMIO_PIPE((pipe) - PIPE_B, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
+#define  DSC_NATIVE_422_ENABLE BIT(23)
+#define  DSC_NATIVE_420_ENABLE BIT(22)
 #define  DSC_ALT_ICH_SEL   (1 << 20)
 #define  DSC_VBR_ENABLE(1 << 19)
 #define  DSC_422_ENABLE(1 << 18)
@@ -8010,6 +8012,32 @@ enum skl_power_gate {
 #define  DSC_SLICE_PER_LINE(slice_per_line)((slice_per_line) << 16)
 #define  DSC_SLICE_CHUNK_SIZE(slice_chunk_size)
((slice_chunk_size) << 0)
 
+/* MTL Display Stream Compression registers */
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB  0x782B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB  0x783B4
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC  0x784B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC  0x785B4
+#define MTL_DSC0_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PB, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PB, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PC)
+#define DSC_SL_BPG_OFFSET(offset)  ((offset) << 27)
+
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB  0x782B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB  0x783B8
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC  0x784B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC  0x785B8
+#define MTL_DSC0_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PB, \
+  
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) - 
PIPE_B, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PB, \
+  
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PC)
+#define DSC_NSL_BPG_OFFSET(offset) ((offset) << 16)
+#define DSC_SL_OFFSET_ADJ(offset)  ((offset) << 0)
+
 /* Icelake Rate Control Buffer Threshold Registers */
 #define DSCA_RC_BUF_THRESH_0   _MMIO(0x6B230)
 #define DSCA_RC_BUF_THRESH_0_UDW   _MMIO(0x6B230 + 4)
-- 
2.25.1



[Intel-gfx] [PATCH v8 2/6] drm/i915/dp: Check if DSC supports the given output_format

2023-01-17 Thread Suraj Kandpal
From: Ankit Nautiyal 

Go with DSC only if the given output_format is supported.

v2: Use drm helper to get DSC format support for sink.

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 30 +
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 30c55f980014..6e531872ff38 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1483,6 +1483,31 @@ static int intel_dp_dsc_compute_params(struct 
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
 }
 
+static bool intel_dp_dsc_supports_format(struct intel_dp *intel_dp,
+enum intel_output_format output_format)
+{
+   u8 sink_dsc_format;
+
+   switch (output_format) {
+   case INTEL_OUTPUT_FORMAT_RGB:
+   sink_dsc_format = DP_DSC_RGB;
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   sink_dsc_format = DP_DSC_YCbCr444;
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   if (min(intel_dp_source_dsc_version_minor(intel_dp),
+   intel_dp_sink_dsc_version_minor(intel_dp)) < 2)
+   return false;
+   sink_dsc_format = DP_DSC_YCbCr420_Native;
+   break;
+   default:
+   return false;
+   }
+
+   return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd, 
sink_dsc_format);
+}
+
 int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
@@ -1503,11 +1528,16 @@ int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
 
+   if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
+   return -EINVAL;
+
if (compute_pipe_bpp)
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
else
pipe_bpp = pipe_config->pipe_bpp;
 
+   pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
+
if (intel_dp->force_dsc_bpc) {
pipe_bpp = intel_dp->force_dsc_bpc * 3;
drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d", 
pipe_bpp);
-- 
2.25.1



[Intel-gfx] [PATCH v8 1/6] drm/dp_helper: Add helper to check if the sink supports given format with DSC

2023-01-17 Thread Suraj Kandpal
From: Ankit Nautiyal 

Add helper function to check if the DP sink supports DSC with the given
output format.

Signed-off-by: Ankit Nautiyal 
---
 include/drm/display/drm_dp_helper.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2c..d529d0254b68 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -194,6 +194,13 @@ drm_dp_dsc_sink_max_slice_width(const u8 
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
DP_DSC_SLICE_WIDTH_MULTIPLIER;
 }
 
+/* Check if sink supports DSC with given output format */
+static inline bool
+drm_dp_dsc_sink_supports_format(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE], 
u8 output_format)
+{
+   return dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] & 
output_format;
+}
+
 /* Forward Error Correction Support on DP 1.4 */
 static inline bool
 drm_dp_sink_supports_fec(const u8 fec_capable)
-- 
2.25.1



[Intel-gfx] [PATCH v8 0/6] Enable YCbCr420 for VDSC

2023-01-17 Thread Suraj Kandpal
This patch series aims to enable the YCbCr420 format
for DSC. Changes are mostly compute params related for
hdmi,dp and dsi along with the addition of new rc_tables
for native_420 and corresponding changes to macros used to
fetch them.

---v2
-add fields missed for vdsc_cfg [Vandita]
-add corresponding registers and writing to the [Vandita]

---v3
-add 11 bit left shift missed in nsl_bpg_offset calculation

---v4
-add display version check before writing in new pps register

---v5
-add helper to check if sink supports given format with DSC
-add debugfs entry to enforce DSC with YCbCr420 format only

--v6
-add patch to check dsc slice design requirement [Vandita]

--v7
-fix function name to intel_slice_dimensions_valid [Jani]
-remove full bspec link just add the ref number [Jani]
-remove patches for debug fs will float them as a seprate series
-Add more description for YUV420 Enablement [Vandita]

--v8
-fix slice width and height 2's multiple check
-fix minimum pixel requirement in slice check

Ankit Nautiyal (2):
  drm/dp_helper: Add helper to check if the sink supports given format
with DSC
  drm/i915/dp: Check if DSC supports the given output_format

Suraj Kandpal (4):
  drm/i915: Adding the new registers for DSC
  drm/i915: Enable YCbCr420 for VDSC
  drm/i915: Fill in native_420 field
  drm/i915/vdsc: Check slice design requirement

 drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
 drivers/gpu/drm/i915/display/intel_dp.c   |  33 +++-
 .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
 .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c | 106 +-
 drivers/gpu/drm/i915/i915_reg.h   |  28 +++
 include/drm/display/drm_dp_helper.h   |   7 +
 7 files changed, 345 insertions(+), 22 deletions(-)

-- 
2.25.1



[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: GMCH refactoring (rev2)

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: GMCH refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/112929/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12592_full -> Patchwork_112929v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/index.html

Participating hosts (13 -> 11)
--

  Additional (1): shard-rkl0 
  Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 

Known issues


  Here are the changes found in Patchwork_112929v2_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#118])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-glk3/igt@gem_exec_whis...@basic-queues-priority-all.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2346])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-glk5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][7] ([fdo#109271])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-glk2/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html

  * igt@kms_flip@2x-flip-vs-expired-vblank@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#79])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html

  
 Possible fixes 

  * igt@fbdev@unaligned-write:
- {shard-rkl}:[SKIP][10] ([i915#2582]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-5/igt@fb...@unaligned-write.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-rkl-6/igt@fb...@unaligned-write.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][12] ([i915#6268]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-rkl-5/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][14] ([i915#7052]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-4/igt@gem_...@suspend.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-rkl-1/igt@gem_...@suspend.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-rkl}:[FAIL][16] ([i915#2842]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-rkl-5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][18] ([i915#3281]) -> [PASS][19] +9 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-1/igt@gem_exec_re...@basic-wc-read-noreloc.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html

  * igt@gem_partial_pwrite_pread@writes-after-reads:
- {shard-rkl}:[SKIP][20] ([i915#3282]) -> [PASS][21] +3 similar 
issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-3/igt@gem_partial_pwrite_pr...@writes-after-reads.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-rkl-5/igt@gem_partial_pwrite_pr...@writes-after-reads.html

  * igt@gen9_exec_parse@valid-registers:
- {shard-rkl}:[SKIP][22] ([i915#2527]) -> [PASS][23] +1 similar 
issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-1/igt@gen9_exec_pa...@valid-registers.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/shard-rkl

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: remove a couple of superfluous i915_drm.h includes

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: remove a couple of superfluous i915_drm.h includes
URL   : https://patchwork.freedesktop.org/series/112931/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12592_full -> Patchwork_112931v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/index.html

Participating hosts (13 -> 11)
--

  Additional (1): shard-rkl0 
  Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 

Known issues


  Here are the changes found in Patchwork_112931v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk:  [PASS][1] -> [FAIL][2] ([i915#2842])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-glk:  [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk2/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-glk6/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2346])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-glk2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html

  * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][7] ([fdo#109271])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-glk5/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html

  * igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#79])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html

  
 Possible fixes 

  * igt@api_intel_bb@object-reloc-keep-cache:
- {shard-rkl}:[SKIP][10] ([i915#3281]) -> [PASS][11] +2 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-6/igt@api_intel...@object-reloc-keep-cache.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-rkl-5/igt@api_intel...@object-reloc-keep-cache.html

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][12] ([i915#7742]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@drm_read@short-buffer-block:
- {shard-rkl}:[SKIP][14] ([i915#4098]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-5/igt@drm_r...@short-buffer-block.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-rkl-6/igt@drm_r...@short-buffer-block.html

  * igt@fbdev@eof:
- {shard-rkl}:[SKIP][16] ([i915#2582]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-3/igt@fb...@eof.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-rkl-6/igt@fb...@eof.html

  * igt@fbdev@info:
- {shard-tglu}:   [SKIP][18] ([i915#2582]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-tglu-6/igt@fb...@info.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-tglu-1/igt@fb...@info.html

  * igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][20] ([i915#7052]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-4/igt@gem_...@suspend.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-rkl-1/igt@gem_...@suspend.html

  * igt@gem_pwrite@basic-self:
- {shard-rkl}:[SKIP][22] ([i915#3282]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/shard-rkl-6/igt@gem_pwr...@basic-self.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/shard-rkl-5/igt@gem_pwr...@basic-self.html

  * igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- {shard-dg1}:[FAIL][24] ([i915#3591]) -> [PASS][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_125

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes

2023-01-17 Thread Deepak R Varma
On Tue, Jan 17, 2023 at 02:29:37PM -0500, Rodrigo Vivi wrote:
> On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> > On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> > > On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > > function adds the overhead of introducing a proxy file operation
> > > > functions to wrap the original read/write inside file removal protection
> > > > functions. This adds significant overhead in terms of introducing and
> > > > managing the proxy factory file operations structure and function
> > > > wrapping at runtime.
> > > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > > > with debugfs_create_file_unsafe() is suggested to be used instead.  The
> > > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > > debugfs_file_put() wrappers to protect the original read and write
> > > > function calls for the debug attributes. There is no need for any
> > > > runtime proxy file operations to be managed by the debugfs core.
> > > > Following coccicheck make command helped identify this change:
> > > > 
> > > > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch 
> > > > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > > 
> > > > Signed-off-by: Deepak R Varma 
> > > 
> > > I believe these 2 gvt cases could be done in one patch.
> > > But anyways,
> > > 
> > > Reviewed-by: Rodrigo Vivi 
> > > 
> > > for both patches... and will leave these 2 patches for gvt folks
> > > to apply. Unless they ack and I apply in the drm-intel along with the 
> > > other ones.
> > >
> > 
> > yeah, they're fine with me, feel free to apply them directly.
> > 
> > Acked-by: Zhenyu Wang 
> 
> Unfortunately I got some conflicts when trying to apply on drm-intel-next.
> 
> We probably need a new version, and probably through gvt branches it
> will be easier to handle conflicts if they appear.

Hello Rodrigo,
Sure. I will send in a new version. I am current using linux-next git repo as my
remote origin [tag 20230113]. Are there any specific instruction/location from
where I should access the gvt branch?

Thank you.

> 
> > 
> > thanks!
> > 
> > > > ---
> > > >  drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c 
> > > > b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > index 03f081c3d9a4..baccbf1761b7 100644
> > > > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> > > > return 0;
> > > >  }
> > > >  
> > > > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, 
> > > > "0x%llx\n");
> > > > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, 
> > > > "0x%llx\n");
> > > >  
> > > >  /**
> > > >   * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> > > > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu 
> > > > *vgpu)
> > > > &vgpu_mmio_diff_fops);
> > > > debugfs_create_file_unsafe("scan_nonprivbb", 0644, 
> > > > vgpu->debugfs, vgpu,
> > > >&vgpu_scan_nonprivbb_fops);
> > > > -   debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > > > -   &vgpu_status_fops);
> > > > +   debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > > > +  &vgpu_status_fops);
> > > >  }
> > > >  
> > > >  /**
> > > > -- 
> > > > 2.34.1
> > > > 
> > > > 
> > > > 
> 
> 




Re: [Intel-gfx] [PATCH] drm/i915/display: Convert i9xx_pipe_crc_auto_source to void

2023-01-17 Thread Deepak R Varma
On Tue, Jan 17, 2023 at 02:21:59PM -0500, Rodrigo Vivi wrote:
> On Sat, Jan 14, 2023 at 07:33:53PM +0530, Deepak R Varma wrote:
> > Convert function i9xx_pipe_crc_auto_source() to return void instead
> > of int since the current implementation always returns 0 to the caller.
> > Issue identified using returnvar Coccinelle semantic patch.
> 
> could you please share the coccinelle commands and files you used here?

Hello Rodrigo,
I used following command to identify this change opportunity:

make coccicheck COCCI=scripts/coccinelle/misc/returnvar.cocci M=drivers/gpu/drm/

Let me know if you would like me to include the same in the commit message.

> 
> > 
> > Signed-off-by: Deepak R Varma 
> > ---
> > Please note: The change is compile tested only.
> 
> np, our CI liked it.
> 
> I liked the clean up as well:
> Reviewed-by: Rodrigo Vivi 

Thank you for your review and the feedback.

Regards,
./drv

> 
> > 
> > 
> >  drivers/gpu/drm/i915/display/intel_pipe_crc.c | 23 ++-
> >  1 file changed, 7 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_pipe_crc.c 
> > b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> > index e9774670e3f6..8d3ea8d7b737 100644
> > --- a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> > @@ -72,14 +72,13 @@ static int i8xx_pipe_crc_ctl_reg(enum 
> > intel_pipe_crc_source *source,
> > return 0;
> >  }
> >  
> > -static int i9xx_pipe_crc_auto_source(struct drm_i915_private *dev_priv,
> > -enum pipe pipe,
> > -enum intel_pipe_crc_source *source)
> > +static void i9xx_pipe_crc_auto_source(struct drm_i915_private *dev_priv,
> > + enum pipe pipe,
> > + enum intel_pipe_crc_source *source)
> >  {
> > struct intel_encoder *encoder;
> > struct intel_crtc *crtc;
> > struct intel_digital_port *dig_port;
> > -   int ret = 0;
> >  
> > *source = INTEL_PIPE_CRC_SOURCE_PIPE;
> >  
> > @@ -121,8 +120,6 @@ static int i9xx_pipe_crc_auto_source(struct 
> > drm_i915_private *dev_priv,
> > }
> > }
> > drm_modeset_unlock_all(&dev_priv->drm);
> > -
> > -   return ret;
> >  }
> >  
> >  static int vlv_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
> > @@ -132,11 +129,8 @@ static int vlv_pipe_crc_ctl_reg(struct 
> > drm_i915_private *dev_priv,
> >  {
> > bool need_stable_symbols = false;
> >  
> > -   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > -   int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> > -   if (ret)
> > -   return ret;
> > -   }
> > +   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
> > +   i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> >  
> > switch (*source) {
> > case INTEL_PIPE_CRC_SOURCE_PIPE:
> > @@ -200,11 +194,8 @@ static int i9xx_pipe_crc_ctl_reg(struct 
> > drm_i915_private *dev_priv,
> >  enum intel_pipe_crc_source *source,
> >  u32 *val)
> >  {
> > -   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > -   int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> > -   if (ret)
> > -   return ret;
> > -   }
> > +   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
> > +   i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> >  
> > switch (*source) {
> > case INTEL_PIPE_CRC_SOURCE_PIPE:
> > -- 
> > 2.34.1
> > 
> > 
> > 




Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

2023-01-17 Thread Matthew Brost
On Thu, Jan 12, 2023 at 04:39:32PM -0800, John Harrison wrote:
> On 1/11/2023 14:56, Jason Ekstrand wrote:
> > On Wed, Jan 11, 2023 at 4:32 PM Matthew Brost 
> > wrote:
> > 
> > On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> > > On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> > > tvrtko.ursu...@linux.intel.com> wrote:
> > >
> > > >
> > [snip]
> > > >
> > > > Typically is the key here. But I am not sure it is good
> > enough. Consider
> > > > this example - Intel Flex 170:
> > > >
> > > >   * Delivers up to 36 streams 1080p60 transcode throughput per
> > card.
> > > >   * When scaled to 10 cards in a 4U server configuration, it
> > can support
> > > > up to 360 streams of HEVC/HEVC 1080p60 transcode throughput.
> > > >
> > >
> > > I had a feeling it was going to be media 😅
> > >
> > 
> > Yea wondering the media UMD can be rewritten to use less
> > xe_engines, it
> > is massive rewrite for VM bind + no implicit dependencies so let's
> > just
> > pile on some more work?
> > 
> > 
> > It could probably use fewer than it does today.  It currently creates
> > and throws away contexts like crazy, or did last I looked at it. 
> > However, the nature of media encode is that it often spreads across two
> > or three different types of engines.  There's not much you can do to
> > change that.
> And as per Tvrtko's example, you get media servers that transcode huge
> numbers of tiny streams in parallel. Almost no work per frame but 100s of
> independent streams being run concurrently. That means many 100s of contexts
> all trying to run at 30fps. I recall a specific bug about thundering herds -
> hundreds (thousands?) of waiting threads all being woken up at once because
> some request had completed.
> 
> > >
> > > > One transcode stream from my experience typically is 3-4 GPU
> > contexts
> > > > (buffer travels from vcs -> rcs -> vcs, maybe vecs) used from
> > a single
> > > > CPU thread. 4 contexts * 36 streams = 144 active contexts.
> > Multiply by
> > > > 60fps = 8640 jobs submitted and completed per second.
> > > >
> > > > 144 active contexts in the proposed scheme means possibly
> > means 144
> > > > kernel worker threads spawned (driven by 36 transcode CPU
> > threads). (I
> > > > don't think the pools would scale down given all are
> > constantly pinged
> > > > at 60fps.)
> > > >
> > > > And then each of 144 threads goes to grab the single GuC CT
> > mutex. First
> > > > threads are being made schedulable, then put to sleep as mutex
> > > > contention is hit, then woken again as mutexes are getting
> > released,
> > > > rinse, repeat.
> > > >
> > >
> > > Why is every submission grabbing the GuC CT mutex? I've not read
> > the GuC
> > > back-end yet but I was under the impression that most run_job()
> > would be
> > > just shoving another packet into a ring buffer.  If we have to
> > send the GuC
> > > a message on the control ring every single time we submit a job,
> > that's
> > > pretty horrible.
> > >
> > 
> > Run job writes the ring buffer and moves the tail as the first
> > step (no
> > lock required). Next it needs to tell the GuC the xe_engine LRC
> > tail has
> > moved, this is done from a single Host to GuC channel which is
> > circular
> > buffer, the writing of the channel protected by the mutex. There are
> > little more nuances too but in practice there is always space in the
> > channel so the time mutex needs to held is really, really small
> > (check cached credits, write 3 dwords in payload, write 1 dword to
> > move
> > tail). I also believe mutexes in Linux are hybrid where they spin
> > for a
> > little bit before sleeping and certainly if there is space in the
> > channel we shouldn't sleep mutex contention.
> > 
> > 
> > Ok, that makes sense.  It's maybe a bit clunky and it'd be nice if we
> > had some way to batch things up a bit so we only have to poke the GuC
> > channel once for every batch of things rather than once per job.  That's
> > maybe something we can look into as a future improvement; not
> > fundamental.
> > 
> > Generally, though, it sounds like contention could be a real problem if
> > we end up ping-ponging that lock between cores.  It's going to depend on
> > how much work it takes to get the next ready thing vs. the cost of that
> > atomic.  But, also, anything we do is going to potentially run into
> > contention problems.  *shrug*  If we were going to go for
> > one-per-HW-engine, we may as well go one-per-device and then we wouldn't
> > need the lock.  Off the top of my head, that doesn't sound great either
> > but IDK.
> > 
> > As far as this being horrible, well didn't design the GuC and this how
> > it is implemented for KMD based subm

[Intel-gfx] linux-next: duplicate patch in the drm-intel tree

2023-01-17 Thread Stephen Rothwell
Hi all,

The following commit is also in the drm-intel-fixes tree as a different
commit (but the same patch):

  0fe76b198d48 ("drm/i915/display: Check source height is > 0")

this is commit

  8565c502e7c1 ("drm/i915/display: Check source height is > 0")

in the drm-intel-fixes tree.

-- 
Cheers,
Stephen Rothwell


pgpTKePF2RJ4i.pgp
Description: OpenPGP digital signature


[Intel-gfx] ✗ Fi.CI.BAT: failure for Allow error capture without a request / on reset failure (rev3)

2023-01-17 Thread Patchwork
== Series Details ==

Series: Allow error capture without a request / on reset failure (rev3)
URL   : https://patchwork.freedesktop.org/series/111454/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12594 -> Patchwork_111454v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_111454v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_111454v3, 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_111454v3/index.html

Participating hosts (42 -> 44)
--

  Additional (3): fi-kbl-soraka bat-rpls-2 fi-skl-6700k2 
  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_111454v3:

### IGT changes ###

 Possible regressions 

  * igt@debugfs_test@read_all_entries:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
- fi-skl-6700k2:  NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-skl-6700k2/igt@debugfs_test@read_all_entries.html
- fi-cfl-8109u:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
- fi-kbl-7567u:   [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html
- fi-kbl-8809g:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html
- fi-ivb-3770:[PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-ivb-3770/igt@debugfs_test@read_all_entries.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-ivb-3770/igt@debugfs_test@read_all_entries.html
- fi-elk-e7500:   [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-elk-e7500/igt@debugfs_test@read_all_entries.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-elk-e7500/igt@debugfs_test@read_all_entries.html
- fi-ctg-p8600:   [PASS][13] -> [INCOMPLETE][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-ctg-p8600/igt@debugfs_test@read_all_entries.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-ctg-p8600/igt@debugfs_test@read_all_entries.html
- fi-blb-e6850:   [PASS][15] -> [INCOMPLETE][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-blb-e6850/igt@debugfs_test@read_all_entries.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-blb-e6850/igt@debugfs_test@read_all_entries.html
- fi-bsw-n3050:   [PASS][17] -> [INCOMPLETE][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-bsw-n3050/igt@debugfs_test@read_all_entries.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-bsw-n3050/igt@debugfs_test@read_all_entries.html
- fi-cfl-guc: [PASS][19] -> [INCOMPLETE][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-cfl-guc/igt@debugfs_test@read_all_entries.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-cfl-guc/igt@debugfs_test@read_all_entries.html
- fi-skl-6600u:   [PASS][21] -> [INCOMPLETE][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-skl-6600u/igt@debugfs_test@read_all_entries.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-skl-6600u/igt@debugfs_test@read_all_entries.html
- fi-pnv-d510:[PASS][23] -> [INCOMPLETE][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
- fi-glk-j4005:   [PASS][25] -> [INCOMPLETE][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-glk-j4005/igt@debugfs_test@read_all_entries.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v3/fi-glk-j4005/igt@debugfs_test@read_all_entries.html
- fi-

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow error capture without a request / on reset failure (rev3)

2023-01-17 Thread Patchwork
== Series Details ==

Series: Allow error capture without a request / on reset failure (rev3)
URL   : https://patchwork.freedesktop.org/series/111454/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy 
expression type 31
+./drivers/gpu/drm/i915/intel_uncore.h:346:1: war

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Allow error capture without a request / on reset failure (rev3)

2023-01-17 Thread Patchwork
== Series Details ==

Series: Allow error capture without a request / on reset failure (rev3)
URL   : https://patchwork.freedesktop.org/series/111454/
State : warning

== Summary ==

Error: dim checkpatch failed
79d89c5b0cf9 drm/i915: Fix request locking during error capture & debugfs dump
-:26: WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12 chars 
of sha1> ("")' - ie: 'Fixes: 98df76aeb29b ("drm/i915/guc: Add a 
debug print on GuC triggered reset")'
#26: 
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset

total: 0 errors, 1 warnings, 0 checks, 83 lines checked
6ad402b58742 drm/i915: Allow error capture without a request
f5f448ea38a4 drm/i915: Allow error capture of a pending request
43da516a0b97 drm/i915/guc: Look for a guilty context when an engine reset fails
98df76aeb29b drm/i915/guc: Add a debug print on GuC triggered reset




Re: [Intel-gfx] [PATCH 1/1] drm/i915: re-disable RC6p on Sandy Bridge

2023-01-17 Thread Ville Syrjälä
On Wed, Dec 21, 2022 at 09:09:17AM -0500, Rodrigo Vivi wrote:
> On Tue, Dec 20, 2022 at 12:32:05PM +0200, Ville Syrjälä wrote:
> > On Mon, Dec 19, 2022 at 06:29:27PM +0100, Sasa Dragic wrote:
> > > RC6p on Sandy Bridge got re-enabled over time, causing visual glitches
> > > and GPU hangs.
> > > 
> > > Disabled originally in commit 1c8ecf80fdee ("drm/i915: do not enable
> > > RC6p on Sandy Bridge").
> > 
> > re cover letter:
> > > It was originally disabled in commit 1c8ecf80fdee ("drm/i915: do not
> > > enable RC6p on Sandy Bridge"), and subsequently re-enabled by
> > > 13c5a577b342 ("drm/i915/gt: Select the deepest available parking mode
> > > for rc6"), which seems to focus only on Ivy Bridge.
> > 
> > That only kicks in while parked (ie. fully idle from
> > software POV). I think the real bad commit is
> > fb6db0f5bf1d ("drm/i915: Remove unsafe i915.enable_rc6")
> > which seems to affects which rc6 level is selected while
> > unparked.
> > 
> > We should mention both of those commits here:
> > Fixes: fb6db0f5bf1d ("drm/i915: Remove unsafe i915.enable_rc6")
> > Fixes: 13c5a577b342 ("drm/i915/gt: Select the deepest available parking 
> > mode for rc6")
> > 
> > Also we want
> > Cc: sta...@vger.kernel.org
> > 
> > We can add those while pushing, so no need to resend for that.
> 
> agreed.
> 
> Reviewed-by: Rodrigo Vivi 

Pushed to drm-intel-gt-next. Thanks for the patch and review.

> 
> > 
> > > 
> > > Signed-off-by: Sasa Dragic 
> > > ---
> > >  drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index 668e9da52584..69377564028a 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -423,7 +423,8 @@ static const struct intel_device_info ilk_m_info = {
> > >   .has_coherent_ggtt = true, \
> > >   .has_llc = 1, \
> > >   .has_rc6 = 1, \
> > > - .has_rc6p = 1, \
> > > + /* snb does support rc6p, but enabling it causes various issues */ \
> > > + .has_rc6p = 0, \
> > 
> > The one downside of doing it this way is that we also lose
> > the debugfs/sysfs files so we can't monitor rc6+/++
> > residency anymore to make sure they are not entered.
> > 
> > I think ideally we'd split this into two parts: which rc6
> > states the hw actually has vs. which rc6 states we actually
> > want to use. But at least for the time being I think this
> > simple should be sufficient, and should be easy to backport
> > to stable releases.
> > 
> > >   .has_rps = true, \
> > >   .dma_mask_size = 40, \
> > >   .__runtime.ppgtt_type = INTEL_PPGTT_ALIASING, \
> > > -- 
> > > 2.37.2
> > 
> > -- 
> > Ville Syrjälä
> > Intel

-- 
Ville Syrjälä
Intel


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move/adjust register definitions related to Wa_22011450934

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Move/adjust register definitions related to Wa_22011450934
URL   : https://patchwork.freedesktop.org/series/112966/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12594 -> Patchwork_112966v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/index.html

Participating hosts (42 -> 43)
--

  Additional (2): bat-rpls-2 fi-skl-6700k2 
  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_112966v1:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@requests:
- {bat-adln-1}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/bat-adln-1/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/bat-adln-1/igt@i915_selftest@l...@requests.html

  
Known issues


  Here are the changes found in Patchwork_112966v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6700k2:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-skl-6700k2:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/fi-skl-6700k2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@prime_vgem@basic-userptr:
- fi-skl-6700k2:  NOTRUN -> [SKIP][5] ([fdo#109271]) +14 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/fi-skl-6700k2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][6] ([i915#7229]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}:   [DMESG-WARN][8] ([i915#2867]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-lvds-1:
- fi-ctg-p8600:   [FAIL][10] ([fdo#103375]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112966v1/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828


Build changes
-

  * Lin

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Unwind hugepages to drop wakeref on error (rev3)

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Unwind hugepages to drop wakeref on error (rev3)
URL   : https://patchwork.freedesktop.org/series/112801/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12590_full -> Patchwork_112801v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/index.html

Participating hosts (13 -> 11)
--

  Additional (1): shard-rkl0 
  Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_112801v3_full:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_eio@unwedge-stress:
- {shard-dg1}:NOTRUN -> [DMESG-FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-dg1-14/igt@gem_...@unwedge-stress.html

  * igt@kms_big_fb@y-tiled-32bpp-rotate-90:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][2] +2 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-dg1-14/igt@kms_big...@y-tiled-32bpp-rotate-90.html

  * igt@perf_pmu@module-unload:
- {shard-dg1}:[PASS][3] -> [DMESG-WARN][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-dg1-19/igt@perf_...@module-unload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-dg1-14/igt@perf_...@module-unload.html

  
New tests
-

  New tests have been introduced between CI_DRM_12590_full and 
Patchwork_112801v3_full:

### New IGT tests (1) ###

  * igt@gem_exec_fair@basic-pace@vcs1:
- Statuses : 1 fail(s)
- Exec time: [0.0] s

  

Known issues


  Here are the changes found in Patchwork_112801v3_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-glk5/igt@gem_exec_fair@basic-n...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vcs1 (NEW):
- {shard-tglu-9}: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-tglu-9/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html

  * igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_cursor_crc@cursor-random-max-size:
- shard-glk:  NOTRUN -> [SKIP][11] ([fdo#109271]) +48 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@kms_cursor_...@cursor-random-max-size.html

  * igt@kms_dsc@dsc-with-bpc-formats:
- shard-glk:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#7205])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@kms_...@dsc-with-bpc-formats.html

  * igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-b-hdmi-a-2:
- shard-glk:  NOTRUN -> [FAIL][13] ([i915#4573]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@kms_plane_alpha_blend@alpha-transparent...@pipe-b-hdmi-a-2.html

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-glk:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@kms_psr2...@overlay-primary-update-sf-dmg-area.html

  * igt@kms_writeback@writeback-fb-id:
- shard-glk:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2437])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/shard-glk8/igt@kms_writeb...@writeback-fb-id.html

  
 Possible fixes 

  * igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][16] ([i915#7742]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-rkl-2/igt@drm_fdinfo@i...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/drm_vma_manager: Add drm_vma_node_allow_once()

2023-01-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/drm_vma_manager: Add 
drm_vma_node_allow_once()
URL   : https://patchwork.freedesktop.org/series/112952/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12594 -> Patchwork_112952v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/index.html

Participating hosts (42 -> 42)
--

  Additional (2): bat-rpls-2 fi-skl-6700k2 
  Missing(2): fi-bsw-kefka fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_112952v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6700k2:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-skl-6700k2:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/fi-skl-6700k2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@prime_vgem@basic-userptr:
- fi-skl-6700k2:  NOTRUN -> [SKIP][3] ([fdo#109271]) +14 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/fi-skl-6700k2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][4] ([i915#7229]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}:   [DMESG-WARN][6] ([i915#2867]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050:   [FAIL][8] ([i915#6298]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-lvds-1:
- fi-ctg-p8600:   [FAIL][10] ([fdo#103375]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112952v1/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828


Build changes
-

  * Linux: CI_DRM_12594 -> Patchwork_112952v1

  CI-20190529: 20190529
  CI_

[Intel-gfx] [PATCH v2 3/5] drm/i915: Allow error capture of a pending request

2023-01-17 Thread John . C . Harrison
From: John Harrison 

A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that this might be better than nothing.

v2: Reword 'not started' warning message (Tvrtko)

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 461489d599a7e..1d33822a8ca23 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1629,12 +1629,9 @@ capture_engine(struct intel_engine_cs *engine,
intel_engine_clear_hung_context(engine);
/* This will reference count the request (if found) */
rq = intel_context_find_active_request(ce);
-   if (rq && !i915_request_started(rq)) {
-   drm_info(&engine->gt->i915->drm, "Got hung context on 
%s with no active request!\n",
-engine->name);
-   i915_request_put(rq);
-   rq = NULL;
-   }
+   if (rq && !i915_request_started(rq))
+   drm_info(&engine->gt->i915->drm, "Got hung context on 
%s with active request %lld:%lld [0x%04X] not yet started\n",
+engine->name, rq->fence.context, 
rq->fence.seqno, ce->guc_id.id);
} else {
/*
 * Getting here with GuC enabled means it is a forced error 
capture
-- 
2.39.0



[Intel-gfx] [PATCH v2 5/5] drm/i915/guc: Add a debug print on GuC triggered reset

2023-01-17 Thread John . C . Harrison
From: John Harrison 

For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.

Signed-off-by: John Harrison 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 
 1 file changed, 4 insertions(+)

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 9bc80b807dbcc..6029dbab5feeb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4665,6 +4665,10 @@ static void guc_handle_context_reset(struct intel_guc 
*guc,
 {
trace_intel_context_reset(ce);
 
+   drm_dbg(&guc_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting = 
%d, banned = %d\n",
+   ce->guc_id.id, test_bit(CONTEXT_EXITING, &ce->flags),
+   test_bit(CONTEXT_BANNED, &ce->flags));
+
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
-- 
2.39.0



[Intel-gfx] [PATCH v2 2/5] drm/i915: Allow error capture without a request

2023-01-17 Thread John . C . Harrison
From: John Harrison 

There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.

In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.

So update the error capture code to always record engine information
if an engine is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.

v2: Remove a duplicate 'if' statement (Umesh) and fix a put of a null
pointer.
v3: Tidy up request locking code flow (Tvrtko)

Signed-off-by: John Harrison 
Reviewed-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 69 ++-
 1 file changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 4107a0dfcca7d..461489d599a7e 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct 
intel_engine_coredump *ee)
 }
 
 static bool record_context(struct i915_gem_context_coredump *e,
-  const struct i915_request *rq)
+  struct intel_context *ce)
 {
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
 
rcu_read_lock();
-   ctx = rcu_dereference(rq->context->gem_context);
+   ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct 
i915_gem_context_coredump *e,
e->guilty = atomic_read(&ctx->guilty_count);
e->active = atomic_read(&ctx->active_count);
 
-   e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
-   e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+   e->total_runtime = intel_context_get_total_runtime_ns(ce);
+   e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
 
simulated = i915_gem_context_no_error_capture(ctx);
 
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs 
*engine, gfp_t gfp, u32 dump_
return ee;
 }
 
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+   struct intel_context *ce,
+   gfp_t gfp)
+{
+   struct intel_engine_capture_vma *vma = NULL;
+
+   ee->simulated |= record_context(&ee->context, ce);
+   if (ee->simulated)
+   return NULL;
+
+   /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+   vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+   vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+   return vma;
+}
+
 struct intel_engine_capture_vma *
 intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
  struct i915_request *rq,
  gfp_t gfp)
 {
-   struct intel_engine_capture_vma *vma = NULL;
+   struct intel_engine_capture_vma *vma;
 
-   ee->simulated |= record_context(&ee->context, rq);
-   if (ee->simulated)
+   vma = engine_coredump_add_context(ee, rq->context, gfp);
+   if (!vma)
return NULL;
 
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct 
intel_engine_coredump *ee,
 */
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
-   vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
-   vma = capture_vma(vma, rq->context->state, "HW context", gfp);
 
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1609,8 +1629,12 @@ capture_engine(struct intel_engine_cs *engine,
intel_engine_clear_hung_context(engine);
/* This will reference count the request (if found) */
rq = intel_context_find_active_request(ce);
-   if (!rq || !i915_request_started(rq))
-   goto no_request_capture;
+   if (rq && !i915_request_started(rq)) {
+   drm_info(&engine->gt->i915->drm, "Got hung context on 
%s with no active request!\n",
+   

[Intel-gfx] [PATCH v2 4/5] drm/i915/guc: Look for a guilty context when an engine reset fails

2023-01-17 Thread John . C . Harrison
From: John Harrison 

Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.

v2: Change comment to be less alarming (Tvrtko)

Signed-off-by: John Harrison 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c   | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

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 3b34a82d692be..9bc80b807dbcc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4754,11 +4754,24 @@ static void reset_fail_worker_func(struct work_struct 
*w)
guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
 
-   if (likely(reset_fail_mask))
+   if (likely(reset_fail_mask)) {
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   /*
+* GuC is toast at this point - it dead loops after sending the 
failed
+* reset notification. So need to manually determine the guilty 
context.
+* Note that it should be reliable to do this here because the 
GuC is
+* toast and will not be scheduling behind the KMD's back.
+*/
+   for_each_engine_masked(engine, gt, reset_fail_mask, id)
+   intel_guc_find_hung_context(engine);
+
intel_gt_handle_error(gt, reset_fail_mask,
  I915_ERROR_CAPTURE,
- "GuC failed to reset engine mask=0x%x\n",
+ "GuC failed to reset engine mask=0x%x",
  reset_fail_mask);
+   }
 }
 
 int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
-- 
2.39.0



[Intel-gfx] [PATCH v2 1/5] drm/i915: Fix request locking during error capture & debugfs dump

2023-01-17 Thread John . C . Harrison
From: John Harrison 

When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.

The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based search relies on external
locking, so it needs an external reference count. So no change to that
code itself but the context version does change.

The only other caller is the code for dumping engine state to debugfs.
That code wasn't previously getting an explicit reference at all as it
does everything while holding the execlist specific spinlock. So that
needs updaing as well as that spinlock doesn't help when using GuC
submission. Rather than trying to conditionally get/put depending on
submission model, just change it to always do the get/put.

In addition, intel_guc_find_hung_context() was not acquiring the
correct spinlock before searching the request list. So fix that up too.

Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset
with GuC")
Fixes: 573ba126aef3 ("drm/i915/guc: Capture error state on context reset")
Cc: Matthew Brost 
Cc: John Harrison 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Cc: Andrzej Hajda 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Matt Roper 
Cc: Umesh Nerlige Ramappa 
Cc: Michael Cheng 
Cc: Lucas De Marchi 
Cc: Tejas Upadhyay 
Cc: Andy Shevchenko 
Cc: Aravind Iddamsetty 
Cc: Alan Previn 
Cc: Bruce Chang 
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/intel_context.c   |  1 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  7 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++
 drivers/gpu/drm/i915/i915_gpu_error.c |  5 ++---
 4 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index e94365b08f1ef..df64cf1954c1d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -552,6 +552,7 @@ struct i915_request 
*intel_context_find_active_request(struct intel_context *ce)
 
active = rq;
}
+   active = i915_request_get_rcu(active);
spin_unlock_irqrestore(&parent->guc_state.lock, flags);
 
return active;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 922f1bb22dc68..517d1fb7ae333 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2236,10 +2236,13 @@ static void engine_dump_active_requests(struct 
intel_engine_cs *engine, struct d
guc = intel_uc_uses_guc_submission(&engine->gt->uc);
if (guc) {
ce = intel_engine_get_hung_context(engine);
-   if (ce)
+   if (ce) {
+   /* This will reference count the request (if found) */
hung_rq = intel_context_find_active_request(ce);
+   }
} else {
hung_rq = intel_engine_execlist_find_hung_request(engine);
+   hung_rq = i915_request_get_rcu(hung_rq);
}
 
if (hung_rq)
@@ -2250,6 +2253,8 @@ static void engine_dump_active_requests(struct 
intel_engine_cs *engine, struct d
else

intel_engine_dump_active_requests(&engine->sched_engine->requests,
  hung_rq, m);
+   if (hung_rq)
+   i915_request_put(hung_rq);
 }
 
 void intel_engine_dump(struct intel_engine_cs *engine,
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 b436dd7f12e42..3b34a82d692be 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4820,6 +4820,8 @@ void intel_guc_find_hung_context(struct intel_engine_cs 
*engine)
 
xa_lock_irqsave(&guc->context_lookup, flags);
xa_for_each(&guc->context_lookup, index, ce) {
+   bool found;
+
if (!kref_get_unless_zero(&ce->ref))
continue;
 
@@ -4836,10 +4838,18 @@ void intel_guc_find_hung_context(struct intel_engine_cs 
*engine)
goto next;
}
 
+   found = false;
+   spin_lock(&ce->guc_state.lock);
list_for_each_entry(rq, &ce->guc_state.requests, sched.link) {
if (i915_test_request_state(rq) != I915_REQUEST_ACTIVE)
continue;
 
+   found = true;
+   break;
+   }
+   spin_unlock(&ce->guc_state.lock);
+
+   if (found) {
intel_engine_set_hung_context(engine, ce);
 
/* Can only cope wit

[Intel-gfx] [PATCH v2 0/5] Allow error capture without a request / on reset failure

2023-01-17 Thread John . C . Harrison
From: John Harrison 

It is technically possible to get a hung context without a valid
request. In such a situation, try to provide as much information in
the error capture as possible rather than just aborting and capturing
nothing.

Similarly, in the case of an engine reset failure the GuC is not able
to report the guilty context. So try a manual search instead of
reporting nothing.

v2: Tidy up code flow in error capture. Reword some comments/messages.
(review feedback from Tvrtko)
Also fix up request locking issues from earlier changes noticed during
code review of this change.

Signed-off-by: John Harrison 


John Harrison (5):
  drm/i915: Fix request locking during error capture & debugfs dump
  drm/i915: Allow error capture without a request
  drm/i915: Allow error capture of a pending request
  drm/i915/guc: Look for a guilty context when an engine reset fails
  drm/i915/guc: Add a debug print on GuC triggered reset

 drivers/gpu/drm/i915/gt/intel_context.c   |  1 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  7 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 -
 drivers/gpu/drm/i915/i915_gpu_error.c | 71 ---
 4 files changed, 82 insertions(+), 29 deletions(-)

-- 
2.39.0



[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftest: fix intel_selftest_modify_policy argument types

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915/selftest: fix intel_selftest_modify_policy argument types
URL   : https://patchwork.freedesktop.org/series/112938/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12594 -> Patchwork_112938v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_112938v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_112938v1, 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_112938v1/index.html

Participating hosts (42 -> 43)
--

  Additional (2): bat-rpls-2 fi-skl-6700k2 
  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_112938v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-elk-e7500:   [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-elk-e7500/igt@i915_susp...@basic-s2idle-without-i915.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-elk-e7500/igt@i915_susp...@basic-s2idle-without-i915.html

  
Known issues


  Here are the changes found in Patchwork_112938v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6700k2:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-skl-6700k2:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-skl-6700k2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-vga-1:
- fi-pnv-d510:[PASS][5] -> [FAIL][6] ([fdo#103375]) +3 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-pnv-d510/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-vga-1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-pnv-d510/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-vga-1.html

  * igt@prime_vgem@basic-userptr:
- fi-skl-6700k2:  NOTRUN -> [SKIP][7] ([fdo#109271]) +14 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-skl-6700k2/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][8] ([i915#7229]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}:   [DMESG-WARN][10] ([i915#2867]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-1}:   [DMESG-FAIL][12] ([i915#4983]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050:   [FAIL][14] ([i915#6298]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-lvds-1:
- fi-ctg-p8600:   [FAIL][16] ([fdo#103375]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12594/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112938v1/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freed

Re: [Intel-gfx] [PATCH v4] vfio: fix potential deadlock on vfio group lock

2023-01-17 Thread Alex Williamson
On Fri, 13 Jan 2023 19:03:51 -0500
Matthew Rosato  wrote:

> Currently it is possible that the final put of a KVM reference comes from
> vfio during its device close operation.  This occurs while the vfio group
> lock is held; however, if the vfio device is still in the kvm device list,
> then the following call chain could result in a deadlock:
> 
> kvm_put_kvm
>  -> kvm_destroy_vm
>   -> kvm_destroy_devices
>-> kvm_vfio_destroy
> -> kvm_vfio_file_set_kvm
>  -> vfio_file_set_kvm
>   -> group->group_lock/group_rwsem  
> 
> Avoid this scenario by having vfio core code acquire a KVM reference
> the first time a device is opened and hold that reference until right
> after the group lock is released after the last device is closed.
> 
> Fixes: 421cfe6596f6 ("vfio: remove VFIO_GROUP_NOTIFY_SET_KVM")
> Reported-by: Alex Williamson 
> Signed-off-by: Matthew Rosato 
> ---
> Changes from v3:
> * Can't check for open_count after the group lock has been dropped because
>   it would be possible for the count to change again once the group lock
>   is dropped (Jason)
>   Solve this by stashing a copy of the kvm and put_kvm while the group
>   lock is held, nullifying the device copies of these in device_close()
>   as soon as the open_count reaches 0, and then checking to see if the
>   device->kvm changed before dropping the group lock.  If it changed
>   during close, we can drop the reference using the stashed kvm and put
>   function after dropping the group lock.
> 
> Changes from v2:
> * Re-arrange vfio_kvm_set_kvm_safe error path to still trigger
>   device_open with device->kvm=NULL (Alex)
> * get device->dev_set->lock when checking device->open_count (Alex)
> * but don't hold it over the kvm_put_kvm (Jason)
> * get kvm_put symbol upfront and stash it in device until close (Jason)
> * check CONFIG_HAVE_KVM to avoid build errors on architectures without
>   KVM support
> 
> Changes from v1:
> * Re-write using symbol get logic to get kvm ref during first device
>   open, release the ref during device fd close after group lock is
>   released
> * Drop kvm get/put changes to drivers; now that vfio core holds a
>   kvm ref until sometime after the device_close op is called, it
>   should be fine for drivers to get and put their own references to it.
> ---
>  drivers/vfio/group.c | 23 +--
>  drivers/vfio/vfio.h  |  9 ++
>  drivers/vfio/vfio_main.c | 61 +---
>  include/linux/vfio.h |  2 +-
>  4 files changed, 87 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index bb24b2f0271e..b396c17d7390 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -165,9 +165,9 @@ static int vfio_device_group_open(struct vfio_device 
> *device)
>   }
>  
>   /*
> -  * Here we pass the KVM pointer with the group under the lock.  If the
> -  * device driver will use it, it must obtain a reference and release it
> -  * during close_device.
> +  * Here we pass the KVM pointer with the group under the lock.  A
> +  * reference will be obtained the first time the device is opened and
> +  * will be held until the open_count reaches 0.
>*/
>   ret = vfio_device_open(device, device->group->iommufd,
>  device->group->kvm);
> @@ -179,9 +179,26 @@ static int vfio_device_group_open(struct vfio_device 
> *device)
>  
>  void vfio_device_group_close(struct vfio_device *device)
>  {
> + void (*put_kvm)(struct kvm *kvm);
> + struct kvm *kvm;
> +
>   mutex_lock(&device->group->group_lock);
> + kvm = device->kvm;
> + put_kvm = device->put_kvm;
>   vfio_device_close(device, device->group->iommufd);
> + if (kvm == device->kvm)
> + kvm = NULL;

Hmm, so we're using whether the device->kvm pointer gets cleared in
last_close to detect whether we should put the kvm reference.  That's a
bit obscure.  Our get and put is also asymmetric.

Did we decide that we couldn't do this via a schedule_work() from the
last_close function, ie. implementing our own version of an async put?
It seems like that potentially has a cleaner implementation, symmetric
call points, handling all the storing and clearing of kvm related
pointers within the get/put wrappers, passing only a vfio_device to the
put wrapper, using the "vfio_device_" prefix for both.  Potentially
we'd just want an unconditional flush outside of lock here for
deterministic release.

What's the downside?  Thanks,

Alex

>   mutex_unlock(&device->group->group_lock);
> +
> + /*
> +  * The last kvm reference will trigger kvm_destroy_vm, which
> can in
> +  * turn re-enter vfio and attempt to acquire the group lock.
>  Therefore
> +  * we get a copy of the kvm pointer and the put function
> under the
> +  * group lock but wait to put that reference until after
> releasing the
> +  * lock.
> +  */
> + if (kvm)
> + vfio_kvm_

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/print: Add drm_dbg_ratelimited

2023-01-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/print: Add drm_dbg_ratelimited
URL   : https://patchwork.freedesktop.org/series/112925/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12590_full -> Patchwork_112925v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/index.html

Participating hosts (13 -> 10)
--

  Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 

Known issues


  Here are the changes found in Patchwork_112925v1_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][1] ([i915#2842])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html

  * igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3886]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_cursor_crc@cursor-random-max-size:
- shard-glk:  NOTRUN -> [SKIP][4] ([fdo#109271]) +48 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@kms_cursor_...@cursor-random-max-size.html

  * igt@kms_dsc@dsc-with-bpc-formats:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#7205])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@kms_...@dsc-with-bpc-formats.html

  * igt@kms_plane_alpha_blend@alpha-transparent-fb@pipe-b-hdmi-a-2:
- shard-glk:  NOTRUN -> [FAIL][6] ([i915#4573]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@kms_plane_alpha_blend@alpha-transparent...@pipe-b-hdmi-a-2.html

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-glk:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#658])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@kms_psr2...@overlay-primary-update-sf-dmg-area.html

  * igt@kms_writeback@writeback-fb-id:
- shard-glk:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2437])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk3/igt@kms_writeb...@writeback-fb-id.html

  
 Possible fixes 

  * igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][9] ([i915#7742]) -> [PASS][10] +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-rkl-3/igt@drm_fdi...@virtual-idle.html

  * igt@fbdev@pan:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12] +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-rkl-3/igt@fb...@pan.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-rkl-6/igt@fb...@pan.html

  * igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][13] ([i915#6247]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-rkl-3/igt@gem_exec_endless@dispa...@bcs0.html

  * igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][15] ([i915#2846]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-rkl-2/igt@gem_exec_f...@basic-deadline.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-rkl-3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [FAIL][17] ([i915#2842]) -> [PASS][18] +1 similar 
issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-glk6/igt@gem_exec_fair@basic-p...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-glk8/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_reloc@basic-write-read-active:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/shard-rkl-6/igt@gem_exec_re...@basic-write-read-active.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/shard-rkl-5/igt@gem_exec_re...@basic-write-read-active.html

  * igt@gem_mmap_wc@set-cache-level:
- {shard-rkl}:[SKIP][21] ([i915#1850]) -> [PASS][22]
   

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: Look for a guilty context when an engine reset fails

2023-01-17 Thread John Harrison

On 1/16/2023 04:43, Tvrtko Ursulin wrote:

On 14/01/2023 01:27, John Harrison wrote:

On 1/13/2023 01:22, Tvrtko Ursulin wrote:

On 12/01/2023 20:59, John Harrison wrote:

On 1/12/2023 02:15, Tvrtko Ursulin wrote:

On 12/01/2023 02:53, john.c.harri...@intel.com wrote:

From: John Harrison 

Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a 
situation, it

is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.

Signed-off-by: John Harrison 
---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c   | 17 
+++--

  1 file changed, 15 insertions(+), 2 deletions(-)

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 b436dd7f12e42..99d09e3394597 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4754,11 +4754,24 @@ static void reset_fail_worker_func(struct 
work_struct *w)

  guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(&guc->submission_state.lock, flags);
  -    if (likely(reset_fail_mask))
+    if (likely(reset_fail_mask)) {
+    struct intel_engine_cs *engine;
+    enum intel_engine_id id;
+
+    /*
+ * GuC is toast at this point - it dead loops after 
sending the failed
+ * reset notification. So need to manually determine the 
guilty context.
+ * Note that it should be safe/reliable to do this here 
because the GuC
+ * is toast and will not be scheduling behind the KMD's 
back.

+ */
+    for_each_engine_masked(engine, gt, reset_fail_mask, id)
+    intel_guc_find_hung_context(engine);
+
  intel_gt_handle_error(gt, reset_fail_mask,
    I915_ERROR_CAPTURE,
-  "GuC failed to reset engine mask=0x%x\n",
+  "GuC failed to reset engine mask=0x%x",
    reset_fail_mask);
+    }
  }
    int intel_guc_engine_failure_process_msg(struct intel_guc *guc,


This one I don't feel "at home" enough to r-b. Just a question - 
can we be sure at this point that GuC is 100% stuck and there 
isn't a chance it somehow comes alive and starts running in 
parallel (being driven in parallel by a different "thread" in 
i915), interfering with the assumption made in the comment?
The GuC API definition for the engine reset failure notification is 
that GuC will dead loop itself after sending - to quote "This is a 
catastrophic failure that requires a full GT reset, or FLR to 
recover.". So yes, GuC is 100% stuck and is not going to self 
recover. Guaranteed. If that changes in the future then that would 
be a backwards breaking API change and would require a 
corresponding driver update to go with supporting the new GuC 
firmware version.


There is the potential for a GT reset to maybe occur in parallel 
and resurrect the GuC that way. Not sure how that could happen 
though. The heartbeat timeout is significantly longer than the 
GuC's pre-emption timeout + engine reset timeout. That just leaves 
manual resets from the user or maybe from a selftest. If the user 
is manually poking reset debugfs files then it is already known 
that all bets are off in terms of getting an accurate error 
capture. And if a selftest is triggering GT resets in parallel with 
engine resets then either it is a broken test or it is attempting 
to test an evil corner case in which it is expected that error 
capture results will be unreliable. Having said all that, given 
that the submission_state lock is held here, such a GT reset would 
not get very far in bring the GuC back up anyway. Certainly, it 
would not be able to get as far as submitting new work and thus 
potentially changing the engine state.


So yes, if multiple impossible events occur back to back then the 
error capture may be wonky. Where wonky means a potentially 
innocent context/request gets blamed for breaking the hardware. Oh 
dear. I can live with that.


Okay, so I was triggered by the "safe/reliable" qualification from 
the comment. I agree "reliable" does not have to be and was mostly 
worried about the "safe" part.


From what you explain if short heartbeat, or manual reset 
invocation, could actually mess up any of the data structures which 
added intel_guc_find_hung_context walks and so crash the kernel.


Looking inside, there is some lock dropping going on (and 
undocumented irqsave games), and walking the list while unlocked. So 
whether or not that can go bang if a full reset happens in parallel 
and re-activates the normal driver flows.
There is no walking of unlocked lists. The xa_lock is held whenever 
it looks at the xa 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftest: fix intel_selftest_modify_policy argument types

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915/selftest: fix intel_selftest_modify_policy argument types
URL   : https://patchwork.freedesktop.org/series/112938/
State : warning

== Summary ==

Error: dim checkpatch failed
ef0c87e4b866 drm/i915/selftest: fix intel_selftest_modify_policy argument types
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#13: 
In file included from 
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:11:

total: 0 errors, 1 warnings, 0 checks, 9 lines checked




Re: [Intel-gfx] linux-next: duplicate patch in the kspp tree

2023-01-17 Thread Stephen Rothwell
Hi Karol,

On Tue, 17 Jan 2023 14:52:12 +0100 Karol Herbst  wrote:
>
> On Tue, Jan 17, 2023 at 5:02 AM Stephen Rothwell  
> wrote:
> >
> > The following commit is also in the drm-misc tree as a different commit
> > (but the same patch):
> >
> >   06b19f46455c ("drm/nouveau/fb/ga102: Replace zero-length array of 
> > trailing structs with flex-array")
> >  
> 
> which branch? Because I just fetched the remote and don't have this
> commit in my local repo

That was from
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git (branch
for-next/kspp) yesterday.  It was the top commit in that branch.  It is
still there today (I am not saying it should not be).

> > This is commit
> >
> >   54d47689c6e3 ("drm/nouveau/fb/ga102: Replace zero-length array of 
> > trailing structs with flex-array")
> >
> > in the drm-misc tree.

That was from git://anongit.freedesktop.org/drm/drm-misc (branch
for-linux-next) yesterday.  It was the top commit in that branch.  It
is still there today (again, I am not saying it should not be) but the
branch has moved on.

-- 
Cheers,
Stephen Rothwell


pgpiLPV2hi847.pgp
Description: OpenPGP digital signature


[Intel-gfx] [PATCH] drm/i915: Move/adjust register definitions related to Wa_22011450934

2023-01-17 Thread Matt Roper
The implementation of Wa_22011450934 introduced three new register
definitions in i915_reg.h that didn't get moved to the GT/engine
register headers when all the other registers moved; let's move them to
the appropriate headers and tidy up their definitions now for
consistency:

 - STATE_ACK_DEBUG is moved to the engine register header and converted
   to a parameterized definition; the workaround only needs the RCS
   instance to be programmed, but there are instances on other engines
   that could be used by other workarounds in the future.

 - The two CULLBIT registers move to the GT register header.  Since
   they belong to MMIO ranges that became MCR starting with Xe_HP,
   their definitions should be defined as MCR_REG() and use an Xe_HP
   prefix to keep the register semantics clear.

Note that the MCR definition is just for consistency and to prevent
accidental misuse if other workarounds related to these registers show
up in the future.  There's no functional change to today's driver since
the workaround that references these registers only accesses them via
MI_LRR engine instructions.  Engine-initiated register accesses do not
utilize the same same steering controls as CPU-initiated accesses; they
use a different steering control register (0x20CC) which is initialized
to a non-terminated DSS target by pre-OS firmware and never changed
thereafter (i915 does not touch it and userspace does not have
permission to change that register).

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 
 drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++---
 drivers/gpu/drm/i915/i915_reg.h | 4 
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index ee3efd06ee54..6b9d9f837669 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -81,6 +81,7 @@
 #define RING_EIR(base) _MMIO((base) + 0xb0)
 #define RING_EMR(base) _MMIO((base) + 0xb4)
 #define RING_ESR(base) _MMIO((base) + 0xb8)
+#define GEN12_STATE_ACK_DEBUG(base)_MMIO((base) + 0xbc)
 #define RING_INSTPM(base)  _MMIO((base) + 0xc0)
 #define RING_CMD_CCTL(base)_MMIO((base) + 0xc4)
 #define ACTHD(base)_MMIO((base) + 0xc8)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 4f5c06d60bcd..4a4bab261e66 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -407,6 +407,8 @@
 #define GEN9_WM_CHICKEN3   _MMIO(0x5588)
 #define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
 
+#define XEHP_CULLBIT1  MCR_REG(0x6100)
+
 #define CHICKEN_RASTER_1   MCR_REG(0x6204)
 #define   DIS_SF_ROUND_NEAREST_EVENREG_BIT(8)
 
@@ -457,6 +459,8 @@
 #define   HZ_DEPTH_TEST_LE_GE_OPT_DISABLE  REG_BIT(13)
 #define   BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE  REG_BIT(3)
 
+#define XEHP_CULLBIT2  MCR_REG(0x7030)
+
 #define GEN8_L3CNTLREG _MMIO(0x7034)
 #define   GEN8_ERRDETBCTRL (1 << 9)
 
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7771a19008c6..1dffe392b95c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1351,16 +1351,16 @@ static u32 *
 dg2_emit_rcs_hang_wabb(const struct intel_context *ce, u32 *cs)
 {
*cs++ = MI_LOAD_REGISTER_IMM(1);
-   *cs++ = i915_mmio_reg_offset(GEN12_STATE_ACK_DEBUG);
+   *cs++ = 
i915_mmio_reg_offset(GEN12_STATE_ACK_DEBUG(ce->engine->mmio_base));
*cs++ = 0x21;
 
*cs++ = MI_LOAD_REGISTER_REG;
*cs++ = i915_mmio_reg_offset(RING_NOPID(ce->engine->mmio_base));
-   *cs++ = i915_mmio_reg_offset(GEN12_CULLBIT1);
+   *cs++ = i915_mmio_reg_offset(XEHP_CULLBIT1);
 
*cs++ = MI_LOAD_REGISTER_REG;
*cs++ = i915_mmio_reg_offset(RING_NOPID(ce->engine->mmio_base));
-   *cs++ = i915_mmio_reg_offset(GEN12_CULLBIT2);
+   *cs++ = i915_mmio_reg_offset(XEHP_CULLBIT2);
 
return cs;
 }
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8b2cf980f323..d30443f06bdd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8113,10 +8113,6 @@ enum skl_power_gate {
 #define CLKGATE_DIS_MISC   _MMIO(0x46534)
 #define  CLKGATE_DIS_MISC_DMASC_GATING_DIS REG_BIT(21)
 
-#define GEN12_CULLBIT1 _MMIO(0x6100)
-#define GEN12_CULLBIT2 _MMIO(0x7030)
-#define GEN12_STATE_ACK_DEBUG  _MMIO(0x20BC)
-
 #define _MTL_CLKGATE_DIS_TRANS_A   0x604E8
 #define _

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Allow error capture without a request

2023-01-17 Thread John Harrison

On 1/16/2023 04:38, Tvrtko Ursulin wrote:

On 13/01/2023 21:29, John Harrison wrote:

On 1/13/2023 09:46, Hellstrom, Thomas wrote:

On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:

On 12/01/2023 20:40, John Harrison wrote:

On 1/12/2023 02:01, Tvrtko Ursulin wrote:

On 12/01/2023 02:53, john.c.harri...@intel.com wrote:


[snip]


+ engine->name);
+    rq = NULL;
+    }
   } else {
   /*
    * Getting here with GuC enabled means it is a forced
error
capture
@@ -1622,22 +1645,24 @@ capture_engine(struct intel_engine_cs
*engine,
  flags);
   }
   }
-    if (rq)
+    if (rq) {
   rq = i915_request_get_rcu(rq);
+    capture = intel_engine_coredump_add_request(ee, rq,
ATOMIC_MAYFAIL);
+    } else if (ce) {
+    capture = engine_coredump_add_context(ee, ce,
ATOMIC_MAYFAIL);
+    }
   -    if (!rq)
-    goto no_request_capture;
-
-    capture = intel_engine_coredump_add_request(ee, rq,
ATOMIC_MAYFAIL);
   if (!capture) {
-    i915_request_put(rq);
+    if (rq)
+    i915_request_put(rq);
   goto no_request_capture;
   }
   if (dump_flags & CORE_DUMP_FLAG_IS_GUC_CAPTURE)
intel_guc_capture_get_matching_node(engine->gt, ee,
ce);

This step requires non-NULL ce, so if you move it under the "else
if
(ce)" above then I *think* exit from the function can be
consolidated
to just:

if (capture) {
 intel_engine_coredump_add_vma(ee, capture, compress);
 if (rq)
 i915_request_put(rq);

Is there any reason the rq ref needs to be held during the add_vma
call?
Can it now just be moved earlier to be:
  if (rq) {
      rq = i915_request_get_rcu(rq);
      capture = intel_engine_coredump_add_request(ee, rq,
ATOMIC_MAYFAIL);
      i915_request_put(rq);
  }

The internals of the request object are only touched in the above
_add_request() code. The later _add_vma() call fiddles around with
vmas
that pulled from the request but the capture_vma code inside
_add_request() has already copied everything, hasn't it? Or rather,
it
has grabbed its own private vma resource locks. So there is no
requirement to keep the request itself around still?

That sounds correct. It was some time ago since I worked with this code
but when i started IIRC KASAN told me the request along with the whole
capture list could disappear under us due to a parallel capture.

So the request reference added then might cover a bit too much now that
we also hold references on vma resources, which it looks like we do in
intel_engine_coredump_add_vma().

So that means we end up with:
 rq = intel_context_find_active_request(ce);
 ...
 [test stuff like i915_request_started(rq)]
 ...
  if (rq) {
     rq = i915_request_get_rcu(rq);
     capture = intel_engine_coredump_add_request(ee, rq, 
ATOMIC_MAYFAIL);

     i915_request_put(rq);
 }

What is special about coredump_add_request() that it needs the 
request to be extra locked for that call and only that call? If the 
request can magically vanish after being found then what protects the 
_started() query? For that matter, what stops the request_get_rcu() 
itself being called on a pointer that is no longer valid? And if we 
do actually have sufficient locking in place to prevent that, why 
doesn't that cover the coredump_add_request() usage?


There is definitely a red flag there with the difference between the 
if and else blocks at the top of capture_engine(). And funnily enough, 
the first block appears to be GuC only. That is not obvious from the 
code and should probably have a comment, or function names made 
self-documenting.
In terms of 'red flag', you mean the apparent difference in locking in 
this section?

    ce = intel_engine_get_hung_context(engine);
    if (ce) {
    intel_engine_clear_hung_context(engine);
    rq = intel_context_find_active_request(ce);
    if (!rq || !i915_request_started(rq))
    goto no_request_capture;
    } else {
    /*
 * Getting here with GuC enabled means it is a forced 
error capture
 * with no actual hang. So, no need to attempt the 
execlist search.

 */
    if (!intel_uc_uses_guc_submission(&engine->gt->uc)) {
spin_lock_irqsave(&engine->sched_engine->lock, flags);
    rq = 
intel_engine_execlist_find_hung_request(engine);

spin_unlock_irqrestore(&engine->sched_engine->lock,
   flags);
    }
    }

There is no actual locking difference. The first thing 
intel_context_find_active_request() does is to acquire the relevant 
spinlock for the list it is about to traverse. I assume 
intel_engine_execlist_find_hung_request() must be called from other 
places that already have the appropriate lock and hence the lock must be 
done externally for all callers.


Technicall

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes

2023-01-17 Thread Rodrigo Vivi
On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > function adds the overhead of introducing a proxy file operation
> > > functions to wrap the original read/write inside file removal protection
> > > functions. This adds significant overhead in terms of introducing and
> > > managing the proxy factory file operations structure and function
> > > wrapping at runtime.
> > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > > with debugfs_create_file_unsafe() is suggested to be used instead.  The
> > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > debugfs_file_put() wrappers to protect the original read and write
> > > function calls for the debug attributes. There is no need for any
> > > runtime proxy file operations to be managed by the debugfs core.
> > > Following coccicheck make command helped identify this change:
> > > 
> > > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch 
> > > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > 
> > > Signed-off-by: Deepak R Varma 
> > 
> > I believe these 2 gvt cases could be done in one patch.
> > But anyways,
> > 
> > Reviewed-by: Rodrigo Vivi 
> > 
> > for both patches... and will leave these 2 patches for gvt folks
> > to apply. Unless they ack and I apply in the drm-intel along with the other 
> > ones.
> >
> 
> yeah, they're fine with me, feel free to apply them directly.
> 
> Acked-by: Zhenyu Wang 

Unfortunately I got some conflicts when trying to apply on drm-intel-next.

We probably need a new version, and probably through gvt branches it
will be easier to handle conflicts if they appear.

> 
> thanks!
> 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c 
> > > b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > index 03f081c3d9a4..baccbf1761b7 100644
> > > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> > >   return 0;
> > >  }
> > >  
> > > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, 
> > > "0x%llx\n");
> > > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, 
> > > "0x%llx\n");
> > >  
> > >  /**
> > >   * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> > > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu 
> > > *vgpu)
> > >   &vgpu_mmio_diff_fops);
> > >   debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> > >  &vgpu_scan_nonprivbb_fops);
> > > - debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > > - &vgpu_status_fops);
> > > + debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > > +&vgpu_status_fops);
> > >  }
> > >  
> > >  /**
> > > -- 
> > > 2.34.1
> > > 
> > > 
> > > 




Re: [Intel-gfx] [PATCH] drm/i915/display: Convert i9xx_pipe_crc_auto_source to void

2023-01-17 Thread Rodrigo Vivi
On Sat, Jan 14, 2023 at 07:33:53PM +0530, Deepak R Varma wrote:
> Convert function i9xx_pipe_crc_auto_source() to return void instead
> of int since the current implementation always returns 0 to the caller.
> Issue identified using returnvar Coccinelle semantic patch.

could you please share the coccinelle commands and files you used here?

> 
> Signed-off-by: Deepak R Varma 
> ---
> Please note: The change is compile tested only.

np, our CI liked it.

I liked the clean up as well:
Reviewed-by: Rodrigo Vivi 

> 
> 
>  drivers/gpu/drm/i915/display/intel_pipe_crc.c | 23 ++-
>  1 file changed, 7 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_pipe_crc.c 
> b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> index e9774670e3f6..8d3ea8d7b737 100644
> --- a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> @@ -72,14 +72,13 @@ static int i8xx_pipe_crc_ctl_reg(enum 
> intel_pipe_crc_source *source,
>   return 0;
>  }
>  
> -static int i9xx_pipe_crc_auto_source(struct drm_i915_private *dev_priv,
> -  enum pipe pipe,
> -  enum intel_pipe_crc_source *source)
> +static void i9xx_pipe_crc_auto_source(struct drm_i915_private *dev_priv,
> +   enum pipe pipe,
> +   enum intel_pipe_crc_source *source)
>  {
>   struct intel_encoder *encoder;
>   struct intel_crtc *crtc;
>   struct intel_digital_port *dig_port;
> - int ret = 0;
>  
>   *source = INTEL_PIPE_CRC_SOURCE_PIPE;
>  
> @@ -121,8 +120,6 @@ static int i9xx_pipe_crc_auto_source(struct 
> drm_i915_private *dev_priv,
>   }
>   }
>   drm_modeset_unlock_all(&dev_priv->drm);
> -
> - return ret;
>  }
>  
>  static int vlv_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
> @@ -132,11 +129,8 @@ static int vlv_pipe_crc_ctl_reg(struct drm_i915_private 
> *dev_priv,
>  {
>   bool need_stable_symbols = false;
>  
> - if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> - int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> - if (ret)
> - return ret;
> - }
> + if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
> + i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
>  
>   switch (*source) {
>   case INTEL_PIPE_CRC_SOURCE_PIPE:
> @@ -200,11 +194,8 @@ static int i9xx_pipe_crc_ctl_reg(struct drm_i915_private 
> *dev_priv,
>enum intel_pipe_crc_source *source,
>u32 *val)
>  {
> - if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> - int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> - if (ret)
> - return ret;
> - }
> + if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
> + i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
>  
>   switch (*source) {
>   case INTEL_PIPE_CRC_SOURCE_PIPE:
> -- 
> 2.34.1
> 
> 
> 


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: move snps_phy_failed_calibration to display sub-struct under snps

2023-01-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: move snps_phy_failed_calibration 
to display sub-struct under snps
URL   : https://patchwork.freedesktop.org/series/112933/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12592 -> Patchwork_112933v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/index.html

Participating hosts (44 -> 45)
--

  Additional (2): fi-kbl-soraka fi-rkl-11600 
  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_112933v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +15 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][3] -> [FAIL][4] ([i915#7229])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#3282])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#7561])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-8109u:   [PASS][11] -> [DMESG-FAIL][12] ([i915#5334])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][13] ([i915#1886])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@ring_submission:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][14] ([i915#7640])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-kbl-soraka/igt@i915_selftest@live@ring_submission.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][15] ([i915#4817])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#7828]) +7 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#4103])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([fdo#109285] / [i915#4098])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([i915#1072]) +3 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112933v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][20] ([i915#3555] / [i915#4098])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwo

Re: [Intel-gfx] [PATCH] drm/i915/gt: Move LSC_CHICKEN_BIT* workarounds to correct function

2023-01-17 Thread Rodrigo Vivi
On Thu, Jan 12, 2023 at 10:19:47PM -0300, Gustavo Sousa wrote:
> That register doesn't belong to a specific engine, so the proper
> placement for workarounds programming it should be
> general_render_compute_wa_init().


Looking to the surrounds it seems like we have more registers
that are not per engine specific being touched there.

So, a few questions came to my mind:
- do we need to a bigger clean up and move other cases as well?
- do we need to review one by one and see if the bug is really
for all the engines or affect one specific engine hence the
function was initially placed here?
- do we have any clean documentation on how to split things
around and when or where to place things here or there?

> 
> Signed-off-by: Gustavo Sousa 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 65 -
>  1 file changed, 36 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 6dacd0dc5c2c..bd40b8c93d24 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2325,10 +2325,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>   /* Wa_1509727124 */
>   wa_mcr_masked_en(wal, GEN10_SAMPLER_MODE,
>SC_DISABLE_POWER_OPTIMIZATION_EBB);
> -
> - /* Wa_22013037850 */
> - wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW,
> - DISABLE_128B_EVICTION_COMMAND_UDW);
>   }
>  
>   if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_FOREVER) ||
> @@ -2357,21 +2353,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>GEN12_DISABLE_HDR_PAST_PAYLOAD_HOLD_FIX);
>   }
>  
> - if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_C0) ||
> - IS_DG2_G11(i915)) {
> - /*
> -  * Wa_22012826095:dg2
> -  * Wa_22013059131:dg2
> -  */
> - wa_mcr_write_clr_set(wal, LSC_CHICKEN_BIT_0_UDW,
> -  MAXREQS_PER_BANK,
> -  REG_FIELD_PREP(MAXREQS_PER_BANK, 2));
> -
> - /* Wa_22013059131:dg2 */
> - wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0,
> - FORCE_1_SUB_MESSAGE_PER_FRAGMENT);
> - }
> -
>   /* Wa_1308578152:dg2_g10 when first gslice is fused off */
>   if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_C0) &&
>   needs_wa_1308578152(engine)) {
> @@ -2396,16 +2377,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, 
> struct i915_wa_list *wal)
>*/
>   wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN,
>MDQ_ARBITRATION_MODE | UGM_BACKUP_MODE);
> -
> - /*
> -  * Wa_14010918519:dg2_g10
> -  *
> -  * LSC_CHICKEN_BIT_0 always reads back as 0 is this stepping,
> -  * so ignoring verification.
> -  */
> - wa_mcr_add(wal, LSC_CHICKEN_BIT_0_UDW, 0,
> -FORCE_SLM_FENCE_SCOPE_TO_TILE | 
> FORCE_UGM_FENCE_SCOPE_TO_TILE,
> -0, false);
>   }
>  
>   if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0)) {
> @@ -2990,6 +2961,15 @@ general_render_compute_wa_init(struct intel_engine_cs 
> *engine, struct i915_wa_li
>  
>   add_render_compute_tuning_settings(i915, wal);
>  
> + if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> + IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0) ||
> + IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_FOREVER) ||
> + IS_DG2_G11(i915) || IS_DG2_G12(i915)) {
> + /* Wa_22013037850 */
> + wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW,
> + DISABLE_128B_EVICTION_COMMAND_UDW);
> + }
> +
>   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
>   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0) ||
>   IS_PONTEVECCHIO(i915) ||
> @@ -3011,6 +2991,33 @@ general_render_compute_wa_init(struct intel_engine_cs 
> *engine, struct i915_wa_li
>   wa_masked_en(wal, VFG_PREEMPTION_CHICKEN, 
> POLYGON_TRIFAN_LINELOOP_DISABLE);
>   }
>  
> + if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_C0) ||
> + IS_DG2_G11(i915)) {
> + /*
> +  * Wa_22012826095:dg2
> +  * Wa_22013059131:dg2
> +  */
> + wa_mcr_write_clr_set(wal, LSC_CHICKEN_BIT_0_UDW,
> +  MAXREQS_PER_BANK,
> +  REG_FIELD_PREP(MAXREQS_PER_BANK, 2));
> +
> + /* Wa_22013059131:dg2 */
> + wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0,
> + FORCE_1_SUB_MESSAGE_PER_FRAGMENT);
> + }
> +
> + if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0)

Re: [Intel-gfx] [PATCH 1/2] drm/i915: add struct i915_dsm to wrap dsm members together

2023-01-17 Thread Rodrigo Vivi
On Mon, Jan 16, 2023 at 07:34:21PM +0200, Jani Nikula wrote:
> Wrap the stolen memory related struct drm_i915_private members (dsm,
> dsm_reserved, and stolen_usable_size) together in a a new struct
> i915_dsm.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c  | 10 ++--
>  drivers/gpu/drm/i915/display/intel_fbdev.c|  2 +-
>  .../drm/i915/display/intel_plane_initial.c|  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 36 ++---
>  drivers/gpu/drm/i915/gt/intel_rc6.c   | 12 ++---
>  drivers/gpu/drm/i915/gt/selftest_reset.c  |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h   | 53 +++
>  drivers/gpu/drm/i915/selftests/i915_gem.c |  4 +-
>  8 files changed, 64 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index c508dcf415b4..b507ff944864 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -331,15 +331,15 @@ static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
>  {
>   struct drm_i915_private *i915 = fbc->i915;
>  
> - GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
> + GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.stolen.start,
>fbc->compressed_fb.start, U32_MAX));
> - GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
> + GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.stolen.start,
>fbc->compressed_llb.start, U32_MAX));
>  
>   intel_de_write(i915, FBC_CFB_BASE,
> -i915->dsm.start + fbc->compressed_fb.start);
> +i915->dsm.stolen.start + fbc->compressed_fb.start);
>   intel_de_write(i915, FBC_LL_BASE,
> -i915->dsm.start + fbc->compressed_llb.start);
> +i915->dsm.stolen.start + fbc->compressed_llb.start);
>  }
>  
>  static const struct intel_fbc_funcs i8xx_fbc_funcs = {
> @@ -712,7 +712,7 @@ static u64 intel_fbc_stolen_end(struct drm_i915_private 
> *i915)
>* underruns, even if that range is not reserved by the BIOS. */
>   if (IS_BROADWELL(i915) ||
>   (DISPLAY_VER(i915) == 9 && !IS_BROXTON(i915)))
> - end = resource_size(&i915->dsm) - 8 * 1024 * 1024;
> + end = resource_size(&i915->dsm.stolen) - 8 * 1024 * 1024;
>   else
>   end = U64_MAX;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index bbdb98d7c96e..19f3b5d92a55 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -170,7 +170,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>* important and we should probably use that space with FBC or 
> other
>* features.
>*/
> - if (size * 2 < dev_priv->stolen_usable_size)
> + if (size * 2 < dev_priv->dsm.usable_size)
>   obj = i915_gem_object_create_stolen(dev_priv, size);
>   if (IS_ERR(obj))
>   obj = i915_gem_object_create_shmem(dev_priv, size);
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index 76be796df255..bb6ea7de5c61 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -107,7 +107,7 @@ initial_plane_vma(struct drm_i915_private *i915,
>*/
>   if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
>   mem == i915->mm.stolen_region &&
> - size * 2 > i915->stolen_usable_size)
> + size * 2 > i915->dsm.usable_size)
>   return NULL;
>  
>   obj = i915_gem_object_create_region_at(mem, phys_base, size, 0);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index bc9521078807..de873498d95b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -211,7 +211,7 @@ static void g4x_get_stolen_reserved(struct 
> drm_i915_private *i915,
>   IS_GM45(i915) ?
>   CTG_STOLEN_RESERVED :
>   ELK_STOLEN_RESERVED);
> - resource_size_t stolen_top = i915->dsm.end + 1;
> + resource_size_t stolen_top = i915->dsm.stolen.end + 1;
>  
>   drm_dbg(&i915->drm, "%s_STOLEN_RESERVED = %08x\n",
>   IS_GM45(i915) ? "CTG" : "ELK", reg_val);
> @@ -276,7 +276,7 @@ static void vlv_get_stolen_reserved(struct 
> drm_i915_private *i915,
>   resource_size_t *size)
>  {
>   u32 reg_val = intel_uncore_read(uncore, GEN6_STOLEN_RESERVED);
> - resource_size_t stolen_top = i915->dsm.end + 1;
> + resource_size_t stolen_to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: GMCH refactoring (rev2)

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: GMCH refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/112929/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12592 -> Patchwork_112929v2


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/index.html

Participating hosts (44 -> 44)
--

  Additional (1): fi-rkl-11600 
  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_112929v2:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-1}:   [DMESG-WARN][1] ([i915#7625]) -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


  Here are the changes found in Patchwork_112929v2 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#7456])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3282])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#7561])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][10] ([i915#4817])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#7828]) +7 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4103])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#3555] / [i915#4098])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v2/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_module_load@load:
- {bat-dg2-8}:[FAIL][18] -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/bat-dg2-8/igt@i915_module_l...@load.html
   [19]: 
https://intel-gfx-ci.01.org/tr

Re: [Intel-gfx] [PATCH] drm/i915/display: add intel_display_limits.h for key enums

2023-01-17 Thread Rodrigo Vivi
On Mon, Jan 16, 2023 at 06:46:44PM +0200, Jani Nikula wrote:
> Move a handful of key enums to a new file intel_display_limits.h. These
> are the enum types, and the MAX/NUM enumerations within them, that are
> used in other headers. Otherwise, there's no common theme between them.
> 
> Replace intel_display.h include with intel_display_limit.h where
> relevant, and add the intel_display.h include directly in the .c files
> where needed.
> 
> Since intel_display.h is used almost everywhere in display/, include it
> from intel_display_types.h to avoid massive changes across the
> board. There are very few files that would need intel_display_types.h
> but not intel_display.h so this is neglible, and further cleanup between
> these headers can be left for the future.
> 
> Overall this change drops the direct and indirect dependencies on
> intel_display.h from about 300 to about 100 compilation units, because
> we can drop the include from i915_drv.h.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Rodrigo Vivi 

> 
> ---
> 
> N.b. intel_display_limits.h is not a great name. I was hoping it was
> only needed for the MAX/NUM enumerations such as I915_MAX_PIPES but
> there are a number of headers that use the types for struct members as
> well. intel_display_enums.h sounds too generic too. Suggestions?
> ---
>  drivers/gpu/drm/i915/display/intel_bw.h   |   2 +-
>  drivers/gpu/drm/i915/display/intel_cdclk.h|   2 +-
>  drivers/gpu/drm/i915/display/intel_display.h  | 115 +---
>  .../gpu/drm/i915/display/intel_display_core.h |   2 +-
>  .../drm/i915/display/intel_display_limits.h   | 124 ++
>  .../i915/display/intel_display_power_map.c|   1 +
>  .../drm/i915/display/intel_display_types.h|   1 +
>  drivers/gpu/drm/i915/display/intel_dvo_dev.h  |   2 +-
>  drivers/gpu/drm/i915/display/skl_watermark.h  |   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_create.c|   1 +
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c|   1 +
>  drivers/gpu/drm/i915/gt/intel_ggtt.c  |   1 +
>  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c  |   1 +
>  drivers/gpu/drm/i915/gt/intel_rps.c   |   1 +
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |   1 +
>  drivers/gpu/drm/i915/gvt/display.c|   1 +
>  drivers/gpu/drm/i915/gvt/fb_decoder.h |   2 +-
>  drivers/gpu/drm/i915/i915_drv.h   |   2 +-
>  drivers/gpu/drm/i915/i915_pci.c   |   1 +
>  drivers/gpu/drm/i915/i915_vma.c   |   1 +
>  drivers/gpu/drm/i915/intel_device_info.c  |   1 +
>  drivers/gpu/drm/i915/intel_device_info.h  |   2 +-
>  drivers/gpu/drm/i915/intel_gvt_mmio_table.c   |   1 +
>  drivers/gpu/drm/i915/intel_pm.c   |   1 +
>  drivers/gpu/drm/i915/intel_pm_types.h |   2 +-
>  drivers/gpu/drm/i915/vlv_sideband.c   |   1 +
>  26 files changed, 149 insertions(+), 123 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_display_limits.h
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index cb7ee3a24a58..f20292143745 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -8,7 +8,7 @@
>  
>  #include 
>  
> -#include "intel_display.h"
> +#include "intel_display_limits.h"
>  #include "intel_display_power.h"
>  #include "intel_global_state.h"
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h 
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index c674879a84a5..51e2f6a11ce4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -8,7 +8,7 @@
>  
>  #include 
>  
> -#include "intel_display.h"
> +#include "intel_display_limits.h"
>  #include "intel_global_state.h"
>  
>  struct drm_i915_private;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> b/drivers/gpu/drm/i915/display/intel_display.h
> index ef73730f32b0..cb6f520cc575 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -28,6 +28,7 @@
>  #include 
>  
>  #include "i915_reg_defs.h"
> +#include "intel_display_limits.h"
>  
>  enum drm_scaling_filter;
>  struct dpll;
> @@ -62,51 +63,9 @@ struct intel_remapped_info;
>  struct intel_rotation_info;
>  struct pci_dev;
>  
> -/*
> - * Keep the pipe enum values fixed: the code assumes that PIPE_A=0, the
> - * rest have consecutive values and match the enum values of transcoders
> - * with a 1:1 transcoder -> pipe mapping.
> - */
> -enum pipe {
> - INVALID_PIPE = -1,
> -
> - PIPE_A = 0,
> - PIPE_B,
> - PIPE_C,
> - PIPE_D,
> - _PIPE_EDP,
> -
> - I915_MAX_PIPES = _PIPE_EDP
> -};
>  
>  #define pipe_name(p) ((p) + 'A')
>  
> -enum transcoder {
> - INVALID_TRANSCODER = -1,
> - /*
> -  * The following transcoders have a 1:1 transcoder -> pipe mapping,
> -  * keep their values fixed: the code assumes that TRANSCODER_A=0, the
> -  * rest

[Intel-gfx] [PATCH 2/2] drm/i915: Fix a memory leak with reused mmap_offset

2023-01-17 Thread Nirmoy Das
drm_vma_node_allow() and drm_vma_node_revoke() should be called in
balanced pairs. We call drm_vma_node_allow() once per-file everytime a
user calls mmap_offset, but only call drm_vma_node_revoke once per-file
on each mmap_offset. As the mmap_offset is reused by the client, the
per-file vm_count may remain non-zero and the rbtree leaked.

Call drm_vma_node_allow_once() instead to prevent that memory leak.

Cc: Tvrtko Ursulin 
Cc: Andi Shyti 

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 4f69bff63068..2aac6bf78740 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -697,7 +697,7 @@ mmap_offset_attach(struct drm_i915_gem_object *obj,
GEM_BUG_ON(lookup_mmo(obj, mmap_type) != mmo);
 out:
if (file)
-   drm_vma_node_allow(&mmo->vma_node, file);
+   drm_vma_node_allow_once(&mmo->vma_node, file);
return mmo;
 
 err:
-- 
2.39.0



[Intel-gfx] [PATCH 1/2] drm/drm_vma_manager: Add drm_vma_node_allow_once()

2023-01-17 Thread Nirmoy Das
Currently there is no easy way for a drm driver to safely check and allow
drm_vma_offset_node for a drm file just once. Allow drm drivers to call
non-refcounted version of drm_vma_node_allow() so that a driver doesn't
need to keep track of each drm_vma_node_allow() to call subsequent
drm_vma_node_revoke() to prevent memory leak.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Andi Shyti 

Suggested-by: Chris Wilson 
Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/drm_vma_manager.c | 76 ++-
 include/drm/drm_vma_manager.h |  1 +
 2 files changed, 55 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_vma_manager.c 
b/drivers/gpu/drm/drm_vma_manager.c
index 7de37f8c68fd..83229a031af0 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -240,27 +240,8 @@ void drm_vma_offset_remove(struct drm_vma_offset_manager 
*mgr,
 }
 EXPORT_SYMBOL(drm_vma_offset_remove);
 
-/**
- * drm_vma_node_allow - Add open-file to list of allowed users
- * @node: Node to modify
- * @tag: Tag of file to remove
- *
- * Add @tag to the list of allowed open-files for this node. If @tag is
- * already on this list, the ref-count is incremented.
- *
- * The list of allowed-users is preserved across drm_vma_offset_add() and
- * drm_vma_offset_remove() calls. You may even call it if the node is currently
- * not added to any offset-manager.
- *
- * You must remove all open-files the same number of times as you added them
- * before destroying the node. Otherwise, you will leak memory.
- *
- * This is locked against concurrent access internally.
- *
- * RETURNS:
- * 0 on success, negative error code on internal failure (out-of-mem)
- */
-int drm_vma_node_allow(struct drm_vma_offset_node *node, struct drm_file *tag)
+static int vma_node_allow(struct drm_vma_offset_node *node,
+ struct drm_file *tag, bool ref_counted)
 {
struct rb_node **iter;
struct rb_node *parent = NULL;
@@ -282,7 +263,8 @@ int drm_vma_node_allow(struct drm_vma_offset_node *node, 
struct drm_file *tag)
entry = rb_entry(*iter, struct drm_vma_offset_file, vm_rb);
 
if (tag == entry->vm_tag) {
-   entry->vm_count++;
+   if (ref_counted)
+   entry->vm_count++;
goto unlock;
} else if (tag > entry->vm_tag) {
iter = &(*iter)->rb_right;
@@ -307,8 +289,58 @@ int drm_vma_node_allow(struct drm_vma_offset_node *node, 
struct drm_file *tag)
kfree(new);
return ret;
 }
+
+/**
+ * drm_vma_node_allow - Add open-file to list of allowed users
+ * @node: Node to modify
+ * @tag: Tag of file to remove
+ *
+ * Add @tag to the list of allowed open-files for this node. If @tag is
+ * already on this list, the ref-count is incremented.
+ *
+ * The list of allowed-users is preserved across drm_vma_offset_add() and
+ * drm_vma_offset_remove() calls. You may even call it if the node is currently
+ * not added to any offset-manager.
+ *
+ * You must remove all open-files the same number of times as you added them
+ * before destroying the node. Otherwise, you will leak memory.
+ *
+ * This is locked against concurrent access internally.
+ *
+ * RETURNS:
+ * 0 on success, negative error code on internal failure (out-of-mem)
+ */
+int drm_vma_node_allow(struct drm_vma_offset_node *node, struct drm_file *tag)
+{
+   return vma_node_allow(node, tag, true);
+}
 EXPORT_SYMBOL(drm_vma_node_allow);
 
+/**
+ * drm_vma_node_allow_once - Add open-file to list of allowed users
+ * @node: Node to modify
+ * @tag: Tag of file to remove
+ *
+ * Add @tag to the list of allowed open-files for this node.
+ *
+ * The list of allowed-users is preserved across drm_vma_offset_add() and
+ * drm_vma_offset_remove() calls. You may even call it if the node is currently
+ * not added to any offset-manager.
+ *
+ * This is not ref-counted unlike drm_vma_node_allow() hence 
drm_vma_node_revoke()
+ * should only be called once after this.
+ *
+ * This is locked against concurrent access internally.
+ *
+ * RETURNS:
+ * 0 on success, negative error code on internal failure (out-of-mem)
+ */
+int drm_vma_node_allow_once(struct drm_vma_offset_node *node, struct drm_file 
*tag)
+{
+   return vma_node_allow(node, tag, false);
+}
+EXPORT_SYMBOL(drm_vma_node_allow_once);
+
 /**
  * drm_vma_node_revoke - Remove open-file from list of allowed users
  * @node: Node to modify
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 4f8c35206f7c..6c2a2f21dbf0 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -74,6 +74,7 @@ void drm_vma_offset_remove(struct drm_vma_offset_manager *mgr,
   struct drm_vma_offset_node *node);
 
 int drm_vma_node_allow(struct drm_vma_offset_node *node, stru

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: extract vblank/scanline code to a separate file

2023-01-17 Thread Ville Syrjälä
On Mon, Jan 16, 2023 at 02:56:11PM +0200, Jani Nikula wrote:
> Basically just https://patchwork.freedesktop.org/series/111854/ with the
> two controversial patches dropped for now.
> 
> BR,
> Jani.
> 
> Jani Nikula (5):
>   drm/i915/irq: split out vblank/scanline code to intel_vblank.[ch]
>   drm/i915/display: move more scanline functions to intel_vblank.[ch]
>   drm/i915/display: use common function for checking scanline is moving
>   drm/i915/vblank: use intel_de_read()
>   drm/i915/vblank: add and use intel_de_read64_2x32() to read vblank
> counter

Series is
Reviewed-by: Ville Syrjälä 

> 
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_crtc.c |   1 +
>  drivers/gpu/drm/i915/display/intel_de.h   |   7 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  54 +--
>  .../drm/i915/display/intel_display_trace.h|   1 +
>  drivers/gpu/drm/i915/display/intel_vblank.c   | 441 ++
>  drivers/gpu/drm/i915/display/intel_vblank.h   |  23 +
>  drivers/gpu/drm/i915/i915_irq.c   | 408 
>  drivers/gpu/drm/i915/i915_irq.h   |   6 -
>  9 files changed, 476 insertions(+), 466 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_vblank.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_vblank.h
> 
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: GMCH refactoring (rev2)

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: GMCH refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/112929/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove a couple of superfluous i915_drm.h includes

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: remove a couple of superfluous i915_drm.h includes
URL   : https://patchwork.freedesktop.org/series/112931/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12592 -> Patchwork_112931v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/index.html

Participating hosts (44 -> 42)
--

  Missing(2): fi-bsw-kefka fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_112931v1:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@hangcheck:
- {bat-adlp-6}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/bat-adlp-6/igt@i915_selftest@l...@hangcheck.html

  
Known issues


  Here are the changes found in Patchwork_112931v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@runner@aborted:
- fi-cfl-8109u:   NOTRUN -> [FAIL][3] ([i915#4312])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/fi-cfl-8109u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_module_load@load:
- {bat-dg2-8}:[FAIL][4] -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/bat-dg2-8/igt@i915_module_l...@load.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/bat-dg2-8/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@guc:
- {bat-rpls-2}:   [DMESG-WARN][6] ([i915#7852]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/bat-rpls-2/igt@i915_selftest@l...@guc.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/bat-rpls-2/igt@i915_selftest@l...@guc.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-adlm-1}:   [DMESG-WARN][8] -> [PASS][9] +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12592/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852


Build changes
-

  * Linux: CI_DRM_12592 -> Patchwork_112931v1

  CI-20190529: 20190529
  CI_DRM_12592: aa316f18737ff65f416f94aa98ed38d6a073582c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7121: aa16e81259f59734230d441905b9d0f605e4a4b5 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_112931v1: aa316f18737ff65f416f94aa98ed38d6a073582c @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

fefdb4290c7b drm/i915: remove a couple of superfluous i915_drm.h includes

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112931v1/index.html


Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission

2023-01-17 Thread Jason Ekstrand
On Thu, Jan 12, 2023 at 11:17 AM Matthew Brost 
wrote:

> On Thu, Jan 12, 2023 at 10:54:25AM +0100, Lucas De Marchi wrote:
> > On Thu, Jan 05, 2023 at 09:27:57PM +, Matthew Brost wrote:
> > > On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote:
> > > >
> > > > On 22/12/2022 22:21, Matthew Brost wrote:
> > > > > Hello,
> > > > >
> > > > > This is a submission for Xe, a new driver for Intel GPUs that
> supports both
> > > > > integrated and discrete platforms starting with Tiger Lake (first
> platform with
> > > > > Intel Xe Architecture). The intention of this new driver is to
> have a fresh base
> > > > > to work from that is unencumbered by older platforms, whilst also
> taking the
> > > > > opportunity to rearchitect our driver to increase sharing across
> the drm
> > > > > subsystem, both leveraging and allowing us to contribute more
> towards other
> > > > > shared components like TTM and drm/scheduler. The memory model is
> based on VM
> > > > > bind which is similar to the i915 implementation. Likewise the
> execbuf
> > > > > implementation for Xe is very similar to execbuf3 in the i915 [1].
> > > > >
> > > > > The code is at a stage where it is already functional and has
> experimental
> > > > > support for multiple platforms starting from Tiger Lake, with
> initial support
> > > > > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan
> drivers), as well
> > > > > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2]
> and NEO
> > > > > implementation will be released publicly early next year. We also
> have a suite
> > > > > of IGTs for XE that will appear on the IGT list shortly.
> > > > >
> > > > > It has been built with the assumption of supporting multiple
> architectures from
> > > > > the get-go, right now with tests running both on X86 and ARM
> hosts. And we
> > > > > intend to continue working on it and improving on it as part of
> the kernel
> > > > > community upstream.
> > > > >
> > > > > The new Xe driver leverages a lot from i915 and work on i915
> continues as we
> > > > > ready Xe for production throughout 2023.
> > > > >
> > > > > As for display, the intent is to share the display code with the
> i915 driver so
> > > > > that there is maximum reuse there. Currently this is being done by
> compiling the
> > > > > display code twice, but alternatives to that are under
> consideration and we want
> > > > > to have more discussion on what the best final solution will look
> like over the
> > > > > next few months. Right now, work is ongoing in refactoring the
> display codebase
> > > > > to remove as much as possible any unnecessary dependencies on i915
> specific data
> > > > > structures there..
> > > > >
> > > > > We currently have 2 submission backends, execlists and GuC. The
> execlist is
> > > > > meant mostly for testing and is not fully functional while GuC
> backend is fully
> > > > > functional. As with the i915 and GuC submission, in Xe the GuC
> firmware is
> > > > > required and should be placed in /lib/firmware/xe.
> > > >
> > > > What is the plan going forward for the execlists backend? I think it
> would
> > > > be preferable to not upstream something semi-functional and so to
> carry
> > > > technical debt in the brand new code base, from the very start. If
> it is for
> > > > Tigerlake, which is the starting platform for Xe, could it be made
> GuC only
> > > > Tigerlake for instance?
> > > >
> > >
> > > A little background here. In the original PoC written by Jason and
> Dave,
> > > the execlist backend was the only one present and it was in
> semi-working
> > > state. As soon as myself and a few others started working on Xe we went
> > > full in a on the GuC backend. We left the execlist backend basically in
> > > the state it was in. We left it in place for 2 reasons.
> > >
> > > 1. Having 2 backends from the start ensured we layered our code
> > > correctly. The layer was a complete disaster in the i915 so we really
> > > wanted to avoid that.
> > > 2. The thought was it might be needed for early product bring up one
> > > day.
> > >
> > > As I think about this a bit more, we likely just delete execlist
> backend
> > > before merging this upstream and perhaps just carry 1 large patch
> > > internally with this implementation that we can use as needed. Final
> > > decession TDB though.
> >
> > but that might regress after some time on "let's keep 2 backends so we
> > layer the code correctly". Leaving the additional backend behind
> > CONFIG_BROKEN or XE_EXPERIMENTAL, or something like that, not
> > enabled by distros, but enabled in CI would be a good idea IMO.
> >
> > Carrying a large patch out of tree would make things harder for new
> > platforms. A perfect backend split would make it possible, but like I
> > said, we are likely not to have it if we delete the second backend.
> >
>
> Good points here Lucas. One thing that we absolutely have wrong is
> falling back to execlists if GuC firmware is missing. We def should not
> be 

[Intel-gfx] [PATCH] drm/i915/selftest: fix intel_selftest_modify_policy argument types

2023-01-17 Thread Arnd Bergmann
From: Arnd Bergmann 

The definition of intel_selftest_modify_policy() does not match the
declaration, as gcc-13 points out:

drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:29:5: error: 
conflicting types for 'intel_selftest_modify_policy' due to enum/integer 
mismatch; have 'int(struct intel_engine_cs *, struct 
intel_selftest_saved_policy *, u32)' {aka 'int(struct intel_engine_cs *, struct 
intel_selftest_saved_policy *, unsigned int)'} [-Werror=enum-int-mismatch]
   29 | int intel_selftest_modify_policy(struct intel_engine_cs *engine,
  | ^~~~
In file included from 
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:11:
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.h:28:5: note: previous 
declaration of 'intel_selftest_modify_policy' with type 'int(struct 
intel_engine_cs *, struct intel_selftest_saved_policy *, enum 
selftest_scheduler_modify)'
   28 | int intel_selftest_modify_policy(struct intel_engine_cs *engine,
  | ^~~~

Change the type in the definition to match.

Fixes: 617e87c05c72 ("drm/i915/selftest: Fix hangcheck self test for GuC 
submission")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c 
b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
index 310fb83c527e..2990dd4d4a0d 100644
--- a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
+++ b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
@@ -28,8 +28,7 @@ struct intel_engine_cs *intel_selftest_find_any_engine(struct 
intel_gt *gt)
 
 int intel_selftest_modify_policy(struct intel_engine_cs *engine,
 struct intel_selftest_saved_policy *saved,
-u32 modify_type)
-
+enum selftest_scheduler_modify modify_type)
 {
int err;
 
-- 
2.39.0



Re: [Intel-gfx] [RFC 04/12] drm/cgroup: Track clients per owning process

2023-01-17 Thread Tvrtko Ursulin



On 17/01/2023 16:03, Stanislaw Gruszka wrote:

Hi

On Thu, Jan 12, 2023 at 04:56:01PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

To enable propagation of settings from the cgroup drm controller to drm we
need to start tracking which processes own which drm clients.

Implement that by tracking the struct pid pointer of the owning process in
a new XArray, pointing to a structure containing a list of associated
struct drm_file pointers.

Clients are added and removed under the filelist mutex and RCU list
operations are used below it to allow for lockless lookup.

Signed-off-by: Tvrtko Ursulin 





+int drm_clients_open(struct drm_file *file_priv)
+{
+   struct drm_device *dev = file_priv->minor->dev;
+   struct drm_pid_clients *clients;
+   bool new_client = false;
+   unsigned long pid;
+
+   lockdep_assert_held(&dev->filelist_mutex);
+
+   pid = (unsigned long)rcu_access_pointer(file_priv->pid);
+   clients = xa_load(&drm_pid_clients, pid);
+   if (!clients) {
+   clients = __alloc_clients();
+   if (!clients)
+   return -ENOMEM;
+   new_client = true;
+   }
+   atomic_inc(&clients->num);
+   list_add_tail_rcu(&file_priv->clink, &clients->file_list);
+   if (new_client) {
+   void *xret;
+
+   xret = xa_store(&drm_pid_clients, pid, clients, GFP_KERNEL);
+   if (xa_err(xret)) {
+   list_del_init(&file_priv->clink);
+   kfree(clients);
+   return PTR_ERR(clients);


This looks incorrect, rather xa_err(xret) should be returned.


Thanks, looks like a copy & paste error. Noted to correct before next 
public post.


Regards,

Tvrtko


Re: [Intel-gfx] [PATCH 0/4] drm/i915: GMCH refactoring

2023-01-17 Thread Ville Syrjälä
On Tue, Jan 17, 2023 at 02:33:05PM +0200, Jani Nikula wrote:
> Let's see if this sticks.
> 
> Jani Nikula (4):
>   drm/i915: add gmch substruct to struct drm_i915_private
>   drm/i915/gmch: split out soc/intel_gmch
>   drm/i915/gmch: mass rename dev_priv to i915
>   drm/i915/gmch: move VGA set state to GMCH code

My main worry with this name would be confusion with HAS_GMCH().

> 
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_vga.c  |  32 +---
>  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c |   2 +-
>  drivers/gpu/drm/i915/i915_driver.c| 145 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  10 +-
>  drivers/gpu/drm/i915/soc/intel_gmch.c | 171 ++
>  drivers/gpu/drm/i915/soc/intel_gmch.h |  18 +++
>  7 files changed, 204 insertions(+), 175 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/soc/intel_gmch.c
>  create mode 100644 drivers/gpu/drm/i915/soc/intel_gmch.h
> 
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PATCH 0/4] drm/i915: GMCH refactoring

2023-01-17 Thread Rodrigo Vivi
On Tue, Jan 17, 2023 at 02:33:05PM +0200, Jani Nikula wrote:
> Let's see if this sticks.

Suddenly all of these 'bridge_dev' makes some sense to me.

I believe we could enjoy the refactor here and add some documentation
about this... at least the name Graphics Memory Controller Hub name...

I also wonder if we should make this a child device now that it is
really organized...

But anyway, everything can be a follow up, the current refactor
is already a very good clean up step, so for the series:


Reviewed-by: Rodrigo Vivi 


> 
> Jani Nikula (4):
>   drm/i915: add gmch substruct to struct drm_i915_private
>   drm/i915/gmch: split out soc/intel_gmch
>   drm/i915/gmch: mass rename dev_priv to i915
>   drm/i915/gmch: move VGA set state to GMCH code
> 
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_vga.c  |  32 +---
>  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c |   2 +-
>  drivers/gpu/drm/i915/i915_driver.c| 145 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  10 +-
>  drivers/gpu/drm/i915/soc/intel_gmch.c | 171 ++
>  drivers/gpu/drm/i915/soc/intel_gmch.h |  18 +++
>  7 files changed, 204 insertions(+), 175 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/soc/intel_gmch.c
>  create mode 100644 drivers/gpu/drm/i915/soc/intel_gmch.h
> 
> -- 
> 2.34.1
> 


Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission

2023-01-17 Thread Jason Ekstrand
On Thu, Dec 22, 2022 at 4:29 PM Matthew Brost 
wrote:

> Hello,
>
> This is a submission for Xe, a new driver for Intel GPUs that supports both
> integrated and discrete platforms starting with Tiger Lake (first platform
> with
> Intel Xe Architecture). The intention of this new driver is to have a
> fresh base
> to work from that is unencumbered by older platforms, whilst also taking
> the
> opportunity to rearchitect our driver to increase sharing across the drm
> subsystem, both leveraging and allowing us to contribute more towards other
> shared components like TTM and drm/scheduler. The memory model is based on
> VM
> bind which is similar to the i915 implementation. Likewise the execbuf
> implementation for Xe is very similar to execbuf3 in the i915 [1].
>
> The code is at a stage where it is already functional and has experimental
> support for multiple platforms starting from Tiger Lake, with initial
> support
> implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as
> well
> as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO
> implementation will be released publicly early next year. We also have a
> suite
> of IGTs for XE that will appear on the IGT list shortly.
>
> It has been built with the assumption of supporting multiple architectures
> from
> the get-go, right now with tests running both on X86 and ARM hosts. And we
> intend to continue working on it and improving on it as part of the kernel
> community upstream.
>
> The new Xe driver leverages a lot from i915 and work on i915 continues as
> we
> ready Xe for production throughout 2023.
>
> As for display, the intent is to share the display code with the i915
> driver so
> that there is maximum reuse there. Currently this is being done by
> compiling the
> display code twice, but alternatives to that are under consideration and
> we want
> to have more discussion on what the best final solution will look like
> over the
> next few months. Right now, work is ongoing in refactoring the display
> codebase
> to remove as much as possible any unnecessary dependencies on i915
> specific data
> structures there..
>
> We currently have 2 submission backends, execlists and GuC. The execlist is
> meant mostly for testing and is not fully functional while GuC backend is
> fully
> functional. As with the i915 and GuC submission, in Xe the GuC firmware is
> required and should be placed in /lib/firmware/xe.
>
> The GuC firmware can be found in the below location:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
>
> The easiest way to setup firmware is:
> cp -r /lib/firmware/i915 /lib/firmware/xe
>
> The code has been organized such that we have all patches that touch areas
> outside of drm/xe first for review, and then the actual new driver in a
> separate
> commit. The code which is outside of drm/xe is included in this RFC while
> drm/xe is not due to the size of the commit. The drm/xe is code is
> available in
> a public repo listed below.
>
> Xe driver commit:
>
> https://cgit.freedesktop.org/drm/drm-xe/commit/?h=drm-xe-next&id=9cb016ebbb6a275f57b1cb512b95d5a842391ad7


Drive-by comment here because I don't see any actual xe patches on the list:

You probably want to drop DRM_XE_SYNC_DMA_BUF from the uAPI.  Now that
we've landed the new dma-buf ioctls for sync_file import/export, there's
really no reason to have it as part of submit.  Dropping it should also
make locking a tiny bit easier.

--Jason



> Xe kernel repo:
> https://cgit.freedesktop.org/drm/drm-xe/
>
> There's a lot of work still to happen on Xe but we're very excited about
> it and
> wanted to share it early and welcome feedback and discussion.
>
> Cheers,
> Matthew Brost
>
> [1] https://patchwork.freedesktop.org/series/105879/
> [2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20418
>
> Maarten Lankhorst (12):
>   drm/amd: Convert amdgpu to use suballocation helper.
>   drm/radeon: Use the drm suballocation manager implementation.
>   drm/i915: Remove gem and overlay frontbuffer tracking
>   drm/i915/display: Neuter frontbuffer tracking harder
>   drm/i915/display: Add more macros to remove all direct calls to uncore
>   drm/i915/display: Remove all uncore mmio accesses in favor of intel_de
>   drm/i915: Rename find_section to find_bdb_section
>   drm/i915/regs: Set DISPLAY_MMIO_BASE to 0 for xe
>   drm/i915/display: Fix a use-after-free when intel_edp_init_connector
> fails
>   drm/i915/display: Remaining changes to make xe compile
>   sound/hda: Allow XE as i915 replacement for sound
>   mei/hdcp: Also enable for XE
>
> Matthew Brost (5):
>   drm/sched: Convert drm scheduler to use a work queue rather than
> kthread
>   drm/sched: Add generic scheduler message interface
>   drm/sched: Start run wq before TDR in drm_sched_start
>   drm/sched: Submit job before starting TDR
>   drm/sched: Add helper to set TDR timeout
>
> Thomas Hellström (3):
>   drm/suballoc: Introduce a generic su

Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Unwind hugepages to drop wakeref on error

2023-01-17 Thread Das, Nirmoy

|Reviewed-by: Nirmoy Das |

On 1/17/2023 1:32 PM, Nirmoy Das wrote:

From: Chris Wilson

Make sure that upon error after we have acquired the wakeref we do
release it again.

v2: add another missing "goto out_wf"(Andi).

Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
Cc: Andi Shyti
Reviewed-by: Matthew Auld
Reviewed-by: Andrzej Hajda
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
---
  drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c281b0ec9e05..defece0bcb81 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1855,7 +1855,7 @@ static int igt_shrink_thp(void *arg)
I915_SHRINK_ACTIVE);
i915_vma_unpin(vma);
if (err)
-   goto out_put;
+   goto out_wf;
  
  	/*

 * Now that the pages are *unpinned* shrinking should invoke
@@ -1871,19 +1871,19 @@ static int igt_shrink_thp(void *arg)
pr_err("unexpected pages mismatch, should_swap=%s\n",
   str_yes_no(should_swap));
err = -EINVAL;
-   goto out_put;
+   goto out_wf;
}
  
  	if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {

pr_err("unexpected residual page-size bits, should_swap=%s\n",
   str_yes_no(should_swap));
err = -EINVAL;
-   goto out_put;
+   goto out_wf;
}
  
  	err = i915_vma_pin(vma, 0, 0, flags);

if (err)
-   goto out_put;
+   goto out_wf;
  
  	while (n--) {

err = cpu_check(obj, n, 0xdeadbeaf);

Re: [Intel-gfx] [RFC 04/12] drm/cgroup: Track clients per owning process

2023-01-17 Thread Stanislaw Gruszka
Hi

On Thu, Jan 12, 2023 at 04:56:01PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> To enable propagation of settings from the cgroup drm controller to drm we
> need to start tracking which processes own which drm clients.
> 
> Implement that by tracking the struct pid pointer of the owning process in
> a new XArray, pointing to a structure containing a list of associated
> struct drm_file pointers.
> 
> Clients are added and removed under the filelist mutex and RCU list
> operations are used below it to allow for lockless lookup.
> 
> Signed-off-by: Tvrtko Ursulin 



> +int drm_clients_open(struct drm_file *file_priv)
> +{
> + struct drm_device *dev = file_priv->minor->dev;
> + struct drm_pid_clients *clients;
> + bool new_client = false;
> + unsigned long pid;
> +
> + lockdep_assert_held(&dev->filelist_mutex);
> +
> + pid = (unsigned long)rcu_access_pointer(file_priv->pid);
> + clients = xa_load(&drm_pid_clients, pid);
> + if (!clients) {
> + clients = __alloc_clients();
> + if (!clients)
> + return -ENOMEM;
> + new_client = true;
> + }
> + atomic_inc(&clients->num);
> + list_add_tail_rcu(&file_priv->clink, &clients->file_list);
> + if (new_client) {
> + void *xret;
> +
> + xret = xa_store(&drm_pid_clients, pid, clients, GFP_KERNEL);
> + if (xa_err(xret)) {
> + list_del_init(&file_priv->clink);
> + kfree(clients);
> + return PTR_ERR(clients);

This looks incorrect, rather xa_err(xret) should be returned.

Regards
Stanislaw


Re: [Intel-gfx] [PATCH 3/3] drm/i915: move chv_dpll_md and bxt_phy_grc to display sub-struct under state

2023-01-17 Thread Rodrigo Vivi
On Tue, Jan 17, 2023 at 04:39:46PM +0200, Jani Nikula wrote:
> Move the display related members to the struct drm_i915_private display
> sub-struct. Put them under "state", as they are related to storing
> values that aren't readable from the hardware, to appease the state
> checker.
> 
> Signed-off-by: Jani Nikula 

For the series:

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_display_core.h | 10 ++
>  drivers/gpu/drm/i915/display/intel_dpio_phy.c |  9 +
>  drivers/gpu/drm/i915/display/intel_dpll.c |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  8 
>  5 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 734e8e613f8e..419537a79255 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3291,7 +3291,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc 
> *crtc,
>   if (DISPLAY_VER(dev_priv) >= 4) {
>   /* No way to read it out on pipes B and C */
>   if (IS_CHERRYVIEW(dev_priv) && crtc->pipe != PIPE_A)
> - tmp = dev_priv->chv_dpll_md[crtc->pipe];
> + tmp = dev_priv->display.state.chv_dpll_md[crtc->pipe];
>   else
>   tmp = intel_de_read(dev_priv, DPLL_MD(crtc->pipe));
>   pipe_config->pixel_multiplier =
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index c0eb753112d5..24c792d44b8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -441,6 +441,16 @@ struct intel_display {
>   u8 phy_failed_calibration;
>   } snps;
>  
> + struct {
> + /*
> +  * Shadows for CHV DPLL_MD regs to keep the state
> +  * checker somewhat working in the presence hardware
> +  * crappiness (can't read out DPLL_MD for pipes B & C).
> +  */
> + u32 chv_dpll_md[I915_MAX_PIPES];
> + u32 bxt_phy_grc;
> + } state;
> +
>   struct {
>   /* ordered wq for modesets */
>   struct workqueue_struct *modeset;
> diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> index 7eb7440b3180..565c06de2432 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> @@ -376,7 +376,7 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
> *dev_priv,
>   if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
>   /* Still read out the GRC value for state verification */
>   if (phy_info->rcomp_phy != -1)
> - dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, phy);
> + dev_priv->display.state.bxt_phy_grc = 
> bxt_get_grc(dev_priv, phy);
>  
>   if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
>   drm_dbg(&dev_priv->drm, "DDI PHY %d already enabled, "
> @@ -442,8 +442,9 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
> *dev_priv,
>* the corresponding calibrated value from PHY1, and disable
>* the automatic calibration on PHY0.
>*/
> - val = dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv,
> -   phy_info->rcomp_phy);
> + val = bxt_get_grc(dev_priv, phy_info->rcomp_phy);
> + dev_priv->display.state.bxt_phy_grc = val;
> +
>   grc_code = val << GRC_CODE_FAST_SHIFT |
>  val << GRC_CODE_SLOW_SHIFT |
>  val;
> @@ -568,7 +569,7 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
> *dev_priv,
>  "BXT_PORT_CL2CM_DW6(%d)", phy);
>  
>   if (phy_info->rcomp_phy != -1) {
> - u32 grc_code = dev_priv->bxt_phy_grc;
> + u32 grc_code = dev_priv->display.state.bxt_phy_grc;
>  
>   grc_code = grc_code << GRC_CODE_FAST_SHIFT |
>  grc_code << GRC_CODE_SLOW_SHIFT |
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
> b/drivers/gpu/drm/i915/display/intel_dpll.c
> index c236aafe9be0..4e9c18be7e1f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll.c
> @@ -1910,7 +1910,7 @@ void chv_enable_pll(const struct intel_crtc_state 
> *crtc_state)
>   intel_de_write(dev_priv, DPLL_MD(PIPE_B),
>  crtc_state->dpll_hw_state.dpll_md);
>   intel_de_write(dev_priv, CBR4_VLV, 0);
> - dev_priv->chv_dpll_md[pipe] = crtc_state->dpll_hw_state.dpll_md;
> + dev_priv->display.

[Intel-gfx] ✓ Fi.CI.IGT: success for Add new CDCLK step for RPL-U (rev5)

2023-01-17 Thread Patchwork
== Series Details ==

Series: Add new CDCLK step for RPL-U (rev5)
URL   : https://patchwork.freedesktop.org/series/111472/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12589_full -> Patchwork_111472v5_full


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/index.html

Participating hosts (12 -> 10)
--

  Additional (1): shard-tglu-9 
  Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 

New tests
-

  New tests have been introduced between CI_DRM_12589_full and 
Patchwork_111472v5_full:

### New IGT tests (128) ###

  * igt@gem_ctx_engines@independent@bcs0:
- Statuses : 4 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_engines@independent@rcs0:
- Statuses : 4 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_engines@independent@vcs0:
- Statuses : 4 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_engines@independent@vcs1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * igt@gem_ctx_engines@independent@vecs0:
- Statuses : 4 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_async@forked-writes:
- Statuses :
- Exec time: [None] s

  * igt@gem_exec_async@forked-writes@bcs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_async@forked-writes@rcs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_async@forked-writes@vcs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_async@forked-writes@vcs1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_async@forked-writes@vecs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_balancer@fairslice:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_balancer@nohangcheck:
- Statuses : 4 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_balancer@noheartbeat:
- Statuses : 1 fail(s) 2 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_balancer@persistence:
- Statuses : 4 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_balancer@sequential:
- Statuses : 4 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_capture@capture@bcs0-lmem0:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_capture@capture@rcs0-lmem0:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_capture@capture@vcs0-lmem0:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_capture@capture@vcs1-lmem0:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_capture@capture@vecs0-lmem0:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_create@legacy:
- Statuses :
- Exec time: [None] s

  * igt@gem_exec_fair@basic-deadline:
- Statuses : 2 fail(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-flow:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-flow@rcs0:
- Statuses : 3 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none-rrul:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- Statuses : 3 fail(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none-share:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none-share@rcs0:
- Statuses : 3 fail(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none-solo:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- Statuses : 3 fail(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none-vip:
- Statuses :
- Exec time: [None] s

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- Statuses : 3 fail(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none@bcs0:
- Statuses : 2 fail(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none@rcs0:
- Statuses : 3 fail(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none@vcs0:
- Statuses : 2 fail(s) 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none@vcs1:
- Statuses : 1 fail(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-none@vecs0:
- Statuses : 2 fail(s) 1 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-pace:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-pace-share:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-pace-solo:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- Statuses : 2 fail(s)
- Exec time: [0.0] s

  * igt@gem_exec_fair@basic-pace@bcs0:
- Statuses : 2 fail(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@gem_exec_fai

Re: [Intel-gfx] [PATCH 1/2] drm/print: Add drm_dbg_ratelimited

2023-01-17 Thread Sam Ravnborg
Hi Nirmoy

On Tue, Jan 17, 2023 at 12:53:49PM +0100, Nirmoy Das wrote:
> Add a function for ratelimitted debug print.
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Reviewed-by: Matthew Auld 
> Signed-off-by: Nirmoy Das 

Thanks for adding this.
The patch as-is is:
Reviewed-by: Sam Ravnborg 

It would have been nice to start adding kernel-doc to the
non-deprecated logging functions. But as everyone else is missing this,
it is OK that we miss it here.

A couple of nice follow-up patches would be to introduce a KMS variant
and replace the only user of DRM_DEBUG_KMS_RATELIMITED with the new
variant and remove the old one.

And maybe even update the remaining *ERROR_RATELIMITED users to a new
variant - and drop the deprecated ones.

Sam

> ---
>  include/drm/drm_print.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index a44fb7ef257f..1d839f507319 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...);
>   drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## 
> __VA_ARGS__);   \
>  })
>  
> +#define drm_dbg_ratelimited(drm, fmt, ...) \
> + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__)
> +
>  #define drm_dbg_kms_ratelimited(drm, fmt, ...) \
>   __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
>  
> -- 
> 2.39.0


Re: [Intel-gfx] [PATCH 1/2] drm/print: Add drm_dbg_ratelimited

2023-01-17 Thread Das, Nirmoy

Hi Sam,

On 1/17/2023 3:49 PM, Sam Ravnborg wrote:

Hi Nirmoy

On Tue, Jan 17, 2023 at 12:53:49PM +0100, Nirmoy Das wrote:

Add a function for ratelimitted debug print.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Reviewed-by: Matthew Auld 
Signed-off-by: Nirmoy Das 

Thanks for adding this.
The patch as-is is:
Reviewed-by: Sam Ravnborg 

It would have been nice to start adding kernel-doc to the
non-deprecated logging functions. But as everyone else is missing this,
it is OK that we miss it here.

A couple of nice follow-up patches would be to introduce a KMS variant
and replace the only user of DRM_DEBUG_KMS_RATELIMITED with the new
variant and remove the old one.

And maybe even update the remaining *ERROR_RATELIMITED users to a new
variant - and drop the deprecated ones.



Thanks for reviewing this. I can definitely work on your suggested 
follow-up patches.


Nirmoy



Sam


---
  include/drm/drm_print.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..1d839f507319 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -602,6 +602,9 @@ void __drm_err(const char *format, ...);
drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## 
__VA_ARGS__);\
  })
  
+#define drm_dbg_ratelimited(drm, fmt, ...) \

+   __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__)
+
  #define drm_dbg_kms_ratelimited(drm, fmt, ...) \
__DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
  
--

2.39.0


[Intel-gfx] [PATCH 3/3] drm/i915: move chv_dpll_md and bxt_phy_grc to display sub-struct under state

2023-01-17 Thread Jani Nikula
Move the display related members to the struct drm_i915_private display
sub-struct. Put them under "state", as they are related to storing
values that aren't readable from the hardware, to appease the state
checker.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_display_core.h | 10 ++
 drivers/gpu/drm/i915/display/intel_dpio_phy.c |  9 +
 drivers/gpu/drm/i915/display/intel_dpll.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  8 
 5 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 734e8e613f8e..419537a79255 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3291,7 +3291,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
if (DISPLAY_VER(dev_priv) >= 4) {
/* No way to read it out on pipes B and C */
if (IS_CHERRYVIEW(dev_priv) && crtc->pipe != PIPE_A)
-   tmp = dev_priv->chv_dpll_md[crtc->pipe];
+   tmp = dev_priv->display.state.chv_dpll_md[crtc->pipe];
else
tmp = intel_de_read(dev_priv, DPLL_MD(crtc->pipe));
pipe_config->pixel_multiplier =
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index c0eb753112d5..24c792d44b8f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -441,6 +441,16 @@ struct intel_display {
u8 phy_failed_calibration;
} snps;
 
+   struct {
+   /*
+* Shadows for CHV DPLL_MD regs to keep the state
+* checker somewhat working in the presence hardware
+* crappiness (can't read out DPLL_MD for pipes B & C).
+*/
+   u32 chv_dpll_md[I915_MAX_PIPES];
+   u32 bxt_phy_grc;
+   } state;
+
struct {
/* ordered wq for modesets */
struct workqueue_struct *modeset;
diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
index 7eb7440b3180..565c06de2432 100644
--- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
@@ -376,7 +376,7 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
*dev_priv,
if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
/* Still read out the GRC value for state verification */
if (phy_info->rcomp_phy != -1)
-   dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, phy);
+   dev_priv->display.state.bxt_phy_grc = 
bxt_get_grc(dev_priv, phy);
 
if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
drm_dbg(&dev_priv->drm, "DDI PHY %d already enabled, "
@@ -442,8 +442,9 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
*dev_priv,
 * the corresponding calibrated value from PHY1, and disable
 * the automatic calibration on PHY0.
 */
-   val = dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv,
- phy_info->rcomp_phy);
+   val = bxt_get_grc(dev_priv, phy_info->rcomp_phy);
+   dev_priv->display.state.bxt_phy_grc = val;
+
grc_code = val << GRC_CODE_FAST_SHIFT |
   val << GRC_CODE_SLOW_SHIFT |
   val;
@@ -568,7 +569,7 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv,
   "BXT_PORT_CL2CM_DW6(%d)", phy);
 
if (phy_info->rcomp_phy != -1) {
-   u32 grc_code = dev_priv->bxt_phy_grc;
+   u32 grc_code = dev_priv->display.state.bxt_phy_grc;
 
grc_code = grc_code << GRC_CODE_FAST_SHIFT |
   grc_code << GRC_CODE_SLOW_SHIFT |
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index c236aafe9be0..4e9c18be7e1f 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1910,7 +1910,7 @@ void chv_enable_pll(const struct intel_crtc_state 
*crtc_state)
intel_de_write(dev_priv, DPLL_MD(PIPE_B),
   crtc_state->dpll_hw_state.dpll_md);
intel_de_write(dev_priv, CBR4_VLV, 0);
-   dev_priv->chv_dpll_md[pipe] = crtc_state->dpll_hw_state.dpll_md;
+   dev_priv->display.state.chv_dpll_md[pipe] = 
crtc_state->dpll_hw_state.dpll_md;
 
/*
 * DPLLB VGA mode also seems to cause problems.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i9

[Intel-gfx] [PATCH 2/3] drm/i915: move pch_ssc_use to display sub-struct under dpll

2023-01-17 Thread Jani Nikula
Move the display related member to the struct drm_i915_private display
sub-struct.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_core.h |  5 +
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  4 ++--
 drivers/gpu/drm/i915/display/intel_pch_refclk.c   | 10 +-
 drivers/gpu/drm/i915/i915_drv.h   |  2 --
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 2e85dd0ef4b5..c0eb753112d5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -122,6 +122,11 @@ struct intel_dpll {
int nssc;
int ssc;
} ref_clks;
+
+   /*
+* Bitmask of PLLs using the PCH SSC, indexed using enum intel_dpll_id.
+*/
+   u8 pch_ssc_use;
 };
 
 struct intel_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 1974eb580ed1..380368eff31a 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -618,7 +618,7 @@ static void hsw_ddi_wrpll_disable(struct drm_i915_private 
*dev_priv,
 * Try to set up the PCH reference clock once all DPLLs
 * that depend on it have been shut down.
 */
-   if (dev_priv->pch_ssc_use & BIT(id))
+   if (dev_priv->display.dpll.pch_ssc_use & BIT(id))
intel_init_pch_refclk(dev_priv);
 }
 
@@ -636,7 +636,7 @@ static void hsw_ddi_spll_disable(struct drm_i915_private 
*dev_priv,
 * Try to set up the PCH reference clock once all DPLLs
 * that depend on it have been shut down.
 */
-   if (dev_priv->pch_ssc_use & BIT(id))
+   if (dev_priv->display.dpll.pch_ssc_use & BIT(id))
intel_init_pch_refclk(dev_priv);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_pch_refclk.c 
b/drivers/gpu/drm/i915/display/intel_pch_refclk.c
index 08a94365b7d1..3657b2940702 100644
--- a/drivers/gpu/drm/i915/display/intel_pch_refclk.c
+++ b/drivers/gpu/drm/i915/display/intel_pch_refclk.c
@@ -467,24 +467,24 @@ static void lpt_init_pch_refclk(struct drm_i915_private 
*dev_priv)
 * clock hierarchy. That would also allow us to do
 * clock bending finally.
 */
-   dev_priv->pch_ssc_use = 0;
+   dev_priv->display.dpll.pch_ssc_use = 0;
 
if (spll_uses_pch_ssc(dev_priv)) {
drm_dbg_kms(&dev_priv->drm, "SPLL using PCH SSC\n");
-   dev_priv->pch_ssc_use |= BIT(DPLL_ID_SPLL);
+   dev_priv->display.dpll.pch_ssc_use |= BIT(DPLL_ID_SPLL);
}
 
if (wrpll_uses_pch_ssc(dev_priv, DPLL_ID_WRPLL1)) {
drm_dbg_kms(&dev_priv->drm, "WRPLL1 using PCH SSC\n");
-   dev_priv->pch_ssc_use |= BIT(DPLL_ID_WRPLL1);
+   dev_priv->display.dpll.pch_ssc_use |= BIT(DPLL_ID_WRPLL1);
}
 
if (wrpll_uses_pch_ssc(dev_priv, DPLL_ID_WRPLL2)) {
drm_dbg_kms(&dev_priv->drm, "WRPLL2 using PCH SSC\n");
-   dev_priv->pch_ssc_use |= BIT(DPLL_ID_WRPLL2);
+   dev_priv->display.dpll.pch_ssc_use |= BIT(DPLL_ID_WRPLL2);
}
 
-   if (dev_priv->pch_ssc_use)
+   if (dev_priv->display.dpll.pch_ssc_use)
return;
 
if (has_fdi) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 33da0f867a93..9ac80a45362f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -368,8 +368,6 @@ struct drm_i915_private {
 
struct intel_pxp *pxp;
 
-   u8 pch_ssc_use;
-
/* For i915gm/i945gm vblank irq workaround */
u8 vblank_enabled;
 
-- 
2.34.1



[Intel-gfx] [PATCH 1/3] drm/i915: move snps_phy_failed_calibration to display sub-struct under snps

2023-01-17 Thread Jani Nikula
Move the display related member to the struct drm_i915_private display
sub-struct.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_display_core.h | 8 
 drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 6 --
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1f5a471a0adf..0034a43f56e5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4323,7 +4323,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
enum port port)
}
 
if (intel_phy_is_snps(dev_priv, phy) &&
-   dev_priv->snps_phy_failed_calibration & BIT(phy)) {
+   dev_priv->display.snps.phy_failed_calibration & BIT(phy)) {
drm_dbg_kms(&dev_priv->drm,
"SNPS PHY %c failed to calibrate, proceeding 
anyway\n",
phy_name(phy));
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 57ddce3ba02b..2e85dd0ef4b5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -428,6 +428,14 @@ struct intel_display {
u32 block_time_us;
} sagv;
 
+   struct {
+   /*
+* DG2: Mask of PHYs that were not calibrated by the firmware
+* and should not be used.
+*/
+   u8 phy_failed_calibration;
+   } snps;
+
struct {
/* ordered wq for modesets */
struct workqueue_struct *modeset;
diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c 
b/drivers/gpu/drm/i915/display/intel_snps_phy.c
index 9494cfd45519..c65c771f5c46 100644
--- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
@@ -40,7 +40,7 @@ void intel_snps_phy_wait_for_calibration(struct 
drm_i915_private *i915)
 */
if (intel_de_wait_for_clear(i915, DG2_PHY_MISC(phy),
DG2_PHY_DP_TX_ACK_MASK, 25))
-   i915->snps_phy_failed_calibration |= BIT(phy);
+   i915->display.snps.phy_failed_calibration |= BIT(phy);
}
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48fd82722f12..33da0f867a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -375,12 +375,6 @@ struct drm_i915_private {
 
bool irq_enabled;
 
-   /*
-* DG2: Mask of PHYs that were not calibrated by the firmware
-* and should not be used.
-*/
-   u8 snps_phy_failed_calibration;
-
struct i915_pmu pmu;
 
struct i915_drm_clients clients;
-- 
2.34.1



[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: GMCH refactoring

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: GMCH refactoring
URL   : https://patchwork.freedesktop.org/series/112929/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12590 -> Patchwork_112929v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_112929v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_112929v1, 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_112929v1/index.html

Participating hosts (42 -> 44)
--

  Additional (3): fi-kbl-soraka fi-rkl-11600 fi-bsw-kefka 
  Missing(1): fi-snb-2520m 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_112929v1:

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-ctg-p8600:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/fi-ctg-p8600/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-ctg-p8600/igt@i915_module_l...@load.html

  
New tests
-

  New tests have been introduced between CI_DRM_12590 and Patchwork_112929v1:

### New IGT tests (1) ###

  * igt@gem_softpin@safe-alignment:
- Statuses : 43 pass(s)
- Exec time: [0.0] s

  

Known issues


  Here are the changes found in Patchwork_112929v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#7456])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271]) +15 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#3282])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#7561])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][11] ([i915#1886])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@ring_submission:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][12] ([i915#7640])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-kbl-soraka/igt@i915_selftest@live@ring_submission.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][13] ([i915#4817])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6:  NOTRUN -> [SKIP][14] ([i915#7828])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([i915#7828]) +7 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][16] ([i915#4103])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112929v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#109285] /

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Unwind hugepages to drop wakeref on error (rev3)

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Unwind hugepages to drop wakeref on error (rev3)
URL   : https://patchwork.freedesktop.org/series/112801/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12590 -> Patchwork_112801v3


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/index.html

Participating hosts (42 -> 43)
--

  Additional (2): fi-bsw-kefka fi-rkl-11600 
  Missing(1): fi-snb-2520m 

New tests
-

  New tests have been introduced between CI_DRM_12590 and Patchwork_112801v3:

### New IGT tests (1) ###

  * igt@gem_softpin@safe-alignment:
- Statuses : 42 pass(s)
- Exec time: [0.0] s

  

Known issues


  Here are the changes found in Patchwork_112801v3 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3282])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#7561])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][6] ([i915#4817])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6:  NOTRUN -> [SKIP][7] ([i915#7828])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#7828]) +7 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#4103])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([fdo#109285] / [i915#4098])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#1072]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4098])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka:   NOTRUN -> [SKIP][13] ([fdo#109271]) +26 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][16] ([i915#7229]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112801v3/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [INCOMPLETE][18] ([i915#4983]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/print: Add drm_dbg_ratelimited

2023-01-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/print: Add drm_dbg_ratelimited
URL   : https://patchwork.freedesktop.org/series/112925/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12590 -> Patchwork_112925v1


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/index.html

Participating hosts (42 -> 43)
--

  Additional (2): fi-bsw-kefka fi-rkl-11600 
  Missing(1): fi-snb-2520m 

New tests
-

  New tests have been introduced between CI_DRM_12590 and Patchwork_112925v1:

### New IGT tests (1) ###

  * igt@gem_softpin@safe-alignment:
- Statuses : 42 pass(s)
- Exec time: [0.0] s

  

Known issues


  Here are the changes found in Patchwork_112925v1 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#3282])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#7561])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][6] ([i915#4817])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6:  NOTRUN -> [SKIP][7] ([i915#7828])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#7828]) +7 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([i915#4103])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([fdo#109285] / [i915#4098])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#1072]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4098])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka:   NOTRUN -> [SKIP][13] ([fdo#109271]) +26 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [INCOMPLETE][16] ([i915#4983]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12590/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112925v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARN

Re: [Intel-gfx] [PATCH] drm/i915: remove a couple of superfluous i915_drm.h includes

2023-01-17 Thread Andi Shyti
Hi Jani,

On Tue, Jan 17, 2023 at 02:38:56PM +0200, Jani Nikula wrote:
> Remove a couple of unnecessary includes.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Andi Shyti 

Thanks,
Andi

> ---
>  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 1 -
>  drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  | 2 --
>  2 files changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c 
> b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
> index 4e2163a1aa46..0e3630103693 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
> @@ -6,7 +6,6 @@
>  #include "intel_ggtt_gmch.h"
>  
>  #include 
> -#include 
>  
>  #include 
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
> index 812c8bc7005e..64609d1b1c0f 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
> @@ -3,8 +3,6 @@
>   * Copyright(c) 2021-2022, Intel Corporation. All rights reserved.
>   */
>  
> -#include 
> -
>  #include "i915_drv.h"
>  
>  #include "gem/i915_gem_region.h"
> -- 
> 2.34.1


Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Unwind hugepages to drop wakeref on error

2023-01-17 Thread Andi Shyti
Hi Nirmoy,

On Tue, Jan 17, 2023 at 01:32:34PM +0100, Nirmoy Das wrote:
> From: Chris Wilson 
> 
> Make sure that upon error after we have acquired the wakeref we do
> release it again.
> 
> v2: add another missing "goto out_wf"(Andi).
> 
> Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
> Cc: Andi Shyti 
> Reviewed-by: Matthew Auld 
> Reviewed-by: Andrzej Hajda 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Nirmoy Das 

Reviewed-by: Andi Shyti 

Thanks,
Andi

> ---
>  drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
> b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> index c281b0ec9e05..defece0bcb81 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> @@ -1855,7 +1855,7 @@ static int igt_shrink_thp(void *arg)
>   I915_SHRINK_ACTIVE);
>   i915_vma_unpin(vma);
>   if (err)
> - goto out_put;
> + goto out_wf;
>  
>   /*
>* Now that the pages are *unpinned* shrinking should invoke
> @@ -1871,19 +1871,19 @@ static int igt_shrink_thp(void *arg)
>   pr_err("unexpected pages mismatch, should_swap=%s\n",
>  str_yes_no(should_swap));
>   err = -EINVAL;
> - goto out_put;
> + goto out_wf;
>   }
>  
>   if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {
>   pr_err("unexpected residual page-size bits, should_swap=%s\n",
>  str_yes_no(should_swap));
>   err = -EINVAL;
> - goto out_put;
> + goto out_wf;
>   }
>  
>   err = i915_vma_pin(vma, 0, 0, flags);
>   if (err)
> - goto out_put;
> + goto out_wf;
>  
>   while (n--) {
>   err = cpu_check(obj, n, 0xdeadbeaf);
> -- 
> 2.39.0


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ratelimit debug log in vm_fault_ttm

2023-01-17 Thread Andi Shyti
Hi Nirmoy,

On Tue, Jan 17, 2023 at 12:53:50PM +0100, Nirmoy Das wrote:
> Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
> dmesg spamming. Use ratelimit api to reduce log rate.
> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
> Cc: Matthew Auld 
> 
> Reviewed-by: Matthew Auld 
> Signed-off-by: Nirmoy Das 

Reviewed-by: Andi Shyti 

Thanks,
Andi

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 8cfed1bef629..25294ddbee46 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -1077,8 +1077,9 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
>   }
>  
>   if (err) {
> - drm_dbg(dev, "Unable to make resource CPU 
> accessible(err = %pe)\n",
> - ERR_PTR(err));
> + drm_dbg_ratelimited(dev,
> + "Unable to make resource CPU 
> accessible(err = %pe)\n",
> + ERR_PTR(err));
>   dma_resv_unlock(bo->base.resv);
>   ret = VM_FAULT_SIGBUS;
>   goto out_rpm;
> -- 
> 2.39.0


Re: [Intel-gfx] [PATCH 1/2] drm/print: Add drm_dbg_ratelimited

2023-01-17 Thread Andi Shyti
Hi,

can any of the DRM maintainers please check and eventually ack
this patch?

On Tue, Jan 17, 2023 at 12:53:49PM +0100, Nirmoy Das wrote:
> Add a function for ratelimitted debug print.
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Reviewed-by: Matthew Auld 
> Signed-off-by: Nirmoy Das 

Reviewed-by: Andi Shyti 

Thanks,
Andi

> ---
>  include/drm/drm_print.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index a44fb7ef257f..1d839f507319 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...);
>   drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## 
> __VA_ARGS__);   \
>  })
>  
> +#define drm_dbg_ratelimited(drm, fmt, ...) \
> + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__)
> +
>  #define drm_dbg_kms_ratelimited(drm, fmt, ...) \
>   __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
>  
> -- 
> 2.39.0


Re: [Intel-gfx] linux-next: duplicate patch in the kspp tree

2023-01-17 Thread Karol Herbst
On Tue, Jan 17, 2023 at 5:02 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> The following commit is also in the drm-misc tree as a different commit
> (but the same patch):
>
>   06b19f46455c ("drm/nouveau/fb/ga102: Replace zero-length array of trailing 
> structs with flex-array")
>

which branch? Because I just fetched the remote and don't have this
commit in my local repo

> This is commit
>
>   54d47689c6e3 ("drm/nouveau/fb/ga102: Replace zero-length array of trailing 
> structs with flex-array")
>
> in the drm-misc tree.
>
> --
> Cheers,
> Stephen Rothwell



[Intel-gfx] ✓ Fi.CI.BAT: success for Add new CDCLK step for RPL-U (rev5)

2023-01-17 Thread Patchwork
== Series Details ==

Series: Add new CDCLK step for RPL-U (rev5)
URL   : https://patchwork.freedesktop.org/series/111472/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12589 -> Patchwork_111472v5


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/index.html

Participating hosts (44 -> 42)
--

  Additional (1): fi-bsw-kefka 
  Missing(3): fi-kbl-soraka fi-rkl-11600 fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_111472v5 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@workarounds:
- bat-dg1-5:  [PASS][1] -> [DMESG-FAIL][2] ([i915#4983])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12589/bat-dg1-5/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/bat-dg1-5/igt@i915_selftest@l...@workarounds.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   NOTRUN -> [FAIL][3] ([i915#6298])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  * igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka:   NOTRUN -> [SKIP][4] ([fdo#109271]) +26 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html

  * igt@runner@aborted:
- bat-dg1-5:  NOTRUN -> [FAIL][5] ([i915#4312])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/bat-dg1-5/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][6] ([i915#7229]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12589/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-dg2-11}:   [INCOMPLETE][8] ([i915#7609]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12589/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_mocs:
- {bat-adln-1}:   [INCOMPLETE][10] ([i915#7884]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12589/bat-adln-1/igt@i915_selftest@live@gt_mocs.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/bat-adln-1/igt@i915_selftest@live@gt_mocs.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7443]: https://gitlab.freedesktop.org/drm/intel/issues/7443
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852
  [i915#7884]: https://gitlab.freedesktop.org/drm/intel/issues/7884


Build changes
-

  * Linux: CI_DRM_12589 -> Patchwork_111472v5

  CI-20190529: 20190529
  CI_DRM_12589: a29e440e749278f57cf6cb90d4e915016df200fd @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7121: aa16e81259f59734230d441905b9d0f605e4a4b5 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111472v5: a29e440e749278f57cf6cb90d4e915016df200fd @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

af0bcd906bfc drm/i915/display: Add 480 MHz CDCLK steps for RPL-U
f325ff4f9951 drm/i915: Add RPL-U sub platform

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111472v5/index.html


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GMCH refactoring

2023-01-17 Thread Patchwork
== Series Details ==

Series: drm/i915: GMCH refactoring
URL   : https://patchwork.freedesktop.org/series/112929/
State : warning

== Summary ==

Error: dim checkpatch failed
f3652809952f drm/i915: add gmch substruct to struct drm_i915_private
a0209e099f2c drm/i915/gmch: split out soc/intel_gmch
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:223: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#223: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 354 lines checked
5970e23a00b1 drm/i915/gmch: mass rename dev_priv to i915
ea0fced4d047 drm/i915/gmch: move VGA set state to GMCH code




[Intel-gfx] [PATCH] drm/i915: remove a couple of superfluous i915_drm.h includes

2023-01-17 Thread Jani Nikula
Remove a couple of unnecessary includes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 1 -
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
index 4e2163a1aa46..0e3630103693 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
@@ -6,7 +6,6 @@
 #include "intel_ggtt_gmch.h"
 
 #include 
-#include 
 
 #include 
 
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
index 812c8bc7005e..64609d1b1c0f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
@@ -3,8 +3,6 @@
  * Copyright(c) 2021-2022, Intel Corporation. All rights reserved.
  */
 
-#include 
-
 #include "i915_drv.h"
 
 #include "gem/i915_gem_region.h"
-- 
2.34.1



  1   2   >