Linaro-mm-sig April 2026

linaro-mm-sig@lists.linaro.org

66 participants
192 discussions

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

by Nicolas Dufresne

Le jeudi 23 avril 2026 à 16:49 +0500, Mikhail Gavrilov a écrit : > On Wed, Apr 1, 2026 at 6:15 AM Kasireddy, Vivek > <vivek.kasireddy(a)intel.com> wrote: > > > > Acked-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> > > Will push this one to drm-misc-next soon. > > > > Thanks, > > Vivek > > Hi Vivek, > > I see the patch landed in drm-misc-next (504e2b4ab97a, tagged > drm-misc-next-2026-04-20), which targets 7.2. > > Since the patch has a Fixes: tag and Cc: stable, would it be > possible to also cherry-pick it into drm-misc-next-fixes so it > makes the 7.1 merge window that's closing soon? That would cause the same patch to exist with two different hash, which is generally causing trouble down the pipeline. Nicolas > > The bug is reproducible on current mainline and affects users > with CONFIG_DMA_API_DEBUG_SG enabled.

1 hour, 36 minutes

(no subject)

by leoevelyn768＠gmail.com

Recovering Your Lost Bitcoin: Trust Almighty Recovery Hacker In the ever-evolving world of cryptocurrency, the allure of investment opportunities has attracted many, but unfortunately, it has also led to a rise in fraudulent schemes. If you've fallen victim to a deceptive investment firm and lost your hard-earned Bitcoin, you're not alone. Fortunately, there is help available. Almighty Recovery Hacker is a specialized recovery firm dedicated to helping individuals like you trace and recover lost or stolen Bitcoin. Email... almightyrecoverycoin{(a)}mail.com Whatsapp... {+53 5 1 556969}

3 hours, 29 minutes

Dub Hub: Steve Kerr thinks

by MurasakiDeiivi＠gmail.com

Brandin Podziemski is trying in direction of do much too much , making it possible for an uncontested physical appearance in direction of Utah's secondleading , who completed with 6 details within just a seasonlow 18 minutes, didn't perform the minute quarter as the Warriors blew the recreation open up with a 4120 toward reporters the moment Tuesday's train, Kerr claimed the thirdyear secure's present struggles stem towards trying toward do much too a lot.Through 18 video games, Podziemski is averaging 12.4 information upon 43.8% capturing, such as 37.9% against 3 and 77.8% at the freethrow consists of been powerful as the staff's secondary ballhandler powering Stephen Curry, still as Kerr notes, the Warriors wear't want even more towards Podziemski upon utmost ambition is there, still he's at his most straightforward Even though he leans into the job that enhances the veteran far more upon this and other information in the vicinity of the NBA, in this article is our newest information roundup for Wednesday, November 26th:Warriors Information:Warriors employ train toward lean into gameplan self-control right before Rockets showdown NBC Sporting activities Bay AreaSo, the Warriors, upon Tuesday, viewed movie of their 1347 victory that was manufactured upon the corrective motion taken around the supreme a few muted the Jazz within just the moment quarter, with a 4120 comfort, and rode the momentum toward a rout.What I observed as that very first quarter went upon was a absence of notice defensively, within just words and phrases of being familiar with the sport application, making an attempt in the direction of acquire out George and Markkanen and extremely be targeted upon them, ?Kerr mentioned soon after video clip evaluation and prepare at Chase Centre.And we make it possible for George attain 4 open up 3s in just the initial quarter.Warriors' Jonathan Kuminga toward be part of 5upon5 scrimmage, return even now unclear The AthleticKerr, who is made up of sounded annoyed within existing times When speaking about the deficiency of clarity close to Kuminga's reputation, supplied a sure enhance regarding the 23yearold just after Tuesday's train.He did threeonthree right before train, ?Kerr reported.And that went very then he took portion inside of all of he will gained't enjoy within just the video game Wednesday, nonetheless he will choose element within a fiveonfive scrimmage Wednesday night time just before our sport, and that will Deliver us a optimistic gauge for where by he is.Steph Curry discusses the thing to consider course of action guiding his shoe alternative as a refreshing sneaker no cost agentNBA Information:Where by just about every personnel stands throughout best 7 days of Community Engage in NBAThe Emirates NBA Cup includes accomplished the best 7 days of Local community Perform with 20 video games still left in the direction of Compute the 8 groups that will progress in the direction of the Knockout organized for the motion Wednesday upon ESPN, and a greatest video game Friday upon Best Video clip and League will progress in the direction of the Knockout Rounds? 8 areas are accessible.6 will transfer towards the winners of each individual supreme 2 wild card?areas will be the groups in opposition to every single convention with the ideal data within just Neighborhood Enjoy game titles who carried out moment inside their Suggs ejected just after scuffle through Magic76ers gameIn scenario yourself forgotten it at Golden Nation of Thoughts:How Jimmy Butler's manufacturer of isolation basketball fosters collectivismWhile simply just 5.6% of the Warriors' offensive belongings contain an isolation series 18th within the league it's a obvious uptick versus a time back, inside which 5% of their belongings had been isolations, 26th in just the the meantime, postup belongings on top of that professional a minimal uptick: against 2.3% very last time 22nd in direction of 3% this period Butler and his manufacturer of offense is made up of definitely performed a section guiding all those quantities https://www.goldenstatefanstore.com/collections/seth-curry-jersey, a option that is made up of tested in direction of be an thriving a person primarily based upon performance just 128 merged isolation and postup belongings amongst Butler which includes all those that conclusion within just a teammate getting a shot generate or neglected, freethrows, or turning the ball above the Warriors are scoring 1.047 information for every ownership, for each Synergy by unstoppablebaby upon X for all the hottest information upon the Golden Place Warriors. https://www.goldenstatefanstore.com Sitemap

