[PATCH 0/3] dma-buf: heaps: cma: respect the importer's maximum segment size

[Karl Mehltretter <kmehltretter@gmail.com>]

The CMA heap builds attachment scatterlists without considering the
importing device's maximum DMA segment size. When an entry exceeds
that limit, DMA_API_DEBUG reports "mapping sg segment longer than
device claims to support". Patch 3 uses the importer's limit. A
corresponding udmabuf fix was posted in [1].

With patch 3, an importer that keeps the 64 KiB default gets a larger
buffer in several entries. Two in-tree importers require a single
entry and never set a limit: tegra-vde without an IOMMU domain, and
armada. Patches 1 and 2 set an unlimited segment size there. I found
them by searching the importers for checks on the number of entries
and on the length of the first entry. etnaviv has a fast path for
single-entry buffers but already declares a 2 GiB limit.

Patches 1 and 2 are valid on their own and can go through their own
trees. Patch 3 should only be applied after them, and is marked
stable+noautosel for that reason.

Tested in QEMU only, not on real hardware: patch 3 on a custom model
of the SAM9X75 Curiosity, and all three patches on xilinx-zynq-a9
with tegra-vde and armada probing from stub device tree nodes. The
notes of each patch have the details.

[1] https://lore.kernel.org/r/20260929054835.94118-1-kmehltretter@gmail.com/

Karl Mehltretter (3):
  media: tegra-vde: set an unlimited DMA segment size
  drm/armada: set an unlimited DMA segment size
  dma-buf: heaps: cma: respect the device's maximum segment size

 drivers/dma-buf/heaps/cma_heap.c              | 14 ++++++++++----
 drivers/gpu/drm/armada/armada_drv.c           |  3 +++
 drivers/media/platform/nvidia/tegra-vde/vde.c |  2 ++
 3 files changed, 15 insertions(+), 4 deletions(-)


base-commit: fe2ec83746e501645709761605c2464a44fd2929
-- 
2.53.0