Am 09.04.25 um 17:04 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
>>> I only see improvement by making things more obvious.
>>>
>>> In any case, how would you call a wrapper that just does
>>> test_bit(IS_SIGNALED, …) ?
Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
>> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
>>> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>>>> On Wed, 2025-04-09 at 14:39 +0200, Boris Bre
Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
>> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
>>> Hi Philipp,
>>>
>>> On Wed, 9 Apr 2025 14:06:37 +0200
>>> Philipp Stanner wrote:
>>>
dma_fence_is_signaled()'s name stron
determining what
error code to return or whether corrective action can be taken at
the driver level.
Cc: Christian König
Cc: Matthew Brost
Signed-off-by: Thomas Hellström
Independent of how we communicate flags to the TTM device init function
this looks like the right approach to me.
So feel
the kernel.
It obviously has some advantages, but do we have any precedence in the
kernel for using that approach?
Regards,
Christian.
This is in preparation of adding yet another bool flag parameter to the
function.
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Cc:
Am 27.02.24 um 19:14 schrieb Dmitry Osipenko:
Hello,
Thank you for the patches!
On 2/27/24 13:14, Thomas Zimmermann wrote:
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in DRM
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Regards,
Christian.
Am 27.02.24 um 11:14 schrieb Thomas Zimmermann:
Dma-buf locking semantics require the caller of pin and unpin to
Am 27.11.23 um 17:47 schrieb Bhardwaj, Rajneesh:
[AMD Official Use Only - General]
-Original Message-
From: amd-gfx On Behalf Of Hamza Mahfooz
Sent: Monday, November 27, 2023 10:53 AM
To: Christian König ; jani.nik...@linux.intel.com;
kher...@redhat.com; d...@redhat.com; za
Try to fill up VRAM as well by setting the busy flag on GTT allocations.
This fixes the issue that when VRAM was evacuated for suspend it's never
filled up again unless the application is restarted.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6
From: Somalapuram Amaranath
Instead of a list of separate busy placement add flags which indicate
that a placement should only be used when there is room or if we need to
evict.
v2: add missing TTM_PL_FLAG_IDLE for i915
v3: fix auto build test ERROR on drm-tip/drm-tip
Signed-off-by: Christian
Hi guys,
TTM has a feature which allows to specify placements for normal operation as
well as when all domains are "busy" and don't have free space.
Not very widely used since it was a bit inflexible and required making multiple
placement lists. Replace the multiple lists with flags and start t
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: virtualizat...@lists.linux-foundation.org
Cc: spice-devel@lists.freedesktop.org
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers
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 thes
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
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu
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. This
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 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().
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 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 w
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
We could need to wait for the pin to complete here.
Signed-off-by: Christian König
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-devel@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_display.c | 8 +++-
1 file changed, 7 insertions(+), 1
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
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 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.
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
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 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. Thi
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
mmit 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,
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 poin
problem, but
this explains it properly and also fixes it up cleanly.
If you would like:
Reviewed-by: Michael J. Ruhl
Feel free to add an Reviewed-by: Christian König
as well.
Regards,
Christian.
For this solution as well.
Mike
___
Sp
Zimmermann
Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement")
Cc: Christian König
Cc: Michael J. Ruhl
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Alex Deucher
r of vmap helpers (Daniel,
Christian)
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Tested-by: Sam Ravnborg
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72 +
Hi Thomas,
[SNIP]
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = &bo->mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_
Am 15.10.20 um 19:52 schrieb Thomas Zimmermann:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's
mmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3213429f8444..2d5e
: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17
rmann
The amdgpu changes look good to me, but I can't fully judge the other stuff.
Acked-by: Christian König
---
Documentation/gpu/todo.rst | 18
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drive
PM Christian König
wrote:
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi
Am 02.10.20 um 11:58 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes s
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct dma_buf_map
with these values. Helpful for TTM-based drivers.
We could completely drop that if we use the same struct
Am 29.09.20 um 12:53 schrieb Daniel Vetter:
On Tue, Sep 29, 2020 at 11:51:15AM +0200, Gerd Hoffmann wrote:
Otherwise ttm throws a WARN because we try to pin without a reservation.
Fixes: 9d36d4320462 ("drm/qxl: switch over to the new pin interface")
Signed-off-by: Gerd Hoffmann
---
drivers/g
Those are not supposed to be used by drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 086ba2c2f60b..2eca752c39e9 100644
--- a/drivers
The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
used in a driver.
Instead call the qxl_ttm_io_mem_reserve() function directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_drv.h| 2 ++
drivers/gpu/drm/qxl/qxl_object.c | 11 +--
driver
manager.
When passing NULL the embedded _vma_manager is used.
All callers are updated to pass NULL, so the behavior doesn't change.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 8 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
Am 11.03.19 um 17:39 schrieb Hans de Goede:
Hi,
On 07-02-19 09:59, Thomas Zimmermann wrote:
Almost all TTM-based drivers use the same values for the mmap-able
range of BO addresses. Each driver therefore duplicates the
DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not
configurab
ffset as other drivers
drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant
drm/ttm: Remove file_page_offset parameter from ttm_bo_device_init()
drm/ttm: Quick-test mmap offset in ttm_bo_mmap()
drm: Use the same mmap-range offset and size for GEM and TTM
Reviewed-by: Christian König
60 matches
Mail list logo
