[PATCH v4 0/4] Implement lazy unmapping for GEM VRAM buffers

[Davidlohr Bueso]

On Fri, 06 Sep 2019, Thomas Zimmermann wrote:

>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 and later of the patch set, this problem is being solved by lazily
>unmapping the buffer as suggested by Gerd. Unmapping with drm_gem_vram_kunmap()
>only changes a reference counter. VRAM helpers later 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().
>
>v4:
>	* lock kmap with ttm_bo_reserve()
>	* acquire lock only once for vmap()
>	* warn about stale mappings during buffer cleanup
>v3:
>      	* implement lazy unmapping
>v2:
>	* fixed comment typos
>
>[1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html
>
>Thomas Zimmermann (4):
>  drm/vram: Add kmap ref-counting to GEM VRAM objects
>  drm/vram: Acquire lock only once per call to vmap()/vunmap()
>  drm/vram: Add infrastructure for move_notify()
>  drm/vram: Implement lazy unmapping for GEM VRAM buffers
>
> drivers/gpu/drm/drm_gem_vram_helper.c | 229 ++++++++++++++++++--------
> drivers/gpu/drm/drm_vram_mm_helper.c  |  12 ++
> include/drm/drm_gem_vram_helper.h     |  18 ++
> include/drm/drm_vram_mm_helper.h      |   4 +
> 4 files changed, 198 insertions(+), 65 deletions(-)

Thanks for the prompt fix, feel free to add my:

Reported-and-tested-by: Davidlohr Bueso <dbueso at suse.de>