diff options
author | Maaz Mombasawala <mombasawalam@vmware.com> | 2022-10-22 00:02:29 -0400 |
---|---|---|
committer | Zack Rusin <zackr@vmware.com> | 2022-10-25 12:42:24 -0400 |
commit | 76a9e07f270cf5fb556ac237dbf11f5dacd61fef (patch) | |
tree | d61159647643c341b61d939a8b56453dba6a84c7 /Documentation/gpu | |
parent | bb6780aa5a1d99e86757c0c96bfae65a46cf839e (diff) | |
download | linux-stable-76a9e07f270cf5fb556ac237dbf11f5dacd61fef.tar.gz linux-stable-76a9e07f270cf5fb556ac237dbf11f5dacd61fef.tar.bz2 linux-stable-76a9e07f270cf5fb556ac237dbf11f5dacd61fef.zip |
drm/vmwgfx: Refactor ttm reference object hashtable to use linux/hashtable.
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 <mombasawalam@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-11-zack@kde.org
Diffstat (limited to 'Documentation/gpu')
0 files changed, 0 insertions, 0 deletions