Linaro-mm-sig April 2026

linaro-mm-sig@lists.linaro.org

70 participants
62 discussions

[PATCH v6 6/8] drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_ttm_clear_buffer

by Pierre-Eric Pelloux-Prayer

This is the only use case for this function. --- v2: amdgpu_ttm_clear_buffer instead of amdgpu_clear_buffer --- Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 12 +++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 ++++++++++------------ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 13 ++++++------ 3 files changed, 22 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index bdeca80cd77d..4dd7c712b8c3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -717,9 +717,9 @@ int amdgpu_bo_create(struct amdgpu_device *adev, bo->tbo.resource->mem_type == TTM_PL_VRAM) { struct dma_fence *fence; - r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), - bo, 0, bo->tbo.base.resv, &fence, - true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); + r = amdgpu_ttm_clear_buffer(amdgpu_ttm_next_clear_entity(adev), + bo, bo->tbo.base.resv, &fence, + true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); if (unlikely(r)) goto fail_unreserve; @@ -1329,9 +1329,9 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) if (r) goto out; - r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), - abo, 0, &bo->base._resv, &fence, - false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); + r = amdgpu_ttm_clear_buffer(amdgpu_ttm_next_clear_entity(adev), + abo, &bo->base._resv, &fence, + false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); if (WARN_ON(r)) goto out; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 7af11623263d..8d778cbce1aa 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -417,8 +417,8 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo, if (old_mem->mem_type == TTM_PL_VRAM && (abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE)) { struct dma_fence *wipe_fence = NULL; - r = amdgpu_fill_buffer(entity, abo, 0, NULL, &wipe_fence, - false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); + r = amdgpu_ttm_clear_buffer(entity, abo, NULL, &wipe_fence, + false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); if (r) { goto error; } else if (wipe_fence) { @@ -2573,26 +2573,23 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_device *adev, } /** - * amdgpu_fill_buffer - fill a buffer with a given value + * amdgpu_ttm_clear_buffer - fill a buffer with 0 * @entity: entity to use * @bo: the bo to fill - * @src_data: the value to set * @resv: fences contained in this reservation will be used as dependencies. * @out_fence: the fence from the last clear will be stored here. It might be * NULL if no job was run. - * @dependency: optional input dependency fence. * @consider_clear_status: true if region reported as cleared by amdgpu_res_cleared() * are skipped. * @k_job_id: trace id * */ -int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, - struct amdgpu_bo *bo, - uint32_t src_data, - struct dma_resv *resv, - struct dma_fence **out_fence, - bool consider_clear_status, - u64 k_job_id) +int amdgpu_ttm_clear_buffer(struct amdgpu_ttm_buffer_entity *entity, + struct amdgpu_bo *bo, + struct dma_resv *resv, + struct dma_fence **out_fence, + bool consider_clear_status, + u64 k_job_id) { struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); struct dma_fence *fence = NULL; @@ -2623,7 +2620,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, goto error; r = amdgpu_ttm_fill_mem(adev, entity, - src_data, to, cur_size, resv, + 0, to, cur_size, resv, &next, true, k_job_id); if (r) goto error; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index 436a3e09a178..d7b14d5cac77 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -187,13 +187,12 @@ int amdgpu_copy_buffer(struct amdgpu_device *adev, struct dma_resv *resv, struct dma_fence **fence, bool vm_needs_flush, uint32_t copy_flags); -int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, - struct amdgpu_bo *bo, - uint32_t src_data, - struct dma_resv *resv, - struct dma_fence **out_fence, - bool consider_clear_status, - u64 k_job_id); +int amdgpu_ttm_clear_buffer(struct amdgpu_ttm_buffer_entity *entity, + struct amdgpu_bo *bo, + struct dma_resv *resv, + struct dma_fence **out_fence, + bool consider_clear_status, + u64 k_job_id); struct amdgpu_ttm_buffer_entity *amdgpu_ttm_next_clear_entity(struct amdgpu_device *adev); int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); -- 2.43.0

6 months, 3 weeks

[PATCH v6 5/8] drm/amdgpu: get rid of amdgpu_ttm_clear_buffer

by Pierre-Eric Pelloux-Prayer

