[PATCH v5 17/21] dma-buf: Move dma_buf_map_attachment() to dynamic locking specification

Move dma-buf attachment mapping functions to the dynamic locking specification by asserting that the reservation lock is held. Reviewed-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git

[PATCH v5 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

Prepare Etnaviv driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH v5 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification

Prepare fastrpc to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Christian König Acked-by: Srinivas Kandagatla Signed-off-by: Dmitry Osipenko --- drivers/misc/fastrpc.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH v5 10/21] RDMA/umem: Prepare to dynamic dma-buf locking specification

Prepare InfiniBand drivers to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/infiniband/core/umem_dmabuf.c | 7 --- 1 file changed, 4 insertions(+), 3

[PATCH v5 08/21] drm/tegra: Prepare to dynamic dma-buf locking specification

Prepare Tegra DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/gem.c | 17 + 1 file changed, 9 insertions(+), 8

[PATCH v5 07/21] drm/omapdrm: Prepare to dynamic dma-buf locking specification

Prepare OMAP DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH v5 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

Prepare i915 driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions and handling cases where importer now holds the reservation lock. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/i915/gem

[PATCH v5 05/21] drm/armada: Prepare to dynamic dma-buf locking specification

Prepare Armada driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/armada/armada_gem.c | 8 1 file changed, 4 insertions(+), 4 deletions

[PATCH v5 03/21] drm/gem: Take reservation lock for vmap/vunmap operations

. This patch prepares DRM core and drivers to the common dynamic dma-buf locking convention. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 ++-- drivers/gpu/drm/drm_gem.c| 24 drivers/gpu/drm

[PATCH v5 01/21] dma-buf: Add unlocked variant of vmapping functions

Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized by drivers that don't take the reservation lock explicitly. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 38 ++ include/linux/dma-buf.h | 2

[PATCH v5 04/21] drm/prime: Prepare to dynamic dma-buf locking specification

Prepare DRM prime core to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Reviewed-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_prime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions

[PATCH v5 02/21] dma-buf: Add unlocked variant of attachment-mapping functions

Add unlocked variant of dma_buf_map/unmap_attachment() that will be used by drivers that don't take the reservation lock explicitly. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 53 +++ include/linux/dma-buf.h

[PATCH v5 00/21] Move all drivers to a common dma-buf locking convention

Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (21): dma-bu

Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

On 9/2/22 19:26, Ruhl, Michael J wrote: >> 02.09.2022 13:31, Dmitry Osipenko пишет: >>> 01.09.2022 17:02, Ruhl, Michael J пишет: >>> ... >>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >>>>> +++ b/drivers/gpu/drm/i915/gem/i9

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/23/22 19:47, Rob Clark wrote: > On Tue, Aug 23, 2022 at 3:01 AM Christian König > wrote: >> >> Am 22.08.22 um 19:26 schrieb Dmitry Osipenko: >>> On 8/16/22 22:55, Dmitry Osipenko wrote: >>>> On 8/16/22 15:03, Christian König wrote: >>>

Re: [PATCH v17 00/10] Add MT8195 DisplayPort driver

On 9/4/22 15:59, Dmitry Osipenko wrote: > 01.09.2022 07:41, Bo-Chen Chen пишет: >> This patch is separated from v10 which is including dp driver, phy driver >> and dpintf driver. This series is only contained the DisplayPort driver. >> >> This series can be tested using

Re: [PATCH v17 02/10] video/hdmi: Add audio_infoframe packing for DP

01.09.2022 07:41, Bo-Chen Chen пишет: > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 9e3aff7e68bb..6c0871164771 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -1536,6 +1536,8 @@ enum drm_dp_phy { > #define

Re: [PATCH v17 00/10] Add MT8195 DisplayPort driver

01.09.2022 07:41, Bo-Chen Chen пишет: > This patch is separated from v10 which is including dp driver, phy driver > and dpintf driver. This series is only contained the DisplayPort driver. > > This series can be tested using 5.19-rc2 kernel and I test it in MT8195 > Tomato Chromebook. Modetest

Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

02.09.2022 13:31, Dmitry Osipenko пишет: > 01.09.2022 17:02, Ruhl, Michael J пишет: > ... >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(

Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

01.09.2022 17:02, Ruhl, Michael J пишет: ... >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct >> drm_i915_private *i915, >> continue; >> } >>

Re: [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention

Hello Christian, On 9/1/22 10:49, Christian König wrote: > Hi Dmitry, > > I've gone over this multiple times now and while it is still possible > that we missed something I think that this should land now. Thank you very much for the review! > The whole topic is just to complicated that we can

Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

On 9/1/22 09:45, Christian König wrote: > Am 31.08.22 um 17:37 schrieb Dmitry Osipenko: >> Prepare i915 driver to the common dynamic dma-buf locking convention >> by starting to use the unlocked versions of dma-buf API functions >> and handling cases where importer now holds

Re: [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

On 9/1/22 09:50, Christian König wrote: > Am 31.08.22 um 17:37 schrieb Dmitry Osipenko: >> Prepare Etnaviv driver to the common dynamic dma-buf locking convention >> by starting to use the unlocked versions of dma-buf API functions. >> >> Signed-off-by: Dmitry Osipen

[PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

Prepare i915 driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions and handling cases where importer now holds the reservation lock. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2

[PATCH v4 21/21] dma-buf: Remove obsoleted internal lock

-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 14 -- include/linux/dma-buf.h | 9 - 2 files changed, 4 insertions(+), 19 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 97ce884fad76..772fdd9eeed8 100644 --- a/drivers/dma-buf/dma

[PATCH v4 18/21] dma-buf: Move dma_buf_mmap() to dynamic locking specification

Move dma_buf_mmap() function to the dynamic locking specification by taking the reservation lock. Neither of the today's drivers take the reservation lock within the mmap() callback, hence it's safe to enforce the locking. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers

[PATCH v4 10/21] RDMA/umem: Prepare to dynamic dma-buf locking specification

Prepare InfiniBand drivers to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/infiniband/core/umem_dmabuf.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[PATCH v4 17/21] dma-buf: Move dma_buf_map_attachment() to dynamic locking specification

Move dma-buf attachment mapping functions to the dynamic locking specification by asserting that the reservation lock is held. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b

[PATCH v4 20/21] media: videobuf2: Stop using internal dma-buf lock

. Acked-by: Tomasz Figa Acked-by: Hans Verkuil Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +-- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +-- drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +-- 3

[PATCH v4 16/21] dma-buf: Move dma_buf_attach() to dynamic locking specification

Move dma-buf attachment API functions to the dynamic locking specification by taking the reservation lock around the mapping operations. The strict locking convention prevents deadlock situations for dma-buf importers and exporters. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c

[PATCH v4 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification

Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking specification by asserting that the reservation lock is held. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma-buf/dma

[PATCH v4 12/21] xen/gntdev: Prepare to dynamic dma-buf locking specification

Prepare gntdev driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/xen/gntdev-dmabuf.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/xen/gntdev

[PATCH v4 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification

Prepare fastrpc to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/misc/fastrpc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/misc/fastrpc.c b

[PATCH v4 14/21] media: tegra-vde: Prepare to dynamic dma-buf locking specification

Prepare Tegra video decoder driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH v4 19/21] dma-buf: Document dynamic locking convention

Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 +++ drivers/dma-buf/dma-buf.c| 64

[PATCH v4 13/21] media: videobuf2: Prepare to dynamic dma-buf locking specification

Prepare V4L2 memory allocators to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Acked-by: Tomasz Figa Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 ++- drivers/media

[PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

Prepare Etnaviv driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers

[PATCH v4 05/21] drm/armada: Prepare to dynamic dma-buf locking specification

Prepare Armada driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/armada/armada_gem.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers

[PATCH v4 07/21] drm/omapdrm: Prepare to dynamic dma-buf locking specification

Prepare OMAP DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v4 04/21] drm/prime: Prepare to dynamic dma-buf locking specification

Prepare DRM prime core to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_prime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm

[PATCH v4 08/21] drm/tegra: Prepare to dynamic dma-buf locking specification

Prepare Tegra DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/gem.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git

[PATCH v4 01/21] dma-buf: Add unlocked variant of vmapping functions

Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized by drivers that don't take the reservation lock explicitly. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 38 ++ include/linux/dma-buf.h | 2

[PATCH v4 03/21] drm/gem: Take reservation lock for vmap/vunmap operations

. This patch prepares DRM core and drivers to the common dynamic dma-buf locking convention. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 ++-- drivers/gpu/drm/drm_gem.c| 24 drivers/gpu/drm

[PATCH v4 02/21] dma-buf: Add unlocked variant of attachment-mapping functions

Add unlocked variant of dma_buf_map/unmap_attachment() that will be used by drivers that don't take the reservation lock explicitly. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 53 +++ include/linux/dma-buf.h

[PATCH v4 00/21] Move all drivers to a common dma-buf locking convention

Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (21): dma-buf: Add unlocked variant of vmapping functions dma-buf: Add unlocked variant of attachment-mapping functions drm/gem: Take reservation lock for vmap/vunmap operati

Re: [Linaro-mm-sig] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 20:45, Christian König wrote: > Am 24.08.22 um 17:49 schrieb Dmitry Osipenko: >> On 8/24/22 18:24, Christian König wrote: >>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >>>> Move dma-buf attachment API functions to the dynamic locking >>>&

[PATCH v1] drm/ttm: Refcount allocated tail pages

://www.collabora.com/news-and-blog/blog/2021/11/26/venus-on-qemu-enabling-new-virtual-vulkan-driver/#qcom1343 Tested-by: Dmitry Osipenko # AMDGPU (Qemu and crosvm) Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/ttm/ttm_pool.c | 25 - 1 file changed, 24 insertions(+), 1 deletion

Re: [Linaro-mm-sig] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 18:24, Christian König wrote: > Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >> Move dma-buf attachment API functions to the dynamic locking >> specification. >> The strict locking convention prevents deadlock situations for dma-buf >> importers and

Re: [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 18:14, Christian König wrote: > Am 24.08.22 um 17:03 schrieb Dmitry Osipenko: >> On 8/24/22 17:08, Christian König wrote: >>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >>>> Move dma-buf attachment API functions to the dynamic locking >>>&

Re: [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 17:08, Christian König wrote: > Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >> Move dma-buf attachment API functions to the dynamic locking >> specification. >> The strict locking convention prevents deadlock situations for dma-buf >> importers and

[PATCH v3 4/9] dma-buf: Move dma_buf_vmap/vunmap_unlocked() to dynamic locking specification

Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking specification by taking the reservation lock. All the affected drivers were prepared to this change by a previous drm/gem patch. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 8 drivers/gpu/drm

[PATCH v3 2/9] dma-buf: Add locked variant of dma_buf_vmap/vunmap()

Add locked variant of dma_buf_vmap/vunmap() that will be utilized by DRM drivers once vmap/unmap functions will be moved to the new locking convention. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 42 +++ include/linux/dma-buf.h | 2 ++ 2

[PATCH v3 9/9] dma-buf: Remove internal lock

The internal dma-buf lock isn't needed anymore because the updated locking specification claims that dma-buf reservation must be locked by importers, and thus, the internal data is already protected by the reservation lock. Remove the obsoleted internal lock. Signed-off-by: Dmitry Osipenko

[PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

atch makes them to take the lock. Intel and AMD GPU drivers already were mapping the attached dma-bufs under the held lock during attachment, hence these drivers are updated to use the locked functions. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c

[PATCH v3 7/9] dma-buf: Document dynamic locking convention

Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 +++ drivers/dma-buf/dma-buf.c| 63

[PATCH v3 5/9] dma-buf: Move dma_buf_mmap_unlocked() to dynamic locking specification

Move dma_buf_mmap_unlocked() function to the dynamic locking specification by taking the reservation lock. Neither of the today's drivers take the reservation lock within the mmap() callback, hence it's safe to enforce the locking. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c

[PATCH v3 8/9] media: videobuf2: Stop using internal dma-buf lock

. Acked-by: Tomasz Figa Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +-- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +-- drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +-- 3 files changed, 3

[PATCH v3 3/9] drm/gem: Take reservation lock for vmap/vunmap operations

. This patch prepares DRM core and drivers for transitioning to the common dma-buf locking convention. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 ++-- drivers/gpu/drm/drm_gem.c| 24 drivers/gpu/drm

[PATCH v3 0/9] Move all drivers to a common dma-buf locking convention

documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (9): dma-buf: Add _unlocked postfix to f

[PATCH v3 1/9] dma-buf: Add _unlocked postfix to function names

functions to take the reservation lock. Acked-by: Christian König Suggested-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 76 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/16/22 22:55, Dmitry Osipenko wrote: > On 8/16/22 15:03, Christian König wrote: >> Am 16.08.22 um 13:44 schrieb Dmitry Osipenko: >>> [SNIP] >>>> The other complication I noticed is that we don't seem to keep around >>>> the fd after impor

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/18/22 01:57, Dmitry Osipenko wrote: > On 8/15/22 18:54, Dmitry Osipenko wrote: >> On 8/15/22 17:57, Dmitry Osipenko wrote: >>> On 8/15/22 16:53, Christian König wrote: >>>> Am 15.08.22 um 15:45 schrieb Dmitry Osipenko: >>>>> [SNIP] >>>&g

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 18:54, Dmitry Osipenko wrote: > On 8/15/22 17:57, Dmitry Osipenko wrote: >> On 8/15/22 16:53, Christian König wrote: >>> Am 15.08.22 um 15:45 schrieb Dmitry Osipenko: >>>> [SNIP] >>>>> Well that comment sounds like KVM is doing the rig

Re: [PATCH] drm/ttm: prevent grabbing page references

On 8/15/22 16:08, Christian König wrote: > TTM owns the pages it uses for backing buffer objects with system > memory. Because of this it is absolutely illegal to mess around with > the reference count of those pages. > > So make sure that nobody ever tries to grab an extra reference on > pages

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/16/22 15:03, Christian König wrote: > Am 16.08.22 um 13:44 schrieb Dmitry Osipenko: >> [SNIP] >>> The other complication I noticed is that we don't seem to keep around >>> the fd after importing to a GEM handle.  And I could imagine that >>> doing so could

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/16/22 14:44, Dmitry Osipenko wrote: > On 8/12/22 18:01, Rob Clark wrote: >> On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote: >>> >>> On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko >>> wrote: >>>> >>>> On 8/11/22 02:19, Rob Clark

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/12/22 18:01, Rob Clark wrote: > On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote: >> >> On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko >> wrote: >>> >>> On 8/11/22 02:19, Rob Clark wrote: >>>> On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osip

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 17:57, Dmitry Osipenko wrote: > On 8/15/22 16:53, Christian König wrote: >> Am 15.08.22 um 15:45 schrieb Dmitry Osipenko: >>> [SNIP] >>>> Well that comment sounds like KVM is doing the right thing, so I'm >>>> wondering what exactly is go

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 16:53, Christian König wrote: > Am 15.08.22 um 15:45 schrieb Dmitry Osipenko: >> [SNIP] >>> Well that comment sounds like KVM is doing the right thing, so I'm >>> wondering what exactly is going on here. >> KVM actually doesn't hold the page reference, i

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 16:06, Christian König wrote: > Am 15.08.22 um 13:50 schrieb Dmitry Osipenko: >> On 8/15/22 14:28, Christian König wrote: >>>>>> Maybe it was discussed privately? In this case I will be happy to get >>>>>> more info from you about the root o

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 14:28, Christian König wrote: Maybe it was discussed privately? In this case I will be happy to get more info from you about the root of the problem so I could start to look at how to fix it properly. It's not apparent where the problem is to a TTM newbie like me.

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 13:51, Christian König wrote: > Am 15.08.22 um 12:47 schrieb Dmitry Osipenko: >> On 8/15/22 13:18, Dmitry Osipenko wrote: >>> On 8/15/22 13:14, Christian König wrote: >>>> Am 15.08.22 um 12:11 schrieb Christian König: >>>>> Am 15.08.22 um 12:

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 13:18, Dmitry Osipenko wrote: > On 8/15/22 13:14, Christian König wrote: >> Am 15.08.22 um 12:11 schrieb Christian König: >>> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko: >>>> On 8/15/22 13:05, Christian König wrote: >>>>> Am 15.08.22 um

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 13:14, Christian König wrote: > Am 15.08.22 um 12:11 schrieb Christian König: >> Am 15.08.22 um 12:09 schrieb Dmitry Osipenko: >>> On 8/15/22 13:05, Christian König wrote: >>>> Am 15.08.22 um 11:54 schrieb Dmitry Osipenko: >>>>> Higher ord

Re: [PATCH v1] drm/ttm: Refcount allocated tail pages

On 8/15/22 13:05, Christian König wrote: > Am 15.08.22 um 11:54 schrieb Dmitry Osipenko: >> Higher order pages allocated using alloc_pages() aren't refcounted and >> they >> need to be refcounted, otherwise it's impossible to map them by KVM. This >> patch sets the

Re: [PATCH] drm/bridge: sii902x: add support for DRM_BRIDGE_ATTACH_NO_CONNECTOR

08.08.2022 12:15, Neil Armstrong пишет: > Hi Dmitry, > > On 31/07/2022 22:07, Dmitry Osipenko wrote: >> 13.01.2022 17:43, Neil Armstrong пишет: >>> This adds support for DRM_BRIDGE_ATTACH_NO_CONNECTOR by adding the >>> bridge get_edid() and detect() callback

Re: [PATCH] drm/bridge: sii902x: add support for DRM_BRIDGE_ATTACH_NO_CONNECTOR

08.08.2022 12:51, Neil Armstrong пишет: > On 08/08/2022 11:15, Neil Armstrong wrote: >> Hi Dmitry, >> >> On 31/07/2022 22:07, Dmitry Osipenko wrote: >>> 13.01.2022 17:43, Neil Armstrong пишет: >>>> This adds support for DRM_BRIDGE_ATTACH_NO_CONNECTOR by ad

Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/12/22 14:34, Christian König wrote: > > > Am 10.08.22 um 20:53 schrieb Dmitry Osipenko: >> On 8/10/22 21:25, Christian König wrote: >>> Am 10.08.22 um 19:49 schrieb Dmitry Osipenko: >>>> On 8/10/22 14:30, Christian König wrote: >>>&g

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/11/22 02:19, Rob Clark wrote: > On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko > wrote: >> >> On 8/11/22 01:03, Rob Clark wrote: >>> On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko >>> wrote: >>>> >>>> On 8/10/22 18:08, Rob Clar

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/11/22 01:03, Rob Clark wrote: > On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko > wrote: >> >> On 8/10/22 18:08, Rob Clark wrote: >>> On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote: >>>> >>>> On Wed, Jul 06, 2022 at 10:02:07AM +0300

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/10/22 14:47, Daniel Vetter wrote: > Dmitry, since you have a bunch of patches merged now I think would also be > good to get commit rights so you can drive this more yourself. I've asked > Daniel Stone to help you out with getting that. > -Daniel Thank you! -- Best regards, Dmitry

Re: [PATCH v8 2/2] drm/gem: Don't map imported GEMs

On 8/10/22 18:08, Rob Clark wrote: > On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote: >> >> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote: >>> On 7/6/22 00:48, Rob Clark wrote: >>>> On Tue, Jul 5, 2022 at 4:51 AM Christian König >>

Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/10/22 21:25, Christian König wrote: > Am 10.08.22 um 19:49 schrieb Dmitry Osipenko: >> On 8/10/22 14:30, Christian König wrote: >>> Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: >>>> This patch moves the non-dynamic dma-buf users over to the dynamic >>

Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/10/22 14:30, Christian König wrote: >> + * - dma_buf_move_notify() > > This one is called by the exporter, not the importer. Good catch, thank you! -- Best regards, Dmitry

Re: [Linaro-mm-sig] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

On 8/10/22 14:30, Christian König wrote: > Am 25.07.22 um 17:18 schrieb Dmitry Osipenko: >> This patch moves the non-dynamic dma-buf users over to the dynamic >> locking specification. The strict locking convention prevents deadlock >> situation for dma-buf im

Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper

On 8/1/22 23:42, Rob Clark wrote: > On Mon, Aug 1, 2022 at 1:26 PM Dmitry Osipenko > wrote: >> >> On 8/1/22 23:13, Dmitry Osipenko wrote: >>> On 8/1/22 23:11, Dmitry Osipenko wrote: >>>> On 8/1/22 23:00, Rob Clark wrote: >>>>> On Mon

Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper

On 8/1/22 23:13, Dmitry Osipenko wrote: > On 8/1/22 23:11, Dmitry Osipenko wrote: >> On 8/1/22 23:00, Rob Clark wrote: >>> On Mon, Aug 1, 2022 at 12:41 PM Dmitry Osipenko >>> wrote: >>>> >>>> On 7/26/22 20:50, Rob Clark wrote: >>>>&g

Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper

On 8/1/22 23:11, Dmitry Osipenko wrote: > On 8/1/22 23:00, Rob Clark wrote: >> On Mon, Aug 1, 2022 at 12:41 PM Dmitry Osipenko >> wrote: >>> >>> On 7/26/22 20:50, Rob Clark wrote: >>>> +/** >>>> + * drm_gem_lru_remove - remove object f

Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper

On 8/1/22 23:00, Rob Clark wrote: > On Mon, Aug 1, 2022 at 12:41 PM Dmitry Osipenko > wrote: >> >> On 7/26/22 20:50, Rob Clark wrote: >>> +/** >>> + * drm_gem_lru_remove - remove object from whatever LRU it is in >>> + * >>

Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper

On 7/26/22 20:50, Rob Clark wrote: > +/** > + * drm_gem_lru_remove - remove object from whatever LRU it is in > + * > + * If the object is currently in any LRU, remove it. > + * > + * @obj: The GEM object to remove from current LRU > + */ > +void > +drm_gem_lru_remove(struct drm_gem_object *obj) >

Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper

On 7/29/22 18:40, Rob Clark wrote: > On Fri, Jul 29, 2022 at 8:27 AM Dmitry Osipenko > wrote: >> >> On 7/26/22 20:50, Rob Clark wrote: >>> +/** >>> + * drm_gem_lru_move_tail_locked - move the object to the tail of the LRU >>> + * >>> + *

Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper

On 7/26/22 20:50, Rob Clark wrote: > +/** > + * drm_gem_lru_move_tail_locked - move the object to the tail of the LRU > + * > + * If the object is already in this LRU it will be moved to the > + * tail. Otherwise it will be removed from whichever other LRU > + * it is in (if any) and moved into

[PATCH v2 5/5] dma-buf: Remove internal lock

-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 5 - include/linux/dma-buf.h | 9 - 2 files changed, 14 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index bfdd551c7571..1d211ab400a1 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma

[PATCH v2 4/5] media: videobuf2: Stop using internal dma-buf lock

. Acked-by: Tomasz Figa Signed-off-by: Dmitry Osipenko --- drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +-- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +-- drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +-- 3 files changed, 3

[PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification

ation lock and this patch makes them to take the lock. Intel and AMD GPU drivers already were mapping imported dma-bufs under the held lock, hence the "locked" variant of the functions are added for them and the drivers are updated to use the "locked" versions. Signed-off-by: Dmitry Osipe

[PATCH v2 1/5] dma-buf: Add _unlocked postfix to function names

functions to take the reservation lock. Suggested-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 76 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +- drivers/gpu/

[PATCH v2 2/5] drm/gem: Take reservation lock for vmap/vunmap operations

the lock. This patch prepares DRM core and drivers to transition to the common dma-buf locking convention where vmapping of exported GEMs will be done under the held reservation lock. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/drm_client.c | 4 ++-- drivers/gpu/drm/drm_gem.c

[PATCH v2 0/5] Move all drivers to a common dma-buf locking convention

uld take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave t

Re: [PATCH v8 0/2] DRM GEM fixes

Hi, On 7/1/22 12:02, Dmitry Osipenko wrote: > This patchset fixes two problems in the common GEM code. First fixed problem > is the bogus lockdep splat that complicates debugging of DRM drivers. Second > problem is the inconsistency in behaviour and improper handling of mapping >

Re: [PATCH v1 4/6] dma-buf: Acquire wait-wound context on attachment

On 7/20/22 11:29, Christian König wrote: > Am 19.07.22 um 22:05 schrieb Dmitry Osipenko: >> On 7/15/22 09:59, Dmitry Osipenko wrote: >>> On 7/15/22 09:50, Christian König wrote: >>>> Am 15.07.22 um 02:52 schrieb Dmitry Osipenko: >>>>> Intel i915 GPU

<    2   3   4   5   6   7   8   9   10   11   >