It always returns zero.
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200401223039.2860-4-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

A resource will be a shmem based resource or a (planned)
vram based resource, so it makes sense to factor out common fields
(resource handle, dumb).

v2: move mapped field to shmem object
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-1-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Move all remaining virtio_gpu_notify() calls from virtio_gpu_cmd_*
to the callers, for consistency reasons.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-7-kraxel@redhat.com

Move virtio_gpu_notify() to higher-level functions for
virtio_gpu_cmd_get_display_info() and virtio_gpu_cmd_get_edids().

virtio_gpu_config_changed_work_func() and virtio_gpu_init() will
batch commands and notify only once per update
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-6-kraxel@redhat.com

Move virtio_gpu_notify() to higher-level functions for
virtio_gpu_cmd_create_resource(), virtio_gpu_cmd_resource_create_3d()
and virtio_gpu_cmd_resource_attach_backing().

virtio_gpu_object_create() will batch commands and notify only once when
creating a resource.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-5-kraxel@redhat.com

Move virtio_gpu_notify() to higher-level functions for
virtio_gpu_cmd_resource_flush(), virtio_gpu_cmd_set_scanout() and
virtio_gpu_cmd_transfer_to_host_{2d,3d}().

virtio_gpu_primary_plane_update() will notify only once for a series
of commands (restores plane update command batching).
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-4-kraxel@redhat.com

Before we are going to wait for virtqueue entries becoming available
call virtio_gpu_notify() to make sure the host has seen everything
we've submitted.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-3-kraxel@redhat.com

Drop the virtio_gpu_{disable,enable}_notify().  Add a new
virtio_gpu_notify() call instead, which must be called whenever
the driver wants make sure the host is notified needed.

Drop automatic notification from command submission.  Add
virtio_gpu_notify() calls after each command query instead.
This allows more fine-grained control over host notification
and can move around the notify calls in subsequent patches to
batch command submissions. With this in place it is also
possible to make notification optional for userspace ioctls.

Page flip batching goes away (temporarely).

v3:
 - move batching to separate patches.
v2:
 - rebase to latest drm-misc-next.
 - use "if (!atomic_read())".
 - add review & test tags.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Tested-by: NGurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-2-kraxel@redhat.com

The >= compare op must happen in cpu byte order, doing it in
little endian fails on big endian machines like s390.
Reported-by: NSebastian Mitterle <smitterl@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214080100.1273-1-kraxel@redhat.com

Split virtio_gpu_deinit(), move the drm shutdown and release to
virtio_gpu_release().  Drop vqs_ready variable, instead use
drm_dev_{enter,exit,unplug} to avoid touching hardware after
device removal.  Tidy up here and there.

v4: add changelog.
v3: use drm_dev_*().
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20200211135805.24436-1-kraxel@redhat.com

Introduce new virtio_gpu_object_shmem_init() helper function which will
create the virtio_gpu_mem_entry array, containing the backing storage
information for the host.  For the most path this just moves code from
virtio_gpu_object_attach().
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207074638.26386-5-kraxel@redhat.comReviewed-by: NChia-I Wu <olvaffe@gmail.com>

Stop sending DETACH_BACKING commands, that will happening anyway when
releasing resources via UNREF.  Handle guest-side cleanup in
virtio_gpu_cleanup_object(), called when the host finished processing
the UNREF command.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207074638.26386-4-kraxel@redhat.comReviewed-by: NChia-I Wu <olvaffe@gmail.com>

Add new virtio_gpu_cleanup_object() helper function for object cleanup.
Wire up callback function for resource unref, do cleanup from callback
when we know the host stopped using the resource.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207074638.26386-3-kraxel@redhat.comReviewed-by: NChia-I Wu <olvaffe@gmail.com>

Just call virtio_gpu_alloc_cmd_resp with some fixed args
instead of duplicating most of the function body.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207074638.26386-2-kraxel@redhat.comReviewed-by: NChia-I Wu <olvaffe@gmail.com>

If the virtio device supports indirect ring descriptors we need only one
ring entry for the whole command.  Take that into account when checking
whenever the virtqueue has enough free entries for our command.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207064653.14403-1-kraxel@redhat.com

It becomes clear that virtio_gpu_queue_fenced_ctrl_buffer should be
responsible for setting up sgs and virtio_gpu_queue_ctrl_sgs should
be responsible for queuing sgs.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-11-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

When vqs_ready is false, vq should be considered invalid and we
should not check vq->num_free.  After this change, a fenced command
queued before the vqs are ready will have fence id 0 and will be
considered done.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-9-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-8-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