It's doing the same thing as amdgpu_fill_buffer(src_data=0), so drop it. The only caveat is that amdgpu_res_cleared() return value is only valid right after allocation. --- v2: introduce new "bool consider_clear_status" arg v6: dont pass a NULL resv when calling amdgpu_fill_buffer from amdgpu_bo_create --- Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 88 +++++----------------- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 6 +- 3 files changed, 32 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 66c20dd46d12..bdeca80cd77d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -717,13 +717,17 @@ int amdgpu_bo_create(struct amdgpu_device *adev, bo->tbo.resource->mem_type == TTM_PL_VRAM) { struct dma_fence *fence; - r = amdgpu_ttm_clear_buffer(bo, bo->tbo.base.resv, &fence); + r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), + bo, 0, bo->tbo.base.resv, &fence, + true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); if (unlikely(r)) goto fail_unreserve; - dma_resv_add_fence(bo->tbo.base.resv, fence, - DMA_RESV_USAGE_KERNEL); - dma_fence_put(fence); + if (fence) { + dma_resv_add_fence(bo->tbo.base.resv, fence, + DMA_RESV_USAGE_KERNEL); + dma_fence_put(fence); + } } if (!bp->resv) amdgpu_bo_unreserve(bo); @@ -1326,8 +1330,8 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) goto out; r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), - abo, 0, &bo->base._resv, - &fence, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); + abo, 0, &bo->base._resv, &fence, + false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); if (WARN_ON(r)) goto out; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 7b92f240eea7..7af11623263d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -418,7 +418,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo, (abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE)) { struct dma_fence *wipe_fence = NULL; r = amdgpu_fill_buffer(entity, abo, 0, NULL, &wipe_fence, - AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); + false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); if (r) { goto error; } else if (wipe_fence) { @@ -2573,76 +2573,25 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_device *adev, } /** - * amdgpu_ttm_clear_buffer - clear memory buffers - * @bo: amdgpu buffer object - * @resv: reservation object - * @fence: dma_fence associated with the operation + * amdgpu_fill_buffer - fill a buffer with a given value + * @entity: entity to use + * @bo: the bo to fill + * @src_data: the value to set + * @resv: fences contained in this reservation will be used as dependencies. + * @out_fence: the fence from the last clear will be stored here. It might be + * NULL if no job was run. + * @dependency: optional input dependency fence. + * @consider_clear_status: true if region reported as cleared by amdgpu_res_cleared() + * are skipped. + * @k_job_id: trace id * - * Clear the memory buffer resource. - * - * Returns: - * 0 for success or a negative error code on failure. */ -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, - struct dma_resv *resv, - struct dma_fence **fence) -{ - struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); - struct amdgpu_ttm_buffer_entity *entity; - struct amdgpu_res_cursor cursor; - u64 addr; - int r = 0; - - if (!adev->mman.buffer_funcs_enabled) - return -EINVAL; - - if (!fence) - return -EINVAL; - entity = &adev->mman.clear_entities[0]; - *fence = dma_fence_get_stub(); - - amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &cursor); - - mutex_lock(&entity->lock); - while (cursor.remaining) { - struct dma_fence *next = NULL; - u64 size; - - if (amdgpu_res_cleared(&cursor)) { - amdgpu_res_next(&cursor, cursor.size); - continue; - } - - /* Never clear more than 256MiB at once to avoid timeouts */ - size = min(cursor.size, 256ULL << 20); - - r = amdgpu_ttm_map_buffer(entity, &bo->tbo, bo->tbo.resource, &cursor, - 0, false, &size, &addr); - if (r) - goto err; - - r = amdgpu_ttm_fill_mem(adev, entity, 0, addr, size, resv, - &next, true, - AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); - if (r) - goto err; - - dma_fence_put(*fence); - *fence = next; - - amdgpu_res_next(&cursor, size); - } -err: - mutex_unlock(&entity->lock); - - return r; -} - int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct amdgpu_bo *bo, uint32_t src_data, struct dma_resv *resv, - struct dma_fence **f, + struct dma_fence **out_fence, + bool consider_clear_status, u64 k_job_id) { struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); @@ -2660,6 +2609,11 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct dma_fence *next; uint64_t cur_size, to; + if (consider_clear_status && amdgpu_res_cleared(&dst)) { + amdgpu_res_next(&dst, dst.size); + continue; + } + /* Never fill more than 256MiB at once to avoid timeouts */ cur_size = min(dst.size, 256ULL << 20); @@ -2681,9 +2635,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, } error: mutex_unlock(&entity->lock); - if (f) - *f = dma_fence_get(fence); - dma_fence_put(fence); + *out_fence = fence; return r; } diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index a6249252948b..436a3e09a178 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -187,14 +187,12 @@ int amdgpu_copy_buffer(struct amdgpu_device *adev, struct dma_resv *resv, struct dma_fence **fence, bool vm_needs_flush, uint32_t copy_flags); -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, - struct dma_resv *resv, - struct dma_fence **fence); int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct amdgpu_bo *bo, uint32_t src_data, struct dma_resv *resv, - struct dma_fence **f, + struct dma_fence **out_fence, + bool consider_clear_status, u64 k_job_id); struct amdgpu_ttm_buffer_entity *amdgpu_ttm_next_clear_entity(struct amdgpu_device *adev); -- 2.43.0

