Am 02.10.23 um 20:22 schrieb Kees Cook:
On Mon, Oct 02, 2023 at 08:11:41PM +0200, Christian König wrote:
Am 02.10.23 um 20:08 schrieb Kees Cook:
On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote:
Am 02.10.23 um 18:53 schrieb Kees Cook:
On Mon, Oct 02, 2023 at 11:06:19AM -0400
Am 02.10.23 um 20:08 schrieb Kees Cook:
On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote:
Am 02.10.23 um 18:53 schrieb Kees Cook:
On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote:
On Mon, Oct 2, 2023 at 5:20 AM Christian König
wrote:
Am 29.09.23 um 21:33 schrieb
Am 02.10.23 um 18:53 schrieb Kees Cook:
On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote:
On Mon, Oct 2, 2023 at 5:20 AM Christian König
wrote:
Am 29.09.23 um 21:33 schrieb Kees Cook:
On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote:
This is a batch of patches touching drm
Am 29.09.23 um 21:33 schrieb Kees Cook:
On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote:
This is a batch of patches touching drm for preparing for the coming
implementation by GCC and Clang of the __counted_by attribute. Flexible
array members annotated with __counted_by can have their
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Xiaojian Du
Cc: Huang Rui
Cc: Kevin Wang
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees Cook
Acked-by: Alex Deucher
Am 29.08.23 um 09:29 schrieb Boris Brezillon:
On Tue, 29 Aug 2023 05:34:23 +0300
Dmitry Osipenko wrote:
On 8/28/23 13:12, Boris Brezillon wrote:
On Sun, 27 Aug 2023 20:54:43 +0300
Dmitry Osipenko wrote:
In a preparation of adding drm-shmem memory shrinker, move all reservation
locking
Am 27.08.23 um 19:54 schrieb Dmitry Osipenko:
Add simple kref_put_dma_resv() helper that wraps around kref_put_ww_mutex()
for drivers that needs to lock dma-resv on kref_put().
It's not possible to easily add this helper to kref.h because of the
headers inclusion dependency, hence add it to
Am 09.08.23 um 05:44 schrieb Ruan Jinjie:
The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie
Reviewed-by: Christian
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
Background is that this makes merge conflicts easier to handle and detect.
Really?
FWIW, I agree with
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/Kconfig | 1
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when
Am 26.05.23 um 05:32 schrieb Su Hui:
Pointer variables of (void*) type do not require type cast.
Please split that up by subsystem/driver. Taking it through the misc
tree might just cause merge conflicts.
Christian.
Signed-off-by: Su Hui
---
Am 25.03.23 um 15:58 schrieb Dmitry Osipenko:
On 3/15/23 16:46, Dmitry Osipenko wrote:
On 3/14/23 05:26, Dmitry Osipenko wrote:
@@ -633,7 +605,10 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem,
struct vm_area_struct
return ret;
}
+
Am 20.02.23 um 11:23 schrieb Tvrtko Ursulin:
On 20/02/2023 10:01, Christian König wrote:
Am 20.02.23 um 10:55 schrieb Tvrtko Ursulin:
Hi,
On 14/02/2023 13:59, Christian König wrote:
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail
Am 20.02.23 um 10:55 schrieb Tvrtko Ursulin:
Hi,
On 14/02/2023 13:59, Christian König wrote:
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having
Am 08.02.23 um 10:38 schrieb Matthew Auld:
On Wed, 8 Feb 2023 at 08:32, Christian König wrote:
Hey guys,
I'm pretty sure this is a bug in bochs which happens to surface because
of a recent TTM change, we have seen similar problems in the past with
this driver.
What happens is that userspace
Hey guys,
I'm pretty sure this is a bug in bochs which happens to surface because
of a recent TTM change, we have seen similar problems in the past with
this driver.
What happens is that userspace tries to bind a BO to a CRTC before the
BO has even a backing store.
Any idea how to fix
Am 20.10.22 um 12:37 schrieb Thomas Zimmermann:
Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as amdgpu uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().
h like was suggested by Michael Ruhl.
The scope of reservation locking is smaller now.
v4: - Added dma_buf_mmap() to the "locking convention" documentation,
which was missed by accident in v3.
- Added acks from Christian König, Tomasz Figa and Hans Verkuil that
Am 06.09.22 um 22:05 schrieb Daniel Vetter:
On Tue, Sep 06, 2022 at 10:01:47PM +0200, Daniel Vetter wrote:
On Mon, Aug 15, 2022 at 12:05:19PM +0200, Christian König wrote:
Am 15.08.22 um 11:54 schrieb Dmitry Osipenko:
Higher order pages allocated using alloc_pages() aren't refcounted
.
Changelog:
v4: - Added dma_buf_mmap() to the "locking convention" documentation,
which was missed by accident in v3.
- Added acks from Christian König, Tomasz Figa and Hans Verkuil that
they gave to couple v3 patches.
- Dropped the "_unlocked" postfix
internal lock.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
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
locking from the videobuf2
memory allocators.
Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Signed-off-by: Dmitry Osipenko
Acked-by: Christian König
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Reviewed-by: Christian König
---
Documentation/driver-api
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
Move dma-buf attachment mapping functions to the dynamic locking
specification by asserting that the reservation lock is held.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
drivers/dma-buf/dma-buf.c | 10 ++
1 file
-by: Dmitry Osipenko
Reviewed-by: Christian König
---
drivers/dma-buf/dma-buf.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ceea4839c641..073942bf5ae9 100644
--- a/drivers/dma-buf/dma-buf.c
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers/media/platform/nvidia
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers/xen/gntdev-dmabuf.c | 8
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers/misc/fastrpc.c | 6 +++---
1 file
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers/infiniband/core/umem_dmabuf.c
-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 3fa2da149639..7031db145a77 100644
--- a/drivers/gpu/drm/etnaviv
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers/gpu/drm/tegra/gem.c | 17
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers/gpu/drm/omapdrm
-by: Christian König , but it's probably
best if somebody from the Intel guys take a look as well.
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12
.../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Acked-by: Christian König
---
drivers/gpu/drm/armada/armada_gem.c | 8
Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
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
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 6
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
specification.
The strict locking convention prevents deadlock situations for dma-buf
importers
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 exporters.
Previously, the "unlocked" versions of the attachment API functions
weren't
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
specification.
The strict locking convention prevents deadlock situations for dma-buf
importers
Reviewed-by: Christian König to patches #2-#4
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations
internal lock.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
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
internal lock.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
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
internal lock.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
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
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 exporters.
Previously, the "unlocked" versions of the attachment API functions
weren't
This should work, but I'm really wondering if this makes a difference
for somebody.
Anyway the approach is fine with me: Acked-by: Christian König
Regards,
Christian.
Am 24.08.22 um 12:22 schrieb Dmitry Osipenko:
Move dma_buf_mmap_unlocked() function to the dynamic locking specification
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:
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
Am 18.08.22 um 01:13 schrieb Dmitry Osipenko:
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]
Well that comment sounds
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 cause issues with too many fd's. So I guess the best
thing is to keep the status quo and
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, it takes the temporal
reference during page fault and then drops the reference once
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 of the problem so I could start to
look at how to fix it properly. It's not apparent where the problem
Am 15.08.22 um 13:19 schrieb Dmitry Osipenko:
[SNIP]
I'll try to dig out the older discussions, thank you for the quick
reply!
Are you sure it was really discussed in public previously? All I can
find is yours two answers to a similar patches where you're saying that
this it's a wrong solution
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:09 schrieb Dmitry Osipenko:
On 8/15/22 13:05, Christian König wrote:
Am 15.08.22 um 11:54 schrieb
Am 15.08.22 um 12:18 schrieb Dmitry Osipenko:
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 order pages
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 order pages allocated using alloc_pages() aren't refcounted and
they
need to be refcounted, otherwise it's
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 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
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 refcount of the tail pages and fixes the KVM memory mapping
faults.
Without this
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:
Am 25.07.22 um 17:18 schrieb Dmitry Osipenko:
This patch moves the non-dynamic dma-buf users over to the dynamic
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
locking specification. The strict locking convention prevents deadlock
situation for dma-buf
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 importers and exporters.
Previously the "unlocked" versions of the dma-buf API functions
Am 10.08.22 um 10:33 schrieb Daniel Vetter:
On Wed, 10 Aug 2022 at 08:52, Christian König wrote:
Am 09.08.22 um 18:44 schrieb Daniel Vetter:
On Tue, Jul 05, 2022 at 01:33:51PM +0200, Christian König wrote:
Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
Use ww_acquire_fini() in the error code
Am 09.08.22 um 18:44 schrieb Daniel Vetter:
On Tue, Jul 05, 2022 at 01:33:51PM +0200, Christian König wrote:
Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
Use ww_acquire_fini() in the error code paths. Otherwise lockdep
thinks that lock is held when lock's memory is freed after
functions for the case where DRM core now holds
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
Reviewed-by: Christian König
on we will make the "unlocked"
functions to take the reservation lock.
Suggested-by: Christian König
Signed-off-by: Dmitry Osipenko
Could be that we later say we will remove the prefix again because some
functions should stay unlocked, but for now it makes it much clearer
what ha
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 driver uses wait-wound mutex to lock multiple GEMs on the
attachment to the i915 dma-buf. In order
Am 15.07.22 um 11:31 schrieb Dmitry Osipenko:
On 7/15/22 10:19, Christian König wrote:
-struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment
*attach,
- enum dma_data_direction direction)
+struct sg_table *
+dma_buf_map_attachment_unlocked(struct
Am 15.07.22 um 02:52 schrieb Dmitry Osipenko:
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked
on we will make the "unlocked"
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/
Am 15.07.22 um 02:52 schrieb Dmitry Osipenko:
Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the
attachment to the i915 dma-buf. In order to let all drivers utilize shared
wait-wound context during attachment in a general way, make dma-buf core to
acquire the ww context
. Let's prohibit the mapping for all DRM drivers
for consistency.
Suggested-by: Thomas Hellström
Signed-off-by: Dmitry Osipenko
I'm pretty sure that this is the right approach, but it's certainly more
than possible that somebody abused this already.
Anyway patch is Reviewed-by: Christian König
the noisy "WARNING: held lock freed!"
splat of VirtIO-GPU driver with CONFIG_DEBUG_MUTEXES=y and enabled lockdep.
Cc: sta...@vger.kernel.org
Fixes: 7edc3e3b975b5 ("drm: Add helpers for locking an array of BO
reservations.")
Reviewed-by: Thomas Hellström
Signed-off-by: Dmitry Osip
Am 30.06.22 um 01:06 schrieb Dmitry Osipenko:
On 6/29/22 11:43, Thomas Hellström (Intel) wrote:
On 6/29/22 10:22, Dmitry Osipenko wrote:
On 6/29/22 09:40, Thomas Hellström (Intel) wrote:
On 5/27/22 01:50, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers
Am 05.06.22 um 18:47 schrieb Daniel Vetter:
On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
wrote:
Introduce a common DRM SHMEM shrinker framework that allows to reduce
code duplication among DRM drivers by replacing theirs custom shrinker
implementations with the generic shrinker.
In order to
Hi Dmitry,
Am 30.05.22 um 15:26 schrieb Dmitry Osipenko:
Hello Christian,
On 5/30/22 09:50, Christian König wrote:
Hi Dmitry,
First of all please separate out this patch from the rest of the series,
since this is a complex separate structural change.
I assume all the patches will go via
Hi Dmitry,
First of all please separate out this patch from the rest of the series,
since this is a complex separate structural change.
Am 27.05.22 um 01:50 schrieb Dmitry Osipenko:
All dma-bufs have dma-reservation lock that allows drivers to perform
exclusive operations over shared
Am 11.05.22 um 21:05 schrieb Daniel Vetter:
[SNIP]
It's unclear to me which driver may ever want to do the mapping under
the dma_resv_lock. But if we will ever have such a driver that will need
to map imported buffer under dma_resv_lock, then we could always add the
dma_buf_vmap_locked()
Am 11.05.22 um 15:00 schrieb Daniel Vetter:
On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote:
[SNIP]
Since vmapping implies implicit pinning, we can't use a separate lock in
drm_gem_shmem_vmap() because we need to protect the
drm_gem_shmem_get_pages(), which is invoked by
We could need to wait for the pin to complete here.
Signed-off-by: Christian König
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_display.c | 8 +++-
1 file changed, 7 insertions(+), 1
() replace it.
Signed-off-by: Cong Liu
Looks sane to me, but I'm really not involved enough to fully judge.
Acked-by: Christian König
---
drivers/gpu/drm/qxl/qxl_kms.c | 4 ++--
drivers/gpu/drm/qxl/qxl_ttm.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
v1 1/2] drm/qxl: replace ioremap
by ioremap_cache on arm64
*日 期：*2022-03-23 18:17
*发件人：*Christian König
*收件人：*liucong2@kylinos.cnairlied@redhat.comkraxel@redhat.comairlied@linux.iedaniel@ffwll.chray.huang@amd.comvirtualization@lists.linux-foundation.orgspice-devel@lists.freedesktop.orgdri-de
] drm/qxl: replace ioremap by
ioremap_cache on arm64
*日 期：*2022-03-23 15:15
*发件人：*Christian König
*收件人：*CongLiuairlied@redhat.comkraxel@redhat.comairlied@linux.iedaniel@ffwll.chray.huang@amd.comvirtualization@lists.linux-foundation.orgspice-devel@lists.freedesktop.orgdri-de
Am 23.03.22 um 10:45 schrieb Robin Murphy:
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM
ioremap by ioremap_cache on
arm64
*日 期：*2022-03-23 15:15
*发件人：*Christian König
*收件人：*Cong
Liuairlied@redhat.comkraxel@redhat.comairlied@linux.iedaniel@ffwll.chray.huang@amd.comvirtualization@lists.linux-foundation.orgspice-devel@lists.freedesktop.orgdri-de...@lists.freedesktop.org
Am
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to MMIO space
is a well known bug of those ARM
Instead of dumping the fence info manually.
Signed-off-by: Christian König
Reviewed-by: Rob Clark
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm
Add functions to dump dma_fence and dma_resv objects into a seq_file and
use them for printing the debugfs information.
v2: fix missing include reported by test robot.
Signed-off-by: Christian König
Reviewed-by: Rob Clark
---
drivers/dma-buf/dma-buf.c | 11 +--
drivers/dma-buf/dma
Hi guys,
second round for those four patches adding some simple yet useful DMA-buf
helper functions for debugfs prints.
Fixed some missing includes and typos in commit messages.
Please review and/or comment,
Christian.
___
Virtualization mailing
Instead of hand rolling pretty much the same code.
Signed-off-by: Christian König
Reviewed-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
I'm not sure why it is useful to know the number of fences
in the reservation object, but we try to avoid exposing the
dma_resv_shared_list() function.
So use the iterator instead. If more information is desired
we could use dma_resv_describe() as well.
Signed-off-by: Christian König
I'm not sure why it is useful to know the number of fences
in the reservation object, but we try to avoid exposing the
dma_resv_shared_list() function.
So use the iterator instead. If more information is desired
we could use dma_resv_describe() as well.
Signed-off-by: Christian König
Instead of dumping the fence info manually.
Signed-off-by: Christian König
Reviewed-by: Rob Clark
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm
Instead of hand rolling pretty much the same code.
Signed-off-by: Christian König
Reviewed-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
Add functions to dump dma_fence and dma_resv objects into a seq_file and
use them for printing the debugfs informations.
Signed-off-by: Christian König
Reviewed-by: Rob Clark
---
drivers/dma-buf/dma-buf.c | 11 +--
drivers/dma-buf/dma-fence.c | 16
drivers/dma-buf
Am 11.05.21 um 10:50 schrieb Christoph Hellwig:
On Tue, May 11, 2021 at 09:35:20AM +0200, Christian König wrote:
We certainly going to need the drm_need_swiotlb() for userptr support
(unless we add some approach for drivers to opt out of swiotlb).
swiotlb use is driven by three things:
1
Am 11.05.21 um 08:05 schrieb Christoph Hellwig:
Use the dma_alloc_pages allocator for the TTM pool allocator.
This allocator is a front end to the page allocator which takes the
DMA mask of the device into account, thus offering the best of both
worlds of the two existing allocator versions.
a1f091f8ef2b680a5184db065527612247cb4cae
Author: Christian König
Date: Tue Oct 6 17:26:42 2020 +0200
drm/ttm: switch to per device LRU lock
Instead of having a global lock for potentially less contention.
The analysis is as follows:
617 int ttm_mem_evict_first(struct ttm_device *bdev,
618
Am 03.03.21 um 14:20 schrieb Thomas Gleixner:
From: Thomas Gleixner
There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().
Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.
Remove the NULL
Hi Vivek,
Am 12.02.21 um 09:36 schrieb Kasireddy, Vivek:
Hi Christian,
Hi Vivek,
[Kasireddy, Vivek] What if I do mmap() on the fd followed by mlock()
or mmap() followed by get_user_pages()? If it still fails, would
ioremapping the device memory and poking at the backing storage be an
1 - 100 of 136 matches
Mail list logo
