- Linaro-mm-sig - lists.linaro.org

[PATCH AUTOSEL 6.17] drm/xe: improve dma-resv handling for backup object

by Sasha Levin

From: Matthew Auld <matthew.auld(a)intel.com> [ Upstream commit edb1745fc618ba8ef63a45ce3ae60de1bdf29231 ] Since the dma-resv is shared we don't need to reserve and add a fence slot fence twice, plus no need to loop through the dependencies. Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt(a)intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Link: https://lore.kernel.org/r/20250829164715.720735-2-matthew.auld@intel.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: YES Explanation - What it fixes - Removes redundant dma-resv operations when a backup BO shares the same reservation object as the original BO, preventing the same fence from being reserved/added twice to the same `dma_resv`. - Avoids scanning the same dependency set twice when source and destination BOs share the same `dma_resv`. - Why the change is correct - The backup object is created to share the parent’s reservation object, so a single reserve/add is sufficient: - The backup BO is initialized with the parent’s resv: `drivers/gpu/drm/xe/xe_bo.c:1309` (`xe_bo_init_locked(..., bo->ttm.base.resv, ...)`), ensuring `bo->ttm.base.resv == backup->ttm.base.resv`. - The patch adds an explicit invariant check to document and enforce this: `drivers/gpu/drm/xe/xe_bo.c:1225` (`xe_assert(xe, bo->ttm.base.resv == backup->ttm.base.resv)`). - With shared `dma_resv`, adding the same fence twice is at best redundant (wasting fence slots and memory) and at worst error-prone. Reserving fence slots only once and adding the fence once is the correct behavior. - Specific code changes and effects - Evict path (GPU migration copy case): - Before: reserves and adds fence on both `bo->ttm.base.resv` and `backup->ttm.base.resv`. - After: reserves and adds exactly once, guarded by the shared-resv assertion. - See single reserve and add: `drivers/gpu/drm/xe/xe_bo.c:1226` (reserve) and `drivers/gpu/drm/xe/xe_bo.c:1237` (add fence). This is the core fix; the removed second reserve/add on the backup is the redundant part eliminated. - Restore path (migration copy back): - Same simplification: reserve once, add once on the shared `dma_resv`. - See single reserve and add: `drivers/gpu/drm/xe/xe_bo.c:1375` (reserve) and `drivers/gpu/drm/xe/xe_bo.c:1387` (add fence). - Dependency handling in migrate: - Before: added deps for both src and dst based only on `src_bo != dst_bo`. - After: only add dst deps if the resv objects differ, avoiding double-walking the same `dma_resv`. - See updated condition: `drivers/gpu/drm/xe/xe_migrate.c:932` (`src_bo->ttm.base.resv != dst_bo->ttm.base.resv`). - User-visible impact without the patch - Duplicate `dma_resv_add_fence()` calls on the same reservation object can: - Consume extra shared-fence slots and memory. - Inflate dependency lists, causing unnecessary scheduler waits and overhead. - Increase failure likelihood of `dma_resv_reserve_fences()` under memory pressure. - These paths are exercised during suspend/resume flows of pinned VRAM BOs (evict/restore), so reliability and performance in power transitions can be affected. - Scope and risk - Small, focused changes localized to the Intel Xe driver migration/evict/restore paths: - Files: `drivers/gpu/drm/xe/xe_bo.c`, `drivers/gpu/drm/xe/xe_migrate.c`. - No API changes or architectural refactors; logic strictly reduces redundant operations. - The `xe_assert` acts as a safety net to catch unexpected non-shared `resv` usage; normal runtime behavior is unchanged when the invariant holds. - The CPU copy fallback paths are untouched. - Stable backport considerations - This is a clear correctness and robustness fix, not a feature. - Low regression risk if the stable branch also creates the backup BO with the parent’s `dma_resv` (as shown by the use of `xe_bo_init_locked(..., bo->ttm.base.resv, ...)` in `drivers/gpu/drm/xe/xe_bo.c:1309`). - If a stable branch diverges and the backup BO does not share the resv, this patch would need adjustment (i.e., keep dual reserve/add in that case). The added `xe_assert` helps surface such mismatches during testing. Conclusion: This commit fixes a real bug (duplicate fence reserve/add and duplicate dependency scanning on a shared `dma_resv`) with a minimal, well-scoped change. It aligns with stable rules (important bugfix, low risk, contained), so it should be backported. drivers/gpu/drm/xe/xe_bo.c | 13 +------------ drivers/gpu/drm/xe/xe_migrate.c | 2 +- 2 files changed, 2 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c index d07e23eb1a54d..5a61441d68af5 100644 --- a/drivers/gpu/drm/xe/xe_bo.c +++ b/drivers/gpu/drm/xe/xe_bo.c @@ -1242,14 +1242,11 @@ int xe_bo_evict_pinned(struct xe_bo *bo) else migrate = mem_type_to_migrate(xe, bo->ttm.resource->mem_type); + xe_assert(xe, bo->ttm.base.resv == backup->ttm.base.resv); ret = dma_resv_reserve_fences(bo->ttm.base.resv, 1); if (ret) goto out_backup; - ret = dma_resv_reserve_fences(backup->ttm.base.resv, 1); - if (ret) - goto out_backup; - fence = xe_migrate_copy(migrate, bo, backup, bo->ttm.resource, backup->ttm.resource, false); if (IS_ERR(fence)) { @@ -1259,8 +1256,6 @@ int xe_bo_evict_pinned(struct xe_bo *bo) dma_resv_add_fence(bo->ttm.base.resv, fence, DMA_RESV_USAGE_KERNEL); - dma_resv_add_fence(backup->ttm.base.resv, fence, - DMA_RESV_USAGE_KERNEL); dma_fence_put(fence); } else { ret = xe_bo_vmap(backup); @@ -1338,10 +1333,6 @@ int xe_bo_restore_pinned(struct xe_bo *bo) if (ret) goto out_unlock_bo; - ret = dma_resv_reserve_fences(backup->ttm.base.resv, 1); - if (ret) - goto out_unlock_bo; - fence = xe_migrate_copy(migrate, backup, bo, backup->ttm.resource, bo->ttm.resource, false); @@ -1352,8 +1343,6 @@ int xe_bo_restore_pinned(struct xe_bo *bo) dma_resv_add_fence(bo->ttm.base.resv, fence, DMA_RESV_USAGE_KERNEL); - dma_resv_add_fence(backup->ttm.base.resv, fence, - DMA_RESV_USAGE_KERNEL); dma_fence_put(fence); } else { ret = xe_bo_vmap(backup); diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c index 2a627ed64b8f8..ba9b8590eccb2 100644 --- a/drivers/gpu/drm/xe/xe_migrate.c +++ b/drivers/gpu/drm/xe/xe_migrate.c @@ -901,7 +901,7 @@ struct dma_fence *xe_migrate_copy(struct xe_migrate *m, if (!fence) { err = xe_sched_job_add_deps(job, src_bo->ttm.base.resv, DMA_RESV_USAGE_BOOKKEEP); - if (!err && src_bo != dst_bo) + if (!err && src_bo->ttm.base.resv != dst_bo->ttm.base.resv) err = xe_sched_job_add_deps(job, dst_bo->ttm.base.resv, DMA_RESV_USAGE_BOOKKEEP); if (err) -- 2.51.0

1 month, 3 weeks

1
0
0 0

Re: [PATCH v2] dma-buf: system_heap: use larger contiguous mappings instead of per-page mmap

by Maxime Ripard

On Tue, 21 Oct 2025 17:20:22 +1300, Barry Song wrote: > From: Barry Song <v-songbaohua(a)oppo.com> > > We can allocate high-order pages, but mapping them one by > one is inefficient. This patch changes the code to map > as large a chunk as possible. The code looks somewhat > > [ ... ] Reviewed-by: Maxime Ripard <mripard(a)kernel.org> Thanks! Maxime

1 month, 3 weeks

1
0
0 0

[PATCH v5 3/8] rust: drm: gem: Add raw_dma_resv() function

by Lyude Paul

