search for: dma_buf_map

...a2 100644 > --- a/include/linux/dma-buf-map.h > +++ b/include/linux/dma-buf-map.h > @@ -32,6 +32,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 <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 <dma_buf_map>` > +...

...d 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 and #2 prepare VRAM helpers and TTM for the changes in patch #3. Patch #3 updates GEM's vmap/vunmap callback to forward instances of t...

...d 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 and #2 prepare VRAM helpers and TTM for the changes in patch #3. Patch #3 updates GEM's vmap/vunmap callback to forward instances of t...

Am 15.10.20 um 14:38 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 TT...

Instances of struct dma_buf_map should be useful throughout DRM's memory management code. Furthermore, several drivers can now use generic fbdev emulation. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- Documentation/gpu/todo.rst | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletio...

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 GEM backends, this simply change the returned type. GEM VRAM helpers are also updated to indicate whether the returned framebuffer address is in system or I/O memory. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm...

...ap.h index 2e8bbecb5091..6ca0f304dda2 100644 --- a/include/linux/dma-buf-map.h +++ b/include/linux/dma-buf-map.h @@ -32,6 +32,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 <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 <dma_buf_map>` + * solves this proble...

GEM's vmap and vunmap interfaces now wrap memory pointers in struct dma_buf_map. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_client.c | 18 +++++++++++------- drivers/gpu/drm/drm_gem.c | 28 ++++++++++++++-------------- drivers/gpu/drm/drm_internal.h | 5 +++-- drivers/gpu/drm/drm_prime.c | 14 ++++---------- 4 files cha...

...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 <linux/io.h> +#include <linux/string.h> /** * 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 <dma...

...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 <linux/io.h> +#include <linux/string.h> /** * 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 <dma...

...s 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. > > 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 >...

On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote: > 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:...

...d 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 T...

...d 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 T...

...u, Oct 15, 2020 at 04:08:13PM +0200, Christian K?nig wrote: > > Am 15.10.20 um 14:38 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}(), > > &gt...

...d 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 T...

...d 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 T...

...d 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 T...

...memory, the callback >>> functions in struct fb_ops test for the type of memory and call the rsp >>> fb_sys_ of fb_cfb_ functions. >>> >>> 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...

...d 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 T...