(was: ast, mgag200: Map console BO while it's being displayed)
Generic fbdev emulation maps and unmaps the console BO for updating it's
content from the shadow buffer. If this involves an actual mapping
operation (instead of reusing an existing mapping), lots of debug messages
may be printed, such as
x86/PAT: Overlap at 0xd0000000-0xd1000000
x86/PAT: reserve_memtype added [mem 0xd0000000-0xd02fffff], track write-combining, req write-combining, ret write-combining
x86/PAT: free_memtype request [mem 0xd0000000-0xd02fffff]
as reported at [1]. Drivers using VRAM helpers may also see reduced
performance as the mapping operations can create overhead.
In v3 of the patch set, this problem is being solved by lazyly unmapping
the buffer as suggested by Gerd. Unmapping with drm_gem_vram_kunmap() only
changes a reference counter. VRAM helpers only perform the unmapping
operation when TTM evicts the buffer object from its current location. If
the buffer is never evicted, the existing mapping is reused by later calls
to drm_gem_vram_kmap().
v3:
* implement lazy unmapping
v2:
* fixed comment typos
[1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html
Thomas Zimmermann (3):
drm/vram: Add kmap ref-counting to GEM VRAM objects
drm/vram: Add infrastructure for move_notify()
drm/vram: Implement lazy unmapping for GEM VRAM buffers
drivers/gpu/drm/drm_gem_vram_helper.c | 112 +++++++++++++++++++++-----
drivers/gpu/drm/drm_vram_mm_helper.c | 12 +++
include/drm/drm_gem_vram_helper.h | 23 ++++++
include/drm/drm_vram_mm_helper.h | 4 +
4 files changed, 130 insertions(+), 21 deletions(-)
--
2.23.0
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
