From: Danilo Krummrich <dakr@redhat.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de,
mripard@kernel.org, corbet@lwn.net, christian.koenig@amd.com,
bskeggs@redhat.com, matthew.brost@intel.com,
boris.brezillon@collabora.com, alexdeucher@gmail.com,
ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org,
jason@jlekstrand.net, dri-devel@lists.freedesktop.org,
nouveau@lists.freedesktop.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings
Date: Tue, 28 Feb 2023 03:17:15 +0100 [thread overview]
Message-ID: <63fd642e.170a0220.f67f6.e248@mx.google.com> (raw)
In-Reply-To: <20230221182050.day6z5ge2e3dxerv@revolver>
[-- Attachment #1: Type: text/plain, Size: 4539 bytes --]
On Tue, Feb 21, 2023 at 01:20:50PM -0500, Liam R. Howlett wrote:
> * Danilo Krummrich <dakr@redhat.com> [230217 08:45]:
> > Add infrastructure to keep track of GPU virtual address (VA) mappings
> > with a decicated VA space manager implementation.
> >
> > 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 infrastructure to track GPU VA allocations and mappings,
> > making use of the maple_tree.
> >
> > 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.
> >
> > Suggested-by: Dave Airlie <airlied@redhat.com>
> > Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> > ---
> > 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 | 1704 +++++++++++++++++++++++++++++++
> > include/drm/drm_drv.h | 6 +
> > include/drm/drm_gem.h | 75 ++
> > include/drm/drm_gpuva_mgr.h | 714 +++++++++++++
> > 7 files changed, 2534 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_gpuva_remove_iter - removes the iterators current element
> > + * @it: the &drm_gpuva_iterator
> > + *
> > + * This removes the element the iterator currently points to.
> > + */
> > +void
> > +drm_gpuva_iter_remove(struct drm_gpuva_iterator *it)
> > +{
> > + mas_erase(&it->mas);
> > +}
> > +EXPORT_SYMBOL(drm_gpuva_iter_remove);
> > +
> > +/**
> > + * drm_gpuva_insert - insert a &drm_gpuva
> > + * @mgr: the &drm_gpuva_manager to insert the &drm_gpuva in
> > + * @va: the &drm_gpuva to insert
> > + * @addr: the start address of the GPU VA
> > + * @range: the range of the GPU VA
> > + *
> > + * Insert a &drm_gpuva with a given address and range into a
> > + * &drm_gpuva_manager.
> > + *
> > + * Returns: 0 on success, negative error code on failure.
> > + */
> > +int
> > +drm_gpuva_insert(struct drm_gpuva_manager *mgr,
> > + struct drm_gpuva *va)
> > +{
> > + u64 addr = va->va.addr;
> > + u64 range = va->va.range;
> > + MA_STATE(mas, &mgr->va_mt, addr, addr + range - 1);
> > + struct drm_gpuva_region *reg = NULL;
> > + int ret;
> > +
> > + if (unlikely(!drm_gpuva_in_mm_range(mgr, addr, range)))
> > + return -EINVAL;
> > +
> > + if (unlikely(drm_gpuva_in_kernel_region(mgr, addr, range)))
> > + return -EINVAL;
> > +
> > + if (mgr->flags & DRM_GPUVA_MANAGER_REGIONS) {
> > + reg = drm_gpuva_in_region(mgr, addr, range);
> > + if (unlikely(!reg))
> > + return -EINVAL;
> > + }
> > +
>
> -----
>
> > + if (unlikely(drm_gpuva_find_first(mgr, addr, range)))
> > + return -EEXIST;
> > +
> > + ret = mas_store_gfp(&mas, va, GFP_KERNEL);
>
> mas_walk() will set the internal maple state to the limits to what it
> finds. So, instead of an iterator, you can use the walk function and
> ensure there is a large enough area in the existing NULL:
>
> /*
> * Nothing at addr, mas now points to the location where the store would
> * happen
> */
> if (mas_walk(&mas))
> return -EEXIST;
>
For some reason mas_walk() finds an entry and hence this function returns
-EEXIST for the following sequence of insertions.
A = [0xc0000 - 0xfffff]
B = [0x0 - 0xbffff]
Interestingly, inserting B before A works fine.
I attached a test module that reproduces the issue. I hope its just a stupid
mistake I just can't spot though.
> /* The NULL entry ends at mas.last, make sure there is room */
> if (mas.last < (addr + range - 1))
> return -EEXIST;
>
> /* Limit the store size to the correct end address, and store */
> mas.last = addr + range - 1;
> ret = mas_store_gfp(&mas, va, GFP_KERNEL);
>
[-- Attachment #2: maple.c --]
[-- Type: text/x-c, Size: 1954 bytes --]
/* SPDX-License-Identifier: GPL-2.0 */
#if 1
#include <linux/init.h>
#include <linux/ioctl.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/maple_tree.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/mutex.h>
#include <linux/printk.h>
#include <linux/proc_fs.h>
#include <linux/slab.h>
#include <linux/types.h>
#endif
struct maple_tree mt;
struct va {
u64 addr;
u64 range;
};
static int va_store(struct va *va)
{
void *entry = NULL;
u64 addr = va->addr;
u64 range = va->range;
u64 last = addr + range - 1;
MA_STATE(mas, &mt, addr, addr);
int ret;
mas_lock(&mas);
if ((entry = mas_walk(&mas))) {
pr_err("addr=%llx, range=%llx, last=%llx, mas.index=%lx, mas.last=%lx, entry=%px - exists\n",
addr, range, last, mas.index, mas.last, entry);
ret = -EEXIST;
goto err_unlock;
}
if (mas.last < last) {
pr_err("addr=%llx, range=%llx, last=%llx, mas.index=%lx, mas.last%lx, va=%px - not enough space\n",
addr, range, last, mas.index, mas.last, va);
ret = -EEXIST;
goto err_unlock;
}
mas.last = last;
ret = mas_store_gfp(&mas, &va, GFP_KERNEL);
if (ret) {
pr_err("mas_store_gfp() failed\n");
goto err_unlock;
}
mas_unlock(&mas);
pr_info("addr=%llx, range=%llx, last=%llx, mas.index=%lx, mas.last=%lx, va=%px - insert\n",
addr, range, last, mas.index, mas.last, va);
return 0;
err_unlock:
mas_unlock(&mas);
return ret;
}
static int __init maple_init(void)
{
struct va kernel_node = { .addr = 0xc0000, .range = 0x40000 };
struct va node = { .addr = 0x0, .range = 0xc0000 };
mt_init(&mt);
va_store(&kernel_node);
va_store(&node);
return 0;
}
static void __exit maple_exit(void)
{
mtree_lock(&mt);
__mt_destroy(&mt);
mtree_unlock(&mt);
}
module_init(maple_init);
module_exit(maple_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Danilo Krummrich");
MODULE_DESCRIPTION("Maple Tree example.");
MODULE_VERSION("0.1");
WARNING: multiple messages have this Message-ID (diff)
From: Danilo Krummrich <dakr@redhat.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de,
mripard@kernel.org, corbet@lwn.net, christian.koenig@amd.com,
bskeggs@redhat.com, matthew.brost@intel.com,
boris.brezillon@collabora.com, alexdeucher@gmail.com,
ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org,
jason@jlekstrand.net, dri-devel@lists.freedesktop.org,
nouveau@lists.freedesktop.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Dave Airlie <airlied@redhat.com>
Subject: Re: [Nouveau] [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings
Date: Tue, 28 Feb 2023 03:17:15 +0100 [thread overview]
Message-ID: <63fd642e.170a0220.f67f6.e248@mx.google.com> (raw)
In-Reply-To: <20230221182050.day6z5ge2e3dxerv@revolver>
[-- Attachment #1: Type: text/plain, Size: 4539 bytes --]
On Tue, Feb 21, 2023 at 01:20:50PM -0500, Liam R. Howlett wrote:
> * Danilo Krummrich <dakr@redhat.com> [230217 08:45]:
> > Add infrastructure to keep track of GPU virtual address (VA) mappings
> > with a decicated VA space manager implementation.
> >
> > 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 infrastructure to track GPU VA allocations and mappings,
> > making use of the maple_tree.
> >
> > 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.
> >
> > Suggested-by: Dave Airlie <airlied@redhat.com>
> > Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> > ---
> > 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 | 1704 +++++++++++++++++++++++++++++++
> > include/drm/drm_drv.h | 6 +
> > include/drm/drm_gem.h | 75 ++
> > include/drm/drm_gpuva_mgr.h | 714 +++++++++++++
> > 7 files changed, 2534 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_gpuva_remove_iter - removes the iterators current element
> > + * @it: the &drm_gpuva_iterator
> > + *
> > + * This removes the element the iterator currently points to.
> > + */
> > +void
> > +drm_gpuva_iter_remove(struct drm_gpuva_iterator *it)
> > +{
> > + mas_erase(&it->mas);
> > +}
> > +EXPORT_SYMBOL(drm_gpuva_iter_remove);
> > +
> > +/**
> > + * drm_gpuva_insert - insert a &drm_gpuva
> > + * @mgr: the &drm_gpuva_manager to insert the &drm_gpuva in
> > + * @va: the &drm_gpuva to insert
> > + * @addr: the start address of the GPU VA
> > + * @range: the range of the GPU VA
> > + *
> > + * Insert a &drm_gpuva with a given address and range into a
> > + * &drm_gpuva_manager.
> > + *
> > + * Returns: 0 on success, negative error code on failure.
> > + */
> > +int
> > +drm_gpuva_insert(struct drm_gpuva_manager *mgr,
> > + struct drm_gpuva *va)
> > +{
> > + u64 addr = va->va.addr;
> > + u64 range = va->va.range;
> > + MA_STATE(mas, &mgr->va_mt, addr, addr + range - 1);
> > + struct drm_gpuva_region *reg = NULL;
> > + int ret;
> > +
> > + if (unlikely(!drm_gpuva_in_mm_range(mgr, addr, range)))
> > + return -EINVAL;
> > +
> > + if (unlikely(drm_gpuva_in_kernel_region(mgr, addr, range)))
> > + return -EINVAL;
> > +
> > + if (mgr->flags & DRM_GPUVA_MANAGER_REGIONS) {
> > + reg = drm_gpuva_in_region(mgr, addr, range);
> > + if (unlikely(!reg))
> > + return -EINVAL;
> > + }
> > +
>
> -----
>
> > + if (unlikely(drm_gpuva_find_first(mgr, addr, range)))
> > + return -EEXIST;
> > +
> > + ret = mas_store_gfp(&mas, va, GFP_KERNEL);
>
> mas_walk() will set the internal maple state to the limits to what it
> finds. So, instead of an iterator, you can use the walk function and
> ensure there is a large enough area in the existing NULL:
>
> /*
> * Nothing at addr, mas now points to the location where the store would
> * happen
> */
> if (mas_walk(&mas))
> return -EEXIST;
>
For some reason mas_walk() finds an entry and hence this function returns
-EEXIST for the following sequence of insertions.
A = [0xc0000 - 0xfffff]
B = [0x0 - 0xbffff]
Interestingly, inserting B before A works fine.
I attached a test module that reproduces the issue. I hope its just a stupid
mistake I just can't spot though.
> /* The NULL entry ends at mas.last, make sure there is room */
> if (mas.last < (addr + range - 1))
> return -EEXIST;
>
> /* Limit the store size to the correct end address, and store */
> mas.last = addr + range - 1;
> ret = mas_store_gfp(&mas, va, GFP_KERNEL);
>
[-- Attachment #2: maple.c --]
[-- Type: text/x-c, Size: 1954 bytes --]
/* SPDX-License-Identifier: GPL-2.0 */
#if 1
#include <linux/init.h>
#include <linux/ioctl.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/maple_tree.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/mutex.h>
#include <linux/printk.h>
#include <linux/proc_fs.h>
#include <linux/slab.h>
#include <linux/types.h>
#endif
struct maple_tree mt;
struct va {
u64 addr;
u64 range;
};
static int va_store(struct va *va)
{
void *entry = NULL;
u64 addr = va->addr;
u64 range = va->range;
u64 last = addr + range - 1;
MA_STATE(mas, &mt, addr, addr);
int ret;
mas_lock(&mas);
if ((entry = mas_walk(&mas))) {
pr_err("addr=%llx, range=%llx, last=%llx, mas.index=%lx, mas.last=%lx, entry=%px - exists\n",
addr, range, last, mas.index, mas.last, entry);
ret = -EEXIST;
goto err_unlock;
}
if (mas.last < last) {
pr_err("addr=%llx, range=%llx, last=%llx, mas.index=%lx, mas.last%lx, va=%px - not enough space\n",
addr, range, last, mas.index, mas.last, va);
ret = -EEXIST;
goto err_unlock;
}
mas.last = last;
ret = mas_store_gfp(&mas, &va, GFP_KERNEL);
if (ret) {
pr_err("mas_store_gfp() failed\n");
goto err_unlock;
}
mas_unlock(&mas);
pr_info("addr=%llx, range=%llx, last=%llx, mas.index=%lx, mas.last=%lx, va=%px - insert\n",
addr, range, last, mas.index, mas.last, va);
return 0;
err_unlock:
mas_unlock(&mas);
return ret;
}
static int __init maple_init(void)
{
struct va kernel_node = { .addr = 0xc0000, .range = 0x40000 };
struct va node = { .addr = 0x0, .range = 0xc0000 };
mt_init(&mt);
va_store(&kernel_node);
va_store(&node);
return 0;
}
static void __exit maple_exit(void)
{
mtree_lock(&mt);
__mt_destroy(&mt);
mtree_unlock(&mt);
}
module_init(maple_init);
module_exit(maple_exit);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Danilo Krummrich");
MODULE_DESCRIPTION("Maple Tree example.");
MODULE_VERSION("0.1");
next prev parent reply other threads:[~2023-02-28 2:18 UTC|newest]
Thread overview: 188+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 13:44 [PATCH drm-next v2 00/16] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI Danilo Krummrich
2023-02-17 13:44 ` Danilo Krummrich
2023-02-17 13:44 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:44 ` [PATCH drm-next v2 01/16] drm: execution context for GEM buffers Danilo Krummrich
2023-02-17 13:44 ` Danilo Krummrich
2023-02-17 13:44 ` [Nouveau] " Danilo Krummrich
2023-02-17 16:00 ` Christian König
2023-02-17 16:00 ` Christian König
2023-02-17 16:00 ` [Nouveau] " Christian König
2023-02-21 14:56 ` Danilo Krummrich
2023-02-21 14:56 ` Danilo Krummrich
2023-02-21 14:56 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:44 ` [PATCH drm-next v2 02/16] drm/exec: fix memory leak in drm_exec_prepare_obj() Danilo Krummrich
2023-02-17 13:44 ` Danilo Krummrich
2023-02-17 13:44 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:44 ` [PATCH drm-next v2 03/16] maple_tree: split up MA_STATE() macro Danilo Krummrich
2023-02-17 13:44 ` Danilo Krummrich
2023-02-17 13:44 ` [Nouveau] " Danilo Krummrich
2023-02-17 18:34 ` Liam R. Howlett
2023-02-17 18:34 ` Liam R. Howlett
2023-02-17 18:34 ` [Nouveau] " Liam R. Howlett
2023-02-20 13:48 ` Danilo Krummrich
2023-02-20 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-21 16:52 ` Liam R. Howlett
2023-02-21 16:52 ` Liam R. Howlett
2023-02-21 16:52 ` [Nouveau] " Liam R. Howlett
2023-02-17 19:45 ` Matthew Wilcox
2023-02-17 19:45 ` Matthew Wilcox
2023-02-17 19:45 ` [Nouveau] " Matthew Wilcox
2023-02-20 13:48 ` Danilo Krummrich
2023-02-20 13:48 ` Danilo Krummrich
2023-02-20 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:44 ` [PATCH drm-next v2 04/16] maple_tree: add flag MT_FLAGS_LOCK_NONE Danilo Krummrich
2023-02-17 13:44 ` Danilo Krummrich
2023-02-17 13:44 ` [Nouveau] " Danilo Krummrich
2023-02-17 18:18 ` Liam R. Howlett
2023-02-17 18:18 ` Liam R. Howlett
2023-02-17 18:18 ` [Nouveau] " Liam R. Howlett
2023-02-17 19:38 ` Matthew Wilcox
2023-02-17 19:38 ` Matthew Wilcox
2023-02-17 19:38 ` [Nouveau] " Matthew Wilcox
2023-02-20 14:00 ` Danilo Krummrich
2023-02-20 14:00 ` Danilo Krummrich
2023-02-20 14:00 ` [Nouveau] " Danilo Krummrich
2023-02-20 15:10 ` Matthew Wilcox
2023-02-20 15:10 ` Matthew Wilcox
2023-02-20 15:10 ` [Nouveau] " Matthew Wilcox
2023-02-20 17:06 ` Danilo Krummrich
2023-02-20 17:06 ` Danilo Krummrich
2023-02-20 17:06 ` [Nouveau] " Danilo Krummrich
2023-02-20 20:33 ` Matthew Wilcox
2023-02-20 20:33 ` Matthew Wilcox
2023-02-20 20:33 ` [Nouveau] " Matthew Wilcox
2023-02-21 14:37 ` Danilo Krummrich
2023-02-21 14:37 ` Danilo Krummrich
2023-02-21 14:37 ` [Nouveau] " Danilo Krummrich
2023-02-21 18:31 ` Matthew Wilcox
2023-02-21 18:31 ` Matthew Wilcox
2023-02-21 18:31 ` [Nouveau] " Matthew Wilcox
2023-02-22 16:11 ` Danilo Krummrich
2023-02-22 16:11 ` Danilo Krummrich
2023-02-22 16:11 ` [Nouveau] " Danilo Krummrich
2023-02-22 16:32 ` Matthew Wilcox
2023-02-22 16:32 ` Matthew Wilcox
2023-02-22 16:32 ` [Nouveau] " Matthew Wilcox
2023-02-22 17:28 ` Danilo Krummrich
2023-02-22 17:28 ` Danilo Krummrich
2023-02-22 17:28 ` [Nouveau] " Danilo Krummrich
2023-02-27 17:39 ` Danilo Krummrich
2023-02-27 17:39 ` Danilo Krummrich
2023-02-27 17:39 ` [Nouveau] " Danilo Krummrich
2023-02-27 18:36 ` Matthew Wilcox
2023-02-27 18:36 ` Matthew Wilcox
2023-02-27 18:36 ` [Nouveau] " Matthew Wilcox
2023-02-27 18:59 ` Danilo Krummrich
2023-02-27 18:59 ` Danilo Krummrich
2023-02-27 18:59 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:44 ` [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings Danilo Krummrich
2023-02-17 13:44 ` Danilo Krummrich
2023-02-17 13:44 ` [Nouveau] " Danilo Krummrich
2023-02-18 1:05 ` kernel test robot
2023-02-18 1:05 ` kernel test robot
2023-02-18 1:05 ` [Nouveau] " kernel test robot
2023-02-21 18:20 ` Liam R. Howlett
2023-02-21 18:20 ` Liam R. Howlett
2023-02-21 18:20 ` [Nouveau] " Liam R. Howlett
2023-02-22 18:13 ` Danilo Krummrich
2023-02-22 18:13 ` Danilo Krummrich
2023-02-22 18:13 ` [Nouveau] " Danilo Krummrich
2023-02-23 19:09 ` Liam R. Howlett
2023-02-23 19:09 ` Liam R. Howlett
2023-02-23 19:09 ` [Nouveau] " Liam R. Howlett
2023-02-27 12:23 ` Danilo Krummrich
2023-02-27 12:23 ` Danilo Krummrich
2023-02-27 12:23 ` [Nouveau] " Danilo Krummrich
2023-03-02 2:38 ` Liam R. Howlett
2023-03-02 2:38 ` Liam R. Howlett
2023-03-02 2:38 ` [Nouveau] " Liam R. Howlett
2023-03-06 15:46 ` Danilo Krummrich
2023-03-06 15:46 ` [Nouveau] " Danilo Krummrich
2023-03-07 22:43 ` Liam R. Howlett
2023-03-07 22:43 ` Liam R. Howlett
2023-03-07 22:43 ` [Nouveau] " Liam R. Howlett
2023-03-13 23:46 ` Danilo Krummrich
2023-03-13 23:46 ` Danilo Krummrich
2023-03-13 23:46 ` [Nouveau] " Danilo Krummrich
2023-03-20 19:16 ` Liam R. Howlett
2023-03-20 19:16 ` Liam R. Howlett
2023-03-20 19:16 ` [Nouveau] " Liam R. Howlett
2023-02-28 2:17 ` Danilo Krummrich [this message]
2023-02-28 2:17 ` Danilo Krummrich
2023-02-28 16:24 ` Liam R. Howlett
2023-02-28 16:24 ` Liam R. Howlett
2023-02-28 16:24 ` [Nouveau] " Liam R. Howlett
2023-03-06 13:39 ` Danilo Krummrich
2023-03-06 13:39 ` [Nouveau] " Danilo Krummrich
2023-02-22 10:25 ` Christian König
2023-02-22 10:25 ` Christian König
2023-02-22 10:25 ` [Nouveau] " Christian König
2023-02-22 15:07 ` Danilo Krummrich
2023-02-22 15:07 ` Danilo Krummrich
2023-02-22 15:07 ` [Nouveau] " Danilo Krummrich
2023-02-22 15:14 ` Christian König
2023-02-22 15:14 ` Christian König
2023-02-22 15:14 ` [Nouveau] " Christian König
2023-02-22 16:40 ` Danilo Krummrich
2023-02-22 16:40 ` Danilo Krummrich
2023-02-22 16:40 ` [Nouveau] " Danilo Krummrich
2023-02-23 7:06 ` Christian König
2023-02-23 7:06 ` Christian König
2023-02-23 7:06 ` [Nouveau] " Christian König
2023-02-23 14:12 ` Danilo Krummrich
2023-02-23 14:12 ` Danilo Krummrich
2023-02-23 14:12 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 06/16] drm: debugfs: provide infrastructure to dump a DRM GPU VA space Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-18 2:47 ` kernel test robot
2023-02-18 2:47 ` kernel test robot
2023-02-18 2:47 ` [Nouveau] " kernel test robot
2023-02-17 13:48 ` [PATCH drm-next v2 07/16] drm/nouveau: new VM_BIND uapi interfaces Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 08/16] drm/nouveau: get vmm via nouveau_cli_vmm() Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 09/16] drm/nouveau: bo: initialize GEM GPU VA interface Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 10/16] drm/nouveau: move usercopy helpers to nouveau_drv.h Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 11/16] drm/nouveau: fence: fail to emit when fence context is killed Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 12/16] drm/nouveau: chan: provide nouveau_channel_kill() Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 13/16] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-18 1:16 ` kernel test robot
2023-02-18 1:16 ` kernel test robot
2023-02-18 1:16 ` [Nouveau] " kernel test robot
2023-02-17 13:48 ` [PATCH drm-next v2 14/16] drm/nouveau: implement uvmm for user mode bindings Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 15/16] drm/nouveau: implement new VM_BIND UAPI Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-02-17 13:48 ` [PATCH drm-next v2 16/16] drm/nouveau: debugfs: implement DRM GPU VA debugfs Danilo Krummrich
2023-02-17 13:48 ` Danilo Krummrich
2023-02-17 13:48 ` [Nouveau] " Danilo Krummrich
2023-03-09 9:12 ` [PATCH drm-next v2 00/16] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI Boris Brezillon
2023-03-09 9:12 ` Boris Brezillon
2023-03-09 9:12 ` [Nouveau] " Boris Brezillon
2023-03-09 9:48 ` Boris Brezillon
2023-03-09 9:48 ` Boris Brezillon
2023-03-09 9:48 ` [Nouveau] " Boris Brezillon
2023-03-10 16:45 ` Danilo Krummrich
2023-03-10 16:45 ` Danilo Krummrich
2023-03-10 16:45 ` [Nouveau] " Danilo Krummrich
2023-03-10 17:25 ` Boris Brezillon
2023-03-10 17:25 ` Boris Brezillon
2023-03-10 17:25 ` [Nouveau] " Boris Brezillon
2023-03-10 20:06 ` Danilo Krummrich
2023-03-10 20:06 ` Danilo Krummrich
2023-03-10 20:06 ` [Nouveau] " Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63fd642e.170a0220.f67f6.e248@mx.google.com \
--to=dakr@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=alexdeucher@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ogabbay@kernel.org \
--cc=tzimmermann@suse.de \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.