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/[email protected]/ 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
