Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

17 participants
3712 discussions

[PATCH v2] dma/contiguous: Fix broken build

by Maxime Ripard

Commit 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") didn't remove one last call to dma_heap_cma_register_heap() that it removed, thus breaking the build. That last call is in dma_contiguous_reserve(), to handle the registration of the default CMA region heap instance. The default CMA region instance is already somewhat handled by retrieving it through the dev_get_cma_area() call in the CMA heap driver. However, since commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"), we will create two heap instances for the CMA default region. The first one is always called "default_cma_region", and is the one handled by the call to dev_get_cma_area() mentioned earlier. The second one is the name it used to have prior to that last commit for backward compatibility. In the case where the default CMA region is defined in the DT, then that region is registered through rmem_cma_setup() and that region is added to the list of CMA regions to create a CMA heap instance for. In the case where the default CMA region is not defined in the DT though used to be the case covered by the now removed dma_heap_cma_register_heap() in dma_contiguous_reserve(). If we only remove the call to dma_heap_cma_register_heap(), then the legacy name of the CMA heap will not be registered anymore. We thus need to replace that call with a call to rmem_cma_insert_area() to make sure we queue this instance, if created, to create a heap instance. Once that call to dma_heap_cma_register_heap() replaced, we can also remove the now unused function definition, its now empty header, and all includes of this header. Fixes: 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") Reported-by: Mark Brown <broonie(a)kernel.org> Closes: https://lore.kernel.org/linux-next/acbjaDJ1a-YQC64d@sirena.co.uk/ Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v2: - Fix creation of the CMA heap instance with the legacy name when not declared in the DT. - Link to v1: https://lore.kernel.org/r/20260330-dma-build-fix-v1-1-748b64f0d8af@kernel.o… --- drivers/dma-buf/heaps/cma_heap.c | 1 - include/linux/dma-buf/heaps/cma.h | 16 ---------------- kernel/dma/contiguous.c | 14 +++++++++++--- 3 files changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 7216a14262b04bb6130ddf26b7d009f7d15b03fd..9a8b36bc929f6daa483a0139a2919d95127e0d23 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -12,11 +12,10 @@ #define pr_fmt(fmt) "cma_heap: " fmt #include <linux/cma.h> #include <linux/dma-buf.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-heap.h> #include <linux/dma-map-ops.h> #include <linux/err.h> #include <linux/highmem.h> #include <linux/io.h> diff --git a/include/linux/dma-buf/heaps/cma.h b/include/linux/dma-buf/heaps/cma.h deleted file mode 100644 index e751479e21e703e24a5f799b4a7fc8bd0df3c1c4..0000000000000000000000000000000000000000 --- a/include/linux/dma-buf/heaps/cma.h +++ /dev/null @@ -1,16 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef DMA_BUF_HEAP_CMA_H_ -#define DMA_BUF_HEAP_CMA_H_ - -struct cma; - -#ifdef CONFIG_DMABUF_HEAPS_CMA -int dma_heap_cma_register_heap(struct cma *cma); -#else -static inline int dma_heap_cma_register_heap(struct cma *cma) -{ - return 0; -} -#endif // CONFIG_DMABUF_HEAPS_CMA - -#endif // DMA_BUF_HEAP_CMA_H_ diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index ad50512d71d3088a73e4b1ac02d6e6122374888e..d5d15983060c5c54744d6a63f2b591e1a3455b86 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -40,11 +40,10 @@ #include <asm/page.h> #include <linux/memblock.h> #include <linux/err.h> #include <linux/sizes.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-map-ops.h> #include <linux/cma.h> #include <linux/nospec.h> #ifdef CONFIG_CMA_SIZE_MBYTES @@ -217,10 +216,19 @@ static void __init dma_numa_cma_reserve(void) static inline void __init dma_numa_cma_reserve(void) { } #endif +#ifdef CONFIG_OF_RESERVED_MEM +static int rmem_cma_insert_area(struct cma *cma); +#else +static inline int rmem_cma_insert_area(struct cma *cma) +{ + return 0; +} +#endif + /** * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling * @limit: End address of the reserved memory (optional, 0 for any). * * This function reserves memory from early allocator. It should be @@ -271,13 +279,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit) &dma_contiguous_default_area, fixed); if (ret) return; - ret = dma_heap_cma_register_heap(dma_contiguous_default_area); + ret = rmem_cma_insert_area(dma_contiguous_default_area); if (ret) - pr_warn("Couldn't register default CMA heap."); + pr_warn("Couldn't queue default CMA region for heap creation."); } } void __weak dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) --- base-commit: 6c683d5b1903a14e362c9f1628ce9fe61eac35e7 change-id: 20260330-dma-build-fix-706a4feb0e0f Best regards, -- Maxime Ripard <mripard(a)kernel.org>

