linux-toradex.git/drivers/gpu/drm/virtio/virtgpu_object.c, branch v5.5-rc3

drm/shmem: switch shmem helper to &drm_gem_object_funcs.mmap

2019-10-17T11:59:16+00:00

Switch gem shmem helper to the new mmap() workflow,
from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap.

v2: Fix vm_flags and vm_page_prot handling.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Steven Price 
Acked-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-3-kraxel@redhat.com

drm/virtio: switch from ttm to gem shmem helpers

2019-09-04T04:54:11+00:00

virtio-gpu basically needs a sg_table for the bo, to tell the host where
the backing pages for the object are.  So the gem shmem helpers are a
perfect fit.  Some drm_gem_object_funcs need thin wrappers to update the
host state, but otherwise the helpers handle everything just fine.

Once the fencing was sorted the switch was surprisingly easy and for the
most part just removing the ttm code.

v4: fix drm_gem_object_funcs name.

Signed-off-by: Gerd Hoffmann 
Acked-by: Daniel Vetter 
Reviewed-by: Chia-I Wu 
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-15-kraxel@redhat.com

drm/virtio: rework virtio_gpu_object_create fencing

2019-09-04T04:54:09+00:00

Rework fencing workflow.  Stop using ttm helpers, use the
virtio_gpu_array_* helpers instead.

Due to using the gem reservation object it is initialized and ready for
use before calling ttm_bo_init.  So we can simply use the standard
fencing workflow and drop the tricky logic which checks whenever the
command is in flight still.

v6: rewrite most of the patch.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Chia-I Wu 
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-10-kraxel@redhat.com

drm/virtio: remove virtio_gpu_object_wait

2019-09-04T04:54:08+00:00

No users left.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Daniel Vetter 
Reviewed-by: Chia-I Wu 
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-5-kraxel@redhat.com

drm/virtio: pass gem reservation object to ttm init

2019-09-04T04:54:07+00:00

With this gem and ttm will use the same reservation object,
so mixing and matching ttm / gem reservation helpers should
work fine.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Daniel Vetter 
Reviewed-by: Chia-I Wu 
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-2-kraxel@redhat.com

drm/virtio: module_param_named() requires linux/moduleparam.h

2019-08-28T09:11:57+00:00

Fixes: 3e93bc2a58aa ("drm/virtio: make resource id workaround runtime switchable.")
Signed-off-by: Stephen Rothwell 
Link: http://patchwork.freedesktop.org/patch/msgid/20190828185516.22b03da8@canb.auug.org.au
Signed-off-by: Gerd Hoffmann

drm/virtio: make resource id workaround runtime switchable.

2019-08-27T05:35:08+00:00

Also update the comment with a reference to the virglrenderer fix.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Chia-I Wu 
Link: http://patchwork.freedesktop.org/patch/msgid/20190822102614.18164-1-kraxel@redhat.com

drm/virtio: rework resource creation workflow.

2019-03-28T11:11:56+00:00

This patch moves the virtio_gpu_cmd_create_resource() call (which
notifies the host about the new resource created) into the
virtio_gpu_object_create() function.  That way we can call
virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
already knows about the object when ttm initializes the object and calls
our driver callbacks.

Specifically the object is already created when the
virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(),
so the extra virtio_gpu_object_attach() calls done after
virtio_gpu_object_create() are not needed any more.

The fence support for the create ioctl becomes a bit more tricky though.
The code moved into virtio_gpu_object_create() too.  We first submit the
(fenced) virtio_gpu_cmd_create_resource() command, then initialize the
ttm object, and finally attach just created object to the fence for the
command in case it didn't finish yet.

Signed-off-by: Gerd Hoffmann 
Acked-by: Noralf Trønnes 
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-6-kraxel@redhat.com

drm/virtio: use struct to pass params to virtio_gpu_object_create()

2019-03-28T11:11:55+00:00

Create virtio_gpu_object_params, use that to pass object parameters to
virtio_gpu_object_create.  This is just the first step, followup patches
will add more parameters to the struct.  The plan is to use the struct
for all object parameters.

Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is
unused and always false.

Also drop "pinned" parameter.  virtio-gpu doesn't shuffle around
objects, so effecively they all are pinned anyway.  Hardcode
TTM_PL_FLAG_NO_EVICT so ttm knows.  Doesn't change much for the moment
as virtio-gpu supports TTM_PL_FLAG_TT only so there is no opportunity to
move around objects.  That'll probably change in the future though.

Signed-off-by: Gerd Hoffmann 
Acked-by: Noralf Trønnes 
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-3-kraxel@redhat.com

drm/virtio: do NOT reuse resource ids

2019-02-11T04:44:10+00:00

Bisected guest kernel changes crashing qemu.  Landed at
"6c1cd97bda drm/virtio: fix resource id handling".  Looked again, and
noticed we where not only leaking *some* ids, but *all* ids.  The old
code never ever called virtio_gpu_resource_id_put().

So, commit 6c1cd97bda effectively makes the linux kernel starting
re-using IDs after releasing them, and apparently virglrenderer can't
deal with that.  Oops.

This patch puts a temporary stopgap into place for the 5.0 release.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Dave Airlie 
Signed-off-by: Dave Airlie 
Link: https://patchwork.freedesktop.org/patch/msgid/20190208140409.15280-1-kraxel@redhat.com