sgs setup does not need to be in the critical section.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-7-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

We don't propagate erros to the callers.  We have to unlock object
arrays on errors.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-6-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

We can get it from vbuf.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-5-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

It is a helper to return the virtio_gpu_ctrl_hdr in a vbuf.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-4-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

The handling of virtqueue_add_sgs ENOSPC error is incorrect because
it can result in out-of-order virtqueue_add_sgs and break fences.
We never get ENOSPC anyway because the caller waits until there is
enough space (the other caller that did not wait was removed in
commit 32d6c2c5 ("drm/virtio: Rewrite virtio_gpu_queue_ctrl_buffer
using fenced version.")).  Remove the incorrect and unnecessary error
path.

This also adds a WARN_ON(ret) until we properly handle errors.
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Cc: David Riley <davidriley@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-3-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

outcnt may be greater than 1 since commit e1218b8c ("drm/virtio:
Use vmalloc for command buffer allocations.").

Fixes: e1218b8c ("drm/virtio: Use vmalloc for command buffer allocations.")
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Cc: David Riley <davidriley@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205181955.202485-2-olvaffe@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Avoid flooding the log in case we screw up badly.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200205102552.21409-1-kraxel@redhat.com

When the driver submits multiple commands in a row it makes sense to
notify the host only after submitting the last one, so the host can
process them all at once, with a single vmexit.

Add functions to enable/disable notifications to allow that.  Use the
new functions for primary plane updates.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20191212125346.8334-3-kraxel@redhat.com

Be consistent with the rest of the code base.
No functional change.

v2:
 - fix sparse warnings for virtio_gpu_cmd_transfer_to_host_2d call.
 - move convert_to_hw_box helper function.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20191023062539.11728-2-kraxel@redhat.com

Be consistent with the rest of the code base.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191018122352.17019-1-kraxel@redhat.com

Fix warning introduced with commit e1218b8c
("drm/virtio: Use vmalloc for command buffer allocations.")
from drm-misc-next.
Signed-off-by: NDavid Riley <davidriley@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190912160048.212495-1-davidriley@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Userspace requested command buffer allocations could be too large
to make as a contiguous allocation.  Use vmalloc if necessary to
satisfy those allocations.
Signed-off-by: NDavid Riley <davidriley@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190911181403.40909-3-davidriley@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Factor function in preparation to generating scatterlist prior to locking.
Signed-off-by: NDavid Riley <davidriley@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190911181403.40909-2-davidriley@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Only call virtio_gpu_array_add_fence if we actually have a fence.

Fixes: da758d51 ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing")
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190904074828.32502-1-kraxel@redhat.com

Move object release into a separate worker.  Releasing objects requires
sending commands to the host.  Doing that in the dequeue worker will
cause deadlocks in case the command queue gets filled up, because the
dequeue worker is also the one which will free up slots in the command
queue.
Reported-by: NChia-I Wu <olvaffe@gmail.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Tested-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190830060116.10476-1-kraxel@redhat.com

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: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-15-kraxel@redhat.com

Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-13-kraxel@redhat.com

Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-12-kraxel@redhat.com

Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-11-kraxel@redhat.com

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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-10-kraxel@redhat.com

Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl.
Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work
on the reservation objects directly) instead.

Also store the object array in struct virtio_gpu_vbuffer, so we
explicitly keep a reference of all buffers used instead of depending
on ttm_bo_put() checking whenever the object is actually idle before
releasing it.

New workflow:

 (1) All gem objects needed by a command are added to a
     virtio_gpu_object_array.
 (2) All reservation objects will be locked (virtio_gpu_array_lock_resv).
 (3) virtio_gpu_fence_emit() completes fence initialization.
 (4) fence gets added to the objects, reservation objects are unlocked
     (virtio_gpu_array_add_fence, virtio_gpu_array_unlock_resv).
 (5) virtio command is submitted to the host.
 (6) The completion callback (virtio_gpu_dequeue_ctrl_func)
     will drop object references and free virtio_gpu_object_array.

v6: rewrite most of the patch.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-9-kraxel@redhat.com

Split virtqueue_kick() call into virtqueue_kick_prepare(), which
requires serialization, and virtqueue_notify(), which does not.  Move
the virtqueue_notify() call out of the critical section protected by the
queue lock.  This avoids triggering a vmexit while holding the lock and
thereby fixes a rather bad spinlock contention.
Suggested-by: NChia-I Wu <olvaffe@gmail.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190813082509.29324-3-kraxel@redhat.com