6 months, 3 weeks

[PATCH v5 6/7] drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_ttm_clear_buffer

by Pierre-Eric Pelloux-Prayer

This is the only use case for this function. --- v2: amdgpu_ttm_clear_buffer instead of amdgpu_clear_buffer --- Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 12 +++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 ++++++++++------------ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 13 ++++++------ 3 files changed, 22 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index d0884bbffa75..195cb1c814d1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -717,9 +717,9 @@ int amdgpu_bo_create(struct amdgpu_device *adev, bo->tbo.resource->mem_type == TTM_PL_VRAM) { struct dma_fence *fence; - r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), - bo, 0, NULL, &fence, - true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); + r = amdgpu_ttm_clear_buffer(amdgpu_ttm_next_clear_entity(adev), + bo, NULL, &fence, + true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); if (unlikely(r)) goto fail_unreserve; @@ -1329,9 +1329,9 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) if (r) goto out; - r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), - abo, 0, &bo->base._resv, &fence, - false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); + r = amdgpu_ttm_clear_buffer(amdgpu_ttm_next_clear_entity(adev), + abo, &bo->base._resv, &fence, + false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); if (WARN_ON(r)) goto out; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index a3d0998b8cec..e74f9f8a88dc 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -417,8 +417,8 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo, if (old_mem->mem_type == TTM_PL_VRAM && (abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE)) { struct dma_fence *wipe_fence = NULL; - r = amdgpu_fill_buffer(entity, abo, 0, NULL, &wipe_fence, - false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); + r = amdgpu_ttm_clear_buffer(entity, abo, NULL, &wipe_fence, + false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); if (r) { goto error; } else if (wipe_fence) { @@ -2572,26 +2572,23 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_device *adev, } /** - * amdgpu_fill_buffer - fill a buffer with a given value + * amdgpu_ttm_clear_buffer - fill a buffer with 0 * @entity: entity to use * @bo: the bo to fill - * @src_data: the value to set * @resv: fences contained in this reservation will be used as dependencies. * @out_fence: the fence from the last clear will be stored here. It might be * NULL if no job was run. - * @dependency: optional input dependency fence. * @consider_clear_status: true if region reported as cleared by amdgpu_res_cleared() * are skipped. * @k_job_id: trace id * */ -int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, - struct amdgpu_bo *bo, - uint32_t src_data, - struct dma_resv *resv, - struct dma_fence **out_fence, - bool consider_clear_status, - u64 k_job_id) +int amdgpu_ttm_clear_buffer(struct amdgpu_ttm_buffer_entity *entity, + struct amdgpu_bo *bo, + struct dma_resv *resv, + struct dma_fence **out_fence, + bool consider_clear_status, + u64 k_job_id) { struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); struct dma_fence *fence = NULL; @@ -2622,7 +2619,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, goto error; r = amdgpu_ttm_fill_mem(adev, entity, - src_data, to, cur_size, resv, + 0, to, cur_size, resv, &next, true, k_job_id); if (r) goto error; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index 436a3e09a178..d7b14d5cac77 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -187,13 +187,12 @@ int amdgpu_copy_buffer(struct amdgpu_device *adev, struct dma_resv *resv, struct dma_fence **fence, bool vm_needs_flush, uint32_t copy_flags); -int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, - struct amdgpu_bo *bo, - uint32_t src_data, - struct dma_resv *resv, - struct dma_fence **out_fence, - bool consider_clear_status, - u64 k_job_id); +int amdgpu_ttm_clear_buffer(struct amdgpu_ttm_buffer_entity *entity, + struct amdgpu_bo *bo, + struct dma_resv *resv, + struct dma_fence **out_fence, + bool consider_clear_status, + u64 k_job_id); struct amdgpu_ttm_buffer_entity *amdgpu_ttm_next_clear_entity(struct amdgpu_device *adev); int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); -- 2.43.0

6 months, 3 weeks

[PATCH v5 5/7] drm/amdgpu: get rid of amdgpu_ttm_clear_buffer

by Pierre-Eric Pelloux-Prayer

