similar to: [PATCH v2 0/6] Unmappable DRM client buffers for fbdev emulation

Displaying 20 results from an estimated 2000 matches similar to: "[PATCH v2 0/6] Unmappable DRM client buffers for fbdev emulation"

2019 Jul 03
11
[PATCH 0/5] Unmappable DRM client buffers for fbdev emulation
DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enougth space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer
2019 Jul 03
11
[PATCH 0/5] Unmappable DRM client buffers for fbdev emulation
DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enougth space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer
2019 Jul 03
1
[PATCH 1/5] drm/client: Support unmapping of DRM client buffers
Den 03.07.2019 10.32, skrev Thomas Zimmermann: > DRM clients, such as the fbdev emulation, have their buffer objects > mapped by default. Mapping a buffer implicitly prevents its relocation. > Hence, the buffer may permanently consume video memory while it's > allocated. This is a problem for drivers of low-memory devices, such as > ast, mgag200 or older framebuffer hardware,
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 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 22
2
[PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
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
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 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
2019 Apr 29
21
[PATCH v3 00/19] Share TTM code among DRM framebuffer drivers
Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same
2019 May 08
22
[PATCH v5 00/20] Share TTM code among DRM framebuffer drivers
Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same
2019 May 08
22
[PATCH v5 00/20] Share TTM code among DRM framebuffer drivers
Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same
2019 Apr 24
21
[PATCH v2 00/17] Share TTM code among DRM framebuffer drivers
Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same
2019 May 06
25
[PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same
2019 May 06
25
[PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same
2019 Jul 03
0
[PATCH 5/5] drm/mgag200: Replace struct mga_fbdev with generic framebuffer emulation
This patch replaces mgag200's framebuffer console with DRM's generic implememtation. All respective code is being removed from the driver. The console is set up with a shadow buffer. The actual buffer object is not permanently pinned in video ram, but just another buffer object that the driver moves in and out of vram as necessary. The driver's function mga_crtc_do_set_base() used to
2019 Jul 05
0
[PATCH v2 1/6] drm/client: Support unmapping of DRM client buffers
DRM clients, such as the fbdev emulation, have their buffer objects mapped by default. Mapping a buffer implicitly prevents its relocation. Hence, the buffer may permanently consume video memory while it's allocated. This is a problem for drivers of low-memory devices, such as ast, mgag200 or older framebuffer hardware, which will then not have enough memory to display other content (e.g.,