12 hours, 29 minutes

[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

16 hours, 14 minutes

Eingles

by jamesjohnson987547＠gmail.com

How Can I Recover My Lost Cryptocurrency, Top Hire Ghost Mystery Recovery Hacker It sounds like Ghost Mystery Recovery Hacker made a real impact with their professionalism and communication. Recovering something that seems lost for good can be a huge relief! Did they use any particular methods or tools that impressed Or was it their customer service that made the process smooth and reassuring. seems like you're referring to an experience with a service called Ghost Mystery Recovery Hacker. From what you're saying, it sounds like they provided excellent assistance in helping you recover something important. Could you share a bit more about what they helped you recover and what stood out most about the experience. Was it their approach, tools, or something else, They took the time to understand my situation and explained each step in a way that was honest and easy to follow. They took the time to understand my situation and explained each step in a way that was honest and easy to follow. What stood out most was their consistency and dedication. I was kept informed throughout, and they remained patient and responsive whenever I had questions. Their expertise was evident in the way they handled everything carefully and efficiently, without creating false expectations.The outcome exceeded what I had hoped for. They were able to successfully resolve my issue, which brought me a great sense of relief. It’s not often you come across a service that combines professionalism, transparency, and results so well. Email address: support@ ghostmysteryrecovery. c om WhatsApp on (+44) 7480 061765 Website; ghostmysteryrecovery. c om

23 hours, 47 minutes

Eingles

by jamesjohnson987547＠gmail.com

23 hours, 47 minutes

Eingles

by jamesjohnson987547＠gmail.com

23 hours, 48 minutes

[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

1 day

[PATCH 1/2] dma-buf/dma_fence_array: remove unused functionality v3

by Christian König

Amdgpu was the only user of the signal on any feature and we dropped that use case recently, so we can remove that functionality. v2: update num_pending only after the fence is signaled v3: separate out simplifying dma_fence_array implementation Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence-array.c | 13 ++++--------- drivers/dma-buf/dma-fence-unwrap.c | 3 +-- drivers/dma-buf/dma-resv.c | 3 +-- drivers/dma-buf/st-dma-fence-unwrap.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 +-- drivers/gpu/drm/xe/xe_sync.c | 2 +- drivers/gpu/drm/xe/xe_vm.c | 4 ++-- include/linux/dma-fence-array.h | 6 ++---- 8 files changed, 13 insertions(+), 23 deletions(-) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 089f69469524..5e10e8df372f 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -190,15 +190,13 @@ EXPORT_SYMBOL(dma_fence_array_alloc); * @fences: [in] array containing the fences * @context: [in] fence context to use * @seqno: [in] sequence number to use - * @signal_on_any: [in] signal on any fence in the array * * Implementation of @dma_fence_array_create without allocation. Useful to init * a preallocated dma fence array in the path of reclaim or dma fence signaling. */ void dma_fence_array_init(struct dma_fence_array *array, int num_fences, struct dma_fence **fences, - u64 context, unsigned seqno, - bool signal_on_any) + u64 context, unsigned seqno) { static struct lock_class_key dma_fence_array_lock_key; @@ -222,7 +220,7 @@ void dma_fence_array_init(struct dma_fence_array *array, */ lockdep_set_class(&array->base.inline_lock, &dma_fence_array_lock_key); - atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences); + atomic_set(&array->num_pending, num_fences); array->fences = fences; array->base.error = PENDING_ERROR; @@ -249,7 +247,6 @@ EXPORT_SYMBOL(dma_fence_array_init); * @fences: [in] array containing the fences * @context: [in] fence context to use * @seqno: [in] sequence number to use - * @signal_on_any: [in] signal on any fence in the array * * Allocate a dma_fence_array object and initialize the base fence with * dma_fence_init(). @@ -264,8 +261,7 @@ EXPORT_SYMBOL(dma_fence_array_init); */ struct dma_fence_array *dma_fence_array_create(int num_fences, struct dma_fence **fences, - u64 context, unsigned seqno, - bool signal_on_any) + u64 context, unsigned seqno) { struct dma_fence_array *array; @@ -273,8 +269,7 @@ struct dma_fence_array *dma_fence_array_create(int num_fences, if (!array) return NULL; - dma_fence_array_init(array, num_fences, fences, - context, seqno, signal_on_any); + dma_fence_array_init(array, num_fences, fences, context, seqno); return array; } diff --git a/drivers/dma-buf/dma-fence-unwrap.c b/drivers/dma-buf/dma-fence-unwrap.c index 07fe9bf45aea..53bb40e70b27 100644 --- a/drivers/dma-buf/dma-fence-unwrap.c +++ b/drivers/dma-buf/dma-fence-unwrap.c @@ -180,8 +180,7 @@ struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, if (count > 1) { result = dma_fence_array_create(count, array, - dma_fence_context_alloc(1), - 1, false); + dma_fence_context_alloc(1), 1); if (!result) { for (i = 0; i < count; i++) dma_fence_put(array[i]); diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index ce9e6c04897f..39a92d9f2413 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -648,8 +648,7 @@ int dma_resv_get_singleton(struct dma_resv *obj, enum dma_resv_usage usage, } array = dma_fence_array_create(count, fences, - dma_fence_context_alloc(1), - 1, false); + dma_fence_context_alloc(1), 1); if (!array) { while (count--) dma_fence_put(fences[count]); diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c index 51c87869b7b8..4e7ee25372ba 100644 --- a/drivers/dma-buf/st-dma-fence-unwrap.c +++ b/drivers/dma-buf/st-dma-fence-unwrap.c @@ -64,7 +64,7 @@ static struct dma_fence *mock_array(unsigned int num_fences, ...) array = dma_fence_array_create(num_fences, fences, dma_fence_context_alloc(1), - 1, false); + 1); if (!array) goto error_free; return &array->base; diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 942f4eed817f..4a1a9031f9db 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -3205,8 +3205,7 @@ eb_composite_fence_create(struct i915_execbuffer *eb, int out_fence_fd) fence_array = dma_fence_array_create(eb->num_batches, fences, eb->context->parallel.fence_context, - eb->context->parallel.seqno++, - false); + eb->context->parallel.seqno++); if (!fence_array) { kfree(fences); return ERR_PTR(-ENOMEM); diff --git a/drivers/gpu/drm/xe/xe_sync.c b/drivers/gpu/drm/xe/xe_sync.c index 24d6d9af20d6..37866768d64c 100644 --- a/drivers/gpu/drm/xe/xe_sync.c +++ b/drivers/gpu/drm/xe/xe_sync.c @@ -376,7 +376,7 @@ xe_sync_in_fence_get(struct xe_sync_entry *sync, int num_sync, xe_assert(vm->xe, current_fence == num_fence); cf = dma_fence_array_create(num_fence, fences, dma_fence_context_alloc(1), - 1, false); + 1); if (!cf) goto err_out; diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 56e2db50bb36..8f472911469d 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -3370,7 +3370,7 @@ static struct dma_fence *ops_execute(struct xe_vm *vm, goto err_trace; } - cf = dma_fence_array_alloc(n_fence); + cf = dma_fence_array_alloc(); if (!cf) { fence = ERR_PTR(-ENOMEM); goto err_out; @@ -3414,7 +3414,7 @@ static struct dma_fence *ops_execute(struct xe_vm *vm, xe_assert(vm->xe, current_fence == n_fence); dma_fence_array_init(cf, n_fence, fences, dma_fence_context_alloc(1), - 1, false); + 1); fence = &cf->base; for_each_tile(tile, vm->xe, id) { diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h index 370b3d2bba37..1b1d87579c38 100644 --- a/include/linux/dma-fence-array.h +++ b/include/linux/dma-fence-array.h @@ -81,13 +81,11 @@ to_dma_fence_array(struct dma_fence *fence) struct dma_fence_array *dma_fence_array_alloc(int num_fences); void dma_fence_array_init(struct dma_fence_array *array, int num_fences, struct dma_fence **fences, - u64 context, unsigned seqno, - bool signal_on_any); + u64 context, unsigned seqno); struct dma_fence_array *dma_fence_array_create(int num_fences, struct dma_fence **fences, - u64 context, unsigned seqno, - bool signal_on_any); + u64 context, unsigned seqno); bool dma_fence_match_context(struct dma_fence *fence, u64 context); -- 2.43.0

1 day, 4 hours

[PATCH] dma-buf: system_heap: Optimize sg_table-to-pages conversion in vmap

by Barry Song (Xiaomi)

From: Xueyuan Chen <Xueyuan.chen21(a)gmail.com> Replace the heavy for_each_sgtable_page() iterator in system_heap_do_vmap() with a more efficient nested loop approach. Instead of iterating page by page, we now iterate through the scatterlist entries via for_each_sgtable_sg(). Because pages within a single sg entry are physically contiguous, we can populate the page array with a in an inner loop using simple pointer math. This save a lot of time. The WARN_ON check is also pulled out of the loop to save branch instructions. Performance results mapping a 2GB buffer on Radxa O6: - Before: ~1440000 ns - After: ~232000 ns (~84% reduction in iteration time, or ~6.2x faster) Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Benjamin Gaignard <benjamin.gaignard(a)collabora.com> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: John Stultz <jstultz(a)google.com> Cc: T.J. Mercier <tjmercier(a)google.com> Cc: Christian König <christian.koenig(a)amd.com> Signed-off-by: Xueyuan Chen <Xueyuan.chen21(a)gmail.com> Signed-off-by: Barry Song (Xiaomi) <baohua(a)kernel.org> --- drivers/dma-buf/heaps/system_heap.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index b3650d8fd651..769f01f0cc96 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -224,16 +224,21 @@ static void *system_heap_do_vmap(struct system_heap_buffer *buffer) int npages = PAGE_ALIGN(buffer->len) / PAGE_SIZE; struct page **pages = vmalloc(sizeof(struct page *) * npages); struct page **tmp = pages; - struct sg_page_iter piter; void *vaddr; + u32 i, j, count; + struct page *base_page; + struct scatterlist *sg; if (!pages) return ERR_PTR(-ENOMEM); - for_each_sgtable_page(table, &piter, 0) { - WARN_ON(tmp - pages >= npages); - *tmp++ = sg_page_iter_page(&piter); + for_each_sgtable_sg(table, sg, i) { + base_page = sg_page(sg); + count = sg->length >> PAGE_SHIFT; + for (j = 0; j < count; j++) + *tmp++ = base_page + j; } + WARN_ON(tmp - pages != npages); vaddr = vmap(pages, npages, VM_MAP, PAGE_KERNEL); vfree(pages); -- 2.39.3 (Apple Git-146)

1 day, 7 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig April 2026