diff options
author | Gerd Hoffmann <kraxel@redhat.com> | 2019-03-18 12:33:32 +0100 |
---|---|---|
committer | Gerd Hoffmann <kraxel@redhat.com> | 2019-03-28 12:11:56 +0100 |
commit | 530b28426a94b822b3c03491cde5c9a961d80e7f (patch) | |
tree | 36c5318d00ff7c3d8903d929dea99ce26cd4e4b8 /net/core/dst.c | |
parent | fd4d6a4277713b647885f68543b4216150540fca (diff) | |
download | linux-530b28426a94b822b3c03491cde5c9a961d80e7f.tar.gz linux-530b28426a94b822b3c03491cde5c9a961d80e7f.tar.bz2 linux-530b28426a94b822b3c03491cde5c9a961d80e7f.zip |
drm/virtio: rework resource creation workflow.
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 <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-6-kraxel@redhat.com
Diffstat (limited to 'net/core/dst.c')
0 files changed, 0 insertions, 0 deletions