Hi Shixiong,
could also be that I didn't fully got what you try to do here.
Between which drivers and implementations are the BOs shared exactly?
You could also just rebase your patches on drm-misc-next and send them out
again and I can take another look.
Regards,
Christian.
On 5/5/25 17:11,
Hi Christian,
I don't see strong relevance between my patch and the patches you're
referring to.
Because the drm_gem_prime_import() function imports sg_table by default,
my patch provides an alternative
import callback implementation for SHMEM-based drivers that differs from
drm_gem_prime_impo
Hi Shixiong,
for drm changes please base your patches on drm-misc-next or drm-next.
That is probably fixed by this one here:
commit b72f66f22c0e39ae6684c43fead774c13db24e73
Author: Christian König
Date: Tue Feb 11 17:20:53 2025 +0100
dma-buf: drop caching of sg_tables
That was p
Hi Christian,
My patch is based on linux-next, so this patch is not based on the
latest code. Then, I'd like to ask which patch resolved the issue with
sg-tables?
Thanks and Regards,
Shixiong.
在 2025/5/5 19:25, Christian König 写道:
Hi Thomas & Shixiong,
first of all the patch is still ba
Hi Thomas & Shixiong,
first of all the patch is still based on outdated code. For example the
cache_sgt_mapping member is already removed in drm-misc-next.
So if I'm not completely mistaken the issue is already resolved upstream.
Regards,
Christian.
On 5/5/25 13:12, Thomas Zimmermann wrote:
>
(cc'ing Christian)
Hi,
I don't feel qualified to fully review this patch.
It would be good to have the issue with sg-tables solved, but I dislike
the dedicated initializer macros. So my question is if this has any
drawbacks. Or could we make this available and the default for all
shmem-based
From: Shixiong Ou
[WHY]
1. Drivers using DRM_GEM_SHADOW_PLANE_HELPER_FUNCS and
DRM_GEM_SHMEM_DRIVER_OPS (e.g., udl, ast) do not require
sg_table import.
They only need dma_buf_vmap() to access the shared buffer's
kernel virtual address.
2. On certain Aspeed-based boards, a dma_mask o
