[PATCH] drm/amd/display: remove duplicate included header files
From: ye xingchen resource.h is included more than once. Signed-off-by: ye xingchen --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 1e60827911c6..6747e4b199de 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -47,7 +47,6 @@ #include "link/link_dp_training_auxless.h" #include "link/link_dp_phy.h" #include "link/link_dp_capability.h" -#include "resource.h" #define DC_LOGGER \ link->ctx->logger -- 2.25.1
Re: remove arch/sh
Hi Rob,
On Wed, Jan 18, 2023 at 5:50 AM Rob Landley wrote:
> On 1/17/23 14:26, Geert Uytterhoeven wrote:
> > On Tue, Jan 17, 2023 at 8:01 PM Rob Landley wrote:
> >> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
> >> really convenient: neither of my physical boards boot from SD card so
> >> replacing
> >> the kernel requires reflashing soldered in flash. (They'll net mount
> >> userspace
> >> but I haven't gotten either bootloader to net-boot a kernel.)
> >
> > On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
> > kernel, and use kexec to boot-test each and every renesas-drivers
> > release. Note that this requires both the original 2.6.22 kernel
> > and matching kexec-tools.
>
> I make it a point to run _current_ kernels in all my mkroot systems, including
> sh4. What I shipped was 6.1 is:
>
> # cat /proc/version
> Linux version 6.1.0 (landley@driftwood) (sh4-linux-musl-cc (GCC) 9.4.0, GNU ld
> (GNU Binutils) 2.33.1) #1 Tue Jan 10 16:32:07 CST 2023
I think you misunderstood: renesas-drivers releases[1] are current
kernels.
Linux version 6.2.0-rc3-landisk-01864-g0c6453b3e5f6 (geert@rox)
(sh4-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU
Binutils for Ubuntu) 2.38) #125 Tue Jan 10 14:29:01 CET 2023
I use 2.6.22 and kexec as a boot loader for newer kernels, to avoid
juggling CF cards. I cannot install a newer base kernel on the CF,
as kexec is broken upstream.
> > Apparently both upstreamed kernel and
> > kexec-tools support for SH are different, and incompatible with each
> > other, so you cannot kexec from a contemporary kernel.
>
> Sure you can. Using toybox's insmod and modprobe, anyway. (That's the target I
> tested those on... :)
>
> Haven't messed with signing or compression or anything yet, my insmod is just
> doing syscall(SYS_finit_module) and then falling back to SYS_init_module if
> that
> fails and either fd was 0 or errno was ENOSYS. (Don't ask me why
> SYS_finit_module doesn't work on stdin...)
>
> https://github.com/landley/toybox/blob/master/toys/other/insmod.c#L31
>
> https://landley.net/toybox/downloads/binaries/0.8.9/toybox-sh4
Again, I think you're talking about something different.
Does kexec work for you?
> > I tried working my way up from 2.6.22, but gave up around 2.6.29.
> > Probably I should do this with r2d and qemu instead ;-)
>
> I have current running there. I've had current running there for years. Config
> attached...
>
> > Both r2d and landisk are SH7751.
>
> Cool. Shouldn't be hard to get landisk running current then.
Current kernels work fine on landisk with an old Debian userspace
on CF. The 8139cp driver is a bit flaky: last time I tried nfsroot,
that didn't work well.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v10 21/23] drm/i915/vm_bind: Async vm_unbind support
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
v3: Add force_unbind function variants
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 49 ++-
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 1cc0b8a4e0e7..78e7c0642c5f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct i915_address_space
*vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 59462812ef4e..5b9ae5ebf55c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1746,7 +1748,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void __force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(>node))
return;
@@ -1760,10 +1762,26 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, >flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
}
+#define force_unbind(vma) __force_unbind((vma), false)
+
static void release_references(struct i915_vma *vma, struct intel_gt *gt,
bool vm_ddestroy)
{
@@ -1842,6 +1860,33 @@ void i915_vma_destroy(struct i915_vma *vma)
release_references(vma, gt, vm_ddestroy);
}
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(>vm->mutex);
+ /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+ if (async && i915_active_wait(>active))
+ async = false;
+
+ __force_unbind(vma, async);
+ list_del_init(>vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(>vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
void i915_vma_parked(struct intel_gt *gt)
{
struct i915_vma *vma, *next;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index d6c05227fb04..8033f5c96efc 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -319,6 +319,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
#define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3f27001a2c8d..b9167f950327 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3970,7 +3970,8 @@ struct drm_i915_gem_vm_bind {
* any error.
*
* VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
- * are not ordered.
+ * are not ordered. Furthermore, parts of the VM_UNBIND operation can be done
+ *
[PATCH v10 23/23] drm/i915/vm_bind: Support capture of persistent mappings
Support dump capture of persistent mappings upon user request.
Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling. They are synchronously
unbound during eviction so that no additional vma resource
reference taking is required in the submission path. Thus, a
list of persistent vmas requiring capture is maintained instead
of a list of vma resources.
v2: enable with CONFIG_DRM_I915_CAPTURE_ERROR, remove gfp
overwrite, add kernel-doc and expand commit message
v3: Ensure vma->resource is valid during capture
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 13 +
drivers/gpu/drm/i915/gt/intel_gtt.c | 5 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 7 +++
drivers/gpu/drm/i915/i915_gem.c | 14 -
drivers/gpu/drm/i915/i915_gpu_error.c | 52 ++-
drivers/gpu/drm/i915/i915_vma.c | 4 ++
drivers/gpu/drm/i915/i915_vma_types.h | 4 ++
include/uapi/drm/i915_drm.h | 9 +++-
8 files changed, 104 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..562a67a988f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ mutex_lock(>vm->vm_capture_lock);
+ if (!list_empty(>vm_capture_link))
+ list_del_init(>vm_capture_link);
+ mutex_unlock(>vm->vm_capture_lock);
+#endif
spin_lock(>vm->vm_rebind_lock);
if (!list_empty(>vm_rebind_link))
list_del_init(>vm_rebind_link);
@@ -357,6 +363,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
continue;
}
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+ mutex_lock(>vm_capture_lock);
+ list_add_tail(>vm_capture_link,
>vm_capture_list);
+ mutex_unlock(>vm_capture_lock);
+ }
+#endif
list_add_tail(>vm_bind_link, >vm_bound_list);
i915_vm_bind_it_insert(vma, >va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2e4c9fabf3b8..103ca55222be 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,11 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
spin_lock_init(>vm_rebind_lock);
spin_lock_init(>userptr_invalidated_lock);
INIT_LIST_HEAD(>userptr_invalidated_list);
+
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ INIT_LIST_HEAD(>vm_capture_list);
+ mutex_init(>vm_capture_lock);
+#endif
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 620b4e020a9f..7f69e1d4fb5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,13 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private objects */
struct drm_i915_gem_object *root_obj;
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ /* @vm_capture_list: list of vm captures */
+ struct list_head vm_capture_list;
+ /* @vm_capture_lock: protects vm_capture_list */
+ struct mutex vm_capture_lock;
+#endif
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 969581e7106f..d97822f203fc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -143,6 +143,8 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
while (!ret && (vma = list_first_entry_or_null(>vma.list,
struct i915_vma,
obj_link))) {
+ bool sync_unbind = true;
+
list_move_tail(>obj_link, _in_list);
if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
continue;
@@ -171,8 +173,18 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
* and destroy the vma from under us.
*/
+ /*
+* Synchronously unbind persistent mappings with capture
+* request so that vma->resource is valid in the error capture
+* path without needing extra reference taking in execbuf path.
+*/
+
[PATCH v10 19/23] 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 9809c58316c2..ba4aca5ff432 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1809,9 +1809,13 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev,
void *data,
if (!HAS_FULL_PPGTT(i915))
return -ENODEV;
- if (args->flags)
+ if (args->flags & I915_VM_CREATE_FLAGS_UNKNOWN)
return -EINVAL;
+ if ((args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) &&
+ !HAS_VM_BIND(i915))
+ return -EOPNOTSUPP;
+
ppgtt = i915_ppgtt_create(to_gt(i915), 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
@@ -1824,15 +1828,32 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev,
void *data,
goto err_put;
}
+ if (args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) {
+ struct drm_i915_gem_object *obj;
+
+ obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ goto err_put;
+ }
+
+ ppgtt->vm.root_obj = obj;
+ }
+
err = xa_alloc(_priv->vm_xa, , >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(>vm);
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e8b41aa8f8c4..b53aef2853cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -150,8 +150,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev, void *data,
*/
static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
{
- /* No support to enable vm_bind mode yet */
- return false;
+ return !!vm->root_obj;
}
struct i915_address_space *
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 7045b2114df6..2e4c9fabf3b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -179,6 +179,8 @@ int i915_vm_lock_objects(struct i915_address_space *vm,
void i915_address_space_fini(struct i915_address_space *vm)
{
drm_mm_takedown(>mm);
+ if (vm->root_obj)
+ i915_gem_object_put(vm->root_obj);
GEM_BUG_ON(!RB_EMPTY_ROOT(>va.rb_root));
mutex_destroy(>vm_bind_lock);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48fd82722f12..030ad237158b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -972,6 +972,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_LMEMBAR_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
GRAPHICS_VER_FULL(i915) >= IP_VER(12,
70))
+#define HAS_VM_BIND(i915) (GRAPHICS_VER(i915) >= 12)
+
/* intel_device_info.c */
static inline struct intel_device_info *
mkwrite_device_info(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 61ef2d9cfa62..20c1bf904a65 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -178,6 +178,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_OA_TIMESTAMP_FREQUENCY:
value = i915_perf_oa_timestamp_frequency(i915);
break;
+ case I915_PARAM_VM_BIND_VERSION:
+ value = HAS_VM_BIND(i915);
+ break;
default:
drm_dbg(>drm, "Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h
[PATCH v10 15/23] 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 804f01b9002d..8fc93f20f70d 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1923,18 +1923,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(>obj->userfault_link);
}
-static int
-__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
-{
- return __i915_request_await_exclusive(rq, >active);
-}
-
static int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request
*rq)
{
int err;
/* Wait for the vma to be bound before we start! */
- err = __i915_request_await_bind(rq, vma);
+ err = i915_request_await_bind(rq, vma);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 1f25e45a6325..d6c05227fb04 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -55,6 +55,22 @@ void i915_vma_unpin_and_release(struct i915_vma **p_vma,
unsigned int flags);
#define __EXEC_OBJECT_NO_RESERVE BIT(31)
#define __EXEC_OBJECT_NO_REQUEST_AWAIT BIT(30)
+/**
+ * i915_request_await_bind() - Setup request to wait for a vma bind completion
+ * @rq: the request which should wait
+ * @vma: vma whose binding @rq should wait to complete
+ *
+ * Setup the request @rq to asynchronously wait for @vma bind to complete
+ * before starting execution.
+ *
+ * Returns 0 on success, error code on failure.
+ */
+static inline int
+i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
+{
+ return __i915_request_await_exclusive(rq, >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 v10 17/23] 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
v3: Initialize vma->userptr_invalidated_link
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 84 ++-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 15
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 +
7 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 913b1f8bda9f..a1aee477e2df 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -20,6 +20,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_USERPTR_USED BIT_ULL(34)
#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -144,7 +145,22 @@ static void eb_scoop_unbound_vma_all(struct
i915_address_space *vm)
{
struct i915_vma *vma, *vn;
- /**
+#ifdef CONFIG_MMU_NOTIFIER
+ /*
+* Move all invalidated userptr vmas back into vm_bind_list so that
+* they are looked up and revalidated.
+*/
+ spin_lock(>userptr_invalidated_lock);
+ list_for_each_entry_safe(vma, vn, >userptr_invalidated_list,
+userptr_invalidated_link) {
+ list_del_init(>userptr_invalidated_link);
+ if (!list_empty(>vm_bind_link))
+ list_move_tail(>vm_bind_link, >vm_bind_list);
+ }
+ spin_unlock(>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_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_bind_lock);
+
+ list_for_each_entry(vma, >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_rebind_lock);
+ if (!list_empty(>vm_rebind_link))
+ list_del_init(>vm_rebind_link);
+ spin_unlock(>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(>userptr_invalidated_lock);
+ if (!list_empty(>userptr_invalidated_list))
+ err = -EAGAIN;
+ spin_unlock(>userptr_invalidated_lock);
+
+ if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
+ read_lock(>i915->mm.notifier_lock);
+ list_for_each_entry(vma, >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(>i915->mm.notifier_lock);
+ }
+#endif
+ if (unlikely(err))
+ goto err_skip;
+
[PATCH v10 20/23] drm/i915/vm_bind: Render VM_BIND documentation
Update i915 documentation to include VM_BIND changes and render all VM_BIND related documentation. Reviewed-by: Matthew Auld Signed-off-by: Niranjana Vishwanathapura --- Documentation/gpu/i915.rst | 78 -- 1 file changed, 59 insertions(+), 19 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 60ea21734902..01429a8f0d6c 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -283,15 +283,18 @@ An Intel GPU has multiple engines. There are several engine types. The Intel GPU family is a family of integrated GPU's using Unified Memory Access. For having the GPU "do work", user space will feed the -GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` -or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will -instruct the GPU to perform work (for example rendering) and that work -needs memory from which to read and memory to which to write. All memory -is encapsulated within GEM buffer objects (usually created with the ioctl -`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU -to create will also list all GEM buffer objects that the batchbuffer reads -and/or writes. For implementation details of memory management see -`GEM BO Management Implementation Details`_. +GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`, +`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` or `DRM_IOCTL_I915_GEM_EXECBUFFER3`. +Most such batchbuffers will instruct the GPU to perform work (for example +rendering) and that work needs memory from which to read and memory to +which to write. All memory is encapsulated within GEM buffer objects +(usually created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). In vm_bind mode +(see `VM_BIND mode`_), the batch buffer and all the GEM buffer objects that +it reads and/or writes should be bound with vm_bind ioctl before submitting +the batch buffer to GPU. In legacy (non-VM_BIND) mode, an ioctl providing a +batchbuffer for the GPU to create will also list all GEM buffer objects that +the batchbuffer reads and/or writes. For implementation details of memory +management see `GEM BO Management Implementation Details`_. The i915 driver allows user space to create a context via the ioctl `DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit @@ -309,8 +312,9 @@ In addition to the ordering guarantees, the kernel will restore GPU state via HW context when commands are issued to a context, this saves user space the need to restore (most of atleast) the GPU state at the start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer -work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) -to identify what context to use with the command. +work can pass that ID (drm_i915_gem_execbuffer3::ctx_id, or in the lower +bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use +with the command. The GPU has its own memory management and address space. The kernel driver maintains the memory translation table for the GPU. For older @@ -318,14 +322,14 @@ GPUs (i.e. those before Gen8), there is a single global such translation table, a global Graphics Translation Table (GTT). For newer generation GPUs each context has its own translation table, called Per-Process Graphics Translation Table (PPGTT). Of important note, is that although -PPGTT is named per-process it is actually per context. When user space -submits a batchbuffer, the kernel walks the list of GEM buffer objects -used by the batchbuffer and guarantees that not only is the memory of -each such GEM buffer object resident but it is also present in the -(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT, -then it is given an address. Two consequences of this are: the kernel -needs to edit the batchbuffer submitted to write the correct value of -the GPU address when a GEM BO is assigned a GPU address and the kernel +PPGTT is named per-process it is actually per context. In legacy +(non-vm_bind) mode, when user space submits a batchbuffer, the kernel walks +the list of GEM buffer objects used by the batchbuffer and guarantees that +not only is the memory of each such GEM buffer object resident but it is +also present in the (PP)GTT. If the GEM buffer object is not yet placed in +the (PP)GTT, then it is given an address. Two consequences of this are: the +kernel needs to edit the batchbuffer submitted to write the correct value +of the GPU address when a GEM BO is assigned a GPU address and the kernel might evict a different GEM BO from the (PP)GTT to make address room for another GEM BO. Consequently, the ioctls submitting a batchbuffer for execution also include a list of all locations within buffers that @@ -407,6 +411,15 @@ objects, which has the goal to make space in gpu virtual address spaces. .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c :internal: +VM_BIND mode + +
[PATCH v10 18/23] 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.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fb4d2dab5053..9809c58316c2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1617,6 +1617,12 @@ i915_gem_create_context(struct drm_i915_private *i915,
INIT_LIST_HEAD(>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 v10 05/23] 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 79b2e19a299f..e43cbb5fa154 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -111,7 +111,8 @@ static void __i915_vma_retire(struct i915_active *ref)
static struct i915_vma *
vma_create(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
- const struct i915_gtt_view *view)
+ const struct i915_gtt_view *view,
+ bool skip_lookup_cache)
{
struct i915_vma *pos = ERR_PTR(-E2BIG);
struct i915_vma *vma;
@@ -198,6 +199,9 @@ vma_create(struct drm_i915_gem_object *obj,
__set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(vma));
}
+ if (skip_lookup_cache)
+ goto skip_rb_insert;
+
rb = NULL;
p = >vma.tree.rb_node;
while (*p) {
@@ -222,6 +226,7 @@ vma_create(struct drm_i915_gem_object *obj,
rb_link_node(>obj_node, rb, p);
rb_insert_color(>obj_node, >vma.tree);
+skip_rb_insert:
if (i915_vma_is_ggtt(vma))
/*
* We put the GGTT vma at the start of the vma-list, followed
@@ -301,7 +306,34 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
/* vma_create() will resolve the race if another creates the vma */
if (unlikely(!vma))
- vma = vma_create(obj, vm, view);
+ vma = vma_create(obj, vm, view, false);
+
+ GEM_BUG_ON(!IS_ERR(vma) && i915_vma_compare(vma, vm, view));
+ return vma;
+}
+
+/**
+ * i915_vma_create_persistent - create a persistent VMA
+ * @obj: parent 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(>ref));
+
+ vma = vma_create(obj, vm, view, true);
+ if (!IS_ERR(vma))
+ i915_vma_set_persistent(vma);
GEM_BUG_ON(!IS_ERR(vma) && i915_vma_compare(vma, vm, view));
return vma;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index ed5c9d682a1b..dd9951a41ff3 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -44,6 +44,10 @@ struct i915_vma *
i915_vma_instance(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
const struct i915_gtt_view *view);
+struct i915_vma *
+i915_vma_create_persistent(struct drm_i915_gem_object *obj,
+ struct i915_address_space *vm,
+ const struct i915_gtt_view *view);
void i915_vma_unpin_and_release(struct i915_vma **p_vma, unsigned int flags);
#define I915_VMA_RELEASE_MAP BIT(0)
@@ -185,6 +189,16 @@ static inline u32 i915_ggtt_pin_bias(struct i915_vma *vma)
return i915_vm_to_ggtt(vma->vm)->pin_bias;
}
+static inline bool i915_vma_is_persistent(const struct i915_vma *vma)
+{
+ return test_bit(I915_VMA_PERSISTENT_BIT, __i915_vma_flags(vma));
+}
+
+static inline void i915_vma_set_persistent(struct i915_vma *vma)
+{
+ set_bit(I915_VMA_PERSISTENT_BIT, __i915_vma_flags(vma));
+}
+
static inline struct i915_vma *i915_vma_get(struct i915_vma *vma)
{
i915_gem_object_get(vma->obj);
@@ -211,7 +225,8 @@ i915_vma_compare(struct i915_vma *vma,
{
ptrdiff_t cmp;
- GEM_BUG_ON(view && !i915_is_ggtt_or_dpt(vm));
+ GEM_BUG_ON(view && !(i915_is_ggtt_or_dpt(vm) ||
+i915_vma_is_persistent(vma)));
cmp = ptrdiff(vma->vm, vm);
if (cmp)
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h
b/drivers/gpu/drm/i915/i915_vma_types.h
index 77fda2244d16..be1cd76304cb 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -265,6
[PATCH v10 11/23] 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.
v2: Use drm_dbg instead of DRM_DEBUG
Reviewed-by: Andi Shyti
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++
.../drm/i915/gem/i915_gem_execbuffer_common.h | 76 ++
3 files changed, 748 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index fc3ed0aea034..68b209a859f1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -153,6 +153,7 @@ gem-y += \
gem/i915_gem_create.o \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
+ gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
new file mode 100644
index ..fb1364f08a61
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
@@ -0,0 +1,671 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_gem_execbuffer_common.h"
+
+#define __EXEC_COMMON_FENCE_WAIT BIT(0)
+#define __EXEC_COMMON_FENCE_SIGNAL BIT(1)
+
+static struct i915_request *eb_throttle(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct intel_timeline *tl = ce->timeline;
+ struct i915_request *rq;
+
+ /*
+* Completely unscientific finger-in-the-air estimates for suitable
+* maximum user request size (to avoid blocking) and then backoff.
+*/
+ if (intel_ring_update_space(ring) >= PAGE_SIZE)
+ return NULL;
+
+ /*
+* Find a request that after waiting upon, there will be at least half
+* the ring available. The hysteresis allows us to compete for the
+* shared ring and should mean that we sleep less often prior to
+* claiming our resources, but not so long that the ring completely
+* drains before we can submit our next request.
+*/
+ list_for_each_entry(rq, >requests, link) {
+ if (rq->ring != ring)
+ continue;
+
+ if (__intel_ring_space(rq->postfix,
+ ring->emit, ring->size) > ring->size / 2)
+ break;
+ }
+ if (>link == >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(>timeline->mutex);
+ intel_context_exit(ce);
+ mutex_unlock(>timeline->mutex);
+
+ if (nonblock)
+ return -EWOULDBLOCK;
+ else
+ return -EINTR;
+ }
+ i915_request_put(rq);
+ }
+
+ return 0;
+}
+
+/**
+ * i915_eb_pin_engine() - Pin the engine
+ * @ce:
[PATCH v10 09/23] 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.
v2: Ensure lvalue of dma_resv_wait_timeout() call is long.
v3: Do not await for purged vmas to become idle during
async unbind
Reviewed-by: Andi Shyti
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +++
drivers/gpu/drm/i915/i915_vma.c | 28 +
drivers/gpu/drm/i915/i915_vma.h | 25 +-
4 files changed, 83 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7bd1861ddbdf..1d8506548d4a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -25,6 +25,45 @@
#include "i915_trace.h"
#include "i915_vgpu.h"
+/**
+ * i915_vm_sync() - Wait until address space is not in use
+ * @vm: address space
+ *
+ * Waits until all requests using the address space are complete.
+ *
+ * Returns: 0 if success, -ve err code upon failure
+ */
+int i915_vm_sync(struct i915_address_space *vm)
+{
+ long ret;
+
+ /* Wait for all requests under this vm to finish */
+ ret = dma_resv_wait_timeout(vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP, false,
+ MAX_SCHEDULE_TIMEOUT);
+ if (ret < 0)
+ return ret;
+ else if (ret > 0)
+ return 0;
+ else
+ return -ETIMEDOUT;
+}
+
+/**
+ * i915_vm_is_active() - Check if address space is being used
+ * @vm: address space
+ *
+ * Check if any request using the specified address space is
+ * active.
+ *
+ * Returns: true if address space is active, false otherwise.
+ */
+bool i915_vm_is_active(const struct i915_address_space *vm)
+{
+ return !dma_resv_test_signaled(vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP);
+}
+
int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object *obj,
struct sg_table *pages)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 243419783052..e62b52c74586 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -52,4 +52,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
#define PIN_OFFSET_MASKI915_GTT_PAGE_MASK
+int i915_vm_sync(struct i915_address_space *vm);
+bool i915_vm_is_active(const struct i915_address_space *vm);
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 353203bd5685..b44fd5f73b64 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -422,6 +422,24 @@ int i915_vma_wait_for_bind(struct i915_vma *vma)
return err;
}
+/**
+ * i915_vma_sync() - Wait for the vma to be idle
+ * @vma: vma to be tested
+ *
+ * Returns 0 on success and error code on failure
+ */
+int i915_vma_sync(struct i915_vma *vma)
+{
+ int ret;
+
+ /* Wait for the asynchronous bindings and pending GPU reads */
+ ret = i915_active_wait(>active);
+ if (ret || !i915_vma_is_persistent(vma) || i915_vma_is_purged(vma))
+ return ret;
+
+ return i915_vm_sync(vma->vm);
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
static int i915_vma_verify_bind_complete(struct i915_vma *vma)
{
@@ -1917,6 +1935,8 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
int err;
assert_object_held(obj);
+ if (i915_vma_is_persistent(vma))
+ return -EINVAL;
GEM_BUG_ON(!vma->pages);
@@ -2131,6 +2151,14 @@ static struct dma_fence *__i915_vma_unbind_async(struct
i915_vma *vma)
return ERR_PTR(-EBUSY);
}
+ if (i915_vma_is_persistent(vma) && !i915_vma_is_purged(vma) &&
+ __i915_sw_fence_await_reservation(>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);
[PATCH v10 13/23] 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 | 579 ++
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 +
drivers/gpu/drm/i915/i915_driver.c| 1 +
include/uapi/drm/i915_drm.h | 61 ++
5 files changed, 644 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68b209a859f1..b2477e85570c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -155,6 +155,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+ gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..49045858a3e9
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,579 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+ DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+ 22; \
+})
+#endif
+
+/**
+ * DOC: User command execution in vm_bind mode
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * @args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ * @fences: array of execbuf fences (See struct eb_fence)
+ * @num_fences: number of fences in @fences array
+ */
+struct i915_execbuffer {
+ struct drm_i915_private *i915;
+ struct drm_file *file;
+ struct drm_i915_gem_execbuffer3 *args;
+
+
[PATCH v10 08/23] 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 | 28 +++
drivers/gpu/drm/i915/i915_vma.h | 10 +++
drivers/gpu/drm/i915/i915_vma_types.h | 8 ++
6 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 4f9df4b756d2..dc738677466b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -86,6 +86,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+ spin_lock(>vm->vm_rebind_lock);
+ if (!list_empty(>vm_rebind_link))
+ list_del_init(>vm_rebind_link);
+ i915_vma_set_purged(vma);
+ spin_unlock(>vm->vm_rebind_lock);
+
list_del_init(>vm_bind_link);
list_del_init(>non_priv_vm_bind_link);
i915_vm_bind_it_remove(vma, >vm->va);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 7ce0237d664f..4f91857dca46 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -291,6 +291,8 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
INIT_LIST_HEAD(>vm_bound_list);
mutex_init(>vm_bind_lock);
INIT_LIST_HEAD(>non_priv_vm_bind_list);
+ INIT_LIST_HEAD(>vm_rebind_list);
+ spin_lock_init(>vm_rebind_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index cb87d0e925c7..dbe6792df3e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -266,6 +266,10 @@ struct i915_address_space {
struct list_head vm_bind_list;
/** @vm_bound_list: List of vm_binding completed */
struct list_head vm_bound_list;
+ /** @vm_rebind_list: list of vmas to be rebinded */
+ struct list_head vm_rebind_list;
+ /** @vm_rebind_lock: protects vm_rebound_list */
+ spinlock_t vm_rebind_lock;
/** @va: tree of persistent vmas */
struct rb_root_cached va;
/** @non_priv_vm_bind_list: list of non-private object mappings */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 30f0c0aca007..353203bd5685 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -243,6 +243,7 @@ vma_create(struct drm_i915_gem_object *obj,
INIT_LIST_HEAD(>vm_bind_link);
INIT_LIST_HEAD(>non_priv_vm_bind_link);
+ INIT_LIST_HEAD(>vm_rebind_link);
return vma;
err_unlock:
@@ -1716,6 +1717,14 @@ static void force_unbind(struct i915_vma *vma)
if (!drm_mm_node_allocated(>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, >flags);
WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
@@ -2082,6 +2091,16 @@ int __i915_vma_unbind(struct i915_vma *vma)
__i915_vma_evict(vma, false);
drm_mm_remove_node(>node); /* pairs with i915_vma_release() */
+
+ if (i915_vma_is_persistent(vma)) {
+ spin_lock(>vm->vm_rebind_lock);
+ if (list_empty(>vm_rebind_link) &&
+ !i915_vma_is_purged(vma))
+ list_add_tail(>vm_rebind_link,
+ >vm->vm_rebind_list);
+ spin_unlock(>vm->vm_rebind_lock);
+ }
+
return 0;
}
@@ -2116,6 +2135,15 @@ static struct dma_fence *__i915_vma_unbind_async(struct
i915_vma *vma)
drm_mm_remove_node(>node); /* pairs with i915_vma_release() */
+ if (i915_vma_is_persistent(vma)) {
+ spin_lock(>vm->vm_rebind_lock);
+ if (list_empty(>vm_rebind_link) &&
+ !i915_vma_is_purged(vma))
+ list_add_tail(>vm_rebind_link,
+ >vm->vm_rebind_list);
+ spin_unlock(>vm->vm_rebind_lock);
+ }
+
return fence;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.h
[PATCH v10 04/23] drm/i915/vm_bind: Support partially mapped vma resource
As persistent vmas can be partialled mapped to an object, remove restriction which require vma resource sg table to be just pointer to object's sg table. Reviewed-by: Matthew Auld Signed-off-by: Niranjana Vishwanathapura --- drivers/gpu/drm/i915/i915_vma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 34f0e6c923c2..79b2e19a299f 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -2060,8 +2060,7 @@ static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma) if (!drm_mm_node_allocated(>node)) return NULL; - if (i915_vma_is_pinned(vma) || - >obj->mm.rsgt->table != vma->resource->bi.pages) + if (i915_vma_is_pinned(vma)) return ERR_PTR(-EAGAIN); /* -- 2.21.0.rc0.32.g243a4c7e27
[PATCH v10 03/23] 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 005a7f842784..86469710bd59 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -15,10 +15,18 @@
#include "i915_trace.h"
#include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region **placements,
- unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the regions
+ * @placements: list of regions
+ * @n_placements: number of the placements
+ *
+ * Returns the largest of min_page_size of the @placements,
+ * or I915_GTT_PAGE_SIZE_4K if @n_placements is 0.
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
{
- u32 max_page_size = 0;
+ u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
for (i = 0; i < n_placements; i++) {
@@ -28,7 +36,6 @@ static u32 object_max_page_size(struct intel_memory_region
**placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
- GEM_BUG_ON(!max_page_size);
return max_page_size;
}
@@ -99,7 +106,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
*i915, u64 size,
i915_gem_flush_free_objects(i915);
- size = round_up(size, object_max_page_size(placements, n_placements));
+ size = round_up(size, i915_gem_object_max_page_size(placements,
+ n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3db53769864c..5455ca0eabe9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
}
void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements);
void i915_objects_module_exit(void);
int i915_objects_module_init(void);
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v10 06/23] drm/i915/vm_bind: Implement bind and unbind of object
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
v2: On older platforms ctx->vm is not set, check for it.
In vm_bind call, add vma to vm_bind_list.
Add more input validity checks.
Update some documentation.
v3: In vm_bind call, add vma to vm_bound_list as user can
request a fence and pass to execbuf3 as input fence.
Remove short term pinning with PIN_VALIDATE flag.
v4: Replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode().
v5: Ensure all reserved fields are 0, use PIN_NOEVICT.
v6: Add reserved fields to drm_i915_gem_vm_bind.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context.h | 15 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 5 +
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 26 ++
.../drm/i915/gem/i915_gem_vm_bind_object.c| 330 ++
drivers/gpu/drm/i915/gt/intel_gtt.c | 10 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +
drivers/gpu/drm/i915/i915_driver.c| 3 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 14 +
include/uapi/drm/i915_drm.h | 105 ++
11 files changed, 519 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f47f00b162a4..fc3ed0aea034 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -171,6 +171,7 @@ gem-y += \
gem/i915_gem_ttm_move.o \
gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
+ gem/i915_gem_vm_bind_object.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 899fa8f1e0fe..e8b41aa8f8c4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -139,6 +139,21 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+/**
+ * i915_gem_vm_is_vm_bind_mode() - Check if address space is in vm_bind mode
+ * @vm: the address space
+ *
+ * Returns:
+ * true: @vm is in vm_bind mode; allows only vm_bind method of binding.
+ * false: @vm is not in vm_bind mode; allows only legacy execbuff method
+ *of binding.
+ */
+static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
+{
+ /* No support to enable vm_bind mode yet */
+ return false;
+}
+
struct i915_address_space *
i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 192bb3f10733..6456f15448bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -785,6 +785,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
+ if (ctx->vm && i915_gem_vm_is_vm_bind_mode(ctx->vm)) {
+ i915_gem_context_put(ctx);
+ return -EOPNOTSUPP;
+ }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
new file mode 100644
index ..5064aba9ab87
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
[PATCH v10 14/23] 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 763ead20ad55..804f01b9002d 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -441,12 +441,25 @@ int i915_vma_sync(struct i915_vma *vma)
return i915_vm_sync(vma->vm);
}
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
-static int i915_vma_verify_bind_complete(struct i915_vma *vma)
+/**
+ * i915_vma_verify_bind_complete() - Check for the bind completion of the vma
+ * @vma: vma to check for bind completion
+ *
+ * As the fence reference is obtained under RCU, no locking is required by
+ * the caller.
+ *
+ * Returns: 0 if the vma bind is completed. Error code otherwise.
+ */
+int i915_vma_verify_bind_complete(struct i915_vma *vma)
{
- struct dma_fence *fence = i915_active_fence_get(>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(>active.excl);
if (!fence)
return 0;
@@ -459,9 +472,6 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
return err;
}
-#else
-#define i915_vma_verify_bind_complete(_vma) 0
-#endif
I915_SELFTEST_EXPORT void
i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res,
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index de1756e4f638..1f25e45a6325 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -487,6 +487,7 @@ void i915_vma_make_purgeable(struct i915_vma *vma);
int i915_vma_wait_for_bind(struct i915_vma *vma);
int i915_vma_sync(struct i915_vma *vma);
+int i915_vma_verify_bind_complete(struct i915_vma *vma);
/**
* i915_vma_get_current_resource - Get the current resource of the vma
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v10 01/23] 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 46e71f62fcec..b90901ad6866 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -346,7 +346,16 @@ static int proto_context_register(struct
drm_i915_file_private *fpriv,
return ret;
}
-static struct i915_address_space *
+/**
+ * i915_gem_vm_lookup() - looks up for the VM reference given the vm id
+ * @file_priv: the private data associated with the user's file
+ * @id: the VM id
+ *
+ * Finds the VM reference associated to a specific id.
+ *
+ * Returns the VM pointer on success, NULL in case of failure.
+ */
+struct i915_address_space *
i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
{
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e5b0f66ea1fe..899fa8f1e0fe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -139,6 +139,9 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+struct i915_address_space *
+i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
+
struct i915_gem_context *
i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id);
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v10 07/23] 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 b90901ad6866..fb4d2dab5053 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -83,6 +83,7 @@
#include "i915_file_private.h"
#include "i915_gem_context.h"
+#include "i915_gem_internal.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 86469710bd59..717403c79226 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
@@ -251,6 +252,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+ u32 vm_id;
};
static void repr_placements(char *buf, size_t size,
@@ -400,9 +402,32 @@ static int ext_set_protected(struct i915_user_extension
__user *base, void *data
return 0;
}
+static int ext_set_vm_private(struct i915_user_extension __user *base,
+ void *data)
+{
+ struct drm_i915_gem_create_ext_vm_private ext;
+ struct create_ext *ext_data = data;
+
+ if (copy_from_user(, 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 =
[PATCH v10 02/23] 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(, resv, dma_resv_usage_rw(write));
+ dma_resv_iter_begin(, resv, usage);
dma_resv_for_each_fence_unlocked(, 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 v10 10/23] 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.
v5: Ensure __I915_TIMELINE_FENCE_UNKNOWN_FLAGS are not set.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 4 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 98 ++-
drivers/gpu/drm/i915/i915_vma.c | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
include/uapi/drm/i915_drm.h | 58 ++-
5 files changed, 165 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 36262a6357b5..b70e900e35ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -8,6 +8,7 @@
#include
+struct dma_fence;
struct drm_device;
struct drm_file;
struct i915_address_space;
@@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void
*data,
void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence);
+
#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index dc738677466b..fd1d82ce99e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -7,6 +7,8 @@
#include
+#include
+
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_vm_bind.h"
@@ -101,6 +103,77 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
i915_gem_object_put(vma->obj);
}
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,
+ u32 handle, u64 point)
+{
+ struct drm_syncobj *syncobj;
+
+ syncobj = drm_syncobj_find(file, handle);
+ if (!syncobj) {
+ drm_dbg(>vm->i915->drm,
+ "Invalid syncobj handle provided\n");
+ return -ENOENT;
+ }
+
+ /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+ if (point) {
+ vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+ if (!vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_put(syncobj);
+ return -ENOMEM;
+ }
+ } else {
+ vma->vm_bind_fence.chain_fence = NULL;
+ }
+ vma->vm_bind_fence.syncobj = syncobj;
+ vma->vm_bind_fence.value = point;
+
+ return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+ if (!vma->vm_bind_fence.syncobj)
+ return;
+
+ drm_syncobj_put(vma->vm_bind_fence.syncobj);
+ dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+ vma->vm_bind_fence.syncobj = NULL;
+}
+
+/**
+ * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
+ * @vma: vma mapping requiring signaling
+ * @fence: fence to be added
+ *
+ * Associate specified @fence with the @vma's syncobj to be
+ * signaled after the @fence work completes.
+ */
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence)
+{
+ struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+ if (!syncobj)
+ return;
+
+ if (vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+ /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+ vma->vm_bind_fence.chain_fence = NULL;
+ } else {
+ drm_syncobj_replace_fence(syncobj, fence);
+ }
+}
+
static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
struct drm_i915_gem_vm_unbind *va)
{
@@ -206,6 +279,11 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
if (!va->length || !IS_ALIGNED(va->start, I915_GTT_PAGE_SIZE))
ret = -EINVAL;
+ /* In fences are not supported */
+ if ((va->fence.flags & I915_TIMELINE_FENCE_WAIT) ||
+ (va->fence.flags & __I915_TIMELINE_FENCE_UNKNOWN_FLAGS))
+ ret = -EINVAL;
+
obj = i915_gem_object_lookup(file, va->handle);
if (!obj)
return -ENOENT;
@@ -238,6 +316,13 @@ static int
[PATCH v10 12/23] 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| 513 ++
1 file changed, 39 insertions(+), 474 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6a7f0227f65f..8b49543f3265 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -28,6 +28,7 @@
#include "i915_file_private.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
#include "i915_gem_evict.h"
#include "i915_gem_ioctls.h"
#include "i915_reg.h"
@@ -236,13 +237,6 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
-struct eb_fence {
- struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
- struct dma_fence *dma_fence;
- u64 value;
- struct dma_fence_chain *chain_fence;
-};
-
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -2452,164 +2446,29 @@ static const enum intel_engine_id user_ring_map[] = {
[I915_EXEC_VEBOX] = VECS0
};
-static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct
intel_context *ce)
-{
- struct intel_ring *ring = ce->ring;
- struct intel_timeline *tl = ce->timeline;
- struct i915_request *rq;
-
- /*
-* Completely unscientific finger-in-the-air estimates for suitable
-* maximum user request size (to avoid blocking) and then backoff.
-*/
- if (intel_ring_update_space(ring) >= PAGE_SIZE)
- return NULL;
-
- /*
-* Find a request that after waiting upon, there will be at least half
-* the ring available. The hysteresis allows us to compete for the
-* shared ring and should mean that we sleep less often prior to
-* claiming our resources, but not so long that the ring completely
-* drains before we can submit our next request.
-*/
- list_for_each_entry(rq, >requests, link) {
- if (rq->ring != ring)
- continue;
-
- if (__intel_ring_space(rq->postfix,
- ring->emit, ring->size) > ring->size / 2)
- break;
- }
- if (>link == >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(>timeline->mutex);
- intel_context_exit(ce);
- mutex_unlock(>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 generate requests in
[PATCH v10 16/23] 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 49045858a3e9..913b1f8bda9f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -3,6 +3,7 @@
* Copyright © 2022 Intel Corporation
*/
+#include
#include
#include
@@ -19,6 +20,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -42,7 +44,9 @@
* execlist. Hence, no support for implicit sync.
*
* The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
*
* The execbuf3 ioctl directly specifies the batch addresses instead of as
* object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -58,6 +62,13 @@
* So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
* vma lookup table, implicit sync, vma active reference tracking etc., are not
* applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
*/
/**
@@ -129,6 +140,23 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
}
+static void eb_scoop_unbound_vma_all(struct i915_address_space *vm)
+{
+ struct i915_vma *vma, *vn;
+
+ /**
+* Move all unbound vmas back into vm_bind_list so that they are
+* revalidated.
+*/
+ spin_lock(>vm_rebind_lock);
+ list_for_each_entry_safe(vma, vn, >vm_rebind_list, vm_rebind_link) {
+ list_del_init(>vm_rebind_link);
+ if (!list_empty(>vm_bind_link))
+ list_move_tail(>vm_bind_link, >vm_bind_list);
+ }
+ spin_unlock(>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, >ww);
+ if (err)
+ return err;
+
+ list_for_each_entry(vma, >non_priv_vm_bind_list,
+ non_priv_vm_bind_link) {
+ err = i915_gem_object_lock(vma->obj, >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_bind_lock);
+
+ if (!(eb->args->flags & __EXEC3_HAS_PIN))
+ return;
+
+ assert_object_held(vm->root_obj);
+
+ list_for_each_entry_safe(vma, vn, >vm_bind_list, vm_bind_link)
+ if (!i915_vma_verify_bind_complete(vma))
+ list_move_tail(>vm_bind_link, >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 fences */
+ if
[PATCH v10 22/23] drm/i915/vm_bind: Properly build persistent map sg table
Properly build the sg table for persistent mapping which can
be partial map of the underlying object. Ensure the sg pages
are properly set for page backed regions. The dump capture
support requires this for page backed regions.
v2: Remove redundant sg_mark_end() call
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 113 +++-
1 file changed, 112 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 5b9ae5ebf55c..2f0994f0ed42 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1328,6 +1328,113 @@ intel_partial_pages(const struct i915_gtt_view *view,
return ERR_PTR(ret);
}
+static unsigned int
+intel_copy_dma_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+ struct scatterlist *dst_sg, *src_sg;
+ unsigned int i, len, nents = 0;
+
+ dst_sg = dst_st->sgl;
+ for_each_sgtable_dma_sg(src_st, src_sg, i) {
+ if (sg_dma_len(src_sg) <= offset) {
+ offset -= sg_dma_len(src_sg);
+ continue;
+ }
+
+ nents++;
+ len = min(sg_dma_len(src_sg) - offset, length);
+ if (!dry_run) {
+ sg_dma_address(dst_sg) = sg_dma_address(src_sg) +
offset;
+ sg_dma_len(dst_sg) = len;
+ dst_sg = sg_next(dst_sg);
+ }
+
+ length -= len;
+ offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static unsigned int
+intel_copy_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+ struct scatterlist *dst_sg, *src_sg;
+ unsigned int i, len, nents = 0;
+
+ dst_sg = dst_st->sgl;
+ for_each_sgtable_sg(src_st, src_sg, i) {
+ if (src_sg->length <= offset) {
+ offset -= src_sg->length;
+ continue;
+ }
+
+ nents++;
+ len = min(src_sg->length - offset, length);
+ if (!dry_run) {
+ unsigned long pfn;
+
+ pfn = page_to_pfn(sg_page(src_sg)) + offset / PAGE_SIZE;
+ sg_set_page(dst_sg, pfn_to_page(pfn), len, 0);
+ dst_sg = sg_next(dst_sg);
+ }
+
+ length -= len;
+ offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static noinline struct sg_table *
+intel_persistent_partial_pages(const struct i915_gtt_view *view,
+ struct drm_i915_gem_object *obj)
+{
+ u64 offset = view->partial.offset << PAGE_SHIFT;
+ struct sg_table *st, *obj_st = obj->mm.pages;
+ u64 length = view->partial.size << PAGE_SHIFT;
+ unsigned int nents;
+ int ret = -ENOMEM;
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ goto err_st_alloc;
+
+ /* Get required sg_table size */
+ nents = intel_copy_dma_sg(obj_st, st, offset, length, true);
+ if (i915_gem_object_has_struct_page(obj)) {
+ unsigned int pg_nents;
+
+ pg_nents = intel_copy_sg(obj_st, st, offset, length, true);
+ if (nents < pg_nents)
+ nents = pg_nents;
+ }
+
+ ret = sg_alloc_table(st, nents, GFP_KERNEL);
+ if (ret)
+ goto err_sg_alloc;
+
+ /* Build sg_table for specified section */
+ intel_copy_dma_sg(obj_st, st, offset, length, false);
+ if (i915_gem_object_has_struct_page(obj))
+ intel_copy_sg(obj_st, st, offset, length, false);
+
+ return st;
+
+err_sg_alloc:
+ kfree(st);
+err_st_alloc:
+ return ERR_PTR(ret);
+}
+
static int
__i915_vma_get_pages(struct i915_vma *vma)
{
@@ -1360,7 +1467,11 @@ __i915_vma_get_pages(struct i915_vma *vma)
break;
case I915_GTT_VIEW_PARTIAL:
- pages = intel_partial_pages(>gtt_view, vma->obj);
+ if (i915_vma_is_persistent(vma))
+ pages = intel_persistent_partial_pages(>gtt_view,
+ vma->obj);
+ else
+ pages = intel_partial_pages(>gtt_view, vma->obj);
break;
}
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v10 00/23] 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. NOTEs: * It is based on below VM_BIND design+uapi rfc. Documentation/gpu/rfc/i915_vm_bind.rst * The IGT RFC series is posted as, [PATCH i-g-t v10 0/19] vm_bind: Add VM_BIND validation support v2: Address various review comments v3: Address review comments and other fixes v4: Remove vm_unbind out fence uapi which is not supported yet, replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to non-recoverable faults v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, add new patch for async vm_unbind support v7: Rebased, minor cleanups as per review feedback v8: Rebased, add capture support v9: Address capture support feedback from v8 v10: Properly handle vma->resource for mappings with capture request Test-with: 20230118071350.17498-1-niranjana.vishwanathap...@intel.com Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (23): drm/i915/vm_bind: Expose vm lookup function drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() drm/i915/vm_bind: Expose i915_gem_object_max_page_size() drm/i915/vm_bind: Support partially mapped vma resource drm/i915/vm_bind: Add support to create persistent vma drm/i915/vm_bind: Implement bind and unbind of object drm/i915/vm_bind: Support for VM private BOs drm/i915/vm_bind: Add support to handle object evictions drm/i915/vm_bind: Support persistent vma activeness tracking drm/i915/vm_bind: Add out fence support drm/i915/vm_bind: Abstract out common execbuf functions drm/i915/vm_bind: Use common execbuf functions in execbuf path drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl drm/i915/vm_bind: Update i915_vma_verify_bind_complete() drm/i915/vm_bind: Expose i915_request_await_bind() drm/i915/vm_bind: Handle persistent vmas in execbuf3 drm/i915/vm_bind: userptr dma-resv changes drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode drm/i915/vm_bind: Render VM_BIND documentation drm/i915/vm_bind: Async vm_unbind support drm/i915/vm_bind: Properly build persistent map sg table drm/i915/vm_bind: Support capture of persistent mappings Documentation/gpu/i915.rst| 78 +- drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 522 +-- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 872 ++ .../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++ .../drm/i915/gem/i915_gem_execbuffer_common.h | 76 ++ drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + .../drm/i915/gem/i915_gem_vm_bind_object.c| 463 ++ drivers/gpu/drm/i915/gt/intel_gtt.c | 22 + drivers/gpu/drm/i915/gt/intel_gtt.h | 28 + drivers/gpu/drm/i915/i915_driver.c| 4 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_gem.c | 14 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + drivers/gpu/drm/i915/i915_gem_gtt.h | 3 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 52 +- drivers/gpu/drm/i915/i915_sw_fence.c | 28 +- drivers/gpu/drm/i915/i915_sw_fence.h | 23 +- drivers/gpu/drm/i915/i915_vma.c | 301 +- drivers/gpu/drm/i915/i915_vma.h | 70 +- drivers/gpu/drm/i915/i915_vma_types.h | 43 + include/uapi/drm/i915_drm.h | 281 +- 32 files changed, 3245 insertions(+), 553
Re: [PATCH v2 1/3] drm/msm/gpu: Add devfreq tuning debugfs
Following build regression noticed on Linux next-20230118. Regressions found on arm: - build/gcc-8-imx_v6_v7_defconfig - build/gcc-12-imx_v6_v7_defconfig - build/clang-15-imx_v6_v7_defconfig - build/clang-nightly-imx_v6_v7_defconfig Reported-by: Linux Kernel Functional Testing WARNING: unmet direct dependencies detected for DEVFREQ_GOV_SIMPLE_ONDEMAND Depends on [n]: PM_DEVFREQ [=n] Selected by [y]: - DRM_MSM [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_QCOM [=n] || SOC_IMX5 [=y] || COMPILE_TEST [=n]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM [=n] || QCOM_OCMEM [=n]=n) && (QCOM_LLCC [=n] || QCOM_LLCC [=n]=n) && (QCOM_COMMAND_DB [=n] || QCOM_COMMAND_DB [=n]=n) WARNING: unmet direct dependencies detected for DEVFREQ_GOV_SIMPLE_ONDEMAND Depends on [n]: PM_DEVFREQ [=n] Selected by [y]: - DRM_MSM [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_QCOM [=n] || SOC_IMX5 [=y] || COMPILE_TEST [=n]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM [=n] || QCOM_OCMEM [=n]=n) && (QCOM_LLCC [=n] || QCOM_LLCC [=n]=n) && (QCOM_COMMAND_DB [=n] || QCOM_COMMAND_DB [=n]=n) make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc' In file included from drivers/gpu/drm/msm/msm_gpu.h:18, from drivers/gpu/drm/msm/adreno/adreno_gpu.h:15, from drivers/gpu/drm/msm/adreno/adreno_device.c:9: drivers/gpu/drm/msm/msm_drv.h:237:45: error: field 'gpu_devfreq_config' has incomplete type 237 | struct devfreq_simple_ondemand_data gpu_devfreq_config; | ^~ Build log: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230118/testrun/14250189/suite/build/test/gcc-12-imx_v6_v7_defconfig/log This was already reported a while back on lore, https://lore.kernel.org/all/202301130108.fslqjvj8-...@intel.com/ -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 2/2] drm_print: Remove deprecated DRM_DEBUG_KMS_RATELIMITED()
Am 17.01.23 um 19:12 schrieb Das, Nirmoy: Hi Alex, On 1/17/2023 7:06 PM, Alex Deucher wrote: On Tue, Jan 17, 2023 at 1:05 PM Nirmoy Das wrote: There are no current users of DRM_DEBUG_KMS_RATELIMITED() so remove it. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Sam Ravnborg Signed-off-by: Nirmoy Das Reviewed-by: Sam Ravnborg Series is: Reviewed-by: Alex Deucher Feel free to take the patches through whatever tree you want. Please help me with this, I don't have committer rights for any tree. Going to push that into drm-misc-next later today. Thanks, Christian. Nirmoy Alex --- include/drm/drm_print.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a44fb7ef257f..c3753da97c4e 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -605,9 +605,6 @@ void __drm_err(const char *format, ...); #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__) -/* NOTE: this is deprecated in favor of drm_dbg_kms_ratelimited(NULL, ...). */ -#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL, fmt, ## __VA_ARGS__) - /* * struct drm_device based WARNs * -- 2.39.0
Re: [PATCH v9 23/23] drm/i915/vm_bind: Support capture of persistent mappings
On Tue, Dec 13, 2022 at 12:03:07PM +, Matthew Auld wrote:
On 12/12/2022 23:15, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling, thus not adding any
additional latency to the submission path.
A list of persistent vmas requiring capture is maintained
instead of a list of vma resources. This allows for no
additional handling around eviction.
v2: enable with CONFIG_DRM_I915_CAPTURE_ERROR, remove gfp
overwrite, add kernel-doc and expand commit message
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../gpu/drm/i915/gem/i915_gem_vm_bind_object.c | 13 +
drivers/gpu/drm/i915/gt/intel_gtt.c| 5 +
drivers/gpu/drm/i915/gt/intel_gtt.h| 7 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 18 +-
drivers/gpu/drm/i915/i915_vma.c| 4
drivers/gpu/drm/i915/i915_vma_types.h | 4
include/uapi/drm/i915_drm.h| 9 +++--
7 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..562a67a988f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ mutex_lock(>vm->vm_capture_lock);
+ if (!list_empty(>vm_capture_link))
+ list_del_init(>vm_capture_link);
+ mutex_unlock(>vm->vm_capture_lock);
+#endif
spin_lock(>vm->vm_rebind_lock);
if (!list_empty(>vm_rebind_link))
list_del_init(>vm_rebind_link);
@@ -357,6 +363,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
continue;
}
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+ mutex_lock(>vm_capture_lock);
+ list_add_tail(>vm_capture_link,
>vm_capture_list);
+ mutex_unlock(>vm_capture_lock);
+ }
+#endif
list_add_tail(>vm_bind_link, >vm_bound_list);
i915_vm_bind_it_insert(vma, >va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2e4c9fabf3b8..103ca55222be 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,11 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
spin_lock_init(>vm_rebind_lock);
spin_lock_init(>userptr_invalidated_lock);
INIT_LIST_HEAD(>userptr_invalidated_list);
+
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ INIT_LIST_HEAD(>vm_capture_list);
+ mutex_init(>vm_capture_lock);
+#endif
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 620b4e020a9f..7f69e1d4fb5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,13 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private objects */
struct drm_i915_gem_object *root_obj;
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ /* @vm_capture_list: list of vm captures */
+ struct list_head vm_capture_list;
+ /* @vm_capture_lock: protects vm_capture_list */
+ struct mutex vm_capture_lock;
+#endif
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64..76b2834ce958 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1460,6 +1460,22 @@ capture_vma(struct intel_engine_capture_vma *next,
return next;
}
+static struct intel_engine_capture_vma *
+capture_user_vm(struct intel_engine_capture_vma *capture,
+ struct i915_address_space *vm, gfp_t gfp)
+{
+ struct i915_vma *vma;
+
+ mutex_lock(>vm_capture_lock);
+ /* vma->resource must be valid here as persistent vmas are bound */
+ list_for_each_entry(vma, >vm_capture_list, vm_capture_link)
+ capture = capture_vma_snapshot(capture, vma->resource,
Thinking some more on this, I don't think we can actually do this. The
vma->resource at this stage could be complete nonsense (could even be
NULL?), if you consider piplelined migrations. For example if we async
evict something, the object state can be freely updated (maybe even
more than once), even though the dma-resv is still
Re: [PATCH] accel: Add .mmap to DRM_ACCEL_FOPS
On Tue, Jan 17, 2023 at 7:48 PM Jeffrey Hugo wrote: > > In reviewing the ivpu driver, DEFINE_DRM_ACCEL_FOPS could have been used > if DRM_ACCEL_FOPS defined .mmap to be drm_gem_mmap. Lets add that since > accel drivers are a variant of drm drivers, modern drm drivers are > expected to use GEM, and mmap() is a common operation that is expected > to be heavily used in accel drivers thus the common accel driver should > be able to just use DEFINE_DRM_ACCEL_FOPS() for convenience. > > Signed-off-by: Jeffrey Hugo > --- > include/drm/drm_accel.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_accel.h b/include/drm/drm_accel.h > index 65c0affb..d495506 100644 > --- a/include/drm/drm_accel.h > +++ b/include/drm/drm_accel.h > @@ -27,7 +27,8 @@ > .compat_ioctl = drm_compat_ioctl,\ > .poll = drm_poll,\ > .read = drm_read,\ > - .llseek = noop_llseek > + .llseek = noop_llseek, \ > + .mmap = drm_gem_mmap > > /** > * DEFINE_DRM_ACCEL_FOPS() - macro to generate file operations for > accelerators drivers > -- > 2.7.4 > Reviewed-by: Oded Gabbay I'll merge it through my tree. Thanks, Oded
Re: [PATCH] MAINTAINERS/ACCEL: Add include/drm/drm_accel.h to the accel entry
On Tue, Jan 17, 2023 at 8:10 PM Jeffrey Hugo wrote: > > get_maintainer.pl does not suggest Oded Gabbay, the DRM COMPUTE > ACCELERATORS DRIVERS AND FRAMEWORK maintainer for changes that touch > the Accel Subsystem header - drm_accel.h. This is because that file is > missing from the Accel Subsystem entry. Fix this. > > Signed-off-by: Jeffrey Hugo > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 31ffd4b..7995ec7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6754,6 +6754,7 @@ C:irc://irc.oftc.net/dri-devel > T: git https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git > F: Documentation/accel/ > F: drivers/accel/ > +F: include/drm/drm_accel.h > > DRM DRIVERS FOR ALLWINNER A10 > M: Maxime Ripard > -- > 2.7.4 > Reviewed-by: Oded Gabbay I'll merge it through my tree. Thanks, Oded.
[PATCH drm-next 14/14] drm/nouveau: debugfs: implement DRM GPU VA debugfs
Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 2a36d1ca8fda..7f6ccc5d1d86 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -202,6 +202,29 @@ nouveau_debugfs_pstate_open(struct inode *inode, struct
file *file)
return single_open(file, nouveau_debugfs_pstate_get, inode->i_private);
}
+static int
+nouveau_debugfs_gpuva(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
+ struct nouveau_cli *cli;
+
+ mutex_lock(>clients_lock);
+ list_for_each_entry(cli, >clients, head) {
+ struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(cli);
+
+ if (!uvmm)
+ continue;
+
+ nouveau_uvmm_lock(uvmm);
+ drm_debugfs_gpuva_info(m, >umgr);
+ nouveau_uvmm_unlock(uvmm);
+ }
+ mutex_unlock(>clients_lock);
+
+ return 0;
+}
+
static const struct file_operations nouveau_pstate_fops = {
.owner = THIS_MODULE,
.open = nouveau_debugfs_pstate_open,
@@ -213,6 +236,7 @@ static const struct file_operations nouveau_pstate_fops = {
static struct drm_info_list nouveau_debugfs_list[] = {
{ "vbios.rom", nouveau_debugfs_vbios_image, 0, NULL },
{ "strap_peek", nouveau_debugfs_strap_peek, 0, NULL },
+ DRM_DEBUGFS_GPUVA_INFO(nouveau_debugfs_gpuva, NULL),
};
#define NOUVEAU_DEBUGFS_ENTRIES ARRAY_SIZE(nouveau_debugfs_list)
--
2.39.0
[PATCH drm-next 13/14] drm/nouveau: implement new VM_BIND UAPI
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and userspace, respectively.
2) Allocate and free a VA space region as well as bind and unbind memory
to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
UMDs can request the named operations to be processed either
synchronously or asynchronously. It supports DRM syncobjs
(incl. timelines) as synchronization mechanism. The management of the
GPU VA mappings is implemented with the DRM GPU VA manager.
3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The
execution happens asynchronously. It supports DRM syncobj (incl.
timelines) as synchronization mechanism. DRM GEM object locking is
handled with drm_exec.
Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM
GPU scheduler for the asynchronous paths.
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/driver-uapi.rst | 3 +
drivers/gpu/drm/nouveau/Kbuild | 2 +
drivers/gpu/drm/nouveau/Kconfig | 2 +
drivers/gpu/drm/nouveau/nouveau_abi16.c | 16 +
drivers/gpu/drm/nouveau/nouveau_abi16.h | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 23 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +-
drivers/gpu/drm/nouveau/nouveau_exec.c | 310 ++
drivers/gpu/drm/nouveau/nouveau_exec.h | 55 ++
drivers/gpu/drm/nouveau/nouveau_sched.c | 780
drivers/gpu/drm/nouveau/nouveau_sched.h | 98 +++
11 files changed, 1295 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.h
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.h
diff --git a/Documentation/gpu/driver-uapi.rst
b/Documentation/gpu/driver-uapi.rst
index 9c7ca6e33a68..c08bcbb95fb3 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -13,4 +13,7 @@ drm/nouveau uAPI
VM_BIND / EXEC uAPI
---
+.. kernel-doc:: drivers/gpu/drm/nouveau/nouveau_exec.c
+:doc: Overview
+
.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index ee281bb76463..cf6b3a80c0c8 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -47,6 +47,8 @@ nouveau-y += nouveau_prime.o
nouveau-y += nouveau_sgdma.o
nouveau-y += nouveau_ttm.o
nouveau-y += nouveau_vmm.o
+nouveau-y += nouveau_exec.o
+nouveau-y += nouveau_sched.o
nouveau-y += nouveau_uvmm.o
# DRM - modesetting
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index a0bb3987bf63..59e5c13be9b6 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -10,6 +10,8 @@ config DRM_NOUVEAU
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
+ select DRM_EXEC
+ select DRM_SCHED
select I2C
select I2C_ALGOBIT
select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 36cc80eb0e20..694777a58bca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -35,6 +35,7 @@
#include "nouveau_chan.h"
#include "nouveau_abi16.h"
#include "nouveau_vmm.h"
+#include "nouveau_sched.h"
static struct nouveau_abi16 *
nouveau_abi16(struct drm_file *file_priv)
@@ -125,6 +126,17 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
{
struct nouveau_abi16_ntfy *ntfy, *temp;
+ /* When a client exits without waiting for it's queued up jobs to
+* finish it might happen that we fault the channel. This is due to
+* drm_file_free() calling drm_gem_release() before the postclose()
+* callback. Hence, we can't tear down this scheduler entity before
+* uvmm mappings are unmapped. Currently, we can't detect this case.
+*
+* However, this should be rare and harmless, since the channel isn't
+* needed anymore.
+*/
+ nouveau_sched_entity_fini(>sched_entity);
+
/* wait for all activity to stop before cleaning up */
if (chan->chan)
nouveau_channel_idle(chan->chan);
@@ -311,6 +323,10 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
if (ret)
goto done;
+ ret = nouveau_sched_entity_init(>sched_entity, >sched);
+ if (ret)
+ goto done;
+
init->channel = chan->chan->chid;
if (device->info.family >= NV_DEVICE_INFO_V0_TESLA)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
b/drivers/gpu/drm/nouveau/nouveau_abi16.h
index
[PATCH drm-next 12/14] drm/nouveau: implement uvmm for user mode bindings
uvmm provides the driver abstraction around the DRM GPU VA manager
connecting it to the nouveau infrastructure.
It handles the split and merge operations provided by the DRM GPU VA
manager for map operations colliding with existent mappings and takes
care of the driver specific locking around the DRM GPU VA manager.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/Kbuild | 1 +
drivers/gpu/drm/nouveau/nouveau_abi16.c | 7 +
drivers/gpu/drm/nouveau/nouveau_bo.c| 147 +++---
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +
drivers/gpu/drm/nouveau/nouveau_drv.h | 48 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 51 ++-
drivers/gpu/drm/nouveau/nouveau_mem.h | 5 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 575
drivers/gpu/drm/nouveau/nouveau_uvmm.h | 68 +++
11 files changed, 835 insertions(+), 73 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.h
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index 5e5617006da5..ee281bb76463 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -47,6 +47,7 @@ nouveau-y += nouveau_prime.o
nouveau-y += nouveau_sgdma.o
nouveau-y += nouveau_ttm.o
nouveau-y += nouveau_vmm.o
+nouveau-y += nouveau_uvmm.o
# DRM - modesetting
nouveau-$(CONFIG_DRM_NOUVEAU_BACKLIGHT) += nouveau_backlight.o
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 82dab51d8aeb..36cc80eb0e20 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -261,6 +261,13 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
if (!drm->channel)
return nouveau_abi16_put(abi16, -ENODEV);
+ /* If uvmm wasn't initialized until now disable it completely to prevent
+* userspace from mixing up UAPIs.
+*
+* The client lock is already acquired by nouveau_abi16_get().
+*/
+ __nouveau_cli_uvmm_disable(cli);
+
device = >device;
engine = NV_DEVICE_HOST_RUNLIST_ENGINES_GR;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4cdeda7fe2df..03bbee291fc9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -199,7 +199,7 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, int *align,
u64 *size)
struct nouveau_bo *
nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 domain,
-u32 tile_mode, u32 tile_flags)
+u32 tile_mode, u32 tile_flags, bool internal)
{
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
@@ -235,68 +235,103 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
nvbo->force_coherent = true;
}
- if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
- nvbo->kind = (tile_flags & 0xff00) >> 8;
- if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
- kfree(nvbo);
- return ERR_PTR(-EINVAL);
+ nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
+ if (!nouveau_cli_uvmm(cli) || internal) {
+ /* for BO noVM allocs, don't assign kinds */
+ if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
+ nvbo->kind = (tile_flags & 0xff00) >> 8;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
+ }
+
+ nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
+ } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
+ nvbo->kind = (tile_flags & 0x7f00) >> 8;
+ nvbo->comp = (tile_flags & 0x0003) >> 16;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
+ }
+ } else {
+ nvbo->zeta = (tile_flags & 0x0007);
}
+ nvbo->mode = tile_mode;
+
+ /* Determine the desirable target GPU page size for the buffer.
*/
+ for (i = 0; i < vmm->page_nr; i++) {
+ /* Because we cannot currently allow VMM maps to fail
+* during buffer migration, we need to determine page
+* size for the buffer up-front, and pre-allocate its
+* page tables.
+*
+* Skip page sizes that can't support needed domains.
+
[PATCH drm-next 10/14] drm/nouveau: chan: provide nouveau_channel_kill()
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.
If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that the device is dead on the next EXEC or VM_BIND ioctl.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 14 +++---
drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 1068abe41024..6f47e997d9cf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -40,6 +40,14 @@ MODULE_PARM_DESC(vram_pushbuf, "Create DMA push buffers in
VRAM");
int nouveau_vram_pushbuf;
module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, 0400);
+void
+nouveau_channel_kill(struct nouveau_channel *chan)
+{
+ atomic_set(>killed, 1);
+ if (chan->fence)
+ nouveau_fence_context_kill(chan->fence, -ENODEV);
+}
+
static int
nouveau_channel_killed(struct nvif_event *event, void *repv, u32 repc)
{
@@ -47,9 +55,9 @@ nouveau_channel_killed(struct nvif_event *event, void *repv,
u32 repc)
struct nouveau_cli *cli = (void *)chan->user.client;
NV_PRINTK(warn, cli, "channel %d killed!\n", chan->chid);
- atomic_set(>killed, 1);
- if (chan->fence)
- nouveau_fence_context_kill(chan->fence, -ENODEV);
+
+ if (unlikely(!atomic_read(>killed)))
+ nouveau_channel_kill(chan);
return NVIF_EVENT_DROP;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
b/drivers/gpu/drm/nouveau/nouveau_chan.h
index e06a8ffed31a..e483f4a254da 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.h
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
@@ -65,6 +65,7 @@ int nouveau_channel_new(struct nouveau_drm *, struct
nvif_device *, bool priv,
u32 vram, u32 gart, struct nouveau_channel **);
void nouveau_channel_del(struct nouveau_channel **);
int nouveau_channel_idle(struct nouveau_channel *);
+void nouveau_channel_kill(struct nouveau_channel *);
extern int nouveau_vram_pushbuf;
--
2.39.0
[PATCH drm-next 07/14] drm/nouveau: bo: initialize GEM GPU VA interface
Initialize the GEM's DRM GPU VA manager interface in preparation for the (u)vmm implementation, provided by subsequent commits, to make use of it. Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index d2b32a47e480..4cdeda7fe2df 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -215,11 +215,14 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 domain, nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL); if (!nvbo) return ERR_PTR(-ENOMEM); + INIT_LIST_HEAD(>head); INIT_LIST_HEAD(>entry); INIT_LIST_HEAD(>vma_list); nvbo->bo.bdev = >ttm.bdev; + drm_gem_gpuva_init(>bo.base); + /* This is confusing, and doesn't actually mean we want an uncached * mapping, but is what NOUVEAU_GEM_DOMAIN_COHERENT gets translated * into in nouveau_gem_new(). -- 2.39.0
[PATCH drm-next 11/14] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.
This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the address space and the corresponding map/unmap/sparse
operations to the upper layers.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 23 ++-
drivers/gpu/drm/nouveau/include/nvif/vmm.h| 17 +-
.../gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 10 ++
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_vmm.c | 4 +-
drivers/gpu/drm/nouveau/nvif/vmm.c| 73 +++-
.../gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c| 168 +-
.../gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.h| 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 32 +++-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 +
10 files changed, 319 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index 9c7ff56831c5..d30e32fb8628 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -3,7 +3,10 @@
struct nvif_vmm_v0 {
__u8 version;
__u8 page_nr;
- __u8 managed;
+#define NVIF_VMM_V0_TYPE_UNMANAGED 0x00
+#define NVIF_VMM_V0_TYPE_MANAGED 0x01
+#define NVIF_VMM_V0_TYPE_RAW 0x02
+ __u8 type;
__u8 pad03[5];
__u64 addr;
__u64 size;
@@ -17,6 +20,7 @@ struct nvif_vmm_v0 {
#define NVIF_VMM_V0_UNMAP 0x04
#define NVIF_VMM_V0_PFNMAP 0x05
#define NVIF_VMM_V0_PFNCLR 0x06
+#define NVIF_VMM_V0_RAW0x07
#define NVIF_VMM_V0_MTHD(i) ((i) +
0x80)
struct nvif_vmm_page_v0 {
@@ -66,6 +70,23 @@ struct nvif_vmm_unmap_v0 {
__u64 addr;
};
+struct nvif_vmm_raw_v0 {
+ __u8 version;
+#define NVIF_VMM_RAW_V0_MAP0x0
+#define NVIF_VMM_RAW_V0_UNMAP 0x1
+#define NVIF_VMM_RAW_V0_SPARSE 0x2
+ __u8 op;
+ __u8 sparse;
+ __u8 ref;
+ __u8 pad04[4];
+ __u64 addr;
+ __u64 size;
+ __u64 offset;
+ __u64 memory;
+ __u64 handle;
+ __u8 data[];
+};
+
struct nvif_vmm_pfnmap_v0 {
__u8 version;
__u8 page;
diff --git a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
index a2ee92201ace..4d0781740336 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
@@ -4,6 +4,12 @@
struct nvif_mem;
struct nvif_mmu;
+enum nvif_vmm_type {
+ UNMANAGED,
+ MANAGED,
+ RAW,
+};
+
enum nvif_vmm_get {
ADDR,
PTES,
@@ -30,8 +36,9 @@ struct nvif_vmm {
int page_nr;
};
-int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass, bool
managed,
- u64 addr, u64 size, void *argv, u32 argc, struct nvif_vmm *);
+int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass,
+ enum nvif_vmm_type, u64 addr, u64 size, void *argv, u32 argc,
+ struct nvif_vmm *);
void nvif_vmm_dtor(struct nvif_vmm *);
int nvif_vmm_get(struct nvif_vmm *, enum nvif_vmm_get, bool sparse,
u8 page, u8 align, u64 size, struct nvif_vma *);
@@ -39,4 +46,10 @@ void nvif_vmm_put(struct nvif_vmm *, struct nvif_vma *);
int nvif_vmm_map(struct nvif_vmm *, u64 addr, u64 size, void *argv, u32 argc,
struct nvif_mem *, u64 offset);
int nvif_vmm_unmap(struct nvif_vmm *, u64);
+int nvif_vmm_raw_unmap(struct nvif_vmm *vmm, u64 handle, bool sparse);
+int nvif_vmm_raw_map(struct nvif_vmm *vmm, u64 addr, u64 size,
+void *argv, u32 argc,
+struct nvif_mem *mem, u64 offset,
+u64 *handle);
+int nvif_vmm_raw_sparse(struct nvif_vmm *vmm, u64 addr, u64 size, bool ref);
#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
index 70e7887ef4b4..ec284c1792b3 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
@@ -31,6 +31,16 @@ struct nvkm_vmm {
u64 start;
u64 limit;
+ struct {
+ struct {
+ u64 addr;
+ u64 size;
+ } p;
+ struct {
+ u64 addr;
+ u64 size;
+ } n;
+ } managed;
struct nvkm_vmm_pt *pd;
[PATCH drm-next 09/14] drm/nouveau: fence: fail to emit when fence context is killed
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.
If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job would hang forever.
To fix that, fail to emit a new fence on a killed fence context with
-ENODEV to unblock the job.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 7 +++
drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index ee5e9d40c166..62c70d9a32e6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -96,6 +96,7 @@ nouveau_fence_context_kill(struct nouveau_fence_chan *fctx,
int error)
if (nouveau_fence_signal(fence))
nvif_event_block(>event);
}
+ fctx->killed = 1;
spin_unlock_irqrestore(>lock, flags);
}
@@ -226,6 +227,12 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct
nouveau_channel *chan)
dma_fence_get(>base);
spin_lock_irq(>lock);
+ if (unlikely(fctx->killed)) {
+ spin_unlock_irq(>lock);
+ dma_fence_put(>base);
+ return -ENODEV;
+ }
+
if (nouveau_fence_update(chan, fctx))
nvif_event_block(>event);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 0ca2bc85adf6..00a08699bb58 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -45,7 +45,7 @@ struct nouveau_fence_chan {
char name[32];
struct nvif_event event;
- int notify_ref, dead;
+ int notify_ref, dead, killed;
};
struct nouveau_fence_priv {
--
2.39.0
[PATCH drm-next 08/14] drm/nouveau: move usercopy helpers to nouveau_drv.h
Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 26 --
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 81350e685b50..20a7f31b9082 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -130,6 +130,32 @@ nouveau_cli(struct drm_file *fpriv)
return fpriv ? fpriv->driver_priv : NULL;
}
+static inline void
+u_free(void *addr)
+{
+ kvfree(addr);
+}
+
+static inline void *
+u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
+{
+ void *mem;
+ void __user *userptr = (void __force __user *)(uintptr_t)user;
+
+ size *= nmemb;
+
+ mem = kvmalloc(size, GFP_KERNEL);
+ if (!mem)
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(mem, userptr, size)) {
+ u_free(mem);
+ return ERR_PTR(-EFAULT);
+ }
+
+ return mem;
+}
+
#include
#include
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 48e6ba00ec27..5dad2d0dd5cb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -613,32 +613,6 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
return 0;
}
-static inline void
-u_free(void *addr)
-{
- kvfree(addr);
-}
-
-static inline void *
-u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
-{
- void *mem;
- void __user *userptr = (void __force __user *)(uintptr_t)user;
-
- size *= nmemb;
-
- mem = kvmalloc(size, GFP_KERNEL);
- if (!mem)
- return ERR_PTR(-ENOMEM);
-
- if (copy_from_user(mem, userptr, size)) {
- u_free(mem);
- return ERR_PTR(-EFAULT);
- }
-
- return mem;
-}
-
static int
nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf *req,
--
2.39.0
[PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
VA area.
2) Bind and unbind GPU VA space mappings via the new
DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.
Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
asynchronous processing with DRM syncobjs as synchronization mechanism.
The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.
Co-authored-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/driver-uapi.rst | 8 ++
include/uapi/drm/nouveau_drm.h| 216 ++
2 files changed, 224 insertions(+)
diff --git a/Documentation/gpu/driver-uapi.rst
b/Documentation/gpu/driver-uapi.rst
index 4411e6919a3d..9c7ca6e33a68 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,11 @@ drm/i915 uAPI
=
.. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+
+
+VM_BIND / EXEC uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 853a327433d3..f6e7d40201d4 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -126,6 +126,216 @@ struct drm_nouveau_gem_cpu_fini {
__u32 handle;
};
+/**
+ * struct drm_nouveau_sync - sync object
+ *
+ * This structure serves as synchronization mechanism for (potentially)
+ * asynchronous operations such as EXEC or VM_BIND.
+ */
+struct drm_nouveau_sync {
+ /**
+* @flags: the flags for a sync object
+*
+* The first 8 bits are used to determine the type of the sync object.
+*/
+ __u32 flags;
+#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
+#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
+#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
+ /**
+* @handle: the handle of the sync object
+*/
+ __u32 handle;
+ /**
+* @timeline_value:
+*
+* The timeline point of the sync object in case the syncobj is of
+* type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
+*/
+ __u64 timeline_value;
+};
+
+/**
+ * struct drm_nouveau_vm_init - GPU VA space init structure
+ *
+ * Used to initialize the GPU's VA space for a user client, telling the kernel
+ * which portion of the VA space is managed by the UMD and kernel respectively.
+ */
+struct drm_nouveau_vm_init {
+ /**
+* @unmanaged_addr: start address of the kernel managed VA space region
+*/
+ __u64 unmanaged_addr;
+ /**
+* @unmanaged_size: size of the kernel managed VA space region in bytes
+*/
+ __u64 unmanaged_size;
+};
+
+/**
+ * struct drm_nouveau_vm_bind_op - VM_BIND operation
+ *
+ * This structure represents a single VM_BIND operation. UMDs should pass
+ * an array of this structure via struct drm_nouveau_vm_bind's _ptr field.
+ */
+struct drm_nouveau_vm_bind_op {
+ /**
+* @op: the operation type
+*/
+ __u32 op;
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_ALLOC:
+ *
+ * The alloc operation is used to reserve a VA space region within the GPU's VA
+ * space. Optionally, the _NOUVEAU_VM_BIND_SPARSE flag can be passed to
+ * instruct the kernel to create sparse mappings for the given region.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_ALLOC 0x0
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_FREE: Free a reserved VA space region.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_FREE 0x1
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_MAP:
+ *
+ * Map a GEM object to the GPU's VA space. The mapping must be fully enclosed
by
+ * a previously allocated VA space region. If the region is sparse, existing
+ * sparse mappings are overwritten.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_MAP 0x2
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_UNMAP:
+ *
+ * Unmap an existing mapping in the GPU's VA space. If the region the mapping
+ * is located in is a sparse region, new sparse mappings are created where the
+ * unmapped (memory backed) mapping was mapped previously.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_UNMAP 0x3
+ /**
+* @flags: the flags for a _nouveau_vm_bind_op
+*/
+ __u32 flags;
+/**
+ * @DRM_NOUVEAU_VM_BIND_SPARSE:
+ *
+ * Indicates that an allocated VA space region should be sparse.
+ */
+#define DRM_NOUVEAU_VM_BIND_SPARSE (1 << 8)
+ /**
+* @handle: the handle of the DRM GEM object to map
+*/
+ __u32 handle;
+ /**
+* @addr:
+*
+* the address the VA space region or (memory backed) mapping should be
mapped to
+*/
+ __u64 addr;
+ /**
+* @bo_offset: the offset within the BO backing the mapping
+*/
+ __u64 bo_offset;
+
[PATCH drm-next 06/14] drm/nouveau: get vmm via nouveau_cli_vmm()
Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +++---
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 335fa91ca4ad..d2b32a47e480 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -204,7 +204,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
struct nvif_mmu *mmu = >mmu;
- struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
+ struct nvif_vmm *vmm = _cli_vmm(cli)->vmm;
int i, pi = -1;
if (!*size) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e648ecd0c1a0..1068abe41024 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -148,7 +148,7 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct
nvif_device *device,
chan->device = device;
chan->drm = drm;
- chan->vmm = cli->svm.cli ? >svm : >vmm;
+ chan->vmm = nouveau_cli_vmm(cli);
atomic_set(>killed, 0);
/* allocate memory for dma push buffer */
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index b5de312a523f..81350e685b50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -112,6 +112,15 @@ struct nouveau_cli_work {
struct dma_fence_cb cb;
};
+static inline struct nouveau_vmm *
+nouveau_cli_vmm(struct nouveau_cli *cli)
+{
+ if (cli->svm.cli)
+ return >svm;
+
+ return >vmm;
+}
+
void nouveau_cli_work_queue(struct nouveau_cli *, struct dma_fence *,
struct nouveau_cli_work *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index ac5793c96957..48e6ba00ec27 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -103,7 +103,7 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : >vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
@@ -180,7 +180,7 @@ nouveau_gem_object_close(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : & cli->vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
@@ -269,7 +269,7 @@ nouveau_gem_info(struct drm_file *file_priv, struct
drm_gem_object *gem,
{
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : >vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
if (is_power_of_2(nvbo->valid_domains))
--
2.39.0
[PATCH drm-next 04/14] drm: debugfs: provide infrastructure to dump a DRM GPU VA space
This commit adds a function to dump a DRM GPU VA space and a macro for
drivers to register the struct drm_info_list 'gpuvas' entry.
Most likely, most drivers might maintain one DRM GPU VA space per struct
drm_file, but there might also be drivers not having a fixed relation
between DRM GPU VA spaces and a DRM core infrastructure, hence we need the
indirection via the driver iterating it's maintained DRM GPU VA spaces.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_debugfs.c | 56 +++
include/drm/drm_debugfs.h | 25
2 files changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4f643a490dc3..5389dd73c0fb 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -175,6 +176,61 @@ static const struct file_operations drm_debugfs_fops = {
.release = single_release,
};
+/**
+ * drm_debugfs_gpuva_info - dump the given DRM GPU VA space
+ * @m: pointer to the _file to write
+ * @mgr: the _gpuva_manager representing the GPU VA space
+ *
+ * Dumps the GPU VA regions and mappings of a given DRM GPU VA manager.
+ *
+ * For each DRM GPU VA space drivers should call this function from their
+ * _info_list's show callback.
+ *
+ * Returns: 0 on success, -ENODEV if the is not initialized
+ */
+int drm_debugfs_gpuva_info(struct seq_file *m,
+ struct drm_gpuva_manager *mgr)
+{
+ struct drm_gpuva_region *reg;
+ struct drm_gpuva *va;
+
+ if (!mgr->name)
+ return -ENODEV;
+
+ seq_printf(m, "DRM GPU VA space (%s)\n", mgr->name);
+ seq_puts (m, "\n");
+ seq_puts (m, " VA regions | start | range |
end| sparse\n");
+ seq_puts (m,
"\n");
+ seq_printf(m, " VA space| 0x%016llx | 0x%016llx | 0x%016llx |
-\n",
+ mgr->mm_start, mgr->mm_range, mgr->mm_start + mgr->mm_range);
+ seq_puts (m,
"---\n");
+ drm_gpuva_for_each_region(reg, mgr) {
+ struct drm_mm_node *node = >node;
+
+ if (node == >kernel_alloc_node) {
+ seq_printf(m, " kernel node | 0x%016llx | 0x%016llx |
0x%016llx | -\n",
+ node->start, node->size, node->start +
node->size);
+ continue;
+ }
+
+ seq_printf(m, " | 0x%016llx | 0x%016llx | 0x%016llx
| %s\n",
+ node->start, node->size, node->start + node->size,
+ reg->sparse ? "true" : "false");
+ }
+ seq_puts(m, "\n");
+ seq_puts(m, " VAs | start | range | end
| object | object offset\n");
+ seq_puts(m,
"-\n");
+ drm_gpuva_for_each_va(va, mgr) {
+ struct drm_mm_node *node = >node;
+
+ seq_printf(m, " | 0x%016llx | 0x%016llx | 0x%016llx |
0x%016llx | 0x%016llx\n",
+ node->start, node->size, node->start + node->size,
+ (u64)va->gem.obj, va->gem.offset);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_debugfs_gpuva_info);
/**
* drm_debugfs_create_files - Initialize a given set of debugfs files for DRM
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7616f457ce70..cb2c1956a214 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -34,6 +34,22 @@
#include
#include
+
+#include
+
+/**
+ * DRM_DEBUGFS_GPUVA_INFO - _info_list entry to dump a GPU VA space
+ * @show: the _info_list's show callback
+ * @data: driver private data
+ *
+ * Drivers should use this macro to define a _info_list entry to provide a
+ * debugfs file for dumping the GPU VA space regions and mappings.
+ *
+ * For each DRM GPU VA space drivers should call drm_debugfs_gpuva_info() from
+ * their @show callback.
+ */
+#define DRM_DEBUGFS_GPUVA_INFO(show, data) {"gpuvas", show, DRIVER_GEM_GPUVA,
data}
+
/**
* struct drm_info_list - debugfs info list entry
*
@@ -134,6 +150,9 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
void drm_debugfs_add_files(struct drm_device *dev,
const struct drm_debugfs_info *files, int count);
+
+int drm_debugfs_gpuva_info(struct seq_file *m,
+ struct drm_gpuva_manager *mgr);
#else
static inline void drm_debugfs_create_files(const struct drm_info_list *files,
int count, struct dentry
[PATCH drm-next 03/14] drm: manager to keep track of GPUs VA mappings
This adds the infrastructure for a manager implementation to keep track of GPU virtual address (VA) mappings. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide a dedicated range allocator to track GPU VA allocations and mappings, making use of the drm_mm range allocator. 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Idea-suggested-by: Dave Airlie Signed-off-by: Danilo Krummrich --- Documentation/gpu/drm-mm.rst| 31 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/drm_gem.c |3 + drivers/gpu/drm/drm_gpuva_mgr.c | 1323 +++ include/drm/drm_drv.h |6 + include/drm/drm_gem.h | 75 ++ include/drm/drm_gpuva_mgr.h | 527 7 files changed, 1966 insertions(+) create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c create mode 100644 include/drm/drm_gpuva_mgr.h diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index a52e6f4117d6..c9f120cfe730 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -466,6 +466,37 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: +DRM GPU VA Manager +== + +Overview + + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Overview + +Split and Merge +--- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Split and Merge + +Locking +--- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Locking + + +DRM GPU VA Manager Function References +-- + +.. kernel-doc:: include/drm/drm_gpuva_mgr.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :export: + DRM Buddy Allocator === diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4fe190aee584..de2ffca3b6e4 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -45,6 +45,7 @@ drm-y := \ drm_vblank.o \ drm_vblank_work.o \ drm_vma_manager.o \ + drm_gpuva_mgr.o \ drm_writeback.o drm-$(CONFIG_DRM_LEGACY) += \ drm_agpsupport.o \ diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 59a0bb5ebd85..65115fe88627 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -164,6 +164,9 @@ void drm_gem_private_object_init(struct drm_device *dev, if (!obj->resv) obj->resv = >_resv; + if (drm_core_check_feature(dev, DRIVER_GEM_GPUVA)) + drm_gem_gpuva_init(obj); + drm_vma_node_reset(>vma_node); INIT_LIST_HEAD(>lru_node); } diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c new file mode 100644 index ..e665f642689d --- /dev/null +++ b/drivers/gpu/drm/drm_gpuva_mgr.c @@ -0,0 +1,1323 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2022 Red Hat. + * + * 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. + * + * Authors: + * Danilo Krummrich + * + */ + +#include +#include + +/** + * DOC: Overview + * + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager keeps track + * of a GPU's virtual address (VA) space and manages the corresponding virtual + * mappings represented by _gpuva objects. It also keeps track of the + * mapping's backing _gem_object buffers. + * + * _gem_object buffers maintain a list (and a corresponding list lock) of + * _gpuva
[PATCH drm-next 02/14] drm/exec: fix memory leak in drm_exec_prepare_obj()
Don't call drm_gem_object_get() unconditionally. Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/drm_exec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c index ed2106c22786..5713a589a6a3 100644 --- a/drivers/gpu/drm/drm_exec.c +++ b/drivers/gpu/drm/drm_exec.c @@ -282,7 +282,6 @@ int drm_exec_prepare_obj(struct drm_exec *exec, struct drm_gem_object *obj, goto error_unlock; } - drm_gem_object_get(obj); return 0; error_unlock: -- 2.39.0
[PATCH drm-next 01/14] drm: execution context for GEM buffers
From: Christian König
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with automated deadlock and duplicate handling.
v2: drop xarray and use dynamic resized array instead, the locking
overhead is unecessary and measureable.
Signed-off-by: Christian König
---
Documentation/gpu/drm-mm.rst | 12 ++
drivers/gpu/drm/Kconfig| 6 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/amd/amdgpu/Kconfig | 1 +
drivers/gpu/drm/drm_exec.c | 295 +
include/drm/drm_exec.h | 144 ++
6 files changed, 460 insertions(+)
create mode 100644 drivers/gpu/drm/drm_exec.c
create mode 100644 include/drm/drm_exec.h
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a79fd3549ff8..a52e6f4117d6 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -493,6 +493,18 @@ DRM Sync Objects
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:export:
+DRM Execution context
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :doc: Overview
+
+.. kernel-doc:: include/drm/drm_exec.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :export:
+
GPU Scheduler
=
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 748b93d00184..05134256da59 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -200,6 +200,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_EXEC
+ tristate
+ depends on DRM
+ help
+ Execution context for command submissions
+
config DRM_BUDDY
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 496fa5a6147a..4fe190aee584 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) +=
drm_panel_orientation_quirks.o
#
# Memory-management helpers
#
+#
+obj-$(CONFIG_DRM_EXEC) += drm_exec.o
obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index 5341b6b242c3..279fb3bba810 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -11,6 +11,7 @@ config DRM_AMDGPU
select DRM_SCHED
select DRM_TTM
select DRM_TTM_HELPER
+ select DRM_EXEC
select POWER_SUPPLY
select HWMON
select I2C
diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
new file mode 100644
index ..ed2106c22786
--- /dev/null
+++ b/drivers/gpu/drm/drm_exec.c
@@ -0,0 +1,295 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+
+#include
+#include
+#include
+
+/**
+ * DOC: Overview
+ *
+ * This component mainly abstracts the retry loop necessary for locking
+ * multiple GEM objects while preparing hardware operations (e.g. command
+ * submissions, page table updates etc..).
+ *
+ * If a contention is detected while locking a GEM object the cleanup procedure
+ * unlocks all previously locked GEM objects and locks the contended one first
+ * before locking any further objects.
+ *
+ * After an object is locked fences slots can optionally be reserved on the
+ * dma_resv object inside the GEM object.
+ *
+ * A typical usage pattern should look like this::
+ *
+ * struct drm_gem_object *obj;
+ * struct drm_exec exec;
+ * unsigned long index;
+ * int ret;
+ *
+ * drm_exec_init(, true);
+ * drm_exec_while_not_all_locked() {
+ * ret = drm_exec_prepare_obj(, boA, 1);
+ * drm_exec_continue_on_contention();
+ * if (ret)
+ * goto error;
+ *
+ * ret = drm_exec_lock(, boB, 1);
+ * drm_exec_continue_on_contention();
+ * if (ret)
+ * goto error;
+ * }
+ *
+ * drm_exec_for_each_locked_object(, index, obj) {
+ * dma_resv_add_fence(obj->resv, fence, DMA_RESV_USAGE_READ);
+ * ...
+ * }
+ * drm_exec_fini();
+ *
+ * See struct dma_exec for more details.
+ */
+
+/* Dummy value used to initially enter the retry loop */
+#define DRM_EXEC_DUMMY (void*)~0
+
+/* Initialize the drm_exec_objects container */
+static void drm_exec_objects_init(struct drm_exec_objects *container)
+{
+ container->objects = kmalloc(PAGE_SIZE, GFP_KERNEL);
+
+ /* If allocation here fails, just delay that till the first use */
+ container->max_objects = container->objects ?
+ PAGE_SIZE / sizeof(void *) : 0;
+ container->num_objects = 0;
+}
+
+/* Cleanup the drm_exec_objects container */
+static void drm_exec_objects_fini(struct drm_exec_objects
[PATCH drm-next 00/14] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI
This patch series provides a new UAPI for the Nouveau driver in order to support Vulkan features, such as sparse bindings and sparse residency. Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to keep track of GPU virtual address (VA) mappings in a more generic way. The DRM GPUVA manager is indented to help drivers implement userspace-manageable GPU VA spaces in reference to the Vulkan API. In order to achieve this goal it serves the following purposes in this context. 1) Provide a dedicated range allocator to track GPU VA allocations and mappings, making use of the drm_mm range allocator. 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager, itself providing the following new interfaces. 1) Initialize a GPU VA space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA space managed by the kernel and userspace, respectively. 2) Allocate and free a VA space region as well as bind and unbind memory to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, make use of the DRM scheduler to queue jobs and support asynchronous processing with DRM syncobjs as synchronization mechanism. By default DRM_IOCTL_NOUVEAU_VM_BIND does synchronous processing, DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only. The new VM_BIND UAPI for Nouveau makes also use of drm_exec (execution context for GEM buffers) by Christian König. Since the patch implementing drm_exec was not yet merged into drm-next it is part of this series, as well as a small fix for this patch, which was found while testing this series. This patch series is also available at [1]. There is a Mesa NVK merge request by Dave Airlie [2] implementing the corresponding userspace parts for this series. The Vulkan CTS test suite passes the sparse binding and sparse residency test cases for the new UAPI together with Dave's Mesa work. There are also some test cases in the igt-gpu-tools project [3] for the new UAPI and hence the DRM GPU VA manager. However, most of them are testing the DRM GPU VA manager's logic through Nouveau's new UAPI and should be considered just as helper for implementation. However, I absolutely intend to change those test cases to proper kunit test cases for the DRM GPUVA manager, once and if we agree on it's usefulness and design. [1] https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next / https://gitlab.freedesktop.org/nouvelles/kernel/-/merge_requests/1 [2] https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/150/ [3] https://gitlab.freedesktop.org/dakr/igt-gpu-tools/-/tree/wip_nouveau_vm_bind I also want to give credit to Dave Airlie, who contributed a lot of ideas to this patch series. Christian König (1): drm: execution context for GEM buffers Danilo Krummrich (13): drm/exec: fix memory leak in drm_exec_prepare_obj() drm: manager to keep track of GPUs VA mappings drm: debugfs: provide infrastructure to dump a DRM GPU VA space drm/nouveau: new VM_BIND uapi interfaces drm/nouveau: get vmm via nouveau_cli_vmm() drm/nouveau: bo: initialize GEM GPU VA interface drm/nouveau: move usercopy helpers to nouveau_drv.h drm/nouveau: fence: fail to emit when fence context is killed drm/nouveau: chan: provide nouveau_channel_kill() drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm drm/nouveau: implement uvmm for user mode bindings drm/nouveau: implement new VM_BIND UAPI drm/nouveau: debugfs: implement DRM GPU VA debugfs Documentation/gpu/driver-uapi.rst | 11 + Documentation/gpu/drm-mm.rst | 43 + drivers/gpu/drm/Kconfig |6 + drivers/gpu/drm/Makefile |3 + drivers/gpu/drm/amd/amdgpu/Kconfig|1 + drivers/gpu/drm/drm_debugfs.c | 56 + drivers/gpu/drm/drm_exec.c| 294 drivers/gpu/drm/drm_gem.c |3 + drivers/gpu/drm/drm_gpuva_mgr.c | 1323 + drivers/gpu/drm/nouveau/Kbuild|3 + drivers/gpu/drm/nouveau/Kconfig |2 + drivers/gpu/drm/nouveau/include/nvif/if000c.h | 23 +- drivers/gpu/drm/nouveau/include/nvif/vmm.h| 17 +- .../gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 10 + drivers/gpu/drm/nouveau/nouveau_abi16.c | 23 + drivers/gpu/drm/nouveau/nouveau_abi16.h |1 + drivers/gpu/drm/nouveau/nouveau_bo.c |
Re: remove arch/sh
On 1/17/23 14:26, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Jan 17, 2023 at 8:01 PM Rob Landley wrote: >> On 1/16/23 01:13, Christoph Hellwig wrote: >> > On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote: >> >> I'm still maintaining and using this port in Debian. >> >> >> >> It's a bit disappointing that people keep hammering on it. It works fine >> >> for me. >> > >> > What platforms do you (or your users) use it on? >> >> 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), >> and an >> sh4 emulator. >> >> I have multiple j-core systems (sh2 compatible with extensions, nommu, 3 >> different kinds of boards running it here). There's an existing mmu version >> of >> j-core that's sh3 flavored but they want to redo it so it hasn't been >> publicly >> released yet, I have yet to get that to run Linux because the mmu code would >> need adapting, but the most recent customer projects were on the existing >> nommu >> SOC, as was last year's ASIC work via sky130. > > J4 still vaporware? The 'existing mmu version' is the theoretical basis for J4 (the move from J3 to J4 is tiny from an instruction set perspective, it was more about internal chip architecture, primarily multi-issue with tomasulo). It exists, but we haven't had a product that uses it and the engineer who was tasked to work on it got reassigned during the pandemic. The real problem is the existing implementation is a branch off of an older SOC version so repotting it to the current tree (which among other things builds under a different VHDL toolchain) is some work. The "conflict requiring actual staring at" isn't the MMU, it's the instruction cancellation logic that backs out half-finished instructions when the MMU complains partway through an instruction that's multiple steps of microcode, so we have to back _out_ what it's already done so it can be cleanly restarted after handling the fault. That's got merge conflicts all over the place with the current stuff... Not actually _hard_, but not something we've sat down and done. We spent those cycles last year working on an ASIC implementation through Google's Sky130 OpenLane/OpenRoad stuff (see https://github.com/j-core/openlane-vhdl-build for our in-house toolchain build for that; Google passes around a magic docker that most people use, we trimmed off most of the dependencies and build it in a clean debootstrap). And that was trying to make an ASIC out of the small simple version, because Google's entire asic/skywater partnership was... fraught? We also tried to get the previous generation of ASIC tools to work before giving up and trying to get what Google was working on to work: https://landley.net/notes-2022.html#26-01-2022 https://landley.net/notes-2022.html#28-01-2022 We targeted "known working SOC that we've been using a long time" to try to make a physical silicon chip out of (and the first version isn't even the J2 2xSMP SOC with all the cache and peripherals, it was a derivative of the ICE40 port that's single processor running straight from SRAM with no DRAM controller), on the theory we can always do a more complicated one later an what we were really trying to establish here is that Google's ASIC development tools and process could be made to work. (Which is kind of a heavy lift, they burned two shuttles full of mostly dead chips that we know of before admitting "those timing annotations we were talking about actually DO need to go all the way through"... Jeff has the URLs to the bug reports in OpenLane/Road's github...) (Sorry, one of OpenLane/OpenRoad is the DARPA project out of Sandia National Laboratory, and the other is Google doing a large extremely complicated thing analogous to the AOSP build on top of Darpa's work using a lot different programming languages and FOREST of build and runtime package dependencies, and I can never remember which is which. The Google thing is the one distributed in a docker because it's considered impossible to build rom source by everybody except us, because we're funny that way. And added VHDL support instead of just Verilog so needed to rebuild from source anyway to do that.) >> My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the >> little blue one is... sh4a I think? (It can run the same userspace, I haven't >> replaced that board's kernel since I got it, I think it's the type Glaubitz >> is >> using? It's mostly in case he had an issue I couldn't reproduce on different >> hardware, or if I spill something on my N40.) >> >> I also have a physical sh2 board on the shelf which I haven't touched in >> years >> (used to comparison test during j2 development, and then the j2 boards >> replaced it). >> >> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's >> really convenient: neither of my physical boards boot from SD card so >> replacing >> the kernel requires reflashing soldered in flash. (They'll net mount >> userspace >>
Re: [PATCH] drm/panel: boe-tv101wum-nl6: Ensure DSI writes succeed during disable
Quoting Dave Stevenson (2023-01-16 06:11:02) > Hi Stephen > > On Fri, 13 Jan 2023 at 21:12, Stephen Boyd wrote: > > > > > > Thanks for the info! It says "Drivers that need the underlying device to > > be powered to perform these operations will first need to make sure it’s > > been properly enabled." Does that mean the panel driver needs to make > > sure the underlying dsi host device is powered? The sentence is too > > ambiguous for me to understand what 'drivers' and 'underlying device' > > are. > > The DSI host driver (ie in your case something under > drivers/gpu/drm/msm/dsi) should ensure that a transfer can be made, > regardless of state. > > I must say that this has been documented as the case, but doesn't > necessarily reflect reality in a number of drivers. Alright, thanks for the clarification. > > > > Cool. Glad that we can clean that up with your series. > > > > Is it wrong to split unprepare to a disable and unprepare phase? I'm not > > super keen on fixing 6.1 stable kernels by opting this driver into the > > ordering change. Splitting the phase into two is small and simple and > > works. I suspect changing the ordering may uncover more bugs, or be a > > larger task. I'd be glad to test that series[2] from you to get rid of > > [3]. > > Ah, I hadn't realised it was a regression in a released kernel :( > > Splitting into a disable and unprepare is totally fine. Normally > disable would normally disable the panel and backlight (probably by > drm_panel before the panel disable call), with unprepare disabling > power and clocks > > Do note that AIUI you will be telling the panel to enter sleep mode > whilst video is still being transmitted. That should be safe as the > panel has to still be partially active to handle an exit sleep mode > command, but actually powering hardware down at that point could cause > DSI bus arbitration errors as clock or data lanes could be pulled down > when the host is trying to adopt HS or LP11. > Ok. I don't think I'm running into that issue, but I have run into a different issue. I tried to split the prepare phase into enable and prepare with the DSI writes in the enable to make things symmetric but that totally failed. Now I get lots of timeouts when enabling the panel. This patch is still the best fix I have. Maybe with your series we can combine the unprepare and disable ops together again (i.e. revert this) so that power is removed immediately after sending the DSI commands? Or is that not enough to avoid the DSI bus arbitration problems you're talking about? When is the host adopting HS or LP11 with regards to the bridge ops?
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
On Tue, Jan 17, 2023 at 02:29:37PM -0500, Rodrigo Vivi wrote:
> On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> > On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> > > On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > > function adds the overhead of introducing a proxy file operation
> > > > functions to wrap the original read/write inside file removal protection
> > > > functions. This adds significant overhead in terms of introducing and
> > > > managing the proxy factory file operations structure and function
> > > > wrapping at runtime.
> > > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > > > with debugfs_create_file_unsafe() is suggested to be used instead. The
> > > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > > debugfs_file_put() wrappers to protect the original read and write
> > > > function calls for the debug attributes. There is no need for any
> > > > runtime proxy file operations to be managed by the debugfs core.
> > > > Following coccicheck make command helped identify this change:
> > > >
> > > > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
> > > > COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > >
> > > > Signed-off-by: Deepak R Varma
> > >
> > > I believe these 2 gvt cases could be done in one patch.
> > > But anyways,
> > >
> > > Reviewed-by: Rodrigo Vivi
> > >
> > > for both patches... and will leave these 2 patches for gvt folks
> > > to apply. Unless they ack and I apply in the drm-intel along with the
> > > other ones.
> > >
> >
> > yeah, they're fine with me, feel free to apply them directly.
> >
> > Acked-by: Zhenyu Wang
>
> Unfortunately I got some conflicts when trying to apply on drm-intel-next.
>
> We probably need a new version, and probably through gvt branches it
> will be easier to handle conflicts if they appear.
Hello Rodrigo,
Sure. I will send in a new version. I am current using linux-next git repo as my
remote origin [tag 20230113]. Are there any specific instruction/location from
where I should access the gvt branch?
Thank you.
>
> >
> > thanks!
> >
> > > > ---
> > > > drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > index 03f081c3d9a4..baccbf1761b7 100644
> > > > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> > > > return 0;
> > > > }
> > > >
> > > > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL,
> > > > "0x%llx\n");
> > > > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL,
> > > > "0x%llx\n");
> > > >
> > > > /**
> > > > * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> > > > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu
> > > > *vgpu)
> > > > _mmio_diff_fops);
> > > > debugfs_create_file_unsafe("scan_nonprivbb", 0644,
> > > > vgpu->debugfs, vgpu,
> > > >_scan_nonprivbb_fops);
> > > > - debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > > > - _status_fops);
> > > > + debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > > > + _status_fops);
> > > > }
> > > >
> > > > /**
> > > > --
> > > > 2.34.1
> > > >
> > > >
> > > >
>
>
Re: [PATCH] drm/i915/display: Convert i9xx_pipe_crc_auto_source to void
On Tue, Jan 17, 2023 at 02:21:59PM -0500, Rodrigo Vivi wrote:
> On Sat, Jan 14, 2023 at 07:33:53PM +0530, Deepak R Varma wrote:
> > Convert function i9xx_pipe_crc_auto_source() to return void instead
> > of int since the current implementation always returns 0 to the caller.
> > Issue identified using returnvar Coccinelle semantic patch.
>
> could you please share the coccinelle commands and files you used here?
Hello Rodrigo,
I used following command to identify this change opportunity:
make coccicheck COCCI=scripts/coccinelle/misc/returnvar.cocci M=drivers/gpu/drm/
Let me know if you would like me to include the same in the commit message.
>
> >
> > Signed-off-by: Deepak R Varma
> > ---
> > Please note: The change is compile tested only.
>
> np, our CI liked it.
>
> I liked the clean up as well:
> Reviewed-by: Rodrigo Vivi
Thank you for your review and the feedback.
Regards,
./drv
>
> >
> >
> > drivers/gpu/drm/i915/display/intel_pipe_crc.c | 23 ++-
> > 1 file changed, 7 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> > b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> > index e9774670e3f6..8d3ea8d7b737 100644
> > --- a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> > @@ -72,14 +72,13 @@ static int i8xx_pipe_crc_ctl_reg(enum
> > intel_pipe_crc_source *source,
> > return 0;
> > }
> >
> > -static int i9xx_pipe_crc_auto_source(struct drm_i915_private *dev_priv,
> > -enum pipe pipe,
> > -enum intel_pipe_crc_source *source)
> > +static void i9xx_pipe_crc_auto_source(struct drm_i915_private *dev_priv,
> > + enum pipe pipe,
> > + enum intel_pipe_crc_source *source)
> > {
> > struct intel_encoder *encoder;
> > struct intel_crtc *crtc;
> > struct intel_digital_port *dig_port;
> > - int ret = 0;
> >
> > *source = INTEL_PIPE_CRC_SOURCE_PIPE;
> >
> > @@ -121,8 +120,6 @@ static int i9xx_pipe_crc_auto_source(struct
> > drm_i915_private *dev_priv,
> > }
> > }
> > drm_modeset_unlock_all(_priv->drm);
> > -
> > - return ret;
> > }
> >
> > static int vlv_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
> > @@ -132,11 +129,8 @@ static int vlv_pipe_crc_ctl_reg(struct
> > drm_i915_private *dev_priv,
> > {
> > bool need_stable_symbols = false;
> >
> > - if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > - int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> > - if (ret)
> > - return ret;
> > - }
> > + if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
> > + i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> >
> > switch (*source) {
> > case INTEL_PIPE_CRC_SOURCE_PIPE:
> > @@ -200,11 +194,8 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > drm_i915_private *dev_priv,
> > enum intel_pipe_crc_source *source,
> > u32 *val)
> > {
> > - if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > - int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> > - if (ret)
> > - return ret;
> > - }
> > + if (*source == INTEL_PIPE_CRC_SOURCE_AUTO)
> > + i9xx_pipe_crc_auto_source(dev_priv, pipe, source);
> >
> > switch (*source) {
> > case INTEL_PIPE_CRC_SOURCE_PIPE:
> > --
> > 2.34.1
> >
> >
> >
[PATCH v7 11/11] ARM: dts: qcom: rename mdp nodes to display-controller
Follow the schema change and rename mdp nodes to generic name
'display-controller'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +-
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index e045edeb5736..95705703fe8f 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -1493,7 +1493,7 @@ hdmi_phy: phy@4a00400 {
status = "disabled";
};
- mdp: mdp@510 {
+ mdp: display-controller@510 {
compatible = "qcom,mdp4";
reg = <0x0510 0xf>;
interrupts = ;
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index ec0c526d0483..2879b29a109c 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1579,7 +1579,7 @@ mdss: display-subsystem@fd90 {
#size-cells = <1>;
ranges;
- mdp: mdp@fd90 {
+ mdp: display-controller@fd90 {
compatible = "qcom,msm8974-mdp5", "qcom,mdp5";
reg = <0xfd900100 0x22000>;
reg-names = "mdp_phys";
--
2.39.0
[PATCH v7 08/11] arm64: dts: qcom: rename mdss nodes to display-subsystem
Follow the schema change and rename mdss nodes to generic name
'display-subsystem'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 68cdf255c474..b688df272207 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -963,7 +963,7 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
- mdss: mdss@1a0 {
+ mdss: display-subsystem@1a0 {
status = "disabled";
compatible = "qcom,mdss";
reg = <0x01a0 0x1000>,
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index 068eac8dc97f..9d4b785409b1 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -670,7 +670,7 @@ tcsr_phy_clk_scheme_sel: syscon@193f044 {
reg = <0x193f044 0x4>;
};
- mdss: mdss@1a0 {
+ mdss: display-subsystem@1a0 {
compatible = "qcom,mdss";
reg = <0x1a0 0x1000>,
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index c05d2a85247e..97979f7a8050 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -908,7 +908,7 @@ mmcc: clock-controller@8c {
<82500>;
};
- mdss: mdss@90 {
+ mdss: display-subsystem@90 {
compatible = "qcom,mdss";
reg = <0x0090 0x1000>,
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 3a0bd0fb56b4..b2ea615e7df1 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2922,7 +2922,7 @@ camcc: clock-controller@ad0 {
#power-domain-cells = <1>;
};
- mdss: mdss@ae0 {
+ mdss: display-subsystem@ae0 {
compatible = "qcom,sc7180-mdss";
reg = <0 0x0ae0 0 0x1000>;
reg-names = "mdss";
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index d1542335be74..2ca2f75f2aa7 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1470,7 +1470,7 @@ opp-26250 {
};
};
- mdss: mdss@c90 {
+ mdss: display-subsystem@c90 {
compatible = "qcom,mdss";
reg = <0x0c90 0x1000>,
<0x0c9b 0x1040>;
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0f1cb2c8addd..72c5ec84d3ef 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4414,7 +4414,7 @@ clock_camcc: clock-controller@ad0 {
clock-names = "bi_tcxo";
};
- mdss: mdss@ae0 {
+ mdss: display-subsystem@ae0 {
compatible = "qcom,sdm845-mdss";
reg = <0 0x0ae0 0 0x1000>;
reg-names = "mdss";
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index a4ce9cf14d9c..dabed46f04a7 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -3970,7 +3970,7 @@ camcc: clock-controller@ad0 {
#power-domain-cells = <1>;
};
- mdss: mdss@ae0 {
+ mdss: display-subsystem@ae0 {
compatible = "qcom,sm8250-mdss";
reg = <0 0x0ae0 0 0x1000>;
reg-names = "mdss";
--
2.39.0
[PATCH v7 10/11] arm64: dts: qcom: rename mdp nodes to display-controller
Follow the schema change and rename mdp nodes to generic name
'display-controller'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index b688df272207..027eb99340e2 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -988,7 +988,7 @@ mdss: display-subsystem@1a0 {
#size-cells = <1>;
ranges;
- mdp: mdp@1a01000 {
+ mdp: display-controller@1a01000 {
compatible = "qcom,msm8916-mdp5", "qcom,mdp5";
reg = <0x01a01000 0x89000>;
reg-names = "mdp_phys";
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index 9d4b785409b1..4e17bc9f8167 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -699,7 +699,7 @@ mdss: display-subsystem@1a0 {
status = "disabled";
- mdp: mdp@1a01000 {
+ mdp: display-controller@1a01000 {
compatible = "qcom,msm8953-mdp5", "qcom,mdp5";
reg = <0x1a01000 0x89000>;
reg-names = "mdp_phys";
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 97979f7a8050..5321b217c1de 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -934,7 +934,7 @@ mdss: display-subsystem@90 {
status = "disabled";
- mdp: mdp@901000 {
+ mdp: display-controller@901000 {
compatible = "qcom,msm8996-mdp5", "qcom,mdp5";
reg = <0x00901000 0x9>;
reg-names = "mdp_phys";
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 2ca2f75f2aa7..5827cda270a0 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1497,7 +1497,7 @@ mdss: display-subsystem@c90 {
ranges;
status = "disabled";
- mdp: mdp@c901000 {
+ mdp: display-controller@c901000 {
compatible = "qcom,sdm630-mdp5", "qcom,mdp5";
reg = <0x0c901000 0x89000>;
reg-names = "mdp_phys";
--
2.39.0
[PATCH v7 04/11] dt-bindings: display/msm: rename mdss nodes to display-subsystem
Follow the 'generic names' rule and rename mdss nodes to
display-subsystem.
Signed-off-by: Dmitry Baryshkov
---
Note, this patch might generate warnings in qcom,sm6115-mdss and
qcom,qcm2290-mdss examples, but they have been fixed by the commit
e5266ca38294 ("dt-bindings: display: msm: Rename mdss node name in
example")
See https://gitlab.freedesktop.org/drm/msm/-/commit/e5266ca38294
---
.../devicetree/bindings/display/msm/mdss-common.yaml | 8
.../devicetree/bindings/display/msm/qcom,mdss.yaml| 5 -
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
index 59f17ac898aa..ccd7d6417523 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
@@ -15,7 +15,15 @@ description:
Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
sub-blocks like DPU display controller, DSI and DP interfaces etc.
+# Do not select this by default, otherwise it is also selected for qcom,mdss
+# devices.
+select:
+ false
+
properties:
+ $nodename:
+pattern: "^display-subsystem@[0-9a-f]+$"
+
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
index 461cb13c7092..7dceb2c54edd 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
@@ -15,6 +15,9 @@ description:
encapsulates sub-blocks like MDP5, DSI, HDMI, eDP, etc.
properties:
+ $nodename:
+pattern: "^display-subsystem@[0-9a-f]+$"
+
compatible:
enum:
- qcom,mdss
@@ -144,7 +147,7 @@ examples:
- |
#include
#include
-mdss@1a0 {
+display-subsystem@1a0 {
compatible = "qcom,mdss";
reg = <0x1a0 0x1000>,
<0x1ac8000 0x3000>;
--
2.39.0
[PATCH v7 09/11] ARM: dts: qcom-msm8974: rename mdss node to display-subsystem
Follow the schema change and rename mdss node to generic name
'display-subsystem'.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index ced62937165a..ec0c526d0483 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1556,7 +1556,7 @@ mmcc: clock-controller@fd8c {
"edp_vco_div";
};
- mdss: mdss@fd90 {
+ mdss: display-subsystem@fd90 {
compatible = "qcom,mdss";
reg = <0xfd90 0x100>, <0xfd924000 0x1000>;
reg-names = "mdss_phys", "vbif_phys";
--
2.39.0
[PATCH v7 05/11] dt-bindings: display/msm: rename mdp nodes to display-controller
Follow the 'generic names' rule and rename mdp nodes to
display-controller.
Reviewed-by: Rob Herring
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/dpu-common.yaml | 8
.../devicetree/bindings/display/msm/qcom,mdp5.yaml| 3 +++
.../devicetree/bindings/display/msm/qcom,mdss.yaml| 6 +++---
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
index 870158bb2aa0..3f953aa5e694 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
@@ -13,7 +13,15 @@ maintainers:
description: |
Common properties for QCom DPU display controller.
+# Do not select this by default, otherwise it is also selected for all
+# display-controller@ nodes
+select:
+ false
+
properties:
+ $nodename:
+pattern: '^display-controller@[0-9a-f]+$'
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
index cb7bf48c3a58..ef461ad6ce4a 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
@@ -33,6 +33,9 @@ properties:
- qcom,sdm660-mdp5
- const: qcom,mdp5
+ $nodename:
+pattern: '^display-controller@[0-9a-f]+$'
+
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
index 7dceb2c54edd..ef89ffe9b578 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
@@ -99,7 +99,7 @@ required:
- ranges
patternProperties:
- "^mdp@[1-9a-f][0-9a-f]*$":
+ "^display-controller@[1-9a-f][0-9a-f]*$":
type: object
properties:
compatible:
@@ -171,8 +171,8 @@ examples:
#size-cells = <1>;
ranges;
-mdp@1a01000 {
-compatible = "qcom,mdp5";
+display-controller@1a01000 {
+compatible = "qcom,msm8916-mdp5", "qcom,mdp5";
reg = <0x01a01000 0x89000>;
reg-names = "mdp_phys";
--
2.39.0
[PATCH v7 07/11] arm64: dts: qcom: add SoC specific compat strings to mdp5 nodes
Add SoC-specific compat string to the MDP5 device nodes to ease
distinguishing between various platforms.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm660.dtsi | 2 ++
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index cf248e10660b..68cdf255c474 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -989,7 +989,7 @@ mdss: mdss@1a0 {
ranges;
mdp: mdp@1a01000 {
- compatible = "qcom,mdp5";
+ compatible = "qcom,msm8916-mdp5", "qcom,mdp5";
reg = <0x01a01000 0x89000>;
reg-names = "mdp_phys";
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index b8cf5c461d98..c05d2a85247e 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -935,7 +935,7 @@ mdss: mdss@90 {
status = "disabled";
mdp: mdp@901000 {
- compatible = "qcom,mdp5";
+ compatible = "qcom,msm8996-mdp5", "qcom,mdp5";
reg = <0x00901000 0x9>;
reg-names = "mdp_phys";
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index e08ead06d4d3..d1542335be74 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1498,7 +1498,7 @@ mdss: mdss@c90 {
status = "disabled";
mdp: mdp@c901000 {
- compatible = "qcom,mdp5";
+ compatible = "qcom,sdm630-mdp5", "qcom,mdp5";
reg = <0x0c901000 0x89000>;
reg-names = "mdp_phys";
diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi
b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index d6908aa4c6e1..f0f27fc12c18 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -142,6 +142,8 @@ {
};
{
+ compatible = "qcom,sdm660-mdp5", "qcom,mdp5";
+
ports {
port@1 {
reg = <1>;
--
2.39.0
[PATCH v7 03/11] dt-bindings: display/msm: add core clock to the mdss bindings
Add (optional) core clock to the mdss bindings to let the MDSS driver access hardware registers before MDP driver probes. Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/qcom,mdss.yaml | 32 +-- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index d09842db3825..461cb13c7092 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -44,18 +44,30 @@ properties: The MDSS power domain provided by GCC clocks: -minItems: 1 -items: - - description: Display abh clock - - description: Display axi clock - - description: Display vsync clock +oneOf: + - minItems: 3 +items: + - description: Display abh clock + - description: Display axi clock + - description: Display vsync clock + - description: Display core clock + - minItems: 1 +items: + - description: Display abh clock + - description: Display core clock clock-names: -minItems: 1 -items: - - const: iface - - const: bus - - const: vsync +oneOf: + - minItems: 3 +items: + - const: iface + - const: bus + - const: vsync + - const: core + - minItems: 1 +items: + - const: iface + - const: core "#address-cells": const: 1 -- 2.39.0
[PATCH v7 06/11] ARM: dts: qcom-msm8974: add SoC specific compat string to mdp5 node
Add SoC-specific compat string to the MDP5 device node to ease
distinguishing between various platforms.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 44c4d8d8f51f..ced62937165a 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1580,7 +1580,7 @@ mdss: mdss@fd90 {
ranges;
mdp: mdp@fd90 {
- compatible = "qcom,mdp5";
+ compatible = "qcom,msm8974-mdp5", "qcom,mdp5";
reg = <0xfd900100 0x22000>;
reg-names = "mdp_phys";
--
2.39.0
[PATCH v7 01/11] dt-bindings: display/msm: convert MDP5 schema to YAML format
Convert the mdp5.txt into the yaml format. Changes to the existing (txt) schema:
- MSM8996 has additional "iommu" clock, define it separately
- Add new properties used on some of platforms:
- interconnects, interconnect-names
- iommus
- power-domains
- operating-points-v2, opp-table
Reviewed-by: Rob Herring
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/mdp5.txt | 132 -
.../bindings/display/msm/qcom,mdp5.yaml | 138 ++
2 files changed, 138 insertions(+), 132 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/msm/mdp5.txt
create mode 100644 Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt
b/Documentation/devicetree/bindings/display/msm/mdp5.txt
deleted file mode 100644
index 65d03c58dee6..
--- a/Documentation/devicetree/bindings/display/msm/mdp5.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-Qualcomm adreno/snapdragon MDP5 display controller
-
-Description:
-
-This is the bindings documentation for the MDP5 display
-controller found in SoCs like MSM8974, APQ8084, MSM8916, MSM8994 and MSM8996.
-
-MDP5:
-Required properties:
-- compatible:
- * "qcom,mdp5" - MDP5
-- reg: Physical base address and length of the controller's registers.
-- reg-names: The names of register regions. The following regions are required:
- * "mdp_phys"
-- interrupts: Interrupt line from MDP5 to MDSS interrupt controller.
-- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required.
-- * "bus"
-- * "iface"
-- * "core"
-- * "vsync"
-- ports: contains the list of output ports from MDP. These connect to
interfaces
- that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
- special case since it is a part of the MDP block itself).
-
- Each output port contains an endpoint that describes how it is connected to
an
- external interface. These are described by the standard properties documented
- here:
- Documentation/devicetree/bindings/graph.txt
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
- The availability of output ports can vary across SoC revisions:
-
- For MSM8974 and APQ8084:
-Port 0 -> MDP_INTF0 (eDP)
-Port 1 -> MDP_INTF1 (DSI1)
-Port 2 -> MDP_INTF2 (DSI2)
-Port 3 -> MDP_INTF3 (HDMI)
-
- For MSM8916:
-Port 0 -> MDP_INTF1 (DSI1)
-
- For MSM8994 and MSM8996:
-Port 0 -> MDP_INTF1 (DSI1)
-Port 1 -> MDP_INTF2 (DSI2)
-Port 2 -> MDP_INTF3 (HDMI)
-
-Optional properties:
-- clock-names: the following clocks are optional:
- * "lut"
- * "tbu"
- * "tbu_rt"
-
-Example:
-
-/ {
- ...
-
- mdss: mdss@1a0 {
- compatible = "qcom,mdss";
- reg = <0x1a0 0x1000>,
- <0x1ac8000 0x3000>;
- reg-names = "mdss_phys", "vbif_phys";
-
- power-domains = < MDSS_GDSC>;
-
- clocks = < GCC_MDSS_AHB_CLK>,
-< GCC_MDSS_AXI_CLK>,
-< GCC_MDSS_VSYNC_CLK>;
- clock-names = "iface",
- "bus",
- "vsync"
-
- interrupts = <0 72 0>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- mdp: mdp@1a01000 {
- compatible = "qcom,mdp5";
- reg = <0x1a01000 0x9>;
- reg-names = "mdp_phys";
-
- interrupt-parent = <>;
- interrupts = <0 0>;
-
- clocks = < GCC_MDSS_AHB_CLK>,
-< GCC_MDSS_AXI_CLK>,
-< GCC_MDSS_MDP_CLK>,
-< GCC_MDSS_VSYNC_CLK>;
- clock-names = "iface",
- "bus",
- "core",
- "vsync";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- mdp5_intf1_out: endpoint {
- remote-endpoint = <_in>;
- };
- };
- };
- };
-
- dsi0: dsi@1a98000 {
- ...
- ports {
- ...
- port@0 {
- reg = <0>;
- dsi0_in: endpoint {
-
[PATCH v7 02/11] dt-bindings: display/msm: add SoC-specific compats to qcom, mdp5.yaml
Add platform-specific compatible entries to the qcom,mdp5.yaml to allow distinguishing between various platforms. Reviewed-by: Rob Herring Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/qcom,mdp5.yaml | 17 - .../bindings/display/msm/qcom,mdss.yaml | 3 ++- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index 5e3cd7abf046..cb7bf48c3a58 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -16,7 +16,22 @@ maintainers: properties: compatible: -const: qcom,mdp5 +oneOf: + - const: qcom,mdp5 +deprecated: true + - items: + - enum: + - qcom,apq8084-mdp5 + - qcom,msm8916-mdp5 + - qcom,msm8917-mdp5 + - qcom,msm8953-mdp5 + - qcom,msm8974-mdp5 + - qcom,msm8976-mdp5 + - qcom,msm8994-mdp5 + - qcom,msm8996-mdp5 + - qcom,sdm630-mdp5 + - qcom,sdm660-mdp5 + - const: qcom,mdp5 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index 7479cd96fdec..d09842db3825 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -88,7 +88,8 @@ patternProperties: type: object properties: compatible: -const: qcom,mdp5 +contains: + const: qcom,mdp5 "^dsi@[1-9a-f][0-9a-f]*$": type: object -- 2.39.0
[PATCH v7 00/11] dt-bindings: display/msm: rework MDP5 and MDSS schema
Krzysztof asked me to merge all pending MDSS/MDP5/DPU patches to a
single series to ease review and to let one to see the whole picture.
This combines three series: MDP5 schema conversion, mdss/mdp renaming
and addition of the "core" clock to the MDSS device node.
Patch 4 might generate warnings in qcom,sm6115-mdss and
qcom,qcm2290-mdss examples, but they have been fixed by the commit
e5266ca38294 ("dt-bindings: display: msm: Rename mdss node name in
example"). See https://gitlab.freedesktop.org/drm/msm/-/commit/e5266ca38294
Changes since v6:
- Switched qcom,mdss.yaml to use contains rather than oneOf (Rob
Herring)
- Fixed typo in patch 3 commit message (Rob Herring)
- Reworked clocks/clock-names to have oneOf under the properties
themselves, rather than having a toplevel switch (Rob Herring)
Changes since v5:
- Merged in the mdss/mdp node renaming and core clock series
- Fixed the formatting of descriptions in qcom,mdp5 schema.
Changes since v4:
- Adjust qcom,mdss.yaml to follow the addition of per-SoC compatibles
Changes since v3:
- Drop MSM8998 completely, it conflicts with qcom,msm8998-dpu.yaml
Changes since v2:
- Fix MSM8998 compatible list: "qcom,msm8998-dpu", "msm,mdp5" to allow
handling this device by either of the drivers.
Dmitry Baryshkov (11):
dt-bindings: display/msm: convert MDP5 schema to YAML format
dt-bindings: display/msm: add SoC-specific compats to qcom,mdp5.yaml
dt-bindings: display/msm: add core clock to the mdss bindings
dt-bindings: display/msm: rename mdss nodes to display-subsystem
dt-bindings: display/msm: rename mdp nodes to display-controller
ARM: dts: qcom-msm8974: add SoC specific compat string to mdp5 node
arm64: dts: qcom: add SoC specific compat strings to mdp5 nodes
arm64: dts: qcom: rename mdss nodes to display-subsystem
ARM: dts: qcom-msm8974: rename mdss node to display-subsystem
arm64: dts: qcom: rename mdp nodes to display-controller
ARM: dts: qcom: rename mdp nodes to display-controller
.../bindings/display/msm/dpu-common.yaml | 8 +
.../devicetree/bindings/display/msm/mdp5.txt | 132 ---
.../bindings/display/msm/mdss-common.yaml | 8 +
.../bindings/display/msm/qcom,mdp5.yaml | 156 ++
.../bindings/display/msm/qcom,mdss.yaml | 46 --
arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +-
arch/arm/boot/dts/qcom-msm8974.dtsi | 6 +-
arch/arm64/boot/dts/qcom/msm8916.dtsi | 6 +-
arch/arm64/boot/dts/qcom/msm8953.dtsi | 4 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm630.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sdm660.dtsi | 2 +
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
15 files changed, 223 insertions(+), 165 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/msm/mdp5.txt
create mode 100644 Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
--
2.39.0
Re: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the interfaces
On 18/01/2023 05:30, Kalyan Thota wrote:
-Original Message-
From: Dmitry Baryshkov
Sent: Tuesday, January 17, 2023 10:26 PM
To: Kalyan Thota (QUIC) ; dri-
de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
; Abhinav Kumar (QUIC)
Subject: Re: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the
interfaces
WARNING: This email originated from outside of Qualcomm. Please be wary of
any links or attachments, and do not enable macros.
On 17/01/2023 18:21, Kalyan Thota wrote:
Allow dspps to be populated as a requirement for all the encoder types
it need not be just DSI. If for any encoder the dspp allocation
doesn't go through then there can be an option to fallback for color
features.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b..e39b345 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder
*drm_enc)
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ struct drm_crtc_state *crtc_state)
Is this new argument used at all?
{
struct msm_display_topology topology = {0};
int i, intf_count = 0;
@@ -563,8 +564,9 @@ static struct msm_display_topology
dpu_encoder_get_topology(
* 1 LM, 1 INTF
* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
*
- * Adding color blocks only to primary interface if available in
- * sufficient number
+ * dspp blocks are made optional. If RM manager cannot allocate
+ * dspp blocks, then reservations will still go through with non dspp LM's
+ * so as to allow color management support via composer
+ fallbacks
*/
No, this is not the way to go.
First, RM should prefer non-DSPP-enabled LMs if DSPP blocks are not required.
Right now your patch makes it possible to allocate LMs, that have DSPP attached,
for non-CTM-enabled encoder and later fail allocation of DSPP for the CRTC
which has CTM blob attached.
Second, the decision on using DSPPs should come from dpu_crtc_atomic_check().
Pass 'bool need_dspp' to this function from dpu_atomic_check(). Fail if the
need_dspp constraint can't be fulfilled.
We may not get color_mgmt_changed property set during modeset commit, where as
our resource allocation happens during modeset.
So, you have to fix the conditions to perform LM reallocation if CTM
usage has changed (note, color_mgmt_changed is not a correct one here).
With this approach, dspps will get allocated on first come first serve basis
I don't think that this is what we have agreed upon.
@Rob, is it possible to send color management property during modeset, in that
case, we can use it for dspp allocation to the datapath. The current approach
doesn't assume it.
On chrome compositor, I see that color property was being set in the subsequent
commits but not in modeset.
if (intf_count == 2)
topology.num_lm = 2;
@@ -573,11 +575,9 @@ static struct msm_display_topology
dpu_encoder_get_topology(
else
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT)
? 2 : 1;
- if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
- if (dpu_kms->catalog->dspp &&
- (dpu_kms->catalog->dspp_count >= topology.num_lm))
- topology.num_dspp = topology.num_lm;
- }
+ if (dpu_kms->catalog->dspp &&
+ (dpu_kms->catalog->dspp_count >= topology.num_lm))
+ topology.num_dspp = topology.num_lm;
topology.num_enc = 0;
topology.num_intf = intf_count;
@@ -643,7 +643,7 @@ static int dpu_encoder_virt_atomic_check(
}
}
- topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
+ topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
+ crtc_state);
/* Reserve dynamic resources now. */
if (!ret) {
--
With best wishes
Dmitry
--
With best wishes
Dmitry
RE: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the interfaces
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Tuesday, January 17, 2023 10:26 PM
>To: Kalyan Thota (QUIC) ; dri-
>de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
>Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>; Abhinav Kumar (QUIC)
>
>Subject: Re: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the
>interfaces
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 17/01/2023 18:21, Kalyan Thota wrote:
>> Allow dspps to be populated as a requirement for all the encoder types
>> it need not be just DSI. If for any encoder the dspp allocation
>> doesn't go through then there can be an option to fallback for color
>> features.
>>
>> Signed-off-by: Kalyan Thota
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +-
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> index 9c6817b..e39b345 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> @@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder
>*drm_enc)
>> static struct msm_display_topology dpu_encoder_get_topology(
>> struct dpu_encoder_virt *dpu_enc,
>> struct dpu_kms *dpu_kms,
>> - struct drm_display_mode *mode)
>> + struct drm_display_mode *mode,
>> + struct drm_crtc_state *crtc_state)
>
>Is this new argument used at all?
>
>> {
>> struct msm_display_topology topology = {0};
>> int i, intf_count = 0;
>> @@ -563,8 +564,9 @@ static struct msm_display_topology
>dpu_encoder_get_topology(
>>* 1 LM, 1 INTF
>>* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
>>*
>> - * Adding color blocks only to primary interface if available in
>> - * sufficient number
>> + * dspp blocks are made optional. If RM manager cannot allocate
>> + * dspp blocks, then reservations will still go through with non dspp
>> LM's
>> + * so as to allow color management support via composer
>> + fallbacks
>>*/
>
>No, this is not the way to go.
>
>First, RM should prefer non-DSPP-enabled LMs if DSPP blocks are not required.
>Right now your patch makes it possible to allocate LMs, that have DSPP
>attached,
>for non-CTM-enabled encoder and later fail allocation of DSPP for the CRTC
>which has CTM blob attached.
>
>Second, the decision on using DSPPs should come from dpu_crtc_atomic_check().
>Pass 'bool need_dspp' to this function from dpu_atomic_check(). Fail if the
>need_dspp constraint can't be fulfilled.
>
We may not get color_mgmt_changed property set during modeset commit, where as
our resource allocation happens during modeset.
With this approach, dspps will get allocated on first come first serve basis
@Rob, is it possible to send color management property during modeset, in that
case, we can use it for dspp allocation to the datapath. The current approach
doesn't assume it.
On chrome compositor, I see that color property was being set in the subsequent
commits but not in modeset.
>
>> if (intf_count == 2)
>> topology.num_lm = 2;
>> @@ -573,11 +575,9 @@ static struct msm_display_topology
>dpu_encoder_get_topology(
>> else
>> topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT)
>> ? 2 : 1;
>>
>> - if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
>> - if (dpu_kms->catalog->dspp &&
>> - (dpu_kms->catalog->dspp_count >= topology.num_lm))
>> - topology.num_dspp = topology.num_lm;
>> - }
>> + if (dpu_kms->catalog->dspp &&
>> + (dpu_kms->catalog->dspp_count >= topology.num_lm))
>> + topology.num_dspp = topology.num_lm;
>>
>> topology.num_enc = 0;
>> topology.num_intf = intf_count;
>> @@ -643,7 +643,7 @@ static int dpu_encoder_virt_atomic_check(
>> }
>> }
>>
>> - topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
>> + topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
>> + crtc_state);
>>
>> /* Reserve dynamic resources now. */
>> if (!ret) {
>
>--
>With best wishes
>Dmitry
Re: [PATCH v8 1/3] dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC
On 17/01/2023 00:52, Bryan O'Donoghue wrote: Currently we do not differentiate between the various users of the qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one compatible string but, the hardware does have some significant differences in the number of clocks. To facilitate documenting the clocks add the following compatible strings - qcom,apq8064-dsi-ctrl - qcom,msm8916-dsi-ctrl - qcom,msm8953-dsi-ctrl - qcom,msm8974-dsi-ctrl - qcom,msm8996-dsi-ctrl - qcom,msm8998-dsi-ctrl - qcom,sc7180-dsi-ctrl - qcom,sc7280-dsi-ctrl - qcom,sdm660-dsi-ctrl - qcom,sdm845-dsi-ctrl - qcom,sm8150-dsi-ctrl - qcom,sm8250-dsi-ctrl - qcom,sm8350-dsi-ctrl - qcom,sm8450-dsi-ctrl - qcom,sm8550-dsi-ctrl - qcom,qcm2290-dsi-ctrl Deprecate qcom,dsi-ctrl-6g-qcm2290 in favour of the desired format while we do so. Several MDSS yaml files exist which document the dsi sub-node. For each existing SoC MDSS yaml, provide the right dsi compat string. Signed-off-by: Bryan O'Donoghue --- .../display/msm/dsi-controller-main.yaml | 30 --- .../bindings/display/msm/qcom,mdss.yaml | 3 +- .../display/msm/qcom,msm8998-mdss.yaml| 8 +++-- .../display/msm/qcom,sc7180-mdss.yaml | 6 ++-- .../display/msm/qcom,sc7280-mdss.yaml | 6 ++-- .../display/msm/qcom,sdm845-mdss.yaml | 8 +++-- .../display/msm/qcom,sm8150-mdss.yaml | 8 +++-- .../display/msm/qcom,sm8250-mdss.yaml | 8 +++-- .../display/msm/qcom,sm8350-mdss.yaml | 6 ++-- .../display/msm/qcom,sm8450-mdss.yaml | 4 ++- 10 files changed, 63 insertions(+), 24 deletions(-) [skipped] diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml index c268e0b662cf9..599a6bad80f43 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml @@ -46,7 +46,9 @@ patternProperties: type: object properties: compatible: -const: qcom,mdss-dsi-ctrl +items: + - const: qcom,sm8450-dsi-ctrl + - const: qcom,mdss-dsi-ctrl "^phy@[0-9a-f]+$": type: object The example also should be updated in this file to include qcom,sm8450-dsi-ctrl for DSI nodes -- With best wishes Dmitry
Re: [PATCH 1/3] drm/msm/disp/dpu1: allow reservation even if dspps are not available.
On 18/01/2023 05:24, Kalyan Thota wrote:
-Original Message-
From: Dmitry Baryshkov
Sent: Tuesday, January 17, 2023 10:10 PM
To: Kalyan Thota (QUIC) ; dri-
de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
; Abhinav Kumar (QUIC)
Subject: Re: [PATCH 1/3] drm/msm/disp/dpu1: allow reservation even if dspps are
not available.
WARNING: This email originated from outside of Qualcomm. Please be wary of
any links or attachments, and do not enable macros.
On 17/01/2023 18:35, Dmitry Baryshkov wrote:
On 17/01/2023 18:21, Kalyan Thota wrote:
if any topology requests for dspps and catalogue doesn't have the
allocation, avoid failing the reservation.
This can pave way to build logic allowing composer fallbacks for all
the color features that are handled in dspp.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 73b3442..c8899ae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -343,7 +343,13 @@ static bool
_dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm,
return true;
idx = lm_cfg->dspp - DSPP_0;
-if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks)) {
+
+if (idx < 0) {
The change doesn't correspond to commit message.
+DPU_DEBUG("lm doesn't have dspp, ignoring the request %d\n",
lm_cfg->dspp);
+return true;
+}
+
+if (idx >= ARRAY_SIZE(rm->dspp_blks)) {
DPU_ERROR("failed to get dspp on lm %d\n", lm_cfg->dspp);
return false;
}
If you'd like to remove duplicate for the (idx >= ARRAY_SIZE) check,
I'd suggest dropping the second one
I've misread the patch. However I don't see, why would one request DSPP_NONE
while specifying topology->num_dspp. I think that you are trying to put
additional
logic into a function that should just check for the available resources.
The link is specified in the catalogue.
For example:
LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
_lm_sblk, PINGPONG_0, 0, DSPP_0), --> This LM has
DSPP attached
LM_BLK("lm_2", LM_2, 0x46000, MIXER_SC7180_MASK,
_lm_sblk, PINGPONG_2, LM_3, 0), --> no DSPP
LM_BLK("lm_3", LM_3, 0x47000, MIXER_SC7180_MASK,
_lm_sblk, PINGPONG_3, LM_2, 0), --> no DSPP
For the above example, num_dspps will be 1 which is nonzero. But if a request
comes on second interface and if there are no dspps then we are not failing the
reservation of data path as color features can be offloaded to GPU.
Idx for LM_2 and LM_3 will be -1 for above case hence the check not to fail
reservation.
topology->num_dspp previously was filled based on encoder type, since we want
to move away from encoder checks, we are now passing it same as LM number. If
there are dspps available we will allocate,
in case of non-availability then we are not failing the datapath reservation so
that composer fallbacks can be implemented.
As I wrote, num_dspps should be filled correctly (by the
dpu_get_topology) to request DSPP for CTM-enabled CRTCs and to set the
field to 0 if CRTC doesn't have CTM enabled.
Then RM code should adhere to the num_dspps passed. It must return an
error if it can not fulfil the requirements. Also if no DSPPs are
requested, RM should prefer non-DSPP-enabled LMs.
--
With best wishes
Dmitry
[PATCH 3/4] dt-bindings: display/msm: dsi-controller-main: allow using fewer lanes
Some platforms might use less than full 4 lanes DSI interface. Allow using any amount of lanes starting from 1 up to 4. Signed-off-by: Dmitry Baryshkov --- .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 357036470b1f..dc318762ef7a 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -123,7 +123,7 @@ properties: properties: data-lanes: maxItems: 4 -minItems: 4 +minItems: 1 items: enum: [ 0, 1, 2, 3 ] @@ -139,7 +139,7 @@ properties: properties: data-lanes: maxItems: 4 -minItems: 4 +minItems: 1 items: enum: [ 0, 1, 2, 3 ] -- 2.39.0
[PATCH 4/4] dt-binbings: display/msm: dsi-controller-main: add missing supplies
Describe DSI supplies used on apq8064 (vdda-supply) and msm8994/96 (vcca-supply). Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/dsi-controller-main.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index dc318762ef7a..31d389249c1d 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -147,6 +147,14 @@ properties: - port@0 - port@1 + avdd-supply: +description: + Phandle to vdd regulator device node + + vcca-supply: +description: + Phandle to vdd regulator device node + vdd-supply: description: VDD regulator -- 2.39.0
[PATCH 1/4] dt-bindings: display/msm: dsi-controller-main: remove #address/#size-cells
Stop mentioning #address-cells/#size-cells which are defined in display/dsi-controller.yaml. Use unevaluatedProperties instead of additionalProperties to allow skipping properties defined in other schema files. Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/dsi-controller-main.yaml | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 7c326f8927fc..b07bdddc1570 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -72,10 +72,6 @@ properties: deprecated: true const: dsi - "#address-cells": true - - "#size-cells": true - syscon-sfpb: description: A phandle to mmss_sfpb syscon node (only for DSIv2). $ref: "/schemas/types.yaml#/definitions/phandle" @@ -357,7 +353,7 @@ allOf: - const: iface - const: bus -additionalProperties: false +unevaluatedProperties: false examples: - | -- 2.39.0
[PATCH 2/4] dt-bindings: display/msm: dsi-controller-main: account for apq8064
APQ8064 requires listing four clocks in the assigned-clocks / assigned-clock-parents properties. Account for that. Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/dsi-controller-main.yaml | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index b07bdddc1570..357036470b1f 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -83,12 +83,16 @@ properties: 2 DSI links. assigned-clocks: -maxItems: 2 +minItems: 2 +maxItems: 4 description: | Parents of "byte" and "pixel" for the given platform. + For DSIv2 platforms this should contain "byte", "esc", "src" and + "pixel_src" clocks. assigned-clock-parents: -maxItems: 2 +minItems: 2 +maxItems: 4 description: | The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. -- 2.39.0
[PATCH 0/4] dt-bindings: display/msm: more dsi-controller fixes
A small set of patches to go on top of Bryan's changes to fix a small number of remaining issues. Dependencies: [1] [1] https://lore.kernel.org/linux-arm-msm/20230116225217.1056258-1-bryan.odonog...@linaro.org/ Dmitry Baryshkov (4): dt-bindings: display/msm: dsi-controller-main: remove #address/#size-cells dt-bindings: display/msm: dsi-controller-main: account for apq8064 dt-bindings: display/msm: dsi-controller-main: allow using fewer lanes dt-binbings: display/msm: dsi-controller-main: add missing supplies .../display/msm/dsi-controller-main.yaml | 26 --- 1 file changed, 17 insertions(+), 9 deletions(-) -- 2.39.0
Re: [PATCH 1/2] drm: Add DRM-managed alloc_workqueue() and alloc_ordered_workqueue()
> On Tue, Jan 10, 2023 at 11:24:47PM +0800, Jiasheng Jiang wrote: >> Add drmm_alloc_workqueue() and drmm_alloc_ordered_workqueue(), the helpers >> that provide managed workqueue cleanup. The workqueue will be destroyed >> with the final reference of the DRM device. >> >> Signed-off-by: Jiasheng Jiang > > Yeah I think this looks nice. > > Reviewed-by: Daniel Vetter > > I'm assuming driver maintainers will pick this up, if not please holler. > > Also the threading seems broken, it's not a patch series. The b4 tool or > git send-email (of all the patches of the entire series at once, not each > individually) should get this right. > > Unfortunately I did't find the right link in the kernel docs, or at least > they're not as detailed as I hoped. > > Also your previous submission had iirc a bunch more patches, do you plan > to include them all in the next patch set? I have found that some previous patches have already been applied. Need I just convert alloc*workqueue into drmm_alloc*workqueue and remove the destroy_workqueue? Or need I convert all the alloc*workqueue in the DRM? Thanks, Jiang
RE: [PATCH 1/3] drm/msm/disp/dpu1: allow reservation even if dspps are not available.
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Tuesday, January 17, 2023 10:10 PM
>To: Kalyan Thota (QUIC) ; dri-
>de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
>Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>; Abhinav Kumar (QUIC)
>
>Subject: Re: [PATCH 1/3] drm/msm/disp/dpu1: allow reservation even if dspps are
>not available.
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 17/01/2023 18:35, Dmitry Baryshkov wrote:
>> On 17/01/2023 18:21, Kalyan Thota wrote:
>>> if any topology requests for dspps and catalogue doesn't have the
>>> allocation, avoid failing the reservation.
>>>
>>> This can pave way to build logic allowing composer fallbacks for all
>>> the color features that are handled in dspp.
>>>
>>> Signed-off-by: Kalyan Thota
>>> ---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
>>> index 73b3442..c8899ae 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
>>> @@ -343,7 +343,13 @@ static bool
>>> _dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm,
>>> return true;
>>> idx = lm_cfg->dspp - DSPP_0;
>>> -if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks)) {
>>> +
>>> +if (idx < 0) {
>>
>> The change doesn't correspond to commit message.
>>
>>> +DPU_DEBUG("lm doesn't have dspp, ignoring the request %d\n",
>>> lm_cfg->dspp);
>>> +return true;
>>> +}
>>> +
>>> +if (idx >= ARRAY_SIZE(rm->dspp_blks)) {
>>> DPU_ERROR("failed to get dspp on lm %d\n", lm_cfg->dspp);
>>> return false;
>>> }
>>
>> If you'd like to remove duplicate for the (idx >= ARRAY_SIZE) check,
>> I'd suggest dropping the second one
>>
>
>I've misread the patch. However I don't see, why would one request DSPP_NONE
>while specifying topology->num_dspp. I think that you are trying to put
>additional
>logic into a function that should just check for the available resources.
>
The link is specified in the catalogue.
For example:
LM_BLK("lm_0", LM_0, 0x44000, MIXER_SC7180_MASK,
_lm_sblk, PINGPONG_0, 0, DSPP_0), --> This LM has
DSPP attached
LM_BLK("lm_2", LM_2, 0x46000, MIXER_SC7180_MASK,
_lm_sblk, PINGPONG_2, LM_3, 0), --> no DSPP
LM_BLK("lm_3", LM_3, 0x47000, MIXER_SC7180_MASK,
_lm_sblk, PINGPONG_3, LM_2, 0), --> no DSPP
For the above example, num_dspps will be 1 which is nonzero. But if a request
comes on second interface and if there are no dspps then we are not failing the
reservation of data path as color features can be offloaded to GPU.
Idx for LM_2 and LM_3 will be -1 for above case hence the check not to fail
reservation.
topology->num_dspp previously was filled based on encoder type, since we want
to move away from encoder checks, we are now passing it same as LM number. If
there are dspps available we will allocate,
in case of non-availability then we are not failing the datapath reservation so
that composer fallbacks can be implemented.
>--
>With best wishes
>Dmitry
[PATCH] arm64: dts: qcom: sm8350: use qcom, sm8350-dsi-ctrl compatibles
Add the per-SoC (qcom,sm8350-dsi-ctrl) compatible strings to DSI nodes
to follow the pending DSI bindings changes.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 703ba3d81e82..a066566b6ea9 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -2883,7 +2883,7 @@ dpu_intf1_out: endpoint {
};
mdss_dsi0: dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8350-dsi-ctrl",
"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;
reg-names = "dsi_ctrl";
@@ -2978,7 +2978,7 @@ mdss_dsi0_phy: phy@ae94400 {
};
mdss_dsi1: dsi@ae96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8350-dsi-ctrl",
"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae96000 0 0x400>;
reg-names = "dsi_ctrl";
--
2.39.0
[PATCH 3/4] arm64: dts: qcom: sc8280xp-crd: drop #sound-dai-cells from eDP node
The eDP device doesn't provide sound DAI. Drop corresponding property
from the eDP node.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
index 4e92dc28e2ce..a3b9c9d0a94d 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
@@ -253,6 +253,7 @@ {
_dp3 {
compatible = "qcom,sc8280xp-edp";
+ /delete-property/ #sound-dai-cells;
data-lanes = <0 1 2 3>;
--
2.39.0
[PATCH 2/4] dt-bindings: display/msm: qcom, sc8280xp-mdss: add DP / eDP child nodes
Describe DP and eDP devices as subdevices to the MDSS on SC8280XP
platform.
Fixes: 45af56bf2d74 ("dt-bindings: display/msm: Add binding for SC8280XP MDSS")
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/qcom,sc8280xp-mdss.yaml | 8
1 file changed, 8 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
index b67e7874ed56..c239544bc37f 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
@@ -38,6 +38,14 @@ patternProperties:
compatible:
const: qcom,sc8280xp-dpu
+ "^displayport-controller@[0-9a-f]+$":
+type: object
+properties:
+ compatible:
+enum:
+ - qcom,sc8280xp-dp
+ - qcom,sc8280xp-edp
+
unevaluatedProperties: false
examples:
--
2.39.0
[PATCH 4/4] arm64: dts: qcom: sc8280xp: add p1 register blocks to DP nodes
Per DT bindings add p1 register blocks to all DP controllers on SC8280XP
platform.
Fixes: 6f299ae7f96d ("arm64: dts: qcom: sc8280xp: add p1 register blocks to DP
nodes")
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index ea2c8ad37ccb..ed11fb89cdc7 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -2448,7 +2448,8 @@ mdss0_dp2: displayport-controller@ae9a000 {
reg = <0 0xae9a000 0 0x200>,
<0 0xae9a200 0 0x200>,
<0 0xae9a400 0 0x600>,
- <0 0xae9b000 0 0x400>;
+ <0 0xae9b000 0 0x400>,
+ <0 0xae9b400 0 0x400>;
clocks = < DISP_CC_MDSS_AHB_CLK>,
< DISP_CC_MDSS_DPTX2_AUX_CLK>,
@@ -2519,7 +2520,8 @@ mdss0_dp3: displayport-controller@aea {
reg = <0 0xaea 0 0x200>,
<0 0xaea0200 0 0x200>,
<0 0xaea0400 0 0x600>,
- <0 0xaea1000 0 0x400>;
+ <0 0xaea1000 0 0x400>,
+ <0 0xaea1400 0 0x400>;
clocks = < DISP_CC_MDSS_AHB_CLK>,
< DISP_CC_MDSS_DPTX3_AUX_CLK>,
@@ -3394,7 +3396,8 @@ mdss1_dp0: displayport-controller@2209 {
reg = <0 0x2209 0 0x200>,
<0 0x22090200 0 0x200>,
<0 0x22090400 0 0x600>,
- <0 0x22091000 0 0x400>;
+ <0 0x22091000 0 0x400>,
+ <0 0x22091400 0 0x400>;
clocks = < DISP_CC_MDSS_AHB_CLK>,
< DISP_CC_MDSS_DPTX0_AUX_CLK>,
@@ -3466,7 +3469,8 @@ mdss1_dp1: displayport-controller@22098000 {
reg = <0 0x22098000 0 0x200>,
<0 0x22098200 0 0x200>,
<0 0x22098400 0 0x600>,
- <0 0x22099000 0 0x400>;
+ <0 0x22099000 0 0x400>,
+ <0 0x22099400 0 0x400>;
clocks = < DISP_CC_MDSS_AHB_CLK>,
< DISP_CC_MDSS_DPTX1_AUX_CLK>,
@@ -3537,7 +3541,8 @@ mdss1_dp2: displayport-controller@2209a000 {
reg = <0 0x2209a000 0 0x200>,
<0 0x2209a200 0 0x200>,
<0 0x2209a400 0 0x600>,
- <0 0x2209b000 0 0x400>;
+ <0 0x2209b000 0 0x400>,
+ <0 0x2209b400 0 0x400>;
clocks = < DISP_CC_MDSS_AHB_CLK>,
< DISP_CC_MDSS_DPTX2_AUX_CLK>,
@@ -3608,7 +3613,8 @@ mdss1_dp3: displayport-controller@220a {
reg = <0 0x220a 0 0x200>,
<0 0x220a0200 0 0x200>,
<0 0x220a0400 0 0x600>,
- <0 0x220a1000 0 0x400>;
+ <0 0x220a1000 0 0x400>,
+ <0 0x220a1400 0 0x400>;
clocks = < DISP_CC_MDSS_AHB_CLK>,
< DISP_CC_MDSS_DPTX3_AUX_CLK>,
--
2.39.0
[PATCH 1/4] dt-bindings: display/msm: add qcom, sc8280xp-edp to list of eDP devices
Add qcom,sc8280xp-edp to the list of eDP devices, unblocking `aux-bus'
property and fobidding `#sound-dai-cells' property. Also since
sc8280xp-edp, overriding sc8280xp-dp, will contain 5 reg resources, drop
the reg contraint (as it will become equivalent to the top-level one,
requiring min 4 and max 5 reg entries).
Fixes: b6f8c4debc00 ("dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles")
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/dp-controller.yaml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 3e54956e57db..efe4257c031f 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -151,11 +151,10 @@ allOf:
enum:
- qcom,sc7280-edp
- qcom,sc8180x-edp
+ - qcom,sc8280xp-edp
then:
properties:
"#sound-dai-cells": false
-reg:
- maxItems: 4
else:
properties:
aux-bus: false
--
2.39.0
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Thu, Jan 12, 2023 at 04:39:32PM -0800, John Harrison wrote: > On 1/11/2023 14:56, Jason Ekstrand wrote: > > On Wed, Jan 11, 2023 at 4:32 PM Matthew Brost > > wrote: > > > > On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote: > > > On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin < > > > tvrtko.ursu...@linux.intel.com> wrote: > > > > > > > > > [snip] > > > > > > > > Typically is the key here. But I am not sure it is good > > enough. Consider > > > > this example - Intel Flex 170: > > > > > > > > * Delivers up to 36 streams 1080p60 transcode throughput per > > card. > > > > * When scaled to 10 cards in a 4U server configuration, it > > can support > > > > up to 360 streams of HEVC/HEVC 1080p60 transcode throughput. > > > > > > > > > > I had a feeling it was going to be media > > > > > > > Yea wondering the media UMD can be rewritten to use less > > xe_engines, it > > is massive rewrite for VM bind + no implicit dependencies so let's > > just > > pile on some more work? > > > > > > It could probably use fewer than it does today. It currently creates > > and throws away contexts like crazy, or did last I looked at it. > > However, the nature of media encode is that it often spreads across two > > or three different types of engines. There's not much you can do to > > change that. > And as per Tvrtko's example, you get media servers that transcode huge > numbers of tiny streams in parallel. Almost no work per frame but 100s of > independent streams being run concurrently. That means many 100s of contexts > all trying to run at 30fps. I recall a specific bug about thundering herds - > hundreds (thousands?) of waiting threads all being woken up at once because > some request had completed. > > > > > > > > One transcode stream from my experience typically is 3-4 GPU > > contexts > > > > (buffer travels from vcs -> rcs -> vcs, maybe vecs) used from > > a single > > > > CPU thread. 4 contexts * 36 streams = 144 active contexts. > > Multiply by > > > > 60fps = 8640 jobs submitted and completed per second. > > > > > > > > 144 active contexts in the proposed scheme means possibly > > means 144 > > > > kernel worker threads spawned (driven by 36 transcode CPU > > threads). (I > > > > don't think the pools would scale down given all are > > constantly pinged > > > > at 60fps.) > > > > > > > > And then each of 144 threads goes to grab the single GuC CT > > mutex. First > > > > threads are being made schedulable, then put to sleep as mutex > > > > contention is hit, then woken again as mutexes are getting > > released, > > > > rinse, repeat. > > > > > > > > > > Why is every submission grabbing the GuC CT mutex? I've not read > > the GuC > > > back-end yet but I was under the impression that most run_job() > > would be > > > just shoving another packet into a ring buffer. If we have to > > send the GuC > > > a message on the control ring every single time we submit a job, > > that's > > > pretty horrible. > > > > > > > Run job writes the ring buffer and moves the tail as the first > > step (no > > lock required). Next it needs to tell the GuC the xe_engine LRC > > tail has > > moved, this is done from a single Host to GuC channel which is > > circular > > buffer, the writing of the channel protected by the mutex. There are > > little more nuances too but in practice there is always space in the > > channel so the time mutex needs to held is really, really small > > (check cached credits, write 3 dwords in payload, write 1 dword to > > move > > tail). I also believe mutexes in Linux are hybrid where they spin > > for a > > little bit before sleeping and certainly if there is space in the > > channel we shouldn't sleep mutex contention. > > > > > > Ok, that makes sense. It's maybe a bit clunky and it'd be nice if we > > had some way to batch things up a bit so we only have to poke the GuC > > channel once for every batch of things rather than once per job. That's > > maybe something we can look into as a future improvement; not > > fundamental. > > > > Generally, though, it sounds like contention could be a real problem if > > we end up ping-ponging that lock between cores. It's going to depend on > > how much work it takes to get the next ready thing vs. the cost of that > > atomic. But, also, anything we do is going to potentially run into > > contention problems. *shrug* If we were going to go for > > one-per-HW-engine, we may as well go one-per-device and then we wouldn't > > need the lock. Off the top of my head, that doesn't sound great either > > but IDK. > > > > As far as this being horrible, well didn't design the GuC and this how > > it is implemented for KMD based
Re: [PATCH v5 10/12] arm64: dts: qcom: sc8280xp: Define some of the display blocks
On 08/12/2022 00:00, Bjorn Andersson wrote:
From: Bjorn Andersson
Define the display clock controllers, the MDSS instances, the DP phys
and connect these together.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
Changes since v4:
- None
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 838 +
1 file changed, 838 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index 9f3132ac2857..c2f186495506 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -4,6 +4,7 @@
* Copyright (c) 2022, Linaro Limited
*/
+#include
#include
#include
#include
@@ -1698,6 +1699,44 @@ usb_1_qmpphy: phy@8903000 {
status = "disabled";
};
+ mdss1_dp0_phy: phy@8909a00 {
+ compatible = "qcom,sc8280xp-dp-phy";
+ reg = <0 0x08909a00 0 0x19c>,
+ <0 0x08909200 0 0xec>,
+ <0 0x08909600 0 0xec>,
+ <0 0x08909000 0 0x1c8>;
+
+ clocks = < DISP_CC_MDSS_DPTX0_AUX_CLK>,
+< DISP_CC_MDSS_AHB_CLK>;
+ clock-names = "aux", "cfg_ahb";
+
+ power-domains = < SC8280XP_MX>;
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ mdss1_dp1_phy: phy@890ca00 {
+ compatible = "qcom,sc8280xp-dp-phy";
+ reg = <0 0x0890ca00 0 0x19c>,
+ <0 0x0890c200 0 0xec>,
+ <0 0x0890c600 0 0xec>,
+ <0 0x0890c000 0 0x1c8>;
+
+ clocks = < DISP_CC_MDSS_DPTX1_AUX_CLK>,
+< DISP_CC_MDSS_AHB_CLK>;
+ clock-names = "aux", "cfg_ahb";
+
+ power-domains = < SC8280XP_MX>;
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
system-cache-controller@920 {
compatible = "qcom,sc8280xp-llcc";
reg = <0 0x0920 0 0x58000>, <0 0x0960 0
0x58000>;
@@ -1813,6 +1852,326 @@ usb_1_dwc3: usb@a80 {
};
};
+ mdss0: display-subsystem@ae0 {
+ compatible = "qcom,sc8280xp-mdss";
+ reg = <0 0x0ae0 0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = < MDSS_GDSC>;
+
+ clocks = < GCC_DISP_AHB_CLK>,
+< DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "ahb",
+ "core";
+
+ resets = < DISP_CC_MDSS_CORE_BCR>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <_noc MASTER_MDP0 0 _virt
SLAVE_EBI1 0>,
+ <_noc MASTER_MDP1 0 _virt
SLAVE_EBI1 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ iommus = <_smmu 0x1000 0x402>;
+
+ status = "disabled";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ mdss0_mdp: display-controller@ae01000 {
+ compatible = "qcom,sc8280xp-dpu";
+ reg = <0 0x0ae01000 0 0x8f000>,
+ <0 0x0aeb 0 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = < GCC_DISP_HF_AXI_CLK>,
+< GCC_DISP_SF_AXI_CLK>,
+< DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_MDP_LUT_CLK>,
+< DISP_CC_MDSS_MDP_CLK>,
+< DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <
DISP_CC_MDSS_MDP_CLK>,
+ <
DISP_CC_MDSS_VSYNC_CLK>;
+
Re: [PATCH v8 2/3] dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis
On 17/01/2023 00:52, Bryan O'Donoghue wrote: Each compatible has a different set of clocks which are associated with it. Add in the list of clocks for each compatible. Acked-by: Rob Herring Acked-by: Krzysztof Kozlowski Signed-off-by: Bryan O'Donoghue --- .../display/msm/dsi-controller-main.yaml | 219 -- 1 file changed, 202 insertions(+), 17 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 35668caa190c4..47faf08a37443 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml [skipped] + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8974-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: mdp_core +- const: iface +- const: bus +- const: vsync vsync clock is not used on msm8974 platform, it causes DT verification errors. +- const: byte +- const: pixel +- const: core +- const: core_mmss +-- With best wishes Dmitry
Re: [PATCH v8 2/3] dt-bindings: msm: dsi-controller-main: Document clocks on a per compatible basis
On 17/01/2023 00:52, Bryan O'Donoghue wrote: Each compatible has a different set of clocks which are associated with it. Add in the list of clocks for each compatible. Acked-by: Rob Herring Acked-by: Krzysztof Kozlowski Signed-off-by: Bryan O'Donoghue --- .../display/msm/dsi-controller-main.yaml | 219 -- 1 file changed, 202 insertions(+), 17 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 35668caa190c4..47faf08a37443 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -9,9 +9,6 @@ title: Qualcomm Display DSI controller maintainers: - Krishna Manikandan -allOf: - - $ref: "../dsi-controller.yaml#" - properties: compatible: oneOf: @@ -50,22 +47,23 @@ properties: maxItems: 1 clocks: -items: - - description: Display byte clock - - description: Display byte interface clock - - description: Display pixel clock - - description: Display core clock - - description: Display AHB clock - - description: Display AXI clock +description: | + Several clocks are used, depending on the variant. Typical ones are:: + - bus:: Display AHB clock. + - byte:: Display byte clock. + - byte_intf:: Display byte interface clock. + - core:: Display core clock. + - core_mss:: Core MultiMedia SubSystem clock. + - iface:: Display AXI clock. + - mdp_core:: MDP Core clock. + - mnoc:: MNOC clock + - pixel:: Display pixel clock. +minItems: 3 +maxItems: 9 clock-names: -items: - - const: byte - - const: byte_intf - - const: pixel - - const: core - - const: iface - - const: bus +minItems: 3 +maxItems: 9 phys: maxItems: 1 @@ -161,6 +159,193 @@ required: - assigned-clock-parents - ports +allOf: + - $ref: ../dsi-controller.yaml# + - if: + properties: +compatible: + contains: +enum: + - qcom,apq8064-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: iface +- const: bus +- const: core_mmss +- const: src +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8916-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: mdp_core +- const: iface +- const: bus +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8953-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: mdp_core +- const: iface +- const: bus +- const: byte +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8974-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: mdp_core +- const: iface +- const: bus +- const: vsync +- const: byte +- const: pixel +- const: core +- const: core_mmss + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8996-dsi-ctrl +then: + properties: +clocks: + maxItems: 7 +clock-names: + items: +- const: mdp_core +- const: byte +- const: iface +- const: bus +- const: core_mmss +- const: pixel +- const: core + + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8998-dsi-ctrl +then: + properties: +clocks: + maxItems: 6 +clock-names: + items: +- const: byte +- const: byte_intf +- const: pixel +- const: core +- const: iface +- const: bus + + - if: + properties: +compatible: + contains: +enum: + - qcom,sc7180-dsi-ctrl + - qcom,sc7280-dsi-ctrl + - qcom,sm8250-dsi-ctrl + - qcom,sm8150-dsi-ctrl + - qcom,sm8250-dsi-ctrl Fails with:
Re: [PATCH v6 04/11] dt-bindings: display/msm: rename mdss nodes to display-subsystem
On 13/01/2023 17:26, Rob Herring wrote:
On Fri, 13 Jan 2023 10:37:13 +0200, Dmitry Baryshkov wrote:
Follow the 'generic names' rule and rename mdss nodes to
display-subsystem.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/mdss-common.yaml | 8
.../devicetree/bindings/display/msm/qcom,mdss.yaml| 5 -
2 files changed, 12 insertions(+), 1 deletion(-)
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.example.dtb:
mdss@5e0: $nodename:0: 'mdss@5e0' does not match
'^display-subsystem@[0-9a-f]+$'
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.example.dtb:
mdss@5e0: $nodename:0: 'mdss@5e0' does not match
'^display-subsystem@[0-9a-f]+$'
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
This should be fixed already by the commit e5266ca38294 ("dt-bindings:
display: msm: Rename mdss node name in example")
See https://gitlab.freedesktop.org/drm/msm/-/commit/e5266ca38294
--
With best wishes
Dmitry
Re: [PATCH] drm/msm/dpu: Reapply CTM if modeset is needed
On Wed, 18 Jan 2023 at 04:14, Jessica Zhang wrote:
>
> Add a !drm_atomic_crtc_needs_modeset() check to
> _dpu_crtc_setup_cp_blocks() so that CTM is reapplied after a
> suspend/resume.
.. or if the LM/DSPP blocks were reallocated by resource allocation
during the modeset.
>
> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/23
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 13ce321283ff..aa120a230222 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -748,7 +748,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc
> *crtc)
> int i;
>
>
> - if (!state->color_mgmt_changed)
> + if (!state->color_mgmt_changed &&
> !drm_atomic_crtc_needs_modeset(state))
> return;
>
> for (i = 0; i < cstate->num_mixers; i++) {
> --
> 2.39.0
>
--
With best wishes
Dmitry
[PATCH] drm/msm/dpu: Reapply CTM if modeset is needed
Add a !drm_atomic_crtc_needs_modeset() check to
_dpu_crtc_setup_cp_blocks() so that CTM is reapplied after a
suspend/resume.
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/23
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 13ce321283ff..aa120a230222 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -748,7 +748,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc *crtc)
int i;
- if (!state->color_mgmt_changed)
+ if (!state->color_mgmt_changed && !drm_atomic_crtc_needs_modeset(state))
return;
for (i = 0; i < cstate->num_mixers; i++) {
--
2.39.0
Re: [PATCH 2/2] drm/msm/dpu: use sm8350_regdma on SM8350 platform
On 1/17/2023 6:09 PM, Abhinav Kumar wrote:
On 1/17/2023 6:04 PM, Dmitry Baryshkov wrote:
Correct sm8350_dpu_cfg.dma_cfg to point to sm8350_regdma rather than
sm8250_regdma.
Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 3d0fbc1746e2..e6618e678384 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2737,7 +2737,7 @@ static const struct dpu_mdss_cfg sm8350_dpu_cfg = {
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
Since you are adding the .dma_cfg, lets stick to the convention of the
rest of the entries and use ARRAY_SIZE.
Since reg_dma is not an array yet,
Reviewed-by: Abhinav Kumar
- .dma_cfg = _regdma,
+ .dma_cfg = _regdma,
.perf = _perf_data,
.mdss_irqs = IRQ_SM8350_MASK,
};
Re: [PATCH 1/2] drm/msm/dpu: point sc8280xp_dpu_cfg to sc8280xp_regdma
On 1/17/2023 6:09 PM, Dmitry Baryshkov wrote:
On 18/01/2023 04:08, Abhinav Kumar wrote:
On 1/17/2023 6:04 PM, Dmitry Baryshkov wrote:
SC8280XP configuration missed the reg_dma configuration. We do not use
regdma for now, but let's put the correct pointer anyway.
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 4375e72a9aab..3d0fbc1746e2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2680,6 +2680,8 @@ static const struct dpu_mdss_cfg
sc8280xp_dpu_cfg = {
.intf = sc8280xp_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
+ .reg_dma_count = 1,
Lets stick to the convention of the rest of the entries and use
ARRAY_SIZE.
regdma is not an array, so all platforms use 1 here. We should probably
change this, as some of newer platforms seem to have two regdma blocks,
but I haven't taken a look into that.
Ah ack, then this is fine. We should probably change that though,
Reviewed-by: Abhinav Kumar
+ .dma_cfg = _regdma,
.perf = _perf_data,
.mdss_irqs = IRQ_SC8280XP_MASK,
};
Re: [PATCH] drm/msm/dpu: add missing dpu_encoder kerneldoc
On 1/17/2023 6:05 PM, Dmitry Baryshkov wrote:
Describe missing dpu_encoder_phys_wb_is_master() argument and struct
dpu_encoder_virt.wide_bus_en field.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index d1a528ff0f28..758261e8ac73 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -162,6 +162,7 @@ enum dpu_enc_rc_states {
* @vsync_event_work: worker to handle vsync event for autorefresh
* @topology: topology of the display
* @idle_timeout: idle timeout duration in milliseconds
+ * @wide_bus_en: wide bus is enabled on this interface
* @dsc: drm_dsc_config pointer, for DSC-enabled encoders
*/
struct dpu_encoder_virt {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 95921efd8139..bac4aa807b4b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -26,6 +26,7 @@
/**
* dpu_encoder_phys_wb_is_master - report wb always as master encoder
+ * @phys_enc: Pointer to physical encoder
*/
static bool dpu_encoder_phys_wb_is_master(struct dpu_encoder_phys *phys_enc)
{
Re: [PATCH 1/2] drm/msm/dpu: point sc8280xp_dpu_cfg to sc8280xp_regdma
On 18/01/2023 04:08, Abhinav Kumar wrote:
On 1/17/2023 6:04 PM, Dmitry Baryshkov wrote:
SC8280XP configuration missed the reg_dma configuration. We do not use
regdma for now, but let's put the correct pointer anyway.
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 4375e72a9aab..3d0fbc1746e2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2680,6 +2680,8 @@ static const struct dpu_mdss_cfg
sc8280xp_dpu_cfg = {
.intf = sc8280xp_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
+ .reg_dma_count = 1,
Lets stick to the convention of the rest of the entries and use ARRAY_SIZE.
regdma is not an array, so all platforms use 1 here. We should probably
change this, as some of newer platforms seem to have two regdma blocks,
but I haven't taken a look into that.
+ .dma_cfg = _regdma,
.perf = _perf_data,
.mdss_irqs = IRQ_SC8280XP_MASK,
};
--
With best wishes
Dmitry
Re: [PATCH 2/2] drm/msm/dpu: use sm8350_regdma on SM8350 platform
On 1/17/2023 6:04 PM, Dmitry Baryshkov wrote:
Correct sm8350_dpu_cfg.dma_cfg to point to sm8350_regdma rather than
sm8250_regdma.
Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 3d0fbc1746e2..e6618e678384 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2737,7 +2737,7 @@ static const struct dpu_mdss_cfg sm8350_dpu_cfg = {
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
.reg_dma_count = 1,
Since you are adding the .dma_cfg, lets stick to the convention of the
rest of the entries and use ARRAY_SIZE.
- .dma_cfg = _regdma,
+ .dma_cfg = _regdma,
.perf = _perf_data,
.mdss_irqs = IRQ_SM8350_MASK,
};
Re: [PATCH 1/2] drm/msm/dpu: point sc8280xp_dpu_cfg to sc8280xp_regdma
On 1/17/2023 6:04 PM, Dmitry Baryshkov wrote:
SC8280XP configuration missed the reg_dma configuration. We do not use
regdma for now, but let's put the correct pointer anyway.
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 4375e72a9aab..3d0fbc1746e2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2680,6 +2680,8 @@ static const struct dpu_mdss_cfg sc8280xp_dpu_cfg = {
.intf = sc8280xp_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
.vbif = sdm845_vbif,
+ .reg_dma_count = 1,
Lets stick to the convention of the rest of the entries and use ARRAY_SIZE.
+ .dma_cfg = _regdma,
.perf = _perf_data,
.mdss_irqs = IRQ_SC8280XP_MASK,
};
Re: [PATCH 1/2] dt-bindings: display/msm: Add SM6375 DSI PHY
On Mon, 16 Jan 2023 12:40:58 +0100, Konrad Dybcio wrote: > SM6375 has a single 7nm DSI PHY. Document it. > > Applied, thanks! [1/2] dt-bindings: display/msm: Add SM6375 DSI PHY https://gitlab.freedesktop.org/lumag/msm/-/commit/f8e6d45c8152 [2/2] drm/msm/dsi: Add phy configuration for SM6375 https://gitlab.freedesktop.org/lumag/msm/-/commit/88f46d2ccdf0 Best regards, -- Dmitry Baryshkov
Re: [PATCH v3 1/2] drm/msm/dsi: add a helper method to compute the dsi byte clk
On Wed, 11 Jan 2023 16:15:59 -0800, Abhinav Kumar wrote: > Re-arrange the dsi_calc_pclk method to two helpers, one to > compute the DSI byte clk and the other to compute the pclk. > > This makes the separation of the two clean and also allows > clients to compute and use the dsi byte clk separately. > > changes in v2: > - move the assignments to definition lines > > [...] Applied, thanks! [1/2] drm/msm/dsi: add a helper method to compute the dsi byte clk https://gitlab.freedesktop.org/lumag/msm/-/commit/8b054353375c [2/2] drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid() https://gitlab.freedesktop.org/lumag/msm/-/commit/adc5d0f5af8d Best regards, -- Dmitry Baryshkov
Re: [PATCH] drm/msm/dp: Remove INIT_SETUP delay
On Tue, 17 Jan 2023 09:29:51 -0800, Bjorn Andersson wrote: > During initalization of the DisplayPort controller an EV_HPD_INIT_SETUP > event is generated, but with a delay of 100 units. This delay existed to > circumvent bug in the QMP combo PHY driver, where if the DP part was > powered up before USB, the common properties would not be properly > initialized - and USB wouldn't work. > > This issue was resolved in the recent refactoring of the QMP driver, > so it's now possible to remove this delay. > > [...] Applied, thanks! [1/1] drm/msm/dp: Remove INIT_SETUP delay https://gitlab.freedesktop.org/lumag/msm/-/commit/e17af1c9d861 Best regards, -- Dmitry Baryshkov
Re: [PATCH v2] drm/msm: Add missing check and destroy for alloc_ordered_workqueue
On Mon, 09 Jan 2023 10:20:38 +0800, Jiasheng Jiang wrote: > Add check for the return value of alloc_ordered_workqueue as it may return > NULL pointer. > Moreover, use the destroy_workqueue in the later fails in order to avoid > memory leak. > > Applied, thanks! [1/1] drm/msm: Add missing check and destroy for alloc_ordered_workqueue https://gitlab.freedesktop.org/lumag/msm/-/commit/643b7d0869cc Best regards, -- Dmitry Baryshkov
Re: [PATCH] dt-bindings: msm/dsi: Don't require vdds-supply on 7nm PHY
On Mon, 16 Jan 2023 12:51:32 +0100, Konrad Dybcio wrote: > On some SoCs (hello SM6375) vdds-supply is not wired to any smd-rpm > or rpmh regulator, but instead powered by the VDD_MX/mx.lvl line, > which is voted for in the DSI ctrl node. > > Applied, thanks! [1/1] dt-bindings: msm/dsi: Don't require vdds-supply on 7nm PHY https://gitlab.freedesktop.org/lumag/msm/-/commit/4ff00ebb193a Best regards, -- Dmitry Baryshkov
Re: [PATCH v3] drm/msm/dpu: Disallow unallocated resources to be returned
On Tue, 10 Jan 2023 00:15:55 +0100, Marijn Suijten wrote: > In the event that the topology requests resources that have not been > created by the system (because they are typically not represented in > dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC > blocks, until their allocation/assignment is being sanity-checked in > "drm/msm/dpu: Reject topologies for which no DSC blocks are available") > remain NULL but will still be returned out of > dpu_rm_get_assigned_resources, where the caller expects to get an array > containing num_blks valid pointers (but instead gets these NULLs). > > [...] Applied, thanks! [1/1] drm/msm/dpu: Disallow unallocated resources to be returned https://gitlab.freedesktop.org/lumag/msm/-/commit/abc40122d9a6 Best regards, -- Dmitry Baryshkov
Re: [PATCH 1/3] dt-bindings: display/msm: Add SM8150 MDSS & DPU
On Mon, 12 Dec 2022 10:33:12 +0100, Konrad Dybcio wrote: > Add bindings for the display hardware on SM8150. > > Applied, thanks! [1/3] dt-bindings: display/msm: Add SM8150 MDSS & DPU https://gitlab.freedesktop.org/lumag/msm/-/commit/9ffbefc1553c Best regards, -- Dmitry Baryshkov
Re: [PATCH v3] drm/msm/dsi: Add missing check for alloc_ordered_workqueue
On Tue, 10 Jan 2023 10:16:51 +0800, Jiasheng Jiang wrote: > Add check for the return value of alloc_ordered_workqueue as it may return > NULL pointer and cause NULL pointer dereference. > > Applied, thanks! [1/1] drm/msm/dsi: Add missing check for alloc_ordered_workqueue https://gitlab.freedesktop.org/lumag/msm/-/commit/e5237cd6ad68 Best regards, -- Dmitry Baryshkov
Re: [PATCH v2] drm/msm/dsi: Drop the redundant fail label
On Wed, 11 Jan 2023 09:10:06 +0800, Jiasheng Jiang wrote: > Drop the redundant fail label and change the "goto fail" into "return ret" > since they are the same. > > Applied, thanks! [1/1] drm/msm/dsi: Drop the redundant fail label https://gitlab.freedesktop.org/lumag/msm/-/commit/dc57f09acc34 Best regards, -- Dmitry Baryshkov
