Commit Graph

2 Commits

Author SHA1 Message Date
Zack Rusin
4e07d71c0d drm/vmwgfx: Fix a size_t/long int format specifier mismatch
On i386 size_t is of course 32bits and using long int throws warnings,
trivially fix it by using the dedicated size_t format.

This is enough to fix the following warning found by the kernel test
robot:
   drivers/gpu/drm/vmwgfx/vmwgfx_gem.c: In function 'vmw_bo_print_info':
>> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c:230:33: warning: format '%ld'
expects argument of type 'long int', but argument 4 has type 'size_t'
{aka 'unsigned int'} [-Wformat=]
     230 |  seq_printf(m, "\t\t0x%08x: %12ld bytes %s, type = %s",
         |                             ~~~~^
         |                                 |
         |                                 long int
         |                             %12d
     231 |      id, bo->base.base.size, placement, type);
         |          ~~~~~~~~~~~~~~~~~~
         |                       |

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: 8afa13a058 ("drm/vmwgfx: Implement DRIVER_GEM")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-1-zack@kde.org
(cherry picked from commit 72345114c9)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2021-12-17 16:34:02 +01:00
Zack Rusin
8afa13a058 drm/vmwgfx: Implement DRIVER_GEM
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 <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-5-zack@kde.org
2021-12-09 13:16:16 -05:00