[PATCH v5 12/19] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
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 | 578 ++
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, 643 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 8d76bb888dc3..6a801684d569 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,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 ..64251dc4cf91
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,578 @@
+// 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
[PATCH v5 10/19] drm/i915/vm_bind: Abstract out common execbuf functions
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.
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 | 666 ++
.../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++
3 files changed, 741 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 bfb59b8f8a43..8d76bb888dc3 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,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 ..4d1c9ce154b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
@@ -0,0 +1,666 @@
+// 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_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 engine
+ * @ce: the context
+ * @ww: optional locking contex
[PATCH v5 07/19] drm/i915/vm_bind: Add support to handle object evictions
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 | 31 +--
drivers/gpu/drm/i915/i915_vma.h | 10 ++
drivers/gpu/drm/i915/i915_vma_types.h | 8 +
6 files changed, 59 insertions(+), 2 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 8f788d7ea73c..863bd17c9253 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
@@ -85,6 +85,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 74c3557e5bc4..ebf8fc3a4603 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -290,6 +290,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 3d0a452567e4..b5a5b68adb32 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 0ffa24bc0954..249697ae1186 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -241,6 +241,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:
@@ -1681,6 +1682,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));
@@ -2042,6 +2051,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;
}
@@ -2054,8 +2073,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);
/*
@@ -2077,6 +2095,15 @@ static struct dma_fence *__i915_vma_unbind_async(struct
i915_vma *vma)
[PATCH v5 02/19] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()
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
[PATCH v5 13/19] drm/i915/vm_bind: Update i915_vma_verify_bind_complete()
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 eaa13e9ba966..aa4705246993 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -439,12 +439,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;
@@ -457,9 +470,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 1cadbf8fdedf..04770f8ba815 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -440,6 +440,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
[PATCH v5 00/19] drm/i915/vm_bind: Add VM_BIND functionality
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. TODOs: * Async VM_UNBIND support. * Optimizations. 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 v5 0/12] 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 Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (19): 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: 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 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| 516 +-- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++ .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 + .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ 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| 446 + drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + drivers/gpu/drm/i915/i915_driver.c| 4 + drivers/gpu/drm/i915/i915_drv.h | 2 + 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_sw_fence.c | 28 +- drivers/gpu/drm/i915/i915_sw_fence.h | 23 +- drivers/gpu/drm/i915/i915_vma.c | 134 ++- drivers/gpu/drm/i915/i915_vma.h | 67 +- drivers/gpu/drm/i915/i915_vma_types.h | 39 + include/uapi/drm/i915_drm.h | 275 +- 30 files changed, 2967 insertions(+), 542 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 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 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 -- 2.21.0.rc0.32.g243a4c7e27
[PATCH v5 04/19] drm/i915/vm_bind: Add support to create persistent vma
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 c39488eb9eeb..529d97318f00 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -109,7 +109,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;
@@ -196,6 +197,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) {
@@ -220,6 +224,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
@@ -299,7 +304,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 aecd9c64486b..c5378ec2f70a 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)
@@ -138,6 +142,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);
@@ -164,7 +178,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 ec0f6c9f57d0..3144d71a0c3e 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i9
[PATCH v5 03/19] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
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 33673fe7ee0a..5c6e396ab74d 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 6b9ecff42bb5..db3dd0e285c5 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
[PATCH v5 17/19] drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts
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.
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 76c6419b7ae0..9a7eaa574966 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
[PATCH v5 18/19] drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode
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 9a7eaa574966..072efb32892c 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 50648ab9214a..ae66fdd4bce9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -178,6 +178,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 d7b8eb9d4117..481590dffbce 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 342c8ca6414e..f45b3c684bcf 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -175,6 +175,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_PERF_REVISION:
value = i915_perf_ioctl_version();
break;
+ case I915_PARAM_VM_BIND_VERSION:
+ value = HAS_VM_BIND(i915);
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_d
[PATCH v5 06/19] drm/i915/vm_bind: Support for VM private BOs
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 793345cbf99e..76c6419b7ae0 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 5c6e396ab74d..62648341780b 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
[PATCH v5 09/19] drm/i915/vm_bind: Add out fence support
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.
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| 93 +++
drivers/gpu/drm/i915/i915_vma.c | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
include/uapi/drm/i915_drm.h | 49 +-
5 files changed, 157 insertions(+), 3 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 863bd17c9253..fca6d6eb9ef8 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"
@@ -100,6 +102,76 @@ 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_DEBUG("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)
{
@@ -205,6 +277,10 @@ 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)
+ ret = -EINVAL;
+
obj = i915_gem_object_lookup(file, va->handle);
if (!obj)
return -ENOENT;
@@ -237,6 +313,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
goto unlock_vm;
}
+ if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
+ ret = i915_vm_bind_add_fence(file
[PATCH v5 16/19] drm/i915/vm_bind: userptr dma-resv changes
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
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_types.h | 2 +
6 files changed, 124 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 d91c2e96cd0f..895d4f0a2647 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);
+ }
+#endif
+ if (unlikely(err))
+ goto err_skip;
+
/* Unconditionally flush any chipset
[PATCH v5 11/19] drm/i915/vm_bind: Use common execbuf functions in execbuf path
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| 507 ++
1 file changed, 38 insertions(+), 469 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 43f29acfbec9..749c3c80e02d 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_trace.h"
@@ -235,13 +236,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 */
@@ -2446,164 +2440,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
Re: [PATCH 00/22] Fallback to native backlight
On 2022/10/25 3:11, Jani Nikula wrote: On Tue, 25 Oct 2022, Akihiko Odaki wrote: That aside, the first patch in this series can be applied without the later patches so you may have a look at it. It's fine if you don't merge it though since it does not fix really a pragmatic bug as its message says. I think it's problematic because it needlessly ties i915 backlight operation to existence of backlight devices that may not be related to Intel GPU at all. The direction should be multiple supported backlight devices, across GPUs and connectors, but only one per display. BR, Jani. Unfortunately it is the current situation (even without this patch), and this patch is not meant to fix the particular issue. This patch replaces the following expression: acpi_video_get_backlight_type() == acpi_backlight_native As you can see, acpi_video_get_backlight_type() doesn't take a parameter which represents the backlight currently being operated. The problem is known and documented in "Brightness handling on devices with multiple internal panels" section of Documentation/gpu/todo.rst. The exiting solution is based on the assumption that no device with i915 and multiple internal backlights. Regards, Akihiko Odaki
[PATCH v5 01/19] drm/i915/vm_bind: Expose vm lookup function
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 1e29b1e6d186..793345cbf99e 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
[PATCH v5 14/19] drm/i915/vm_bind: Expose i915_request_await_bind()
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 aa4705246993..f73955aef16a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1888,18 +1888,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 04770f8ba815..737ef310d046 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -54,6 +54,22 @@ void i915_vma_unpin_and_release(struct i915_vma **p_vma,
unsigned int flags);
/* do not reserve memory to prevent deadlocks */
#define __EXEC_OBJECT_NO_RESERVE BIT(31)
+/**
+ * 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
[PATCH v5 08/19] drm/i915/vm_bind: Support persistent vma activeness tracking
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.
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..f4a3fc54fe66 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)
+{
+ int 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 8c2f57eb5dda..a5bbdc59d9df 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -51,4 +51,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 249697ae1186..04abdb92c2b2 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -420,6 +420,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)
{
@@ -1882,6 +1900,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);
@@ -2091,6 +2111,14 @@ static struct dma_fence *__i915_vma_unbind_async(struct
i915_vma *vma)
return ERR_PTR(-EBUSY);
}
+ if (i915_vma_is_persistent(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);
drm_mm_remove_node(&vma->node); /* pairs with i915_vma_release() */
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
in
[PATCH v5 15/19] drm/i915/vm_bind: Handle persistent vmas in execbuf3
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 64251dc4cf91..d91c2e96cd0f 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
ast: resolutions that require single-buffering (due to VRAM limitations) are unavailable
Hi dri-devel, I have two machines with ASPEED GPU's (ast Linux driver). One machine is x86_64, running an ASRock Rack Tommy 90-SC02P1-00UBNZ GPU (AST2510 chipset) with KDE Plasma Wayland; the other is ppc64le, running an integrated AST2500 GPU with KDE Plasma X11. Both the AST2510 and AST2500 have 16 MiB VRAM according to lspci. Both ASPEED GPU's are advertised as supporting up to 1920x1200 resolution, but KDE only detects a maximum resolution of 1920x1080. Some additional information about this bug can be found at https://forums.raptorcs.com/index.php/topic,31.0.html . I believe this is a Linux bug, because it is solely dependent on the Linux version. The following Linux versions are confirmed to have the bug: Debian: 5.6.0-1 (ppc64el) Fedora: 5.6.0-1.fc33.x86_64 5.6.0-1.fc33.ppc64le 5.17.5-300.fc36.x86_64 5.18.6-200.fc36.ppc64le 6.1.0-0.rc0.20221007git4c86114194e6.5.fc38.ppc64le Whereas the following Linux versions are confirmed to work fine (max resolution detected by KDE is 1920x1200 as it should be, and that resolution works fine when selected): Debian: 5.5.0-2 (ppc64el) Fedora: 5.5.17-200.fc31.x86_64 5.5.17-200.fc31.ppc64le I believe the bug was introduced by Linux commit 9253f830c9166bfa6cc07d5ed59e174e9d5ec6ca, which adds a VRAM size check that assumes double-buffering. 1920x1080 resolution at 4 bytes per pixel with 2 buffers is 16.6 MB, while bumping that to 1920x1200 results in 18.4 MB. Since the VRAM size is 16 MiB == 16.8 MB, that explains the issue. Steps to reproduce: * Add a GPU that uses the ast driver, which supports 1920x1200 resolution and has 16 MiB VRAM. * Boot into KDE. * Go to KDE System Settings -> Display and Monitor -> Display Configuration. * Look at list of detected resolutions. * KDE will only detect up to 1920x1080 resolution. I'm attaching the output of "journalctl --no-hostname -k", although I'm doubtful that anything useful is in the log. I reported this bug to Fedora at https://bugzilla.redhat.com/show_bug.cgi?id=2136950 , and was directed to this mailing list. Happy to provide more details on request. (I'm not subscribed to this list, so please CC any replies to me.) Cheers, -- -Jeremy Rand Lead Application Engineer at Namecoin Oct 21 19:48:58 kernel: Linux version 5.17.5-300.fc36.x86_64 (mockbu...@bkernel01.iad2.fedoraproject.org) (gcc (GCC) 12.0.1 20220413 (Red Hat 12.0.1-0), GNU ld version 2.37-24.fc36) #1 SMP PREEMPT Thu Apr 28 15:51:30 UTC 2022 Oct 21 19:48:58 kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.17.5-300.fc36.x86_64 root=UUID=b220295a-382f-47da-affd-edeb013a9e56 ro rootflags=subvol=root rhgb quiet Oct 21 19:48:58 kernel: random: get_random_u32 called from bsp_init_amd+0x181/0x210 with crng_init=0 Oct 21 19:48:58 kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Oct 21 19:48:58 kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Oct 21 19:48:58 kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Oct 21 19:48:58 kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Oct 21 19:48:58 kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Oct 21 19:48:58 kernel: signal: max sigframe size: 1776 Oct 21 19:48:58 kernel: BIOS-provided physical RAM map: Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x-0x0009e7ff] usable Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x0009e800-0x0009] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x000e-0x000f] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x0010-0x3bd45fff] usable Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3bd46000-0x3bd75fff] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3bd76000-0x3c034fff] usable Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3c035000-0x3c0f0fff] ACPI NVS Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3c0f1000-0x3e116fff] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3e117000-0x3e117fff] usable Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3e118000-0x3e31dfff] ACPI NVS Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3e31e000-0x3e472fff] usable Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3e473000-0x3f02efff] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3f02f000-0x3f071fff] usable Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3f072000-0x3f7f0fff] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0x3f7f1000-0x3f7f] usable Oct 21 19:48:58 kernel: BIOS-e820: [mem 0xfec0-0xfec01fff] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0xfec1-0xfec10fff] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0xfed0-0xfed00fff] reserved Oct 21 19:48:58 kernel: BIOS-e820: [mem 0xfed4-0xfed44fff] reser
Re: [PATCH] drm/amdgpu: don't call drm_fb_helper_lastclose in lastclose()
Hi
Am 24.10.22 um 18:48 schrieb Alex Deucher:
On Mon, Oct 24, 2022 at 3:33 AM Thomas Zimmermann wrote:
Hi
Am 24.10.22 um 08:20 schrieb Quan, Evan:
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex
Deucher
Sent: Thursday, October 20, 2022 10:36 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Deucher, Alexander ; Thomas
Zimmermann
Subject: [PATCH] drm/amdgpu: don't call drm_fb_helper_lastclose in
lastclose()
It's used to restore the fbdev console, but as amdgpu uses
generic fbdev emulation, the console is being restored by the
DRM client helpers already. See the call to drm_client_dev_restore()
in drm_lastclose().
Fixes: 087451f372bf76 ("drm/amdgpu: use generic fb helpers instead of
setting up AMD own's.")
Cc: Thomas Zimmermann
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index fe23e09eec98..474b9f40f792 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1106,7 +1106,6 @@ int amdgpu_info_ioctl(struct drm_device *dev,
void *data, struct drm_file *filp)
*/
void amdgpu_driver_lastclose_kms(struct drm_device *dev)
{
-drm_fb_helper_lastclose(dev);
vga_switcheroo_process_delayed_switch();
}
Without the call to drm_fb_helper_lastclose(), the console emulation
will be restored by drm_client_dev_restore() from drm_lastclose(). [1]
It means that it's now changing order with the call to
vga_switcheroo_process_delay_switch(). Can this become a problem?
I looked at the other callers of that function. Most restore the console
before doing the switcheroo. Nouveau doesn't seem to care about the
console at all.
I don't know off hand. I suppose if the switch powered down the GPU
and then we tried to restore it's console state that would be a
problem, but it looks like vga_switchto_stage2() just powers down the
GPU without going through suspend so I'm not sure if this actually
worked correctly? What are the potential problems with calling
drm_fb_helper_lastclose twice?
It should do fbdev console modesetting twice; so no problem.
AFAIU calling vga switcheroo does nothing for devices without support.
So let's call vga_switcheroo_process_delayed_switch() at the very end of
drm_lastclose() and remove the amdgpu callback entirely. [1] This
should not be a problem and if, we can refactor the whole function.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_file.c#L468
Alex
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.0.3/source/drivers/gpu/drm/drm_file.c#L467
--
2.37.3
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH -next] drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but
dereferenced.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index cddf259875c0..405dd51521dc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -981,7 +981,8 @@ static vm_fault_t svm_migrate_to_ram(struct vm_fault *vmf)
out_mmput:
mmput(mm);
- pr_debug("CPU fault svms 0x%p address 0x%lx done\n", &p->svms, addr);
+ if (p)
+ pr_debug("CPU fault svms 0x%p address 0x%lx done\n", &p->svms,
addr);
return r ? VM_FAULT_SIGBUS : 0;
}
--
2.20.1.7.g153144c
Re: [PATCH v8] drm: Add initial ci/ subdirectory
On Fri, 9 Sept 2022 at 19:18, Daniel Stone wrote: > > Hi, > > On Fri, 9 Sept 2022 at 15:15, Tomeu Vizoso wrote: >> >> Also include a configuration file that points to the out-of-tree CI >> scripts. > > > I think this para is outdated given ... > >> v8: >> - Move all files specific to testing the kernel into the kernel tree >> (thus I have dropped the r-bs I had collected so far) >> - Uprev Gitlab CI infrastructure scripts to the latest from Mesa > > > But equally - and sorry for not jumping on the IRC (?) discussion as I was in > the middle of other stuff when it came up - I'm don't think this is the right > plan. > > Mesa having all its CI in-tree makes sense, because merges happen rapidly to > a single canonical tree. If the scripts need to be changed for whatever > reason, we can merge something in under an hour and everyone immediately gets > it. DRM is quite different though, given the forest of trees we have and the > long merge paths between them. I worry that merging the CI scripts in-tree - > especially for our initial attempt at it, when we're likely to need to make > quite a lot of changes before it settles down to become a stable system that > works for everyone - is shooting ourselves in the foot by limiting our > flexibility. So the entire "we have multiple trees" is why I want at least the gitlab-ci.yaml in tree, to force people to collaborate more on one thing instead of everyone rolling their own fun and hacking stuff up. And there's still tons of stuff outside in the separate repo, like the lab status so Linus doesn't get a silly history of lab flapping. Also wrt "developers don't get the update right away due to backmerge/pull delays", that's why integration trees like drm-tip or linux-next exist. So maybe initially we should make sure the ci patches go in through drm-misc, to maximize how many people see it. And even for mesa it's not fully automatic, you still have the rebase your branch if you picked a bad one for development (but yeah marge does that if the MR is ready). If you're doing kernel development on a linear tree instead of an integration tree, you're doing it very wrong. What I think everyone agrees on is that we probably get the split wrong and need to shuffle some files back&forth, and that's something we need to warn Linus about I guess. But somewhere we do need a split between internal and external stuff, and personally I'd like if at least the pure sw testing (build and virtual stuff) could be all in upstream. > Given that it's currently very dependent on fd.o infrastructure (published > ci-templates, the registry, the specific-tag runners for Collabora/CrOS DUTs, > etc), there isn't much of a portability gain in bringing the scripts into the > tree either. It's a good goal, but not where we are today. I don't think there's huge chances for any non-fdo gitlab anytime soon. Once we get there we might need to figure out how to standardize the hw lab interfacing, and if we have all the sw targets in upstream that should help with shuffling stuff around for a hypothetical LF gitlab CI (or whatever it is). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: ast: resolutions that require single-buffering (due to VRAM limitations) are unavailable
Hi Am 25.10.22 um 09:12 schrieb Jeremy Rand: Hi dri-devel, I have two machines with ASPEED GPU's (ast Linux driver). One machine is x86_64, running an ASRock Rack Tommy 90-SC02P1-00UBNZ GPU (AST2510 chipset) with KDE Plasma Wayland; the other is ppc64le, running an integrated AST2500 GPU with KDE Plasma X11. Both the AST2510 and AST2500 have 16 MiB VRAM according to lspci. Both ASPEED GPU's are advertised as supporting up to 1920x1200 resolution, but KDE only detects a maximum resolution of 1920x1080. Some additional information about this bug can be found at https://forums.raptorcs.com/index.php/topic,31.0.html . I believe this is a Linux bug, because it is solely dependent on the Linux version. The following Linux versions are confirmed to have the bug: Debian: 5.6.0-1 (ppc64el) Fedora: 5.6.0-1.fc33.x86_64 5.6.0-1.fc33.ppc64le 5.17.5-300.fc36.x86_64 5.18.6-200.fc36.ppc64le 6.1.0-0.rc0.20221007git4c86114194e6.5.fc38.ppc64le Whereas the following Linux versions are confirmed to work fine (max resolution detected by KDE is 1920x1200 as it should be, and that resolution works fine when selected): Debian: 5.5.0-2 (ppc64el) Fedora: 5.5.17-200.fc31.x86_64 5.5.17-200.fc31.ppc64le I believe the bug was introduced by Linux commit 9253f830c9166bfa6cc07d5ed59e174e9d5ec6ca, which adds a VRAM size check that assumes double-buffering. 1920x1080 resolution at 4 bytes per pixel with 2 buffers is 16.6 MB, while bumping that to 1920x1200 results in 18.4 MB. Since the VRAM size is 16 MiB == 16.8 MB, that explains the issue. Thanks for reporting. It's been a known issue for a while. But in the most recent devel tree, we have replaced ast memory management, so that it can now use the full vram size for scanout buffers. See https://cgit.freedesktop.org/drm/drm-tip/commit/drivers/gpu/drm/ast/ast_mode.c?id=f2fa5a99ca81ce1056539e83c705f3d6bec62e31 To test, get the latest drm-tip from git://anongit.freedesktop.org/drm/drm-tip and try on your machine. The updated driver should become available in Linux v6.3. Best regards Thomas Steps to reproduce: * Add a GPU that uses the ast driver, which supports 1920x1200 resolution and has 16 MiB VRAM. * Boot into KDE. * Go to KDE System Settings -> Display and Monitor -> Display Configuration. * Look at list of detected resolutions. * KDE will only detect up to 1920x1080 resolution. I'm attaching the output of "journalctl --no-hostname -k", although I'm doubtful that anything useful is in the log. I reported this bug to Fedora at https://bugzilla.redhat.com/show_bug.cgi?id=2136950 , and was directed to this mailing list. Happy to provide more details on request. (I'm not subscribed to this list, so please CC any replies to me.) Cheers, -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[airlied:01.01-gsp-rm 132/180] drivers/gpu/drm/nouveau/nouveau_connector.c:1218:30: warning: unused variable 'aux'
tree: git://people.freedesktop.org/~airlied/linux.git 01.01-gsp-rm
head: 6be95d5e52818808565790c5ee3fd5569263bd36
commit: beea5ab213b28f7abf7c3405439ac9abcd1b8415 [132/180] drm/nouveau/disp:
add output aux xfer method
config: i386-allyesconfig (attached as .config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
git remote add airlied git://people.freedesktop.org/~airlied/linux.git
git fetch --no-tags airlied 01.01-gsp-rm
git checkout beea5ab213b28f7abf7c3405439ac9abcd1b8415
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/nouveau/nouveau_connector.c: In function
'nouveau_connector_aux_xfer':
>> drivers/gpu/drm/nouveau/nouveau_connector.c:1218:30: warning: unused
>> variable 'aux' [-Wunused-variable]
1218 | struct nvkm_i2c_aux *aux;
| ^~~
vim +/aux +1218 drivers/gpu/drm/nouveau/nouveau_connector.c
4f47643dbb4c34 Ben Skeggs 2013-02-03 1211
8894f4919bc43f Ben Skeggs 2014-05-30 1212 static ssize_t
2aa5eac5163fed Ben Skeggs 2015-08-20 1213 nouveau_connector_aux_xfer(struct
drm_dp_aux *obj, struct drm_dp_aux_msg *msg)
8894f4919bc43f Ben Skeggs 2014-05-30 1214 {
8894f4919bc43f Ben Skeggs 2014-05-30 1215 struct nouveau_connector
*nv_connector =
2aa5eac5163fed Ben Skeggs 2015-08-20 1216 container_of(obj,
typeof(*nv_connector), aux);
8894f4919bc43f Ben Skeggs 2014-05-30 1217 struct nouveau_encoder
*nv_encoder;
2aa5eac5163fed Ben Skeggs 2015-08-20 @1218 struct nvkm_i2c_aux *aux;
1af5c410cc0cae Ben Skeggs 2017-03-01 1219 u8 size = msg->size;
8894f4919bc43f Ben Skeggs 2014-05-30 1220 int ret;
8894f4919bc43f Ben Skeggs 2014-05-30 1221
860b3f587f0d6d Ben Skeggs 2022-10-13 1222 nv_encoder =
find_encoder(&nv_connector->base, NVIF_OUTP_DP);
beea5ab213b28f Ben Skeggs 2022-10-13 1223 if (!nv_encoder)
8894f4919bc43f Ben Skeggs 2014-05-30 1224 return -ENODEV;
8894f4919bc43f Ben Skeggs 2014-05-30 1225 if (WARN_ON(msg->size > 16))
8894f4919bc43f Ben Skeggs 2014-05-30 1226 return -E2BIG;
8894f4919bc43f Ben Skeggs 2014-05-30 1227
beea5ab213b28f Ben Skeggs 2022-10-13 1228 ret =
nvif_outp_dp_aux_xfer(&nv_encoder->outp,
beea5ab213b28f Ben Skeggs 2022-10-13 1229
msg->request, &size, msg->address, msg->buffer);
8894f4919bc43f Ben Skeggs 2014-05-30 1230 if (ret >= 0) {
8894f4919bc43f Ben Skeggs 2014-05-30 1231 msg->reply = ret;
1af5c410cc0cae Ben Skeggs 2017-03-01 1232 return size;
8894f4919bc43f Ben Skeggs 2014-05-30 1233 }
8894f4919bc43f Ben Skeggs 2014-05-30 1234
8894f4919bc43f Ben Skeggs 2014-05-30 1235 return ret;
8894f4919bc43f Ben Skeggs 2014-05-30 1236 }
8894f4919bc43f Ben Skeggs 2014-05-30 1237
:: The code at line 1218 was first introduced by commit
:: 2aa5eac5163fedf09f2d61992cb5ea4d75bec9db drm/nouveau/i2c: transition
pad/ports away from being based on nvkm_object
:: TO: Ben Skeggs
:: CC: Ben Skeggs
--
0-DAY CI Kernel Test Service
https://01.org/lkp
.config.gz
Description: application/gzip
Re: [Regression] CPU stalls and eventually causes a complete system freeze with 6.0.3 due to "video/aperture: Disable and unregister sysfb devices via aperture helpers"
Hi Andreas
Am 24.10.22 um 18:19 schrieb Andreas Thalhammer:
Am 24.10.22 um 13:31 schrieb Thomas Zimmermann:
Hi
Am 24.10.22 um 13:27 schrieb Greg KH:
On Mon, Oct 24, 2022 at 12:41:43PM +0200, Thorsten Leemhuis wrote:
Hi! Thx for the reply.
On 24.10.22 12:26, Thomas Zimmermann wrote:
Am 23.10.22 um 10:04 schrieb Thorsten Leemhuis:
I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developer don't keep an eye on it, I decided to forward it by
mail. Quoting from
https://bugzilla.kernel.org/show_bug.cgi?id=216616 :
Andreas 2022-10-22 14:25:32 UTC
Created attachment 303074 [details]
dmesg
I've looked at the kernel log and found that simpledrm has been loaded
*after* amdgpu, which should never happen. The problematic patch has
been taken from a long list of refactoring work on this code. No
wonder
that it doesn't work as expected.
Please cherry-pick commit 9d69ef183815 ("fbdev/core: Remove
remove_conflicting_pci_framebuffers()") into the 6.0 stable branch and
report on the results. It should fix the problem.
Greg, is that enough for you to pick this up? Or do you want Andreas to
test first if it really fixes the reported problem?
This should be good enough. If this does NOT fix the issue, please let
me know.
Thanks a lot. I think I can provided a dedicated fix if the proposed
commit doesn't work.
Best regards
Thomas
thanks,
greg k-h
Thanks... In short: the additional patch did NOT fix the problem.
Yeah, it's also part of a larger changeset. But I wouldn't want to
backport all those changes either.
Attached is a simple patch for linux-stable that adds the necessary fix.
If this still doesn't work, we should probably revert the problematic patch.
Please test the patch and let me know if it works.
Best regards
Thomas
I don't use git and I don't know how to /cherry-pick commit/
9d69ef183815, but I found the patch here:
https://patchwork.freedesktop.org/patch/494609/
I hope that's the right one. I reintegrated
v2-07-11-video-aperture-Disable-and-unregister-sysfb-devices-via-aperture-helpers.patch
and also applied
v2-04-11-fbdev-core-Remove-remove_conflicting_pci_framebuffers.patch,
did a "make mrproper" and thereafter compiled a clean new 6.0.3 kernel
(same .config).
Now the system doesn't even boot to a console. The first boot got me to
a rcu_shed stall on CPUs/tasks, same as above, but this time with:
Workqueue: btrfs-cache btrfs_work_helper
I booted a second time with the same kernel, and it got stuck after
mounting the root btrfs filesystem (what looked like a total freeze, but
when it didn't show a rcu_stall message after ~2 min I got impatient and
wanted to see if I had just busted my root filesystem...)
I booted 6.0.2 and everything is fine. (I'm very glad! I definitely
should update my backup right away!)
I will try 6.1-rc1 next, bear with...
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
From ba55e238e64817a2369a267153a5b980683465a1 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 25 Oct 2022 09:38:44 +0200
Subject: [PATCH] video/aperture: Call sysfb_disable() before removing PCI
devices
Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
before removing PCI devices. Without, simpledrm can still bind to
simple-framebuffer devices after the hardware driver has taken over
the hardware. Both drivers interfere with each other and results are
undefined.
Reported modesetting errors are shown below.
snap
rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13- } 7 jiffies s: 165 root: 0x2000/.
rcu: blocking rcu_node structures (internal RCU debug):
Task dump for CPU 13:
task:X state:R running task stack:0 pid: 4242 ppid: 4228 flags:0x0008
Call Trace:
? commit_tail+0xd7/0x130
? drm_atomic_helper_commit+0x126/0x150
? drm_atomic_commit+0xa4/0xe0
? drm_plane_get_damage_clips.cold+0x1c/0x1c
? drm_atomic_helper_dirtyfb+0x19e/0x280
? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? drm_ioctl_kernel+0xc4/0x150
? drm_ioctl+0x246/0x3f0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? __x64_sys_ioctl+0x91/0xd0
? do_syscall_64+0x60/0xd0
? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
...
rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13- } 30 jiffies s: 169 root: 0x2000/.
rcu: blocking rcu_node structures (internal RCU debug):
Task dump for CPU 13:
task:X state:R running task stack:0 pid: 4242 ppid: 4228 flags:0x400e
Call Trace:
? memcpy_toio+0x76/0xc0
? memcpy_toio+0x1b/0xc0
? drm_fb_memcpy_toio+0x76/0xb0
? drm_fb_blit_toio+0x75/0x2b0
? simpledrm_simple_display_pipe_update+0x132/0x150
? drm_atomic_helper_commit_planes+0xb6/0x230
? drm_atomic_helper_commit_tail+0x44/0x80
? commit_tail+0xd7/0x130
? drm_atomic_helper_commit+0x126/0x150
? drm_atomic_comm
Re: [Regression] CPU stalls and eventually causes a complete system freeze with 6.0.3 due to "video/aperture: Disable and unregister sysfb devices via aperture helpers"
Am 25.10.22 um 10:16 schrieb Thomas Zimmermann:
Hi Andreas
Am 24.10.22 um 18:19 schrieb Andreas Thalhammer:
Am 24.10.22 um 13:31 schrieb Thomas Zimmermann:
Hi
Am 24.10.22 um 13:27 schrieb Greg KH:
On Mon, Oct 24, 2022 at 12:41:43PM +0200, Thorsten Leemhuis wrote:
Hi! Thx for the reply.
On 24.10.22 12:26, Thomas Zimmermann wrote:
Am 23.10.22 um 10:04 schrieb Thorsten Leemhuis:
I noticed a regression report in bugzilla.kernel.org. As many
(most?)
kernel developer don't keep an eye on it, I decided to forward it by
mail. Quoting from
https://bugzilla.kernel.org/show_bug.cgi?id=216616 :
Andreas 2022-10-22 14:25:32 UTC
Created attachment 303074 [details]
dmesg
I've looked at the kernel log and found that simpledrm has been
loaded
*after* amdgpu, which should never happen. The problematic patch has
been taken from a long list of refactoring work on this code. No
wonder
that it doesn't work as expected.
Please cherry-pick commit 9d69ef183815 ("fbdev/core: Remove
remove_conflicting_pci_framebuffers()") into the 6.0 stable branch
and
report on the results. It should fix the problem.
Greg, is that enough for you to pick this up? Or do you want
Andreas to
test first if it really fixes the reported problem?
This should be good enough. If this does NOT fix the issue, please let
me know.
Thanks a lot. I think I can provided a dedicated fix if the proposed
commit doesn't work.
Best regards
Thomas
thanks,
greg k-h
Thanks... In short: the additional patch did NOT fix the problem.
Yeah, it's also part of a larger changeset. But I wouldn't want to
backport all those changes either.
Attached is a simple patch for linux-stable that adds the necessary fix.
If this still doesn't work, we should probably revert the problematic
patch.
Please test the patch and let me know if it works.
Yes, this fixed the problem. I'm running 6.0.3 with your patch now, all
fine.
Thanks!
Andreas
Best regards
Thomas
I don't use git and I don't know how to /cherry-pick commit/
9d69ef183815, but I found the patch here:
https://patchwork.freedesktop.org/patch/494609/
I hope that's the right one. I reintegrated
v2-07-11-video-aperture-Disable-and-unregister-sysfb-devices-via-aperture-helpers.patch
and also applied
v2-04-11-fbdev-core-Remove-remove_conflicting_pci_framebuffers.patch,
did a "make mrproper" and thereafter compiled a clean new 6.0.3 kernel
(same .config).
Now the system doesn't even boot to a console. The first boot got me to
a rcu_shed stall on CPUs/tasks, same as above, but this time with:
Workqueue: btrfs-cache btrfs_work_helper
I booted a second time with the same kernel, and it got stuck after
mounting the root btrfs filesystem (what looked like a total freeze, but
when it didn't show a rcu_stall message after ~2 min I got impatient and
wanted to see if I had just busted my root filesystem...)
I booted 6.0.2 and everything is fine. (I'm very glad! I definitely
should update my backup right away!)
I will try 6.1-rc1 next, bear with...
Re: [Regression] CPU stalls and eventually causes a complete system freeze with 6.0.3 due to "video/aperture: Disable and unregister sysfb devices via aperture helpers"
Hi Am 25.10.22 um 10:45 schrieb Andreas Thalhammer: [...] Yeah, it's also part of a larger changeset. But I wouldn't want to backport all those changes either. Attached is a simple patch for linux-stable that adds the necessary fix. If this still doesn't work, we should probably revert the problematic patch. Please test the patch and let me know if it works. Yes, this fixed the problem. I'm running 6.0.3 with your patch now, all fine. Thanks a lot for testing. If Greg doesn't already pick up the patch from this discussion, I'll send it to stable soonish; adding your Tested-by tag. Best regards Thomas Thanks! Andreas Best regards Thomas I don't use git and I don't know how to /cherry-pick commit/ 9d69ef183815, but I found the patch here: https://patchwork.freedesktop.org/patch/494609/ I hope that's the right one. I reintegrated v2-07-11-video-aperture-Disable-and-unregister-sysfb-devices-via-aperture-helpers.patch and also applied v2-04-11-fbdev-core-Remove-remove_conflicting_pci_framebuffers.patch, did a "make mrproper" and thereafter compiled a clean new 6.0.3 kernel (same .config). Now the system doesn't even boot to a console. The first boot got me to a rcu_shed stall on CPUs/tasks, same as above, but this time with: Workqueue: btrfs-cache btrfs_work_helper I booted a second time with the same kernel, and it got stuck after mounting the root btrfs filesystem (what looked like a total freeze, but when it didn't show a rcu_stall message after ~2 min I got impatient and wanted to see if I had just busted my root filesystem...) I booted 6.0.2 and everything is fine. (I'm very glad! I definitely should update my backup right away!) I will try 6.1-rc1 next, bear with... -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[airlied:01.01-gsp-rm 87/180] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:213:68: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type
tree: git://people.freedesktop.org/~airlied/linux.git 01.01-gsp-rm
head: 6be95d5e52818808565790c5ee3fd5569263bd36
commit: e7be44d4385351aaf43f09786faa38d153722673 [87/180] drm/nouveau/acr: use
common falcon HS FW code for ACR FWs
config: microblaze-randconfig-r001-20221023 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add airlied git://people.freedesktop.org/~airlied/linux.git
git fetch --no-tags airlied 01.01-gsp-rm
git checkout e7be44d4385351aaf43f09786faa38d153722673
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=microblaze SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/nouveau/nvkm/core/firmware.c: In function
'nvkm_firmware_ctor':
>> drivers/gpu/drm/nouveau/nvkm/core/firmware.c:213:68: error: passing argument
>> 3 of 'dma_alloc_coherent' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
213 | fw->img = dma_alloc_coherent(fw->device->dev, len,
&fw->phys, GFP_KERNEL);
|
^
||
|
u64 * {aka long long unsigned int *}
In file included from arch/microblaze/include/asm/pci.h:14,
from include/linux/pci.h:1910,
from drivers/gpu/drm/nouveau/include/nvif/os.h:8,
from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4,
from drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4,
from drivers/gpu/drm/nouveau/nvkm/core/firmware.c:22:
include/linux/dma-mapping.h:426:29: note: expected 'dma_addr_t *' {aka
'unsigned int *'} but argument is of type 'u64 *' {aka 'long long unsigned int
*'}
426 | dma_addr_t *dma_handle, gfp_t gfp)
| ^~
cc1: some warnings being treated as errors
vim +/dma_alloc_coherent +213 drivers/gpu/drm/nouveau/nvkm/core/firmware.c
196
197 int
198 nvkm_firmware_ctor(const struct nvkm_firmware_func *func, const char
*name,
199 struct nvkm_device *device, const void *src, int
len, struct nvkm_firmware *fw)
200 {
201 fw->func = func;
202 fw->name = name;
203 fw->device = device;
204 fw->len = len;
205
206 switch (fw->func->type) {
207 case NVKM_FIRMWARE_IMG_RAM:
208 fw->img = kmemdup(src, fw->len, GFP_KERNEL);
209 break;
210 case NVKM_FIRMWARE_IMG_DMA:
211 len = ALIGN(fw->len, PAGE_SIZE);
212
> 213 fw->img = dma_alloc_coherent(fw->device->dev, len,
> &fw->phys, GFP_KERNEL);
--
0-DAY CI Kernel Test Service
https://01.org/lkp
.config.gz
Description: application/gzip
RE: [PATCH] video: fbdev: sis: use explicitly signed char
From: Jason A. Donenfeld
> Sent: 24 October 2022 17:29
> To: linux-ker...@vger.kernel.org
>
> With char becoming unsigned by default, and with `char` alone being
> ambiguous and based on architecture, signed chars need to be marked
> explicitly as such. This fixes warnings like:
>
...
> ---
> drivers/usb/misc/sisusbvga/sisusb_struct.h | 2 +-
> drivers/video/fbdev/sis/vstruct.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/misc/sisusbvga/sisusb_struct.h
> b/drivers/usb/misc/sisusbvga/sisusb_struct.h
> index 3df64d2a9d43..a86032a26d36 100644
> --- a/drivers/usb/misc/sisusbvga/sisusb_struct.h
> +++ b/drivers/usb/misc/sisusbvga/sisusb_struct.h
> @@ -91,7 +91,7 @@ struct SiS_Ext {
> unsigned char VB_ExtTVYFilterIndex;
> unsigned char VB_ExtTVYFilterIndexROM661;
> unsigned char REFindex;
> - char ROMMODEIDX661;
> + signed char ROMMODEIDX661;
Isn't the correct fix to use u8 and s8 ?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
[PATCH v2 1/2] drm/atomic-helper: Add {begin, end}_fb_access to plane helpers
Add {begin,end}_fb_access helpers to run at the beginning and end of
an atomic commit. The begin_fb_access helper aquires resources that
are necessary to perform the atomic commit. It it similar to prepare_fb,
except that the resources are to be released at the end of the commit.
Resources acquired by prepare_fb are held until after the next pageflip.
The end_fb_access helper performs the corresponding resource cleanup.
Atomic helpers call it with the new plane state. This is differnt from
cleanup_fb, which releases resources of the old plane state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_atomic_helper.c | 34 ++--
drivers/gpu/drm/drm_gem_atomic_helper.c | 19 ++-
drivers/gpu/drm/drm_simple_kms_helper.c | 26 +++
include/drm/drm_modeset_helper_vtables.h | 41 +++-
include/drm/drm_simple_kms_helper.h | 20
5 files changed, 126 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 1a586b3c454b4..d579fd8f7cb83 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2536,7 +2536,7 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
if (funcs->prepare_fb) {
ret = funcs->prepare_fb(plane, new_plane_state);
if (ret)
- goto fail;
+ goto fail_prepare_fb;
} else {
WARN_ON_ONCE(funcs->cleanup_fb);
@@ -2545,13 +2545,34 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
ret = drm_gem_plane_helper_prepare_fb(plane,
new_plane_state);
if (ret)
- goto fail;
+ goto fail_prepare_fb;
+ }
+ }
+
+ for_each_new_plane_in_state(state, plane, new_plane_state, i) {
+ const struct drm_plane_helper_funcs *funcs =
plane->helper_private;
+
+ if (funcs->begin_fb_access) {
+ ret = funcs->begin_fb_access(plane, new_plane_state);
+ if (ret)
+ goto fail_begin_fb_access;
}
}
return 0;
-fail:
+fail_begin_fb_access:
+ for_each_new_plane_in_state(state, plane, new_plane_state, j) {
+ const struct drm_plane_helper_funcs *funcs =
plane->helper_private;
+
+ if (j >= i)
+ continue;
+
+ if (funcs->end_fb_access)
+ funcs->end_fb_access(plane, new_plane_state);
+ }
+ i = j; /* set i to upper limit to cleanup all planes */
+fail_prepare_fb:
for_each_new_plane_in_state(state, plane, new_plane_state, j) {
const struct drm_plane_helper_funcs *funcs;
@@ -2827,6 +2848,13 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
struct drm_plane_state *old_plane_state, *new_plane_state;
int i;
+ for_each_oldnew_plane_in_state(old_state, plane, old_plane_state,
new_plane_state, i) {
+ const struct drm_plane_helper_funcs *funcs =
plane->helper_private;
+
+ if (funcs->end_fb_access)
+ funcs->end_fb_access(plane, new_plane_state);
+ }
+
for_each_oldnew_plane_in_state(old_state, plane, old_plane_state,
new_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
struct drm_plane_state *plane_state;
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index b6a0110eb64af..1de0a08afd86e 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -414,16 +414,14 @@ void drm_gem_cleanup_shadow_fb(struct drm_plane *plane,
struct drm_plane_state *
EXPORT_SYMBOL(drm_gem_cleanup_shadow_fb);
/**
- * drm_gem_simple_kms_prepare_shadow_fb - prepares shadow framebuffers
+ * drm_gem_simple_kms_begin_shadow_fb_access - prepares shadow framebuffers
for CPU access
* @pipe: the simple display pipe
* @plane_state: the plane state of type struct drm_shadow_plane_state
*
- * This function implements struct drm_simple_display_funcs.prepare_fb. It
- * maps all buffer objects of the plane's framebuffer into kernel address
- * space and stores them in struct drm_shadow_plane_state.map. The
- * framebuffer will be synchronized as part of the atomic commit.
+ * This function implements struct drm_simple_display_funcs.begin_fb_access.
*
- * See drm_gem_simple_kms_cleanup_shadow_fb() for cleanup.
+ * See drm_gem_begin_shadow_fb_access() for details and
+ * drm_gem_simple_kms_cleanup_shadow_fb() for cleanup.
*
* Returns:
* 0 on success, or a negative errno code otherwise.
@@ -436,14 +434,15 @@ int drm_gem_simple_kms_prepare_shadow_fb(struct
drm_simple_display
[PATCH v2 0/2] drm: Add new plane helpers to begin/end FB access
This patchset adds the callbacks begin_fb_access and end_fb_access
to struct drm_plane_helper_funcs. They provide hooks to acquire and
release resources that are only held during the commit. It adds
related simple-KMS helpers and converts shadow-plane helpers.
As resource allocation often can fail, we have to do this before an
atomic commit starts the update in order to handle the error. But
prepare_fb is only reverted after the next pageflip. We want to
reduce the time resources are held for a commit, which requires the
new hooks.
With this in place, move shadow-plane helpers' automatic vmap/vunmap
behind the new callbacks. The shadow-plane mapping is only required
during the atomic commit.
Tested with combinations of radeon, udl and simpledrm under X11, Weston
and Wayland-Gnome.
Thomas Zimmermann (2):
drm/atomic-helper: Add {begin,end}_fb_access to plane helpers
drm/gem: Implement shadow-plane {begin,end}_fb_access with vmap
drivers/gpu/drm/drm_atomic_helper.c | 34 ++--
drivers/gpu/drm/drm_gem_atomic_helper.c | 66 +++-
drivers/gpu/drm/drm_simple_kms_helper.c | 26 ++
include/drm/drm_gem_atomic_helper.h | 20 +++
include/drm/drm_modeset_helper_vtables.h | 41 ++-
include/drm/drm_simple_kms_helper.h | 20 +++
6 files changed, 157 insertions(+), 50 deletions(-)
base-commit: 746559738f1335241ea686566cb654847c20d7a4
--
2.38.0
[PATCH v2 2/2] drm/gem: Implement shadow-plane {begin, end}_fb_access with vmap
Move the vmap code for shadow-plane helpers from prepare_fb to
begin_fb_access helpers. Vunmap is now performed at the end of
the current pageflip, instead of the end of the following pageflip.
Reduces the duration of the mapping from while the framebuffer is
being displayed to just the atomic commit. This is safe as outside
of the pageflip, nothing should access the mapped buffer memory.
Unmapping the framebuffer BO memory early allows reduces address-space
consumption and possibly allows for evicting the memory pages.
The change is effectively a rename of prepare_fb and cleanup_fb
implementations, plus updates to the shadow-plane init macro. As
there's no longer a prepare_fb helper for shadow planes, atomic
helpers will call drm_gem_plane_helper_prepare_fb() automatically.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 47 +++--
include/drm/drm_gem_atomic_helper.h | 20 +--
2 files changed, 31 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index 1de0a08afd86e..e42800718f515 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -360,48 +360,43 @@ void drm_gem_reset_shadow_plane(struct drm_plane *plane)
EXPORT_SYMBOL(drm_gem_reset_shadow_plane);
/**
- * drm_gem_prepare_shadow_fb - prepares shadow framebuffers
+ * drm_gem_begin_shadow_fb_access - prepares shadow framebuffers for CPU access
* @plane: the plane
* @plane_state: the plane state of type struct drm_shadow_plane_state
*
- * This function implements struct &drm_plane_helper_funcs.prepare_fb. It
+ * This function implements struct &drm_plane_helper_funcs.begin_fb_access. It
* maps all buffer objects of the plane's framebuffer into kernel address
- * space and stores them in &struct drm_shadow_plane_state.map. The
- * framebuffer will be synchronized as part of the atomic commit.
+ * space and stores them in struct &drm_shadow_plane_state.map. The first data
+ * bytes are available in struct &drm_shadow_plane_state.data.
*
- * See drm_gem_cleanup_shadow_fb() for cleanup.
+ * See drm_gem_end_shadow_fb_access() for cleanup.
*
* Returns:
* 0 on success, or a negative errno code otherwise.
*/
-int drm_gem_prepare_shadow_fb(struct drm_plane *plane, struct drm_plane_state
*plane_state)
+int drm_gem_begin_shadow_fb_access(struct drm_plane *plane, struct
drm_plane_state *plane_state)
{
struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
- int ret;
if (!fb)
return 0;
- ret = drm_gem_plane_helper_prepare_fb(plane, plane_state);
- if (ret)
- return ret;
-
return drm_gem_fb_vmap(fb, shadow_plane_state->map,
shadow_plane_state->data);
}
-EXPORT_SYMBOL(drm_gem_prepare_shadow_fb);
+EXPORT_SYMBOL(drm_gem_begin_shadow_fb_access);
/**
- * drm_gem_cleanup_shadow_fb - releases shadow framebuffers
+ * drm_gem_end_shadow_fb_access - releases shadow framebuffers from CPU access
* @plane: the plane
* @plane_state: the plane state of type struct drm_shadow_plane_state
*
- * This function implements struct &drm_plane_helper_funcs.cleanup_fb.
- * This function unmaps all buffer objects of the plane's framebuffer.
+ * This function implements struct &drm_plane_helper_funcs.end_fb_access. It
+ * undoes all effects of drm_gem_begin_shadow_fb_access() in reverse order.
*
- * See drm_gem_prepare_shadow_fb() for more information.
+ * See drm_gem_begin_shadow_fb_access() for more information.
*/
-void drm_gem_cleanup_shadow_fb(struct drm_plane *plane, struct drm_plane_state
*plane_state)
+void drm_gem_end_shadow_fb_access(struct drm_plane *plane, struct
drm_plane_state *plane_state)
{
struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
@@ -411,7 +406,7 @@ void drm_gem_cleanup_shadow_fb(struct drm_plane *plane,
struct drm_plane_state *
drm_gem_fb_vunmap(fb, shadow_plane_state->map);
}
-EXPORT_SYMBOL(drm_gem_cleanup_shadow_fb);
+EXPORT_SYMBOL(drm_gem_end_shadow_fb_access);
/**
* drm_gem_simple_kms_begin_shadow_fb_access - prepares shadow framebuffers
for CPU access
@@ -426,12 +421,12 @@ EXPORT_SYMBOL(drm_gem_cleanup_shadow_fb);
* Returns:
* 0 on success, or a negative errno code otherwise.
*/
-int drm_gem_simple_kms_prepare_shadow_fb(struct drm_simple_display_pipe *pipe,
-struct drm_plane_state *plane_state)
+int drm_gem_simple_kms_begin_shadow_fb_access(struct drm_simple_display_pipe
*pipe,
+ struct drm_plane_state
*plane_state)
{
- return drm_gem_prepare_shadow_fb(&pipe->plane, plane_state);
+ return drm_gem_begin_shadow_fb_access(&pipe->plane, plane_state);
Re: [PATCH v2 0/8] Fix several device private page reference counting issues
On 9/28/22 14:01, Alistair Popple wrote: > This series aims to fix a number of page reference counting issues in > drivers dealing with device private ZONE_DEVICE pages. These result in > use-after-free type bugs, either from accessing a struct page which no > longer exists because it has been removed or accessing fields within the > struct page which are no longer valid because the page has been freed. > > During normal usage it is unlikely these will cause any problems. However > without these fixes it is possible to crash the kernel from userspace. > These crashes can be triggered either by unloading the kernel module or > unbinding the device from the driver prior to a userspace task exiting. In > modules such as Nouveau it is also possible to trigger some of these issues > by explicitly closing the device file-descriptor prior to the task exiting > and then accessing device private memory. Hi, as this series was noticed to create a CVE [1], do you think a stable backport is warranted? I think the "It is possible to launch the attack remotely." in [1] is incorrect though, right? It looks to me that patch 1 would be needed since the CONFIG_DEVICE_PRIVATE introduction, while the following few only to kernels with 27674ef6c73f (probably not so critical as that includes no LTS)? Thanks, Vlastimil [1] https://nvd.nist.gov/vuln/detail/CVE-2022-3523 > This involves some minor changes to both PowerPC and AMD GPU code. > Unfortunately I lack hardware to test either of those so any help there > would be appreciated. The changes mimic what is done in for both Nouveau > and hmm-tests though so I doubt they will cause problems. > > To: Andrew Morton > To: linux...@kvack.org > Cc: linux-ker...@vger.kernel.org > Cc: amd-...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > > Alistair Popple (8): > mm/memory.c: Fix race when faulting a device private page > mm: Free device private pages have zero refcount > mm/memremap.c: Take a pgmap reference on page allocation > mm/migrate_device.c: Refactor migrate_vma and migrate_deivce_coherent_page() > mm/migrate_device.c: Add migrate_device_range() > nouveau/dmem: Refactor nouveau_dmem_fault_copy_one() > nouveau/dmem: Evict device private memory during release > hmm-tests: Add test for migrate_device_range() > > arch/powerpc/kvm/book3s_hv_uvmem.c | 17 +- > drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 19 +- > drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 11 +- > drivers/gpu/drm/nouveau/nouveau_dmem.c | 108 +++ > include/linux/memremap.h | 1 +- > include/linux/migrate.h | 15 ++- > lib/test_hmm.c | 129 ++--- > lib/test_hmm_uapi.h | 1 +- > mm/memory.c | 16 +- > mm/memremap.c| 30 ++- > mm/migrate.c | 34 +-- > mm/migrate_device.c | 239 +--- > mm/page_alloc.c | 8 +- > tools/testing/selftests/vm/hmm-tests.c | 49 +- > 15 files changed, 516 insertions(+), 163 deletions(-) > > base-commit: 088b8aa537c2c767765f1c19b555f21ffe555786
Re: [Regression] CPU stalls and eventually causes a complete system freeze with 6.0.3 due to "video/aperture: Disable and unregister sysfb devices via aperture helpers"
On Tue, Oct 25, 2022 at 11:21:57AM +0200, Thomas Zimmermann wrote: > Hi > > Am 25.10.22 um 10:45 schrieb Andreas Thalhammer: > [...] > > > Yeah, it's also part of a larger changeset. But I wouldn't want to > > > backport all those changes either. > > > > > > Attached is a simple patch for linux-stable that adds the necessary fix. > > > If this still doesn't work, we should probably revert the problematic > > > patch. > > > > > > Please test the patch and let me know if it works. > > > > > > Yes, this fixed the problem. I'm running 6.0.3 with your patch now, all > > fine. > > Thanks a lot for testing. If Greg doesn't already pick up the patch from > this discussion, I'll send it to stable soonish; adding your Tested-by tag. Please send it as a real patch. thanks, greg k-h
Re: [PATCH v1] drm/scheduler: Set the FIFO scheduling policy as the default
Pushed to drm-misc-next. Christian. Am 24.10.22 um 23:26 schrieb Luben Tuikov: The currently default Round-Robin GPU scheduling can result in starvation of entities which have a large number of jobs, over entities which have a very small number of jobs (single digit). This can be illustrated in the following diagram, where jobs are alphabetized to show their chronological order of arrival, where job A is the oldest, B is the second oldest, and so on, to J, the most recent job to arrive. ---> entities j | H-F-A--E--I-- o | --G-B-J-- b | C s\/ D WLOG, assuming all jobs are "ready", then a R-R scheduling will execute them in the following order (a slice off of the top of the entities' list), H, F, A, E, I, G, B, J, C, D. However, to mitigate job starvation, we'd rather execute C and D before E, and so on, given, of course, that they're all ready to be executed. So, if all jobs are ready at this instant, the order of execution for this and the next 9 instances of picking the next job to execute, should really be, A, B, C, D, E, F, G, H, I, J, which is their chronological order. The only reason for this order to be broken, is if an older job is not yet ready, but a younger job is ready, at an instant of picking a new job to execute. For instance if job C wasn't ready at time 2, but job D was ready, then we'd pick job D, like this: 0 +1 +2 ... A, B, D, ... And from then on, C would be preferred before all other jobs, if it is ready at the time when a new job for execution is picked. So, if C became ready two steps later, the execution order would look like this: ..0 +1 +2 ... A, B, D, E, C, F, G, H, I, J This is what the FIFO GPU scheduling algorithm achieves. It uses a Red-Black tree to keep jobs sorted in chronological order, where picking the oldest job is O(1) (we use the "cached" structure), and balancing the tree is O(log n). IOW, it picks the *oldest ready* job to execute now. The implementation is already in the kernel, and this commit only changes the default GPU scheduling algorithm to use. This was tested and achieves about 1% faster performance over the Round Robin algorithm. Cc: Christian König Cc: Alex Deucher Cc: Direct Rendering Infrastructure - Development Signed-off-by: Luben Tuikov Reviewed-by: Christian König --- drivers/gpu/drm/scheduler/sched_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index 2fab218d708279..d0ff9e11cb69fa 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -62,13 +62,13 @@ #define to_drm_sched_job(sched_job) \ container_of((sched_job), struct drm_sched_job, queue_node) -int drm_sched_policy = DRM_SCHED_POLICY_RR; +int drm_sched_policy = DRM_SCHED_POLICY_FIFO; /** * DOC: sched_policy (int) * Used to override default entities scheduling policy in a run queue. */ -MODULE_PARM_DESC(sched_policy, "Specify schedule policy for entities on a runqueue, " __stringify(DRM_SCHED_POLICY_RR) " = Round Robin (default), " __stringify(DRM_SCHED_POLICY_FIFO) " = use FIFO."); +MODULE_PARM_DESC(sched_policy, "Specify the scheduling policy for entities on a run-queue, " __stringify(DRM_SCHED_POLICY_RR) " = Round Robin, " __stringify(DRM_SCHED_POLICY_FIFO) " = FIFO (default)."); module_param_named(sched_policy, drm_sched_policy, int, 0444); static __always_inline bool drm_sched_entity_compare_before(struct rb_node *a, base-commit: 27b2ae654370e1a8e446b0e48c4e406abed12ca1
[PATCH] video/aperture: Call sysfb_disable() before removing PCI devices
Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
before removing PCI devices. Without, simpledrm can still bind to
simple-framebuffer devices after the hardware driver has taken over
the hardware. Both drivers interfere with each other and results are
undefined.
Reported modesetting errors are shown below.
snap
rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13- } 7
jiffies s: 165 root: 0x2000/.
rcu: blocking rcu_node structures (internal RCU debug):
Task dump for CPU 13:
task:X state:R running task stack:0 pid: 4242 ppid:
4228 flags:0x0008
Call Trace:
? commit_tail+0xd7/0x130
? drm_atomic_helper_commit+0x126/0x150
? drm_atomic_commit+0xa4/0xe0
? drm_plane_get_damage_clips.cold+0x1c/0x1c
? drm_atomic_helper_dirtyfb+0x19e/0x280
? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? drm_ioctl_kernel+0xc4/0x150
? drm_ioctl+0x246/0x3f0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? __x64_sys_ioctl+0x91/0xd0
? do_syscall_64+0x60/0xd0
? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
...
rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13- } 30
jiffies s: 169 root: 0x2000/.
rcu: blocking rcu_node structures (internal RCU debug):
Task dump for CPU 13:
task:X state:R running task stack:0 pid: 4242 ppid:
4228 flags:0x400e
Call Trace:
? memcpy_toio+0x76/0xc0
? memcpy_toio+0x1b/0xc0
? drm_fb_memcpy_toio+0x76/0xb0
? drm_fb_blit_toio+0x75/0x2b0
? simpledrm_simple_display_pipe_update+0x132/0x150
? drm_atomic_helper_commit_planes+0xb6/0x230
? drm_atomic_helper_commit_tail+0x44/0x80
? commit_tail+0xd7/0x130
? drm_atomic_helper_commit+0x126/0x150
? drm_atomic_commit+0xa4/0xe0
? drm_plane_get_damage_clips.cold+0x1c/0x1c
? drm_atomic_helper_dirtyfb+0x19e/0x280
? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? drm_ioctl_kernel+0xc4/0x150
? drm_ioctl+0x246/0x3f0
? drm_mode_getfb2_ioctl+0x2d0/0x2d0
? __x64_sys_ioctl+0x91/0xd0
? do_syscall_64+0x60/0xd0
? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
The problem was added by commit 5e0137612430 ("video/aperture: Disable
and unregister sysfb devices via aperture helpers") to v6.0.3 and does
not exist in the mainline branch.
Reported-by: Andreas Thalhammer
Reported-by: Thorsten Leemhuis
Signed-off-by: Thomas Zimmermann
Tested-by: Andreas Thalhammer
Fixes: cfecfc98a78d ("video/aperture: Disable and unregister sysfb devices via
aperture helpers")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Zack Rusin
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Alex Deucher
Cc: Zhen Lei
Cc: Changcheng Deng
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Cc: Sasha Levin
Cc: linux-fb...@vger.kernel.org
Cc: # v6.0.3+
Link:
https://lore.kernel.org/dri-devel/d6afe54b-f8d7-beb2-3609-186e566cb...@gmx.net/T/#t
---
drivers/video/aperture.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index d245826a9324d..cc6427a091bc7 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -338,6 +338,17 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev
*pdev, const char *na
resource_size_t base, size;
int bar, ret;
+ /*
+* If a driver asked to unregister a platform device registered by
+* sysfb, then can be assumed that this is a driver for a display
+* that is set up by the system firmware and has a generic driver.
+*
+* Drivers for devices that don't have a generic driver will never
+* ask for this, so let's assume that a real driver for the display
+* was already probed and prevent sysfb to register devices later.
+*/
+ sysfb_disable();
+
/*
* WARNING: Apparently we must kick fbdev drivers before vgacon,
* otherwise the vga fbdev driver falls over.
--
2.38.0
Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
On Tue, Oct 25, 2022 at 12:27:11PM +1000, Dave Airlie wrote: > The userspace for those is normally bespoke like ROCm, which uses > amdkfd, and amdkfd doesn't operate like most device files from what I > know, so I'm not sure we'd want it to operate as an accel device. I intensely dislike this direction that drivers will create their own char devs buried inside their device driver with no support or supervision. We've been here before with RDMA and it is just a complete mess. Whatever special non-drm stuff amdkfd need to do should be supported through the new subsystem, in a proper maintainable way. Jason
Re: [PATCH] video/aperture: Call sysfb_disable() before removing PCI devices
On Tue, Oct 25, 2022 at 01:04:53PM +0200, Thomas Zimmermann wrote:
> Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
> before removing PCI devices. Without, simpledrm can still bind to
> simple-framebuffer devices after the hardware driver has taken over
> the hardware. Both drivers interfere with each other and results are
> undefined.
>
> Reported modesetting errors are shown below.
>
> snap
> rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13- } 7
> jiffies s: 165 root: 0x2000/.
> rcu: blocking rcu_node structures (internal RCU debug):
> Task dump for CPU 13:
> task:X state:R running task stack:0 pid: 4242 ppid:
> 4228 flags:0x0008
> Call Trace:
>
> ? commit_tail+0xd7/0x130
> ? drm_atomic_helper_commit+0x126/0x150
> ? drm_atomic_commit+0xa4/0xe0
> ? drm_plane_get_damage_clips.cold+0x1c/0x1c
> ? drm_atomic_helper_dirtyfb+0x19e/0x280
> ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? drm_ioctl_kernel+0xc4/0x150
> ? drm_ioctl+0x246/0x3f0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? __x64_sys_ioctl+0x91/0xd0
> ? do_syscall_64+0x60/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
>
> ...
> rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13- } 30
> jiffies s: 169 root: 0x2000/.
> rcu: blocking rcu_node structures (internal RCU debug):
> Task dump for CPU 13:
> task:X state:R running task stack:0 pid: 4242 ppid:
> 4228 flags:0x400e
> Call Trace:
>
> ? memcpy_toio+0x76/0xc0
> ? memcpy_toio+0x1b/0xc0
> ? drm_fb_memcpy_toio+0x76/0xb0
> ? drm_fb_blit_toio+0x75/0x2b0
> ? simpledrm_simple_display_pipe_update+0x132/0x150
> ? drm_atomic_helper_commit_planes+0xb6/0x230
> ? drm_atomic_helper_commit_tail+0x44/0x80
> ? commit_tail+0xd7/0x130
> ? drm_atomic_helper_commit+0x126/0x150
> ? drm_atomic_commit+0xa4/0xe0
> ? drm_plane_get_damage_clips.cold+0x1c/0x1c
> ? drm_atomic_helper_dirtyfb+0x19e/0x280
> ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? drm_ioctl_kernel+0xc4/0x150
> ? drm_ioctl+0x246/0x3f0
> ? drm_mode_getfb2_ioctl+0x2d0/0x2d0
> ? __x64_sys_ioctl+0x91/0xd0
> ? do_syscall_64+0x60/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5
>
>
> The problem was added by commit 5e0137612430 ("video/aperture: Disable
> and unregister sysfb devices via aperture helpers") to v6.0.3 and does
> not exist in the mainline branch.
Why isn't this a problem in Linus's tree? What commits there cause this
to not be an issue and why can't we just take them instead?
thanks,
greg k-h
[bug report] dma-buf: Move dma_buf_attach() to dynamic locking specification
Hello Dmitry Osipenko,
The patch 809d9c72c2f8: "dma-buf: Move dma_buf_attach() to dynamic
locking specification" from Oct 17, 2022, leads to the following
Smatch static checker warning:
drivers/dma-buf/dma-buf.c:957 dma_buf_dynamic_attach()
error: double unlocked 'dmabuf->resv' (orig line 915)
drivers/dma-buf/dma-buf.c
987 /**
988 * dma_buf_detach - Remove the given attachment from dmabuf's
attachments list
989 * @dmabuf: [in]buffer to detach from.
990 * @attach: [in]attachment to be detached; is free'd after this
call.
991 *
992 * Clean up a device attachment obtained by calling dma_buf_attach().
993 *
994 * Optionally this calls &dma_buf_ops.detach for device-specific detach.
995 */
996 void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment
*attach)
997 {
998 if (WARN_ON(!dmabuf || !attach))
999 return;
1000
1001 dma_resv_lock(attach->dmabuf->resv, NULL);
In the original code used to take this both the "attach->dmabuf->resv"
and "dmabuf->resv" locks and unlock them both. But now it takes one
lock and unlocks the other. Seems sus.
1002
1003 if (attach->sgt) {
1004
1005 __unmap_dma_buf(attach, attach->sgt, attach->dir);
1006
1007 if (dma_buf_is_dynamic(attach->dmabuf))
1008 dmabuf->ops->unpin(attach);
1009 }
1010 list_del(&attach->node);
1011
1012 dma_resv_unlock(dmabuf->resv);
1013
1014 if (dmabuf->ops->detach)
1015 dmabuf->ops->detach(dmabuf, attach);
1016
1017 kfree(attach);
1018 }
regards,
dan carpenter
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
Hi, thanks for detailed review. My responses inline. On 10/25/2022 1:00 AM, Jeffrey Hugo wrote: > On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote: >> VPU stands for Versatile Processing Unit and it's a CPU-integrated >> inference accelerator for Computer Vision and Deep Learning >> applications. >> >> The VPU device consist of following componensts: >>- Buttress - provides CPU to VPU integration, interrupt, frequency and >> power management. >>- Memory Management Unit (based on ARM MMU-600) - translates VPU to >> host DMA addresses, isolates user workloads. >>- RISC based microcontroller - executes firmware that provides job >> execution API for the kernel-mode driver >>- Neural Compute Subsystem (NCS) - does the actual work, provides >> Compute and Copy engines. >>- Network on Chip (NoC) - network fabric connecting all the components >> >> This driver supports VPU IP v2.7 integrated into Intel Meteor Lake >> client CPUs (14th generation). >> >> Module sources are at drivers/gpu/drm/ivpu and module name is >> "intel_vpu.ko". >> >> This patch includes only very besic functionality: >>- module, PCI device and IRQ initialization >>- register definitions and low level register manipulation functions >>- SET/GET_PARAM ioctls >>- power up without firmware >> >> Signed-off-by: Krystian Pradzynski >> Signed-off-by: Jacek Lawrynowicz >> --- >> MAINTAINERS|8 + >> drivers/gpu/drm/Kconfig|2 + >> drivers/gpu/drm/Makefile |1 + >> drivers/gpu/drm/ivpu/Kconfig | 12 + >> drivers/gpu/drm/ivpu/Makefile |8 + >> drivers/gpu/drm/ivpu/TODO |7 + >> drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + >> drivers/gpu/drm/ivpu/ivpu_drv.h| 153 >> drivers/gpu/drm/ivpu/ivpu_hw.h | 169 >> drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 >> drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ >> drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ >> include/uapi/drm/ivpu_drm.h| 95 +++ >> 13 files changed, 2451 insertions(+) >> create mode 100644 drivers/gpu/drm/ivpu/Kconfig >> create mode 100644 drivers/gpu/drm/ivpu/Makefile >> create mode 100644 drivers/gpu/drm/ivpu/TODO >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h >> create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h >> create mode 100644 include/uapi/drm/ivpu_drm.h >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 9475aa701a3f..d72ceef107e6 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -7046,6 +7046,14 @@ F: >> Documentation/devicetree/bindings/gpu/vivante,gc.yaml >> F:drivers/gpu/drm/etnaviv/ >> F:include/uapi/drm/etnaviv_drm.h >> +DRM DRIVERS FOR VPU >> +M:Jacek Lawrynowicz >> +M:Stanislaw Gruszka >> +S:Supported >> +T:git git://anongit.freedesktop.org/drm/drm-misc >> +F:drivers/gpu/drm/ivpu/ >> +F:include/uapi/drm/ivpu_drm.h > > No mail list? OK, I will add a link to dri-devel. >> + >> DRM DRIVERS FOR XEN >> M:Oleksandr Andrushchenko >> L:dri-devel@lists.freedesktop.org >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 198ba846d34b..0aaac0e5366f 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" >> source "drivers/gpu/drm/vc4/Kconfig" >> +source "drivers/gpu/drm/ivpu/Kconfig" >> + > > Why here of all places? Just randomly in the middle of the list of sourced > Kconfigs? I'll move it to the end. >> source "drivers/gpu/drm/etnaviv/Kconfig" >> source "drivers/gpu/drm/hisilicon/Kconfig" >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index 25d0ba310509..1bfd7415c2d0 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ >> obj-$(CONFIG_DRM_MGAG200) += mgag200/ >> obj-$(CONFIG_DRM_V3D) += v3d/ >> obj-$(CONFIG_DRM_VC4) += vc4/ >> +obj-$(CONFIG_DRM_IVPU) += ivpu/ > > Again, why here? I'll move it to the end. >> diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile >> new file mode 100644 >> index ..e59dc65abe6a >> --- /dev/null >> +++ b/drivers/gpu/drm/ivpu/Makefile >> @@ -0,0 +1,8 @@ >> +# SPDX-License-Identifier: GPL-2.0-only >> +# Copyright © 2022 Intel Corporation > > I'm pretty sure (C) is preferred. Looks like you do this in multiple places. > I'm only going to mention it here. OK, I'll use (C) everywhere. >> +int ivpu_dbg_mask; >> +module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644); >> +MODULE_PARM_DESC(dbg_mask,
[bug report] drm/bridge: it6505: Adapt runtime power management framework
Hello Pin-yen Lin,
The patch 1051d302: "drm/bridge: it6505: Adapt runtime power
management framework" from Oct 4, 2022, leads to the following Smatch
static checker warning:
drivers/gpu/drm/bridge/ite-it6505.c:2712 it6505_extcon_work()
warn: pm_runtime_get_sync() also returns 1 on success
drivers/gpu/drm/bridge/ite-it6505.c
2685 static void it6505_extcon_work(struct work_struct *work)
2686 {
2687 struct it6505 *it6505 = container_of(work, struct it6505,
extcon_wq);
2688 struct device *dev = &it6505->client->dev;
2689 int state, ret;
2690
2691 if (it6505->enable_drv_hold)
2692 return;
2693
2694 mutex_lock(&it6505->extcon_lock);
2695
2696 state = extcon_get_state(it6505->extcon, EXTCON_DISP_DP);
2697 DRM_DEV_DEBUG_DRIVER(dev, "EXTCON_DISP_DP = 0x%02x", state);
2698
2699 if (state == it6505->extcon_state || unlikely(state < 0))
2700 goto unlock;
2701 it6505->extcon_state = state;
2702 if (state) {
2703 DRM_DEV_DEBUG_DRIVER(dev, "start to power on");
2704 msleep(100);
2705 ret = pm_runtime_get_sync(dev);
2706
2707 /*
2708 * On system resume, extcon_work can be triggered
before
2709 * pm_runtime_force_resume re-enables runtime power
management.
2710 * Handling the error here to make sure the bridge is
powered on.
2711 */
--> 2712 if (ret)
2713 it6505_poweron(it6505);
pm_runtime_get_sync() returns 1 on success. Consider using
pm_runtime_resume_and_get() instead.
2714 } else {
2715 DRM_DEV_DEBUG_DRIVER(dev, "start to power off");
2716 pm_runtime_put_sync(dev);
2717
2718 drm_helper_hpd_irq_event(it6505->bridge.dev);
2719 memset(it6505->dpcd, 0, sizeof(it6505->dpcd));
2720 DRM_DEV_DEBUG_DRIVER(dev, "power off it6505 success!");
2721 }
2722
2723 unlock:
2724 mutex_unlock(&it6505->extcon_lock);
2725 }
regards,
dan carpenter
Re: [bug report] dma-buf: Move dma_buf_attach() to dynamic locking specification
On 10/25/22 14:41, Dan Carpenter wrote:
> Hello Dmitry Osipenko,
>
> The patch 809d9c72c2f8: "dma-buf: Move dma_buf_attach() to dynamic
> locking specification" from Oct 17, 2022, leads to the following
> Smatch static checker warning:
>
> drivers/dma-buf/dma-buf.c:957 dma_buf_dynamic_attach()
> error: double unlocked 'dmabuf->resv' (orig line 915)
>
> drivers/dma-buf/dma-buf.c
>987 /**
>988 * dma_buf_detach - Remove the given attachment from dmabuf's
> attachments list
>989 * @dmabuf: [in]buffer to detach from.
>990 * @attach: [in]attachment to be detached; is free'd after
> this call.
>991 *
>992 * Clean up a device attachment obtained by calling dma_buf_attach().
>993 *
>994 * Optionally this calls &dma_buf_ops.detach for device-specific
> detach.
>995 */
>996 void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment
> *attach)
>997 {
>998 if (WARN_ON(!dmabuf || !attach))
>999 return;
> 1000
> 1001 dma_resv_lock(attach->dmabuf->resv, NULL);
>
> In the original code used to take this both the "attach->dmabuf->resv"
> and "dmabuf->resv" locks and unlock them both. But now it takes one
> lock and unlocks the other. Seems sus.
It will be the same lock. Apparently I copied the part of code from
other function, that's why lock/unlock aren't consistent there. The
dma_buf_detach() doesn't really need the `dmabuf` argument, perhaps it
was more useful in the past.
I'll prepare the patch to clean up the locking pointer. Thank you for
the report!
--
Best regards,
Dmitry
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
Hi Am 25.10.22 um 13:42 schrieb Jacek Lawrynowicz: Hi, thanks for detailed review. My responses inline. On 10/25/2022 1:00 AM, Jeffrey Hugo wrote: On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote: VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following componensts: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/gpu/drm/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Signed-off-by: Krystian Pradzynski Signed-off-by: Jacek Lawrynowicz --- MAINTAINERS|8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivpu/Kconfig | 12 + drivers/gpu/drm/ivpu/Makefile |8 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + drivers/gpu/drm/ivpu/ivpu_drv.h| 153 drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ include/uapi/drm/ivpu_drm.h| 95 +++ 13 files changed, 2451 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 include/uapi/drm/ivpu_drm.h diff --git a/MAINTAINERS b/MAINTAINERS index 9475aa701a3f..d72ceef107e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7046,6 +7046,14 @@ F: Documentation/devicetree/bindings/gpu/vivante,gc.yaml F:drivers/gpu/drm/etnaviv/ F:include/uapi/drm/etnaviv_drm.h +DRM DRIVERS FOR VPU +M:Jacek Lawrynowicz +M:Stanislaw Gruszka +S:Supported +T:git git://anongit.freedesktop.org/drm/drm-misc +F:drivers/gpu/drm/ivpu/ +F:include/uapi/drm/ivpu_drm.h No mail list? OK, I will add a link to dri-devel. + DRM DRIVERS FOR XEN M:Oleksandr Andrushchenko L:dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..0aaac0e5366f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" +source "drivers/gpu/drm/ivpu/Kconfig" + Why here of all places? Just randomly in the middle of the list of sourced Kconfigs? I'll move it to the end. I known that the Kconfigs and Makefiles are chaotic. But if you can, try to sort it alphabetically. source "drivers/gpu/drm/etnaviv/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 25d0ba310509..1bfd7415c2d0 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_IVPU) += ivpu/ Again, why here? I'll move it to the end. Same. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v5 05/19] drm/i915/vm_bind: Implement bind and unbind of object
Hi Niranjana, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Niranjana-Vishwanathapura/drm-i915-vm_bind-Add-VM_BIND-functionality/20221025-150246 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip patch link: https://lore.kernel.org/r/20221025065905.13325-6-niranjana.vishwanathapura%40intel.com patch subject: [Intel-gfx] [PATCH v5 05/19] drm/i915/vm_bind: Implement bind and unbind of object config: i386-randconfig-a003-20221024 (attached as .config) compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/493d35709c7a1fafd30f53c539e36cec9a1f9fb8 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Niranjana-Vishwanathapura/drm-i915-vm_bind-Add-VM_BIND-functionality/20221025-150246 git checkout 493d35709c7a1fafd30f53c539e36cec9a1f9fb8 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot All errors (new ones prefixed by >>): >> drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c:18:1: error: unused >> function 'i915_vm_bind_it_iter_next' [-Werror,-Wunused-function] INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last, ^ include/linux/interval_tree_generic.h:151:33: note: expanded from macro 'INTERVAL_TREE_DEFINE' ITSTATIC ITSTRUCT * \ ^ :88:1: note: expanded from here i915_vm_bind_it_iter_next ^ 1 error generated. vim +/i915_vm_bind_it_iter_next +18 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 17 > 18 INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last, 19 START, LAST, static inline, i915_vm_bind_it) 20 -- 0-DAY CI Kernel Test Service https://01.org/lkp .config.gz Description: application/gzip
[airlied:01.01-gsp-rm 173/180] drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:640:71: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type
tree: git://people.freedesktop.org/~airlied/linux.git 01.01-gsp-rm
head: 6be95d5e52818808565790c5ee3fd5569263bd36
commit: 2428d9aef24a6a497b8740afadbb028c17b5e697 [173/180]
drm/nouveau/gsp/tu102-: add support for booting GSP-RM
config: microblaze-randconfig-r001-20221023 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add airlied git://people.freedesktop.org/~airlied/linux.git
git fetch --no-tags airlied 01.01-gsp-rm
git checkout 2428d9aef24a6a497b8740afadbb028c17b5e697
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=microblaze SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c: In function
'nvkm_gsp_mem_ctor':
>> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:640:71: error: passing
>> argument 3 of 'dma_alloc_coherent' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
640 | mem->data = dma_alloc_coherent(gsp->subdev.device->dev,
size, &mem->addr, GFP_KERNEL);
|
^~
|
|
|
u64 * {aka long long unsigned int *}
In file included from arch/microblaze/include/asm/pci.h:14,
from include/linux/pci.h:1910,
from drivers/gpu/drm/nouveau/include/nvif/os.h:8,
from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4,
from drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3,
from drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4,
from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4,
from drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h:4,
from drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h:4,
from drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:22:
include/linux/dma-mapping.h:426:29: note: expected 'dma_addr_t *' {aka
'unsigned int *'} but argument is of type 'u64 *' {aka 'long long unsigned int
*'}
426 | dma_addr_t *dma_handle, gfp_t gfp)
| ^~
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c: In function 'r515_gsp_load':
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c:1141:58: error: passing
argument 3 of 'dma_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
1141 |
&gsp->radix3[i].addr, GFP_KERNEL);
|
^~~~
| |
| u64 * {aka
long long unsigned int *}
include/linux/dma-mapping.h:426:29: note: expected 'dma_addr_t *' {aka
'unsigned int *'} but argument is of type 'u64 *' {aka 'long long unsigned int
*'}
426 | dma_addr_t *dma_handle, gfp_t gfp)
| ^~
cc1: some warnings being treated as errors
vim +/dma_alloc_coherent +640 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r515.c
635
636 static int
637 nvkm_gsp_mem_ctor(struct nvkm_gsp *gsp, u32 size, struct nvkm_gsp_mem
*mem)
638 {
639 mem->size = size;
> 640 mem->data = dma_alloc_coherent(gsp->subdev.device->dev, size,
> &mem->addr, GFP_KERNEL);
641 if (WARN_ON(!mem->data))
642 return -ENOMEM;
643
644 return 0;
645 }
646
--
0-DAY CI Kernel Test Service
https://01.org/lkp
.config.gz
Description: application/gzip
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
Hi, please find some review comments below. Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz: VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following componensts: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/gpu/drm/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Signed-off-by: Krystian Pradzynski Signed-off-by: Jacek Lawrynowicz --- MAINTAINERS|8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivpu/Kconfig | 12 + drivers/gpu/drm/ivpu/Makefile |8 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + drivers/gpu/drm/ivpu/ivpu_drv.h| 153 drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ include/uapi/drm/ivpu_drm.h| 95 +++ 13 files changed, 2451 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 include/uapi/drm/ivpu_drm.h diff --git a/MAINTAINERS b/MAINTAINERS index 9475aa701a3f..d72ceef107e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7046,6 +7046,14 @@ F: Documentation/devicetree/bindings/gpu/vivante,gc.yaml F:drivers/gpu/drm/etnaviv/ F:include/uapi/drm/etnaviv_drm.h +DRM DRIVERS FOR VPU +M: Jacek Lawrynowicz +M: Stanislaw Gruszka +S: Supported +T: git git://anongit.freedesktop.org/drm/drm-misc +F: drivers/gpu/drm/ivpu/ +F: include/uapi/drm/ivpu_drm.h + DRM DRIVERS FOR XEN M:Oleksandr Andrushchenko L:dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..0aaac0e5366f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" +source "drivers/gpu/drm/ivpu/Kconfig" + source "drivers/gpu/drm/etnaviv/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 25d0ba310509..1bfd7415c2d0 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_IVPU) += ivpu/ obj-$(CONFIG_DRM_SIS) += sis/ obj-$(CONFIG_DRM_SAVAGE)+= savage/ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ diff --git a/drivers/gpu/drm/ivpu/Kconfig b/drivers/gpu/drm/ivpu/Kconfig new file mode 100644 index ..30af359c52f2 --- /dev/null +++ b/drivers/gpu/drm/ivpu/Kconfig @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0-only +config DRM_IVPU + tristate "Intel VPU for Meteor Lake and newer" + depends on DRM + depends on X86_64 && PCI + select SHMEM + help + Choose this option if you have a system that has an 14th generation Intel CPU + or newer. VPU stands for Versatile Processing Unit and it's a CPU-integrated + inference accelerator for Computer Vision and Deep Learning applications. + + If "M" is selected, the module will be called intel_vpu. diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile new file mode 100644 index ..e59dc65abe6a --- /dev/null +++ b/drivers/gpu/drm/ivpu/Makefile @@ -0,0 +1,8 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright © 2022 Intel Cor
Re: [PATCH v3 3/7] drm/ivpu: Add GEM buffer object management
Hi
Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz:
Adds four types of GEM-based BOs for the VPU:
- shmem
- userptr
- internal
- prime
All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime buffers that allocate it in BO_INFO IOCTL due
to missing file_priv arg in gem_prime_import callback.
Internal buffers are pinned on creation, the rest of buffers types
can be pinned on demand (in SUBMIT IOCTL).
Buffer VPU address, allocated pages and mappings are relased when the
buffer is destroyed.
Eviction mechism is planned for future versions.
Add three new IOCTLs: BO_CREATE, BO_INFO, BO_USERPTR
I feels like TTM already does all you need. (?) Why not build upon TTM?
Best regards
Thomas
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 1 +
drivers/gpu/drm/ivpu/ivpu_drv.c | 9 +
drivers/gpu/drm/ivpu/ivpu_gem.c | 823
drivers/gpu/drm/ivpu/ivpu_gem.h | 128 +
include/uapi/drm/ivpu_drm.h | 127 +
5 files changed, 1088 insertions(+)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index 95bb04f26296..4053fe341d56 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index cbeb9a801a31..b0442e2a4960 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include "ivpu_drv.h"
+#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -187,6 +189,9 @@ static void ivpu_postclose(struct drm_device *dev, struct
drm_file *file)
static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_GET_PARAM, ivpu_get_param_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(IVPU_SET_PARAM, ivpu_set_param_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl,
DRM_RENDER_ALLOW),
};
DEFINE_DRM_GEM_FOPS(ivpu_fops);
@@ -210,6 +215,10 @@ static const struct drm_driver driver = {
.open = ivpu_open,
.postclose = ivpu_postclose,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import = ivpu_gem_prime_import,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.ioctls = ivpu_drm_ioctls,
.num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls),
diff --git a/drivers/gpu/drm/ivpu/ivpu_gem.c b/drivers/gpu/drm/ivpu/ivpu_gem.c
new file mode 100644
index ..54319a25c18e
--- /dev/null
+++ b/drivers/gpu/drm/ivpu/ivpu_gem.c
@@ -0,0 +1,823 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2020-2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "ivpu_drv.h"
+#include "ivpu_gem.h"
+#include "ivpu_hw.h"
+#include "ivpu_mmu.h"
+#include "ivpu_mmu_context.h"
+
+MODULE_IMPORT_NS(DMA_BUF);
+
+static const struct drm_gem_object_funcs ivpu_gem_funcs;
+
+static int __must_check prime_alloc_pages_locked(struct ivpu_bo *bo)
+{
+ /* Pages are managed by the underlying dma-buf */
+ return 0;
+}
+
+static void prime_free_pages_locked(struct ivpu_bo *bo)
+{
+ /* Pages are managed by the underlying dma-buf */
+}
+
+static int prime_map_pages_locked(struct ivpu_bo *bo)
+{
+ struct ivpu_device *vdev = ivpu_bo_to_vdev(bo);
+ struct sg_table *sgt;
+
+ WARN_ON(!bo->base.import_attach);
+
+ sgt = dma_buf_map_attachment(bo->base.import_attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt)) {
+ ivpu_err(vdev, "Failed to map attachment: %ld\n", PTR_ERR(sgt));
+ return PTR_ERR(sgt);
+ }
+
+ bo->sgt = sgt;
+ return 0;
+}
+
+static void prime_unmap_pages_locked(struct ivpu_bo *bo)
+{
+ WARN_ON(!bo->base.import_attach);
+
+ dma_buf_unmap_attachment(bo->base.import_attach, bo->sgt,
DMA_BIDIRECTIONAL);
+ bo->sgt = NULL;
+}
+
+static const struct ivpu_bo_ops prime_ops = {
+ .type = IVPU_BO_TYPE_PRIME,
+ .name = "prime",
+ .alloc_pages = prime_alloc_pages_locked,
+ .free_pages = prime_free_pages_locked,
+ .map_pages = prime_map_pages_locked,
+ .unmap_pages = prime_unmap_pages_locked,
+};
+
+static int __must_check shmem_alloc_pages_locked(struct ivpu_bo *bo)
+{
+ int npages = bo->bas
Re: [PATCH] video: fbdev: sis: use explicitly signed char
On Mon, Oct 24, 2022 at 8:29 PM Helge Deller wrote: > > On 10/24/22 18:29, Jason A. Donenfeld wrote: > > With char becoming unsigned by default, and with `char` alone being > > ambiguous and based on architecture, signed chars need to be marked > > explicitly as such. This fixes warnings like: > > > > drivers/video/fbdev/sis/init301.c:3549 SiS_GetCRT2Data301() warn: > > 'SiS_Pr->SiS_EModeIDTable[ModeIdIndex]->ROMMODEIDX661' is unsigned > > > > Cc: Thomas Winischhofer > > Cc: Greg Kroah-Hartman > > Cc: Helge Deller > > Cc: linux-...@vger.kernel.org > > Cc: linux-fb...@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Jason A. Donenfeld > > Applied to linux-fbdev git tree. For 6.1 as a fix, right? Since this is already broken on, e.g., ARM. Jason
Re: [PATCH] video: fbdev: sis: use explicitly signed char
On 10/25/22 14:55, Jason A. Donenfeld wrote: On Mon, Oct 24, 2022 at 8:29 PM Helge Deller wrote: On 10/24/22 18:29, Jason A. Donenfeld wrote: With char becoming unsigned by default, and with `char` alone being ambiguous and based on architecture, signed chars need to be marked explicitly as such. This fixes warnings like: drivers/video/fbdev/sis/init301.c:3549 SiS_GetCRT2Data301() warn: 'SiS_Pr->SiS_EModeIDTable[ModeIdIndex]->ROMMODEIDX661' is unsigned Cc: Thomas Winischhofer Cc: Greg Kroah-Hartman Cc: Helge Deller Cc: linux-...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jason A. Donenfeld Applied to linux-fbdev git tree. For 6.1 as a fix, right? Since this is already broken on, e.g., ARM. Yes. Helge
Re: [RFC PATCH 3/3] drm: add dedicated minor for accelerator devices
On Mon, Oct 24, 2022 at 08:43:58PM +0300, Oded Gabbay wrote:
> On Mon, Oct 24, 2022 at 6:21 PM Jeffrey Hugo wrote:
> >
> > On 10/22/2022 3:46 PM, Oded Gabbay wrote:
> > > The accelerator devices are exposed to user-space using a dedicated
> > > major. In addition, they are represented in /dev with new, dedicated
> > > device char names: /dev/accel/accel*. This is done to make sure any
> > > user-space software that tries to open a graphic card won't open
> > > the accelerator device by mistake.
> > >
> > > The above implies that the minor numbering should be separated from
> > > the rest of the drm devices. However, to avoid code duplication, we
> > > want the drm_minor structure to be able to represent the accelerator
> > > device.
> > >
> > > To achieve this, we add a new drm_minor* to drm_device that represents
> > > the accelerator device. This pointer is initialized for drivers that
> > > declare they handle compute accelerator, using a new driver feature
> > > flag called DRIVER_COMPUTE_ACCEL. It is important to note that this
> > > driver feature is mutually exclusive with DRIVER_RENDER. Devices that
> > > want to expose both graphics and compute device char files should be
> > > handled by two drivers that are connected using the auxiliary bus
> > > framework.
> > >
> > > In addition, we define a different idr to handle the accelerators
> > > minors. This is done to make the minor's index be identical to the
> > > device index in /dev/. In most places, this is hidden inside the drm
> > > core functions except when calling drm_minor_acquire(), where I had to
> > > add an extra parameter to specify the idr to use (because the
> > > accelerators minors index and the drm primary minor index both begin
> > > at 0).
> > >
> > > Signed-off-by: Oded Gabbay
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 171 +
> > > drivers/gpu/drm/drm_file.c | 69 +
> > > drivers/gpu/drm/drm_internal.h | 2 +-
> > > drivers/gpu/drm/drm_sysfs.c| 29 --
> > > include/drm/drm_device.h | 3 +
> > > include/drm/drm_drv.h | 8 ++
> > > include/drm/drm_file.h | 21 +++-
> > > 7 files changed, 235 insertions(+), 68 deletions(-)
> >
> > Can we please add something to Documentation? I know this leverages DRM
> > a lot, but I believe that a new subsystem should not be introduced
> > without documentation. A lot of the info in the commit message is very
> > good, but should not be buried in the git log.
> >
> > Besides, imagine this has been in mainline for N years, and someone
> > completely new to the kernel wants to write an accel driver. They
> > should be able to get started with something from Documentation that
> > at-least gives that person some insight into what to grep the code for.
> Agreed. The only reason I haven't done it at this stage was because I
> wanted to get an initial reaction to the code itself, see if the
> direction is accepted.
> I didn't want to write documentation and then completely re-write it.
> So I will do it for the next patch-set, once I collect everyone's
> feedback and I see there is a majority agreement.
> >
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index b58ffb1433d6..c13701a8d4be 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -56,6 +56,9 @@ MODULE_LICENSE("GPL and additional rights");
> > > static DEFINE_SPINLOCK(drm_minor_lock);
> > > static struct idr drm_minors_idr;
> > >
> > > +static DEFINE_SPINLOCK(accel_minor_lock);
> > > +static struct idr accel_minors_idr;
> >
> > IDR is deprecated. XArray is the preferred mechanism.
> > Yes, there already is IDR here, but I believe we should not be adding
> > new uses. Maybe at some point, the current IDR will be converted. Also
> > with XArray, I think you don't need the spinlock since XArray has
> > internal locking already.
> ok, I wasn't aware. I don't have any problem replacing the idr to xarray.
The conversion is sitting on the mailinglist for a while now
(unfortunately, without much interest).
Perhaps you could help with reviewing it?
https://lore.kernel.org/dri-devel/20220911211443.581481-2-michal.winiar...@intel.com/
-Michał
>
> Thanks,
> Oded
>
Re: [PATCH] drm/scheduler: set current_entity to next when remove from rq
+ Luben On Tue, Oct 25, 2022 at 2:55 AM brolerliew wrote: > > When entity move from one rq to another, current_entity will be set to NULL > if it is the moving entity. This make entities close to rq head got > selected more frequently, especially when doing load balance between > multiple drm_gpu_scheduler. > > Make current_entity to next when removing from rq. > > Signed-off-by: brolerliew > --- > drivers/gpu/drm/scheduler/sched_main.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > b/drivers/gpu/drm/scheduler/sched_main.c > index 2fab218d7082..00b22cc50f08 100644 > --- a/drivers/gpu/drm/scheduler/sched_main.c > +++ b/drivers/gpu/drm/scheduler/sched_main.c > @@ -168,10 +168,11 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq *rq, > spin_lock(&rq->lock); > > atomic_dec(rq->sched->score); > - list_del_init(&entity->list); > > if (rq->current_entity == entity) > - rq->current_entity = NULL; > + rq->current_entity = list_next_entry(entity, list); > + > + list_del_init(&entity->list); > > if (drm_sched_policy == DRM_SCHED_POLICY_FIFO) > drm_sched_rq_remove_fifo_locked(entity); > -- > 2.34.1 >
Re: [PATCH printk v2 24/38] xen: fbfront: use srcu console list iterator
On Wed 2022-10-19 17:01:46, John Ogness wrote:
> Since the console_lock is not being used for anything other than
> safe console list traversal, use srcu console list iteration instead.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
> ---
> drivers/video/fbdev/xen-fbfront.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/xen-fbfront.c
> b/drivers/video/fbdev/xen-fbfront.c
> index 4d2694d904aa..2552c853c6c2 100644
> --- a/drivers/video/fbdev/xen-fbfront.c
> +++ b/drivers/video/fbdev/xen-fbfront.c
> @@ -500,16 +500,18 @@ static int xenfb_probe(struct xenbus_device *dev,
> static void xenfb_make_preferred_console(void)
Just for record. This function is a dirty hack how to associate "ttyX"
console with /dev/console.
A clean solution would be to just reshuffle console_drivers list. I
have a patch for this in my bottom drawer. It is part of a bigger
clean up that it not ready for upstreaming yet.
Best Regards,
Petr
> {
> struct console *c;
> + int cookie;
>
> if (console_set_on_cmdline)
> return;
>
> - console_lock();
> - for_each_console(c) {
> + cookie = console_srcu_read_lock();
> + for_each_console_srcu(c) {
> if (!strcmp(c->name, "tty") && c->index == 0)
> break;
> }
> - console_unlock();
> + console_srcu_read_unlock(cookie);
> +
> if (c) {
> unregister_console(c);
> c->flags |= CON_CONSDEV;
> --
> 2.30.2
Re: [PATCH v5 1/3] drm: Use XArray instead of IDR for minors
On 9/11/2022 3:14 PM, Michał Winiarski wrote: IDR is deprecated, and since XArray manages its own state with internal locking, it simplifies the locking on DRM side. Additionally, don't use the IRQ-safe variant, since operating on drm minor is not done in IRQ context. Signed-off-by: Michał Winiarski Suggested-by: Matthew Wilcox --- Reviewed-by: Jeffrey Hugo
Re: [PATCH 1/2] drm: remove DRM_MINOR_CONTROL
On Tue, Oct 11, 2022 at 01:55:01PM +0200, Christian König wrote:
> Am 11.10.22 um 13:39 schrieb Simon Ser:
> > On Tuesday, October 11th, 2022 at 13:04, Christian König
> > wrote:
> >
> > > --- a/include/drm/drm_file.h
> > > +++ b/include/drm/drm_file.h
> > > @@ -54,7 +54,6 @@ struct file;
> > >*/
> > > enum drm_minor_type {
> > > DRM_MINOR_PRIMARY,
> > > - DRM_MINOR_CONTROL,
> > > DRM_MINOR_RENDER,
> > > };
> > This makes me uncomfortable: this enum no longer matches DRM_NODE_* in
> > libdrm.
>
> Ah! There it was! I was remembering in the back of my head that we had
> somehow used this in libdrm as well, but couldn't really get where exactly.
>
> But I don't really see a problem here. The control nodes are identified by
> name and we don't expose them for quite some time now without any negative
> impact.
>
> Even the minor number distribution stays the same. So what bad can come from
> this?
>
> Thanks,
> Christian.
>
I proposed something similar in:
https://lore.kernel.org/dri-devel/20220817230600.272790-1-michal.winiar...@intel.com/
except acompanied by expanding the minor pool to accomodate more than
128 devices:
And after receiving similar feedback, that eventually evolved into
leaving the "legacy minors" alone, and changing the rules only for cases
where we have more than 64 devices (when we run out of the "legacy
minors").
Perhaps something like this:
https://lore.kernel.org/dri-devel/20220911211443.581481-1-michal.winiar...@intel.com/
Would work for your usecase as well?
-Michał
Re: [PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
On 10/25/2022 5:42 AM, Jacek Lawrynowicz wrote: Hi, thanks for detailed review. My responses inline. On 10/25/2022 1:00 AM, Jeffrey Hugo wrote: On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote: VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following componensts: Just noticed this. "components" - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/gpu/drm/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Signed-off-by: Krystian Pradzynski Signed-off-by: Jacek Lawrynowicz --- MAINTAINERS|8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivpu/Kconfig | 12 + drivers/gpu/drm/ivpu/Makefile |8 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + drivers/gpu/drm/ivpu/ivpu_drv.h| 153 drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ include/uapi/drm/ivpu_drm.h| 95 +++ 13 files changed, 2451 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 include/uapi/drm/ivpu_drm.h diff --git a/MAINTAINERS b/MAINTAINERS index 9475aa701a3f..d72ceef107e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7046,6 +7046,14 @@ F: Documentation/devicetree/bindings/gpu/vivante,gc.yaml F:drivers/gpu/drm/etnaviv/ F:include/uapi/drm/etnaviv_drm.h +DRM DRIVERS FOR VPU +M:Jacek Lawrynowicz +M:Stanislaw Gruszka +S:Supported +T:git git://anongit.freedesktop.org/drm/drm-misc +F:drivers/gpu/drm/ivpu/ +F:include/uapi/drm/ivpu_drm.h No mail list? OK, I will add a link to dri-devel. + DRM DRIVERS FOR XEN M:Oleksandr Andrushchenko L:dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..0aaac0e5366f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" +source "drivers/gpu/drm/ivpu/Kconfig" + Why here of all places? Just randomly in the middle of the list of sourced Kconfigs? I'll move it to the end. source "drivers/gpu/drm/etnaviv/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 25d0ba310509..1bfd7415c2d0 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_IVPU) += ivpu/ Again, why here? I'll move it to the end. diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile new file mode 100644 index ..e59dc65abe6a --- /dev/null +++ b/drivers/gpu/drm/ivpu/Makefile @@ -0,0 +1,8 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright © 2022 Intel Corporation I'm pretty sure (C) is preferred. Looks like you do this in multiple places. I'm only going to mention it here. OK, I'll use (C) everywhere. +int ivpu_dbg_mask; +module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644); +MODULE_PARM_DESC(dbg_mask, "Driver debug mask. See IVPU_DBG_* macros."); Shouldn't this be unnecessary with the DRM_DEBUG levels, or making the things tracepoints? drm logging doesn't provide the gran
Re: [PATCH 3/3] Revert "drm/amd/display: Limit max DSC target bpp for specific monitors"
Series is
Reviewed-by: Harry Wentland
Harry
On 2022-10-24 15:22, Hamza Mahfooz wrote:
> This reverts commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059.
>
> This quirk is now handled in the DRM core, so we can drop all of
> the internal code that was added to handle it.
>
> Signed-off-by: Hamza Mahfooz
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 35 ---
> 1 file changed, 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 4956a0118215..a21e2ba77ddb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -41,39 +41,6 @@
> #include "dm_helpers.h"
> #include "ddc_service_types.h"
>
> -struct monitor_patch_info {
> - unsigned int manufacturer_id;
> - unsigned int product_id;
> - void (*patch_func)(struct dc_edid_caps *edid_caps, unsigned int param);
> - unsigned int patch_param;
> -};
> -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> int param);
> -
> -static const struct monitor_patch_info monitor_patch_table[] = {
> -{0x6D1E, 0x5BBF, set_max_dsc_bpp_limit, 15},
> -{0x6D1E, 0x5B9A, set_max_dsc_bpp_limit, 15},
> -};
> -
> -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> int param)
> -{
> - if (edid_caps)
> - edid_caps->panel_patch.max_dsc_target_bpp_limit = param;
> -}
> -
> -static int amdgpu_dm_patch_edid_caps(struct dc_edid_caps *edid_caps)
> -{
> - int i, ret = 0;
> -
> - for (i = 0; i < ARRAY_SIZE(monitor_patch_table); i++)
> - if ((edid_caps->manufacturer_id ==
> monitor_patch_table[i].manufacturer_id)
> - && (edid_caps->product_id ==
> monitor_patch_table[i].product_id)) {
> - monitor_patch_table[i].patch_func(edid_caps,
> monitor_patch_table[i].patch_param);
> - ret++;
> - }
> -
> - return ret;
> -}
> -
> /* dm_helpers_parse_edid_caps
> *
> * Parse edid caps
> @@ -148,8 +115,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
> kfree(sads);
> kfree(sadb);
>
> - amdgpu_dm_patch_edid_caps(edid_caps);
> -
> return result;
> }
>
Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
On Tue, Oct 25, 2022 at 7:15 AM Jason Gunthorpe wrote: > > On Tue, Oct 25, 2022 at 12:27:11PM +1000, Dave Airlie wrote: > > > The userspace for those is normally bespoke like ROCm, which uses > > amdkfd, and amdkfd doesn't operate like most device files from what I > > know, so I'm not sure we'd want it to operate as an accel device. > > I intensely dislike this direction that drivers will create their own > char devs buried inside their device driver with no support or > supervision. > > We've been here before with RDMA and it is just a complete mess. > > Whatever special non-drm stuff amdkfd need to do should be supported > through the new subsystem, in a proper maintainable way. We plan to eventually move ROCm over the drm interfaces once we get user mode queues working on non-compute queues which is already in progress. ROCm already uses the existing drm nodes and libdrm for a number of things today (buffer sharing, media and compute command submission in certain cases, etc.). I don't see much value in the accel nodes for AMD products at this time. Even when we transition, there are still a bunch of things that we'd need to think about, so the current kfd node may stick around until we figure out a plan for those areas. E.g., the kfd node provides platform level compute topology information; e.g., the NUMA details for connected GPUs and CPUs, non-GPU compute node information, cache level topologies, etc. Alex > > Jason
Re: [PATCH 3/3] Revert "drm/amd/display: Limit max DSC target bpp for specific monitors"
@Daniel Vetter
, @Dave Airlie
Any objections taking this through the AMD tree or would you rather it
landed via drm-misc?
Thanks,
Alex
On Tue, Oct 25, 2022 at 10:21 AM Harry Wentland wrote:
>
> Series is
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> On 2022-10-24 15:22, Hamza Mahfooz wrote:
> > This reverts commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059.
> >
> > This quirk is now handled in the DRM core, so we can drop all of
> > the internal code that was added to handle it.
> >
> > Signed-off-by: Hamza Mahfooz
> > ---
> > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 35 ---
> > 1 file changed, 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > index 4956a0118215..a21e2ba77ddb 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > @@ -41,39 +41,6 @@
> > #include "dm_helpers.h"
> > #include "ddc_service_types.h"
> >
> > -struct monitor_patch_info {
> > - unsigned int manufacturer_id;
> > - unsigned int product_id;
> > - void (*patch_func)(struct dc_edid_caps *edid_caps, unsigned int
> > param);
> > - unsigned int patch_param;
> > -};
> > -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> > int param);
> > -
> > -static const struct monitor_patch_info monitor_patch_table[] = {
> > -{0x6D1E, 0x5BBF, set_max_dsc_bpp_limit, 15},
> > -{0x6D1E, 0x5B9A, set_max_dsc_bpp_limit, 15},
> > -};
> > -
> > -static void set_max_dsc_bpp_limit(struct dc_edid_caps *edid_caps, unsigned
> > int param)
> > -{
> > - if (edid_caps)
> > - edid_caps->panel_patch.max_dsc_target_bpp_limit = param;
> > -}
> > -
> > -static int amdgpu_dm_patch_edid_caps(struct dc_edid_caps *edid_caps)
> > -{
> > - int i, ret = 0;
> > -
> > - for (i = 0; i < ARRAY_SIZE(monitor_patch_table); i++)
> > - if ((edid_caps->manufacturer_id ==
> > monitor_patch_table[i].manufacturer_id)
> > - && (edid_caps->product_id ==
> > monitor_patch_table[i].product_id)) {
> > - monitor_patch_table[i].patch_func(edid_caps,
> > monitor_patch_table[i].patch_param);
> > - ret++;
> > - }
> > -
> > - return ret;
> > -}
> > -
> > /* dm_helpers_parse_edid_caps
> > *
> > * Parse edid caps
> > @@ -148,8 +115,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
> > kfree(sads);
> > kfree(sadb);
> >
> > - amdgpu_dm_patch_edid_caps(edid_caps);
> > -
> > return result;
> > }
> >
>
Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote: > E.g., the kfd node provides platform level compute > topology information; e.g., the NUMA details for connected GPUs and > CPUs, non-GPU compute node information, cache level topologies, etc. See, this is exactly what I'm talking about. What on earth does any of this have to do with DRM? We alread have places in the kernel that own and expose these kinds of information, drivers need to use them. Not re-invent them. Jason
Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices
On Tue, Oct 25, 2022 at 10:34 AM Jason Gunthorpe wrote: > > On Tue, Oct 25, 2022 at 10:21:34AM -0400, Alex Deucher wrote: > > > E.g., the kfd node provides platform level compute > > topology information; e.g., the NUMA details for connected GPUs and > > CPUs, non-GPU compute node information, cache level topologies, etc. > > See, this is exactly what I'm talking about. What on earth does any of > this have to do with DRM? At least for the GPU information it seems relevant. What value are acceleration device cache topologies outside of the subsytsem that uses them? > > We alread have places in the kernel that own and expose these kinds of > information, drivers need to use them. Not re-invent them. I don't disagree, but I'm not sure where the best place for these should be. Probably a lack of knowledge of where this should actually live and indifference from the maintainers of those areas since this use case doesn't match existing ones. Alex
Re: [PATCH v8] drm: Add initial ci/ subdirectory
Hi all, On Tue, 25 Oct 2022 at 08:32, Daniel Vetter wrote: > On Fri, 9 Sept 2022 at 19:18, Daniel Stone wrote: > > But equally - and sorry for not jumping on the IRC (?) discussion as I was > > in the middle of other stuff when it came up - I'm don't think this is the > > right plan. > > > > Mesa having all its CI in-tree makes sense, because merges happen rapidly > > to a single canonical tree. If the scripts need to be changed for whatever > > reason, we can merge something in under an hour and everyone immediately > > gets it. DRM is quite different though, given the forest of trees we have > > and the long merge paths between them. I worry that merging the CI scripts > > in-tree - especially for our initial attempt at it, when we're likely to > > need to make quite a lot of changes before it settles down to become a > > stable system that works for everyone - is shooting ourselves in the foot > > by limiting our flexibility. > > So the entire "we have multiple trees" is why I want at least the > gitlab-ci.yaml in tree, to force people to collaborate more on one > thing instead of everyone rolling their own fun and hacking stuff up. > And there's still tons of stuff outside in the separate repo, like the > lab status so Linus doesn't get a silly history of lab flapping. > > Also wrt "developers don't get the update right away due to > backmerge/pull delays", that's why integration trees like drm-tip or > linux-next exist. So maybe initially we should make sure the ci > patches go in through drm-misc, to maximize how many people see it. > And even for mesa it's not fully automatic, you still have the rebase > your branch if you picked a bad one for development (but yeah marge > does that if the MR is ready). If you're doing kernel development on a > linear tree instead of an integration tree, you're doing it very > wrong. > > What I think everyone agrees on is that we probably get the split > wrong and need to shuffle some files back&forth, and that's something > we need to warn Linus about I guess. But somewhere we do need a split > between internal and external stuff, and personally I'd like if at > least the pure sw testing (build and virtual stuff) could be all in > upstream. > > > Given that it's currently very dependent on fd.o infrastructure (published > > ci-templates, the registry, the specific-tag runners for Collabora/CrOS > > DUTs, etc), there isn't much of a portability gain in bringing the scripts > > into the tree either. It's a good goal, but not where we are today. > > I don't think there's huge chances for any non-fdo gitlab anytime > soon. Once we get there we might need to figure out how to standardize > the hw lab interfacing, and if we have all the sw targets in upstream > that should help with shuffling stuff around for a hypothetical LF > gitlab CI (or whatever it is). Yep, having talked through things on IRC, I'm happy with where we are; let's give it a go and find out. Acked-by: Daniel Stone Cheers, Daniel
Re: [Intel-gfx] [PATCH v4] drm/i915/slpc: Use platform limits for min/max frequency
On Mon, 24 Oct 2022 15:54:53 -0700, Vinay Belgaumkar wrote:
>
> GuC will set the min/max frequencies to theoretical max on
> ATS-M. This will break kernel ABI, so limit min/max frequency
> to RP0(platform max) instead.
>
> Also modify the SLPC selftest to update the min frequency
> when we have a server part so that we can iterate between
> platform min and max.
>
> v2: Check softlimits instead of platform limits (Riana)
> v3: More review comments (Ashutosh)
> v4: No need to use saved_min_freq and other comments (Ashutosh)
OK, much better now overall.
> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7030
>
> +static void update_server_min_softlimit(struct intel_guc_slpc *slpc)
> +{
> + /* For server parts, SLPC min will be at RPMax.
> + * Use min softlimit to clamp it to RP0 instead.
> + */
> + if (!slpc->min_freq_softlimit &&
> + is_slpc_min_freq_rpmax(slpc)) {
> + slpc->min_is_rpmax = true;
The only remaining issue is slpc->min_is_rpmax is now set but never used so
it can possibly be removed, or retained for debuggability (I think it's a
fair reason to retain it). Though I am not sure if we will hit a "variable
set but never used" error from these clever compilers.
> + slpc->min_freq_softlimit = slpc->rp0_freq;
> + (slpc_to_gt(slpc))->defaults.min_freq =
> slpc->min_freq_softlimit;
> + }
> +}
In any case, this is now:
Reviewed-by: Ashutosh Dixit
[PATCH v2 0/4] Add JDI LPM102A188A display panel support
Hello, These patches add support for the JDI LPM102A188A display panel, found in the Google Pixel C. Patch 1 adds the DT bindings for the panel. Patch 2 adds a register clear to the Tegra DSI driver, needed for the panel initialization commands to be properly sent. Patch 3 adds the panel driver, which is based on the downstream kernel driver published by Google and developed by Sean Paul. Patch 4 adds the DT node for the Google Pixel C. The first version of this patch series can be found at: https://lore.kernel.org/all/20220929170502.1034040-1-diogo@tecnico.ulisboa.pt/ Changes in v2: - Patch 1: remove touchscreen reset gpio property - Patch 2: clear register based on its value rather than a DT property - Patch 3: tune backlight delay values - Patch 4: add generic node names, remove underscores Thank you. Diogo Ivo (4): dt-bindings: display: Add bindings for JDI LPM102A188A drm/tegra: dsi: Clear enable register if powered by bootloader drm/panel: Add driver for JDI LPM102A188A arm64: dts: smaug: Add display panel node .../display/panel/jdi,lpm102a188a.yaml| 94 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 70 +++ drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c | 509 ++ drivers/gpu/drm/tegra/dsi.c | 9 + 6 files changed, 694 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml create mode 100644 drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c -- 2.38.1
[PATCH v2 1/4] dt-bindings: display: Add bindings for JDI LPM102A188A
The LPM102A188A is a 10.2" 2560x1800 IPS panel found in
the Google Pixel C.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- removed the touch screen property
.../display/panel/jdi,lpm102a188a.yaml| 94 +++
1 file changed, 94 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
b/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
new file mode 100644
index ..2f4d27a309a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/jdi,lpm102a188a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: JDI LPM102A188A 2560x1800 10.2" DSI Panel
+
+maintainers:
+ - Diogo Ivo
+
+description: |
+ This panel requires a dual-channel DSI host to operate. It supports two
modes:
+ - left-right: each channel drives the left or right half of the screen
+ - even-odd: each channel drives the even or odd lines of the screen
+
+ Each of the DSI channels controls a separate DSI peripheral. The peripheral
+ driven by the first link (DSI-LINK1) is considered the primary peripheral
+ and controls the device. The 'link2' property contains a phandle to the
+ peripheral driven by the second link (DSI-LINK2).
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: jdi,lpm102a188a
+
+ reg: true
+ enable-gpios: true
+ reset-gpios: true
+ power-supply: true
+ backlight: true
+
+ ddi-supply:
+description: The regulator that provides IOVCC (1.8V).
+
+ link2:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+ phandle to the DSI peripheral on the secondary link. Note that the
+ presence of this property marks the containing node as DSI-LINK1.
+
+required:
+ - compatible
+ - reg
+
+if:
+ required:
+- link2
+then:
+ required:
+- power-supply
+- ddi-supply
+- enable-gpios
+- reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+dsia: dsi@5430 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x0 0x5430 0x0 0x0004>;
+
+link2: panel@0 {
+compatible = "jdi,lpm102a188a";
+reg = <0>;
+};
+};
+
+dsib: dsi@5440{
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x0 0x5440 0x0 0x0004>;
+nvidia,ganged-mode = <&dsia>;
+
+link1: panel@0 {
+compatible = "jdi,lpm102a188a";
+reg = <0>;
+power-supply = <&pplcd_vdd>;
+ddi-supply = <&pp1800_lcdio>;
+enable-gpios = <&gpio TEGRA_GPIO(V, 1) GPIO_ACTIVE_HIGH>;
+reset-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>;
+link2 = <&link2>;
+backlight = <&backlight>;
+};
+};
+
+...
--
2.38.1
[PATCH v2 2/4] drm/tegra: dsi: Clear enable register if powered by bootloader
In cases where the DSI module is left on by the bootloader
some panels may fail to initialize if the enable register is not cleared
before the panel's initialization sequence is sent, so clear it if that
is the case.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- detect if the DSI module is on based on the register value,
instead of a DT property.
- remove Display Controller clear, since it is redundant.
drivers/gpu/drm/tegra/dsi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index de1333dc0d86..5954676a7ab1 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -912,6 +912,15 @@ static void tegra_dsi_encoder_enable(struct drm_encoder
*encoder)
u32 value;
int err;
+ /* If the bootloader enabled DSI it needs to be disabled
+* in order for the panel initialization commands to be
+* properly sent.
+*/
+ value = tegra_dsi_readl(dsi, DSI_POWER_CONTROL);
+
+ if (value & DSI_POWER_CONTROL_ENABLE)
+ tegra_dsi_disable(dsi);
+
err = tegra_dsi_prepare(dsi);
if (err < 0) {
dev_err(dsi->dev, "failed to prepare: %d\n", err);
--
2.38.1
[PATCH v2 3/4] drm/panel: Add driver for JDI LPM102A188A
The JDI LPM102A188A is a 2560x1800 IPS panel found in the Google Pixel C.
This driver is based on the downstream GPLv2 driver released by Google
written by Sean Paul [1], which was then adapted to the newer kernel APIs.
[1]:
https://android.googlesource.com/kernel/tegra/+/refs/heads/android-tegra-dragon-3.18-oreo/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
Signed-off-by: Diogo Ivo
---
Changes in v2:
- tuned backlight delays
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c | 509 ++
3 files changed, 521 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a582ddd583c2..80eda8f6bee0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -214,6 +214,17 @@ config DRM_PANEL_JDI_LT070ME05000
The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
24 bit per pixel.
+config DRM_PANEL_JDI_LPM102A188A
+ tristate "JDI LPM102A188A DSI panel"
+ depends on OF && GPIOLIB
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for JDI LPM102A188A DSI
+ control mode panel as found in Google Pixel C devices.
+ The panel has a 2560×1800 resolution. It provides a MIPI DSI interface
+ to the host.
+
config DRM_PANEL_JDI_R63452
tristate "JDI R63452 Full HD DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 34e717382dbb..2870cba96d14 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_EJ030NA) += panel-innolux-ej030na.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
+obj-$(CONFIG_DRM_PANEL_JDI_LPM102A188A) += panel-jdi-lpm102a188a.o
obj-$(CONFIG_DRM_PANEL_JDI_R63452) += panel-jdi-fhd-r63452.o
obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
b/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
new file mode 100644
index ..980af82ad6d6
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
@@ -0,0 +1,509 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * Copyright (C) 2022 Diogo Ivo
+ *
+ * Adapted from the downstream Pixel C driver written by Sean Paul
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+struct jdi_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link1;
+ struct mipi_dsi_device *link2;
+
+ struct regulator *supply;
+ struct regulator *ddi_supply;
+ struct backlight_device *backlight;
+
+ struct gpio_desc *enable_gpio;
+ struct gpio_desc *reset_gpio;
+
+ const struct drm_display_mode *mode;
+
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct jdi_panel *to_panel_jdi(struct drm_panel *panel)
+{
+ return container_of(panel, struct jdi_panel, base);
+}
+
+static void jdi_wait_frames(struct jdi_panel *jdi, unsigned int frames)
+{
+ unsigned int refresh = drm_mode_vrefresh(jdi->mode);
+
+ if (WARN_ON(frames > refresh))
+ return;
+
+ msleep(1000 / (refresh / frames));
+}
+
+static int jdi_panel_disable(struct drm_panel *panel)
+{
+ struct jdi_panel *jdi = to_panel_jdi(panel);
+
+ if (!jdi->enabled)
+ return 0;
+
+ backlight_disable(jdi->backlight);
+
+ jdi_wait_frames(jdi, 2);
+
+ jdi->enabled = false;
+
+ return 0;
+}
+
+static int jdi_panel_unprepare(struct drm_panel *panel)
+{
+ struct jdi_panel *jdi = to_panel_jdi(panel);
+ int ret;
+
+ if (!jdi->prepared)
+ return 0;
+
+ ret = mipi_dsi_dcs_set_display_off(jdi->link1);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to set display off: %d\n", ret);
+ ret = mipi_dsi_dcs_set_display_off(jdi->link2);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to set display off: %d\n", ret);
+
+ /* Specified by JDI @ 50ms, subject to change */
+ msleep(50);
+
+ ret = mipi_dsi_dcs_enter_sleep_mode(jdi->link1);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
+ ret = mipi_dsi_dcs_enter_sleep_mode(jdi->link2);
+ if (ret < 0)
+ dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
+
+ /* Specified by JDI @ 150ms, subject to change */
+ ms
[PATCH v2 4/4] arm64: dts: smaug: Add display panel node
The Google Pixel C has a JDI LPM102A188A display panel. Add a
DT node for it. Tested on Pixel C.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- renamed backlight node to a generic name
- removed underscores
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 70 +++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
index 84ec4d8b7f10..5db0b25c8d58 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
@@ -31,6 +31,37 @@ memory {
};
host1x@5000 {
+ dc@5420 {
+ status = "okay";
+ };
+
+ dsia: dsi@5430 {
+ avdd-dsi-csi-supply = <&vdd_dsi_csi>;
+ status = "okay";
+
+ link2: panel@0 {
+ compatible = "jdi,lpm102a188a";
+ reg = <0>;
+ };
+ };
+
+ dsib: dsi@5440 {
+ avdd-dsi-csi-supply = <&vdd_dsi_csi>;
+ nvidia,ganged-mode = <&dsia>;
+ status = "okay";
+
+ link1: panel@0 {
+ compatible = "jdi,lpm102a188a";
+ reg = <0>;
+ power-supply = <&pplcd_vdd>;
+ ddi-supply = <&pp1800_lcdio>;
+ enable-gpios = <&gpio TEGRA_GPIO(V, 1)
GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio TEGRA_GPIO(V, 2)
GPIO_ACTIVE_LOW>;
+ link2 = <&link2>;
+ backlight = <&backlight>;
+ };
+ };
+
dpaux: dpaux@545c {
status = "okay";
};
@@ -1627,6 +1658,37 @@ nau8825@1a {
status = "okay";
};
+ backlight: backlight@2c {
+ compatible = "ti,lp8557";
+ reg = <0x2c>;
+ power-supply = <&pplcd_vdd>;
+ enable-supply = <&pp1800_lcdio>;
+ bl-name = "lp8557-backlight";
+ dev-ctrl = /bits/ 8 <0x01>;
+ init-brt = /bits/ 8 <0x80>;
+
+ /* Full scale current, 20mA */
+ rom-11h {
+ rom-addr = /bits/ 8 <0x11>;
+ rom-val = /bits/ 8 <0x05>;
+ };
+ /* Frequency = 4.9kHz, magic undocumented val */
+ rom-12h {
+ rom-addr = /bits/ 8 <0x12>;
+ rom-val = /bits/ 8 <0x29>;
+ };
+ /* Boost freq = 1MHz, BComp option = 1 */
+ rom-13h {
+ rom-addr = /bits/ 8 <0x13>;
+ rom-val = /bits/ 8 <0x03>;
+ };
+ /* 4V OV, 6 output LED string enabled */
+ rom-14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xbf>;
+ };
+ };
+
audio-codec@2d {
compatible = "realtek,rt5677";
reg = <0x2d>;
@@ -1908,4 +1970,12 @@ usbc_vbus: regulator-usbc-vbus {
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ vdd_dsi_csi: regulator-vdd-dsi-csi {
+ compatible = "regulator-fixed";
+ regulator-name = "AVDD_DSI_CSI_1V2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ vin-supply = <&pp1200_avdd>;
+ };
};
--
2.38.1
[PATCH] drm/panel: khadas-ts050: update timings to achieve 60Hz refresh rate
From: Neil Armstrong
This updates the panel timings to achieve a clean 60Hz refresh rate.
Signed-off-by: Neil Armstrong
---
To: Sam Ravnborg
To: David Airlie
To: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/panel/panel-khadas-ts050.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c
b/drivers/gpu/drm/panel/panel-khadas-ts050.c
index 1ab1ebe30882..e0cebfa14b36 100644
--- a/drivers/gpu/drm/panel/panel-khadas-ts050.c
+++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
@@ -568,7 +568,7 @@ static const struct khadas_ts050_panel_cmd init_code[] = {
{0xfb, 0x01},
/* Select CMD1 */
{0xff, 0x00},
- {0xd3, 0x05}, /* RGBMIPICTRL: VSYNC back porch = 5 */
+ {0xd3, 0x22}, /* RGBMIPICTRL: VSYNC back porch = 34 */
{0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
};
@@ -717,15 +717,15 @@ static int khadas_ts050_panel_disable(struct drm_panel
*panel)
}
static const struct drm_display_mode default_mode = {
- .clock = 12,
- .hdisplay = 1088,
- .hsync_start = 1088 + 104,
- .hsync_end = 1088 + 104 + 4,
- .htotal = 1088 + 104 + 4 + 127,
+ .clock = 16,
+ .hdisplay = 1080,
+ .hsync_start = 1080 + 117,
+ .hsync_end = 1080 + 117 + 5,
+ .htotal = 1080 + 117 + 5 + 160,
.vdisplay = 1920,
- .vsync_start = 1920 + 4,
- .vsync_end = 1920 + 4 + 2,
- .vtotal = 1920 + 4 + 2 + 3,
+ .vsync_start = 1920 + 4 ,
+ .vsync_end = 1920 + 4 + 3,
+ .vtotal = 1920 + 4 + 3 + 31 ,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
---
base-commit: 247f34f7b80357943234f93f247a1ae6b6c3a740
change-id: 20221025-ts050-timings-2fb4b034a268
Best regards,
--
Neil Armstrong
[PATCH v2] drm/ttm: rework on ttm_resource to use size_t type
Change ttm_resource structure from num_pages to size_t size in bytes.
v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages
v1 -> v2: change bo->resource->size to bo->base.size at some places
v1 -> v2: remove the local variable
v1 -> v2: cleanup cmp_size_smaller_first()
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 7 +--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++---
include/drm/ttm/ttm_resource.h | 4 ++--
38 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..974e85d8b6cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.base.size), &bo->kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
goto fallback;
- BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
+ BUG_ON(start + size > res->size);
cur->mem_type = res->mem_type;
@@ -110,7 +110,7 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
cur->size = size;
cur->remaining = size;
cur->node = NULL;
- WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+ WARN_ON(res && start + size > res->size);
[Bug 216625] New: [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 Bug ID: 216625 Summary: [regression] GPU lockup on Radeon R7 Kaveri Product: Drivers Version: 2.5 Kernel Version: 5.19.16-100.fc35.x86_64 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: pierre-bugzi...@ossman.eu Regression: No Created attachment 303084 --> https://bugzilla.kernel.org/attachment.cgi?id=303084&action=edit dmesg since problems began Ever since I upgraded from Fedora 34 to Fedora 35 I've gotten random GPU lockups. This machine has otherwise been stable for years. I don't really know what triggers the issue. I *think* it happens in some cases when I try to play a video in Firefox, but I'm not completely sure. Reported here, but Fedora generally don't give any attention to GPU driver issues: https://bugzilla.redhat.com/show_bug.cgi?id=2131923 Last working system: kernel-5.13.8-100.fc33.x86_64 libglvnd-1:1.3.3-1.fc34.x86_64 mesa-libGL-21.1.8-3.fc34.x86_64 libdrm-2.4.109-1.fc34.x86_64 xorg-x11-server-Xorg-1.20.14-3.fc34.x86_64 First broken system: kernel-5.19.8-100.fc35.x86_64 libglvnd-1:1.3.4-2.fc35.x86_64 mesa-libGL-21.3.9-1.fc35.x86_64 libdrm-2.4.110-1.fc35.x86_64 xorg-x11-server-Xorg-1.20.14-7.fc35.x86_64 Attached is all kernel logs since the issue started happening. It also includes a fresh boot from the last good kernel, and a good run with the new kernel. I think that first run with the new kernel was just a fluke, though. The only package upgraded after the system upgrade and before the lockups started is annobin. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 Pierre Ossman (pierre-bugzi...@ossman.eu) changed: What|Removed |Added Tree|Mainline|Fedora -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 1/2] drm: remove DRM_MINOR_CONTROL
Am 25.10.22 um 15:59 schrieb Michał Winiarski:
On Tue, Oct 11, 2022 at 01:55:01PM +0200, Christian König wrote:
Am 11.10.22 um 13:39 schrieb Simon Ser:
On Tuesday, October 11th, 2022 at 13:04, Christian König
wrote:
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -54,7 +54,6 @@ struct file;
*/
enum drm_minor_type {
DRM_MINOR_PRIMARY,
- DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
};
This makes me uncomfortable: this enum no longer matches DRM_NODE_* in
libdrm.
Ah! There it was! I was remembering in the back of my head that we had
somehow used this in libdrm as well, but couldn't really get where exactly.
But I don't really see a problem here. The control nodes are identified by
name and we don't expose them for quite some time now without any negative
impact.
Even the minor number distribution stays the same. So what bad can come from
this?
Thanks,
Christian.
I proposed something similar in:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20220817230600.272790-1-michal.winiarski%40intel.com%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C085831b6e1b647ca1dbd08dab6911b4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023031607291573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=56FxZ4UThGlbJ0ut8biicsYtIvtTZ8RGHISJqe%2BXixY%3D&reserved=0
except acompanied by expanding the minor pool to accomodate more than
128 devices:
And after receiving similar feedback, that eventually evolved into
leaving the "legacy minors" alone, and changing the rules only for cases
where we have more than 64 devices (when we run out of the "legacy
minors").
Perhaps something like this:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20220911211443.581481-1-michal.winiarski%40intel.com%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C085831b6e1b647ca1dbd08dab6911b4b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023031607291573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dFRTx0%2Fi7a4aps57JWGtEJ6GoW5IfI5CQjFkig4KFnA%3D&reserved=0
Would work for your usecase as well?
We don't desperately need the additional minor numbers, this was merely
just a cleanup to remove an unused define.
Christian.
-Michał
Re: IMX6 etnaviv issue
On Sat, Oct 22, 2022 at 7:06 PM Chris Healy wrote: > > I can't speak to why you are experiencing issues when using the GPU, > but in the examples you gave, the example that is working is using a > SW based GL implementation instead of the real GPU. This can be > determined by looking at the GL_RENDERER string to see if it mentions > a Vivante GPU or something else (like LLVMPIPE). It's quite likely > that if you were using the real GPU with etnaviv in Mesa with the > older config you would also experience similar issues. As such, we > shouldn't consider this a regression between the two Ubuntu versions. Chris, Thanks for this insight. I was curious about the meaning of the GL_RENDERER string which is why I included that. I'm not clear how to configure what renderer is used? Best Regards, Tim > > One thing you may want to try doing is run with Mesa 22.2.1 and TOT to > see if either of these address any of the issues you are experiencing. > > On Thu, Oct 20, 2022 at 1:44 PM Tim Harvey wrote: > > > > Greetings, > > > > I use a standard Ubuntu 20.04 focal rootfs with a mainline kernel on > > an IMX6Q based board and have had no issues using things like gnome > > desktop, glxgears, glmark2 however recently I updated the rootfs to > > Ubuntu 22.04 jammy using the same mainline kernel and now I see some > > issues. I've replicated the issue with several kernel versions > > including 5.4, 5.10, 5.15 and 6.0 so I would say this is not a kernel > > regression but something related to the graphics stack being used > > which I'm not very familiar with. > > > > The issues I see can be described as: > > - mouse cursor is incorrect (looks like a hatched square) > > - glxgears shows some sort of sync/jitter issue and has a fairly low > > framerate > > - glmark2 shows a some sync issues then after a few seconds results in > > a GPU hang > > > > My ubuntu focal image that appears to work fine has the following: > > gnome 3.36.5-0 > > xserver-xorg 1:7.7+19 > > xserver-xorg-core 2:1.20.13-1 > > xwayland 2:1.20.13-1 > > glmark2 2021.02 > > mesa-utils 8.4.0-1 > > GL_VENDOR: Mesa/X.org > > GL_RENDERER: llvmpipe (LLVM 12.0.0, 128 bits) > > GL_VERSION: 3.1 Mesa 21.2.6 > > > > My ubuntu jammy image that has the issues has the following: > > gnome-41.7-0 > > xserver-xorg 1:7.7+23 > > xserver-xorg-core 2:21.1.3-2 > > xwayland 2:22.1.1-1 > > glmark2 2021.02-0 > > mesa-utils 8.4.0-1 > > GL_VENDOR: etnaviv > > GL_RENDERER: Vivantte GC2000 rev 5108 > > GL_VERSION: 2.1 Mesa 22.0.5 > > > > Does anyone have any ideas on what might be going on here? I apologize > > for my lack of knowledge regarding the software layers on top of the > > etnaviv kernel driver being used here. > > > > Best Regards, > > > > Tim
[Bug 216625] [regression] GPU lockup on Radeon R7 Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=216625 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Any chance you could bisect? There have been very few changes to the radeon kernel driver over the last few years. I could also be a mesa regression. Does upgrading or downgrading mesa help? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2] drm/ttm: rework on ttm_resource to use size_t type
Am 25.10.22 um 17:50 schrieb Somalapuram Amaranath:
Change ttm_resource structure from num_pages to size_t size in bytes.
v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages
v1 -> v2: change bo->resource->size to bo->base.size at some places
v1 -> v2: remove the local variable
v1 -> v2: cleanup cmp_size_smaller_first()
Of hand that looks good to me now.
It would be nice if we keep the separation of one patch for each driver.
But that would mean we need something like adding the size field first,
patch all drivers and then remove num_pages which isn't a good approach
either.
But please make sure that the Intel CI systems are happy with that.
Signed-off-by: Somalapuram Amaranath
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 7 +--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++---
include/drm/ttm/ttm_resource.h | 4 ++--
38 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..974e85d8b6cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.base.size), &bo->kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
Re: [Intel-gfx] [PATCH v2] drm/ttm: rework on ttm_resource to use size_t type
On Tue, 25 Oct 2022 at 16:51, Somalapuram Amaranath wrote: > > Change ttm_resource structure from num_pages to size_t size in bytes. > v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages > v1 -> v2: change bo->resource->size to bo->base.size at some places > v1 -> v2: remove the local variable > v1 -> v2: cleanup cmp_size_smaller_first() > > Signed-off-by: Somalapuram Amaranath > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 > drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +- > drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++-- > drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++-- > drivers/gpu/drm/i915/intel_region_ttm.c| 2 +- > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++--- > drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- > drivers/gpu/drm/radeon/radeon_cs.c | 7 +-- > drivers/gpu/drm/radeon/radeon_object.c | 4 ++-- > drivers/gpu/drm/radeon/radeon_trace.h | 2 +- > drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++-- > drivers/gpu/drm/ttm/ttm_bo.c | 3 --- > drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++--- > drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++-- > drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +- > drivers/gpu/drm/ttm/ttm_resource.c | 14 ++ > drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++-- > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++--- > drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++--- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++--- > include/drm/ttm/ttm_resource.h | 4 ++-- > 38 files changed, 79 insertions(+), 81 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c > index 38119311284d..f86dc92965bb 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c > @@ -217,7 +217,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf, > page_last = vma_pages(vma) + vma->vm_pgoff - > drm_vma_node_start(&bo->base.vma_node); > > - if (unlikely(page_offset >= bo->resource->num_pages)) > + if (unlikely(page_offset >= bo->base.size)) At a glance it looks like we are missing PFN_UP(bo->base.size) for this one?
Re: [PATCH] drm/scheduler: set current_entity to next when remove from rq
Looking... Regards, Luben On 2022-10-25 09:35, Alex Deucher wrote: > + Luben > > On Tue, Oct 25, 2022 at 2:55 AM brolerliew wrote: >> >> When entity move from one rq to another, current_entity will be set to NULL >> if it is the moving entity. This make entities close to rq head got >> selected more frequently, especially when doing load balance between >> multiple drm_gpu_scheduler. >> >> Make current_entity to next when removing from rq. >> >> Signed-off-by: brolerliew >> --- >> drivers/gpu/drm/scheduler/sched_main.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >> b/drivers/gpu/drm/scheduler/sched_main.c >> index 2fab218d7082..00b22cc50f08 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -168,10 +168,11 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq >> *rq, >> spin_lock(&rq->lock); >> >> atomic_dec(rq->sched->score); >> - list_del_init(&entity->list); >> >> if (rq->current_entity == entity) >> - rq->current_entity = NULL; >> + rq->current_entity = list_next_entry(entity, list); >> + >> + list_del_init(&entity->list); >> >> if (drm_sched_policy == DRM_SCHED_POLICY_FIFO) >> drm_sched_rq_remove_fifo_locked(entity); >> -- >> 2.34.1 >>
[PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
This legacy module knob has become uAPI, when set on the vfio_iommu_type1
it disables some security protections in the iommu drivers. Move the
storage for this knob to vfio_main.c so that iommufd can access it too.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.h | 2 ++
drivers/vfio/vfio_iommu_type1.c | 5 ++---
drivers/vfio/vfio_main.c| 3 +++
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index f95f4925b83bbd..54e5a8e0834ccb 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -130,4 +130,6 @@ extern bool vfio_noiommu __read_mostly;
enum { vfio_noiommu = false };
#endif
+extern bool vfio_allow_unsafe_interrupts;
+
#endif
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 23c24fe98c00d4..186e33a006d314 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -44,9 +44,8 @@
#define DRIVER_AUTHOR "Alex Williamson "
#define DRIVER_DESC "Type1 IOMMU driver for VFIO"
-static bool allow_unsafe_interrupts;
module_param_named(allow_unsafe_interrupts,
- allow_unsafe_interrupts, bool, S_IRUGO | S_IWUSR);
+ vfio_allow_unsafe_interrupts, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(allow_unsafe_interrupts,
"Enable VFIO IOMMU support for on platforms without interrupt
remapping support.");
@@ -2282,7 +2281,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
iommu_group_for_each_dev(iommu_group, (void
*)IOMMU_CAP_INTR_REMAP,
vfio_iommu_device_capable);
- if (!allow_unsafe_interrupts && !msi_remap) {
+ if (!vfio_allow_unsafe_interrupts && !msi_remap) {
pr_warn("%s: No interrupt remapping support. Use the module
param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this
platform\n",
__func__);
ret = -EPERM;
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 8d809ecd982b39..1e414b2c48a511 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -51,6 +51,9 @@ static struct vfio {
struct ida device_ida;
} vfio;
+bool vfio_allow_unsafe_interrupts;
+EXPORT_SYMBOL_GPL(vfio_allow_unsafe_interrupts);
+
static DEFINE_XARRAY(vfio_device_set_xa);
static const struct file_operations vfio_group_fops;
--
2.38.0
[PATCH 03/10] vfio: Rename vfio_device_assign/unassign_container()
These functions don't really assign anything anymore, they just increment
some refcounts and do a sanity check. Call them
vfio_group_[un]use_container()
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/container.c | 14 ++
drivers/vfio/vfio.h | 4 ++--
drivers/vfio/vfio_main.c | 6 +++---
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index dd79a66ec62cad..499777930b08fa 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -511,10 +511,8 @@ void vfio_group_detach_container(struct vfio_group *group)
vfio_container_put(container);
}
-int vfio_device_assign_container(struct vfio_device *device)
+int vfio_group_use_container(struct vfio_group *group)
{
- struct vfio_group *group = device->group;
-
lockdep_assert_held(&group->group_lock);
if (!group->container || !group->container->iommu_driver ||
@@ -529,13 +527,13 @@ int vfio_device_assign_container(struct vfio_device
*device)
return 0;
}
-void vfio_device_unassign_container(struct vfio_device *device)
+void vfio_group_unuse_container(struct vfio_group *group)
{
- lockdep_assert_held_write(&device->group->group_lock);
+ lockdep_assert_held(&group->group_lock);
- WARN_ON(device->group->container_users <= 1);
- device->group->container_users--;
- fput(device->group->opened_file);
+ WARN_ON(group->container_users <= 1);
+ group->container_users--;
+ fput(group->opened_file);
}
/*
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index bcad54bbab08c4..f95f4925b83bbd 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -112,8 +112,8 @@ void vfio_unregister_iommu_driver(const struct
vfio_iommu_driver_ops *ops);
bool vfio_assert_device_open(struct vfio_device *device);
struct vfio_container *vfio_container_from_file(struct file *filep);
-int vfio_device_assign_container(struct vfio_device *device);
-void vfio_device_unassign_container(struct vfio_device *device);
+int vfio_group_use_container(struct vfio_group *group);
+void vfio_group_unuse_container(struct vfio_group *group);
int vfio_container_attach_group(struct vfio_container *container,
struct vfio_group *group);
void vfio_group_detach_container(struct vfio_group *group);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 204443ba3b3cd9..8d809ecd982b39 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,7 +749,7 @@ static int vfio_device_first_open(struct vfio_device
*device)
* it during close_device.
*/
mutex_lock(&device->group->group_lock);
- ret = vfio_device_assign_container(device);
+ ret = vfio_group_use_container(device->group);
if (ret)
goto err_module_put;
@@ -764,7 +764,7 @@ static int vfio_device_first_open(struct vfio_device
*device)
return 0;
err_container:
- vfio_device_unassign_container(device);
+ vfio_group_unuse_container(device->group);
err_module_put:
device->kvm = NULL;
mutex_unlock(&device->group->group_lock);
@@ -781,7 +781,7 @@ static void vfio_device_last_close(struct vfio_device
*device)
if (device->ops->close_device)
device->ops->close_device(device);
device->kvm = NULL;
- vfio_device_unassign_container(device);
+ vfio_group_unuse_container(device->group);
mutex_unlock(&device->group->group_lock);
module_put(device->dev->driver->owner);
}
--
2.38.0
[PATCH 00/10] Connect VFIO to IOMMUFD
This series provides an alternative container layer for VFIO implemented using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will not be compiled in. At this point iommufd can be injected by passing in a iommfd FD to VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd to obtain the compat IOAS and then connect up all the VFIO drivers as appropriate. This is temporary stopping point, a following series will provide a way to directly open a VFIO device FD and directly connect it to IOMMUFD using native ioctls that can expose the IOMMUFD features like hwpt, future vPASID and dynamic attachment. This series, in compat mode, has passed all the qemu tests we have available, including the test suites for the Intel GVT mdev. Aside from the temporary limitation with P2P memory this is belived to be fully compatible with VFIO. This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd It requires the iommufd series: https://lore.kernel.org/r/0-v3-402a7d6459de+24b-iommufd_...@nvidia.com Jason Gunthorpe (10): vfio: Move vfio_device driver open/close code to a function vfio: Move vfio_device_assign_container() into vfio_device_first_open() vfio: Rename vfio_device_assign/unassign_container() vfio: Move storage of allow_unsafe_interrupts to vfio_main.c vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent() vfio-iommufd: Allow iommufd to be used in place of a container fd vfio-iommufd: Support iommufd for physical VFIO devices vfio-iommufd: Support iommufd for emulated VFIO devices vfio: Make vfio_container optionally compiled iommufd: Allow iommufd to supply /dev/vfio/vfio drivers/gpu/drm/i915/gvt/kvmgt.c | 3 + drivers/iommu/iommufd/Kconfig | 12 + drivers/iommu/iommufd/main.c | 35 +- drivers/s390/cio/vfio_ccw_ops.c | 3 + drivers/s390/crypto/vfio_ap_ops.c | 3 + drivers/vfio/Kconfig | 38 ++- drivers/vfio/Makefile | 5 +- drivers/vfio/container.c | 136 ++-- drivers/vfio/fsl-mc/vfio_fsl_mc.c | 3 + drivers/vfio/iommufd.c| 161 + .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 6 + drivers/vfio/pci/mlx5/main.c | 3 + drivers/vfio/pci/vfio_pci.c | 3 + drivers/vfio/platform/vfio_amba.c | 3 + drivers/vfio/platform/vfio_platform.c | 3 + drivers/vfio/vfio.h | 100 +- drivers/vfio/vfio_iommu_type1.c | 5 +- drivers/vfio/vfio_main.c | 318 ++ include/linux/vfio.h | 39 +++ 19 files changed, 681 insertions(+), 198 deletions(-) create mode 100644 drivers/vfio/iommufd.c base-commit: 3bec937e94942a6aee8854be1c1f5cc2b92d15e2 -- 2.38.0
[PATCH 05/10] vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent()
iommufd doesn't establish the iommu_domains until after the device FD is
opened, even if the container has been set. This design is part of moving
away from the group centric iommu APIs.
This is fine, except that the normal sequence of establishing the kvm
wbindv won't work:
group = open("/dev/vfio/XX")
ioctl(group, VFIO_GROUP_SET_CONTAINER)
ioctl(kvm, KVM_DEV_VFIO_GROUP_ADD)
ioctl(group, VFIO_GROUP_GET_DEVICE_FD)
As the domains don't start existing until GET_DEVICE_FD. Further,
GET_DEVICE_FD requires that KVM_DEV_VFIO_GROUP_ADD already be done as that
is what sets the group->kvm and thus device->kvm for the driver to use
during open.
Now that we have device centric cap ops and the new
IOMMU_CAP_ENFORCE_CACHE_COHERENCY we know what the iommu_domain will be
capable of without having to create it. Use this to compute
vfio_file_enforced_coherent() and resolve the ordering problems.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/container.c | 5 +++--
drivers/vfio/vfio.h | 2 --
drivers/vfio/vfio_main.c | 27 ++-
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index 499777930b08fa..d97747dfb05d02 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -188,8 +188,9 @@ void vfio_device_container_unregister(struct vfio_device
*device)
device->group->container->iommu_data, device);
}
-long vfio_container_ioctl_check_extension(struct vfio_container *container,
- unsigned long arg)
+static long
+vfio_container_ioctl_check_extension(struct vfio_container *container,
+unsigned long arg)
{
struct vfio_iommu_driver *driver;
long ret = 0;
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 54e5a8e0834ccb..247590334e14b0 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -119,8 +119,6 @@ int vfio_container_attach_group(struct vfio_container
*container,
void vfio_group_detach_container(struct vfio_group *group);
void vfio_device_container_register(struct vfio_device *device);
void vfio_device_container_unregister(struct vfio_device *device);
-long vfio_container_ioctl_check_extension(struct vfio_container *container,
- unsigned long arg);
int __init vfio_container_init(void);
void vfio_container_cleanup(void);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 1e414b2c48a511..a8d1fbfcc3ddad 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -1625,24 +1625,25 @@ EXPORT_SYMBOL_GPL(vfio_file_is_group);
bool vfio_file_enforced_coherent(struct file *file)
{
struct vfio_group *group = file->private_data;
- bool ret;
+ struct vfio_device *device;
+ bool ret = true;
if (!vfio_file_is_group(file))
return true;
- mutex_lock(&group->group_lock);
- if (group->container) {
- ret = vfio_container_ioctl_check_extension(group->container,
- VFIO_DMA_CC_IOMMU);
- } else {
- /*
-* Since the coherency state is determined only once a container
-* is attached the user must do so before they can prove they
-* have permission.
-*/
- ret = true;
+ /*
+* If the device does not have IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
+* any domain later attached to it will also not support it.
+*/
+ mutex_lock(&group->device_lock);
+ list_for_each_entry(device, &group->device_list, group_next) {
+ if (!device_iommu_capable(device->dev,
+ IOMMU_CAP_ENFORCE_CACHE_COHERENCY)) {
+ ret = false;
+ break;
+ }
}
- mutex_unlock(&group->group_lock);
+ mutex_unlock(&group->device_lock);
return ret;
}
EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
--
2.38.0
[PATCH 02/10] vfio: Move vfio_device_assign_container() into vfio_device_first_open()
The only thing this function does is assert the group has an assigned
container and incrs refcounts.
The overall model we have is that once a conatiner_users refcount is
incremented it cannot be de-assigned from the group -
vfio_group_ioctl_unset_container() will fail and the group FD cannot be
closed.
Thus we do not need to check this on evey device FD open, just the
first. Reorganize the code so that only the first open and last close
manages the container.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/container.c | 4 ++--
drivers/vfio/vfio_main.c | 18 --
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index d74164abbf401d..dd79a66ec62cad 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -531,11 +531,11 @@ int vfio_device_assign_container(struct vfio_device
*device)
void vfio_device_unassign_container(struct vfio_device *device)
{
- mutex_lock(&device->group->group_lock);
+ lockdep_assert_held_write(&device->group->group_lock);
+
WARN_ON(device->group->container_users <= 1);
device->group->container_users--;
fput(device->group->opened_file);
- mutex_unlock(&device->group->group_lock);
}
/*
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index d043383fc3ba2b..204443ba3b3cd9 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,16 +749,22 @@ static int vfio_device_first_open(struct vfio_device
*device)
* it during close_device.
*/
mutex_lock(&device->group->group_lock);
+ ret = vfio_device_assign_container(device);
+ if (ret)
+ goto err_module_put;
+
device->kvm = device->group->kvm;
if (device->ops->open_device) {
ret = device->ops->open_device(device);
if (ret)
- goto err_module_put;
+ goto err_container;
}
vfio_device_container_register(device);
mutex_unlock(&device->group->group_lock);
return 0;
+err_container:
+ vfio_device_unassign_container(device);
err_module_put:
device->kvm = NULL;
mutex_unlock(&device->group->group_lock);
@@ -775,6 +781,7 @@ static void vfio_device_last_close(struct vfio_device
*device)
if (device->ops->close_device)
device->ops->close_device(device);
device->kvm = NULL;
+ vfio_device_unassign_container(device);
mutex_unlock(&device->group->group_lock);
module_put(device->dev->driver->owner);
}
@@ -784,12 +791,6 @@ static struct file *vfio_device_open(struct vfio_device
*device)
struct file *filep;
int ret;
- mutex_lock(&device->group->group_lock);
- ret = vfio_device_assign_container(device);
- mutex_unlock(&device->group->group_lock);
- if (ret)
- return ERR_PTR(ret);
-
mutex_lock(&device->dev_set->lock);
device->open_count++;
if (device->open_count == 1) {
@@ -833,7 +834,6 @@ static struct file *vfio_device_open(struct vfio_device
*device)
err_unassign_container:
device->open_count--;
mutex_unlock(&device->dev_set->lock);
- vfio_device_unassign_container(device);
return ERR_PTR(ret);
}
@@ -1040,8 +1040,6 @@ static int vfio_device_fops_release(struct inode *inode,
struct file *filep)
device->open_count--;
mutex_unlock(&device->dev_set->lock);
- vfio_device_unassign_container(device);
-
vfio_device_put_registration(device);
return 0;
--
2.38.0
[PATCH 01/10] vfio: Move vfio_device driver open/close code to a function
This error unwind is getting complicated. Move all the code into two
pair'd function. The functions should be called when the open_count == 1
after incrementing/before decrementing.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio_main.c | 95 ++--
1 file changed, 53 insertions(+), 42 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 2d168793d4e1ce..d043383fc3ba2b 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -734,6 +734,51 @@ bool vfio_assert_device_open(struct vfio_device *device)
return !WARN_ON_ONCE(!READ_ONCE(device->open_count));
}
+static int vfio_device_first_open(struct vfio_device *device)
+{
+ int ret;
+
+ lockdep_assert_held(&device->dev_set->lock);
+
+ if (!try_module_get(device->dev->driver->owner))
+ return -ENODEV;
+
+ /*
+* Here we pass the KVM pointer with the group under the read lock. If
+* the device driver will use it, it must obtain a reference and release
+* it during close_device.
+*/
+ mutex_lock(&device->group->group_lock);
+ device->kvm = device->group->kvm;
+ if (device->ops->open_device) {
+ ret = device->ops->open_device(device);
+ if (ret)
+ goto err_module_put;
+ }
+ vfio_device_container_register(device);
+ mutex_unlock(&device->group->group_lock);
+ return 0;
+
+err_module_put:
+ device->kvm = NULL;
+ mutex_unlock(&device->group->group_lock);
+ module_put(device->dev->driver->owner);
+ return ret;
+}
+
+static void vfio_device_last_close(struct vfio_device *device)
+{
+ lockdep_assert_held(&device->dev_set->lock);
+
+ mutex_lock(&device->group->group_lock);
+ vfio_device_container_unregister(device);
+ if (device->ops->close_device)
+ device->ops->close_device(device);
+ device->kvm = NULL;
+ mutex_unlock(&device->group->group_lock);
+ module_put(device->dev->driver->owner);
+}
+
static struct file *vfio_device_open(struct vfio_device *device)
{
struct file *filep;
@@ -745,29 +790,12 @@ static struct file *vfio_device_open(struct vfio_device
*device)
if (ret)
return ERR_PTR(ret);
- if (!try_module_get(device->dev->driver->owner)) {
- ret = -ENODEV;
- goto err_unassign_container;
- }
-
mutex_lock(&device->dev_set->lock);
device->open_count++;
if (device->open_count == 1) {
- /*
-* Here we pass the KVM pointer with the group under the read
-* lock. If the device driver will use it, it must obtain a
-* reference and release it during close_device.
-*/
- mutex_lock(&device->group->group_lock);
- device->kvm = device->group->kvm;
-
- if (device->ops->open_device) {
- ret = device->ops->open_device(device);
- if (ret)
- goto err_undo_count;
- }
- vfio_device_container_register(device);
- mutex_unlock(&device->group->group_lock);
+ ret = vfio_device_first_open(device);
+ if (ret)
+ goto err_unassign_container;
}
mutex_unlock(&device->dev_set->lock);
@@ -800,20 +828,11 @@ static struct file *vfio_device_open(struct vfio_device
*device)
err_close_device:
mutex_lock(&device->dev_set->lock);
- mutex_lock(&device->group->group_lock);
- if (device->open_count == 1 && device->ops->close_device) {
- device->ops->close_device(device);
-
- vfio_device_container_unregister(device);
- }
-err_undo_count:
- mutex_unlock(&device->group->group_lock);
+ if (device->open_count == 1)
+ vfio_device_last_close(device);
+err_unassign_container:
device->open_count--;
- if (device->open_count == 0 && device->kvm)
- device->kvm = NULL;
mutex_unlock(&device->dev_set->lock);
- module_put(device->dev->driver->owner);
-err_unassign_container:
vfio_device_unassign_container(device);
return ERR_PTR(ret);
}
@@ -1016,19 +1035,11 @@ static int vfio_device_fops_release(struct inode
*inode, struct file *filep)
mutex_lock(&device->dev_set->lock);
vfio_assert_device_open(device);
- mutex_lock(&device->group->group_lock);
- if (device->open_count == 1 && device->ops->close_device)
- device->ops->close_device(device);
-
- vfio_device_container_unregister(device);
- mutex_unlock(&device->group->group_lock);
+ if (device->open_count == 1)
+ vfio_device_last_close(device);
device->open_count--;
- if (device->open_count == 0)
- d
[PATCH 10/10] iommufd: Allow iommufd to supply /dev/vfio/vfio
If the VFIO container is compiled out, give a kconfig option for iommufd
to provide the miscdev node with the same name and permissions as vfio
uses.
The compatibility node supports the same ioctls as VFIO and automatically
enables the VFIO compatible pinned page accounting mode.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommufd/Kconfig | 12
drivers/iommu/iommufd/main.c | 35 ---
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommufd/Kconfig b/drivers/iommu/iommufd/Kconfig
index f0a2012234fa09..afc83b7575cce6 100644
--- a/drivers/iommu/iommufd/Kconfig
+++ b/drivers/iommu/iommufd/Kconfig
@@ -14,6 +14,18 @@ config IOMMUFD
If you don't know what to do here, say N.
if IOMMUFD
+config IOMMUFD_VFIO_CONTAINER
+ bool "IOMMUFD provides the VFIO container /dev/vfio/vfio"
+ depends on VFIO && !VFIO_CONTAINER
+ default VFIO && !VFIO_CONTAINER
+ help
+ IOMMUFD will provide /dev/vfio/vfio instead of VFIO. This relies on
+ IOMMUFD providing compatibility emulation to give the same ioctls.
+ It provides an option to build a kernel with legacy VFIO components
+ removed.
+
+ Unless testing IOMMUFD say N here.
+
config IOMMUFD_TEST
bool "IOMMU Userspace API Test support"
depends on RUNTIME_TESTING_MENU
diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c
index 8a31c1a14cdd53..19db81fbf7f08f 100644
--- a/drivers/iommu/iommufd/main.c
+++ b/drivers/iommu/iommufd/main.c
@@ -24,6 +24,7 @@
#include
#include
+#include "io_pagetable.h"
#include "iommufd_private.h"
#include "iommufd_test.h"
@@ -31,6 +32,7 @@ struct iommufd_object_ops {
void (*destroy)(struct iommufd_object *obj);
};
static struct iommufd_object_ops iommufd_object_ops[];
+static struct miscdevice vfio_misc_dev;
struct iommufd_object *_iommufd_object_alloc(struct iommufd_ctx *ictx,
size_t size,
@@ -167,6 +169,13 @@ static int iommufd_fops_open(struct inode *inode, struct
file *filp)
if (!ictx)
return -ENOMEM;
+ /*
+* For compatibility with VFIO when /dev/vfio/vfio is opened we default
+* to the same rlimit accounting as vfio uses.
+*/
+ if (filp->private_data == &vfio_misc_dev)
+ ictx->account_mode = IOPT_PAGES_ACCOUNT_MM;
+
xa_init_flags(&ictx->objects, XA_FLAGS_ALLOC1 | XA_FLAGS_ACCOUNT);
ictx->file = filp;
filp->private_data = ictx;
@@ -392,26 +401,46 @@ static struct miscdevice iommu_misc_dev = {
.mode = 0660,
};
+
+static struct miscdevice vfio_misc_dev = {
+ .minor = VFIO_MINOR,
+ .name = "vfio",
+ .fops = &iommufd_fops,
+ .nodename = "vfio/vfio",
+ .mode = 0666,
+};
+
static int __init iommufd_init(void)
{
int ret;
ret = misc_register(&iommu_misc_dev);
- if (ret) {
- pr_err("Failed to register misc device\n");
+ if (ret)
return ret;
- }
+ if (IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)) {
+ ret = misc_register(&vfio_misc_dev);
+ if (ret)
+ goto err_misc;
+ }
return 0;
+err_misc:
+ misc_deregister(&iommu_misc_dev);
+ return ret;
}
static void __exit iommufd_exit(void)
{
+ if (IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER))
+ misc_deregister(&vfio_misc_dev);
misc_deregister(&iommu_misc_dev);
}
module_init(iommufd_init);
module_exit(iommufd_exit);
+#if IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)
+MODULE_ALIAS_MISCDEV(VFIO_MINOR);
+#endif
MODULE_DESCRIPTION("I/O Address Space Management for passthrough devices");
MODULE_LICENSE("GPL");
--
2.38.0
[PATCH 08/10] vfio-iommufd: Support iommufd for emulated VFIO devices
Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
consist of all the mdev drivers.
Like the physical drivers, support for iommufd is provided by the driver
supplying the correct correct standard ops. Provide ops from the core that
duplicate what vfio_register_emulated_iommu_dev() does.
Emulated drivers are where it is more likely to see variation in the
iommfd support ops. For instance IDXD will probably need to setup both a
iommfd_device context linked to a PASID and an iommufd_access context to
support all their mdev operations.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +
drivers/s390/cio/vfio_ccw_ops.c | 3 +
drivers/s390/crypto/vfio_ap_ops.c | 3 +
drivers/vfio/container.c | 108 ++---
drivers/vfio/iommufd.c| 57
drivers/vfio/vfio.h | 10 ++-
drivers/vfio/vfio_main.c | 110 +-
include/linux/vfio.h | 14
8 files changed, 217 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 7a45e5360caf2d..579b230a0f58d9 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1474,6 +1474,9 @@ static const struct vfio_device_ops intel_vgpu_dev_ops = {
.mmap = intel_vgpu_mmap,
.ioctl = intel_vgpu_ioctl,
.dma_unmap = intel_vgpu_dma_unmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas= vfio_iommufd_emulated_attach_ioas,
};
static int intel_vgpu_probe(struct mdev_device *mdev)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 6ae4d012d80084..560453d99c24fc 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -588,6 +588,9 @@ static const struct vfio_device_ops vfio_ccw_dev_ops = {
.ioctl = vfio_ccw_mdev_ioctl,
.request = vfio_ccw_mdev_request,
.dma_unmap = vfio_ccw_dma_unmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas = vfio_iommufd_emulated_attach_ioas,
};
struct mdev_driver vfio_ccw_mdev_driver = {
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 0b4cc8c597ae67..bb7776d207924f 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1789,6 +1789,9 @@ static const struct vfio_device_ops
vfio_ap_matrix_dev_ops = {
.close_device = vfio_ap_mdev_close_device,
.ioctl = vfio_ap_mdev_ioctl,
.dma_unmap = vfio_ap_mdev_dma_unmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas = vfio_iommufd_emulated_attach_ioas,
};
static struct mdev_driver vfio_ap_matrix_driver = {
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index 8772dad6808539..0388f2e33447eb 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -540,113 +540,45 @@ void vfio_group_unuse_container(struct vfio_group *group)
fput(group->opened_file);
}
-/*
- * Pin contiguous user pages and return their associated host pages for local
- * domain only.
- * @device [in] : device
- * @iova [in]: starting IOVA of user pages to be pinned.
- * @npage [in] : count of pages to be pinned. This count should not
- *be greater than VFIO_PIN_PAGES_MAX_ENTRIES.
- * @prot [in]: protection flags
- * @pages[out] : array of host pages
- * Return error or number of pages pinned.
- *
- * A driver may only call this function if the vfio_device was created
- * by vfio_register_emulated_iommu_dev().
- */
-int vfio_pin_pages(struct vfio_device *device, dma_addr_t iova,
- int npage, int prot, struct page **pages)
+int vfio_container_pin_pages(struct vfio_container *container,
+struct iommu_group *iommu_group, dma_addr_t iova,
+int npage, int prot, struct page **pages)
{
- struct vfio_container *container;
- struct vfio_group *group = device->group;
- struct vfio_iommu_driver *driver;
- int ret;
-
- if (!pages || !npage || !vfio_assert_device_open(device))
- return -EINVAL;
+ /* group->container cannot change while a vfio device is open */
+ struct vfio_iommu_driver *driver = container->iommu_driver;
if (npage > VFIO_PIN_PAGES_MAX_ENTRIES)
return -E2BIG;
/* group->container cannot change while a vfio device is open */
- container = group->container;
driver = container->iommu_driver;
- if (likely(driver && driver->ops->pin_pages))
- ret = driver->ops->pin_pages(container->iommu_data,
-group->iom
[PATCH 06/10] vfio-iommufd: Allow iommufd to be used in place of a container fd
This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD and an
iommufd.
In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will
not be attached to any groups.
>From a VFIO perspective this means that the VFIO_GROUP_GET_STATUS and
VFIO_GROUP_FLAGS_VIABLE works subtly differently. With the container FD
the iommu_group_claim_dma_owner() is done during SET_CONTAINER but for
IOMMFD this is done during VFIO_GROUP_GET_DEVICE_FD. Meaning that
VFIO_GROUP_FLAGS_VIABLE could be set but GET_DEVICE_FD will fail due to
viability.
As GET_DEVICE_FD can fail for many reasons already this is not expected to
be a meaningful difference.
Reorganize the tests for if the group has an assigned container or iommu
into a vfio_group_has_iommu() function and consolidate all the duplicated
WARN_ON's etc related to this.
Call container functions only if a container is actually present on the
group.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/container.c | 7 ++--
drivers/vfio/vfio.h | 2 ++
drivers/vfio/vfio_main.c | 76
4 files changed, 69 insertions(+), 17 deletions(-)
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 86c381ceb9a1e9..1118d322eec97d 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -2,6 +2,7 @@
menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
select IOMMU_API
+ depends on IOMMUFD || !IOMMUFD
select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
select INTERVAL_TREE
help
diff --git a/drivers/vfio/container.c b/drivers/vfio/container.c
index d97747dfb05d02..8772dad6808539 100644
--- a/drivers/vfio/container.c
+++ b/drivers/vfio/container.c
@@ -516,8 +516,11 @@ int vfio_group_use_container(struct vfio_group *group)
{
lockdep_assert_held(&group->group_lock);
- if (!group->container || !group->container->iommu_driver ||
- WARN_ON(!group->container_users))
+ /*
+* The container fd has been assigned with VFIO_GROUP_SET_CONTAINER but
+* VFIO_SET_IOMMU hasn't been done yet.
+*/
+ if (!group->container->iommu_driver)
return -EINVAL;
if (group->type == VFIO_NO_IOMMU && !capable(CAP_SYS_RAWIO))
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 247590334e14b0..985e13d52989ca 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -10,6 +10,7 @@
#include
#include
+struct iommufd_ctx;
struct iommu_group;
struct vfio_device;
struct vfio_container;
@@ -60,6 +61,7 @@ struct vfio_group {
struct kvm *kvm;
struct file *opened_file;
struct blocking_notifier_head notifier;
+ struct iommufd_ctx *iommufd;
};
/* events for the backend driver notify callback */
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index a8d1fbfcc3ddad..cf0ea744de931e 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "vfio.h"
#define DRIVER_VERSION "0.3"
@@ -665,6 +666,16 @@ EXPORT_SYMBOL_GPL(vfio_unregister_group_dev);
/*
* VFIO Group fd, /dev/vfio/$GROUP
*/
+static bool vfio_group_has_iommu(struct vfio_group *group)
+{
+ lockdep_assert_held(&group->group_lock);
+ if (!group->container)
+ WARN_ON(group->container_users);
+ else
+ WARN_ON(!group->container_users);
+ return group->container || group->iommufd;
+}
+
/*
* VFIO_GROUP_UNSET_CONTAINER should fail if there are other users or
* if there was no container to unset. Since the ioctl is called on
@@ -676,15 +687,21 @@ static int vfio_group_ioctl_unset_container(struct
vfio_group *group)
int ret = 0;
mutex_lock(&group->group_lock);
- if (!group->container) {
+ if (!vfio_group_has_iommu(group)) {
ret = -EINVAL;
goto out_unlock;
}
- if (group->container_users != 1) {
- ret = -EBUSY;
- goto out_unlock;
+ if (group->container) {
+ if (group->container_users != 1) {
+ ret = -EBUSY;
+ goto out_unlock;
+ }
+ vfio_group_detach_container(group);
+ }
+ if (group->iommufd) {
+ iommufd_ctx_put(group->iommufd);
+ group->iommufd = NULL;
}
- vfio_group_detach_container(group);
out_unlock:
mutex_unlock(&group->group_lock);
@@ -695,6 +712,7 @@ static int vfio_group_ioctl_set_container(struct vfio_group
*group,
int __user *arg)
{
struct vfio_container *container;
+ struct iommufd_ctx *iommufd;
struct fd f;
int ret;
int fd;
@@ -707,7 +725,7 @@ static int vfio_group_ioctl_set_container(struct vfio_gr
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi,
On 10/24/22 22:30, Matthew Garrett wrote:
> On Tue, Sep 27, 2022 at 01:04:52PM +0200, Hans de Goede wrote:
>
>> So to fix this we need to make acpi_video_get_backlight_type()
>> return native on the Acer Chromebook Spin 713.
>
> Isn't the issue broader than that? Unless the platform is Windows 8 or
> later, we'll *always* (outside of some corner cases) return
> acpi_backlight_vendor if there's no ACPI video interface. This is broken
> for any platform that implements ACPI but relies on native video
> control, which is going to include a range of Coreboot platforms, not
> just Chromebooks.
That is a valid point, but keep in mind that this is only used on ACPI
platforms and then only on devices with a builtin LCD panel and then
only by GPU drivers which actually call acpi_video_get_backlight_type(),
so e.g. not by all the ARM specific display drivers.
So I believe that Chromebooks quite likely are the only devices with
this issue.
We could do something like the patch which I have pasted at the end
of this email, but as its commit message notes there is a real
good chance this will cause regressions on some laptops.
So if we ever decide to go with something like the patch below,
I think we should at a minimum wait for the next cycle with that,
because 6.1 already significantly reworks the ACPI backlight
detect handling and I don't want to throw this into the mix
on top of those changes.
> I think for this to work correctly you need to have
> the infrastructure be aware of whether or not a vendor interface exists,
> which means having to handle cleanup if a vendor-specific module gets
> loaded later.
Getting rid of the whole ping-ponging of which backlight drivers
get loaded during boot was actually one of the goals of the rework
which landed in 6.1 this actually allowed us to remove some quirks
because some hw/firmware did not like us changing our mind and
switching backlight interfaces after first poking another one.
So we definitely don't want to go back to the ping-pong thing.
Regards,
Hans
>From 67ee5d7163e33e65dca06887befd0639b0345883 Mon Sep 17 00:00:00 2001
From: Hans de Goede
Date: Tue, 25 Oct 2022 20:38:56 +0200
Subject: [PATCH] ACPI: video: Simplify __acpi_video_get_backlight_type()
Simplify __acpi_video_get_backlight_type() removing a nested if which
makes the flow harder to follow.
Note this will cause a behavior change on devices which do not have
ACPI video support but do have both a vendor and native backlight
driver available. This change will cause these devices to switch
from vendor to native.
This may not be desirable in all cases, this is likely to happen
on significantly older laptops, where there very well might be
cases where the native driver does not work because the backlight is
controlled by the EC.
This removes the need for the special handling of Chromebooks,
these will now hit the if (native_available) return acpi_backlight_native;
path.
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 36 +++-
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 9cd8797d12bb..9bd85b159e02 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -668,11 +668,6 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
{ },
};
-static bool google_cros_ec_present(void)
-{
- return acpi_dev_found("GOOG0004");
-}
-
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
@@ -718,30 +713,21 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
if (apple_gmux_present())
return acpi_backlight_apple_gmux;
- /* On systems with ACPI video use either native or ACPI video. */
- if (video_caps & ACPI_VIDEO_BACKLIGHT) {
- /*
-* Windows 8 and newer no longer use the ACPI video interface,
-* so it often does not work. If the ACPI tables are written
-* for win8 and native brightness ctl is available, use that.
-*
-* The native check deliberately is inside the if acpi-video
-* block on older devices without acpi-video support native
-* is usually not the best choice.
-*/
- if (acpi_osi_is_win8() && native_available)
- return acpi_backlight_native;
- else
- return acpi_backlight_video;
- }
-
/*
-* Chromebooks that don't have backlight handle in ACPI table
-* are supposed to use native backlight if it's available.
+* Pre Windows 8, Windows uses ACPI video, so prefer that over native
+* on pre-win8 systems (Windows 8+ no longer uses ACPI video).
*/
- if (google_cros_ec_present() && native_available)
+
[PATCH 07/10] vfio-iommufd: Support iommufd for physical VFIO devices
This creates the iommufd_device for the physical VFIO drivers. These are
all the drivers that are calling vfio_register_group_dev() and expect the
type1 code to setup a real iommu_domain against their parent struct
device.
The design gives the driver a choice in how it gets connected to iommufd
by providing bind_iommufd/unbind_iommufd/attach_ioas callbacks to
implement as required. The core code provides three default callbacks for
physical mode using a real iommu_domain. This is suitable for drivers
using vfio_register_group_dev()
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/Makefile | 1 +
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 3 +
drivers/vfio/iommufd.c| 104 ++
.../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 6 +
drivers/vfio/pci/mlx5/main.c | 3 +
drivers/vfio/pci/vfio_pci.c | 3 +
drivers/vfio/platform/vfio_amba.c | 3 +
drivers/vfio/platform/vfio_platform.c | 3 +
drivers/vfio/vfio.h | 15 +++
drivers/vfio/vfio_main.c | 13 ++-
include/linux/vfio.h | 25 +
11 files changed, 177 insertions(+), 2 deletions(-)
create mode 100644 drivers/vfio/iommufd.c
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index b693a1169286f8..3863922529ef20 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_VFIO) += vfio.o
vfio-y += vfio_main.o \
iova_bitmap.o \
container.o
+vfio-$(CONFIG_IOMMUFD) += iommufd.o
obj-$(CONFIG_VFIO_VIRQFD) += vfio_virqfd.o
obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index b16874e913e4f5..5cd4bb47644039 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -592,6 +592,9 @@ static const struct vfio_device_ops vfio_fsl_mc_ops = {
.read = vfio_fsl_mc_read,
.write = vfio_fsl_mc_write,
.mmap = vfio_fsl_mc_mmap,
+ .bind_iommufd = vfio_iommufd_physical_bind,
+ .unbind_iommufd = vfio_iommufd_physical_unbind,
+ .attach_ioas= vfio_iommufd_physical_attach_ioas,
};
static struct fsl_mc_driver vfio_fsl_mc_driver = {
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
new file mode 100644
index 00..8280bb32ee677c
--- /dev/null
+++ b/drivers/vfio/iommufd.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021-2022, NVIDIA CORPORATION & AFFILIATES
+ */
+#include
+#include
+
+#include "vfio.h"
+
+MODULE_IMPORT_NS(IOMMUFD);
+MODULE_IMPORT_NS(IOMMUFD_VFIO);
+
+int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
+{
+ u32 ioas_id;
+ u32 device_id;
+ int ret;
+
+ lockdep_assert_held(&vdev->dev_set->lock);
+
+ /*
+* If the driver doesn't provide this op then it means the device does
+* not do DMA at all. So nothing to do.
+*/
+ if (!vdev->ops->bind_iommufd)
+ return 0;
+
+ ret = vdev->ops->bind_iommufd(vdev, ictx, &device_id);
+ if (ret)
+ return ret;
+
+ if (vdev->ops->attach_ioas) {
+ ret = iommufd_vfio_compat_ioas_id(ictx, &ioas_id);
+ if (ret)
+ goto err_unbind;
+ ret = vdev->ops->attach_ioas(vdev, &ioas_id);
+ if (ret)
+ goto err_unbind;
+ vdev->iommufd_attached = true;
+ }
+
+ /*
+* The legacy path has no way to return the device id or the selected
+* pt_id
+*/
+ return 0;
+
+err_unbind:
+ if (vdev->ops->unbind_iommufd)
+ vdev->ops->unbind_iommufd(vdev);
+ return ret;
+}
+
+void vfio_iommufd_unbind(struct vfio_device *vdev)
+{
+ lockdep_assert_held(&vdev->dev_set->lock);
+
+ if (!vdev->iommufd_device)
+ return;
+
+ if (vdev->ops->unbind_iommufd)
+ vdev->ops->unbind_iommufd(vdev);
+}
+
+/*
+ * The physical standard ops mean that the iommufd_device is bound to the
+ * physical device vdev->dev that was provided to vfio_init_group_dev().
Drivers
+ * using this ops set should call vfio_register_group_dev()
+ */
+int vfio_iommufd_physical_bind(struct vfio_device *vdev,
+ struct iommufd_ctx *ictx, u32 *out_device_id)
+{
+ struct iommufd_device *idev;
+
+ idev = iommufd_device_bind(ictx, vdev->dev, out_device_id);
+ if (IS_ERR(idev))
+ return PTR_ERR(idev);
+ vdev->iommufd_device = idev;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_iommufd_physical_bind);
+
+void vfio_iommufd_physical_unbind(struct vfio_device *vdev)
+{
+ lockdep_assert_held(&vdev->dev_set->lock);
+
+ if (vdev->iommufd_attached) {
+ iommufd_device_d
[PATCH 09/10] vfio: Make vfio_container optionally compiled
Add a kconfig CONFIG_VFIO_CONTAINER that controls compiling the container
code. If 'n' then only iommufd will provide the container service. All the
support for vfio iommu drivers, including type1, will not be built.
This allows a compilation check that no inappropriate dependencies between
the device/group and container have been created.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/Kconfig | 37
drivers/vfio/Makefile | 4 +--
drivers/vfio/vfio.h | 65 +++
3 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 1118d322eec97d..d384419d151dda 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -3,8 +3,8 @@ menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
select IOMMU_API
depends on IOMMUFD || !IOMMUFD
- select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
select INTERVAL_TREE
+ select VFIO_CONTAINER if IOMMUFD=n
help
VFIO provides a framework for secure userspace device drivers.
See Documentation/driver-api/vfio.rst for more details.
@@ -12,25 +12,27 @@ menuconfig VFIO
If you don't know what to do here, say N.
if VFIO
+config VFIO_CONTAINER
+ bool "Support for the VFIO container /dev/vfio/vfio"
+ select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
+ default y
+ help
+ The VFIO container is the classic interface to VFIO for establishing
+ mappings. If N is selected here then IOMMUFD must be used the manage
+ the mappings.
+
+ Unless testing IOMMUFD say Y here.
+
+if VFIO_CONTAINER
config VFIO_IOMMU_TYPE1
tristate
- default n
+ default MMU && (X86 || S390 || ARM || ARM64)
config VFIO_IOMMU_SPAPR_TCE
tristate
depends on SPAPR_TCE_IOMMU
default VFIO
-config VFIO_SPAPR_EEH
- tristate
- depends on EEH && VFIO_IOMMU_SPAPR_TCE
- default VFIO
-
-config VFIO_VIRQFD
- tristate
- select EVENTFD
- default n
-
config VFIO_NOIOMMU
bool "VFIO No-IOMMU support"
help
@@ -44,6 +46,17 @@ config VFIO_NOIOMMU
this mode since there is no IOMMU to provide DMA translation.
If you don't know what to do here, say N.
+endif
+
+config VFIO_SPAPR_EEH
+ tristate
+ depends on EEH && VFIO_IOMMU_SPAPR_TCE
+ default VFIO
+
+config VFIO_VIRQFD
+ tristate
+ select EVENTFD
+ default n
source "drivers/vfio/pci/Kconfig"
source "drivers/vfio/platform/Kconfig"
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 3863922529ef20..b953517dc70f99 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -4,9 +4,9 @@ vfio_virqfd-y := virqfd.o
obj-$(CONFIG_VFIO) += vfio.o
vfio-y += vfio_main.o \
- iova_bitmap.o \
- container.o
+ iova_bitmap.o
vfio-$(CONFIG_IOMMUFD) += iommufd.o
+vfio-$(CONFIG_VFIO_CONTAINER) += container.o
obj-$(CONFIG_VFIO_VIRQFD) += vfio_virqfd.o
obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index d57a08afb5cf5c..3378714a746274 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -55,7 +55,9 @@ struct vfio_group {
struct list_headdevice_list;
struct mutexdevice_lock;
struct list_headvfio_next;
+#if IS_ENABLED(CONFIG_VFIO_CONTAINER)
struct list_headcontainer_next;
+#endif
enum vfio_group_typetype;
struct mutexgroup_lock;
struct kvm *kvm;
@@ -64,6 +66,7 @@ struct vfio_group {
struct iommufd_ctx *iommufd;
};
+#if IS_ENABLED(CONFIG_VFIO_CONTAINER)
/* events for the backend driver notify callback */
enum vfio_iommu_notify_type {
VFIO_IOMMU_CONTAINER_CLOSE = 0,
@@ -129,6 +132,68 @@ int vfio_container_dma_rw(struct vfio_container
*container, dma_addr_t iova,
int __init vfio_container_init(void);
void vfio_container_cleanup(void);
+#else
+static inline struct vfio_container *
+vfio_container_from_file(struct file *filep)
+{
+ return NULL;
+}
+
+static inline int vfio_group_use_container(struct vfio_group *group)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void vfio_group_unuse_container(struct vfio_group *group)
+{
+}
+
+static inline int vfio_container_attach_group(struct vfio_container *container,
+ struct vfio_group *group)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void vfio_group_detach_container(struct vfio_group *group)
+{
+}
+
+static inline void vfio_device_container_register(struct vfio_device *device)
+{
+}
+
+static inline void vfio_device_container_unregister(struct vfio_device *device)
+{
+}
+
+static inline int vfio_container_pin_pages(str
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: > That is a valid point, but keep in mind that this is only used on ACPI > platforms and then only on devices with a builtin LCD panel and then > only by GPU drivers which actually call acpi_video_get_backlight_type(), > so e.g. not by all the ARM specific display drivers. > > So I believe that Chromebooks quite likely are the only devices with > this issue. My laptop is, uh, weird, but it falls into this category. > > I think for this to work correctly you need to have > > the infrastructure be aware of whether or not a vendor interface exists, > > which means having to handle cleanup if a vendor-specific module gets > > loaded later. > > Getting rid of the whole ping-ponging of which backlight drivers > get loaded during boot was actually one of the goals of the rework > which landed in 6.1 this actually allowed us to remove some quirks > because some hw/firmware did not like us changing our mind and > switching backlight interfaces after first poking another one. > So we definitely don't want to go back to the ping-pong thing. Defaulting to native but then having a vendor driver be able to disable native drivers seems easiest? It shouldn't be a regression over the previous state of affairs since both drivers were being loaded already.
Re: [PATCH -next] drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()
Am 2022-10-25 um 03:28 schrieb Yang Li:
./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but
dereferenced.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2549
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index cddf259875c0..405dd51521dc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -981,7 +981,8 @@ static vm_fault_t svm_migrate_to_ram(struct vm_fault *vmf)
out_mmput:
mmput(mm);
- pr_debug("CPU fault svms 0x%p address 0x%lx done\n", &p->svms, addr);
+ if (p)
+ pr_debug("CPU fault svms 0x%p address 0x%lx done\n", &p->svms,
addr);
Thank you for catching and reporting this problem. I think the correct
solution would be to move the pr_debug up before the kfd_unref_process
call. That way you're sure that the pointer is initialized and that it
represents a valid reference to the kfd_process structure.
Regards,
Felix
return r ? VM_FAULT_SIGBUS : 0;
}
Re: [PATCH -next] drm/amdkfd: clean up some inconsistent indentings
Am 2022-10-25 um 02:09 schrieb Yang Li: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:331 svm_migrate_copy_to_vram() warn: inconsistent indenting Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2537 Reported-by: Abaci Robot Signed-off-by: Yang Li This patch doesn't apply to our amd-staging-drm-next, nor to the kernel.org master branch. Which branch is this against? Thanks, Felix --- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c index 20d6b2578927..cddf259875c0 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c @@ -328,8 +328,7 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, struct svm_range *prange, dst[i] = cursor.start + (j << PAGE_SHIFT); migrate->dst[i] = svm_migrate_addr_to_pfn(adev, dst[i]); - svm_migrate_get_vram_page(&kfddev->pgmap, prange, - migrate->dst[i]); + svm_migrate_get_vram_page(&kfddev->pgmap, prange, migrate->dst[i]); migrate->dst[i] = migrate_pfn(migrate->dst[i]); spage = migrate_pfn_to_page(migrate->src[i]);
Re: [PATCH] [next] amdkfd: remove unused kfd_pm4_headers_diq header file
Am 2022-10-25 um 05:12 schrieb Paulo Miguel Almeida:
kfd_pm4_headers_diq.h header is a leftover from the old H/W debugger
module support added on commit . That implementation
was removed after a while and the last file that included that header
was removed on commit <5bdd3eb253544b1>.
This patch removes the unused header file kfd_pm4_headers_diq.h
Signed-off-by: Paulo Miguel Almeida
Thank you for this patch and the one that removes struct cdit_header. I
am applying both to our amd-staging-drm-next branch. I'm also fixing up
the prefix of the commit headline to match our usual convention:
drm/amdkfd: ...
Both patches are
Reviewed-by: Felix Kuehling
---
.../gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h | 291 --
1 file changed, 291 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
b/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
deleted file mode 100644
index f9cd28690151..
--- a/drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_diq.h
+++ /dev/null
@@ -1,291 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 OR MIT */
-/*
- * Copyright 2014-2022 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- */
-
-#ifndef KFD_PM4_HEADERS_DIQ_H_
-#define KFD_PM4_HEADERS_DIQ_H_
-
-/*_INDIRECT_BUFFER */
-
-#ifndef _PM4__INDIRECT_BUFFER_DEFINED
-#define _PM4__INDIRECT_BUFFER_DEFINED
-enum _INDIRECT_BUFFER_cache_policy_enum {
- cache_policy___indirect_buffer__lru = 0,
- cache_policy___indirect_buffer__stream = 1,
- cache_policy___indirect_buffer__bypass = 2
-};
-
-enum {
- IT_INDIRECT_BUFFER_PASID = 0x5C
-};
-
-struct pm4__indirect_buffer_pasid {
- union {
- union PM4_MES_TYPE_3_HEADER header; /* header */
- unsigned int ordinal1;
- };
-
- union {
- struct {
- unsigned int reserved1:2;
- unsigned int ib_base_lo:30;
- } bitfields2;
- unsigned int ordinal2;
- };
-
- union {
- struct {
- unsigned int ib_base_hi:16;
- unsigned int reserved2:16;
- } bitfields3;
- unsigned int ordinal3;
- };
-
- union {
- unsigned int control;
- unsigned int ordinal4;
- };
-
- union {
- struct {
- unsigned int pasid:10;
- unsigned int reserved4:22;
- } bitfields5;
- unsigned int ordinal5;
- };
-
-};
-
-#endif
-
-/*_RELEASE_MEM */
-
-#ifndef _PM4__RELEASE_MEM_DEFINED
-#define _PM4__RELEASE_MEM_DEFINED
-enum _RELEASE_MEM_event_index_enum {
- event_index___release_mem__end_of_pipe = 5,
- event_index___release_mem__shader_done = 6
-};
-
-enum _RELEASE_MEM_cache_policy_enum {
- cache_policy___release_mem__lru = 0,
- cache_policy___release_mem__stream = 1,
- cache_policy___release_mem__bypass = 2
-};
-
-enum _RELEASE_MEM_dst_sel_enum {
- dst_sel___release_mem__memory_controller = 0,
- dst_sel___release_mem__tc_l2 = 1,
- dst_sel___release_mem__queue_write_pointer_register = 2,
- dst_sel___release_mem__queue_write_pointer_poll_mask_bit = 3
-};
-
-enum _RELEASE_MEM_int_sel_enum {
- int_sel___release_mem__none = 0,
- int_sel___release_mem__send_interrupt_only = 1,
- int_sel___release_mem__send_interrupt_after_write_confirm = 2,
- int_sel___release_mem__send_data_after_write_confirm = 3
-};
-
-enum _RELEASE_MEM_data_sel_enum {
- data_sel___release_mem__none = 0,
- data_sel___release_mem__send_32_bit_low = 1,
- data_sel___release_mem__send_64_bit_data = 2,
- data_sel___release_mem__send_gpu_clock_co
[PATCH v3] drm/i915: Fix CFI violations in gt_sysfs
From: Nathan Chancellor
When booting with CONFIG_CFI_CLANG, there are numerous violations when
accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
$ grep . *
id:0
punit_req_freq_mhz:350
rc6_enable:1
rc6_residency_ms:214934
rps_act_freq_mhz:1300
rps_boost_freq_mhz:1300
rps_cur_freq_mhz:350
rps_max_freq_mhz:1300
rps_min_freq_mhz:350
rps_RP0_freq_mhz:1300
rps_RP1_freq_mhz:350
rps_RPn_freq_mhz:350
throttle_reason_pl1:0
throttle_reason_pl2:0
throttle_reason_pl4:0
throttle_reason_prochot:0
throttle_reason_ratl:0
throttle_reason_status:0
throttle_reason_thermal:0
throttle_reason_vr_tdc:0
throttle_reason_vr_thermalert:0
$ sudo dmesg &| grep "CFI failure at"
[ 214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target:
id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
[ 214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target:
punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
[ 214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target:
act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target:
boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target:
cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target:
max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target:
min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target:
RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.
The ultimate issue is that these sysfs functions are expecting to be
called via dev_attr_show() but they may also be called via
kobj_attr_show(), as certain files are created under two different
kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
hence the warnings above. When accessing the gt_ files under
/sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
sysfs functions, there are no violations, meaning the functions are
being called with the proper type.
To make everything work properly, adjust certain functions to match the
type of the ->show() and ->store() members in 'struct kobj_attribute'.
Add a macro to generate functions for that can be called via both
dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
called through both kobject locations without violating kCFI and adjust
the attribute groups to account for this.
Link: https://github.com/ClangBuiltLinux/linux/issues/1716
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
Reviewed-by: Kees Cook
Signed-off-by: Nathan Chancellor
Signed-off-by: Andi Shyti
Link:
https://patchwork.freedesktop.org/patch/msgid/20221013205909.1282545-1-nat...@kernel.org
---
Hi,
just respinning this patch as we got a failure from CI and I wanted to
be
[PATCH v3 0/2] drm/msm: rework msm_iommu_new() and .create_address_space cb
Simplify the MSM IOMMU code a bit. This moves iommu_domain_alloc() and iommu_set_pgtable_quirks() calls to msm_iommu_new() to get rid of the disbalance, when the iommu domain is allocated by the caller of msm_iommu_new() and then it is freed by the msm_iommu code itself. Changes since v2: - Reorder the patches. - Move iommu_set_pgtable_quirks() to the msm_iommu_new() too. It will not work if it's called after attaching the device. Changes since v1: - Fixed the uninitialized variable usage in a6xx_gmu_memory_probe() (reported by lkp) Dmitry Baryshkov (2): drm/msm: move domain allocation into msm_iommu_new() drm/msm: remove duplicated code from a6xx_create_address_space drivers/gpu/drm/msm/adreno/a3xx_gpu.c| 2 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c| 2 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 2 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c| 12 drivers/gpu/drm/msm/adreno/a6xx_gpu.c| 36 +--- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 29 ++- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 9 -- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 19 +++-- drivers/gpu/drm/msm/msm_drv.c| 18 ++-- drivers/gpu/drm/msm/msm_iommu.c | 20 +++-- drivers/gpu/drm/msm/msm_mmu.h| 3 +- 11 files changed, 67 insertions(+), 85 deletions(-) -- 2.35.1
[PATCH v3 1/2] drm/msm: move domain allocation into msm_iommu_new()
After the msm_iommu instance is created, the IOMMU domain is completely
handled inside the msm_iommu code. Move the iommu_domain_alloc() call
into the msm_iommu_new() to simplify callers code.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c| 12 +---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c| 25 +---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 25 +---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 19 +-
drivers/gpu/drm/msm/msm_drv.c| 18 -
drivers/gpu/drm/msm/msm_iommu.c | 20 ---
drivers/gpu/drm/msm/msm_mmu.h| 3 ++-
8 files changed, 60 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index e033d6a67a20..6484b97c5344 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1213,19 +1213,17 @@ static int a6xx_gmu_memory_alloc(struct a6xx_gmu *gmu,
struct a6xx_gmu_bo *bo,
static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
{
- struct iommu_domain *domain;
struct msm_mmu *mmu;
- domain = iommu_domain_alloc(&platform_bus_type);
- if (!domain)
+ mmu = msm_iommu_new(gmu->dev, 0);
+ if (!mmu)
return -ENODEV;
+ if (IS_ERR(mmu))
+ return PTR_ERR(mmu);
- mmu = msm_iommu_new(gmu->dev, domain);
gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x8000);
- if (IS_ERR(gmu->aspace)) {
- iommu_domain_free(domain);
+ if (IS_ERR(gmu->aspace))
return PTR_ERR(gmu->aspace);
- }
return 0;
}
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index fdc578016e0b..7a1b4397b842 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1784,37 +1784,30 @@ static void a6xx_gpu_set_freq(struct msm_gpu *gpu,
struct dev_pm_opp *opp,
static struct msm_gem_address_space *
a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
{
- struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
- struct iommu_domain *iommu;
struct msm_mmu *mmu;
struct msm_gem_address_space *aspace;
+ struct iommu_domain_geometry *geometry;
u64 start, size;
- iommu = iommu_domain_alloc(&platform_bus_type);
- if (!iommu)
- return NULL;
-
/*
* This allows GPU to set the bus attributes required to use system
* cache on behalf of the iommu page table walker.
*/
- if (!IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice))
- adreno_set_llc_attributes(iommu);
-
- mmu = msm_iommu_new(&pdev->dev, iommu);
- if (IS_ERR(mmu)) {
- iommu_domain_free(iommu);
+ mmu = msm_iommu_new(&pdev->dev, IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
+ if (IS_ERR_OR_NULL(mmu))
return ERR_CAST(mmu);
- }
+
+ geometry = msm_iommu_get_geometry(mmu);
+ if (IS_ERR(geometry))
+ return ERR_CAST(geometry);
/*
* Use the aperture start or SZ_16M, whichever is greater. This will
* ensure that we align with the allocated pagetable range while still
* allowing room in the lower 32 bits for GMEM and whatnot
*/
- start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
- size = iommu->geometry.aperture_end - start + 1;
+ start = max_t(u64, SZ_16M, geometry->aperture_start);
+ size = geometry->aperture_end - start + 1;
aspace = msm_gem_address_space_create(mmu, "gpu",
start & GENMASK_ULL(48, 0), size);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 382fb7f9e497..5808911899c7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -191,37 +191,30 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 pasid)
return zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw, pasid);
}
-void adreno_set_llc_attributes(struct iommu_domain *iommu)
-{
- iommu_set_pgtable_quirks(iommu, IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
-}
-
struct msm_gem_address_space *
adreno_iommu_create_address_space(struct msm_gpu *gpu,
struct platform_device *pdev)
{
- struct iommu_domain *iommu;
struct msm_mmu *mmu;
struct msm_gem_address_space *aspace;
+ struct iommu_domain_geometry *geometry;
u64 start, size;
- iommu = iommu_domain_alloc(&platform_bus_type);
- if (!iommu)
- return NULL;
-
- mmu = msm_iommu_new(&pdev->dev, iommu);
- if (IS_ERR(mmu)) {
- iommu_domain_fre
[PATCH v3 2/2] drm/msm: remove duplicated code from a6xx_create_address_space
The function a6xx_create_address_space() is mostly a copy of
adreno_iommu_create_address_space() with added quirk setting. Rework
these two functions to be a thin wrappers around a common helper.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 29 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 12 --
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 +-
6 files changed, 20 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 2c8b9899625b..948785ed07bb 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -500,7 +500,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = adreno_create_address_space,
.get_rptr = a3xx_get_rptr,
},
};
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 7cb8d9849c07..2fb32d5552c4 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -635,7 +635,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = adreno_create_address_space,
.get_rptr = a4xx_get_rptr,
},
.get_timestamp = a4xx_get_timestamp,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 3dcec7acb384..3c537c0016fa 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1705,7 +1705,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_busy = a5xx_gpu_busy,
.gpu_state_get = a5xx_gpu_state_get,
.gpu_state_put = a5xx_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = adreno_create_address_space,
.get_rptr = a5xx_get_rptr,
},
.get_timestamp = a5xx_get_timestamp,
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 7a1b4397b842..2daba2029db1 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1784,38 +1784,11 @@ static void a6xx_gpu_set_freq(struct msm_gpu *gpu,
struct dev_pm_opp *opp,
static struct msm_gem_address_space *
a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
{
- struct msm_mmu *mmu;
- struct msm_gem_address_space *aspace;
- struct iommu_domain_geometry *geometry;
- u64 start, size;
-
/*
* This allows GPU to set the bus attributes required to use system
* cache on behalf of the iommu page table walker.
*/
- mmu = msm_iommu_new(&pdev->dev, IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
- if (IS_ERR_OR_NULL(mmu))
- return ERR_CAST(mmu);
-
- geometry = msm_iommu_get_geometry(mmu);
- if (IS_ERR(geometry))
- return ERR_CAST(geometry);
-
- /*
-* Use the aperture start or SZ_16M, whichever is greater. This will
-* ensure that we align with the allocated pagetable range while still
-* allowing room in the lower 32 bits for GMEM and whatnot
-*/
- start = max_t(u64, SZ_16M, geometry->aperture_start);
- size = geometry->aperture_end - start + 1;
-
- aspace = msm_gem_address_space_create(mmu, "gpu",
- start & GENMASK_ULL(48, 0), size);
-
- if (IS_ERR(aspace) && !IS_ERR(mmu))
- mmu->funcs->destroy(mmu);
-
- return aspace;
+ return adreno_iommu_create_address_space(gpu, pdev,
IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
}
static struct msm_gem_address_space *
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 5808911899c7..822a60c5b6b1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -191,16 +191,24 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 pasid)
return zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw, pasid);
}
+struct msm_gem_address_space *
+adreno_create_address_space(struct msm_gpu *gpu,
+ struct platform_device *pdev)
+{
+ return adreno_iommu_create_address_space(gpu, pdev, 0);
+}
+
struct msm_gem_address_space *
adreno_iommu_create_address_space(struct msm_gpu *gpu,
- struct p
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi Matthew, On 10/25/22 21:32, Matthew Garrett wrote: > On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: > >> That is a valid point, but keep in mind that this is only used on ACPI >> platforms and then only on devices with a builtin LCD panel and then >> only by GPU drivers which actually call acpi_video_get_backlight_type(), >> so e.g. not by all the ARM specific display drivers. >> >> So I believe that Chromebooks quite likely are the only devices with >> this issue. > > My laptop is, uh, weird, but it falls into this category. > >>> I think for this to work correctly you need to have >>> the infrastructure be aware of whether or not a vendor interface exists, >>> which means having to handle cleanup if a vendor-specific module gets >>> loaded later. >> >> Getting rid of the whole ping-ponging of which backlight drivers >> get loaded during boot was actually one of the goals of the rework >> which landed in 6.1 this actually allowed us to remove some quirks >> because some hw/firmware did not like us changing our mind and >> switching backlight interfaces after first poking another one. >> So we definitely don't want to go back to the ping-pong thing. > > Defaulting to native but then having a vendor driver be able to disable > native drivers seems easiest? It shouldn't be a regression over the > previous state of affairs since both drivers were being loaded already. Part of the reason for the ACPI backlight detect refactor is because of a planned new backlight uAPI where the brightness control becomes a property on the drm connector object, for a RFC including the rationale behind this planned uAPI change see: https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/ These plans require that there is only 1 backlight device registered (per panel). Having the native driver come and then go and be replaced with the vendor driver would also be quite inconvenient for these planned changes. As such I would rather find a solution for your "weird" laptop so that acpi_video_get_backlight_type() just always returns vendor there. Note that drivers/acpi/video_detect.c already has a DMI quirk tables for models where the heuristics from acpi_video_get_backlight_type() don't work. In general we (mostly me) try to make it so that the heuristics work on most models, to avoid needing to add every model under the sun to the DMI quirk table, but if your laptop is somehow special then adding a DMI quirk for it should be fine ? Can you perhaps explain a bit in what way your laptop is weird ? Note that technically if the native backlight does not work, then the GPU driver really should not even try to register it. But sometimes the video-bios-tables claim the backlight pwm input is attached to the GPU while it is not and things have evolved in such a way that the DMI quirks for that live in acpi/video_detect.c rather then in the GPU driver. Regards, Hans
Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On 10/25/2022 15:25, Hans de Goede wrote: Hi Matthew, On 10/25/22 21:32, Matthew Garrett wrote: On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: That is a valid point, but keep in mind that this is only used on ACPI platforms and then only on devices with a builtin LCD panel and then only by GPU drivers which actually call acpi_video_get_backlight_type(), so e.g. not by all the ARM specific display drivers. So I believe that Chromebooks quite likely are the only devices with this issue. My laptop is, uh, weird, but it falls into this category. I think for this to work correctly you need to have the infrastructure be aware of whether or not a vendor interface exists, which means having to handle cleanup if a vendor-specific module gets loaded later. Getting rid of the whole ping-ponging of which backlight drivers get loaded during boot was actually one of the goals of the rework which landed in 6.1 this actually allowed us to remove some quirks because some hw/firmware did not like us changing our mind and switching backlight interfaces after first poking another one. So we definitely don't want to go back to the ping-pong thing. Defaulting to native but then having a vendor driver be able to disable native drivers seems easiest? It shouldn't be a regression over the previous state of affairs since both drivers were being loaded already. Part of the reason for the ACPI backlight detect refactor is because of a planned new backlight uAPI where the brightness control becomes a property on the drm connector object, for a RFC including the rationale behind this planned uAPI change see: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3D&reserved=0 These plans require that there is only 1 backlight device registered (per panel). Having the native driver come and then go and be replaced with the vendor driver would also be quite inconvenient for these planned changes. As such I would rather find a solution for your "weird" laptop so that acpi_video_get_backlight_type() just always returns vendor there. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. Note that drivers/acpi/video_detect.c already has a DMI quirk tables for models where the heuristics from acpi_video_get_backlight_type() don't work. In general we (mostly me) try to make it so that the heuristics work on most models, to avoid needing to add every model under the sun to the DMI quirk table, but if your laptop is somehow special then adding a DMI quirk for it should be fine ? Can you perhaps explain a bit in what way your laptop is weird ? Note that technically if the native backlight does not work, then the GPU driver really should not even try to register it. But sometimes the video-bios-tables claim the backlight pwm input is attached to the GPU while it is not and things have evolved in such a way that the DMI quirks for that live in acpi/video_detect.c rather then in the GPU driver. Regards, Hans
