Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

59 participants
6157 discussions

Re: [PATCH] dma-buf: heaps: Add Coherent heap to dmabuf heaps

by Robin Murphy

On 24/02/2026 7:57 am, Albert Esteve wrote: > Add a dma-buf heap for DT coherent reserved-memory > (i.e., 'shared-dma-pool' without 'reusable' property), > exposing one heap per region for userspace buffers. Despite the "shared" naming of the compatible, these kinds of reservations are often for highly device-specific purposes, and sometimes may not even be accessible to other devices at all, so it's far from clear that there's a generic use-case for connecting them to dma-buf. Certainly it doesn't seem like a good idea to unconditionally create heaps for *everyting*, and give userspace free reign to mess with things it doesn't necessarily understand (especially where usage-specific restrictions implied by "no-map" are involved) and which may break drivers. Most drivers that accomodate a memory-region expect to manage it themselves, so I would think it should be up to the drivers to opt into delegating "their" pool to userspace by registering it as a heap. Or at very worst, at least some additional DT compatible or property to indicate that it really is safe and desirable to use a given pool in a truly shared manner. Otherwise, If we just present some heaps named "memory@xyz" to userspace (arch/arm64/boot/dts/ti/k3-j784s4-j742s2-ti-ipc-firmware-common.dtsi is a fun example), do we really expect it to maintain exhaustive platform-specific knowledge of which actual device(s) they belong to and what they're for? And if it does try to just mess around and allocate and map stuff, how does the dma-buf layer also have all of that usage-specific detail to know what memory attributes are safe to map with etc.? Thanks, Robin. > The heap binds a synthetic platform device to each region > so coherent allocations use the correct dev->dma_mem, > and it defers registration until late_initcall when > normal allocator are available. > > This patch includes charging of the coherent heap > allocator to the dmem cgroup. > > Signed-off-by: Albert Esteve <aesteve(a)redhat.com> > --- > This patch introduces a new driver to expose DT coherent reserved-memory > regions as dma-buf heaps, allowing userspace buffers to be created. > > Since these regions are device-dependent, we bind a synthetic platform > device to each region so coherent allocations use the correct dev->dma_mem. > > Following Eric’s [1] and Maxime’s [2] work on charging DMA buffers > allocated from userspace to cgroups (dmem), this patch adds the same > charging pattern used by CMA heaps patch. Charging is done only through > the dma-buf heap interface so it can be attributed to a userspace allocator. > > This allows each device-specific reserved-memory region to enforce its > own limits. > > [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… > [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… > --- > drivers/dma-buf/heaps/Kconfig | 17 ++ > drivers/dma-buf/heaps/Makefile | 1 + > drivers/dma-buf/heaps/coherent_heap.c | 485 ++++++++++++++++++++++++++++++++++ > include/linux/dma-heap.h | 11 + > kernel/dma/coherent.c | 9 + > 5 files changed, 523 insertions(+) > > diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig > index a5eef06c42264..93765dca164e3 100644 > --- a/drivers/dma-buf/heaps/Kconfig > +++ b/drivers/dma-buf/heaps/Kconfig > @@ -12,3 +12,20 @@ config DMABUF_HEAPS_CMA > Choose this option to enable dma-buf CMA heap. This heap is backed > by the Contiguous Memory Allocator (CMA). If your system has these > regions, you should say Y here. > + > +config DMABUF_HEAPS_COHERENT > + bool "DMA-BUF Coherent Reserved-Memory Heap" > + depends on DMABUF_HEAPS && OF_RESERVED_MEM && DMA_DECLARE_COHERENT > + help > + Choose this option to enable coherent reserved-memory dma-buf heaps. > + This heap is backed by non-reusable DT "shared-dma-pool" regions. > + If your system defines coherent reserved-memory regions, you should > + say Y here. > + > +config COHERENT_AREAS_DEFERRED > + int "Max deferred coherent reserved-memory regions" > + depends on DMABUF_HEAPS_COHERENT > + default 16 > + help > + Maximum number of coherent reserved-memory regions that can be > + deferred for later registration during early boot. > diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile > index 974467791032f..96bda7a65f041 100644 > --- a/drivers/dma-buf/heaps/Makefile > +++ b/drivers/dma-buf/heaps/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o > obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o > +obj-$(CONFIG_DMABUF_HEAPS_COHERENT) += coherent_heap.o > diff --git a/drivers/dma-buf/heaps/coherent_heap.c b/drivers/dma-buf/heaps/coherent_heap.c > new file mode 100644 > index 0000000000000..870b2b89aefcb > --- /dev/null > +++ b/drivers/dma-buf/heaps/coherent_heap.c > @@ -0,0 +1,485 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * DMABUF heap for coherent reserved-memory regions > + * > + * Copyright (C) 2026 Red Hat, Inc. > + * Author: Albert Esteve <aesteve(a)redhat.com> > + * > + */ > + > +#include <linux/cgroup_dmem.h> > +#include <linux/dma-heap.h> > +#include <linux/dma-buf.h> > +#include <linux/dma-mapping.h> > +#include <linux/err.h> > +#include <linux/highmem.h> > +#include <linux/iosys-map.h> > +#include <linux/of_reserved_mem.h> > +#include <linux/platform_device.h> > +#include <linux/scatterlist.h> > +#include <linux/slab.h> > +#include <linux/vmalloc.h> > + > +#define DEFERRED_AREAS_MAX CONFIG_COHERENT_AREAS_DEFERRED > + > +/* > + * Early init can't use normal memory management yet (memblock is used > + * instead), so keep a small deferred list and retry at late_initcall. > + */ > +static struct reserved_mem *rmem_areas_deferred[DEFERRED_AREAS_MAX]; > +static unsigned int rmem_areas_deferred_num; > + > +static int coherent_heap_add_deferred(struct reserved_mem *rmem) > +{ > + if (rmem_areas_deferred_num >= DEFERRED_AREAS_MAX) { > + pr_warn("Deferred heap areas list full, dropping %s\n", > + rmem->name ? rmem->name : "unknown"); > + return -EINVAL; > + } > + rmem_areas_deferred[rmem_areas_deferred_num++] = rmem; > + return 0; > +} > + > +struct coherent_heap { > + struct dma_heap *heap; > + struct reserved_mem *rmem; > + char *name; > + struct device *dev; > + struct platform_device *pdev; > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + struct dmem_cgroup_region *cg; > +#endif > +}; > + > +struct coherent_heap_buffer { > + struct coherent_heap *heap; > + struct list_head attachments; > + struct mutex lock; > + unsigned long len; > + dma_addr_t dma_addr; > + void *alloc_vaddr; > + struct page **pages; > + pgoff_t pagecount; > + int vmap_cnt; > + void *vaddr; > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + struct dmem_cgroup_pool_state *pool; > +#endif > +}; > + > +struct dma_heap_attachment { > + struct device *dev; > + struct sg_table table; > + struct list_head list; > + bool mapped; > +}; > + > +static int coherent_heap_attach(struct dma_buf *dmabuf, > + struct dma_buf_attachment *attachment) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + struct dma_heap_attachment *a; > + int ret; > + > + a = kzalloc_obj(*a); > + if (!a) > + return -ENOMEM; > + > + ret = sg_alloc_table_from_pages(&a->table, buffer->pages, > + buffer->pagecount, 0, > + buffer->pagecount << PAGE_SHIFT, > + GFP_KERNEL); > + if (ret) { > + kfree(a); > + return ret; > + } > + > + a->dev = attachment->dev; > + INIT_LIST_HEAD(&a->list); > + a->mapped = false; > + > + attachment->priv = a; > + > + mutex_lock(&buffer->lock); > + list_add(&a->list, &buffer->attachments); > + mutex_unlock(&buffer->lock); > + > + return 0; > +} > + > +static void coherent_heap_detach(struct dma_buf *dmabuf, > + struct dma_buf_attachment *attachment) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + struct dma_heap_attachment *a = attachment->priv; > + > + mutex_lock(&buffer->lock); > + list_del(&a->list); > + mutex_unlock(&buffer->lock); > + > + sg_free_table(&a->table); > + kfree(a); > +} > + > +static struct sg_table *coherent_heap_map_dma_buf(struct dma_buf_attachment *attachment, > + enum dma_data_direction direction) > +{ > + struct dma_heap_attachment *a = attachment->priv; > + struct sg_table *table = &a->table; > + int ret; > + > + ret = dma_map_sgtable(attachment->dev, table, direction, 0); > + if (ret) > + return ERR_PTR(-ENOMEM); > + a->mapped = true; > + > + return table; > +} > + > +static void coherent_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, > + struct sg_table *table, > + enum dma_data_direction direction) > +{ > + struct dma_heap_attachment *a = attachment->priv; > + > + a->mapped = false; > + dma_unmap_sgtable(attachment->dev, table, direction, 0); > +} > + > +static int coherent_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, > + enum dma_data_direction direction) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + struct dma_heap_attachment *a; > + > + mutex_lock(&buffer->lock); > + if (buffer->vmap_cnt) > + invalidate_kernel_vmap_range(buffer->vaddr, buffer->len); > + > + list_for_each_entry(a, &buffer->attachments, list) { > + if (!a->mapped) > + continue; > + dma_sync_sgtable_for_cpu(a->dev, &a->table, direction); > + } > + mutex_unlock(&buffer->lock); > + > + return 0; > +} > + > +static int coherent_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, > + enum dma_data_direction direction) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + struct dma_heap_attachment *a; > + > + mutex_lock(&buffer->lock); > + if (buffer->vmap_cnt) > + flush_kernel_vmap_range(buffer->vaddr, buffer->len); > + > + list_for_each_entry(a, &buffer->attachments, list) { > + if (!a->mapped) > + continue; > + dma_sync_sgtable_for_device(a->dev, &a->table, direction); > + } > + mutex_unlock(&buffer->lock); > + > + return 0; > +} > + > +static int coherent_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + struct coherent_heap *coh_heap = buffer->heap; > + > + return dma_mmap_coherent(coh_heap->dev, vma, buffer->alloc_vaddr, > + buffer->dma_addr, buffer->len); > +} > + > +static void *coherent_heap_do_vmap(struct coherent_heap_buffer *buffer) > +{ > + void *vaddr; > + > + vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL); > + if (!vaddr) > + return ERR_PTR(-ENOMEM); > + > + return vaddr; > +} > + > +static int coherent_heap_vmap(struct dma_buf *dmabuf, struct iosys_map *map) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + void *vaddr; > + int ret = 0; > + > + mutex_lock(&buffer->lock); > + if (buffer->vmap_cnt) { > + buffer->vmap_cnt++; > + iosys_map_set_vaddr(map, buffer->vaddr); > + goto out; > + } > + > + vaddr = coherent_heap_do_vmap(buffer); > + if (IS_ERR(vaddr)) { > + ret = PTR_ERR(vaddr); > + goto out; > + } > + > + buffer->vaddr = vaddr; > + buffer->vmap_cnt++; > + iosys_map_set_vaddr(map, buffer->vaddr); > +out: > + mutex_unlock(&buffer->lock); > + > + return ret; > +} > + > +static void coherent_heap_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + > + mutex_lock(&buffer->lock); > + if (!--buffer->vmap_cnt) { > + vunmap(buffer->vaddr); > + buffer->vaddr = NULL; > + } > + mutex_unlock(&buffer->lock); > + iosys_map_clear(map); > +} > + > +static void coherent_heap_dma_buf_release(struct dma_buf *dmabuf) > +{ > + struct coherent_heap_buffer *buffer = dmabuf->priv; > + struct coherent_heap *coh_heap = buffer->heap; > + > + if (buffer->vmap_cnt > 0) { > + WARN(1, "%s: buffer still mapped in the kernel\n", __func__); > + vunmap(buffer->vaddr); > + buffer->vaddr = NULL; > + buffer->vmap_cnt = 0; > + } > + > + if (buffer->alloc_vaddr) > + dma_free_coherent(coh_heap->dev, buffer->len, buffer->alloc_vaddr, > + buffer->dma_addr); > + kfree(buffer->pages); > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + dmem_cgroup_uncharge(buffer->pool, buffer->len); > +#endif > + kfree(buffer); > +} > + > +static const struct dma_buf_ops coherent_heap_buf_ops = { > + .attach = coherent_heap_attach, > + .detach = coherent_heap_detach, > + .map_dma_buf = coherent_heap_map_dma_buf, > + .unmap_dma_buf = coherent_heap_unmap_dma_buf, > + .begin_cpu_access = coherent_heap_dma_buf_begin_cpu_access, > + .end_cpu_access = coherent_heap_dma_buf_end_cpu_access, > + .mmap = coherent_heap_mmap, > + .vmap = coherent_heap_vmap, > + .vunmap = coherent_heap_vunmap, > + .release = coherent_heap_dma_buf_release, > +}; > + > +static struct dma_buf *coherent_heap_allocate(struct dma_heap *heap, > + unsigned long len, > + u32 fd_flags, > + u64 heap_flags) > +{ > + struct coherent_heap *coh_heap; > + struct coherent_heap_buffer *buffer; > + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); > + size_t size = PAGE_ALIGN(len); > + pgoff_t pagecount = size >> PAGE_SHIFT; > + struct dma_buf *dmabuf; > + int ret = -ENOMEM; > + pgoff_t pg; > + > + coh_heap = dma_heap_get_drvdata(heap); > + if (!coh_heap) > + return ERR_PTR(-EINVAL); > + if (!coh_heap->dev) > + return ERR_PTR(-ENODEV); > + > + buffer = kzalloc_obj(*buffer); > + if (!buffer) > + return ERR_PTR(-ENOMEM); > + > + INIT_LIST_HEAD(&buffer->attachments); > + mutex_init(&buffer->lock); > + buffer->len = size; > + buffer->heap = coh_heap; > + buffer->pagecount = pagecount; > + > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + if (mem_accounting) { > + ret = dmem_cgroup_try_charge(coh_heap->cg, size, > + &buffer->pool, NULL); > + if (ret) > + goto free_buffer; > + } > +#endif > + > + buffer->alloc_vaddr = dma_alloc_coherent(coh_heap->dev, buffer->len, > + &buffer->dma_addr, GFP_KERNEL); > + if (!buffer->alloc_vaddr) { > + ret = -ENOMEM; > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + goto uncharge_cgroup; > +#else > + goto free_buffer; > +#endif > + } > + > + buffer->pages = kmalloc_array(pagecount, sizeof(*buffer->pages), > + GFP_KERNEL); > + if (!buffer->pages) { > + ret = -ENOMEM; > + goto free_dma; > + } > + > + for (pg = 0; pg < pagecount; pg++) > + buffer->pages[pg] = virt_to_page((char *)buffer->alloc_vaddr + > + (pg * PAGE_SIZE)); > + > + /* create the dmabuf */ > + exp_info.exp_name = dma_heap_get_name(heap); > + exp_info.ops = &coherent_heap_buf_ops; > + exp_info.size = buffer->len; > + exp_info.flags = fd_flags; > + exp_info.priv = buffer; > + dmabuf = dma_buf_export(&exp_info); > + if (IS_ERR(dmabuf)) { > + ret = PTR_ERR(dmabuf); > + goto free_pages; > + } > + return dmabuf; > + > +free_pages: > + kfree(buffer->pages); > +free_dma: > + dma_free_coherent(coh_heap->dev, buffer->len, buffer->alloc_vaddr, > + buffer->dma_addr); > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > +uncharge_cgroup: > + dmem_cgroup_uncharge(buffer->pool, size); > +#endif > +free_buffer: > + kfree(buffer); > + return ERR_PTR(ret); > +} > + > +static const struct dma_heap_ops coherent_heap_ops = { > + .allocate = coherent_heap_allocate, > +}; > + > +static int __coherent_heap_register(struct reserved_mem *rmem) > +{ > + struct dma_heap_export_info exp_info; > + struct coherent_heap *coh_heap; > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + struct dmem_cgroup_region *region; > +#endif > + const char *rmem_name; > + int ret; > + > + if (!rmem) > + return -EINVAL; > + > + rmem_name = rmem->name ? rmem->name : "unknown"; > + > + coh_heap = kzalloc_obj(*coh_heap); > + if (!coh_heap) > + return -ENOMEM; > + > + coh_heap->name = kasprintf(GFP_KERNEL, "coherent_%s", rmem_name); > + if (!coh_heap->name) { > + ret = -ENOMEM; > + goto free_coherent_heap; > + } > + > + coh_heap->rmem = rmem; > + > + /* create a platform device per rmem and bind it */ > + coh_heap->pdev = platform_device_register_simple("coherent-heap", > + PLATFORM_DEVID_AUTO, > + NULL, 0); > + if (IS_ERR(coh_heap->pdev)) { > + ret = PTR_ERR(coh_heap->pdev); > + goto free_name; > + } > + > + if (rmem->ops && rmem->ops->device_init) { > + ret = rmem->ops->device_init(rmem, &coh_heap->pdev->dev); > + if (ret) > + goto pdev_unregister; > + } > + > + coh_heap->dev = &coh_heap->pdev->dev; > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + region = dmem_cgroup_register_region(rmem->size, "coh/%s", rmem_name); > + if (IS_ERR(region)) { > + ret = PTR_ERR(region); > + goto pdev_unregister; > + } > + coh_heap->cg = region; > +#endif > + > + exp_info.name = coh_heap->name; > + exp_info.ops = &coherent_heap_ops; > + exp_info.priv = coh_heap; > + > + coh_heap->heap = dma_heap_add(&exp_info); > + if (IS_ERR(coh_heap->heap)) { > + ret = PTR_ERR(coh_heap->heap); > + goto cg_unregister; > + } > + > + return 0; > + > +cg_unregister: > +#if IS_ENABLED(CONFIG_CGROUP_DMEM) > + dmem_cgroup_unregister_region(coh_heap->cg); > +#endif > +pdev_unregister: > + platform_device_unregister(coh_heap->pdev); > + coh_heap->pdev = NULL; > +free_name: > + kfree(coh_heap->name); > +free_coherent_heap: > + kfree(coh_heap); > + > + return ret; > +} > + > +int dma_heap_coherent_register(struct reserved_mem *rmem) > +{ > + int ret; > + > + ret = __coherent_heap_register(rmem); > + if (ret == -ENOMEM) > + return coherent_heap_add_deferred(rmem); > + return ret; > +} > + > +static int __init coherent_heap_register_deferred(void) > +{ > + unsigned int i; > + int ret; > + > + for (i = 0; i < rmem_areas_deferred_num; i++) { > + struct reserved_mem *rmem = rmem_areas_deferred[i]; > + > + ret = __coherent_heap_register(rmem); > + if (ret) { > + pr_warn("Failed to add coherent heap %s", > + rmem->name ? rmem->name : "unknown"); > + continue; > + } > + } > + > + return 0; > +} > +late_initcall(coherent_heap_register_deferred); > +MODULE_DESCRIPTION("DMA-BUF heap for coherent reserved-memory regions"); > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h > index 648328a64b27e..e894cfa1ecf1a 100644 > --- a/include/linux/dma-heap.h > +++ b/include/linux/dma-heap.h > @@ -9,9 +9,11 @@ > #ifndef _DMA_HEAPS_H > #define _DMA_HEAPS_H > > +#include <linux/errno.h> > #include <linux/types.h> > > struct dma_heap; > +struct reserved_mem; > > /** > * struct dma_heap_ops - ops to operate on a given heap > @@ -48,4 +50,13 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info); > > extern bool mem_accounting; > > +#if IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT) > +int dma_heap_coherent_register(struct reserved_mem *rmem); > +#else > +static inline int dma_heap_coherent_register(struct reserved_mem *rmem) > +{ > + return -EOPNOTSUPP; > +} > +#endif > + > #endif /* _DMA_HEAPS_H */ > diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c > index 1147497bc512c..f49d13e460e4b 100644 > --- a/kernel/dma/coherent.c > +++ b/kernel/dma/coherent.c > @@ -9,6 +9,7 @@ > #include <linux/module.h> > #include <linux/dma-direct.h> > #include <linux/dma-map-ops.h> > +#include <linux/dma-heap.h> > > struct dma_coherent_mem { > void *virt_base; > @@ -393,6 +394,14 @@ static int __init rmem_dma_setup(struct reserved_mem *rmem) > rmem->ops = &rmem_dma_ops; > pr_info("Reserved memory: created DMA memory pool at %pa, size %ld MiB\n", > &rmem->base, (unsigned long)rmem->size / SZ_1M); > + > + if (IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT)) { > + int ret = dma_heap_coherent_register(rmem); > + > + if (ret) > + pr_warn("Reserved memory: failed to register coherent heap for %s (%d)\n", > + rmem->name ? rmem->name : "unknown", ret); > + } > return 0; > } > > > --- > base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f > change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 > > Best regards,

3 weeks, 2 days

Re: [PATCH 7/9] accel/neutron: Add job submission IOCTL

by Christian König

On 2/26/26 14:40, Ioana Ciocoi-Radulescu wrote: > [Sie erhalten nicht häufig E-Mails von ruxandra.radulescu(a)nxp.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] > > Neutron can execute a single job at a time. For now, only inference > jobs are supported. Each job has exactly one BO associated with it. > > When submitting a job, user also provides a syncobj handle on which it > will wait for job completion. > > We use the DRM GPU scheduler for job management. Large part of the job > submission code is based on the example of the ethosu driver. > > Signed-off-by: Jiwei Fu <jiwei.fu(a)nxp.com> > Signed-off-by: Ioana Ciocoi-Radulescu <ruxandra.radulescu(a)nxp.com> > --- > drivers/accel/neutron/Makefile | 1 + > drivers/accel/neutron/neutron_device.c | 8 +- > drivers/accel/neutron/neutron_device.h | 21 ++ > drivers/accel/neutron/neutron_driver.c | 28 ++- > drivers/accel/neutron/neutron_driver.h | 3 + > drivers/accel/neutron/neutron_job.c | 367 +++++++++++++++++++++++++++++++++ > drivers/accel/neutron/neutron_job.h | 45 ++++ > include/uapi/drm/neutron_accel.h | 51 +++++ > 8 files changed, 519 insertions(+), 5 deletions(-) > > diff --git a/drivers/accel/neutron/Makefile b/drivers/accel/neutron/Makefile > index 192ed896a9f9..ac6dd576521c 100644 > --- a/drivers/accel/neutron/Makefile > +++ b/drivers/accel/neutron/Makefile > @@ -6,4 +6,5 @@ neutron-y := \ > neutron_driver.o \ > neutron_device.o \ > neutron_gem.o \ > + neutron_job.o \ > neutron_mailbox.o > diff --git a/drivers/accel/neutron/neutron_device.c b/drivers/accel/neutron/neutron_device.c > index e5c09105be99..571ec906ad72 100644 > --- a/drivers/accel/neutron/neutron_device.c > +++ b/drivers/accel/neutron/neutron_device.c > @@ -7,6 +7,7 @@ > #include <linux/iopoll.h> > > #include "neutron_device.h" > +#include "neutron_job.h" > #include "neutron_mailbox.h" > > void neutron_enable_irq(struct neutron_device *ndev) > @@ -32,9 +33,14 @@ void neutron_handle_irq(struct neutron_device *ndev) > /* Write 1 to clear */ > writel_relaxed(appstatus & APPSTATUS_CLEAR_MASK, NEUTRON_REG(ndev, APPSTATUS)); > > - if (appstatus & APPSTATUS_FAULTCAUSE_MASK) > + if (appstatus & APPSTATUS_FAULTCAUSE_MASK) { > dev_err(ndev->dev, "Neutron halted due to fault: 0x%lx\n", > FIELD_GET(APPSTATUS_FAULTCAUSE_MASK, appstatus)); > + return neutron_job_err_handler(ndev); > + } > + > + if (appstatus & APPSTATUS_INFDONE) > + neutron_job_done_handler(ndev); > } > > #define neutron_boot_done(appctrl) \ > diff --git a/drivers/accel/neutron/neutron_device.h b/drivers/accel/neutron/neutron_device.h > index 8e4df7462d82..0ed72965774d 100644 > --- a/drivers/accel/neutron/neutron_device.h > +++ b/drivers/accel/neutron/neutron_device.h > @@ -9,8 +9,10 @@ > #include <linux/spinlock.h> > #include <linux/bits.h> > #include <drm/drm_device.h> > +#include <drm/gpu_scheduler.h> > > struct clk_bulk_data; > +struct neutron_job; > > #define NEUTRON_FIRMWARE_NAME "NeutronFirmware.elf" > > @@ -92,6 +94,13 @@ enum neutron_mem_id { > * @clks: Neutron clocks > * @num_clks: Number of clocks > * @flags: Software flags used by driver > + * @fence_lock: DMA fence lock > + * @sched: GPU scheduler > + * @sched_lock: Scheduler lock, for neutron_push_job > + * @fence_context: Fence context > + * @job_seqno: Job sequence number > + * @job_lock: Job lock, for active_job handling > + * @active_job: Currently active job > */ > struct neutron_device { > struct drm_device base; > @@ -103,6 +112,18 @@ struct neutron_device { > struct clk_bulk_data *clks; > int num_clks; > u32 flags; > + > + /* For dma_fence */ > + spinlock_t fence_lock; I've just pushed a patch set to drm-misc-next which makes the fence_lock superflous in most cases. Just provide NULL as lock when calling to dma_fence_init(). > + struct drm_gpu_scheduler sched; > + /* For neutron_push_job */ > + struct mutex sched_lock; > + u64 fence_context; > + u64 job_seqno; > + > + /* For active_job handling */ > + struct mutex job_lock; > + struct neutron_job *active_job; > }; > > #define to_neutron_device(drm) \ > diff --git a/drivers/accel/neutron/neutron_driver.c b/drivers/accel/neutron/neutron_driver.c > index c9a18bf52037..ceae1f7e8359 100644 > --- a/drivers/accel/neutron/neutron_driver.c > +++ b/drivers/accel/neutron/neutron_driver.c > @@ -19,40 +19,53 @@ > #include "neutron_device.h" > #include "neutron_driver.h" > #include "neutron_gem.h" > +#include "neutron_job.h" > > #define NEUTRON_SUSPEND_DELAY_MS 1000 > > static const struct drm_ioctl_desc neutron_drm_ioctls[] = { > DRM_IOCTL_DEF_DRV(NEUTRON_CREATE_BO, neutron_ioctl_create_bo, 0), > DRM_IOCTL_DEF_DRV(NEUTRON_SYNC_BO, neutron_ioctl_sync_bo, 0), > + DRM_IOCTL_DEF_DRV(NEUTRON_SUBMIT_JOB, neutron_ioctl_submit_job, 0), > }; > > static int neutron_open(struct drm_device *drm, struct drm_file *file) > { > struct neutron_device *ndev = to_neutron_device(drm); > struct neutron_file_priv *npriv; > + int ret; > > npriv = kzalloc_obj(*npriv); > if (!npriv) > return -ENOMEM; > > npriv->ndev = ndev; > - file->driver_priv = npriv; > > + ret = neutron_job_open(npriv); > + if (ret) > + goto err_free; > + > + file->driver_priv = npriv; > return 0; > + > +err_free: > + kfree(npriv); > + return ret; > } > > static void neutron_postclose(struct drm_device *drm, struct drm_file *file) > { > struct neutron_file_priv *npriv = file->driver_priv; > > + neutron_job_close(npriv); > kfree(npriv); > } > > DEFINE_DRM_ACCEL_FOPS(neutron_drm_driver_fops); > > static const struct drm_driver neutron_drm_driver = { > - .driver_features = DRIVER_COMPUTE_ACCEL | DRIVER_GEM, > + .driver_features = DRIVER_COMPUTE_ACCEL | DRIVER_GEM | > + DRIVER_SYNCOBJ, > .name = "neutron", > .desc = "NXP Neutron driver", > .major = 1, > @@ -151,19 +164,25 @@ static int neutron_probe(struct platform_device *pdev) > return ret; > } > > - ret = devm_pm_runtime_enable(dev); > + ret = neutron_job_init(ndev); > if (ret) > goto free_reserved; > > + ret = devm_pm_runtime_enable(dev); > + if (ret) > + goto free_job; > + > pm_runtime_set_autosuspend_delay(dev, NEUTRON_SUSPEND_DELAY_MS); > pm_runtime_use_autosuspend(dev); > > ret = drm_dev_register(&ndev->base, 0); > if (ret) > - goto free_reserved; > + goto free_job; > > return 0; > > +free_job: > + neutron_job_fini(ndev); > free_reserved: > of_reserved_mem_device_release(&pdev->dev); > > @@ -175,6 +194,7 @@ static void neutron_remove(struct platform_device *pdev) > struct neutron_device *ndev = platform_get_drvdata(pdev); > > drm_dev_unregister(&ndev->base); > + neutron_job_fini(ndev); > of_reserved_mem_device_release(&pdev->dev); > } > > diff --git a/drivers/accel/neutron/neutron_driver.h b/drivers/accel/neutron/neutron_driver.h > index cd52b5eb2d27..b709de74105a 100644 > --- a/drivers/accel/neutron/neutron_driver.h > +++ b/drivers/accel/neutron/neutron_driver.h > @@ -4,10 +4,13 @@ > #ifndef __NEUTRON_DRIVER_H__ > #define __NEUTRON_DRIVER_H__ > > +#include <drm/gpu_scheduler.h> > + > struct neutron_device; > > struct neutron_file_priv { > struct neutron_device *ndev; > + struct drm_sched_entity sched_entity; > }; > > #endif /* __NEUTRON_DRIVER_H__ */ > diff --git a/drivers/accel/neutron/neutron_job.c b/drivers/accel/neutron/neutron_job.c > new file mode 100644 > index 000000000000..316e361166a2 > --- /dev/null > +++ b/drivers/accel/neutron/neutron_job.c > @@ -0,0 +1,367 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* Copyright 2025-2026 NXP */ > + > +#include <linux/delay.h> > +#include <linux/pm_runtime.h> > +#include <drm/drm_file.h> > +#include <drm/drm_print.h> > +#include <drm/drm_gem_dma_helper.h> > +#include <drm/neutron_accel.h> > + > +#include "neutron_driver.h" > +#include "neutron_device.h" > +#include "neutron_gem.h" > +#include "neutron_mailbox.h" > +#include "neutron_job.h" > + > +#define NEUTRON_JOB_TIMEOUT_MS 5000 > + > +static const char *neutron_fence_get_driver_name(struct dma_fence *fence) > +{ > + return "neutron"; > +} > + > +static const char *neutron_fence_get_timeline_name(struct dma_fence *fence) > +{ > + return "neutron-npu"; > +} > + > +static const struct dma_fence_ops neutron_fence_ops = { > + .get_driver_name = neutron_fence_get_driver_name, > + .get_timeline_name = neutron_fence_get_timeline_name, > +}; > + > +static void neutron_hw_submit(struct neutron_job *job) > +{ > + struct neutron_device *ndev = job->ndev; > + struct neutron_mbox_cmd cmd = {0}; > + u32 base_l, base_h; > + u64 base_addr; > + int ret; > + > + switch (job->type) { > + case DRM_NEUTRON_JOB_INFERENCE: > + cmd.id = NEUTRON_CMD_INFERENCE; > + cmd.args[0] = job->inference.tensor_offset; > + cmd.args[1] = job->inference.microcode_offset; > + cmd.args[2] = job->inference.tensor_count; > + break; > + default: > + dev_WARN(ndev->dev, "Unknown job type: %d\n", job->type); > + return; > + } > + > + base_addr = to_drm_gem_dma_obj(job->bo)->dma_addr; > + base_l = lower_32_bits(base_addr); > + base_h = upper_32_bits(base_addr); > + > + writel_relaxed(base_l, NEUTRON_REG(ndev, BASEDDRL)); > + writel_relaxed(base_l, NEUTRON_REG(ndev, BASEINOUTL)); > + writel_relaxed(base_l, NEUTRON_REG(ndev, BASESPILLL)); > + writel_relaxed(base_h, NEUTRON_REG(ndev, BASEDDRH)); > + writel_relaxed(base_h, NEUTRON_REG(ndev, BASEINOUTH)); > + writel_relaxed(base_h, NEUTRON_REG(ndev, BASESPILLH)); > + > + ret = neutron_mbox_send_cmd(ndev, &cmd); > + if (ret) { > + /* Nothing we can do here, we'll reset the device on timeout */ > + dev_err(ndev->dev, "Failed to submit job, device is busy\n"); > + } > +} > + > +void neutron_job_err_handler(struct neutron_device *ndev) > +{ > + guard(mutex)(&ndev->job_lock); > + > + if (ndev->active_job) > + drm_sched_fault(&ndev->sched); > +} > + > +void neutron_job_done_handler(struct neutron_device *ndev) > +{ > + struct neutron_mbox_state state; > + > + neutron_mbox_read_state(ndev, &state); > + if (state.status != NEUTRON_FW_STATUS_DONE) { > + dev_err(ndev->dev, "Inconsistent firmware state: status 0x%x, err 0x%x\n", > + state.status, state.err_code); > + return neutron_job_err_handler(ndev); > + } > + > + if (state.err_code != 0) > + dev_warn(ndev->dev, "Job finished with error: 0x%x\n", > + state.err_code); Not mandatory but you might also want to forward that as error to your dma_fence, see dma_fence_set_error(). > + > + /* Reset Neutron internal state to prepare for next inference */ > + neutron_mbox_reset_state(ndev); > + > + scoped_guard(mutex, &ndev->job_lock) { > + if (ndev->active_job) { > + dma_fence_signal(ndev->active_job->neutron_fence); > + ndev->active_job = NULL; > + } > + } > +} > + > +static void neutron_cleanup_job(struct kref *ref) > +{ > + struct neutron_job *job = container_of(ref, struct neutron_job, refcnt); > + > + pm_runtime_put_autosuspend(job->ndev->base.dev); > + > + dma_fence_put(job->neutron_fence); > + dma_fence_put(job->sched_fence); > + drm_gem_object_put(job->bo); > + drm_syncobj_put(job->syncobj); > + > + kfree(job); > +} > + > +static void neutron_put_job(struct neutron_job *job) > +{ > + kref_put(&job->refcnt, neutron_cleanup_job); > +} > + > +static void neutron_free_job(struct drm_sched_job *sched_job) > +{ > + struct neutron_job *job = to_neutron_job(sched_job); > + > + drm_sched_job_cleanup(sched_job); > + neutron_put_job(job); > +} > + > +static struct dma_fence *neutron_run_job(struct drm_sched_job *sched_job) > +{ > + struct neutron_job *job = to_neutron_job(sched_job); > + struct dma_fence *fence = job->neutron_fence; > + struct neutron_device *ndev = job->ndev; > + > + if (unlikely(job->base.s_fence->finished.error)) > + return NULL; > + > + dma_fence_init(fence, &neutron_fence_ops, &ndev->fence_lock, > + ndev->fence_context, ++ndev->job_seqno); > + dma_fence_get(fence); > + > + scoped_guard(mutex, &ndev->job_lock) { > + ndev->active_job = job; > + neutron_hw_submit(job); > + } > + > + return fence; > +} > + > +static enum drm_gpu_sched_stat neutron_timedout_job(struct drm_sched_job *sched_job) > +{ > + struct neutron_job *job = to_neutron_job(sched_job); > + struct neutron_device *ndev = job->ndev; > + struct neutron_mbox_state state; > + > + /* We assume Neutron is stuck, retrieve current state and reset */ > + neutron_mbox_read_state(ndev, &state); > + dev_err(ndev->dev, "Neutron timedout, status: 0x%x, err: 0x%x\n", > + state.status, state.err_code); > + > + drm_sched_stop(&ndev->sched, sched_job); > + > + scoped_guard(mutex, &ndev->job_lock) > + ndev->active_job = NULL; > + > + pm_runtime_force_suspend(ndev->dev); > + pm_runtime_force_resume(ndev->dev); > + > + drm_sched_start(&ndev->sched, 0); > + > + return DRM_GPU_SCHED_STAT_RESET; > +} > + > +static void neutron_cancel_job(struct drm_sched_job *sched_job) > +{ > + struct neutron_job *job = to_neutron_job(sched_job); > + struct neutron_device *ndev = job->ndev; > + > + guard(mutex)(&ndev->job_lock); > + > + if (!dma_fence_is_signaled(job->neutron_fence)) { > + dma_fence_set_error(job->neutron_fence, -ECANCELED); > + dma_fence_signal(job->neutron_fence); > + } > +} > + > +static const struct drm_sched_backend_ops neutron_sched_ops = { > + .run_job = neutron_run_job, > + .free_job = neutron_free_job, > + .timedout_job = neutron_timedout_job, > + .cancel_job = neutron_cancel_job, > +}; > + > +int neutron_job_init(struct neutron_device *ndev) > +{ > + const struct drm_sched_init_args args = { > + .ops = &neutron_sched_ops, > + .num_rqs = DRM_SCHED_PRIORITY_COUNT, > + .credit_limit = 1, > + .timeout = msecs_to_jiffies(NEUTRON_JOB_TIMEOUT_MS), > + .name = dev_name(ndev->dev), > + .dev = ndev->dev, > + }; > + int ret; > + > + ret = devm_mutex_init(ndev->dev, &ndev->sched_lock); > + if (ret) > + return ret; > + ret = devm_mutex_init(ndev->dev, &ndev->job_lock); > + if (ret) > + return ret; > + spin_lock_init(&ndev->fence_lock); > + > + ndev->fence_context = dma_fence_context_alloc(1); > + > + ret = drm_sched_init(&ndev->sched, &args); > + if (ret) > + dev_err(ndev->dev, "Error creating DRM scheduler\n"); > + > + return ret; > +} > + > +void neutron_job_fini(struct neutron_device *ndev) > +{ > + drm_sched_fini(&ndev->sched); > +} > + > +int neutron_job_open(struct neutron_file_priv *npriv) > +{ > + struct neutron_device *ndev = npriv->ndev; > + struct drm_gpu_scheduler *sched = &ndev->sched; > + int ret; > + > + ret = drm_sched_entity_init(&npriv->sched_entity, > + DRM_SCHED_PRIORITY_NORMAL, > + &sched, 1, NULL); > + if (ret) > + dev_err(ndev->dev, "Error creating scheduler entity\n"); > + > + return ret; > +} > + > +void neutron_job_close(struct neutron_file_priv *npriv) > +{ > + drm_sched_entity_destroy(&npriv->sched_entity); > +} > + > +static int neutron_push_job(struct neutron_job *job) > +{ > + struct neutron_device *ndev = job->ndev; > + struct ww_acquire_ctx acquire_ctx; > + int ret; > + > + ret = drm_gem_lock_reservations(&job->bo, 1, &acquire_ctx); > + if (ret) > + return ret; > + > + ret = dma_resv_reserve_fences(job->bo->resv, 1); > + if (ret) > + goto out_unlock_res; > + > + ret = drm_sched_job_add_implicit_dependencies(&job->base, job->bo, true); > + if (ret) > + goto out_unlock_res; > + > + ret = pm_runtime_resume_and_get(ndev->base.dev); > + if (ret) > + goto out_unlock_res; > + > + scoped_guard(mutex, &ndev->sched_lock) { > + drm_sched_job_arm(&job->base); > + > + job->sched_fence = dma_fence_get(&job->base.s_fence->finished); > + drm_syncobj_replace_fence(job->syncobj, job->sched_fence); > + > + kref_get(&job->refcnt); > + drm_sched_entity_push_job(&job->base); > + > + dma_resv_add_fence(job->bo->resv, job->sched_fence, > + DMA_RESV_USAGE_WRITE); > + } > + > +out_unlock_res: > + drm_gem_unlock_reservations(&job->bo, 1, &acquire_ctx); > + > + return ret; > +} > + > +int neutron_ioctl_submit_job(struct drm_device *drm, void *data, struct drm_file *filp) > +{ > + struct neutron_device *ndev = to_neutron_device(drm); > + struct neutron_file_priv *npriv = filp->driver_priv; > + struct drm_neutron_submit_job *args = data; > + struct neutron_job *job; > + int ret; > + > + if (args->pad) > + return -EINVAL; > + > + job = kzalloc_obj(*job); > + if (!job) > + return -ENOMEM; > + > + job->ndev = ndev; > + kref_init(&job->refcnt); > + > + job->neutron_fence = kzalloc_obj(*job->neutron_fence); > + if (!job->neutron_fence) { > + ret = -ENOMEM; > + goto out_free_job; > + } > + > + switch (args->type) { > + case DRM_NEUTRON_JOB_INFERENCE: > + memcpy(&job->inference, &args->inference, > + sizeof(args->inference)); > + break; > + default: > + dev_dbg(ndev->dev, "Invalid job type %d\n", args->type); > + ret = -EINVAL; > + goto out_free_fence; > + } > + > + job->bo = drm_gem_object_lookup(filp, args->bo_handle); > + if (!job->bo) { > + dev_dbg(ndev->dev, "Invalid BO handle\n"); > + ret = -ENOENT; > + goto out_free_fence; > + } > + > + job->syncobj = drm_syncobj_find(filp, args->syncobj_handle); > + if (!job->syncobj) { > + dev_dbg(ndev->dev, "Invalid syncobj handle\n"); > + ret = -ENOENT; > + goto out_put_gem; > + } > + > + ret = drm_sched_job_init(&job->base, &npriv->sched_entity, 1, NULL, > + filp->client_id); > + if (ret) > + goto out_put_syncobj; > + > + ret = neutron_push_job(job); > + if (ret) > + goto out_sched_cleanup; > + > + neutron_put_job(job); > + > + return 0; > + > +out_sched_cleanup: > + drm_sched_job_cleanup(&job->base); > +out_put_syncobj: > + drm_syncobj_put(job->syncobj); > +out_put_gem: > + drm_gem_object_put(job->bo); > +out_free_fence: > + kfree(job->neutron_fence); > +out_free_job: > + kfree(job); > + > + return ret; > +} > diff --git a/drivers/accel/neutron/neutron_job.h b/drivers/accel/neutron/neutron_job.h > new file mode 100644 > index 000000000000..bb7773aeb218 > --- /dev/null > +++ b/drivers/accel/neutron/neutron_job.h > @@ -0,0 +1,45 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* Copyright 2025-2026 NXP */ > + > +#ifndef __NEUTRON_JOB_H__ > +#define __NEUTRON_JOB_H__ > + > +#include <linux/kref.h> > +#include <drm/drm_gem.h> > +#include <drm/drm_syncobj.h> > +#include <drm/gpu_scheduler.h> > +#include <drm/neutron_accel.h> > + > +#include "neutron_driver.h" > + > +struct neutron_device; > +struct neutron_file_priv; > + > +struct neutron_job { > + struct drm_sched_job base; > + struct neutron_device *ndev; > + struct dma_fence *neutron_fence; > + struct dma_fence *sched_fence; That looks superflous to me. You should always have the scheduler fence through the base. > + struct drm_syncobj *syncobj; Why do you want to keep the syncobj around? Apart from those notes looks pretty good to me, but I'm a bit disapointed that there isn't any DMA-buf support to review :) Regards, Christian. > + struct drm_gem_object *bo; > + enum drm_neutron_job_type type; > + union { > + struct drm_neutron_inference_job inference; > + }; > + struct kref refcnt; > +}; > + > +#define to_neutron_job(job) \ > + container_of(job, struct neutron_job, base) > + > +int neutron_job_init(struct neutron_device *dev); > +void neutron_job_fini(struct neutron_device *dev); > +int neutron_job_open(struct neutron_file_priv *npriv); > +void neutron_job_close(struct neutron_file_priv *npriv); > + > +void neutron_job_done_handler(struct neutron_device *dev); > +void neutron_job_err_handler(struct neutron_device *dev); > + > +int neutron_ioctl_submit_job(struct drm_device *dev, void *data, struct drm_file *filp); > + > +#endif /* __NEUTRON_JOB_H__ */ > diff --git a/include/uapi/drm/neutron_accel.h b/include/uapi/drm/neutron_accel.h > index 2f5639f2e0e8..a9e5682709d2 100644 > --- a/include/uapi/drm/neutron_accel.h > +++ b/include/uapi/drm/neutron_accel.h > @@ -15,10 +15,12 @@ extern "C" { > * > * @DRM_NEUTRON_CREATE_BO: Create a buffer object > * @DRM_NEUTRON_SYNC_BO: Sync (parts of) the buffer object memory > + * @DRM_NEUTRON_SUBMIT_JOB: Submit a job to the device > */ > enum drm_neutron_ioctl { > DRM_NEUTRON_CREATE_BO = 0, > DRM_NEUTRON_SYNC_BO, > + DRM_NEUTRON_SUBMIT_JOB, > }; > > /** > @@ -64,6 +66,51 @@ struct drm_neutron_sync_bo { > __u64 offset; > }; > > +/** > + * enum drm_neutron_job_type - Type of job to submit to Neutron device > + * > + * @DRM_NEUTRON_JOB_INFERENCE: Inference job > + */ > +enum drm_neutron_job_type { > + DRM_NEUTRON_JOB_INFERENCE = 0, > +}; > + > +/** > + * struct drm_neutron_inference_job - Inference job descriptor > + * > + * @tensor_offset: Offset of tensor array inside job BO > + * @microcode_offset: Microcode offset inside BO > + * @tensor_count: Number of valid tensors > + * @pad: MBZ > + */ > +struct drm_neutron_inference_job { > + __u32 tensor_offset; > + __u32 microcode_offset; > + __u32 tensor_count; > + __u32 pad[5]; > +}; > + > +/** > + * struct drm_neutron_submit_job - Submit a job to Neutron device > + * > + * @type: Job type, one of enum drm_neutron_job_type > + * @bo_handle: BO handle for this job > + * @inference: Inference job descriptor (when type is DRM_NEUTRON_JOB_INFERENCE) > + * @reserved: Reserved for future job types > + * @syncobj_handle: Handle of syncobj on which user waits for job completion > + * @pad: MBZ > + */ > +struct drm_neutron_submit_job { > + __u32 type; > + __u32 bo_handle; > + union { > + struct drm_neutron_inference_job inference; > + __u32 reserved[8]; > + }; > + __u32 syncobj_handle; > + __u32 pad; > +}; > + > #define DRM_IOCTL_NEUTRON_CREATE_BO \ > DRM_IOWR(DRM_COMMAND_BASE + DRM_NEUTRON_CREATE_BO, \ > struct drm_neutron_create_bo) > @@ -72,6 +119,10 @@ struct drm_neutron_sync_bo { > DRM_IOWR(DRM_COMMAND_BASE + DRM_NEUTRON_SYNC_BO, \ > struct drm_neutron_sync_bo) > > +#define DRM_IOCTL_NEUTRON_SUBMIT_JOB \ > + DRM_IOWR(DRM_COMMAND_BASE + DRM_NEUTRON_SUBMIT_JOB, \ > + struct drm_neutron_submit_job) > + > #if defined(__cplusplus) > } > #endif > > -- > 2.34.1 >

3 weeks, 2 days

PROFESSIONAL CRYPTO RECOVERY CONTACT WHISPERER HACKER RECOVERY

by kimberleyward369＠gmail.com

I had a tough time with my crypto assets after a mishap, and I was honestly feeling pretty lost. That’s when I found WHISPERER HACKER RECOVERY. From the get go, they were super approachable and walked me through the entire recovery process step by step.What really impressed me was their level of patience. They took the time to explain things in a way I could understand, which made me feel a lot more at ease. I appreciated that they weren’t just focused on the technical side of things; they genuinely seemed to care about helping me recover my investments.In the end, I was able to recover a significant portion of my crypto, and I couldn't be happier. If you’re facing a similar situation, I’d definitely recommend giving WHISPERER HACKER RECOVERY a try. They made a stressful situation much easier to handle!For More information visit their website at; Homepage > whispershackerrecovery . c o m WhatApp ; +44 (73 5 22, 191 25 Mailbox; info @ whispershackerrecovery. c o m

3 weeks, 2 days

Can Blockchain Trace Stolen Crypto? The Real Answer in 2026

by hamtonbecky＠gmail.com

Many believe stolen crypto is untraceable due to anonymity. In reality, public blockchains like Bitcoin and Ethereum make tracing possible. Addresses are pseudonymous, but transaction patterns, clusters, and exchange points reveal flows. Tracing identifies theft points, maps movements, clusters wallets, detects exchanges, and produces reports. Early action is key. Cryptera Chain Signals leads with 28+ years of experience, hundreds of successes, and high ratings. They trace effectively and educate on prevention. For tracing help, visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com.

3 weeks, 2 days

Lost USDT Recovery: Practical Steps and Expert Guidance in 2026

by hamtonbecky＠gmail.com

Lost USDT Recovery: Practical Steps and Expert Guidance in 2026 Losing USDT (Tether) whether through a scam, hack, or wallet error hurts because it's a stable coin meant to preserve value. In February 2026, USDT recovery is often more feasible than other tokens due to its heavy use on traceable chains like Ethereum, Tron, and BSC. Here's how to pursue lost USDT recovery. Step 1: Identify the Loss Type Scam/hack: funds transferred out. Wallet access loss: forgotten credentials. Mistaken send: wrong address. Step 2: Gather Evidence Save TXIDs, addresses, timestamps, scam proof. USDT transactions are visible on Tronscan, Etherscan, or BscScan. Step 3: Report and Secure Report to authorities and platforms. Move remaining assets. Step 4: Tracing USDT Flows USDT is ERC-20/TRC-20, making it highly traceable. Experts follow approvals, transfers, and exchange deposits. Cryptera Chain Signals specializes in USDT recovery with 28+ years of experience, hundreds of successes, and strong reviews. They trace flows and prepare evidence for freezes. Visit https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com for help.

3 weeks, 2 days

Re: [PATCH RFC 16/18] accel/qda: Add FastRPC-based DSP memory mapping support

by Krzysztof Kozlowski

On 23/02/2026 20:09, Ekansh Gupta wrote: > Add a DRM_QDA_MAP ioctl and supporting FastRPC plumbing to map GEM > backed buffers into the DSP virtual address space. The new > qda_mem_map UAPI structure allows userspace to request legacy MMAP > style mappings or handle-based MEM_MAP mappings with attributes, and > encodes flags, offsets and optional virtual address hints that are > forwarded to the DSP. > > On the FastRPC side new method identifiers FASTRPC_RMID_INIT_MMAP > and FASTRPC_RMID_INIT_MEM_MAP are introduced together with message > structures for map requests and responses. The fastrpc_prepare_args > path is extended to build the appropriate request headers, serialize > the physical page information derived from a GEM object into a > fastrpc_phy_page array and pack the arguments into the shared message > buffer used by the existing invoke infrastructure. > > The qda_ioctl_mmap() handler dispatches mapping requests based on the > qda_mem_map request type, reusing the generic fastrpc_invoke() > machinery and the RPMsg transport to communicate with the DSP. This > provides the foundation for explicit buffer mapping into the DSP > address space for subsequent FastRPC calls, aligned with the > traditional FastRPC user space model. > > Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> > --- > arch/arm64/configs/defconfig | 2 + Not relevan there. Don't stuff other subsystem code into your patches. Especially without any reasons (your commit msg must explain WHY you are doing things). > drivers/accel/qda/qda_drv.c | 1 + > drivers/accel/qda/qda_fastrpc.c | 217 ++++++++++++++++++++++++++++++++++++++++ > drivers/accel/qda/qda_fastrpc.h | 64 ++++++++++++ > drivers/accel/qda/qda_ioctl.c | 24 +++++ > drivers/accel/qda/qda_ioctl.h | 13 +++ > include/uapi/drm/qda_accel.h | 44 +++++++- > 7 files changed, 364 insertions(+), 1 deletion(-) > Best regards, Krzysztof

3 weeks, 2 days

Re: [PATCH RFC 04/18] accel/qda: Add built-in compute CB bus for QDA and integrate with IOMMU

by Krzysztof Kozlowski

On 23/02/2026 20:08, Ekansh Gupta wrote: > Introduce a built-in compute context-bank (CB) bus used by the Qualcomm > DSP accelerator (QDA) driver to represent DSP CB devices that require > IOMMU configuration. This separates the CB bus from the QDA driver and > allows QDA to remain a loadable module while the bus is always built-in. > > A new bool Kconfig symbol DRM_ACCEL_QDA_COMPUTE_BUS is added and is > selected by the main DRM_ACCEL_QDA driver. The parent accel Makefile is > updated to descend into the QDA directory for both built-in and module > builds so that the CB bus is compiled into vmlinux while the driver > remains modular. > > The CB bus is registered at postcore_initcall() time and is exposed to > the IOMMU core through iommu_buses[] in the same way as the Tegra > host1x context-bus. This enables later patches to create CB devices on > this bus and obtain IOMMU domains for them. > > Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> > --- > drivers/accel/Makefile | 1 + > drivers/accel/qda/Kconfig | 5 +++++ > drivers/accel/qda/Makefile | 2 ++ > drivers/accel/qda/qda_compute_bus.c | 23 +++++++++++++++++++++++ > drivers/iommu/iommu.c | 4 ++++ > include/linux/qda_compute_bus.h | 22 ++++++++++++++++++++++ Do not combine independent work into one patch. Also, your patch has clear patch warnings, so please review it BEFORE you send. Best regards, Krzysztof

3 weeks, 2 days

Best Crypto Scam Recovery Services in 2026: What Victims Need to Know

by hamtonbecky＠gmail.com

Best Crypto Scam Recovery Services in 2026: What Victims Need to Know Crypto scams phishing, fake platforms, romance fraud, rug pullsco st billions every year. Victims often feel helpless, believing recovery is impossible. In February 2026, legitimate recovery services do exist, and choosing the right one can lead to meaningful returns. Here's what you need to know about the best crypto scam recovery services and why Cryptera Chain Signals stands out. What Makes a Recovery Service Legitimate? Look for transparency: no upfront fees without assessment, no requests for private keys or seed phrases, realistic expectations (no 100% guarantees), and verifiable track records (reviews, case studies). Legitimate firms focus on tracing funds, identifying exchange endpoints, and preparing evidence for freezes or law enforcement. Common Recovery Paths Tracing maps funds through peeling chains, bridges, DEX swaps, and mixers to exchange deposits. Freezes happen when evidence proves theft. Law enforcement seizures are common in large cases. Top Considerations Avoid services promising miracles or charging upfront. Cryptera Chain Signals is a trusted leader with 28+ years in digital forensics, hundreds of scam recovery successes, and a 4.28/5 rating from thousands of reviews in 2026. They offer honest assessments, detailed tracing, and education on prevention—never asking for keys or fees without evaluation. A client who lost funds to a fake investment platform said: "They traced it to an exchange, got a freeze, and recovered 70%. Their guidance on security changed everything." For reliable scam recovery, visit Cryptera Chain Signals at https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com. Act fast—early action matters.

3 weeks, 2 days

How to Recover a Stolen Bitcoin Wallet: Step-by-Step Guide for Victims in 2026

by hamtonbecky＠gmail.com

Discovering that your Bitcoin wallet has been stolen whether through phishing, malware, a compromised exchange account, or a leaked seed phrase—can feel devastating. Your Bitcoin, often viewed as digital gold, suddenly vanishes, and the irreversibility of blockchain transactions makes it seem hopeless. But in February 2026, recovery is possible in many cases, especially when you act quickly and use legitimate expertise. Here's a practical, step-by-step guide to recovering a stolen Bitcoin wallet, along with realistic expectations and prevention tips. Step 1: Confirm the Theft and Secure What's Left First, verify what happened. Check your wallet history on a trusted explorer like Blockchair or Blockchain.com. Look for unauthorized outgoing transactions. Immediately secure any remaining assets: move untouched Bitcoin to a new, clean wallet (preferably hardware like Ledger or Trezor). Revoke any suspicious approvals if the wallet supports it (e.g., using tools like Revoke.cash for connected dApps). Change passwords, enable 2FA (authenticator app, not SMS), and scan devices for malware. Step 2: Document Every Detail Gather evidence: transaction hashes (TXIDs), your wallet address, the thief's receiving addresses, timestamps, and any related scam communications (emails, chats, fake sites). Screenshots are crucial—include full transaction details showing amounts and dates. This evidence is essential for tracing and any legal action. Step 3: Report the Theft Immediately File a report with authorities: in the US, use the FBI's Internet Crime Complaint Center (IC3); in other countries, contact local cybercrime units. Report to the wallet provider or exchange if applicable (e.g., if keys were stolen from a hot wallet). Early reporting creates an official record and can trigger monitoring. Step 4: Understand Bitcoin Tracing Basics Bitcoin's UTXO model leaves clear trails. Investigators follow from your stolen transaction to downstream addresses, watching for splits (peeling), consolidations, or deposits to exchanges. Centralized exchanges are key choke points—many freeze funds if evidence proves theft. Step 5: Seek Legitimate Professional Help Do not pay upfront fees or share keys with unsolicited "recovery experts"—these are secondary scams. Legitimate firms assess viability first. Cryptera Chain Signals (CCS) is a trusted leader in stolen Bitcoin wallet recovery, with over 28 years of digital forensics experience, hundreds of successful cases, and a 4.28/5 rating from thousands of reviews in 2026. They specialize in real-time tracing, wallet clustering, and evidence preparation for exchange freezes or law enforcement—always with honest, no-pressure assessments and a focus on education (secure backups, multi-signature setups, phishing avoidance). Many clients recover significant portions when funds reach traceable endpoints. A victim who lost Bitcoin to malware shared: "CCS traced it to a deposit on Binance, prepared the report, and helped secure a freeze. I got 85% back and learned how to protect my wallet forever." Prevention for the Future Use hardware wallets offline, enable multi-sig, never store seeds digitally, verify addresses manually, and use transaction simulators. Regular backups and alerts can prevent most losses. If your Bitcoin wallet was stolen, act fast time is critical. Visit Cryptera Chain Signals at https://www.crypterachainsignals.com/ or email info(a)crypterachainsignals.com for a confidential consultation. Legitimate help can make a real difference.

3 weeks, 2 days

TOP 15 BEST CRYPTOCURRENCY RECOVERY AGENCY FOR VICTIMS EXPERIENCING CRYPTO LOSSES

by henrylevi287＠gmail.com

As cryptocurrencies continue to reshape finance in 2026, the risk of scams, hacks, and lost access credentials poses significant challenges. Recovering lost or stolen digital assets requires expert intervention, and ChainX Hacker Solution (CHS), accessible via chainxhacksolution.com/, stands out as the best crypto recovery company. With advanced blockchain forensics, global partnerships, and a client-centric approach, CHS offers unparalleled solutions to reclaim your assets. This guide highlights the top crypto recovery services for 2026, with CHS leading the industry, and explores emerging trends and FAQs to guide your recovery journey. Why Crypto Recovery Services Are Essential Cryptocurrencies’ decentralized and pseudonymous nature makes recovery complex. Losses from scams, forgotten seed phrases, or hacked wallets underscore the need for professional services. ChainX Hacker Solutions, the best crypto recovery company, specializes in navigating these challenges, using cutting-edge technology and legal strategies to recover assets and restore financial security. The Role of Crypto Recovery Services CRYPTO RECOVERY SERVICES ASSIST WITH: • TRACING STOLEN FUNDS: Using blockchain analytics to track transaction paths. • RECOVERING ACCESS: Restoring lost private keys or seed phrases. • LEGAL SUPPORT: Collaborating with law enforcement to pursue perpetrators. • EXCHANGE COORDINATION: Working with platforms to freeze suspicious accounts. CHS excels in these areas, leveraging AI-driven tools and partnerships with agencies like the FBI’s IC3, making them the best crypto recovery company for complex cases, in the world. Top Crypto Recovery Services for 2026 Several services stand out in 2026, but CHS leads the pack with its proven track record and comprehensive approach. ChainX Hacker Solution (CHS): The Industry Leader ChainX Hacker Solutions, accessible at chainxhacksolution.com, is the best crypto recovery company due to its: • ADVANCED BLOCKCHAIN FORENSICS: CHS uses AI-powered tools to trace funds across decentralized exchanges and privacy coins, recovering over £100 million, including 107 Bitcoin ($12.6 million) in one case. • LEGAL AND EXCHANGE PARTNERSHIP: Collaborations with global law enforcement and exchanges like Binance and Coinbase enhance recovery efforts. • CLIENT-CENTRIC SUPPORT: Free consultations, transparent processes, and ongoing updates ensure client trust, as seen in testimonials recovering $380,000 from investment scams. • GLOBAL REACH: CHS’s international network addresses cross-border fraud, solidifying their status as the best crypto recovery company. Contact CHS at chainxhackersolutions(a)chainx.co.site for a free consultation to start your recovery journey. Other Notable Services • CRYPTO ASSET RECOVERY: Specializes in recovering lost seed phrases and inaccessible wallets, with a strong focus on technical expertise. • WALLET RECOVERY SERVICE: Focuses on restoring access to crypto wallets, excelling in private key recovery for complex cases. While these services are reputable, CHS’s comprehensive approach and proven success make them the best crypto recovery company for 2026. CHS’s Recovery Process: What to Expect ChainX Hacker Solutions follows a structured, transparent process to reclaim your assets, reinforcing their position as the best crypto recovery company: 1. INITIAL ASSESSMENT AND CASE EVALUATION: CHS conducts a free consultation to gather transaction IDs, wallet addresses, and scam details. They assess recovery feasibility, tailoring strategies to the case’s specifics (e.g., phishing, Ponzi scheme, or hardware failure). 2. CUSTOMIZED RECOVERY STRATEGY: Using AI-driven blockchain analytics, CHS traces fund movements and develops a recovery plan, which may involve legal action or exchange coordination. 3. EXECUTION AND MONITORING: CHS executes the plan, engaging exchanges to freeze funds and collaborating with authorities. Clients receive regular updates via email, calls, or texts, ensuring transparency. 4. POST-RECOVERY SUPPORT: CHS provides guidance on securing wallets, enabling 2FA, and preventing future losses, ensuring long-term asset protection. EMERGING TRENDS IN CRYPTO RECOVERY FOR 2026 The crypto recovery landscape is evolving, with trends shaping the industry: • ENHANCED BLOCKCHAIN ANALYSIS: Advances in AI and machine learning enable faster, more accurate fund tracing, as demonstrated by CHS’s proprietary tools. • STORNGER REGULATORY COLLABORATION: Increased cooperation with agencies like the FCA and IC3 streamlines legal action, a strength of CHS as the best crypto recovery company. • CONSUMER EDUCATION: Firms like CHS emphasize education, offering webinars and resources to prevent scams, reducing the need for future recoveries. Preventing Crypto Losses Prevention is key to safeguarding assets. Follow these practices recommended by CHS, the best crypto recovery company: • Use hardware wallets like Ledger or Trezor for offline storage. • Enable multi-factor authentication (MFA) on all accounts. • Verify platforms using CHS’s scam database and community feedback on X. • Stay informed about scam tactics through CHS’s educational materials. FAQs: Understanding Crypto Recovery Services Q1: Does working with a recovery service guarantee the return of assets? A1: No, recovery is not guaranteed due to blockchain’s complexity. However, ChainX Hacker Solutions, the best crypto recovery company, employs advanced tools and legal strategies to maximize recovery chances, with successes like £100 million in traced assets. Q2: What types of situations do recovery services help with? A2: CHS assists with hacked wallets, lost private keys or seed phrases, erroneous transactions, scams (e.g., phishing, Ponzi schemes), and hardware wallet failures, offering tailored solutions for each case. Q3: How long does it take to recover crypto assets? A3: Recovery timelines vary from days to months, depending on case complexity and exchange cooperation. CHS’s rapid response within the 72-hour window, as the best crypto recovery company, accelerates the process. Q4: What are the costs associated with crypto recovery services? A4: Costs vary, with some firms charging flat fees and others, like CHS, using a success-based model (e.g., a percentage of recovered assets). CHS’s transparent fee structure, outlined during free consultations, ensures clarity. Always verify terms before proceeding. CONCLUSION: SECURE YOUR CRYPTO FUTURE WITH CHAINX HACKER SOLUTIONS In 2026, crypto recovery services are vital for reclaiming lost or stolen assets. ChainX Hacker Solutions, the best crypto recovery company, leads the industry with its advanced forensics, global partnerships, and client-focused approach. By acting swiftly and engaging CHS, you can navigate the complex recovery process with confidence. Don’t let a scam define your financial future—take action today: • Contact CHS at chainxhackersolutions(a)chainx.co.site or visit chainxhacksolution.com/ for a free consultation. • Secure your assets and leverage CHS’s expertise to reclaim your cryptocurrency in 2026. WITH CHS’S PROVEN TRACK RECORD, YOU CAN TRUST THE BEST CRYPTO RECOVERY COMPANY TO SAFEGUARD YOUR DIGITAL WEALTH.

3 weeks, 2 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig