Displaying 20 results from an estimated 21 matches for "dma_buf_vmap".
Did you mean:
dma_buf_map
2018 Jan 11
5
[PATCH 1/5] drm/prime: Remove duplicate forward declaration
From: Thierry Reding <treding at nvidia.com>
struct device is forward-declared twice. Remove the second instance.
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
include/drm/drm_prime.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index
2020 Oct 15
1
[PATCH v4 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
...BO's memory.
- *
- * Returns:
- * The virtual address of the mapping or an error pointer.
- */
-void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int ret;
-
- ret = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages,
- &bo->dma_buf_vmap);
- if (ret)
- return ERR_PTR(ret);
-
- return bo->dma_buf_vmap.virtual;
-}
-
-/**
- * amdgpu_gem_prime_vunmap - &dma_buf_ops.vunmap implementation
- * @obj: GEM BO
- * @vaddr: Virtual address (unused)
- *
- * Tears down the in-kernel virtual mapping of the BO's memory.
- */
-void amdgp...
2020 Oct 15
0
[PATCH v4 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
...e virtual address of the mapping or an error pointer.
> - */
> -void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
> -{
> - struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> - int ret;
> -
> - ret = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages,
> - &bo->dma_buf_vmap);
> - if (ret)
> - return ERR_PTR(ret);
> -
> - return bo->dma_buf_vmap.virtual;
> -}
> -
> -/**
> - * amdgpu_gem_prime_vunmap - &dma_buf_ops.vunmap implementation
> - * @obj: GEM BO
> - * @vaddr: Virtual address (unused)
> - *
> - * Tears down the in-ker...
2020 Sep 29
0
[PATCH v3 3/7] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
...)
+int amdgpu_gem_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
int ret;
@@ -58,19 +59,20 @@ void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
ret = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages,
&bo->dma_buf_vmap);
if (ret)
- return ERR_PTR(ret);
+ return ret;
+ ttm_kmap_obj_to_dma_buf_map(&bo->dma_buf_vmap, map);
- return bo->dma_buf_vmap.virtual;
+ return 0;
}
/**
* amdgpu_gem_prime_vunmap - &dma_buf_ops.vunmap implementation
* @obj: GEM BO
- * @vaddr: Virtual address (unused)...
2020 Sep 29
14
[PATCH v3 0/7] 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
2020 Sep 29
14
[PATCH v3 0/7] 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
2020 Oct 28
10
[PATCH v6 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
2020 Nov 03
10
[PATCH v7 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
2020 Nov 03
10
[PATCH v7 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
2020 Nov 03
10
[PATCH v7 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
2020 Oct 20
15
[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
2020 Oct 15
19
[PATCH v4 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
2020 May 13
2
[PATCH v3 1/4] dma-buf: add support for virtio exported objects
...* will be populated with the buffer's UUID.
> + */
> + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid);
> };
>
> /**
> @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
> unsigned long);
> void *dma_buf_vmap(struct dma_buf *);
> void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> +
> +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid);
> +
> #endif /* __DMA_BUF_H__ */
> --
> 2.25.1.481.gfbce0eb801-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0...
2020 May 13
2
[PATCH v3 1/4] dma-buf: add support for virtio exported objects
...* will be populated with the buffer's UUID.
> + */
> + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid);
> };
>
> /**
> @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
> unsigned long);
> void *dma_buf_vmap(struct dma_buf *);
> void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> +
> +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid);
> +
> #endif /* __DMA_BUF_H__ */
> --
> 2.25.1.481.gfbce0eb801-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0...
2019 Oct 28
0
[PATCH v2 07/15] drm/radeon: use mmu_range_notifier_insert
...nclude <linux/dma-fence.h>
+#ifdef CONFIG_MMU_NOTIFIER
+#include <linux/mmu_notifier.h>
+#endif
+
#include <drm/ttm/ttm_bo_api.h>
#include <drm/ttm/ttm_bo_driver.h>
#include <drm/ttm/ttm_placement.h>
@@ -509,8 +513,9 @@ struct radeon_bo {
struct ttm_bo_kmap_obj dma_buf_vmap;
pid_t pid;
- struct radeon_mn *mn;
- struct list_head mn_list;
+#ifdef CONFIG_MMU_NOTIFIER
+ struct mmu_range_notifier notifier;
+#endif
};
#define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, tbo.base)
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c b/drivers/gpu/drm...
2019 Oct 29
0
[PATCH v2 07/15] drm/radeon: use mmu_range_notifier_insert
...ONFIG_MMU_NOTIFIER
> +#include <linux/mmu_notifier.h>
> +#endif
> +
> #include <drm/ttm/ttm_bo_api.h>
> #include <drm/ttm/ttm_bo_driver.h>
> #include <drm/ttm/ttm_placement.h>
> @@ -509,8 +513,9 @@ struct radeon_bo {
> struct ttm_bo_kmap_obj dma_buf_vmap;
> pid_t pid;
>
> - struct radeon_mn *mn;
> - struct list_head mn_list;
> +#ifdef CONFIG_MMU_NOTIFIER
> + struct mmu_range_notifier notifier;
> +#endif
> };
> #define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, tbo.base)
>
> diff...
2019 Oct 29
0
[PATCH v2 13/15] drm/amdgpu: Use mmu_range_insert instead of hmm_mirror
...#include "amdgpu.h"
> +#ifdef CONFIG_MMU_NOTIFIER
> +#include <linux/mmu_notifier.h>
> +#endif
>
> #define AMDGPU_BO_INVALID_OFFSET LONG_MAX
> #define AMDGPU_BO_MAX_PLACEMENTS 3
> @@ -100,10 +103,12 @@ struct amdgpu_bo {
> struct ttm_bo_kmap_obj dma_buf_vmap;
> struct amdgpu_mn *mn;
>
> - union {
> - struct list_head mn_list;
> - struct list_head shadow_list;
> - };
> +
> +#ifdef CONFIG_MMU_NOTIFIER
> + struct mmu_range_notifier notifier;
> +#endif
> +
> + struct list_head shadow_list;
>
> struc...
2019 Oct 28
2
[PATCH v2 13/15] drm/amdgpu: Use mmu_range_insert instead of hmm_mirror
...+30,9 @@
#include <drm/amdgpu_drm.h>
#include "amdgpu.h"
+#ifdef CONFIG_MMU_NOTIFIER
+#include <linux/mmu_notifier.h>
+#endif
#define AMDGPU_BO_INVALID_OFFSET LONG_MAX
#define AMDGPU_BO_MAX_PLACEMENTS 3
@@ -100,10 +103,12 @@ struct amdgpu_bo {
struct ttm_bo_kmap_obj dma_buf_vmap;
struct amdgpu_mn *mn;
- union {
- struct list_head mn_list;
- struct list_head shadow_list;
- };
+
+#ifdef CONFIG_MMU_NOTIFIER
+ struct mmu_range_notifier notifier;
+#endif
+
+ struct list_head shadow_list;
struct kgd_mem *kfd_bo;
};
--
2.23.0
2019 Oct 28
32
[PATCH v2 00/15] Consolidate the mmu notifier interval_tree and locking
From: Jason Gunthorpe <jgg at mellanox.com>
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell if the
driver is interested. Half of them use an interval_tree, the others
2019 Nov 12
20
[PATCH hmm v3 00/14] Consolidate the mmu notifier interval_tree and locking
From: Jason Gunthorpe <jgg at mellanox.com>
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating range against some driver data structure to tell if the
driver is interested. Half of them use an interval_tree, the others