It's doing the same thing as amdgpu_fill_buffer(src_data=0), so drop it. The only caveat is that amdgpu_res_cleared() return value is only valid right after allocation. --- v2: introduce new "bool consider_clear_status" arg --- Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 88 +++++----------------- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 6 +- 3 files changed, 32 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 66c20dd46d12..d0884bbffa75 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -717,13 +717,17 @@ int amdgpu_bo_create(struct amdgpu_device *adev, bo->tbo.resource->mem_type == TTM_PL_VRAM) { struct dma_fence *fence; - r = amdgpu_ttm_clear_buffer(bo, bo->tbo.base.resv, &fence); + r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), + bo, 0, NULL, &fence, + true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); if (unlikely(r)) goto fail_unreserve; - dma_resv_add_fence(bo->tbo.base.resv, fence, - DMA_RESV_USAGE_KERNEL); - dma_fence_put(fence); + if (fence) { + dma_resv_add_fence(bo->tbo.base.resv, fence, + DMA_RESV_USAGE_KERNEL); + dma_fence_put(fence); + } } if (!bp->resv) amdgpu_bo_unreserve(bo); @@ -1326,8 +1330,8 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) goto out; r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), - abo, 0, &bo->base._resv, - &fence, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); + abo, 0, &bo->base._resv, &fence, + false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); if (WARN_ON(r)) goto out; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 648ad344e89c..a3d0998b8cec 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -418,7 +418,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo, (abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE)) { struct dma_fence *wipe_fence = NULL; r = amdgpu_fill_buffer(entity, abo, 0, NULL, &wipe_fence, - AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); + false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); if (r) { goto error; } else if (wipe_fence) { @@ -2572,76 +2572,25 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_device *adev, } /** - * amdgpu_ttm_clear_buffer - clear memory buffers - * @bo: amdgpu buffer object - * @resv: reservation object - * @fence: dma_fence associated with the operation + * amdgpu_fill_buffer - fill a buffer with a given value + * @entity: entity to use + * @bo: the bo to fill + * @src_data: the value to set + * @resv: fences contained in this reservation will be used as dependencies. + * @out_fence: the fence from the last clear will be stored here. It might be + * NULL if no job was run. + * @dependency: optional input dependency fence. + * @consider_clear_status: true if region reported as cleared by amdgpu_res_cleared() + * are skipped. + * @k_job_id: trace id * - * Clear the memory buffer resource. - * - * Returns: - * 0 for success or a negative error code on failure. */ -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, - struct dma_resv *resv, - struct dma_fence **fence) -{ - struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); - struct amdgpu_ttm_buffer_entity *entity; - struct amdgpu_res_cursor cursor; - u64 addr; - int r = 0; - - if (!adev->mman.buffer_funcs_enabled) - return -EINVAL; - - if (!fence) - return -EINVAL; - entity = &adev->mman.clear_entities[0]; - *fence = dma_fence_get_stub(); - - amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &cursor); - - mutex_lock(&entity->lock); - while (cursor.remaining) { - struct dma_fence *next = NULL; - u64 size; - - if (amdgpu_res_cleared(&cursor)) { - amdgpu_res_next(&cursor, cursor.size); - continue; - } - - /* Never clear more than 256MiB at once to avoid timeouts */ - size = min(cursor.size, 256ULL << 20); - - r = amdgpu_ttm_map_buffer(entity, &bo->tbo, bo->tbo.resource, &cursor, - 0, false, &size, &addr); - if (r) - goto err; - - r = amdgpu_ttm_fill_mem(adev, entity, 0, addr, size, resv, - &next, true, - AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); - if (r) - goto err; - - dma_fence_put(*fence); - *fence = next; - - amdgpu_res_next(&cursor, size); - } -err: - mutex_unlock(&entity->lock); - - return r; -} - int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct amdgpu_bo *bo, uint32_t src_data, struct dma_resv *resv, - struct dma_fence **f, + struct dma_fence **out_fence, + bool consider_clear_status, u64 k_job_id) { struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); @@ -2659,6 +2608,11 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct dma_fence *next; uint64_t cur_size, to; + if (consider_clear_status && amdgpu_res_cleared(&dst)) { + amdgpu_res_next(&dst, dst.size); + continue; + } + /* Never fill more than 256MiB at once to avoid timeouts */ cur_size = min(dst.size, 256ULL << 20); @@ -2680,9 +2634,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, } error: mutex_unlock(&entity->lock); - if (f) - *f = dma_fence_get(fence); - dma_fence_put(fence); + *out_fence = fence; return r; } diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index a6249252948b..436a3e09a178 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -187,14 +187,12 @@ int amdgpu_copy_buffer(struct amdgpu_device *adev, struct dma_resv *resv, struct dma_fence **fence, bool vm_needs_flush, uint32_t copy_flags); -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, - struct dma_resv *resv, - struct dma_fence **fence); int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct amdgpu_bo *bo, uint32_t src_data, struct dma_resv *resv, - struct dma_fence **f, + struct dma_fence **out_fence, + bool consider_clear_status, u64 k_job_id); struct amdgpu_ttm_buffer_entity *amdgpu_ttm_next_clear_entity(struct amdgpu_device *adev); -- 2.43.0

