summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/virtio/virtgpu_fence.c
AgeCommit message (Collapse)AuthorFilesLines
2021-09-29drm/virtio: implement context init: add virtio_gpu_fence_eventGurchetan Singh1-0/+10
Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event to the DRM file descriptor when a fence on a specific ring is signaled. One difference is the event is not exposed via the UAPI -- this is because host responses are on a shared memory buffer of type BLOB_MEM_GUEST [this is the common way to receive responses with virtgpu]. As such, there is no context specific read(..) implementation either -- just a poll(..) implementation. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-12-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-29drm/virtio: implement context init: stop using drv->context when creating fenceGurchetan Singh1-2/+14
The plumbing is all here to do this. Since we always use the default fence context when allocating a fence, this makes no functional difference. We can't process just the largest fence id anymore, since it's it's associated with different timelines. It's fine for fence_id 260 to signal before 259. As such, process each fence_id individually. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-9-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-29drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to ↵Gurchetan Singh1-1/+3
virtio_gpu_fence_alloc These were defined in the previous commit. We'll need these parameters when allocating a dma_fence. The use case for this is multiple synchronizations timelines. The maximum number of timelines per 3D instance will be 32. Usually, only 2 are needed -- one for CPU commands, and another for GPU commands. As such, we'll need to specify these parameters when allocating a dma_fence. vgdev->fence_drv.context is the "default" fence context for 2D mode and old userspace. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-8-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-12-02drm/virtio: consider dma-fence context when signalingGurchetan Singh1-9/+30
This an incremental refactor towards multiple dma-fence contexts in virtio-gpu. Since all fences are still allocated using &virtio_gpu_fence_driver.context, nothing should break and every processed fence will be signaled. The overall idea is every 3D context can allocate a number of dma-fence contexts. Each dma-fence context refers to it's own timeline. For example, consider the following case where virgl submits commands to the GPU (fence ids 1, 3) and does a metadata query with the CPU (fence id 5). In a different process, gfxstream submits commands to the GPU (fence ids 2, 4). fence_id (&dma_fence.seqno) | 1 2 3 4 5 ----------------------------------|----------- fence_ctx 0 (virgl gpu) | 1 3 fence_ctx 1 (virgl metadata query)| 5 fence_ctx 2 (gfxstream gpu) | 2 4 With multiple fence contexts, we can wait for the metadata query to finish without waiting for the virgl gpu to finish. virgl gpu does not have to wait for gfxstream gpu. The fence id still is the monotonically increasing sequence number, but it's only revelant to the specific dma-fence context. To fully enable this feature, we'll need to: - have each 3d context allocate a number of fence contexts. Not too hard with explicit context initialization on the horizon. - have guest userspace specify fence context when performing ioctls. - tag each fence emitted to the host with the fence context information. virtio_gpu_ctrl_hdr has padding + flags available, so that should be easy. This change goes in the direction specified above, by: - looking up the virtgpu_fence given a fence_id - signalling all prior fences in a given context - signalling current fence v2: fix grammar in comment v3: add r-b tags Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-12-02drm/virtio: rework virtio_fence_signaledGurchetan Singh1-8/+4
virtio_gpu_fence_event_process sets the last_fence_id and subsequently calls dma_fence_signal_locked(..). dma_fence_signal_locked(..) sets DMA_FENCE_FLAG_SIGNALED_BIT, which is actually checked before &dma_fence_ops.(*signaled) is called. The check for last_fence_id is therefore a bit redundant, and it will not be sufficient to check the last_fence_id for multiple synchronization timelines. Remove it. v3: add r-b tags Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-12-02drm/virtio: virtio_{blah} --> virtio_gpu_{blah}Gurchetan Singh1-15/+17
virtio_gpu typically uses the prefix virtio_gpu, but there are a few places where the virtio prefix is used. Modify this for consistency. v3: add r-b tags Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-11-20drm/virtio: rename sync_seq and last_seqGurchetan Singh1-4/+5
To be clearer about our intentions to associate sequence numbers and fence IDs, let's rename these variables. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-11-20drm/virtio: use fence_id when processing fencesGurchetan Singh1-3/+3
Currently, the fence ID, which can be used to identify a virtgpu fence, is the same as the fence sequence number. Let's use the fence_id name to clearly signal this. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-4-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-12-19drm/virtio: move to_virtio_fence inside virtgpu_fenceGurchetan Singh1-0/+3
That's the only file that uses it. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-12-19drm/virtio: static-ify virtio_fence_signaledGurchetan Singh1-1/+1
Not used anywhere else. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-09-04drm/virtio: add fence sanity checkGerd Hoffmann1-0/+4
Make sure we don't leak half-initialized fences outside the driver. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-19-kraxel@redhat.com
2019-07-15drm/virtgpu: drop use of drmP.hSam Ravnborg1-1/+1
Drop use of the deprecated drmP.h header file. Fix fallout by adding missing include files. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Emil Velikov <emil.velikov@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20190630061922.7254-28-sam@ravnborg.org
2019-05-06drm/virtio: Remove redundant return typeRobert Foss1-2/+1
virtio_gpu_fence_emit() always returns 0, since it has no error paths. Consequently no calls for virtio_gpu_fence_emit() use the return value, and it can be removed. Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190506091034.30289-1-robert.foss@collabora.com Suggested-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-06drm/virtio: allocate fences with GFP_KERNELChia-I Wu1-1/+1
It was changed to GFP_ATOMIC in commit ec2f0577c (add & use virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened with a spinlock held. That was no longer true after commit 9fdd90c0f (add virtio_gpu_alloc_fence()). Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190429221021.159784-1-olvaffe@gmail.com Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.com> Cc: Robert Foss <robert.foss@collabora.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-06drm/virtio: trace drm_fence_emitChia-I Wu1-0/+3
For most drivers, drm_fence_init is followed by drm_fence_emit immediately. But for our driver, they are done separately. We also don't know the fence seqno until drm_fence_emit. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-2-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-06drm/virtio: set seqno for dma-fenceChia-I Wu1-7/+10
This is motivated by having meaningful ftrace events, but it also fixes use cases where dma_fence_is_later is called, such as in sync_file_merge. In other drivers, fence creation and cmdbuf submission normally happen atomically, mutex_lock(); fence = dma_fence_create(..., ++timeline->seqno); submit_cmdbuf(); mutex_unlock(); and have no such issue. But in our driver, because most ioctls queue commands into ctrlq, we do not want to grab a lock. Instead, we set seqno to 0 when a fence is created, and update it when the command is finally queued and the seqno is known. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-1-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-03-28drm/virtio: rework resource creation workflow.drm-misc-next-2019-03-28-1Gerd Hoffmann1-2/+2
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
2019-01-08drm/virtio: drop virtio_gpu_fence_cleanup()Gerd Hoffmann1-8/+0
Just call drm_fence_put directly instead. Also set vgfb->fence to NULL after dropping the reference. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181219122708.4586-4-kraxel@redhat.com
2018-11-29drm/virtio: fence: pass plain pointerGerd Hoffmann1-5/+5
Since commit "9fdd90c0f4 drm/virtio: add virtio_gpu_alloc_fence()" fences are not allocated any more by virtio_gpu_fence_emit(). So there is no need to pass down a reference to the fence pointer, a plain pointer is enough now. Convert virtio_gpu_fence_emit() and callers. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Robert Foss <robert.foss@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181128151021.29565-2-kraxel@redhat.com
2018-11-14drm/virtio: add virtio_gpu_alloc_fence()Robert Foss1-7/+22
Refactor fence creation, add fences to relevant GPU operations and add cursor helper functions. This removes the potential for allocation failures from the cmd_submit and atomic_commit paths. Now a fence will be allocated first and only after that will we proceed with the rest of the execution. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Robert Foss <robert.foss@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-2-robert.foss@collabora.com Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-07-03drm/virtio: Remove unecessary dma_fence_opsDaniel Vetter1-7/+0
dma_fence_default_wait is the default now, same for the trivial enable_signaling implementation. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20180503142603.28513-15-daniel.vetter@ffwll.ch
2016-10-25dma-buf: Rename struct fence to dma_fenceChris Wilson1-13/+13
I plan to usurp the short name of struct fence for a core kernel struct, and so I need to rename the specialised fence/timeline for DMA operations to make room. A consensus was reached in https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html that making clear this fence applies to DMA operations was a good thing. Since then the patch has grown a bit as usage increases, so hopefully it remains a good thing! (v2...: rebase, rerun spatch) v3: Compile on msm, spotted a manual fixup that I broke. v4: Try again for msm, sorry Daniel coccinelle script: @@ @@ - struct fence + struct dma_fence @@ @@ - struct fence_ops + struct dma_fence_ops @@ @@ - struct fence_cb + struct dma_fence_cb @@ @@ - struct fence_array + struct dma_fence_array @@ @@ - enum fence_flag_bits + enum dma_fence_flag_bits @@ @@ ( - fence_init + dma_fence_init | - fence_release + dma_fence_release | - fence_free + dma_fence_free | - fence_get + dma_fence_get | - fence_get_rcu + dma_fence_get_rcu | - fence_put + dma_fence_put | - fence_signal + dma_fence_signal | - fence_signal_locked + dma_fence_signal_locked | - fence_default_wait + dma_fence_default_wait | - fence_add_callback + dma_fence_add_callback | - fence_remove_callback + dma_fence_remove_callback | - fence_enable_sw_signaling + dma_fence_enable_sw_signaling | - fence_is_signaled_locked + dma_fence_is_signaled_locked | - fence_is_signaled + dma_fence_is_signaled | - fence_is_later + dma_fence_is_later | - fence_later + dma_fence_later | - fence_wait_timeout + dma_fence_wait_timeout | - fence_wait_any_timeout + dma_fence_wait_any_timeout | - fence_wait + dma_fence_wait | - fence_context_alloc + dma_fence_context_alloc | - fence_array_create + dma_fence_array_create | - to_fence_array + to_dma_fence_array | - fence_is_array + dma_fence_is_array | - trace_fence_emit + trace_dma_fence_emit | - FENCE_TRACE + DMA_FENCE_TRACE | - FENCE_WARN + DMA_FENCE_WARN | - FENCE_ERR + DMA_FENCE_ERR ) ( ... ) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
2016-09-20drm/virtio: add real fence context and seqnoGustavo Padovan1-1/+1
virtio fences were created with no fence context, which would make then clash with an allocated fence context. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Message-id: 1472660813-28219-2-git-send-email-gustavo@padovan.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-11-10Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds1-1/+1
Pull drm updates from Dave Airlie: "I Was Almost Tempted To Capitalise Every Word, but then I decided I couldn't read it myself! I've also got one pull request for the sti driver outstanding. It relied on a commit in Greg's tree and I didn't find out in time, that commit is in your tree now so I might send that along once this is merged. I also had the accidental misfortune to have access to a Skylake on my desk for a few days, and I've had to encourage Intel to try harder, which seems to be happening now. Here is the main drm-next pull request for 4.4. Highlights: New driver: vc4 driver for the Rasberry Pi VPU. (From Eric Anholt at Broadcom.) Core: Atomic fbdev support Atomic helpers for runtime pm dp/aux i2c STATUS_UPDATE handling struct_mutex usage cleanups. Generic of probing support. Documentation: Kerneldoc for VGA switcheroo code. Rename to gpu instead of drm to reflect scope. i915: Skylake GuC firmware fixes HPD A support VBT backlight fallbacks Fastboot by default for some systems FBC work BXT/SKL workarounds Skylake deeper sleep state fixes amdgpu: Enable GPU scheduler by default New atombios opcodes GPUVM debugging options Stoney support. Fencing cleanups. radeon: More efficient CS checking nouveau: gk20a instance memory handling improvements. Improved PGOB detection and GK107 support Kepler GDDR5 PLL statbility improvement G8x/GT2xx reclock improvements new userspace API compatiblity fixes. virtio-gpu: Add 3D support - qemu 2.5 has it merged for it's gtk backend. msm: Initial msm88896 (snapdragon 8200) exynos: HDMI cleanups Enable mixer driver byt default Add DECON-TV support vmwgfx: Move to using memremap + fixes. rcar-du: Add support for R8A7793/4 DU armada: Remove support for non-component mode Improved plane handling Power savings while in DPMS off. tda998x: Remove unused slave encoder support Use more HDMI helpers Fix EDID read handling dwhdmi: Interlace video mode support for ipu-v3/dw_hdmi Hotplug state fixes Audio driver integration imx: More color formats support. tegra: Minor fixes/improvements" [ Merge fixup: remove unused variable 'dev' that had all uses removed in commit 4e270f088011: "drm/gem: Drop struct_mutex requirement from drm_gem_mmap_obj" ] * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (764 commits) drm/vmwgfx: Relax irq locking somewhat drm/vmwgfx: Properly flush cursor updates and page-flips drm/i915/skl: disable display side power well support for now drm/i915: Extend DSL readout fix to BDW and SKL. drm/i915: Do graphics device reset under forcewake drm/i915: Skip fence installation for objects with rotated views (v4) vga_switcheroo: Drop client power state VGA_SWITCHEROO_INIT drm/amdgpu: group together common fence implementation drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE drm/amdgpu: remove now unused fence functions drm/amdgpu: fix fence fallback check drm/amdgpu: fix stoping the scheduler timeout drm/amdgpu: cleanup on error in amdgpu_cs_ioctl() drm/i915: Fix locking around GuC firmware load drm/amdgpu: update Fiji's Golden setting drm/amdgpu: update Fiji's rev id drm/amdgpu: extract common code in vi_common_early_init drm/amd/scheduler: don't oops on failure to load drm/amdgpu: don't oops on failure to load (v2) drm/amdgpu: don't VT switch on suspend ...
2015-10-16virtio-gpu: add & use virtio_gpu_queue_fenced_ctrl_bufferGerd Hoffmann1-1/+1
Add helper function to handle the submission of fenced control requests. Make sure we initialize the fence while holding the virtqueue lock, so requests can't be reordered. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-10-16drm/virtio: use %llu format string form atomic64_tArnd Bergmann1-1/+1
The virtgpu driver prints the last_seq variable using the %ld or %lu format string, which does not work correctly on all architectures and causes this compiler warning on ARM: drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); ^ drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info': drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=] seq_printf(m, "fence %ld %lld\n", ^ In order to avoid the warnings, this changes the format strings to %llu and adds a cast to u64, which makes it work the same way everywhere. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-06-03Add virtio gpu driver.Dave Airlie1-0/+119
This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga framebuffer, the later is a pure virtio device. The only concern for this driver is that in the virtio-vga case we have to kick out the firmware framebuffer. Initial revision has only 2d support, 3d (virgl) support requires some more work on the qemu side and will be added later. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-23 22:57:29 +0000