For retrieving a pointer to the struct dma_resv for a given GEM object. We also introduce it in a new trait, BaseObjectPrivate, which we automatically implement for all gem objects and don't expose to users outside of the crate. Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- rust/kernel/drm/gem/mod.rs | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs index 32bff2e8463f4..67813cfb0db42 100644 --- a/rust/kernel/drm/gem/mod.rs +++ b/rust/kernel/drm/gem/mod.rs @@ -200,6 +200,18 @@ fn create_mmap_offset(&self) -> Result<u64> { impl<T: IntoGEMObject> BaseObject for T {} +/// Crate-private base operations shared by all GEM object classes. +#[expect(unused)] +pub(crate) trait BaseObjectPrivate: IntoGEMObject { + /// Return a pointer to this object's dma_resv. + fn raw_dma_resv(&self) -> *mut bindings::dma_resv { + // SAFETY: `as_gem_obj()` always returns a valid pointer to the base DRM gem object + unsafe { (*self.as_raw()).resv } + } +} + +impl<T: IntoGEMObject> BaseObjectPrivate for T {} + /// A base GEM object. /// /// Invariants -- 2.51.0

1 month, 3 weeks

1
0
0 0

[PATCH v5 2/8] rust: helpers: Add bindings/wrappers for dma_resv_lock

by Lyude Paul

From: Asahi Lina <lina(a)asahilina.net> This is just for basic usage in the DRM shmem abstractions for implied locking, not intended as a full DMA Reservation abstraction yet. Signed-off-by: Asahi Lina <lina(a)asahilina.net> Signed-off-by: Daniel Almeida <daniel.almeida(a)collabora.com> Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- rust/bindings/bindings_helper.h | 1 + rust/helpers/dma-resv.c | 13 +++++++++++++ rust/helpers/helpers.c | 1 + 3 files changed, 15 insertions(+) create mode 100644 rust/helpers/dma-resv.c diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h index 2e43c66635a2c..07f79e125c329 100644 --- a/rust/bindings/bindings_helper.h +++ b/rust/bindings/bindings_helper.h @@ -48,6 +48,7 @@ #include <linux/cpumask.h> #include <linux/cred.h> #include <linux/debugfs.h> +#include <linux/dma-resv.h> #include <linux/device/faux.h> #include <linux/dma-direction.h> #include <linux/dma-mapping.h> diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c new file mode 100644 index 0000000000000..05501cb814513 --- /dev/null +++ b/rust/helpers/dma-resv.c @@ -0,0 +1,13 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/dma-resv.h> + +int rust_helper_dma_resv_lock(struct dma_resv *obj, struct ww_acquire_ctx *ctx) +{ + return dma_resv_lock(obj, ctx); +} + +void rust_helper_dma_resv_unlock(struct dma_resv *obj) +{ + dma_resv_unlock(obj); +} diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c index 551da6c9b5064..36d40f911345c 100644 --- a/rust/helpers/helpers.c +++ b/rust/helpers/helpers.c @@ -25,6 +25,7 @@ #include "cred.c" #include "device.c" #include "dma.c" +#include "dma-resv.c" #include "drm.c" #include "err.c" #include "irq.c" -- 2.51.0

1 month, 3 weeks

1
0
0 0

Re: [PATCH v5 2/2] accel: Add Arm Ethos-U NPU driver

by Rob Herring

On Tue, Oct 21, 2025 at 4:43 PM Matthew Brost <matthew.brost(a)intel.com> wrote: > > On Sat, Oct 18, 2025 at 12:42:30AM -0700, Matthew Brost wrote: > > On Fri, Oct 17, 2025 at 11:43:51PM -0700, Matthew Brost wrote: > > > On Fri, Oct 17, 2025 at 10:37:46AM -0500, Rob Herring wrote: > > > > On Thu, Oct 16, 2025 at 11:25:34PM -0700, Matthew Brost wrote: > > > > > On Thu, Oct 16, 2025 at 04:06:05PM -0500, Rob Herring (Arm) wrote: > > > > > > Add a driver for Arm Ethos-U65/U85 NPUs. The Ethos-U NPU has a > > > > > > relatively simple interface with single command stream to describe > > > > > > buffers, operation settings, and network operations. It supports up to 8 > > > > > > memory regions (though no h/w bounds on a region). The Ethos NPUs > > > > > > are designed to use an SRAM for scratch memory. Region 2 is reserved > > > > > > for SRAM (like the downstream driver stack and compiler). Userspace > > > > > > doesn't need access to the SRAM. > > > > > > > > Thanks for the review. > > > > > > > > [...] > > > > > > > > > > +static struct dma_fence *ethosu_job_run(struct drm_sched_job *sched_job) > > > > > > +{ > > > > > > + struct ethosu_job *job = to_ethosu_job(sched_job); > > > > > > + struct ethosu_device *dev = job->dev; > > > > > > + struct dma_fence *fence = NULL; > > > > > > + int ret; > > > > > > + > > > > > > + if (unlikely(job->base.s_fence->finished.error)) > > > > > > + return NULL; > > > > > > + > > > > > > + fence = ethosu_fence_create(dev); > > > > > > > > > > Another reclaim issue: ethosu_fence_create allocates memory using > > > > > GFP_KERNEL. Since we're already in the DMA fence signaling path > > > > > (reclaim), this can lead to a deadlock. > > > > > > > > > > Without too much thought, you likely want to move this allocation to > > > > > ethosu_job_do_push, but before taking dev->sched_lock or calling > > > > > drm_sched_job_arm. > > > > > > > > > > We really should fix the DRM scheduler work queue to be tainted with > > > > > reclaim. If I recall correctly, we'd need to update the work queue > > > > > layer. Let me look into that—I've seen this type of bug several times, > > > > > and lockdep should be able to catch it. > > > > > > > > Likely the rocket driver suffers from the same issues... > > > > > > > > > > I am not surprised by this statement. > > > > > > > > > > > > > > + if (IS_ERR(fence)) > > > > > > + return fence; > > > > > > + > > > > > > + if (job->done_fence) > > > > > > + dma_fence_put(job->done_fence); > > > > > > + job->done_fence = dma_fence_get(fence); > > > > > > + > > > > > > + ret = pm_runtime_get_sync(dev->base.dev); > > > > > > > > > > I haven't looked at your PM design, but this generally looks quite > > > > > dangerous with respect to reclaim. For example, if your PM resume paths > > > > > allocate memory or take locks that allocate memory underneath, you're > > > > > likely to run into issues. > > > > > > > > > > A better approach would be to attach a PM reference to your job upon > > > > > creation and release it upon job destruction. That would be safer and > > > > > save you headaches in the long run. > > > > > > > > Our PM is nothing more than clock enable/disable and register init. > > > > > > > > If the runtime PM API doesn't work and needs special driver wrappers, > > > > then I'm inclined to just not use it and manage clocks directly (as > > > > that's all it is doing). > > > > > > > > > > Yes, then you’re probably fine. More complex drivers can do all sorts of > > > things during a PM wake, which is why PM wakes should generally be the > > > outermost layer. I still suggest, to future-proof your code, that you > > > move the PM reference to an outer layer. > > > > > > > Also, taking a PM reference in a function call — as opposed to tying it > > to a object's lifetime — is risky. It can quickly lead to imbalances in > > PM references if things go sideways or function calls become unbalanced. > > Depending on how your driver uses the DRM scheduler, this seems like a > > real possibility. > > > > Matt > > > > > > > > > > > > This is what we do in Xe [1] [2]. > > > > > > > > > > Also, in general, this driver has been reviewed (RB’d), but it's not > > > > > great that I spotted numerous issues within just five minutes. I suggest > > > > > taking a step back and thoroughly evaluating everything this driver is > > > > > doing. > > > > > > > > Well, if it is hard to get simple drivers right, then it's a problem > > > > with the subsystem APIs IMO. > > > > > > > > > > Yes, agreed. We should have assertions and lockdep annotations in place > > > to catch driver-side misuses. This is the second driver I’ve randomly > > > looked at over the past year that has broken DMA fencing and reclaim > > > rules. I’ll take an action item to fix this in the DRM scheduler, but > > > I’m afraid I’ll likely break multiple drivers in the process as misuess > > > / lockdep will complain. > > I've posted a series [1] for the DRM scheduler which will complain about the > things I've pointed out here. Thanks. I ran v6 with them and no lockdep splats. Rob

1 month, 3 weeks

1
0
0 0

[PATCH v5 0/9] vfio/pci: Allow MMIO regions to be exported through dma-buf

by Leon Romanovsky

Changelog: v5: * Rebased on top of v6.18-rc1. * Added more validation logic to make sure that DMA-BUF length doesn't overflow in various scenarios. * Hide kernel config from the users. * Fixed type conversion issue. DMA ranges are exposed with u64 length, but DMA-BUF uses "unsigned int" as a length for SG entries. * Added check to prevent from VFIO drivers which reports BAR size different from PCI, do not use DMA-BUF functionality. v4: https://lore.kernel.org/all/cover.1759070796.git.leon@kernel.org * Split pcim_p2pdma_provider() to two functions, one that initializes array of providers and another to return right provider pointer. v3: https://lore.kernel.org/all/cover.1758804980.git.leon@kernel.org * Changed pcim_p2pdma_enable() to be pcim_p2pdma_provider(). * Cache provider in vfio_pci_dma_buf struct instead of BAR index. * Removed misleading comment from pcim_p2pdma_provider(). * Moved MMIO check to be in pcim_p2pdma_provider(). v2: https://lore.kernel.org/all/cover.1757589589.git.leon@kernel.org/ * Added extra patch which adds new CONFIG, so next patches can reuse * it. * Squashed "PCI/P2PDMA: Remove redundant bus_offset from map state" into the other patch. * Fixed revoke calls to be aligned with true->false semantics. * Extended p2pdma_providers to be per-BAR and not global to whole * device. * Fixed possible race between dmabuf states and revoke. * Moved revoke to PCI BAR zap block. v1: https://lore.kernel.org/all/cover.1754311439.git.leon@kernel.org * Changed commit messages. * Reused DMA_ATTR_MMIO attribute. * Returned support for multiple DMA ranges per-dMABUF. v0: https://lore.kernel.org/all/cover.1753274085.git.leonro@nvidia.com --------------------------------------------------------------------------- Based on "[PATCH v6 00/16] dma-mapping: migrate to physical address-based API" https://lore.kernel.org/all/cover.1757423202.git.leonro@nvidia.com/ series. --------------------------------------------------------------------------- This series extends the VFIO PCI subsystem to support exporting MMIO regions from PCI device BARs as dma-buf objects, enabling safe sharing of non-struct page memory with controlled lifetime management. This allows RDMA and other subsystems to import dma-buf FDs and build them into memory regions for PCI P2P operations. The series supports a use case for SPDK where a NVMe device will be owned by SPDK through VFIO but interacting with a RDMA device. The RDMA device may directly access the NVMe CMB or directly manipulate the NVMe device's doorbell using PCI P2P. However, as a general mechanism, it can support many other scenarios with VFIO. This dmabuf approach can be usable by iommufd as well for generic and safe P2P mappings. In addition to the SPDK use-case mentioned above, the capability added in this patch series can also be useful when a buffer (located in device memory such as VRAM) needs to be shared between any two dGPU devices or instances (assuming one of them is bound to VFIO PCI) as long as they are P2P DMA compatible. The implementation provides a revocable attachment mechanism using dma-buf move operations. MMIO regions are normally pinned as BARs don't change physical addresses, but access is revoked when the VFIO device is closed or a PCI reset is issued. This ensures kernel self-defense against potentially hostile userspace. The series includes significant refactoring of the PCI P2PDMA subsystem to separate core P2P functionality from memory allocation features, making it more modular and suitable for VFIO use cases that don't need struct page support. ----------------------------------------------------------------------- The series is based originally on https://lore.kernel.org/all/20250307052248.405803-1-vivek.kasireddy@intel.c… but heavily rewritten to be based on DMA physical API. ----------------------------------------------------------------------- The WIP branch can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=… Thanks Leon Romanovsky (7): PCI/P2PDMA: Separate the mmap() support from the core logic PCI/P2PDMA: Simplify bus address mapping API PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation PCI/P2PDMA: Export pci_p2pdma_map_type() function types: move phys_vec definition to common header vfio/pci: Enable peer-to-peer DMA transactions by default vfio/pci: Add dma-buf export support for MMIO regions Vivek Kasireddy (2): vfio: Export vfio device get and put registration helpers vfio/pci: Share the core device pointer while invoking feature functions block/blk-mq-dma.c | 7 +- drivers/iommu/dma-iommu.c | 4 +- drivers/pci/p2pdma.c | 175 ++++++++--- drivers/vfio/pci/Kconfig | 3 + drivers/vfio/pci/Makefile | 2 + drivers/vfio/pci/vfio_pci_config.c | 22 +- drivers/vfio/pci/vfio_pci_core.c | 63 ++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 446 +++++++++++++++++++++++++++++ drivers/vfio/pci/vfio_pci_priv.h | 23 ++ drivers/vfio/vfio_main.c | 2 + include/linux/pci-p2pdma.h | 120 +++++--- include/linux/types.h | 5 + include/linux/vfio.h | 2 + include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 25 ++ kernel/dma/direct.c | 4 +- mm/hmm.c | 2 +- 17 files changed, 785 insertions(+), 121 deletions(-) create mode 100644 drivers/vfio/pci/vfio_pci_dmabuf.c -- 2.51.0

1 month, 3 weeks

3
41
0 0

Re: [PATCH v2] Signed-off-by: Biancaa Ramesh <biancaa2210329@ssn.edu.in>

by Jani Nikula

On Wed, 22 Oct 2025, Biancaa Ramesh <biancaa2210329(a)ssn.edu.in> wrote: > -- > ::DISCLAIMER:: > > --------------------------------------------------------------------- > The > contents of this e-mail and any attachment(s) are confidential and > intended > for the named recipient(s) only. Views or opinions, if any, > presented in > this email are solely those of the author and may not > necessarily reflect > the views or opinions of SSN Institutions (SSN) or its > affiliates. Any form > of reproduction, dissemination, copying, disclosure, > modification, > distribution and / or publication of this message without the > prior written > consent of authorized representative of SSN is strictly > prohibited. If you > have received this email in error please delete it and > notify the sender > immediately. There are some obvious issues in the patch itself, but please do figure out how to send patches and generally list email without disclaimers like this first. Or use the b4 web submission endpoint [1]. BR, Jani. [1] https://b4.docs.kernel.org/en/latest/contributor/send.html -- Jani Nikula, Intel

1 month, 3 weeks

1
0
0 0

Re: [PATCH net-next v3 0/6] Add AF_XDP zero copy support

by Jakub Kicinski

On Tue, 14 Oct 2025 16:26:06 +0530 Meghana Malladi wrote: > This series adds AF_XDP zero coppy support to icssg driver. > > Tests were performed on AM64x-EVM with xdpsock application [1]. > > A clear improvement is seen Transmit (txonly) and receive (rxdrop) > for 64 byte packets. 1500 byte test seems to be limited by line > rate (1G link) so no improvement seen there in packet rate > > Having some issue with l2fwd as the benchmarking numbers show 0 > for 64 byte packets after forwading first batch packets and I am > currently looking into it. This series stopped applying, could you please respin? -- pw-bot: cr

1 month, 3 weeks

1
0
0 0

[PATCH v6 0/2] accel: Add Arm Ethos-U NPU

by Rob Herring (Arm)

The Arm Ethos-U65/85 NPUs are designed for edge AI inference applications[0]. The driver works with Mesa Teflon. The Ethos support was merged on 10/15. The UAPI should also be compatible with the downstream (open source) driver stack[2] and Vela compiler though that has not been implemented. Testing so far has been on i.MX93 boards with Ethos-U65 and a FVP model with Ethos-U85. More work is needed in mesa for handling U85 command stream differences, but that doesn't affect the UAPI. A git tree is here[3]. Rob [0] https://www.arm.com/products/silicon-ip-cpu?families=ethos%20npus [2] https://gitlab.arm.com/artificial-intelligence/ethos-u/ [3] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ethos-v6 Signed-off-by: Rob Herring (Arm) <robh(a)kernel.org> --- Changes in v6: - Rework job submit to avoid potential deadlocks with allocations/reclaim in the fence signaling paths. ethosu_acquire_object_fences() and the job done_fence allocation are moved earlier. The runtime-pm resume now before the job is pushed and autosuspend is done when the job is freed. - Drop unused ethosu_job_is_idle() - Link to v5: https://lore.kernel.org/r/20251016-ethos-v5-0-ba0aece0a006@kernel.org Changes in v5: - Rework Runtime PM init in probe - Use __free() cleanups where possible - Use devm_mutex_init() - Handle U85 NPU_SET_WEIGHT2_BASE and NPU_SET_WEIGHT2_LENGTH - Link to v4: https://lore.kernel.org/r/20251015-ethos-v4-0-81025a3dcbf3@kernel.org Changes in v4: - Use bulk clk API - Various whitespace fixes mostly due to ethos->ethosu rename - Drop error check on dma_set_mask_and_coherent() - Drop unnecessary pm_runtime_mark_last_busy() call - Move variable declarations out of switch (a riscv/clang build failure) - Use lowercase hex in all defines - Drop unused ethosu_device.coherent member - Add comments on all locks - Link to v3: https://lore.kernel.org/r/20250926-ethos-v3-0-6bd24373e4f5@kernel.org Changes in v3: - Rework and improve job submit validation - Rename ethos to ethosu. There was an Ethos-Nxx that's unrelated. - Add missing init for sched_lock mutex - Drop some prints to debug level - Fix i.MX93 SRAM accesses (AXI config) - Add U85 AXI configuration and test on FVP with U85 - Print the current cmd value on timeout - Link to v2: https://lore.kernel.org/r/20250811-ethos-v2-0-a219fc52a95b@kernel.org Changes in v2: - Rebase on v6.17-rc1 adapting to scheduler changes - scheduler: Drop the reset workqueue. According to the scheduler docs, we don't need it since we have a single h/w queue. - scheduler: Rework the timeout handling to continue running if we are making progress. Fixes timeouts on larger jobs. - Reset the NPU on resume so it's in a known state - Add error handling on clk_get() calls - Fix drm_mm splat on module unload. We were missing a put on the cmdstream BO in the scheduler clean-up. - Fix 0-day report needing explicit bitfield.h include - Link to v1: https://lore.kernel.org/r/20250722-ethos-v1-0-cc1c5a0cbbfb@kernel.org --- Rob Herring (Arm) (2): dt-bindings: npu: Add Arm Ethos-U65/U85 accel: Add Arm Ethos-U NPU driver .../devicetree/bindings/npu/arm,ethos.yaml | 79 +++ MAINTAINERS | 9 + drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 1 + drivers/accel/ethosu/Kconfig | 10 + drivers/accel/ethosu/Makefile | 4 + drivers/accel/ethosu/ethosu_device.h | 195 ++++++ drivers/accel/ethosu/ethosu_drv.c | 403 ++++++++++++ drivers/accel/ethosu/ethosu_drv.h | 15 + drivers/accel/ethosu/ethosu_gem.c | 704 +++++++++++++++++++++ drivers/accel/ethosu/ethosu_gem.h | 46 ++ drivers/accel/ethosu/ethosu_job.c | 496 +++++++++++++++ drivers/accel/ethosu/ethosu_job.h | 40 ++ include/uapi/drm/ethosu_accel.h | 261 ++++++++ 14 files changed, 2264 insertions(+) --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20250715-ethos-3fdd39ef6f19 Best regards, -- Rob Herring (Arm) <robh(a)kernel.org>

1 month, 3 weeks

1
2
0 0

Re: [RFC 1/8] dma-buf: Add support for map/unmap APIs for interconnects

by Thomas Hellström

Hi, Vivek, On Tue, 2025-10-14 at 00:08 -0700, Vivek Kasireddy wrote: > For the map operation, the dma-buf core will create an xarray but > the exporter is expected to populate it with the interconnect > specific addresses. And, similarly for unmap, the exporter is > expected to cleanup the individual entries of the xarray. > > Cc: Jason Gunthorpe <jgg(a)nvidia.com> > Cc: Christian Koenig <christian.koenig(a)amd.com> > Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > Cc: Simona Vetter <simona.vetter(a)ffwll.ch> > Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> > --- > drivers/dma-buf/dma-buf.c | 68 > ++++++++++++++++++++++++++++ > include/linux/dma-buf-interconnect.h | 29 ++++++++++++ > include/linux/dma-buf.h | 11 +++++ > 3 files changed, 108 insertions(+) > create mode 100644 include/linux/dma-buf-interconnect.h > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 2bcf9ceca997..162642bd53e8 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1612,6 +1612,74 @@ void dma_buf_vunmap_unlocked(struct dma_buf > *dmabuf, struct iosys_map *map) > } > EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, "DMA_BUF"); > > +struct dma_buf_ranges * > +dma_buf_map_interconnect(struct dma_buf_attachment *attach) Even if this is an RFC, please add kerneldoc so that the way the interface is intended to be used becomes completely clear. Both for functions and structs. > +{ > + const struct dma_buf_interconnect_ops *ic_ops; > + struct dma_buf *dmabuf = attach->dmabuf; > + struct dma_buf_ranges *ranges; > + int ret; > + > + might_sleep(); > + > + if (WARN_ON(!attach || !attach->dmabuf)) > + return ERR_PTR(-EINVAL); > + > + if (!dma_buf_attachment_is_dynamic(attach)) > + return ERR_PTR(-EINVAL); > + > + if (!attach->allow_ic) > + return ERR_PTR(-EOPNOTSUPP); > + > + dma_resv_assert_held(attach->dmabuf->resv); > + > + ic_ops = dmabuf->ops->interconnect_ops; > + if (!ic_ops || !ic_ops->map_interconnect) > + return ERR_PTR(-EINVAL); > + > + ranges = kzalloc(sizeof(*ranges), GFP_KERNEL); > + if (!ranges) > + return ERR_PTR(-ENOMEM); > + > + xa_init(&ranges->ranges); > + ret = ic_ops->map_interconnect(attach, ranges); > + if (ret) > + goto err_free_ranges; > + > + return ranges; > + > +err_free_ranges: > + xa_destroy(&ranges->ranges); > + kfree(ranges); > + return ERR_PTR(ret); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_map_interconnect, "DMA_BUF"); > + > +void dma_buf_unmap_interconnect(struct dma_buf_attachment *attach, > + struct dma_buf_ranges *ranges) > +{ > + const struct dma_buf_interconnect_ops *ic_ops; > + struct dma_buf *dmabuf = attach->dmabuf; > + > + if (WARN_ON(!attach || !attach->dmabuf || !ranges)) > + return; > + > + if (!attach->allow_ic) > + return; > + > + ic_ops = dmabuf->ops->interconnect_ops; > + if (!ic_ops || !ic_ops->unmap_interconnect) > + return; > + > + dma_resv_assert_held(attach->dmabuf->resv); > + > + ic_ops->unmap_interconnect(attach, ranges); > + > + xa_destroy(&ranges->ranges); > + kfree(ranges); > +} > +EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_interconnect, "DMA_BUF"); > + > #ifdef CONFIG_DEBUG_FS > static int dma_buf_debug_show(struct seq_file *s, void *unused) > { > diff --git a/include/linux/dma-buf-interconnect.h > b/include/linux/dma-buf-interconnect.h > new file mode 100644 > index 000000000000..17504dea9691 > --- /dev/null > +++ b/include/linux/dma-buf-interconnect.h > @@ -0,0 +1,29 @@ > +/* SPDX-License-Identifier: MIT */ > + > +#ifndef __DMA_BUF_INTERCONNECT_H__ > +#define __DMA_BUF_INTERCONNECT_H__ > + > +#include <linux/xarray.h> > + > +struct dma_buf_attachment; > + > +struct dma_buf_ranges { > + struct xarray ranges; > + unsigned int nranges; IIUC this would replace the sg-table right? I guess Jason or Christian would need to comment on whether this is generic enough or whether it needs to be interconnect-dependent. > +}; > + > +enum dma_buf_interconnect_type { > + DMA_BUF_INTERCONNECT_NONE = 0, > +}; This calls for registering all known interconnects with the dma-buf layer even if the interconnects are completely driver-private. I'd suggest using a pointer to identify interconnect and whatever entity defines the interconnect provides a unique pointer. For globally visible interconnects this could be done in dma-buf.c or a dma-buf- interconnect.c > + > +struct dma_buf_interconnect { > + enum dma_buf_interconnect_type type; > +}; > + > +struct dma_buf_interconnect_ops { > + int (*map_interconnect)(struct dma_buf_attachment *attach, > + struct dma_buf_ranges *ranges); > + void (*unmap_interconnect)(struct dma_buf_attachment > *attach, > + struct dma_buf_ranges *ranges); > +}; > +#endif > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index d58e329ac0e7..db91c67c00d6 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -23,6 +23,8 @@ > #include <linux/dma-fence.h> > #include <linux/wait.h> > > +#include <linux/dma-buf-interconnect.h> > + > struct device; > struct dma_buf; > struct dma_buf_attachment; > @@ -276,6 +278,8 @@ struct dma_buf_ops { > > int (*vmap)(struct dma_buf *dmabuf, struct iosys_map *map); > void (*vunmap)(struct dma_buf *dmabuf, struct iosys_map > *map); > + > + const struct dma_buf_interconnect_ops *interconnect_ops; > }; > > /** > @@ -502,7 +506,9 @@ struct dma_buf_attachment { > struct device *dev; > struct list_head node; > bool peer2peer; > + bool allow_ic; > const struct dma_buf_attach_ops *importer_ops; > + struct dma_buf_interconnect interconnect; Hmm. Could we have a pointer to the interconnect here? Let's say the interconnect implementation would want to subclass with additional information? > void *importer_priv; > void *priv; > }; > @@ -589,6 +595,11 @@ struct sg_table *dma_buf_map_attachment(struct > dma_buf_attachment *, > enum dma_data_direction); > void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct > sg_table *, > enum dma_data_direction); > + > +struct dma_buf_ranges *dma_buf_map_interconnect(struct > dma_buf_attachment *); > +void dma_buf_unmap_interconnect(struct dma_buf_attachment *, > + struct dma_buf_ranges *); > + > void dma_buf_move_notify(struct dma_buf *dma_buf); > int dma_buf_begin_cpu_access(struct dma_buf *dma_buf, > enum dma_data_direction dir); Thanks, Thomas