7 months, 2 weeks

[PATCH] 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> --- 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 94b8ecb892bb..9c6f8785a28a 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -162,7 +162,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, ubuf->offsets[i]); - 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; @@ -177,7 +177,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

7 months, 2 weeks

[PATCH v9 0/7] Rust bindings for gem shmem

by Lyude Paul

This is the next version of the shmem backed GEM objects series originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/156093/ This patch series may be applied on top of the driver-core/driver-core-testing branch: https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git… Changelogs are per-patch Asahi Lina (2): rust: helpers: Add bindings/wrappers for dma_resv_lock rust: drm: gem: shmem: Add DRM shmem helper abstraction Lyude Paul (5): rust: drm: Add gem::impl_aref_for_gem_obj! rust: drm: gem: Add raw_dma_resv() function rust: gem: Introduce DriverObject::Args rust: drm: gem: Introduce shmem::SGTable rust: drm/gem: Add vmap functions to shmem bindings drivers/gpu/drm/nova/gem.rs | 5 +- drivers/gpu/drm/tyr/gem.rs | 3 +- rust/bindings/bindings_helper.h | 3 + rust/helpers/dma-resv.c | 13 + rust/helpers/drm.c | 56 ++- rust/helpers/helpers.c | 1 + rust/kernel/drm/gem/mod.rs | 79 +++- rust/kernel/drm/gem/shmem.rs | 654 ++++++++++++++++++++++++++++++++ 8 files changed, 792 insertions(+), 22 deletions(-) create mode 100644 rust/helpers/dma-resv.c create mode 100644 rust/kernel/drm/gem/shmem.rs base-commit: dc33ae50d32b509af5ae61030912fa20c79ef112 prerequisite-patch-id: c631986f96e2073263e97e82a65b96fc5ada6924 prerequisite-patch-id: ae853e8eb8d58c77881371960be4ae92755e83c6 prerequisite-patch-id: 0ab78b50648c7d8f66b83c32ed2af0ec3ede42a3 prerequisite-patch-id: 636ec7f913f4047e5e1a1788f3e835b7259698c2 prerequisite-patch-id: d75e4d7140eadeeed8017af8cd093bfd2766ee8e prerequisite-patch-id: 67a8010c1bc95bca1d2cf6b246c67bc79d24e766 -- 2.53.0

7 months, 2 weeks

[PATCH RESEND] dma-fence: Dereference correct dma_fence in dma_fence_chain_find_seqno()

by Li Ming

dma_fence_chain_find_seqno() uses dma_fence_chain_for_each() to walk a given dma_fence_chain. dma_fence_chain_for_each() always holds a reference for the current fence during iteration. The reference must be dropped after breaking out. Instead of dereferencing the last fence as intended, dma_fence_chain_find_seqno() incorrectly dereferences the first fence in the chain. Fixes: 7bf60c52e093 ("dma-buf: add new dma_fence_chain container v7") Signed-off-by: Li Ming <ming.li(a)zohomail.com> --- drivers/dma-buf/dma-fence-chain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index a8a90acf4f34..71fa173aef13 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -103,7 +103,7 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno) to_dma_fence_chain(*pfence)->prev_seqno < seqno) break; } - dma_fence_put(&chain->base); + dma_fence_put(*pfence); return 0; } --- base-commit: c369299895a591d96745d6492d4888259b004a9e change-id: 20260327-fix_dma_fence_chain_find_seqno-7adea64efe01 Best regards, -- Li Ming <ming.li(a)zohomail.com>

