[Nouveau] [PATCH v5 02/10] drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo.c | 1 -
include/drm/drm_gem_cma_helper.h | 1 -
3 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 2165633c9b9e..d527485ea0b7 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -537,23 +537,6 @@ void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj)
}
EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vmap);
-/**
- * drm_gem_cma_prime_vunmap - unmap a CMA GEM object from the kernel's virtual
- * address space
- * @obj: GEM object
- * @vaddr: kernel virtual address where the CMA GEM object was mapped
- *
- * This function removes a buffer exported via DRM PRIME from the kernel's
- * virtual address space. This is a no-op because CMA buffers cannot be
- * unmapped from kernel space. Drivers using the CMA helpers should set this
- * as their _gem_object_funcs.vunmap callback.
- */
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vunmap);
-
static const struct drm_gem_object_funcs drm_gem_cma_default_funcs = {
.free = drm_gem_cma_free_object,
.print_info = drm_gem_cma_print_info,
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index f432278173cd..557f0d1e6437 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -387,7 +387,6 @@ static const struct drm_gem_object_funcs
vc4_gem_object_funcs = {
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_prime_get_sg_table,
.vmap = vc4_prime_vmap,
- .vunmap = drm_gem_cma_prime_vunmap,
.vm_ops = _vm_ops,
};
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 2bfa2502607a..a064b0d1c480 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -104,7 +104,6 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj);
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
struct drm_gem_object *
drm_gem_cma_create_object_default_funcs(struct drm_device *dev, size_t size);
--
2.28.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v5 04/10] drm/exynos: Remove empty exynos_drm_gem_prime_{vmap, vunmap}()
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index e7a6eb96f692..13a35623ac04 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -137,8 +137,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
.free = exynos_drm_gem_free_object,
.get_sg_table = exynos_drm_gem_prime_get_sg_table,
- .vmap = exynos_drm_gem_prime_vmap,
- .vunmap = exynos_drm_gem_prime_vunmap,
.vm_ops = _drm_gem_vm_ops,
};
@@ -471,16 +469,6 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device
*dev,
return _gem->base;
}
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj)
-{
- return NULL;
-}
-
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 74e926abeff0..a23272fb96fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -107,8 +107,6 @@ struct drm_gem_object *
exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj);
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
--
2.28.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v5 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap()
et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of
implementing their own vmap callbacks.
v5:
* update vkms after switch to shmem
v4:
* use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian)
* fix a trailing { in drm_gem_vmap()
* remove several empty functions instead of converting them (Daniel)
* comment uses of raw pointers with a TODO (Daniel)
* TODO list: convert more helpers to use struct dma_buf_map
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
Documentation/gpu/todo.rst | 18
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/ast/ast_cursor.c| 27 +++--
drivers/gpu/drm/ast/ast_drv.h | 7 +-
drivers/gpu/drm/drm_gem.c | 23 +++--
drivers/gpu/drm/drm_gem_cma_helper.c| 10 +-
drivers/gpu/drm/drm_gem_shmem_helper.c | 48 +
drivers/gpu/drm/drm_gem_vram_helper.c | 107 ++--
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 9 +-
drivers/gpu/drm/lima/lima_gem.c | 6 +-
drivers/gpu/drm/lima/lima_sched.c | 11 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 -
drivers/gpu/drm/nouveau/nouveau_prime.c | 20
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 14 +--
drivers/gpu/drm/qxl/qxl_display.c | 11 +-
drivers/gpu/drm/qxl/qxl_draw.c | 14 ++-
drivers/gpu/drm/qxl/qxl_drv.h | 11 +-
drivers/gpu/drm/qxl/qxl_object.c| 31 +++---
drivers/gpu/drm/qxl/qxl_object.h| 2 +-
drivers/gpu/drm/qxl/qxl_prime.c | 12 +--
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_gem.c | 7 +-
drivers/gpu/drm/radeon/radeon_prime.c | 20
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 22 ++--
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c | 10 +-
drivers/gpu/drm/udl/udl_modeset.c | 8 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 +-
drivers/gpu/drm/vc4/vc4_bo.c| 6 +-
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 16 ++-
drivers/gpu/drm/vkms/vkms_plane.c | 15 ++-
drivers/gpu/drm/vkms/vkms_writeback.c | 22 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.h | 6 +-
include/drm/drm_gem.h | 5 +-
include/drm/drm_gem_cma_helper.h| 2 +-
include/drm/drm_gem_shmem_helper.h | 4 +-
include/drm/drm_gem_vram_helper.h | 14 +--
49 files changed, 345 insertions(+), 308 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 700637e25ecd..7e6fc3c04add 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -446,6 +446,24 @@ Contact: Ville Syrjälä, Daniel Vetter
Level: Intermediate
+Use struct dma_buf_map throughout codebase
+--
+
+Pointers to shared device memory are stored in struct dma_buf_map. Each
+instance knows whether it refers to system or I/O memory. Most of the DRM-wide
+interface have been converted to use struct dma_buf_map, but implementations
+often still use raw pointers.
+
+The task is to use struct dma_buf_map where it makes sense.
+
+* Memory managers should use struct dma_buf_map for dma-buf-imported buffers.
+* TTM might benefit from using struct dma_buf_map internally.
+* Framebuffer copying and blitting helpers should operate on struct
dma_buf_map.
+
+Contact: Thomas Zimmermann , Christian König, Daniel
Vetter
+
+Level: Intermediate
+
Core refactorings
=
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 32257189e09b..e479b04e955e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -239,6 +239,7 @@ config DRM_RADEON
select FW_LOADER
select DRM_KMS_HELPER
Re: [Nouveau] [RFC] treewide: cleanup unreachable breaks
On 10/19/20 4:05 PM, Jason Gunthorpe wrote: > On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote: >> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote: >>> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: From: Tom Rix This is a upcoming change to clean up a new warning treewide. I am wondering if the change could be one mega patch (see below) or normal patch per file about 100 patches or somewhere half way by collecting early acks. >>> Please break it up into one-patch-per-subsystem, like normal, and get it >>> merged that way. >>> >>> Sending us a patch, without even a diffstat to review, isn't going to >>> get you very far... >> Tom, >> If you're able to automate this cleanup, I suggest checking in a >> script that can be run on a directory. Then for each subsystem you >> can say in your commit "I ran scripts/fix_whatever.py on this subdir." >> Then others can help you drive the tree wide cleanup. Then we can >> enable -Wunreachable-code-break either by default, or W=2 right now >> might be a good idea. > I remember using clang-modernize in the past to fix issues very > similar to this, if clang machinery can generate the warning, can't > something like clang-tidy directly generate the patch? Yes clang-tidy and similar are good tools. Sometimes they change too much and your time shifts from editing to analyzing and dropping changes. I am looking at them for auto changing api. When i have something greater than half baked i will post. Tom > > You can send me a patch for drivers/infiniband/* as well > > Thanks, > Jason > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v5 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
two helpers that convert a GEM object into the TTM BO and forward the call
to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
callbacks.
v5:
* use size_t for storing mapping size (Christian)
* ignore premapped memory areas correctly in ttm_bo_vunmap()
* rebase onto latest TTM interfaces (Christian)
* remove BUG() from ttm_bo_vmap() (Christian)
v4:
* drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
Christian)
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72
include/drm/drm_gem_ttm_helper.h | 6 +++
include/drm/ttm/ttm_bo_api.h | 28 +++
include/linux/dma-buf-map.h | 20
5 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 0e4fb9ba43ad..db4c14d78a30 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
+/**
+ * drm_gem_ttm_vmap() - vmap _buffer_object
+ * @gem: GEM object.
+ * @map: [out] returns the dma-buf mapping.
+ *
+ * Maps a GEM object with ttm_bo_vmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_gem_ttm_vmap(struct drm_gem_object *gem,
+struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ return ttm_bo_vmap(bo, map);
+
+}
+EXPORT_SYMBOL(drm_gem_ttm_vmap);
+
+/**
+ * drm_gem_ttm_vunmap() - vunmap _buffer_object
+ * @gem: GEM object.
+ * @map: dma-buf mapping.
+ *
+ * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ */
+void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
+ struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ ttm_bo_vunmap(bo, map);
+}
+EXPORT_SYMBOL(drm_gem_ttm_vunmap);
+
/**
* drm_gem_ttm_mmap() - mmap _buffer_object
* @gem: GEM object.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ba7ab5ed85d0..5c79418405ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -527,6 +528,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = >mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_iomem;
+ size_t size = bo->num_pages << PAGE_SHIFT;
+
+ if (mem->bus.addr)
+ vaddr_iomem = (void __iomem *)mem->bus.addr;
+ else if (mem->bus.caching == ttm_write_combined)
+ vaddr_iomem = ioremap_wc(mem->bus.offset, size);
+ else
+ vaddr_iomem = ioremap(mem->bus.offset, size);
+
+ if (!vaddr_iomem)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
+
+ } else {
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
+ struct ttm_tt *ttm = bo->ttm;
+ pgprot_t prot;
+ void *vaddr;
+
+ ret = ttm_tt_populate(bo->bdev, ttm, );
+ if (ret)
+ return ret;
+
+ /*
+* We need to use vmap to get the desired page protection
+* or to make the buffer object look contiguous.
+*/
+ prot = ttm_io_prot(bo, mem, PAGE_KERNEL);
+ vaddr = vmap(ttm->pages, bo->num_pages, 0, prot);
+ if (!vaddr)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr(map, vaddr);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vmap);
+
+void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = >mem;
+
+ if
[Nouveau] [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
include/linux/dma-buf-map.h | 73 -
1 file changed, 63 insertions(+), 10 deletions(-)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 2e8bbecb5091..583a3a1f9447 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -7,6 +7,7 @@
#define __DMA_BUF_MAP_H__
#include
+#include
/**
* DOC: overview
@@ -32,6 +33,14 @@
* accessing the buffer. Use the returned instance and the helper functions
* to access the buffer's memory in the correct way.
*
+ * The type :c:type:`struct dma_buf_map ` and its helpers are
+ * actually independent from the dma-buf infrastructure. When sharing buffers
+ * among devices, drivers have to know the location of the memory to access
+ * the buffers in a safe way. :c:type:`struct dma_buf_map `
+ * solves this problem for dma-buf and its users. If other drivers or
+ * sub-systems require similar functionality, the type could be generalized
+ * and moved to a more prominent header file.
+ *
* Open-coding access to :c:type:`struct dma_buf_map ` is
* considered bad style. Rather then accessing its fields directly, use one
* of the provided helper functions, or implement your own. For example,
@@ -51,6 +60,14 @@
*
* dma_buf_map_set_vaddr_iomem( 0xdeadbeaf);
*
+ * Instances of struct dma_buf_map do not have to be cleaned up, but
+ * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
+ * always refer to system memory.
+ *
+ * .. code-block:: c
+ *
+ * dma_buf_map_clear();
+ *
* Test if a mapping is valid with either dma_buf_map_is_set() or
* dma_buf_map_is_null().
*
@@ -73,17 +90,19 @@
* if (dma_buf_map_is_equal(_map, _map))
* // always false
*
- * Instances of struct dma_buf_map do not have to be cleaned up, but
- * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
- * always refer to system memory.
+ * A set up instance of struct dma_buf_map can be used to access or manipulate
+ * the buffer memory. Depending on the location of the memory, the provided
+ * helpers will pick the correct operations. Data can be copied into the memory
+ * with dma_buf_map_memcpy_to(). The address can be manipulated with
+ * dma_buf_map_incr().
*
- * The type :c:type:`struct dma_buf_map ` and its helpers are
- * actually independent from the dma-buf infrastructure. When sharing buffers
- * among devices, drivers have to know the location of the memory to access
- * the buffers in a safe way. :c:type:`struct dma_buf_map `
- * solves this problem for dma-buf and its users. If other drivers or
- * sub-systems require similar functionality, the type could be generalized
- * and moved to a more prominent header file.
+ * .. code-block:: c
+ *
+ * const void *src = ...; // source buffer
+ * size_t len = ...; // length of src
+ *
+ * dma_buf_map_memcpy_to(, src, len);
+ * dma_buf_map_incr(, len); // go to first byte after the memcpy
*/
/**
@@ -210,4 +229,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
*map)
}
}
+/**
+ * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
+ * @dst: The dma-buf mapping structure
+ * @src: The source buffer
+ * @len: The number of byte in src
+ *
+ * Copies data into a dma-buf mapping. The source buffer is in system
+ * memory. Depending on the buffer's location, the helper picks the correct
+ * method of accessing the memory.
+ */
+static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
*src, size_t len)
+{
+ if (dst->is_iomem)
+ memcpy_toio(dst->vaddr_iomem, src, len);
+ else
+ memcpy(dst->vaddr, src, len);
+}
+
+/**
+ * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
+ * @map: The dma-buf mapping structure
+ * @incr: The number of bytes to increment
+ *
+ * Increments the address stored in a dma-buf mapping. Depending on the
+ * buffer's location, the correct value will be updated.
+ */
+static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
+{
+ if (map->is_iomem)
+ map->vaddr_iomem += incr;
+ else
+ map->vaddr += incr;
+}
+
#endif /* __DMA_BUF_MAP_H__ */
--
2.28.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
internally by DRM's fbdev helper.
For drivers that employ a shadow buffer, fbdev's blit function retrieves
the framebuffer address as struct dma_buf_map, and uses dma_buf_map
interfaces to access the buffer.
The bochs driver on sparc64 uses a workaround to flag the framebuffer as
I/O memory and avoid a HW exception. With the introduction of struct
dma_buf_map, this is not required any longer. The patch removes the rsp
code from both, bochs and fbdev.
v5:
* implement fb_read/fb_write internally (Daniel, Sam)
v4:
* move dma_buf_map changes into separate patch (Daniel)
* TODO list: comment on fbdev updates (Daniel)
Signed-off-by: Thomas Zimmermann
Tested-by: Sam Ravnborg
---
Documentation/gpu/todo.rst| 19 ++-
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
drivers/gpu/drm/drm_fb_helper.c | 227 --
include/drm/drm_mode_config.h | 12 --
4 files changed, 230 insertions(+), 29 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7e6fc3c04add..638b7f704339 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
-atomic modesetting and GEM vmap support. Current generic fbdev emulation
-expects the framebuffer in system memory (or system-like memory).
+atomic modesetting and GEM vmap support. Historically, generic fbdev emulation
+expected the framebuffer in system memory or system-like memory. By employing
+struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
+as well.
Contact: Maintainer of the driver you plan to convert
Level: Intermediate
+Reimplement functions in drm_fbdev_fb_ops without fbdev
+---
+
+A number of callback functions in drm_fbdev_fb_ops could benefit from
+being rewritten without dependencies on the fbdev module. Some of the
+helpers could further benefit from using struct dma_buf_map instead of
+raw pointers.
+
+Contact: Thomas Zimmermann , Daniel Vetter
+
+Level: Advanced
+
+
drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
-
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 13d0d04c4457..853081d186d5 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs->dev->mode_config.preferred_depth = 24;
bochs->dev->mode_config.prefer_shadow = 0;
bochs->dev->mode_config.prefer_shadow_fbdev = 1;
- bochs->dev->mode_config.fbdev_use_iomem = true;
bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
bochs->dev->mode_config.funcs = _mode_funcs;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6212cd7cde1d..1d3180841778 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
work_struct *work)
}
static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
- struct drm_clip_rect *clip)
+ struct drm_clip_rect *clip,
+ struct dma_buf_map *dst)
{
struct drm_framebuffer *fb = fb_helper->fb;
unsigned int cpp = fb->format->cpp[0];
size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
void *src = fb_helper->fbdev->screen_buffer + offset;
- void *dst = fb_helper->buffer->map.vaddr + offset;
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y;
- for (y = clip->y1; y < clip->y2; y++) {
- if (!fb_helper->dev->mode_config.fbdev_use_iomem)
- memcpy(dst, src, len);
- else
- memcpy_toio((void __iomem *)dst, src, len);
+ dma_buf_map_incr(dst, offset); /* go to first pixel within clip rect */
+ for (y = clip->y1; y < clip->y2; y++) {
+ dma_buf_map_memcpy_to(dst, src, len);
+ dma_buf_map_incr(dst, fb->pitches[0]);
src += fb->pitches[0];
- dst += fb->pitches[0];
}
}
@@ -417,8 +415,9 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
ret = drm_client_buffer_vmap(helper->buffer, );
Re: [Nouveau] [PATCH v5 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
Am 20.10.20 um 14:20 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
two helpers that convert a GEM object into the TTM BO and forward the call
to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
callbacks.
v5:
* use size_t for storing mapping size (Christian)
* ignore premapped memory areas correctly in ttm_bo_vunmap()
* rebase onto latest TTM interfaces (Christian)
* remove BUG() from ttm_bo_vmap() (Christian)
v4:
* drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
Christian)
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Tested-by: Sam Ravnborg
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72
include/drm/drm_gem_ttm_helper.h | 6 +++
include/drm/ttm/ttm_bo_api.h | 28 +++
include/linux/dma-buf-map.h | 20
5 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 0e4fb9ba43ad..db4c14d78a30 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
+/**
+ * drm_gem_ttm_vmap() - vmap _buffer_object
+ * @gem: GEM object.
+ * @map: [out] returns the dma-buf mapping.
+ *
+ * Maps a GEM object with ttm_bo_vmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_gem_ttm_vmap(struct drm_gem_object *gem,
+struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ return ttm_bo_vmap(bo, map);
+
+}
+EXPORT_SYMBOL(drm_gem_ttm_vmap);
+
+/**
+ * drm_gem_ttm_vunmap() - vunmap _buffer_object
+ * @gem: GEM object.
+ * @map: dma-buf mapping.
+ *
+ * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ */
+void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
+ struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ ttm_bo_vunmap(bo, map);
+}
+EXPORT_SYMBOL(drm_gem_ttm_vunmap);
+
/**
* drm_gem_ttm_mmap() - mmap _buffer_object
* @gem: GEM object.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ba7ab5ed85d0..5c79418405ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -527,6 +528,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = >mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_iomem;
+ size_t size = bo->num_pages << PAGE_SHIFT;
+
+ if (mem->bus.addr)
+ vaddr_iomem = (void __iomem *)mem->bus.addr;
+ else if (mem->bus.caching == ttm_write_combined)
+ vaddr_iomem = ioremap_wc(mem->bus.offset, size);
+ else
+ vaddr_iomem = ioremap(mem->bus.offset, size);
+
+ if (!vaddr_iomem)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
+
+ } else {
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
+ struct ttm_tt *ttm = bo->ttm;
+ pgprot_t prot;
+ void *vaddr;
+
+ ret = ttm_tt_populate(bo->bdev, ttm, );
+ if (ret)
+ return ret;
+
+ /*
+* We need to use vmap to get the desired page protection
+* or to make the buffer object look contiguous.
+*/
+ prot = ttm_io_prot(bo, mem, PAGE_KERNEL);
+ vaddr = vmap(ttm->pages, bo->num_pages, 0, prot);
+ if (!vaddr)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr(map, vaddr);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vmap);
+
+void ttm_bo_vunmap(struct
Re: [Nouveau] [RFC] treewide: cleanup unreachable breaks
On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote: > On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > > From: Tom Rix > > > > > > This is a upcoming change to clean up a new warning treewide. > > > I am wondering if the change could be one mega patch (see below) or > > > normal patch per file about 100 patches or somewhere half way by > > > collecting > > > early acks. > > > > Please break it up into one-patch-per-subsystem, like normal, and get it > > merged that way. > > > > Sending us a patch, without even a diffstat to review, isn't going to > > get you very far... > > Tom, > If you're able to automate this cleanup, I suggest checking in a > script that can be run on a directory. Then for each subsystem you > can say in your commit "I ran scripts/fix_whatever.py on this subdir." > Then others can help you drive the tree wide cleanup. Then we can > enable -Wunreachable-code-break either by default, or W=2 right now > might be a good idea. > > Ah, George (gbiv@, cc'ed), did an analysis recently of > `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and > `-Wunreachable-code-return` for Android userspace. From the review: > ``` > Spoilers: of these, it seems useful to turn on > -Wunreachable-code-loop-increment and -Wunreachable-code-return by > default for Android > ... > While these conventions about always having break arguably became > obsolete when we enabled -Wfallthrough, my sample turned up zero > potential bugs caught by this warning, and we'd need to put a lot of > effort into getting a clean tree. So this warning doesn't seem to be > worth it. > ``` > Looks like there's an order of magnitude of `-Wunreachable-code-break` > than the other two. > > We probably should add all 3 to W=2 builds (wrapped in cc-option). > I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to > follow up on. I suggest using W=1 as people that are doing cleanups generally use that and not W=123 or any other style. Every other use of W= is still quite noisy and these code warnings are relatively trivially to fix up. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] x86/mm/kmmio: correctly handle kzalloc return
Replacing return value -1 to error code Signed-off-by: Mugilraj Dhavachelvan --- arch/x86/mm/kmmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c index be020a7bc414..15430520c232 100644 --- a/arch/x86/mm/kmmio.c +++ b/arch/x86/mm/kmmio.c @@ -386,7 +386,7 @@ static int add_kmmio_fault_page(unsigned long addr) f = kzalloc(sizeof(*f), GFP_ATOMIC); if (!f) - return -1; + return -ENOMEN; f->count = 1; f->addr = addr; -- 2.25.1 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v5 01/10] drm/vram-helper: Remove invariant parameters from internal kmap function
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 7aeb5daf2805..bfc059945e31 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -379,32 +379,22 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
-static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
- bool map, bool *is_iomem)
+static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo)
{
int ret;
struct ttm_bo_kmap_obj *kmap = >kmap;
+ bool is_iomem;
if (gbo->kmap_use_count > 0)
goto out;
- if (kmap->virtual || !map)
- goto out;
-
ret = ttm_bo_kmap(>bo, 0, gbo->bo.num_pages, kmap);
if (ret)
return ERR_PTR(ret);
out:
- if (!kmap->virtual) {
- if (is_iomem)
- *is_iomem = false;
- return NULL; /* not mapped; don't increment ref */
- }
++gbo->kmap_use_count;
- if (is_iomem)
- return ttm_kmap_obj_virtual(kmap, is_iomem);
- return kmap->virtual;
+ return ttm_kmap_obj_virtual(kmap, _iomem);
}
static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo)
@@ -449,7 +439,7 @@ void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo)
ret = drm_gem_vram_pin_locked(gbo, 0);
if (ret)
goto err_ttm_bo_unreserve;
- base = drm_gem_vram_kmap_locked(gbo, true, NULL);
+ base = drm_gem_vram_kmap_locked(gbo);
if (IS_ERR(base)) {
ret = PTR_ERR(base);
goto err_drm_gem_vram_unpin_locked;
--
2.28.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v5 03/10] drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 -
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 914f0867ff71..9682c26d89bb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -52,7 +52,6 @@ int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct
*vma);
int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device
*dev,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 67d9a2b9ea6a..bbd235473645 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -571,7 +571,6 @@ static const struct drm_gem_object_funcs
etnaviv_gem_object_funcs = {
.unpin = etnaviv_gem_prime_unpin,
.get_sg_table = etnaviv_gem_prime_get_sg_table,
.vmap = etnaviv_gem_prime_vmap,
- .vunmap = etnaviv_gem_prime_vunmap,
.vm_ops = _ops,
};
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 135fbff6fecf..a6d9932a32ae 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -27,11 +27,6 @@ void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj)
return etnaviv_gem_vmap(obj);
}
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* TODO msm_gem_vunmap() */
-}
-
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
--
2.28.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modified with
dma_buf_map interfaces.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c| 34 +++--
drivers/gpu/drm/drm_fb_helper.c | 23 +-
include/drm/drm_client.h| 7 ---
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index ac0082bed966..fe573acf1067 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -235,7 +235,7 @@ static void drm_client_buffer_delete(struct
drm_client_buffer *buffer)
{
struct drm_device *dev = buffer->client->dev;
- drm_gem_vunmap(buffer->gem, buffer->vaddr);
+ drm_gem_vunmap(buffer->gem, >map);
if (buffer->gem)
drm_gem_object_put(buffer->gem);
@@ -291,25 +291,31 @@ drm_client_buffer_create(struct drm_client_dev *client,
u32 width, u32 height, u
/**
* drm_client_buffer_vmap - Map DRM client buffer into address space
* @buffer: DRM client buffer
+ * @map_copy: Returns the mapped memory's address
*
* This function maps a client buffer into kernel address space. If the
- * buffer is already mapped, it returns the mapping's address.
+ * buffer is already mapped, it returns the existing mapping's address.
*
* Client buffer mappings are not ref'counted. Each call to
* drm_client_buffer_vmap() should be followed by a call to
* drm_client_buffer_vunmap(); or the client buffer should be mapped
* throughout its lifetime.
*
+ * The returned address is a copy of the internal value. In contrast to
+ * other vmap interfaces, you don't need it for the client's vunmap
+ * function. So you can modify it at will during blit and draw operations.
+ *
* Returns:
- * The mapped memory's address
+ * 0 on success, or a negative errno code otherwise.
*/
-void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
+int
+drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct dma_buf_map
*map_copy)
{
- struct dma_buf_map map;
+ struct dma_buf_map *map = >map;
int ret;
- if (buffer->vaddr)
- return buffer->vaddr;
+ if (dma_buf_map_is_set(map))
+ goto out;
/*
* FIXME: The dependency on GEM here isn't required, we could
@@ -319,13 +325,14 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
*buffer)
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- ret = drm_gem_vmap(buffer->gem, );
+ ret = drm_gem_vmap(buffer->gem, map);
if (ret)
- return ERR_PTR(ret);
+ return ret;
- buffer->vaddr = map.vaddr;
+out:
+ *map_copy = *map;
- return map.vaddr;
+ return 0;
}
EXPORT_SYMBOL(drm_client_buffer_vmap);
@@ -339,10 +346,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
*/
void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
{
- struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->vaddr);
+ struct dma_buf_map *map = >map;
- drm_gem_vunmap(buffer->gem, );
- buffer->vaddr = NULL;
+ drm_gem_vunmap(buffer->gem, map);
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c2f72bb6afb1..6212cd7cde1d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -378,7 +378,7 @@ static void drm_fb_helper_dirty_blit_real(struct
drm_fb_helper *fb_helper,
unsigned int cpp = fb->format->cpp[0];
size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
void *src = fb_helper->fbdev->screen_buffer + offset;
- void *dst = fb_helper->buffer->vaddr + offset;
+ void *dst = fb_helper->buffer->map.vaddr + offset;
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y;
@@ -400,7 +400,8 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
struct drm_clip_rect *clip = >dirty_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
- void *vaddr;
+ struct dma_buf_map map;
+ int ret;
spin_lock_irqsave(>dirty_lock, flags);
clip_copy = *clip;
@@ -413,8 +414,8 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
/* Generic fbdev uses a shadow buffer */
if (helper->buffer) {
- vaddr = drm_client_buffer_vmap(helper->buffer);
- if (IS_ERR(vaddr))
+ ret = drm_client_buffer_vmap(helper->buffer, );
+
[Nouveau] [PATCH v5 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use them correctly. This enables I/O-memory operations on all framebuffers
that require and support them.
Patches #1 to #4 prepare VRAM helpers and drivers.
Next is the update of the GEM vmap functions. Patch #5 adds vmap and vunmap
that is usable with TTM-based GEM drivers, and patch #6 updates GEM's
vmap/vunmap callback to forward instances of type struct dma_buf_map. While
the patch touches many files throughout the DRM modules, the applied changes
are mostly trivial interface fixes. Several TTM-based GEM drivers now use
the new vmap code. Patch #7 updates GEM's internal vmap/vunmap functions to
forward struct dma_buf_map.
With struct dma_buf_map propagated through the layers, patches #8 to #10
convert DRM clients and generic fbdev emulation to use it. Updating the
fbdev framebuffer will select the correct functions, either for system or
I/O memory.
v5:
* rebase onto latest TTM changes (Chrsitian)
* support TTM premapped memory correctly (Christian)
* implement fb_read/fb_write internally (Sam, Daniel)
* cleanups
v4:
* provide TTM vmap/vunmap plus GEM helpers and convert drivers
over (Christian, Daniel)
* remove several empty functions
* more TODOs and documentation (Daniel)
v3:
* recreate the whole patchset on top of struct dma_buf_map
v2:
* RFC patchset
Thomas Zimmermann (10):
drm/vram-helper: Remove invariant parameters from internal kmap
function
drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()
drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
drm/exynos: Remove empty exynos_drm_gem_prime_{vmap,vunmap}()
drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM
backends
drm/gem: Update internal GEM vmap/vunmap interfaces to use struct
dma_buf_map
drm/gem: Store client buffer mappings as struct dma_buf_map
dma-buf-map: Add memcpy and pointer-increment interfaces
drm/fb_helper: Support framebuffers in I/O memory
Documentation/gpu/todo.rst | 37 ++-
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/ast/ast_cursor.c| 27 +--
drivers/gpu/drm/ast/ast_drv.h | 7 +-
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
drivers/gpu/drm/drm_client.c| 38 +--
drivers/gpu/drm/drm_fb_helper.c | 248 ++--
drivers/gpu/drm/drm_gem.c | 29 ++-
drivers/gpu/drm/drm_gem_cma_helper.c| 27 +--
drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++--
drivers/gpu/drm/drm_gem_ttm_helper.c| 38 +++
drivers/gpu/drm/drm_gem_vram_helper.c | 117 +
drivers/gpu/drm/drm_internal.h | 5 +-
drivers/gpu/drm/drm_prime.c | 14 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 3 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 12 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 -
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 -
drivers/gpu/drm/lima/lima_gem.c | 6 +-
drivers/gpu/drm/lima/lima_sched.c | 11 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 -
drivers/gpu/drm/nouveau/nouveau_prime.c | 20 --
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 14 +-
drivers/gpu/drm/qxl/qxl_display.c | 11 +-
drivers/gpu/drm/qxl/qxl_draw.c | 14 +-
drivers/gpu/drm/qxl/qxl_drv.h | 11 +-
drivers/gpu/drm/qxl/qxl_object.c| 31 ++-
drivers/gpu/drm/qxl/qxl_object.h| 2 +-
drivers/gpu/drm/qxl/qxl_prime.c | 12 +-
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_gem.c | 7 +-
drivers/gpu/drm/radeon/radeon_prime.c | 20 --
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 22 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c | 10 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 72 ++
drivers/gpu/drm/udl/udl_modeset.c | 8 +-
[Nouveau] [PATCH v5 07/10] drm/gem: Update internal GEM vmap/vunmap interfaces to use struct dma_buf_map
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drivers/gpu/drm/drm_internal.h | 5 +++--
drivers/gpu/drm/drm_prime.c| 14 --
4 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 495f47d23d87..ac0082bed966 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -3,6 +3,7 @@
* Copyright 2018 Noralf Trønnes
*/
+#include
#include
#include
#include
@@ -304,7 +305,8 @@ drm_client_buffer_create(struct drm_client_dev *client, u32
width, u32 height, u
*/
void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
{
- void *vaddr;
+ struct dma_buf_map map;
+ int ret;
if (buffer->vaddr)
return buffer->vaddr;
@@ -317,13 +319,13 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
*buffer)
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- vaddr = drm_gem_vmap(buffer->gem);
- if (IS_ERR(vaddr))
- return vaddr;
+ ret = drm_gem_vmap(buffer->gem, );
+ if (ret)
+ return ERR_PTR(ret);
- buffer->vaddr = vaddr;
+ buffer->vaddr = map.vaddr;
- return vaddr;
+ return map.vaddr;
}
EXPORT_SYMBOL(drm_client_buffer_vmap);
@@ -337,7 +339,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
*/
void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
{
- drm_gem_vunmap(buffer->gem, buffer->vaddr);
+ struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->vaddr);
+
+ drm_gem_vunmap(buffer->gem, );
buffer->vaddr = NULL;
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a89ad4570e3c..4d5fff4bd821 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1206,32 +1206,32 @@ void drm_gem_unpin(struct drm_gem_object *obj)
obj->funcs->unpin(obj);
}
-void *drm_gem_vmap(struct drm_gem_object *obj)
+int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
- struct dma_buf_map map;
int ret;
if (!obj->funcs->vmap)
- return ERR_PTR(-EOPNOTSUPP);
+ return -EOPNOTSUPP;
- ret = obj->funcs->vmap(obj, );
+ ret = obj->funcs->vmap(obj, map);
if (ret)
- return ERR_PTR(ret);
- else if (dma_buf_map_is_null())
- return ERR_PTR(-ENOMEM);
+ return ret;
+ else if (dma_buf_map_is_null(map))
+ return -ENOMEM;
- return map.vaddr;
+ return 0;
}
-void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr)
+void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
- struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(vaddr);
-
- if (!vaddr)
+ if (dma_buf_map_is_null(map))
return;
if (obj->funcs->vunmap)
- obj->funcs->vunmap(obj, );
+ obj->funcs->vunmap(obj, map);
+
+ /* Always set the mapping to NULL. Callers may rely on this. */
+ dma_buf_map_clear(map);
}
/**
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index b65865c630b0..58832d75a9bd 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -33,6 +33,7 @@
struct dentry;
struct dma_buf;
+struct dma_buf_map;
struct drm_connector;
struct drm_crtc;
struct drm_framebuffer;
@@ -187,8 +188,8 @@ void drm_gem_print_info(struct drm_printer *p, unsigned int
indent,
int drm_gem_pin(struct drm_gem_object *obj);
void drm_gem_unpin(struct drm_gem_object *obj);
-void *drm_gem_vmap(struct drm_gem_object *obj);
-void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
+int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
+void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map);
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 89e2a2496734..cb8fbeeb731b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -667,21 +667,15 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
*
* Sets up a kernel virtual mapping. This can be used as the _buf_ops.vmap
* callback. Calls into _gem_object_funcs.vmap for device specific
handling.
+ * The kernel virtual address is returned in map.
*
- * Returns the kernel virtual address or NULL on failure.
+ * Returns 0 on success or a negative errno code otherwise.
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map)
{
struct drm_gem_object *obj
Re: [Nouveau] [RFC] treewide: cleanup unreachable breaks
On 10/19/20 12:42 PM, Nick Desaulniers wrote: > On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote: >> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: >>> From: Tom Rix >>> >>> This is a upcoming change to clean up a new warning treewide. >>> I am wondering if the change could be one mega patch (see below) or >>> normal patch per file about 100 patches or somewhere half way by collecting >>> early acks. >> Please break it up into one-patch-per-subsystem, like normal, and get it >> merged that way. >> >> Sending us a patch, without even a diffstat to review, isn't going to >> get you very far... > Tom, > If you're able to automate this cleanup, I suggest checking in a > script that can be run on a directory. Then for each subsystem you > can say in your commit "I ran scripts/fix_whatever.py on this subdir." > Then others can help you drive the tree wide cleanup. Then we can > enable -Wunreachable-code-break either by default, or W=2 right now > might be a good idea. I should have waited for Joe Perches's fixer addition to checkpatch :) The easy fixes I did only cover about 1/2 of the problems. Remaining are mostly nested switches, which from a complexity standpoint is bad. > > Ah, George (gbiv@, cc'ed), did an analysis recently of > `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and > `-Wunreachable-code-return` for Android userspace. From the review: > ``` > Spoilers: of these, it seems useful to turn on > -Wunreachable-code-loop-increment and -Wunreachable-code-return by > default for Android In my simple add-a-cflag bot, i see there are about 250 issues for -Wunreachable-code-return. I'll see about doing this one next. > ... > While these conventions about always having break arguably became > obsolete when we enabled -Wfallthrough, my sample turned up zero > potential bugs caught by this warning, and we'd need to put a lot of > effort into getting a clean tree. So this warning doesn't seem to be > worth it. > ``` > Looks like there's an order of magnitude of `-Wunreachable-code-break` > than the other two. > > We probably should add all 3 to W=2 builds (wrapped in cc-option). > I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to > follow up on. Yes, i think think these should be added. Tom ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
> On 19 Oct 2020, at 20:42, Nick Desaulniers wrote: > > We probably should add all 3 to W=2 builds (wrapped in cc-option). > I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to > follow up on. It looks as though the URL mangling has been fixed. If anyone sees that specific URL mangled, please let me know. jch signature.asc Description: Message signed with OpenPGP ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] x86/mm/kmmio: correctly handle kzalloc return
On Tue, 20 Oct 2020 14:13:44 +0530 Mugilraj Dhavachelvan wrote: > Replacing return value -1 to error code > > Signed-off-by: Mugilraj Dhavachelvan > --- > arch/x86/mm/kmmio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c > index be020a7bc414..15430520c232 100644 > --- a/arch/x86/mm/kmmio.c > +++ b/arch/x86/mm/kmmio.c > @@ -386,7 +386,7 @@ static int add_kmmio_fault_page(unsigned long addr) > > f = kzalloc(sizeof(*f), GFP_ATOMIC); > if (!f) > - return -1; > + return -ENOMEN; > > f->count = 1; > f->addr = addr; Hi, did you even build-test this? Why did you write this patch? What does it achieve? Thanks, pq pgp3RnAGg4C9Q.pgp Description: OpenPGP digital signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] RIP: 0010:g84_gr_tlb_flush+0x2eb/0x300 [nouveau]
Hi there, Could someone please comment on the following hard-lock (*). Staring at the code, I see `nvkm_rd32` calls are enclosed in a timeout detection, except one. drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c#L171 ... nvkm_msec(device, 2000, if (!(nvkm_rd32(device, 0x100c80) & 0x0001)) break; ); ... Would it make sense to also enclose this in the do/while loop ? Full ref: * https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/536 Thanks (*) Oct 20 08:44:13 vostrodell kernel: [55669.783436] [ cut here ] Oct 20 08:44:13 vostrodell kernel: [55669.783446] nouveau :01:00.0: timeout Oct 20 08:44:13 vostrodell kernel: [55669.783527] WARNING: CPU: 1 PID: 7812 at drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c:171 g84_gr_tlb_flush+0x2eb/0x300 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.783527] Modules linked in: cdc_acm(OE) fuse md4 sha512_ssse3 sha512_generic cmac nls_utf8 cifs dns_resolver fscache libdes intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm ath9k irqbypass ath9k_common ath9k_hw crc32_pclmul ath snd_hda_codec_conexant ghash_clmulni_intel snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio mac80211 snd_hda_intel snd_intel_dspcfg aesni_intel libaes crypto_simd snd_hda_codec snd_hda_core cryptd snd_hwdep cfg80211 glue_helper dcdbas snd_pcm rapl iTCO_wdt snd_timer intel_pmc_bxt mei_me intel_cstate rfkill iTCO_vendor_support snd intel_uncore dell_smm_hwmon mei serio_raw soundcore watchdog libarc4 at24 sg pcspkr evdev binfmt_misc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod sr_mod t10_pi cdrom crc_t10dif crct10dif_generic hid_generic usbhid hid uas ata_generic usb_storage nouveau mxm_wmi wmi ata_piix crct10dif_pclmul crct10dif_common video i2c_algo_bit libata ttm crc32c_intel Oct 20 08:44:13 vostrodell kernel: [55669.783551] drm_kms_helper psmouse scsi_mod i2c_i801 i2c_smbus cec lpc_ich ehci_pci ehci_hcd drm usbcore r8169 realtek libphy usb_common button [last unloaded: cdc_acm] Oct 20 08:44:13 vostrodell kernel: [55669.783558] CPU: 1 PID: 7812 Comm: kworker/1:0 Tainted: G OE 5.8.0-0.bpo.2-amd64 #1 Debian 5.8.10-1~bpo10+1 Oct 20 08:44:13 vostrodell kernel: [55669.783559] Hardware name: Dell Inc. Vostro 260 /0GDG8Y , BIOS A10 02/22/2013 Oct 20 08:44:13 vostrodell kernel: [55669.783595] Workqueue: events nouveau_cli_work [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.783631] RIP: 0010:g84_gr_tlb_flush+0x2eb/0x300 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.783633] Code: 8b 40 10 48 8b 78 10 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 87 e7 ab e7 4c 89 e2 48 c7 c7 6c 43 63 c0 48 89 c6 e8 30 af 58 e7 <0f> 0b e9 44 ff ff ff e8 d9 d7 cf e7 66 0f 1f 84 00 00 00 00 00 66 Oct 20 08:44:13 vostrodell kernel: [55669.783634] RSP: 0018:ae76c66db998 EFLAGS: 00010082 Oct 20 08:44:13 vostrodell kernel: [55669.783634] RAX: RBX: 9dc2450f8c00 RCX: 0027 Oct 20 08:44:13 vostrodell kernel: [55669.783635] RDX: 0027 RSI: 9dc277498ac0 RDI: 9dc277498ac8 Oct 20 08:44:13 vostrodell kernel: [55669.783636] RBP: R08: 04df R09: 0004 Oct 20 08:44:13 vostrodell kernel: [55669.783636] R10: R11: 0001 R12: 9dc26fc42290 Oct 20 08:44:13 vostrodell kernel: [55669.783637] R13: 32a15d0363a0 R14: 9dc277560580 R15: 0001 Oct 20 08:44:13 vostrodell kernel: [55669.783638] FS: () GS:9dc27748() knlGS: Oct 20 08:44:13 vostrodell kernel: [55669.783639] CS: 0010 DS: ES: CR0: 80050033 Oct 20 08:44:13 vostrodell kernel: [55669.783639] CR2: 7f72949e5000 CR3: 00020480a001 CR4: 000606e0 Oct 20 08:44:13 vostrodell kernel: [55669.783640] Call Trace: Oct 20 08:44:13 vostrodell kernel: [55669.783648] ? enqueue_task_fair+0x8e/0x690 Oct 20 08:44:13 vostrodell kernel: [55669.783683] ? nv04_timer_read+0x42/0x60 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831715] nv50_vmm_flush+0x1f1/0x220 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831719] ? refcount_dec_and_mutex_lock+0x26/0x60 Oct 20 08:44:13 vostrodell kernel: [55669.831751] nvkm_vmm_iter.constprop.10+0x364/0x820 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831783] ? nvkm_vmm_map_choose+0xa0/0xa0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831815] ? nv44_vmm_new+0xe0/0xe0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831847] nvkm_vmm_ptes_unmap_put+0x2c/0x40 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831885] ? nvkm_vmm_map_choose+0xa0/0xa0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831922] ? nv44_vmm_new+0xe0/0xe0 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.831968] nvkm_vmm_put_locked+0x203/0x240 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.832000] nvkm_uvmm_mthd+0x249/0x710 [nouveau] Oct 20 08:44:13 vostrodell kernel: [55669.832022]