1 month, 3 weeks

1
0
0 0

[PATCH v8 0/5] dma-buf: heaps: Create a CMA heap for each CMA reserved region

by Maxime Ripard

Hi, Here's another attempt at supporting user-space allocations from a specific carved-out reserved memory region. The initial problem we were discussing was that I'm currently working on a platform which has a memory layout with ECC enabled. However, enabling the ECC has a number of drawbacks on that platform: lower performance, increased memory usage, etc. So for things like framebuffers, the trade-off isn't great and thus there's a memory region with ECC disabled to allocate from for such use cases. After a suggestion from John, I chose to first start using heap allocations flags to allow for userspace to ask for a particular ECC setup. This is then backed by a new heap type that runs from reserved memory chunks flagged as such, and the existing DT properties to specify the ECC properties. After further discussion, it was considered that flags were not the right solution, and relying on the names of the heaps would be enough to let userspace know the kind of buffer it deals with. Thus, even though the uAPI part of it had been dropped in this second version, we still needed a driver to create heaps out of carved-out memory regions. In addition to the original usecase, a similar driver can be found in BSPs from most vendors, so I believe it would be a useful addition to the kernel. Some extra discussion with Rob Herring [1] came to the conclusion that some specific compatible for this is not great either, and as such an new driver probably isn't called for either. Some other discussions we had with John [2] also dropped some hints that multiple CMA heaps might be a good idea, and some vendors seem to do that too. So here's another attempt that doesn't affect the device tree at all and will just create a heap for every CMA reserved memory region. It also falls nicely into the current plan we have to support cgroups in DRM/KMS and v4l2, which is an additional benefit. Let me know what you think, Maxime 1: https://lore.kernel.org/all/20250707-cobalt-dingo-of-serenity-dbf92c@houat/ 2: https://lore.kernel.org/all/CANDhNCroe6ZBtN_o=c71kzFFaWK-fF5rCdnr9P5h1sgPOW… Let me know what you think, Maxime Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v8: - Rebased on top of 6.18-rc1 - Added TJ R-b - Link to v7: https://lore.kernel.org/r/20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kerne… Changes in v7: - Invert the logic and register CMA heap from the reserved memory / dma contiguous code, instead of iterating over them from the CMA heap. - Link to v6: https://lore.kernel.org/r/20250709-dma-buf-ecc-heap-v6-0-dac9bf80f35d@kerne… Changes in v6: - Drop the new driver and allocate a CMA heap for each region now - Dropped the binding - Rebased on 6.16-rc5 - Link to v5: https://lore.kernel.org/r/20250617-dma-buf-ecc-heap-v5-0-0abdc5863a4f@kerne… Changes in v5: - Rebased on 6.16-rc2 - Switch from property to dedicated binding - Link to v4: https://lore.kernel.org/r/20250520-dma-buf-ecc-heap-v4-1-bd2e1f1bb42c@kerne… Changes in v4: - Rebased on 6.15-rc7 - Map buffers only when map is actually called, not at allocation time - Deal with restricted-dma-pool and shared-dma-pool - Reword Kconfig options - Properly report dma_map_sgtable failures - Link to v3: https://lore.kernel.org/r/20250407-dma-buf-ecc-heap-v3-0-97cdd36a5f29@kerne… Changes in v3: - Reworked global variable patch - Link to v2: https://lore.kernel.org/r/20250401-dma-buf-ecc-heap-v2-0-043fd006a1af@kerne… Changes in v2: - Add vmap/vunmap operations - Drop ECC flags uapi - Rebase on top of 6.14 - Link to v1: https://lore.kernel.org/r/20240515-dma-buf-ecc-heap-v1-0-54cbbd049511@kerne… --- Maxime Ripard (5): doc: dma-buf: List the heaps by name dma-buf: heaps: cma: Register list of CMA regions at boot dma: contiguous: Register reusable CMA regions at boot dma: contiguous: Reserve default CMA heap dma-buf: heaps: cma: Create CMA heap for each CMA reserved region Documentation/userspace-api/dma-buf-heaps.rst | 24 ++++++++------ MAINTAINERS | 1 + drivers/dma-buf/heaps/Kconfig | 10 ------ drivers/dma-buf/heaps/cma_heap.c | 47 +++++++++++++++++---------- include/linux/dma-buf/heaps/cma.h | 16 +++++++++ kernel/dma/contiguous.c | 11 +++++++ 6 files changed, 72 insertions(+), 37 deletions(-) --- base-commit: 47633099a672fc7bfe604ef454e4f116e2c954b1 change-id: 20240515-dma-buf-ecc-heap-28a311d2c94e prerequisite-message-id: <20250610131231.1724627-1-jkangas(a)redhat.com> prerequisite-patch-id: bc44be5968feb187f2bc1b8074af7209462b18e7 prerequisite-patch-id: f02a91b723e5ec01fbfedf3c3905218b43d432da prerequisite-patch-id: e944d0a3e22f2cdf4d3b3906e5603af934696deb Best regards, -- Maxime Ripard <mripard(a)kernel.org>

