On Mon, Oct 05, 2026 at 08:46:40AM +0200, Karl Mehltretter wrote:
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 3fb4b946c91a..9d61d14688b8 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -58,16 +58,22 @@ static int cma_heap_attach(struct dma_buf *dmabuf, { struct cma_heap_buffer *buffer = dmabuf->priv; struct dma_heap_attachment *a;
- unsigned int max_segment; int ret;
- max_segment = dma_get_max_seg_size(attachment->dev);
- /* The SG allocator requires a segment limit of at least PAGE_SIZE. */
- if (max_segment < PAGE_SIZE)
return -EINVAL;
This seems like unnecessary AI paranoia.. If something like this should exist it should be inside sg_alloc_table_from_pages_segment().
I guess pretty much every DRM user has this latent issue? Given few importers even seem to use the segment size, it would be nicer to solve it by just not using segment size here.
This is possible with the new dma api, and adding a new dma_buf_pages_to_sgt() using that approach looked OK from an AI draft.
However, the dma_sync_sgtable_for_device() in the heap doesn't seem to have a straightforward conversion.. We never made streaming functions for the new dma api, and drivers are not permitted to call the cache flushing functions by themselves.
Something to think about at least.
Jason