6 months, 3 weeks

[PATCH] dma-buf: heaps: system: document system_cc_shared heap

by Jiri Pirko

From: Jiri Pirko <jiri(a)nvidia.com> Document the system_cc_shared dma-buf heap that was introduced recently. Describe its purpose, availability conditions and relation to confidential computing VMs. Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> --- Documentation/userspace-api/dma-buf-heaps.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst index 05445c83b79a..591732393e7d 100644 --- a/Documentation/userspace-api/dma-buf-heaps.rst +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -16,6 +16,14 @@ following heaps: - The ``system`` heap allocates virtually contiguous, cacheable, buffers. + - The ``system_cc_shared`` heap allocates virtually contiguous, cacheable, + buffers using shared (decrypted) memory. It is only present on + confidential computing (CoCo) VMs where memory encryption is active + (e.g., AMD SEV, Intel TDX). The allocated pages have the encryption + bit cleared, making them accessible for device DMA without TDISP + support. On non-CoCo VMs configurations, this heap is + not registered. + - The ``default_cma_region`` heap allocates physically contiguous, cacheable, buffers. Only present if a CMA region is present. Such a region is usually created either through the kernel commandline -- 2.51.1

6 months, 3 weeks

Expertise in Recovery

by penelopestaunton931＠gmail.com

Safeguard is not just another name in the crowded field of cryptocurrency recovery; they are renowned for their effectiveness and expertise in tracing lost funds. Their team comprises skilled professionals who understand the intricate workings of blockchain technology and the tactics employed by online scammers. This specialized knowledge enables them to devise tailored strategies to recover your assets. Email,.. safeguardbitcoin(a)consultant.com WhatsApp,.. +44 7426 168300 Web:., https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

6 months, 4 weeks

Re: [PATCH 1/7] drm/shmem-helper: Add lockdep asserts to vmap/vunmap

by Bence Csókás

Hi, I just came across this commit while researching something else. Original patch had too few context lines, so I here's the diff with `-U10`. On 3/18/25 20:22, Daniel Almeida wrote: > From: Asahi Lina <lina(a)asahilina.net> > > Since commit 21aa27ddc582 ("drm/shmem-helper: Switch to reservation > lock"), the drm_gem_shmem_vmap and drm_gem_shmem_vunmap functions > require that the caller holds the DMA reservation lock for the object. > Add lockdep assertions to help validate this. There were already lockdep assertions... > Signed-off-by: Asahi Lina <lina(a)asahilina.net> > Signed-off-by: Daniel Almeida <daniel.almeida(a)collabora.com> > Reviewed-by: Christian König <christian.koenig(a)amd.com> > Signed-off-by: Lyude Paul <lyude(a)redhat.com> > Link: https://lore.kernel.org/r/20250318-drm-gem-shmem-v1-1-64b96511a84f@collabor… > --- > drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c > index aa43265f4f4f..0b41f0346bad 100644 > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > @@ -341,20 +341,22 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin); > * > * Returns: > * 0 on success or a negative error code on failure. > */ > int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, > struct iosys_map *map) > { > struct drm_gem_object *obj = &shmem->base; > int ret = 0; > > + dma_resv_assert_held(obj->resv); > + > if (drm_gem_is_imported(obj)) { > ret = dma_buf_vmap(obj->dma_buf, map); > } else { > pgprot_t prot = PAGE_KERNEL; > > dma_resv_assert_held(shmem->base.resv); ... right here, and > if (refcount_inc_not_zero(&shmem->vmap_use_count)) { > iosys_map_set_vaddr(map, shmem->vaddr); > return 0; > @@ -401,20 +403,22 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_vmap_locked); > * drops to zero. > * > * This function hides the differences between dma-buf imported and natively > * allocated objects. > */ > void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem, > struct iosys_map *map) > { > struct drm_gem_object *obj = &shmem->base; > > + dma_resv_assert_held(obj->resv); > + > if (drm_gem_is_imported(obj)) { > dma_buf_vunmap(obj->dma_buf, map); > } else { > dma_resv_assert_held(shmem->base.resv); ...here. > if (refcount_dec_and_test(&shmem->vmap_use_count)) { > vunmap(shmem->vaddr); > shmem->vaddr = NULL; > > drm_gem_shmem_unpin_locked(shmem); Or were those insufficient for some reason? If so, should we keep both of them, or should the older ones have been removed? Bence

7 months

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

by Maxime Ripard

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

7 months

[PATCH V2] i2c: qcom-geni: Avoid extra TX DMA TRE for single read message in GPI mode

by Aniket Randive

In GPI mode, the I2C GENI driver programs an extra TX DMA transfer descriptor (TRE) on the TX channel when handling a single read message. This results in an unintended write phase being issued on the I2C bus, even though a read transaction does not require any TX data. For a single-byte read, the correct hardware sequence consists of the CONFIG and GO commands followed by a single RX DMA TRE. Programming an additional TX DMA TRE is redundant, causes unnecessary DMA buffer mapping on the TX channel, and may lead to incorrect bus behavior. Update the transfer logic to avoid programming a TX DMA TRE for single read messages in GPI mode. Co-developed-by: Maramaina Naresh <naresh.maramaina(a)oss.qualcomm.com> Signed-off-by: Maramaina Naresh <naresh.maramaina(a)oss.qualcomm.com> Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- Changes in v2: - Updated the commit message. drivers/i2c/busses/i2c-qcom-geni.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index a4acb78fafb6..2706309bbebb 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -625,8 +625,8 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], { struct gpi_i2c_config *peripheral; unsigned int flags; - void *dma_buf; - dma_addr_t addr; + void *dma_buf = NULL; + dma_addr_t addr = 0; enum dma_data_direction map_dirn; enum dma_transfer_direction dma_dirn; struct dma_async_tx_descriptor *desc; @@ -639,6 +639,11 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], gi2c_gpi_xfer = &gi2c->i2c_multi_desc_config; msg_idx = gi2c_gpi_xfer->msg_idx_cnt; + if (op == I2C_WRITE && msgs[msg_idx].flags & I2C_M_RD) { + peripheral->multi_msg = true; + goto skip_dma; + } + dma_buf = i2c_get_dma_safe_msg_buf(&msgs[msg_idx], 1); if (!dma_buf) { ret = -ENOMEM; @@ -668,6 +673,7 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK; } +skip_dma: /* set the length as message for rx txn */ peripheral->rx_len = msgs[msg_idx].len; peripheral->op = op; @@ -740,9 +746,11 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], return 0; err_config: - dma_unmap_single(gi2c->se.dev->parent, addr, - msgs[msg_idx].len, map_dirn); - i2c_put_dma_safe_msg_buf(dma_buf, &msgs[msg_idx], false); + if (op == I2C_WRITE && (msgs[msg_idx].flags & I2C_M_RD)) { + dma_unmap_single(gi2c->se.dev->parent, addr, + msgs[msg_idx].len, map_dirn); + i2c_put_dma_safe_msg_buf(dma_buf, &msgs[msg_idx], false); + } out: gi2c->err = ret; -- 2.34.1

7 months

[PATCH RFC 00/18] accel/qda: Introduce Qualcomm DSP Accelerator driver

by Ekansh Gupta