1 month, 4 weeks

3
9
0 0

Re: [PATCH v5 2/2] accel: Add Arm Ethos-U NPU driver

by Rob Herring

On Thu, Oct 16, 2025 at 11:25:34PM -0700, Matthew Brost wrote: > On Thu, Oct 16, 2025 at 04:06:05PM -0500, Rob Herring (Arm) wrote: > > Add a driver for Arm Ethos-U65/U85 NPUs. The Ethos-U NPU has a > > relatively simple interface with single command stream to describe > > buffers, operation settings, and network operations. It supports up to 8 > > memory regions (though no h/w bounds on a region). The Ethos NPUs > > are designed to use an SRAM for scratch memory. Region 2 is reserved > > for SRAM (like the downstream driver stack and compiler). Userspace > > doesn't need access to the SRAM. Thanks for the review. [...] > > +static struct dma_fence *ethosu_job_run(struct drm_sched_job *sched_job) > > +{ > > + struct ethosu_job *job = to_ethosu_job(sched_job); > > + struct ethosu_device *dev = job->dev; > > + struct dma_fence *fence = NULL; > > + int ret; > > + > > + if (unlikely(job->base.s_fence->finished.error)) > > + return NULL; > > + > > + fence = ethosu_fence_create(dev); > > Another reclaim issue: ethosu_fence_create allocates memory using > GFP_KERNEL. Since we're already in the DMA fence signaling path > (reclaim), this can lead to a deadlock. > > Without too much thought, you likely want to move this allocation to > ethosu_job_do_push, but before taking dev->sched_lock or calling > drm_sched_job_arm. > > We really should fix the DRM scheduler work queue to be tainted with > reclaim. If I recall correctly, we'd need to update the work queue > layer. Let me look into that—I've seen this type of bug several times, > and lockdep should be able to catch it. Likely the rocket driver suffers from the same issues... > > > + if (IS_ERR(fence)) > > + return fence; > > + > > + if (job->done_fence) > > + dma_fence_put(job->done_fence); > > + job->done_fence = dma_fence_get(fence); > > + > > + ret = pm_runtime_get_sync(dev->base.dev); > > I haven't looked at your PM design, but this generally looks quite > dangerous with respect to reclaim. For example, if your PM resume paths > allocate memory or take locks that allocate memory underneath, you're > likely to run into issues. > > A better approach would be to attach a PM reference to your job upon > creation and release it upon job destruction. That would be safer and > save you headaches in the long run. Our PM is nothing more than clock enable/disable and register init. If the runtime PM API doesn't work and needs special driver wrappers, then I'm inclined to just not use it and manage clocks directly (as that's all it is doing). > > This is what we do in Xe [1] [2]. > > Also, in general, this driver has been reviewed (RB’d), but it's not > great that I spotted numerous issues within just five minutes. I suggest > taking a step back and thoroughly evaluating everything this driver is > doing. Well, if it is hard to get simple drivers right, then it's a problem with the subsystem APIs IMO. Rob

1 month, 4 weeks

1
0
0 0

[PATCH v4 4/9] rust: drm: gem: Add raw_dma_resv() function

by Lyude Paul

For retrieving a pointer to the struct dma_resv for a given GEM object. We also introduce it in a new trait, BaseObjectPrivate, which we automatically implement for all gem objects and don't expose to users outside of the crate. Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- rust/kernel/drm/gem/mod.rs | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs index 981fbb931e952..760fcd61da0b7 100644 --- a/rust/kernel/drm/gem/mod.rs +++ b/rust/kernel/drm/gem/mod.rs @@ -199,6 +199,18 @@ fn create_mmap_offset(&self) -> Result<u64> { impl<T: IntoGEMObject> BaseObject for T {} +/// Crate-private base operations shared by all GEM object classes. +#[expect(unused)] +pub(crate) trait BaseObjectPrivate: IntoGEMObject { + /// Return a pointer to this object's dma_resv. + fn raw_dma_resv(&self) -> *mut bindings::dma_resv { + // SAFETY: `as_gem_obj()` always returns a valid pointer to the base DRM gem object + unsafe { (*self.as_raw()).resv } + } +} + +impl<T: IntoGEMObject> BaseObjectPrivate for T {} + /// A base GEM object. /// /// Invariants -- 2.51.0

2 months

1
0
0 0

[PATCH v4 3/9] rust: helpers: Add bindings/wrappers for dma_resv_lock

by Lyude Paul

From: Asahi Lina <lina(a)asahilina.net> This is just for basic usage in the DRM shmem abstractions for implied locking, not intended as a full DMA Reservation abstraction yet. Signed-off-by: Asahi Lina <lina(a)asahilina.net> Signed-off-by: Daniel Almeida <daniel.almeida(a)collabora.com> Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- rust/bindings/bindings_helper.h | 1 + rust/helpers/dma-resv.c | 13 +++++++++++++ rust/helpers/helpers.c | 1 + 3 files changed, 15 insertions(+) create mode 100644 rust/helpers/dma-resv.c diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h index 2e43c66635a2c..07f79e125c329 100644 --- a/rust/bindings/bindings_helper.h +++ b/rust/bindings/bindings_helper.h @@ -48,6 +48,7 @@ #include <linux/cpumask.h> #include <linux/cred.h> #include <linux/debugfs.h> +#include <linux/dma-resv.h> #include <linux/device/faux.h> #include <linux/dma-direction.h> #include <linux/dma-mapping.h> diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c new file mode 100644 index 0000000000000..05501cb814513 --- /dev/null +++ b/rust/helpers/dma-resv.c @@ -0,0 +1,13 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/dma-resv.h> + +int rust_helper_dma_resv_lock(struct dma_resv *obj, struct ww_acquire_ctx *ctx) +{ + return dma_resv_lock(obj, ctx); +} + +void rust_helper_dma_resv_unlock(struct dma_resv *obj) +{ + dma_resv_unlock(obj); +} diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c index 551da6c9b5064..36d40f911345c 100644 --- a/rust/helpers/helpers.c +++ b/rust/helpers/helpers.c @@ -25,6 +25,7 @@ #include "cred.c" #include "device.c" #include "dma.c" +#include "dma-resv.c" #include "drm.c" #include "err.c" #include "irq.c" -- 2.51.0

2 months

1
0
0 0

[PATCH v5 0/2] accel: Add Arm Ethos-U NPU

by Rob Herring (Arm)

The Arm Ethos-U65/85 NPUs are designed for edge AI inference applications[0]. The driver works with Mesa Teflon. The Ethos support was merged on 10/15. The UAPI should also be compatible with the downstream (open source) driver stack[2] and Vela compiler though that has not been implemented. Testing so far has been on i.MX93 boards with Ethos-U65 and a FVP model with Ethos-U85. More work is needed in mesa for handling U85 command stream differences, but that doesn't affect the UAPI. A git tree is here[3]. Rob [0] https://www.arm.com/products/silicon-ip-cpu?families=ethos%20npus [2] https://gitlab.arm.com/artificial-intelligence/ethos-u/ [3] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ethos-v5 Signed-off-by: Rob Herring (Arm) <robh(a)kernel.org> --- Changes in v5: - Rework Runtime PM init in probe - Use __free() cleanups where possible - Use devm_mutex_init() - Handle U85 NPU_SET_WEIGHT2_BASE and NPU_SET_WEIGHT2_LENGTH - Link to v4: https://lore.kernel.org/r/20251015-ethos-v4-0-81025a3dcbf3@kernel.org Changes in v4: - Use bulk clk API - Various whitespace fixes mostly due to ethos->ethosu rename - Drop error check on dma_set_mask_and_coherent() - Drop unnecessary pm_runtime_mark_last_busy() call - Move variable declarations out of switch (a riscv/clang build failure) - Use lowercase hex in all defines - Drop unused ethosu_device.coherent member - Add comments on all locks - Link to v3: https://lore.kernel.org/r/20250926-ethos-v3-0-6bd24373e4f5@kernel.org Changes in v3: - Rework and improve job submit validation - Rename ethos to ethosu. There was an Ethos-Nxx that's unrelated. - Add missing init for sched_lock mutex - Drop some prints to debug level - Fix i.MX93 SRAM accesses (AXI config) - Add U85 AXI configuration and test on FVP with U85 - Print the current cmd value on timeout - Link to v2: https://lore.kernel.org/r/20250811-ethos-v2-0-a219fc52a95b@kernel.org Changes in v2: - Rebase on v6.17-rc1 adapting to scheduler changes - scheduler: Drop the reset workqueue. According to the scheduler docs, we don't need it since we have a single h/w queue. - scheduler: Rework the timeout handling to continue running if we are making progress. Fixes timeouts on larger jobs. - Reset the NPU on resume so it's in a known state - Add error handling on clk_get() calls - Fix drm_mm splat on module unload. We were missing a put on the cmdstream BO in the scheduler clean-up. - Fix 0-day report needing explicit bitfield.h include - Link to v1: https://lore.kernel.org/r/20250722-ethos-v1-0-cc1c5a0cbbfb@kernel.org --- Rob Herring (Arm) (2): dt-bindings: npu: Add Arm Ethos-U65/U85 accel: Add Arm Ethos-U NPU driver .../devicetree/bindings/npu/arm,ethos.yaml | 79 +++ MAINTAINERS | 9 + drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 1 + drivers/accel/ethosu/Kconfig | 10 + drivers/accel/ethosu/Makefile | 4 + drivers/accel/ethosu/ethosu_device.h | 195 ++++++ drivers/accel/ethosu/ethosu_drv.c | 403 ++++++++++++ drivers/accel/ethosu/ethosu_drv.h | 15 + drivers/accel/ethosu/ethosu_gem.c | 704 +++++++++++++++++++++ drivers/accel/ethosu/ethosu_gem.h | 46 ++ drivers/accel/ethosu/ethosu_job.c | 540 ++++++++++++++++ drivers/accel/ethosu/ethosu_job.h | 41 ++ include/uapi/drm/ethosu_accel.h | 261 ++++++++ 14 files changed, 2309 insertions(+) --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20250715-ethos-3fdd39ef6f19 Best regards, -- Rob Herring (Arm) <robh(a)kernel.org>

2 months

1
2
0 0

Re: [PATCH v8 0/2] i2c: i2c-qcom-geni: Add Block event interrupt support

by Vinod Koul

On Thu, 25 Sep 2025 17:30:33 +0530, Jyothi Kumar Seerapu wrote: > The I2C driver gets an interrupt upon transfer completion. > When handling multiple messages in a single transfer, this > results in N interrupts for N messages, leading to significant > software interrupt latency. > > To mitigate this latency, utilize Block Event Interrupt (BEI) > mechanism. Enabling BEI instructs the hardware to prevent interrupt > generation and BEI is disabled when an interrupt is necessary. > > [...] Applied, thanks! [1/2] dmaengine: qcom: gpi: Add GPI Block event interrupt support commit: 4e8331317e73902e8b2663352c8766227e633901 [2/2] i2c: i2c-qcom-geni: Add Block event interrupt support commit: 398035178503bf662281bbffb4bebce1460a4bc5 Best regards, -- ~Vinod

2 months

1
0
0 0

Re: [PATCH v4 2/2] accel: Add Arm Ethos-U NPU driver

by Rob Herring

On Wed, Oct 15, 2025 at 4:02 PM Frank Li <Frank.li(a)nxp.com> wrote: > > On Wed, Oct 15, 2025 at 03:36:05PM -0500, Rob Herring wrote: > > On Wed, Oct 15, 2025 at 2:39 PM Frank Li <Frank.li(a)nxp.com> wrote: > > > > > > On Wed, Oct 15, 2025 at 12:47:40PM -0500, Rob Herring (Arm) wrote: > > > > Add a driver for Arm Ethos-U65/U85 NPUs. The Ethos-U NPU has a > > > > relatively simple interface with single command stream to describe > > > > buffers, operation settings, and network operations. It supports up to 8 > > > > memory regions (though no h/w bounds on a region). The Ethos NPUs > > > > are designed to use an SRAM for scratch memory. Region 2 is reserved > > > > for SRAM (like the downstream driver stack and compiler). Userspace > > > > doesn't need access to the SRAM. > > > > +static int ethosu_init(struct ethosu_device *ethosudev) > > > > +{ > > > > + int ret; > > > > + u32 id, config; > > > > + > > > > + ret = devm_pm_runtime_enable(ethosudev->base.dev); > > > > + if (ret) > > > > + return ret; > > > > + > > > > + ret = pm_runtime_resume_and_get(ethosudev->base.dev); > > > > + if (ret) > > > > + return ret; > > > > + > > > > + pm_runtime_set_autosuspend_delay(ethosudev->base.dev, 50); > > > > + pm_runtime_use_autosuspend(ethosudev->base.dev); > > > > + > > > > + /* If PM is disabled, we need to call ethosu_device_resume() manually. */ > > > > + if (!IS_ENABLED(CONFIG_PM)) { > > > > + ret = ethosu_device_resume(ethosudev->base.dev); > > > > + if (ret) > > > > + return ret; > > > > + } > > > > > > I think it should call ethosu_device_resume() unconditional before > > > devm_pm_runtime_enable(); > > > > > > ethosu_device_resume(); > > > pm_runtime_set_active(); > > > pm_runtime_set_autosuspend_delay(ethosudev->base.dev, 50); > > > devm_pm_runtime_enable(); > > > > Why do you think this? Does this do a get? > > > > I don't think it is good to call the resume hook on our own, but we > > have no choice with !CONFIG_PM. With CONFIG_PM, we should only use the > > pm_runtime API. > > Enable clock and do some init work at probe() is quite common. But I never > seen IS_ENABLED(CONFIG_PM) check. It is quite weird and not necessary to > check CONFIG_PM flags. The most CONFIG_PM is enabled, so the branch !CONFIG_PM > almost never tested. Okay, I get what you meant. > > probe() > { > devm_clk_bulk_get_all_enabled(); > > ... did some init work > > pm_runtime_set_active(); > devm_pm_runtime_enable(); > > ... > pm_runtime_put_autosuspend(ethosudev->base.dev); > } I think we still need a pm_runtime_get_noresume() in here since we do a put later on. Here's what I have now: ret = ethosu_device_resume(ethosudev->base.dev); if (ret) return ret; pm_runtime_set_autosuspend_delay(ethosudev->base.dev, 50); pm_runtime_use_autosuspend(ethosudev->base.dev); ret = devm_pm_runtime_set_active_enabled(ethosudev->base.dev); if (ret) return ret; pm_runtime_get_noresume(ethosudev->base.dev); Rob

2 months

1
0
0 0

Re: [PATCH v8 2/2] i2c: i2c-qcom-geni: Add Block event interrupt support

by Vinod Koul

On 03-10-25, 20:50, Andi Shyti wrote: > On Thu, Sep 25, 2025 at 05:30:35PM +0530, Jyothi Kumar Seerapu wrote: > > From: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > > > > The I2C driver gets an interrupt upon transfer completion. > > When handling multiple messages in a single transfer, this > > results in N interrupts for N messages, leading to significant > > software interrupt latency. > > > > To mitigate this latency, utilize Block Event Interrupt (BEI) > > mechanism. Enabling BEI instructs the hardware to prevent interrupt > > generation and BEI is disabled when an interrupt is necessary. > > > > Large I2C transfer can be divided into chunks of messages internally. > > Interrupts are not expected for the messages for which BEI bit set, > > only the last message triggers an interrupt, indicating the completion of > > N messages. This BEI mechanism enhances overall transfer efficiency. > > > > BEI optimizations are currently implemented for I2C write transfers only, > > as there is no use case for multiple I2C read messages in a single transfer > > at this time. > > > > Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > > Because this series is touching multiple subsystems, I'm going to > ack it: > > Acked-by: Andi Shyti <andi.shyti(a)kernel.org> > > We are waiting for someone from DMA to ack it (Vinod or Sinan). Thanks, I will pick it with your ack -- ~Vinod

2 months

1
0
0 0

Re: [PATCH v2] htmldocs: userspace-api/dma-buf-heaps.rst: fix block quote warning

by Bagas Sanjaya

On Thu, Oct 16, 2025 at 02:09:12AM +0000, Kriish Sharma wrote: > diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst > index a0979440d2a4..c0035dc257e0 100644 > --- a/Documentation/userspace-api/dma-buf-heaps.rst > +++ b/Documentation/userspace-api/dma-buf-heaps.rst > @@ -26,6 +26,7 @@ following heaps: > ``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option is set, a duplicate node is > created following legacy naming conventions; the legacy name might be > ``reserved``, ``linux,cma``, or ``default-pool``. > + > Naming Convention > ================= > LGTM, thanks! Reviewed-by: Bagas Sanjaya <bagasdotme(a)gmail.com> -- An old man doll... just what I always wanted! - Clara

2 months

1
0
0 0

Re: [PATCH v5 8/9] vfio/pci: Enable peer-to-peer DMA transactions by default

by Leon Romanovsky

On Wed, Oct 15, 2025 at 09:09:53PM -0700, Nicolin Chen wrote: > Hi Leon, > > On Mon, Oct 13, 2025 at 06:26:10PM +0300, Leon Romanovsky wrote: > > @@ -2090,6 +2092,9 @@ int vfio_pci_core_init_dev(struct vfio_device *core_vdev) > > INIT_LIST_HEAD(&vdev->dummy_resources_list); > > INIT_LIST_HEAD(&vdev->ioeventfds_list); > > INIT_LIST_HEAD(&vdev->sriov_pfs_item); > > + ret = pcim_p2pdma_init(vdev->pdev); > > + if (ret != -EOPNOTSUPP) > > + return ret; > > init_rwsem(&vdev->memory_lock); > > xa_init(&vdev->ctx); > > I think this should be: > if (ret && ret != -EOPNOTSUPP) > return ret; > > Otherwise, init_rwsem() and xa_init() would be missed if ret==0. You absolutely right. Thanks > > Thanks > Nicolin >

2 months

1
0
0 0

Re: [PATCH] htmldocs: userspace-api/dma-buf-heaps.rst: fix block quote warning

by Bagas Sanjaya

On Wed, Oct 15, 2025 at 06:34:02PM +0000, Kriish Sharma wrote: > Fixes: 1fdbb3ff1233 ("Add linux-next specific files for 20251015") The correct blamed fixes should've been: Fixes: 507211e3c7a1 ("Documentation: dma-buf: heaps: Add naming guidelines") Thanks. -- An old man doll... just what I always wanted! - Clara

2 months

1
0
0 0

Re: [PATCH] htmldocs: userspace-api/dma-buf-heaps.rst: fix block quote warning

by Randy Dunlap

On 10/15/25 11:34 AM, Kriish Sharma wrote: > Fix the following warning encountered when running `make htmldocs`: > > Documentation/userspace-api/dma-buf-heaps.rst:29: WARNING: Block quote ends without a blank line; unexpected unindent > > Added a blank line before the "Naming Convention" heading to comply with reST > > Fixes: 1fdbb3ff1233 ("Add linux-next specific files for 20251015") > Signed-off-by: Kriish Sharma <kriish.sharma2006(a)gmail.com> Reviewed-by: Randy Dunlap <rdunlap(a)infradead.org> Tested-by: Randy Dunlap <rdunlap(a)infradead.org> Thanks. > --- > Documentation/userspace-api/dma-buf-heaps.rst | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst > index a0979440d2a4..c0035dc257e0 100644 > --- a/Documentation/userspace-api/dma-buf-heaps.rst > +++ b/Documentation/userspace-api/dma-buf-heaps.rst > @@ -26,6 +26,7 @@ following heaps: > ``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option is set, a duplicate node is > created following legacy naming conventions; the legacy name might be > ``reserved``, ``linux,cma``, or ``default-pool``. > + > Naming Convention > ================= > -- ~Randy

2 months

1
0
0 0

Re: [PATCH v4 2/2] accel: Add Arm Ethos-U NPU driver

by Rob Herring

On Wed, Oct 15, 2025 at 2:39 PM Frank Li <Frank.li(a)nxp.com> wrote: > > On Wed, Oct 15, 2025 at 12:47:40PM -0500, Rob Herring (Arm) wrote: > > Add a driver for Arm Ethos-U65/U85 NPUs. The Ethos-U NPU has a > > relatively simple interface with single command stream to describe > > buffers, operation settings, and network operations. It supports up to 8 > > memory regions (though no h/w bounds on a region). The Ethos NPUs > > are designed to use an SRAM for scratch memory. Region 2 is reserved > > for SRAM (like the downstream driver stack and compiler). Userspace > > doesn't need access to the SRAM. > > > > The h/w has no MMU nor external IOMMU and is a DMA engine which can > > read and write anywhere in memory without h/w bounds checks. The user > > submitted command streams must be validated against the bounds of the > > GEM BOs. This is similar to the VC4 design which validates shaders. > > > > The job submit is based on the rocket driver for the Rockchip NPU > > utilizing the GPU scheduler. It is simpler as there's only 1 core rather > > than 3. > > > > Tested on i.MX93 platform (U65) and FVP (U85) with WIP Mesa Teflon > > support. > > > > Acked-by: Thomas Zimmermann <tzimmermann(a)suse.de> > > Signed-off-by: Rob Herring (Arm) <robh(a)kernel.org> > > --- > > How to test this driver? You need to add the DT node to i.MX93 .dts like the example, build the mesa ethosu branch, and then run tflite with it pointed to the mesa delegate. I can send an i.MX93 dts patch after this is merged. > > v4: > > - Use bulk clk API > > - Various whitespace fixes mostly due to ethos->ethosu rename > > - Drop error check on dma_set_mask_and_coherent() > > - Drop unnecessary pm_runtime_mark_last_busy() call > > - Move variable declarations out of switch (a riscv/clang build failure) > > - Use lowercase hex in all defines > > - Drop unused ethosu_device.coherent member > > - Add comments on all locks > > > ... > > diff --git a/drivers/accel/ethosu/ethosu_device.h b/drivers/accel/ethosu/ethosu_device.h > > new file mode 100644 > > index 000000000000..69d610c5c2d7 > > --- /dev/null > > +++ b/drivers/accel/ethosu/ethosu_device.h > > @@ -0,0 +1,190 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only or MIT */ > > +/* Copyright 2025 Arm, Ltd. */ > > + > > +#ifndef __ETHOSU_DEVICE_H__ > > +#define __ETHOSU_DEVICE_H__ > > + > > +#include <linux/types.h> > > + > > +#include <drm/drm_device.h> > > +#include <drm/gpu_scheduler.h> > > + > > +#include <drm/ethosu_accel.h> > > + > > +struct clk; > > +struct gen_pool; > > Supposed should include clk.h instead declear a struct. Headers should only use a forward declaration if that's all they need. It keeps the struct opaque for starters. > ... > > + > > +static int ethosu_open(struct drm_device *ddev, struct drm_file *file) > > +{ > > + int ret = 0; > > + struct ethosu_file_priv *priv; > > + > > + if (!try_module_get(THIS_MODULE)) > > + return -EINVAL; > > + > > + priv = kzalloc(sizeof(*priv), GFP_KERNEL); > > + if (!priv) { > > + ret = -ENOMEM; > > + goto err_put_mod; > > + } > > + priv->edev = to_ethosu_device(ddev); > > + > > + ret = ethosu_job_open(priv); > > + if (ret) > > + goto err_free; > > + > > + file->driver_priv = priv; > > slice simple. > > struct ethosu_file_priv __free(kfree) *priv = NULL; > ... > priv = kzalloc(sizeof(*priv), GFP_KERNEL); Linus has voiced his opinion that the above should not be done. It should be all one line *only*. But now we allow C99 declarations, so we can move it down. We can't get rid of the goto for module_put(), so it only marginally helps here. > ... > > file->driver_priv = no_free_ptr(priv); > > > > + return 0; > > + > > +err_free: > > + kfree(priv); > > +err_put_mod: > > + module_put(THIS_MODULE); > > + return ret; > > +} > > + > ... > > + > > + > > +static int ethosu_init(struct ethosu_device *ethosudev) > > +{ > > + int ret; > > + u32 id, config; > > + > > + ret = devm_pm_runtime_enable(ethosudev->base.dev); > > + if (ret) > > + return ret; > > + > > + ret = pm_runtime_resume_and_get(ethosudev->base.dev); > > + if (ret) > > + return ret; > > + > > + pm_runtime_set_autosuspend_delay(ethosudev->base.dev, 50); > > + pm_runtime_use_autosuspend(ethosudev->base.dev); > > + > > + /* If PM is disabled, we need to call ethosu_device_resume() manually. */ > > + if (!IS_ENABLED(CONFIG_PM)) { > > + ret = ethosu_device_resume(ethosudev->base.dev); > > + if (ret) > > + return ret; > > + } > > I think it should call ethosu_device_resume() unconditional before > devm_pm_runtime_enable(); > > ethosu_device_resume(); > pm_runtime_set_active(); > pm_runtime_set_autosuspend_delay(ethosudev->base.dev, 50); > devm_pm_runtime_enable(); Why do you think this? Does this do a get? I don't think it is good to call the resume hook on our own, but we have no choice with !CONFIG_PM. With CONFIG_PM, we should only use the pm_runtime API. Rob

2 months

1
0
0 0

[PATCH v4 0/2] accel: Add Arm Ethos-U NPU

by Rob Herring (Arm)

The Arm Ethos-U65/85 NPUs are designed for edge AI inference applications[0]. The driver works with Mesa Teflon. A merge request for Ethos support is here[1]. The UAPI should also be compatible with the downstream (open source) driver stack[2] and Vela compiler though that has not been implemented. Testing so far has been on i.MX93 boards with Ethos-U65 and a FVP model with Ethos-U85. More work is needed in mesa for handling U85 command stream differences, but that doesn't affect the UABI. A git tree is here[3]. Rob [0] https://www.arm.com/products/silicon-ip-cpu?families=ethos%20npus [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36699/ [2] https://gitlab.arm.com/artificial-intelligence/ethos-u/ [3] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ethos-v4 Signed-off-by: Rob Herring (Arm) <robh(a)kernel.org> --- Changes in v4: - Use bulk clk API - Various whitespace fixes mostly due to ethos->ethosu rename - Drop error check on dma_set_mask_and_coherent() - Drop unnecessary pm_runtime_mark_last_busy() call - Move variable declarations out of switch (a riscv/clang build failure) - Use lowercase hex in all defines - Drop unused ethosu_device.coherent member - Add comments on all locks - Link to v3: https://lore.kernel.org/r/20250926-ethos-v3-0-6bd24373e4f5@kernel.org Changes in v3: - Rework and improve job submit validation - Rename ethos to ethosu. There was an Ethos-Nxx that's unrelated. - Add missing init for sched_lock mutex - Drop some prints to debug level - Fix i.MX93 SRAM accesses (AXI config) - Add U85 AXI configuration and test on FVP with U85 - Print the current cmd value on timeout - Link to v2: https://lore.kernel.org/r/20250811-ethos-v2-0-a219fc52a95b@kernel.org Changes in v2: - Rebase on v6.17-rc1 adapting to scheduler changes - scheduler: Drop the reset workqueue. According to the scheduler docs, we don't need it since we have a single h/w queue. - scheduler: Rework the timeout handling to continue running if we are making progress. Fixes timeouts on larger jobs. - Reset the NPU on resume so it's in a known state - Add error handling on clk_get() calls - Fix drm_mm splat on module unload. We were missing a put on the cmdstream BO in the scheduler clean-up. - Fix 0-day report needing explicit bitfield.h include - Link to v1: https://lore.kernel.org/r/20250722-ethos-v1-0-cc1c5a0cbbfb@kernel.org --- Rob Herring (Arm) (2): dt-bindings: npu: Add Arm Ethos-U65/U85 accel: Add Arm Ethos-U NPU driver .../devicetree/bindings/npu/arm,ethos.yaml | 79 +++ MAINTAINERS | 9 + drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 1 + drivers/accel/ethosu/Kconfig | 10 + drivers/accel/ethosu/Makefile | 4 + drivers/accel/ethosu/ethosu_device.h | 190 ++++++ drivers/accel/ethosu/ethosu_drv.c | 418 ++++++++++++ drivers/accel/ethosu/ethosu_drv.h | 15 + drivers/accel/ethosu/ethosu_gem.c | 710 +++++++++++++++++++++ drivers/accel/ethosu/ethosu_gem.h | 46 ++ drivers/accel/ethosu/ethosu_job.c | 539 ++++++++++++++++ drivers/accel/ethosu/ethosu_job.h | 41 ++ include/uapi/drm/ethosu_accel.h | 261 ++++++++ 14 files changed, 2324 insertions(+) --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20250715-ethos-3fdd39ef6f19 Best regards, -- Rob Herring (Arm) <robh(a)kernel.org>

2 months

1
2
0 0

Re: [PATCH 1/2] mm: call back alloc_pages_bulk_list since it is useful

by David Hildenbrand

On 14.10.25 10:32, zhaoyang.huang wrote: > From: Zhaoyang Huang <zhaoyang.huang(a)unisoc.com> Probably the subject should be "mm: reintroduce alloc_pages_bulk_list()" > > commit c8b979530f27 ("mm: alloc_pages_bulk_noprof: drop page_list > argument") drops alloc_pages_bulk_list. This commit would like to call back > it since it is proved to be helpful to the drivers which allocate a bulk of > pages(see patch of 2 in this series ). "Let's reintroduce it so we can us for bulk allocation in the context of XXX next." > I do notice that Matthew's comment of the time cost of iterating a list. > However, I also observed in our test that the extra page_array's allocation > could be more expensive than cpu iteration when direct reclaiming happens > when ram is low[1]. IMHO, could we leave the API here to have the users > choose between the array or list according to their scenarios. I'd prefer if we avoid reintroducing this interface. How many pages are you intending to allocate? Wouldn't a smaller array on the stack be sufficient? -- Cheers David / dhildenb

2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig