similar to: [PATCH v3 02/12] drm/virtio: pass gem reservation object to ttm init

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 <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index

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 <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index

On Mon, Jun 17, 2019 at 01:14:03PM +0200, Gerd Hoffmann wrote: > 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 <kraxel at redhat.com> While doing my prime doc+cleanup series I wondered whether we should do this for everyone, and perhaps even remove

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 <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

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 <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

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 <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

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 <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

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 <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

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

Create virtio_gpu_object_params, use that to pass object parameters to virtio_gpu_object_create. Also drop unused "kernel" parameter (unused, always false). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 15 ++++++++++----- drivers/gpu/drm/virtio/virtgpu_gem.c | 18 +++++++++++------- drivers/gpu/drm/virtio/virtgpu_ioctl.c |

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

Specifically call virtio_gpu_object_create() before ttm_bo_init(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++ drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +-- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 ++-------- drivers/gpu/drm/virtio/virtgpu_object.c | 10 ++++++++-- 4 files changed, 13 insertions(+), 12 deletions(-) diff

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:

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.

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.

. On Wed, Jun 19, 2019 at 11:08 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > 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. >

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. v5:

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v5: fix fencing (Chia-I Wu). v3: Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init, so we can also drop the tricky fence logic which checks whenever the command is in flight still. We can simply fence our object before submitting the virtio command and be done

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v3: Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init, so we can also drop the tricky fence logic which checks whenever the command is in flight still. We can simply fence our object before submitting the virtio command and be done with it. Signed-off-by: Gerd

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