7 months, 2 weeks

[PATCH] dma/contiguous: Fix broken build

by Maxime Ripard

7 months, 2 weeks

[PATCH] dma-fence: Dereference correct dma_fence in dma_fence_chain_find_seqno()

by Li Ming

7 months, 2 weeks

[PATCH v3 0/8] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

Hi, The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules. It's generally a good idea if possible, including for the already existing system and CMA heaps. The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code. Let me know what you think, Maxime 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v3: - Squashed cma_get_name and cma_alloc/release patches - Fixed typo in Export dev_get_cma_area commit title - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06… Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (8): dma: contiguous: Turn heap registration logic around dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Make dma_contiguous_default_area static dma: contiguous: Export dev_get_cma_area() mm: cma: Export cma_alloc(), cma_release() and cma_get_name() dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 ++-- drivers/dma-buf/heaps/cma_heap.c | 21 +++++---------------- drivers/dma-buf/heaps/system_heap.c | 5 +++++ include/linux/dma-map-ops.h | 18 ++++++++++-------- kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++--- mm/cma.c | 3 +++ 7 files changed, 60 insertions(+), 29 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

7 months, 2 weeks

[PATCH v2 0/9] accel: New driver for NXP's Neutron NPU

by Ioana Ciocoi-Radulescu

Introduce a new accel driver for the Neutron Neural Processing Unit (NPU), along with associated dt-bindings and DTS node. The first patch extends the GEM DMA helper APIs to allow bidirectional mapping of non-coherent DMA buffers. While not part of the Neutron driver, it's a prerequisite allowing us to use the GEM DMA helper. Neutron is a Neural Processing Unit from NXP, providing machine learning (ML) acceleration for edge AI applications. Neutron is integrated on NXP SoCs such as the i.MX95. The NPU consists of the following: - RISC-V core running a proprietary firmware - One or more Neutron cores, representing the main computation engine performing ML operations - Dedicated fast memory (TCM) - DMA engine that handles data transfers between DDR and TCM The firmware is closed source and distributed as a binary here [1]. The Neutron software stack also contains a userspace library [1] and a LiteRT custom delegate [2] that allow integration with standard LiteRT tools. [1] https://github.com/nxp-upstream/neutron/tree/upstream [2] https://github.com/nxp-imx/tflite-neutron-delegate Signed-off-by: Ioana Ciocoi-Radulescu <ruxandra.radulescu(a)nxp.com> --- Changes in v2: - rebase on newer drm-misc-next - dt bindings: clock fixes and renames - update DTS to match new names - remove unnecessary fields from neutron_job structure - fix use of uninitialized variable - Link to v1: https://lore.kernel.org/r/20260226-neutron-v1-0-46eccb3bb50a@nxp.com --- Ioana Ciocoi-Radulescu (9): drm/gem-dma: Add flag for bidirectional mapping of non-coherent GEM DMA buffers accel/neutron: Add documentation for NXP Neutron accelerator driver dt-bindings: npu: Add NXP Neutron accel/neutron: Add driver for NXP Neutron NPU accel/neutron: Add GEM buffer object support accel/neutron: Add mailbox support accel/neutron: Add job submission IOCTL accel/neutron: Add logging support arm64: dts: imx95: Add Neutron node Documentation/accel/index.rst | 1 + Documentation/accel/neutron/index.rst | 12 + Documentation/accel/neutron/neutron.rst | 131 ++++++++ .../devicetree/bindings/npu/nxp,imx95-neutron.yaml | 96 ++++++ MAINTAINERS | 10 + arch/arm64/boot/dts/freescale/imx95.dtsi | 28 ++ drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 3 +- drivers/accel/neutron/Kconfig | 16 + drivers/accel/neutron/Makefile | 12 + drivers/accel/neutron/neutron_debugfs.c | 34 ++ drivers/accel/neutron/neutron_debugfs.h | 15 + drivers/accel/neutron/neutron_device.c | 239 +++++++++++++ drivers/accel/neutron/neutron_device.h | 155 +++++++++ drivers/accel/neutron/neutron_driver.c | 262 +++++++++++++++ drivers/accel/neutron/neutron_driver.h | 16 + drivers/accel/neutron/neutron_gem.c | 116 +++++++ drivers/accel/neutron/neutron_gem.h | 14 + drivers/accel/neutron/neutron_job.c | 372 +++++++++++++++++++++ drivers/accel/neutron/neutron_job.h | 43 +++ drivers/accel/neutron/neutron_mailbox.c | 47 +++ drivers/accel/neutron/neutron_mailbox.h | 42 +++ drivers/gpu/drm/drm_gem_dma_helper.c | 6 +- include/drm/drm_gem_dma_helper.h | 3 + include/uapi/drm/neutron_accel.h | 130 +++++++ 25 files changed, 1801 insertions(+), 3 deletions(-) --- base-commit: 6716101ae42949e98ad4b9e71eeba08c055be410 change-id: 20260226-neutron-c435e39d167f Best regards, -- Ioana Ciocoi-Radulescu <ruxandra.radulescu(a)nxp.com>

7 months, 2 weeks

corgi puppies for sale near me

by Tirrell Otalvaro

7 months, 3 weeks

Diving Headfirst into the Addictive World of io Games

by ideal.elephant.yxcu＠hidingmail.com

Ever find yourself with five minutes to spare and a craving for some quick, competitive fun? Look no further than the ever-expanding universe of io games! These browser-based gems offer instant gratification and addictive gameplay, making them perfect for short bursts of entertainment or even surprisingly engaging longer sessions. Let's explore how to get started and truly enjoy these simple yet captivating games. https://iogamesweb.com/ Introduction: What's the Allure of io Games? The beauty of io games lies in their accessibility. No downloads, no complex tutorials, just pure, unadulterated gaming. Often featuring simple graphics and intuitive controls, they're incredibly easy to pick up. But don't let the simplicity fool you – under the hood lies competitive gameplay that can be surprisingly strategic and rewarding. The “io” suffix typically indicates a game hosted on a public domain, allowing for many different developers and styles within the genre. Tips for Thriving in the io Arena While easy to learn, mastering io games requires some strategy. Here are a few tips to help you succeed: Observe and Adapt: Pay attention to the gameplay style of other players. Are they aggressive or defensive? What strategies are they using? Adjust your own approach accordingly. Learn the Maps: Familiarize yourself with the layout of each game's map. Knowing where resources are located and where potential dangers lurk can give you a significant advantage. Team Up (Sometimes): Some io games encourage or even necessitate teamwork. Forming alliances with other players can provide mutual protection and increase your chances of survival. However, be wary of betrayal! Practice Makes Perfect: The more you play, the better you'll become at understanding the game's mechanics, anticipating enemy movements, and executing effective strategies. Don’t get discouraged if you are constantly losing in the beginning. Have Fun! The most important tip of all! Don't take the games too seriously. Relax, experiment, and enjoy the fast-paced, chaotic nature of io games. Explore different types of io games to find what style best suits your gaming preferences. Conclusion: A Quick Escape for the Modern Gamer io games offer a fantastic escape for anyone looking for a quick dose of competitive fun. Their accessibility, simple mechanics, and addictive gameplay make them a perfect choice for short breaks or longer gaming sessions. So, jump in, give it a try, and prepare to be captivated by the surprisingly engaging world of io games!

7 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig