Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

19 participants
3646 discussions

Re: [PATCH v11 08/11] tee: add Qualcomm TEE driver

by Dmitry Baryshkov

On Wed, Sep 10, 2025 at 08:41:21PM -0700, Amirreza Zarrabi wrote: > Introduce qcomtee_object, which represents an object in both QTEE and > the kernel. QTEE clients can invoke an instance of qcomtee_object to > access QTEE services. If this invocation produces a new object in QTEE, > an instance of qcomtee_object will be returned. > > Similarly, QTEE can request services from by issuing a callback > request, which invokes an instance of qcomtee_object. > > Implement initial support for exporting qcomtee_object to userspace > and QTEE, enabling the invocation of objects hosted in QTEE and userspace > through the TEE subsystem. > > Tested-by: Neil Armstrong <neil.armstrong(a)linaro.org> > Tested-by: Harshal Dev <quic_hdev(a)quicinc.com> > Acked-by: Sumit Garg <sumit.garg(a)oss.qualcomm.com> > Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> > --- > MAINTAINERS | 6 + > drivers/tee/Kconfig | 1 + > drivers/tee/Makefile | 1 + > drivers/tee/qcomtee/Kconfig | 12 + > drivers/tee/qcomtee/Makefile | 7 + > drivers/tee/qcomtee/async.c | 182 +++++++ > drivers/tee/qcomtee/call.c | 813 +++++++++++++++++++++++++++++++ > drivers/tee/qcomtee/core.c | 906 +++++++++++++++++++++++++++++++++++ > drivers/tee/qcomtee/qcomtee.h | 143 ++++++ > drivers/tee/qcomtee/qcomtee_msg.h | 304 ++++++++++++ > drivers/tee/qcomtee/qcomtee_object.h | 316 ++++++++++++ > drivers/tee/qcomtee/shm.c | 153 ++++++ > drivers/tee/qcomtee/user_obj.c | 692 ++++++++++++++++++++++++++ > include/uapi/linux/tee.h | 1 + > 14 files changed, 3537 insertions(+) > > + > +static int > +qcomtee_object_invoke_ctx_invoke(struct qcomtee_object_invoke_ctx *oic, > + int *result, u64 *res_type) > +{ > + phys_addr_t out_msg_paddr; > + phys_addr_t in_msg_paddr; > + int ret; > + u64 res; > + > + tee_shm_get_pa(oic->out_shm, 0, &out_msg_paddr); > + tee_shm_get_pa(oic->in_shm, 0, &in_msg_paddr); > + if (!(oic->flags & QCOMTEE_OIC_FLAG_BUSY)) > + ret = qcom_scm_qtee_invoke_smc(in_msg_paddr, oic->in_msg.size, > + out_msg_paddr, oic->out_msg.size, > + &res, res_type); > + else > + ret = qcom_scm_qtee_callback_response(out_msg_paddr, > + oic->out_msg.size, > + &res, res_type); > + > + if (ret) > + pr_err("QTEE returned with %d.\n", ret); > + else > + *result = (int)res; After enablign QCOMTEE driver, I observe the following error during the bootup on RB3 Gen2: [ 4.720777] qcomtee: QTEE returned with -22. [ 4.725251] qcomtee: QTEE version 0.0.0 > + > + return ret; > +} > + -- With best wishes Dmitry

5 months, 2 weeks

[PATCH v2] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning

by Mikhail Gavrilov

When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> --- v1 -> v2: - Rebased on drm-tip to resolve conflict with folio conversion patches. No code change, same two-line fix. v1: https://lore.kernel.org/all/20260317053653.28888-1-mikhail.v.gavrilov@gmail… drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b26ea706a3..bced421c0d65 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -145,7 +145,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, if (ret < 0) goto err_alloc; - ret = dma_map_sgtable(dev, sg, direction, 0); + ret = dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); if (ret < 0) goto err_map; return sg; @@ -160,7 +160,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, static void put_sg_table(struct device *dev, struct sg_table *sg, enum dma_data_direction direction) { - dma_unmap_sgtable(dev, sg, direction, 0); + dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sg); kfree(sg); } -- 2.53.0

5 months, 3 weeks

[PATCH v13 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() rust: drm: gem/shmem: Add DmaResvGuard helper rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 32 +- include/drm/drm_gem_shmem_helper.h | 1 + rust/kernel/drm/gem/shmem.rs | 602 ++++++++++++++++++++++++- 3 files changed, 614 insertions(+), 21 deletions(-) base-commit: d9a6809478f9815b6455a327aa001737ac7b2c09 -- 2.54.0

5 months, 3 weeks

[PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports

by Markus Fritsche

Hi, This series proposes a small opt-in API in videobuf2-core that lets V4L2 drivers populate a dma_resv exclusive write fence on the dmabufs they export to userspace, signalled when the buffer transitions to VB2_BUF_STATE_DONE. Two example drivers (hantro, rockchip-rga) opt in to demonstrate the call shape; the change is no-op for every other driver. Why --- Modern Wayland compositors and any other userspace consumers that import V4L2-produced dmabufs and want to do implicit synchronization the spec-clean way (poll(POLLIN) on the dmabuf fd, or DMA_BUF_IOCTL_EXPORT_SYNC_FILE for a sync_file) currently get either: 1. A stub fence from dma_buf_export_sync_file(), because the dmabuf's dma_resv has no fences populated. The kernel substitutes dma_fence_get_stub() which is permanently signalled. The compositor "successfully" waits on a fence that represents nothing real about the producer's state. 2. A poll(POLLIN) on the dmabuf fd that returns immediately for the same reason — dma_buf_poll_add_cb finds zero fences in the resv, triggers the wake callback inline, and reports POLLIN ready before the producer has actually said anything. Today this works as a happy accident on most paths because clients attach buffers after VIDIOC_DQBUF, which the userspace V4L2 contract guarantees only returns a buffer after the producer is done. So the implicit "the kernel's stub fence is fine because the buffer is already complete by the time anyone polls it" assumption has held. But: - It's a contract gap. The kernel claims to expose implicit sync; it does not, for V4L2 producers. - It paid latency for nothing. Every Wayland frame from a V4L2 producer pays a DMA_BUF_IOCTL_EXPORT_SYNC_FILE round-trip for a fence that's stub-signalled. On Mali-class hardware (RK3566 Wayland chrome video playback), this contributed to compositor stalls. Removing the wait at the compositor level is a workaround, not a fix. - It blocks downstream consumers from doing the right thing. A Wayland compositor that defensively waits on a sync_file gets a stub-fence pass-through with no actual gating; if the V4L2 driver ever has an out-of-band path that releases the buffer before finishing the write, there is no fence to gate on. What ---- Patch 1 adds: - struct dma_fence *release_fence to struct vb2_buffer - u64 dma_resv_fence_context + atomic64_t dma_resv_fence_seqno + spinlock_t dma_resv_fence_lock to struct vb2_queue - vb2_buffer_attach_release_fence(vb) — drivers call this from their buf_queue callback. Allocates a dma_fence on the queue's fence context, attaches it as DMA_RESV_USAGE_WRITE on each plane's dmabuf->resv. No-op for buffers without exported dmabufs. - vb2_buffer_done() extended to signal+put the fence if attached, so the producer's completion signal lands in the resv synchronously with the userspace DQBUF wakeup. Patches 2 and 3 add a single call to the helper from hantro_buf_queue and rga_buf_queue respectively. Both are demonstration drivers; other vb2 drivers can opt in incrementally with the same one-line change. Tested on --------- PineTab2 (RK3566 / Mali-G52 panfrost / mainline 6.19.10, this series backported), playing 1080p30 H.264 in chromium under KDE Plasma 6.6.4 Wayland. The test harness is the chromium-fourier patch series at https://github.com/marfrit/fourier — chromium plus a KWin patch that *previously bypassed* Transaction::watchDmaBuf because the kernel-side fence was stub-signalled. With this series applied, the bypass becomes unnecessary; KWin's fence wait completes correctly because the fence now signals when hantro completes the capture buffer write. End-to-end result before the kernel patch (chromium + Qt 6 patches + KWin watchDmaBuf bypass): 1080p30 H.264 plays through, ~81% combined chrome CPU, but the watchDmaBuf bypass weakens KWin's defenses against misbehaving clients. End-to-end result after the kernel patch (chromium + Qt 6 patches + plain unmodified KWin): 1080p30 H.264 plays through with the same CPU profile, KWin's watchDmaBuf wait completes within microseconds against the now-real producer fence, no defenses weakened. What's missing in this RFC -------------------------- - Other vb2-using drivers don't opt in. Each maintainer should look at their driver and decide. The hantro + rga patches show the shape; copying it to other drivers should be straightforward. - For drivers that have intermediate image-processor stages (e.g. CSI -> ISP -> user), the fence semantics across stage boundaries are out of scope here. This series only addresses the producer-to- userspace edge. - No selftest. videobuf2 doesn't have a great in-tree selftest harness for dmabuf flows; the validation is end-to-end at the userspace consumer level (KWin, in our case). Reviews especially welcome on: - The decision to make this opt-in per driver vs. automatic for all vb2-CAPTURE queues. Auto-on would force every driver to be audited; opt-in is incremental and safer but leaves the contract gap for drivers nobody touches. - Whether vb2_buffer_done is the right place to signal vs. an earlier hook (e.g. immediately after DMA-from-device finishes). For hantro the two are effectively the same; for drivers with asynchronous post-processing they may differ. - The choice of DMA_RESV_USAGE_WRITE — we are emitting the producer's write completion, so WRITE matches dma-buf documentation, but a sanity check is welcome. Cheers, Markus Markus Fritsche (3): media: videobuf2: add dma_resv release-fence helper media: hantro: attach dma_resv release fence at buf_queue media: rockchip-rga: attach dma_resv release fence at buf_queue .../media/common/videobuf2/videobuf2-core.c | 95 +++++++++++++++++++ drivers/media/platform/rockchip/rga/rga-buf.c | 10 ++ .../media/platform/verisilicon/hantro_v4l2.c | 12 +++ include/media/videobuf2-core.h | 29 ++++++ 4 files changed, 146 insertions(+) -- 2.47.3

5 months, 3 weeks

[PATCH v2] dma-buf: heaps: use max3() in dma_heap_ioctl

by Thorsten Blum

Replace two nested max() calls with a single max3() in dma_heap_ioctl(). Reviewed-by: T.J. Mercier <tjmercier(a)google.com> Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Changes in v2: - Include minmax.h as suggested by T.J. Mercier - v1: https://lore.kernel.org/lkml/20260427172519.417333-3-thorsten.blum@linux.de… --- drivers/dma-buf/dma-heap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index ac5f8685a649..d49188893608 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -13,6 +13,7 @@ #include <linux/err.h> #include <linux/export.h> #include <linux/list.h> +#include <linux/minmax.h> #include <linux/nospec.h> #include <linux/syscalls.h> #include <linux/uaccess.h> @@ -153,7 +154,7 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, in_size = 0; if ((ucmd & kcmd & IOC_OUT) == 0) out_size = 0; - ksize = max(max(in_size, out_size), drv_size); + ksize = max3(in_size, out_size, drv_size); /* If necessary, allocate buffer for ioctl argument */ if (ksize > sizeof(stack_kdata)) {

5 months, 3 weeks

[PATCH] dma-buf: heaps: use max3() in dma_heap_ioctl

by Thorsten Blum

Replace two nested max() calls with a single max3() in dma_heap_ioctl(). Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/dma-buf/dma-heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index ac5f8685a649..52eec2ebb2e8 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -153,7 +153,7 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, in_size = 0; if ((ucmd & kcmd & IOC_OUT) == 0) out_size = 0; - ksize = max(max(in_size, out_size), drv_size); + ksize = max3(in_size, out_size, drv_size); /* If necessary, allocate buffer for ioctl argument */ if (ksize > sizeof(stack_kdata)) {

5 months, 3 weeks

[PATCH V13 0/7] Rust support for powerpc

by Mukesh Kumar Chaurasiya (IBM)

Enable experimental rust support for ppc64le and ppc32be. The patch for ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been merged over it. ppc32 needs some toolchain fixes mentioned in the patch `rust: Add PowerPC support` and the discussion for that is done here[1]. This has been tested on - powernv9 hardware - pseries P11 hardware - pseries(9, 10) qemu - powernv(9, 10) qemu - rustdoc on x86 and powerpc64le - rusttest on x86 and powerpc64le We are actively working with our LLVM team to get the target for ppc, ppc64 and ppc64le in the rust compiler. [1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr [2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com Changelog: V12 -> V13: - Added a patch for fixing build issue on ppc32 by Link Mauve - Added another patch to fix a build issue in dma-buf - Added another patch to enforce minimum `rustc` version for powerpc V12: https://lore.kernel.org/all/20260421120958.190430-1-mkchauras@gmail.com/ V11 -> V12: - Rebased to mainline (rust/Makefile conflict resolved) V11: https://lore.kernel.org/all/20260417152253.2312961-1-mkchauras@gmail.com/ V10 -> V11: - Updated `rust/Makefile` - Not all libraries are move to `rust/host` directory now. Only proc_macro2, quote and syn are moved - Special handling for pin init is added. Details in commit - Removed mkdir for `rust/host`, this is now handled by toolchain. V10: https://lore.kernel.org/all/20260406200149.3727922-1-mkchauras@gmail.com/ V9 -> V10: - rust/Makefile updated with review comments from Miguel - Patch 1/4 updated with commit message and subject V9: https://lore.kernel.org/all/20260404121610.1956528-1-mkchauras@gmail.com/ V8 -> V9: - rust/Makefile updated with a directory instead of abspath V8: https://lore.kernel.org/all/20260403145308.1042622-1-mkchauras@gmail.com/ V7 -> V8: - rust/Makefile updated to separate host libraries from target V7: https://lore.kernel.org/all/20260329160254.2592207-1-mkchauras@gmail.com/ Changelog: V6 -> V7: - Documentation removed as powerpc is still under development - Added a fix for race condition in rust/Makefile V6: https://lore.kernel.org/all/20260210090023.2587534-1-mkchauras@gmail.com V5 -> V6: - Added a missing Tested by from Venkat which got missed since V3 - Support is marked as Maintained instead of experimental V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com V4 -> V5: - Removed a nested ifdef from PPC64 for Little endian toolchain V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com V3 -> V4: - Co-developed-by header added in patch 1 V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com V2 -> V3: - Splited HAVE_RUST in 2 lines - BINDGEN_TARGET_powerpc initialized before assigning the same to BINDGEN_TARGET V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com V1 -> V2: - jump label fix for rust has been moved to a separate patch - PPC32 support has been taken - rust support has been marked experimental - target.json dependency has been removed - HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64 Link Mauve (2): rust: Make __udivdi3() and __umoddi3() panic rust: Add PowerPC support Mukesh Kumar Chaurasiya (IBM) (5): rust: Fix "multiple candidates for rmeta dependency core" error dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled powerpc/jump_label: adjust inline asm to be consistent rust/powerpc: Set min rustc version for powerpc powerpc: Enable Rust for ppc64le arch/powerpc/Kconfig | 2 ++ arch/powerpc/Makefile | 7 ++++ arch/powerpc/include/asm/jump_label.h | 23 ++++++------ include/linux/dma-resv.h | 2 +- rust/Makefile | 52 +++++++++++++++++---------- rust/compiler_builtins.rs | 6 ++++ scripts/min-tool-version.sh | 6 +++- 7 files changed, 68 insertions(+), 30 deletions(-) -- 2.53.0

5 months, 3 weeks

[PATCH v12 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() drm/gem/shmem: Export drm_gem_shmem_get_pages_sgt_locked() rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++- include/drm/drm_gem_shmem_helper.h | 2 + rust/kernel/drm/gem/shmem.rs | 557 ++++++++++++++++++++++++- 3 files changed, 593 insertions(+), 14 deletions(-) base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd -- 2.53.0

5 months, 3 weeks

[PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them

by Jason Gunthorpe

Since its introduction, DMA-buf has only supported using scatterlist for the exporter and importer to exchange address information. This is not sufficient for all use cases as dma_addr_t is a very specific and limited type that should not be abused for things unrelated to the DMA API. There are several motivations for addressing this now: 1) VFIO to IOMMUFD and KVM requires a physical address, not a dma_addr_t scatterlist, it cannot be represented in the scatterlist structure 2) xe vGPU requires the host driver to accept a DMABUF from VFIO of its own VF and convert it into an internal VRAM address on the PF 3) We are starting to look at replacement datastructures for scatterlist 4) Ideas around UALink/etc are suggesting not using the DMA API None of these can sanely be achieved using scatterlist. Introduce a new mechanism called "mapping types" which allows DMA-buf to work with more map/unmap options than scatterlist. Each mapping type encompasses a full set of functions and data unique to itself. The core code provides a match-making system to select the best type offered by the exporter and importer to be the active mapping type for the attachment. Everything related to scatterlist is moved into a DMA-buf SGT mapping type, and into the "dma_buf_sgt_*" namespace for clarity. Existing exporters are moved over to explicitly declare SGT mapping types and importers are adjusted to use the dma_buf_sgt_* named importer helpers. Mapping types are designed to be extendable, a driver can declare its own mapping type for its internal private interconnect and use that without having to adjust the core code. The new attachment sequence starts with the importing driver declaring what mapping types it can accept: struct dma_buf_mapping_match imp_match[] = { DMA_BUF_IMAPPING_MY_DRIVER(dev, ...), DMA_BUF_IMAPPING_SGT(dev, false), }; attach = dma_buf_mapping_attach(dmabuf, imp_match, ...) Most drivers will do this via a dma_buf_sgt_*attach() helper. The exporting driver can then declare what mapping types it can supply: int exporter_match_mapping(struct dma_buf_match_args *args) { struct dma_buf_mapping_match exp_match[] = { DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...), DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false), DMA_BUF_EMAPPING_PAL(PAL_ops), }; return dma_buf_match_mapping(args, exp_match, ...); } Most drivers will do this via a helper: static const struct dma_buf_ops ops = { DMA_BUF_SIMPLE_SGT_EXP_MATCH(map_func, unmap_func) }; During dma_buf_mapping_attach() the core code will select a mutual match between the importer and exporter and record it as the active match in the attach->map_type. Each mapping type has its own types/function calls for mapping/unmapping, and storage in the attach->map_type for its information. As such each mapping type can offer function signatures and data that exactly matches its needs. This series goes through a sequence of: 1) Introduce the basic mapping type framework and the main components of the SGT mapping type 2) Automatically make all existing exporters and importers use core generated SGT mapping types so every attachment has a SGT mapping type 3) Convert all exporter drivers to natively create a SGT mapping type 4) Move all dma_buf_* functions and types that are related to SGT into dma_buf_sgt_* 5) Remove all the now-unused items that have been moved into SGT specific structures. 6) Demonstrate adding a new Physical Address List alongside SGT. Due to the high number of files touched I would expect this to be broken into phases, but this shows the entire picture. This is on github: https://github.com/jgunthorpe/linux/commits/dmabuf_map_type It is a followup to the discussion here: https://lore.kernel.org/dri-devel/20251027044712.1676175-1-vivek.kasireddy@… Jason Gunthorpe (26): dma-buf: Introduce DMA-buf mapping types dma-buf: Add the SGT DMA mapping type dma-buf: Add dma_buf_mapping_attach() dma-buf: Route SGT related actions through attach->map_type dma-buf: Allow single exporter drivers to avoid the match_mapping function drm: Check the SGT ops for drm_gem_map_dma_buf() dma-buf: Convert all the simple exporters to use SGT mapping type drm/vmwgfx: Use match_mapping instead of dummy calls accel/habanalabs: Use the SGT mapping type drm/xe/dma-buf: Use the SGT mapping type drm/amdgpu: Use the SGT mapping type vfio/pci: Change the DMA-buf exporter to use mapping_type dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type iio: buffer: convert to use the SGT mapping type functionfs: convert to use the SGT mapping type dma-buf: Remove unused SGT stuff from the common structures treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() dma-buf: Add the Physical Address List DMA mapping type vfio/pci: Add physical address list support to DMABUF iommufd: Use the PAL mapping type instead of a vfio function iommufd: Support DMA-bufs with multiple physical ranges iommufd/selftest: Check multi-phys DMA-buf scenarios dma-buf: Add kunit tests for mapping type Documentation/gpu/todo.rst | 2 +- drivers/accel/amdxdna/amdxdna_gem.c | 14 +- drivers/accel/amdxdna/amdxdna_ubuf.c | 10 +- drivers/accel/habanalabs/common/memory.c | 54 ++- drivers/accel/ivpu/ivpu_gem.c | 10 +- drivers/accel/ivpu/ivpu_gem_userptr.c | 11 +- drivers/accel/qaic/qaic_data.c | 8 +- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-mapping.c | 186 ++++++++- drivers/dma-buf/dma-buf.c | 180 ++++++--- drivers/dma-buf/heaps/cma_heap.c | 12 +- drivers/dma-buf/heaps/system_heap.c | 13 +- drivers/dma-buf/st-dma-mapping.c | 373 ++++++++++++++++++ drivers/dma-buf/udmabuf.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 98 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/armada/armada_gem.c | 33 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 31 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 8 +- drivers/gpu/drm/msm/msm_gem_prime.c | 7 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 11 +- drivers/gpu/drm/tegra/gem.c | 33 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 23 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 32 +- drivers/gpu/drm/xe/xe_bo.c | 18 +- drivers/gpu/drm/xe/xe_dma_buf.c | 61 +-- drivers/iio/industrialio-buffer.c | 15 +- drivers/infiniband/core/umem_dmabuf.c | 15 +- drivers/iommu/iommufd/io_pagetable.h | 4 +- drivers/iommu/iommufd/iommufd_private.h | 8 - drivers/iommu/iommufd/iommufd_test.h | 7 + drivers/iommu/iommufd/pages.c | 85 ++-- drivers/iommu/iommufd/selftest.c | 177 ++++++--- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 21 +- .../common/videobuf2/videobuf2-vmalloc.c | 13 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 9 +- drivers/misc/fastrpc.c | 21 +- drivers/tee/tee_heap.c | 13 +- drivers/usb/gadget/function/f_fs.c | 11 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 79 ++-- drivers/xen/gntdev-dmabuf.c | 29 +- include/linux/dma-buf-mapping.h | 297 ++++++++++++++ include/linux/dma-buf.h | 168 ++++---- io_uring/zcrx.c | 9 +- net/core/devmem.c | 14 +- samples/vfio-mdev/mbochs.c | 10 +- sound/soc/fsl/fsl_asrc_m2m.c | 12 +- tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 17 + 55 files changed, 1764 insertions(+), 614 deletions(-) create mode 100644 drivers/dma-buf/st-dma-mapping.c base-commit: c63e5a50e1dd291cd95b04291b028fdcaba4c534 -- 2.43.0

6 months

[PATCH v11 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here (+ a hack required to make sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() drm/gem/shmem: Export drm_gem_shmem_get_pages_sgt_locked() rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++- include/drm/drm_gem_shmem_helper.h | 2 + rust/kernel/drm/gem/shmem.rs | 557 ++++++++++++++++++++++++- 3 files changed, 593 insertions(+), 14 deletions(-) base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd -- 2.53.0

6 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig