that it's impossible to have locking contention with the fs_reclam
at this special time.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 37 +-
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b
Add lockless drm_gem_shmem_get_pages() helper that skips taking reservation
lock if pages_use_count is non-zero, leveraging from atomicity of the kref
counter. Make drm_gem_shmem_mmap() to utilize the new helper.
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm
in
order to prevent spurious lockdep warning about resv lock ordering vs
fs_reclaim code paths.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm
code paths.
Replace open-coded drm_gem_shmem_free() with drm_gem_object_put() that
drops kref to zero before freeing GEM.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/v3d/v3d_bo.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_client.c | 6 +++---
drivers/gpu/drm/drm_gem.c| 20 ++--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +++---
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm
Add _locked postfix to drm_gem functions that have unlocked counterpart
functions to make GEM functions naming more consistent and intuitive in
regards to the locking requirements.
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 6 +++---
include
t;)
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
include/drm/drm_gem_shmem_helper.h | 7 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index a7
emoves
the ambiguity.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
drivers/gpu/drm/lima/lima_gem.c| 1 +
include/drm/drm_gem_shmem_helper.h | 7 +++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helpe
85e9-51bb40a8b...@collabora.com/T/
Dmitry Osipenko (23):
drm/shmem-helper: Fix UAF in error path when freeing SGT of imported
GEM
drm/shmem-helper: Use flag for tracking page count bumped by
get_pages_sgt()
drm/gem: Change locked/unlocked postfix of drm_gem_v/unmap() function
nam
On 8/20/23 23:58, Kim, Dongwon wrote:
> On 8/17/2023 7:33 PM, Dmitry Osipenko wrote:
>> On 7/13/23 01:44, Dongwon Kim wrote:
>>> This helper is needed for framebuffer synchronization. Old
>>> framebuffer data
>>> is often displayed on the guest display w
.
Acked-by: Boris Brezillon
Acked-by: Tomeu Vizoso
Acked-by: Alyssa Rosenzweig
Signed-off-by: Dmitry Osipenko
---
Changelog:
v2: - Added acks from Boris, Alyssa and Tomeu. Tomeu answered with ack
to the v1 email, though he answered to me only and not "to all",
so it's n
On 8/11/23 16:08, Steven Price wrote:
> On 09/08/2023 17:53, Boris Brezillon wrote:
>> This way we can grab a pages ref without acquiring the resv lock when
>> pages_use_count > 0. Need to implement asynchronous map using the
>
> NIT: s/Need/This is needed/
>
>> drm_gpuva_mgr when the map/unmap
On 7/13/23 01:44, Dongwon Kim wrote:
> This helper is needed for framebuffer synchronization. Old framebuffer data
> is often displayed on the guest display without this helper.
>
> Cc: Gerd Hoffmann
> Cc: Vivek Kasireddy
> Signed-off-by: Dongwon Kim
> ---
>
...
> +static struct
> +drm_plane_state *virtio_gpu_plane_duplicate_state(struct drm_plane *plane)
> +{
> + struct virtio_gpu_plane_state *new;
> +
> + if (WARN_ON(!plane->state))
> + return NULL;
When plane->state can be NULL?
> + new = kzalloc(sizeof(*new), GFP_KERNEL);
On 8/17/23 08:25, Kim, Dongwon wrote:
...
> Yeah, I know it frees 'struct dma_fence *f' but what about 'struct
> virtio_gpu_fence *fence'? This is a device specific fence that contains
> struct dma_fence *f. But hold on... so when fence->ops->release is
> called then dma_fence_free won't be called
On 8/16/23 21:10, Kim, Dongwon wrote:
> Hi,
>
> On 8/14/2023 9:18 PM, Dmitry Osipenko wrote:
>> On 7/13/23 01:44, Dongwon Kim wrote:
>>> virtio_gpu_fence_release is added to free virtio-gpu-fence
>>> upon release of dma_fence.
>>>
>>> Cc: Ger
On 7/13/23 01:44, Dongwon Kim wrote:
> virtio_gpu_fence_release is added to free virtio-gpu-fence
> upon release of dma_fence.
>
> Cc: Gerd Hoffmann
> Cc: Vivek Kasireddy
> Signed-off-by: Dongwon Kim
> ---
> drivers/gpu/drm/virtio/virtgpu_fence.c | 8
> 1 file changed, 8
On 7/17/23 11:15, Dmitry Osipenko wrote:
> Add Boris Brezillon as Panfrost driver maintainer. Boris is a new lead
> developer of the Panfrost Mesa driver and main developer behind the
> upcoming Panthor kernel driver that will serve next-gen Mali GPUs.
>
> Remove Tomeu and A
)
> {
> - struct virtio_gpu_fence_event *e = NULL;
> + struct virtio_gpu_fence_event *e;
> int ret;
>
> e = kzalloc(sizeof(*e), GFP_KERNEL);
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
ime_import(struct drm_device *dev,
> struct dma_buf *buf);
> -int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj,
> -uuid_t *uuid);
> struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
> struct drm_device *dev, struct dma_buf_attachment *attach,
> struct sg_table *sgt);
Reviewed-by: Dmitry Osipenko
--
Best regards,
Dmitry
job timeouts due to a slow IRQ processing.
Reviewed-by: Steven Price
Reviewed-by: Boris Brezillon
Reviewed-by: AngeloGioacchino Del Regno
Tested-by: AngeloGioacchino Del Regno
# MediaTek MT8192 and MT8195 Chromebooks
Signed-off-by: Dmitry Osipenko
---
Changelog:
v4: - Improved comment like
job timeouts due to a slow IRQ processing.
Reviewed-by: Steven Price
Reviewed-by: AngeloGioacchino Del Regno
Tested-by: AngeloGioacchino Del Regno
# MediaTek MT8192 and MT8195 Chromebooks:
Signed-off-by: Dmitry Osipenko
---
Changelog:
v3: - Added comment to the code as was suggested by Boris
On 4/16/23 14:52, Dmitry Osipenko wrote:
> Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
> support is needed by native context VirtIO-GPU Mesa drivers, it also will
> be used by Venus and Virgl contexts.
>
> Reviewed-by; Emil Velikov
> Signed-off-b
On 7/29/23 01:03, Gurchetan Singh wrote:
> On Wed, Jul 19, 2023 at 11:58 AM Dmitry Osipenko <
> dmitry.osipe...@collabora.com> wrote:
>
>> 27.06.2023 20:16, Rob Clark пишет:
>> ...
>>>> Now these are just suggestions, and while I think they
On 7/25/23 10:53, Boris Brezillon wrote:
> On Sun, 23 Jul 2023 02:47:46 +0300
> Dmitry Osipenko wrote:
>
>> Make clear that drm_gem_pin/unpin() functions take reservation lock by
>> adding _unlocked postfix to the function names.
>>
>> Suggested-by: Boris Br
On 7/31/23 15:27, Dmitry Osipenko wrote:
> On 7/25/23 11:32, Boris Brezillon wrote:
>>> Can we make it an atomic_t, so we can avoid taking the lock when the
>>> GEM has already been pinned. That's something I need to be able to grab
>>> a pin-ref in a path where the G
On 7/25/23 11:32, Boris Brezillon wrote:
>> Can we make it an atomic_t, so we can avoid taking the lock when the
>> GEM has already been pinned. That's something I need to be able to grab
>> a pin-ref in a path where the GEM resv lock is already held[1]. We could
>> of course expose the locked
job timeouts due to a slow IRQ processing.
Signed-off-by: Dmitry Osipenko
---
Changelog:
v2: - Moved synchronize_irq() after first signal-check to avoid unnecessary
blocking on syncing.
- Added warn message about high interrupt latency.
drivers/gpu/drm/panfrost/panfrost_job.c | 7
y if
guest supports SWAP file or partition.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 20 +++-
drivers/gpu/drm/virtio/virtgpu_gem.c| 72 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 33 ++
d
Export drm_gem_shmem_get_pages_sgt_locked() that will be used by virtio-gpu
shrinker during GEM swap-in operation done under the held reservation lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
include/drm/drm_gem_shmem_helper.h | 1 +
2 files
y: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 0b6c4f318da5..5aa85242071a 100644
--- a/driver
Make drm_gem_shmem_print_info() exported symbol GPL to make it consistent
with the rest of drm-shmem exports. It's the only remaining drm-shmem
symbol that isn't GPL.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 9 +
include/drm/drm_gem_shmem_helper.h | 9 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 267153853e2c..42ba201dda50 100644
Make clear that drm_gem_pin/unpin() functions take reservation lock by
adding _unlocked postfix to the function names.
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 4 ++--
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c
Add locked/unlocked postfixes to drm-shmem function names to make clear
where reservation lock is taken and where not. Add more common helpers to
drm_gem_shmem_helper.h
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 172
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Tested-by: Steven Price # Firefly-RK3288
Reviewed-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/Makefile | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h| 4
Factor out pages unpinning code from drm_gem_shmem_purge() into new
drm_gem_shmem_unpin_pages(). This prepares code for addition of memory
shrinker support. The new common function will be used by shrinker for
eviction of shmem pages.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm
ile the new pages_pin_count will do that. Switch the vmap/vunmap to use
pin/unpin functions in a preparation of addition of the memory shrinker
support.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --
. Initialize drm-shmem internals using drmm_gem_shmem_init(drm_device),
which will register drm-shmem shrinker
3. Implement madvise IOCTL that will use drm_gem_shmem_madvise()
Signed-off-by: Daniel Almeida
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 351
off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 65 --
1 file changed, 52 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index a783d2245599..267153853e2c 100644
--- a/drivers/gpu/
-b's that were given to v10.
v10:- Was partially applied to misc-fixes/next.
https://lore.kernel.org/dri-devel/6c16f303-81df-7ebe-85e9-51bb40a8b...@collabora.com/T/
Dmitry Osipenko (12):
drm/shmem-helper: Factor out pages alloc/release from
drm_gem_shmem_get/put_pages()
drm/shmem-
27.06.2023 15:01, Geert Uytterhoeven пишет:
> Hi Dmitry,
>
> On Mon, Jun 26, 2023 at 6:11 PM Dmitry Osipenko
> wrote:
>> On 6/25/23 18:36, Geert Uytterhoeven wrote:
>>> On Sun, Jun 25, 2023 at 2:41 PM Dmitry Osipenko
>>> wrote:
>>>> On 6/25/23 11
27.06.2023 20:16, Rob Clark пишет:
...
>> Now these are just suggestions, and while I think they are good, you can
>> safely ignore them.
>>
>> But there's also the DRM requirements, which state "userspace side must be
>> fully reviewed and tested to the standards of that user-space project.".
17.07.2023 11:59, Steven Price пишет:
> On 17/07/2023 09:49, Boris Brezillon wrote:
>> On Mon, 17 Jul 2023 09:06:56 +0100
>> Steven Price wrote:
>>
>>> On 17/07/2023 08:49, Boris Brezillon wrote:
>>>> On Mon, 17 Jul 2023 10:20:02 +0300
>
.
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5d6536fef2fc..08dc75916148 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1615,9 +1615,8 @@ F:drivers/gpu/drm/arm/display/komeda/
ARM MALI
Hi,
On 7/17/23 10:05, Boris Brezillon wrote:
> Hi Dmitry,
>
> On Mon, 17 Jul 2023 09:52:54 +0300
> Dmitry Osipenko wrote:
>
>> Panfrost IRQ handler may stuck for a long time, for example this happens
>> when there is a bad HDMI connection and HDMI handler tak
job timeouts due to a slow IRQ processing.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/panfrost_job.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index dbc597ab46fb..a356163da22d 100644
08.07.2023 00:31, Gurchetan Singh пишет:
> We don't want to create a fence for every command submission. It's
> only necessary when userspace provides a waitable token for submission.
> This could be:
>
> 1) bo_handles, to be used with VIRTGPU_WAIT
> 2) out_fence_fd, to be used with dma_fence
return err;
> + }
> }
>
> submit->out_fence = out_fence;
Another small note for the future is that you should always start a new
email thread for every new version of the patch, i.e. don't reply with
new version to the old thread. This is not a problem here since it's
just a single patch, nevertheless please take it into account later on.
It eases patch tracking for reviewers.
I tested v4, including the applied CL4605854 to Sommilier. Everything
works well as before. Thank you for addressing all the issues.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 7/7/23 20:59, Gurchetan Singh wrote:
///
>>> Previously, when VIRTGPU_EXECBUF_RING_IDX flag wasn't specified, the
>>> fence event was created for a default ring_idx=0. Now you changed this
>>> behaviour and event will never be created without
>>> VIRTGPU_EXECBUF_RING_IDX flag being set.
>
>
On 7/7/23 20:04, Dmitry Osipenko wrote:
> On 7/7/23 18:43, Gurchetan Singh wrote:
>> @@ -161,21 +157,27 @@ static int virtio_gpu_init_submit(struct
>> virtio_gpu_submit *submit,
>>struct drm_file *file,
>>
On 7/7/23 18:43, Gurchetan Singh wrote:
> @@ -161,21 +157,27 @@ static int virtio_gpu_init_submit(struct
> virtio_gpu_submit *submit,
> struct drm_file *file,
> u64 fence_ctx, u32 ring_idx)
> {
> + int err;
> + struct
On 7/7/23 05:53, Dmitry Osipenko wrote:
> On 7/7/23 05:49, Dmitry Osipenko wrote:
>> On 6/28/23 18:58, Gurchetan Singh wrote:
>>> @@ -168,9 +168,13 @@ static int virtio_gpu_init_submit(struct
>>> virtio_gpu_submit *submit,
>>>
>>> memset(submit,
On 7/7/23 05:49, Dmitry Osipenko wrote:
> On 6/28/23 18:58, Gurchetan Singh wrote:
>> @@ -168,9 +168,13 @@ static int virtio_gpu_init_submit(struct
>> virtio_gpu_submit *submit,
>>
>> memset(submit, 0, sizeof(*submit));
>>
>> -out_fence =
On 6/28/23 18:58, Gurchetan Singh wrote:
> @@ -168,9 +168,13 @@ static int virtio_gpu_init_submit(struct
> virtio_gpu_submit *submit,
>
> memset(submit, 0, sizeof(*submit));
>
> - out_fence = virtio_gpu_fence_alloc(vgdev, fence_ctx, ring_idx);
> - if (!out_fence)
> -
gt;num_bo_handles)
>> + out_fence = virtio_gpu_fence_alloc(vgdev, fence_ctx,
>> ring_idx);
>> + else
>> + out_fence = NULL;
>>
>> err = virtio_gpu_fence_event_create(dev, file, out_fence, ring_idx);
>> if (err) {
>> --
>
> Ping for additional reviews or merge.
I tested this patch with virgl,venus and nctx. No problems spotted.
Going to apply it tomorrow if there won't be additional comments from
anyone.
Tested-by: Dmitry Osipenko
--
Best regards,
Dmitry
On 6/25/23 18:36, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Sun, Jun 25, 2023 at 2:41 PM Dmitry Osipenko
> wrote:
>> On 6/25/23 11:47, Geert Uytterhoeven wrote:
>>> On Sun, Apr 16, 2023 at 1:55 PM Dmitry Osipenko
>>> wrote:
>>>> Add sync ob
On 6/26/23 18:43, Boris Brezillon wrote:
> On Mon, 26 Jun 2023 16:20:53 +0300
> Dmitry Osipenko wrote:
>
>> On 6/26/23 15:02, Boris Brezillon wrote:
>>> -err_pages:
>>> - drm_gem_shmem_put_pages(>base);
>>> err_unlock:
>>> dma_r
On 6/26/23 18:21, Boris Brezillon wrote:
> On Mon, 26 Jun 2023 17:04:57 +0200
> Boris Brezillon wrote:
>
>> Hi Dmitry,
>>
>> Sorry for chiming in only now :-/.
>>
>> On Tue, 14 Mar 2023 05:26:52 +0300
>> Dmitry Osipenko wrote:
>>
>>>
On 6/26/23 15:02, Boris Brezillon wrote:
> -err_pages:
> - drm_gem_shmem_put_pages(>base);
> err_unlock:
> dma_resv_unlock(obj->resv);
> +
> + if (ret && pinned)
> + drm_gem_shmem_unpin(>base);
The drm_gem_shmem_unpin() was supposed to be used only in conjunction
with
On 6/26/23 12:40, Boris Brezillon wrote:
> I think here is the major problem I have with this patch: you've made
> drm_gem_shmem_{get_pages,pin}() private, which forces me to call
> drm_gem_shmem_pin() in a path where I already acquired the resv lock
> (using the drm_exec infra proposed by
On 6/26/23 12:40, Boris Brezillon wrote:
> Same problem with this renaming: it's confusing because this function
> was previously taking care of the locking, and it's no longer the case.
> That's actually true for other public functions your patching, but I
> won't go over all of them.
>
> I know
On 6/25/23 11:47, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Sun, Apr 16, 2023 at 1:55 PM Dmitry Osipenko
> wrote:
>> Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
>> support is needed by native context VirtIO-GPU Mesa drivers, it also will
>&
On 5/30/23 01:39, Dmitry Osipenko wrote:
> This patchset makes dma-buf exporters responisble for taking care of
> the reservation lock. I also included patch that moves drm-shmem to use
> reservation lock, to let CI test the whole set. I'm going to take all
> the patches via the d
On 6/21/23 08:42, Christian König wrote:
> Am 20.06.23 um 17:58 schrieb Dmitry Osipenko:
>> On 5/31/23 22:58, Dmitry Osipenko wrote:
>>> On 5/30/23 01:39, Dmitry Osipenko wrote:
>>>> Change locking policy of mmap() callback, making exporters responsible
>>
Hi,
On 6/21/23 20:21, T.J. Mercier wrote:
> On Mon, May 29, 2023 at 3:46 PM Dmitry Osipenko
> wrote:
>>
>> Don't assert held dma-buf reservation lock on memory mapping of exported
>> buffer.
>>
>> We're going to change dma-buf mmap() locking policy such t
On 5/31/23 22:58, Dmitry Osipenko wrote:
> On 5/30/23 01:39, Dmitry Osipenko wrote:
>> Change locking policy of mmap() callback, making exporters responsible
>> for handling dma-buf reservation locking. Previous locking policy stated
>> that dma-buf is locked for both im
On 6/13/23 20:43, Gurchetan Singh wrote:
> We don't want to create a fence for every command submission. It's
> only necessary when userspace provides a waitable token for submission.
> This could be:
>
> 1) bo_handles, to be used with VIRTGPU_WAIT
> 2) out_fence_fd, to be used with dma_fence
> Dmitry Osipenko (3):
> drm/virtio: Refactor and optimize job submission code path
> drm/virtio: Wait for each dma-fence of in-fence array individually
Applied these two patches to misc-next. The syncobj patch will wait for
the turnip Mesa MR.
--
Best regards,
Dmitry
On 5/30/23 01:39, Dmitry Osipenko wrote:
> Change locking policy of mmap() callback, making exporters responsible
> for handling dma-buf reservation locking. Previous locking policy stated
> that dma-buf is locked for both importers and exporters by the dma-buf
> core, which cause
-by: Daniel Vetter
Acked-by: Thomas Zimmermann
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 210 --
drivers/gpu/drm/lima/lima_gem.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-
.../gpu
these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares DRM
drivers for the locking policy update.
Reviewed-by: Emil Velikov
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c
dma-bufs which required to take the lock from the DRM
exporter side.
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
these
drivers are moved to use reservation lock universally. The problem
solved by moving the lock down to exporters. This patch prepares dma-buf
heaps for the locking policy update.
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/heaps/cma_heap.c| 3 ---
drivers/dma
these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares udmabuf
for the locking policy update.
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/udmabuf.c | 2 --
1 file changed, 2
ggested in a comment to v1.
- Corrected drm-shmem patch dma_resv_lock(obj->resv) inconsistently
used with dma_resv_unlock(shmem->base.resv). Now shmem->base.resv
variant is used for all locks/unlocks.
Dmitry Osipenko (6):
media: videobuf2: Don't assert held reservation
these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares videobuf2
for the locking policy update.
Reviewed-by: Emil Velikov
Reviewed-by: Hans Verkuil
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2
On 5/22/23 16:02, Emil Velikov wrote:
>> -void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
>> +static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem)
>> +{
>> + int ret;
>> +
>> + dma_resv_assert_held(shmem->base.resv);
>> +
>> + ret =
On 5/22/23 16:02, Emil Velikov wrote:
> Hi Dmitry,
>
> Saw v3 fly by, so I had a quick look. Original RB still stands,
> although I noticed a couple of non-blocking nitpicks.
>
> On Sun, 21 May 2023 at 22:00, Dmitry Osipenko
> wrote:
>
>> -static int drm_gem
-by: Daniel Vetter
Acked-by: Thomas Zimmermann
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 208 --
drivers/gpu/drm/lima/lima_gem.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-
.../gpu
dma-bufs which required to take the lock from the DRM
exporter side.
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares DRM
drivers for the locking policy update.
Reviewed-by: Emil Velikov
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c
these
drivers are moved to use reservation lock universally. The problem
solved by moving the lock down to exporters. This patch prepares dma-buf
heaps for the locking policy update.
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/heaps/cma_heap.c| 3 ---
drivers/dma
these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares udmabuf
for the locking policy update.
Reviewed-by: Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/udmabuf.c | 2 --
1 file changed, 2
these
drivers are moved to use reservation lock universally. The problem is
solved by moving the lock down to exporters. This patch prepares videobuf2
for the locking policy update.
Reviewed-by: Emil Velikov
Reviewed-by: Hans Verkuil
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2
esv). Now shmem->base.resv
variant is used for all locks/unlocks.
Dmitry Osipenko (6):
media: videobuf2: Don't assert held reservation lock for dma-buf
mmapping
dma-buf/heaps: Don't assert held reservation lock for dma-buf mmapping
udmabuf: Don't assert held reservation lock for
On 5/12/23 03:17, Gurchetan Singh wrote:
...
> Can we get one of the Mesa MRs reviewed first? There's currently no
> virtio-intel MR AFAICT, and the amdgpu one is marked as "Draft:".
>
> Even for the amdgpu, Pierre suggests the feature "will be marked as
> experimental both in Mesa and
On 5/3/23 09:51, Gerd Hoffmann wrote:
> On Mon, May 01, 2023 at 06:38:45PM +0300, Dmitry Osipenko wrote:
>> On 4/16/23 14:52, Dmitry Osipenko wrote:
>>> We have multiple Vulkan context types that are awaiting for the addition
>>> of the sync object DRM UAPI support to t
On 4/6/23 19:06, Dmitry Osipenko wrote:
> Change locking policy of mmap() callback, making exporters responsible
> for handling dma-buf reservation locking. Previous locking policy stated
> that dma-buf is locked for both importers and exporters by the dma-buf
> core, which cause
On 4/16/23 14:52, Dmitry Osipenko wrote:
> We have multiple Vulkan context types that are awaiting for the addition
> of the sync object DRM UAPI support to the VirtIO-GPU kernel driver:
>
> 1. Venus context
> 2. Native contexts (virtio-freedreno, virtio-intel, virtio-amdgpu)
On 4/16/23 14:52, Dmitry Osipenko wrote:
> Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
> support is needed by native context VirtIO-GPU Mesa drivers, it also will
> be used by Venus and Virgl contexts.
>
> Reviewed-by; Emil Velikov
> Signed-off-b
Hello Gurchetan,
On 4/18/23 02:17, Gurchetan Singh wrote:
> On Sun, Apr 16, 2023 at 4:53 AM Dmitry Osipenko <
> dmitry.osipe...@collabora.com> wrote:
>
>> We have multiple Vulkan context types that are awaiting for the addition
>> of the sync object DRM UAPI suppo
to the point of
pushing job to virtio queue. Job's initialization is now performed before
in-fence is awaited and out-fence setup is made after sending out job to
virtio.
Reviewed-by: Rob Clark
Reviewed-by; Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/Makefile
Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
support is needed by native context VirtIO-GPU Mesa drivers, it also will
be used by Venus and Virgl contexts.
Reviewed-by; Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 3
pcoming host-waits feature
because of how variables are passed around the code, the virtgpu_ioctl.c
also was growing to unmanageable size.
Dmitry Osipenko (3):
drm/virtio: Refactor and optimize job submission code path
drm/virtio: Wait for each dma-fence of in-fence array individ
Reviewed-by; Emil Velikov
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_submit.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_submit.c
b/drivers/gpu/drm/virtio/virtgpu_submit.c
index 84e7c4d9d8c7
Hello,
On 4/11/23 14:07, Emil Velikov wrote:
> Hi Dmitry,
>
> On Sun, 9 Apr 2023 at 13:40, Dmitry Osipenko
> wrote:
>
>> +static void virtio_gpu_free_syncobjs(struct drm_syncobj **syncobjs,
>> +uint32_t nr_syncobjs)
>> +{
&g
y difficult to add a new/upcoming host-waits feature
because of how variables are passed around the code, the virtgpu_ioctl.c
also was growing to unmanageable size.
Dmitry Osipenko (3):
drm/virtio: Refactor and optimize job submission code path
drm/virtio: Wait for each dma-fence
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_submit.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_submit.c
b/drivers/gpu/drm/virtio/virtgpu_submit.c
index 902734778d1b..b60dea077240 100644
Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
support is needed by native context VirtIO-GPU Mesa drivers, it also will
be used by Venus and Virgl contexts.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 3 +-
drivers/gpu/drm/virtio
201 - 300 of 2899 matches
Mail list logo
