Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

10 participants
5189 discussions

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 >

2 days, 23 hours

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 days, 3 hours

Re: [PATCH v2 0/3] dma-buf: heaps: cma: enable dmem cgroup accounting

by Christian König

On 2/24/26 10:43, Maxime Ripard wrote: > Hi Christian, > > On Fri, Feb 20, 2026 at 10:45:08AM +0100, Christian König wrote: >> On 2/20/26 02:14, T.J. Mercier wrote: >>> On Wed, Feb 18, 2026 at 9:15 AM Eric Chanudet <echanude(a)redhat.com> wrote: >>> >>> Hi Eric, >>> >>>> An earlier series[1] from Maxime introduced dmem to the cma allocator in >>>> an attempt to use it generally for dma-buf. Restart from there and apply >>>> the charge in the narrower context of the CMA dma-buf heap instead. >>>> >>>> In line with introducing cgroup to the system heap[2], this behavior is >>>> enabled based on dma_heap.mem_accounting, disabled by default. >>>> >>>> dmem is chosen for CMA heaps as it allows limits to be set for each >>>> region backing each heap. The charge is only put in the dma-buf heap for >>>> now as it guaranties it can be accounted against a userspace process >>>> that requested the allocation. >>> >>> But CMA memory is system memory, and regular (non-CMA) movable >>> allocations can occur out of these CMA areas. So this splits system >>> memory accounting between memcg (from [2]) and dmem. If I want to put >>> a limit on system memory use I have to adjust multiple limits (memcg + >>> dmems) and know how to divide the total between them all. >>> >>> How do you envision using this combination of different controllers? >> >> Yeah we have this problem pretty much everywhere. >> >> There are both use cases where you want to account device allocations >> to memcg and when you don't want that. >> >> From what I know at the moment it would be best if the administrator >> could say for each dmem if it should account additionally to memcg or >> not. >> >> Using module parameters to enable/disable it globally is just a >> workaround as far as I can see. > > That's a pretty good idea! It would indeed be a solution that could > satisfy everyone (I assume?). I think so yeah. From what I have seen we have three different use cases: 1. local device memory (VRAM), GTT/CMA and memcg are completely separate domains and you want to have completely separate values as limit for them. 2. local device memory (VRAM) is separate. GTT/CMA are accounted to memcg, you can still have separate values as limit so that nobody over allocates CMA (for example). 3. All three are accounted to memcg because system memory is actually used as fallback if applications over allocate device local memory. It's debatable what should be the default, but we clearly need to handle all three use cases. Potentially even on the same system. Regards, Christian. > > Maxime

3 days, 3 hours

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 days, 4 hours

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 days, 4 hours

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 days, 4 hours

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 days, 4 hours

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 days, 4 hours

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 days, 4 hours

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 days, 6 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig