linux-toradex.git/drivers/gpu/drm/vmwgfx/ttm_object.c, branch v6.7

drm/vmwgfx: Remove rcu locks from user resources

2023-01-10T02:15:36+00:00

User resource lookups used rcu to avoid two extra atomics. Unfortunately
the rcu paths were buggy and it was easy to make the driver crash by
submitting command buffers from two different threads. Because the
lookups never show up in performance profiles replace them with a
regular spin lock which fixes the races in accesses to those shared
resources.

Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and
seen crashes with apps using shared resources.

Fixes: e14c02e6b699 ("drm/vmwgfx: Look up objects without taking a reference")
Signed-off-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
Link: https://patchwork.freedesktop.org/patch/msgid/20221207172907.959037-1-zack@kde.org

drm/vmwgfx: Remove vmwgfx_hashtab

2022-10-25T16:42:25+00:00

The vmwgfx driver has migrated from using the hashtable in vmwgfx_hashtab
to the linux/hashtable implementation. Remove the vmwgfx_hashtab from the
driver.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Reviewed-by: Zack Rusin 
Signed-off-by: Zack Rusin 
Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-12-zack@kde.org

drm/vmwgfx: Refactor ttm reference object hashtable to use linux/hashtable.

2022-10-25T16:42:24+00:00

This is part of an effort to move from the vmwgfx_open_hash hashtable to
linux/hashtable implementation.
Refactor the ref_hash hashtable, used for fast lookup of reference objects
associated with a ttm file.
This also exposed a problem related to inconsistently using 32-bit and
64-bit keys with this hashtable. The hash function used changes depending
on the size of the type, and results are not consistent across numbers,
for example, hash_32(329) = 329, but hash_long(329) = 328. This would
cause the lookup to fail for objects already in the hashtable, since keys
of different sizes were being passed during adding and lookup. This was
not an issue before because vmwgfx_open_hash always used hash_long.
Fix this by always using 64-bit keys for this hashtable, which means that
hash_long is always used.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Zack Rusin 
Signed-off-by: Zack Rusin 
Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-11-zack@kde.org

drm/vmwgfx: Remove ttm object hashtable

2022-10-25T16:42:19+00:00

The object_hash hashtable for ttm objects is not being used.
Remove it and perform refactoring in ttm_object init function.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Signed-off-by: Zack Rusin 
Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-5-zack@kde.org

drm/vmwgfx: Implement DRIVER_GEM

2021-12-09T18:16:16+00:00

This is initial change adding support for DRIVER_GEM to vmwgfx. vmwgfx
was written before GEM and has always used TTM. Over the years the
TTM buffers started inherting from GEM objects but vmwgfx never
implemented GEM making it quite awkward. We were directly setting
variables in GEM objects to not make DRM crash.

This change brings vmwgfx inline with other DRM drivers and allows us
to use a lot of DRM helpers which have depended on drivers with GEM
support.

Due to historical reasons vmwgfx splits the idea of a buffer and surface
which makes it a littly tricky since either one can be used in most
of our ioctl's which take user space handles. For now our BO's are
GEM objects and our surfaces are opaque objects which are backed by
GEM objects. In the future I'd like to combine those into a single
BO but we don't want to break any of our existing ioctl's so it will
take time to do it in a non-destructive way.

Signed-off-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-5-zack@kde.org

drm/vmwgfx: Remove the dedicated memory accounting

2021-12-09T18:16:10+00:00

vmwgfx shared very elaborate memory accounting with ttm. It was moved
from ttm to vmwgfx in change
f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4")
but because of complexity it was hard to maintain. Some parts of the code
weren't freeing memory correctly and  some were missing accounting all
together. While those would be fairly easy to fix the fundamental reason
for memory accounting in the driver was the ability to invoke shrinker
which is part of TTM code as well (with support for unified memory
hopefully coming soon).

That meant that vmwgfx had a lot of code that was either unused or
duplicating code from TTM. Removing this code also prevents excessive
calls to global swapout which were common during memory pressure
because both vmwgfx and TTM would invoke the shrinker when memory
usage reached half of RAM.

Fixes: f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4")
Signed-off-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-2-zack@kde.org

drm/vmwgfx: Copy DRM hash-table code into driver

2021-11-30T08:41:25+00:00

Besides some legacy code, vmwgfx is the only user of DRM's hash-
table implementation. Copy the code into the driver, so that the
core code can be retired.

No functional changes. However, the real solution for vmwgfx is to
use Linux' generic hash-table functions.

v2:
	* add TODO item for updating vmwgfx (Sam)

Signed-off-by: Thomas Zimmermann 
Acked-by: Daniel Vetter 
Acked-by: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20211129094841.22499-3-tzimmermann@suse.de

dma-buf: move dma-buf symbols into the DMA_BUF module namespace

2021-10-25T12:53:08+00:00

In order to better track where in the kernel the dma-buf code is used,
put the symbols in the namespace DMA_BUF and modify all users of the
symbols to properly import the namespace to not break the build at the
same time.

Now the output of modinfo shows the use of these symbols, making it
easier to watch for users over time:

$ modinfo drivers/misc/fastrpc.ko | grep import
import_ns:      DMA_BUF

Cc: "Pan, Xinhui" 
Cc: David Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Mauro Carvalho Chehab 
Cc: dri-devel@lists.freedesktop.org
Acked-by: Daniel Vetter 
Acked-by: Christian König 
Acked-by: Arnd Bergmann 
Acked-by: Sumit Semwal 
Acked-by: Alex Deucher 
Link: https://lore.kernel.org/r/20211010124628.17691-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: replace idr_init() by idr_init_base()

2021-04-29T18:54:54+00:00

idr_init() uses base 0 which is an invalid identifier for this driver.
The idr_alloc for this driver uses 1 as start value for ID range. The
new function idr_init_base allows IDR to set the ID lookup from base 1.
This avoids all lookups that otherwise starts from 0 since 0 is always
unused / available.

References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")

Signed-off-by: Deepak R Varma 
Signed-off-by: Zack Rusin 
Link: https://patchwork.freedesktop.org/patch/msgid/20201105190718.GA89863@localhost

drm/vmwgfx/ttm_object: Reorder header to immediately precede its struct

2021-01-19T19:19:12+00:00

Also add missing description for 'refcount'

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/vmwgfx/ttm_object.c:60: error: Cannot parse struct or union!

Cc: VMware Graphics 
Cc: Roland Scheidegger 
Cc: Zack Rusin 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: Dave Airlie 
Cc: Rob Clark 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Signed-off-by: Lee Jones 
Signed-off-by: Zack Rusin 
Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-30-lee.jones@linaro.org