This patch series introduces the Qualcomm DSP Accelerator (QDA) driver, a modern DRM-based accelerator implementation for Qualcomm Hexagon DSPs. The driver provides a standardized interface for offloading computational tasks to DSPs found on Qualcomm SoCs, supporting all DSP domains (ADSP, CDSP, SDSP, GDSP). The QDA driver is designed as an alternative for the FastRPC driver in drivers/misc/, offering improved resource management, better integration with standard kernel subsystems, and alignment with the Linux kernel's Compute Accelerators framework. User-space staging branch ============ https://github.com/qualcomm/fastrpc/tree/accel/staging Key Features ============ * Standard DRM accelerator interface via /dev/accel/accelN * GEM-based buffer management with DMA-BUF import/export support * IOMMU-based memory isolation using per-process context banks * FastRPC protocol implementation for DSP communication * RPMsg transport layer for reliable message passing * Support for all DSP domains (ADSP, CDSP, SDSP, GDSP) * Comprehensive IOCTL interface for DSP operations High-Level Architecture Differences with Existing FastRPC Driver ================================================================= The QDA driver represents a significant architectural departure from the existing FastRPC driver (drivers/misc/fastrpc.c), addressing several key limitations while maintaining protocol compatibility: 1. DRM Accelerator Framework Integration - FastRPC: Custom character device (/dev/fastrpc-*) - QDA: Standard DRM accel device (/dev/accel/accelN) - Benefit: Leverages established DRM infrastructure for device management. 2. Memory Management - FastRPC: Custom memory allocator with ION/DMA-BUF integration - QDA: Native GEM objects with full PRIME support - Benefit: Seamless buffer sharing using standard DRM mechanisms 3. IOMMU Context Bank Management - FastRPC: Direct IOMMU domain manipulation, limited isolation - QDA: Custom compute bus (qda_cb_bus_type) with proper device model - Benefit: Each CB device is a proper struct device with IOMMU group support, enabling better isolation and resource tracking. - https://lore.kernel.org/all/245d602f-3037-4ae3-9af9-d98f37258aae@oss.qualco… 4. Memory Manager Architecture - FastRPC: Monolithic allocator - QDA: Pluggable memory manager with backend abstraction - Benefit: Currently uses DMA-coherent backend, easily extensible for future memory types (e.g., carveout, CMA) 5. Transport Layer - FastRPC: Direct RPMsg integration in core driver - QDA: Abstracted transport layer (qda_rpmsg.c) - Benefit: Clean separation of concerns, easier to add alternative transports if needed 8. Code Organization - FastRPC: ~3000 lines in single file - QDA: Modular design across multiple files (~4600 lines total) * qda_drv.c: Core driver and DRM integration * qda_gem.c: GEM object management * qda_memory_manager.c: Memory and IOMMU management * qda_fastrpc.c: FastRPC protocol implementation * qda_rpmsg.c: Transport layer * qda_cb.c: Context bank device management - Benefit: Better maintainability, clearer separation of concerns 9. UAPI Design - FastRPC: Custom IOCTL interface - QDA: DRM-style IOCTLs with proper versioning support - Benefit: Follows DRM conventions, easier userspace integration 10. Documentation - FastRPC: Minimal in-tree documentation - QDA: Comprehensive documentation in Documentation/accel/qda/ - Benefit: Better developer experience, clearer API contracts 11. Buffer Reference Mechanism - FastRPC: Uses buffer file descriptors (FDs) for all book-keeping in both kernel and DSP - QDA: Uses GEM handles for kernel-side management, providing better integration with DRM subsystem - Benefit: Leverages DRM GEM infrastructure for reference counting, lifetime management, and integration with other DRM components Key Technical Improvements =========================== * Proper device model: CB devices are real struct device instances on a custom bus, enabling proper IOMMU group management and power management integration * Reference-counted IOMMU devices: Multiple file descriptors from the same process share a single IOMMU device, reducing overhead * GEM-based buffer lifecycle: Automatic cleanup via DRM GEM reference counting, eliminating many resource leak scenarios * Modular memory backends: The memory manager supports pluggable backends, currently implementing DMA-coherent allocations with SID-prefixed addresses for DSP firmware * Context-based invocation tracking: XArray-based context management with proper synchronization and cleanup Patch Series Organization ========================== Patches 1-2: Driver skeleton and documentation Patches 3-6: RPMsg transport and IOMMU/CB infrastructure Patches 7-9: DRM device registration and basic IOCTL Patches 10-12: GEM buffer management and PRIME support Patches 13-17: FastRPC protocol implementation (attach, invoke, create, map/unmap) Patch 18: MAINTAINERS entry Open Items =========== The following items are identified as open items: 1. Privilege Level Management - Currently, daemon processes and user processes have the same access level as both use the same accel device node. This needs to be addressed as daemons attach to privileged DSP PDs and require higher privilege levels for system-level operations - Seeking guidance on the best approach: separate device nodes, capability-based checks, or DRM master/authentication mechanisms 2. UAPI Compatibility Layer - Add UAPI compat layer to facilitate migration of client applications from existing FastRPC UAPI to the new QDA accel driver UAPI, ensuring smooth transition for existing userspace code - Seeking guidance on implementation approach: in-kernel translation layer, userspace wrapper library, or hybrid solution 3. Documentation Improvements - Add detailed IOCTL usage examples - Document DSP firmware interface requirements - Create migration guide from existing FastRPC 4. Per-Domain Memory Allocation - Develop new userspace API to support memory allocation on a per domain basis, enabling domain-specific memory management and optimization 5. Audio and Sensors PD Support - The current patch series does not handle Audio PD and Sensors PD functionalities. These specialized protection domains require additional support for real-time constraints and power management Interface Compatibility ======================== The QDA driver maintains compatibility with existing FastRPC infrastructure: * Device Tree Bindings: The driver uses the same device tree bindings as the existing FastRPC driver, ensuring no changes are required to device tree sources. The "qcom,fastrpc" compatible string and child node structure remain unchanged. * Userspace Interface: While the driver provides a new DRM-based UAPI, the underlying FastRPC protocol and DSP firmware interface remain compatible. This ensures that DSP firmware and libraries continue to work without modification. * Migration Path: The modular design allows for gradual migration, where both drivers can coexist during the transition period. Applications can be migrated incrementally to the new UAPI with the help of the planned compatibility layer. References ========== Previous discussions on this migration: - https://lkml.org/lkml/2024/6/24/479 - https://lkml.org/lkml/2024/6/21/1252 Testing ======= The driver has been tested on Qualcomm platforms with: - Basic FastRPC attach/release operations - DSP process creation and initialization - Memory mapping/unmapping operations - Dynamic invocation with various buffer types - GEM buffer allocation and mmap - PRIME buffer import from other subsystems Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> --- Ekansh Gupta (18): accel/qda: Add Qualcomm QDA DSP accelerator driver docs accel/qda: Add Qualcomm DSP accelerator driver skeleton accel/qda: Add RPMsg transport for Qualcomm DSP accelerator accel/qda: Add built-in compute CB bus for QDA and integrate with IOMMU accel/qda: Create compute CB devices on QDA compute bus accel/qda: Add memory manager for CB devices accel/qda: Add DRM accel device registration for QDA driver accel/qda: Add per-file DRM context and open/close handling accel/qda: Add QUERY IOCTL and basic QDA UAPI header accel/qda: Add DMA-backed GEM objects and memory manager integration accel/qda: Add GEM_CREATE and GEM_MMAP_OFFSET IOCTLs accel/qda: Add PRIME dma-buf import support accel/qda: Add initial FastRPC attach and release support accel/qda: Add FastRPC dynamic invocation support accel/qda: Add FastRPC DSP process creation support accel/qda: Add FastRPC-based DSP memory mapping support accel/qda: Add FastRPC-based DSP memory unmapping support MAINTAINERS: Add MAINTAINERS entry for QDA driver Documentation/accel/index.rst | 1 + Documentation/accel/qda/index.rst | 14 + Documentation/accel/qda/qda.rst | 129 ++++ MAINTAINERS | 9 + arch/arm64/configs/defconfig | 2 + drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 2 + drivers/accel/qda/Kconfig | 35 ++ drivers/accel/qda/Makefile | 19 + drivers/accel/qda/qda_cb.c | 182 ++++++ drivers/accel/qda/qda_cb.h | 26 + drivers/accel/qda/qda_compute_bus.c | 23 + drivers/accel/qda/qda_drv.c | 375 ++++++++++++ drivers/accel/qda/qda_drv.h | 171 ++++++ drivers/accel/qda/qda_fastrpc.c | 1002 ++++++++++++++++++++++++++++++++ drivers/accel/qda/qda_fastrpc.h | 433 ++++++++++++++ drivers/accel/qda/qda_gem.c | 211 +++++++ drivers/accel/qda/qda_gem.h | 103 ++++ drivers/accel/qda/qda_ioctl.c | 271 +++++++++ drivers/accel/qda/qda_ioctl.h | 118 ++++ drivers/accel/qda/qda_memory_dma.c | 91 +++ drivers/accel/qda/qda_memory_dma.h | 46 ++ drivers/accel/qda/qda_memory_manager.c | 382 ++++++++++++ drivers/accel/qda/qda_memory_manager.h | 148 +++++ drivers/accel/qda/qda_prime.c | 194 +++++++ drivers/accel/qda/qda_prime.h | 43 ++ drivers/accel/qda/qda_rpmsg.c | 327 +++++++++++ drivers/accel/qda/qda_rpmsg.h | 57 ++ drivers/iommu/iommu.c | 4 + include/linux/qda_compute_bus.h | 22 + include/uapi/drm/qda_accel.h | 224 +++++++ 31 files changed, 4665 insertions(+) --- base-commit: d4906ae14a5f136ceb671bb14cedbf13fa560da6 change-id: 20260223-qda-firstpost-4ab05249e2cc Best regards, -- Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com>

7 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig April 2026