libcamera: prefer udmabuf over dma-heaps

[Wenmeng Liu (wenmliu)]

On Hamoa, CMA memory is currently insufficient for libcamera operation
at some resolutions. Make the DMA-BUF provider priority order
configurable through the runtime configuration.

DmaBufAllocator now accepts an ordered list of preferred provider names;
providers not listed are tried afterwards in the built-in order. When
the list is empty, the historical order is preserved, so behaviour
remains unchanged by default.

The change is carried as a qcom-specific patch applied through a
libcamera bbappend.

[Wenmeng Liu (wenmliu)]

kernel config PR: qualcomm-linux/kernel-topics#1805

[github-actions]

Test run workflow

Test jobs for commit 5948083

qcom-distro
Pass: 114 | Fail: 0 | Total: 119

qcom-distro_linux-qcom-6.18
Pass: 113 | Fail: 0 | Total: 119

[test-reporting-app]

Test Results

   34 files    260 suites   2h 14m 28s ⏱️
   91 tests    91 ✅  0 💤 0 ❌
1 646 runs  1 635 ✅ 11 💤 0 ❌

Results for commit 5948083.

♻️ This comment has been updated with latest results.

[Dmitry Baryshkov (lumag)]

I think this is a more generic problem, to be solved with libcamera itself. If the allocator can't provide enough memory, the libcamera should be able to fallback to the other allocators. This is especially true for the CMA allocators where we know that memory space is limited.

[Hans de Goede (jwrdegoede)]

The upstream linux-media (e.g. gstreamer) direction seems to be to use udmabuf more and more where ever possible now that it is generally available in most distro configurations.

I think trying relatively unlimited udmabuf memory before CMA heaps makes sense from a not wasting scarce resources like CMA. OTOH IIRC the try CMA first approach is there for platforms where e.g. the video hw encoder which may sit after libcamera can only operate on CMA memory.

So I think that rather then carrying a downstream patch the following should be done:

1. Make the order in which allocators are tried configurable through libcamera's configfile mechanism allowing changing of the order by dropping a /etc/libcamera/configuration.yaml file. This alone should be sufficient for meta-qcom for now, by meta-qcom using this new config mechanism.
2. Allow pipeline-handlers to provide a pipeline-handler specific default order which to use when the config file does not specify any order. pipeline-handlers is how libcamera deals with platform differences. So this will allow the camss pipeline-handler I'm working on to make trying udmabuf first the default on Qualcomm platforms.

Dmitry Baryshkov (@lumag)'s idea of falling back to another allocator is interesting but I think that will complicate things quite a bit. E.g. in case of platforms where we actually want CMA to be tried first, returning a udmabuf backed dmabuf may cause errors elsewhere (e.g. the video-encoder), so I'm not sure how helpful this will be.

I think that a configurable setting in which order to try the allocators should solve this nicely.

[Dmitry Baryshkov (lumag)]

Wenmeng Liu (@wenmliu) I think, Hans de Goede (@jwrdegoede) 's reply means: please open a merge request against libcamera, once agreed there, please backport it to QLI.

[Hans de Goede (jwrdegoede)]

Ack, I was about to write: to be clear my suggestion to fix this should be done upstream first.

[Hans de Goede (jwrdegoede)]

p.s. :

1. For more info on the config mechanism see: https://docs.libcamera.org/master/runtime_configuration.html and also please update runtime_configuration.rst when adding a setting for this.
2. Note upstream does not take pull-requests they use an email based patch-workflow closely mirroring the kernel's. So subscribe to the libcamera-devel list: https://lists.libcamera.org/listinfo/libcamera-devel and after writing the patches git send-email them to the libcamera-devel list.

[Wenmeng Liu (wenmliu)]

Sounds good. I'll work on the changes and submit them upstream.

[Loïc Minier (lool)]

The upstream linux-media (e.g. gstreamer) direction seems to be to use udmabuf more and more where ever possible now that it is generally available in most distro configurations.

Just an FYI but you probably already know: UDMABUF is not enabled in defconfig

[Hans de Goede (jwrdegoede)]

The upstream linux-media (e.g. gstreamer) direction seems to be to use udmabuf more and more where ever possible now that it is generally available in most distro configurations.

Just an FYI but you probably already know: UDMABUF is not enabled in defconfig

Interesting, I'm not really a defconfig user, but that is a good point and one which is probably worth fixing... Let me discuss this with Robert Mader who has been pushing this from the gstreamer side.

[Wenmeng Liu (wenmliu)]

The upstream linux-media (e.g. gstreamer) direction seems to be to use udmabuf more and more where ever possible now that it is generally available in most distro configurations.

Just an FYI but you probably already know: UDMABUF is not enabled in defconfig

Yes, that's why I submitted a PR to enable UDMABUF for Qualcomm platforms:
qualcomm-linux/kernel-topics#1805

[Wenmeng Liu (wenmliu)]

The patch has been submitted to the libcamera community: https://lists.libcamera.org/pipermail/libcamera-devel/2026-September/062007.html

[Jose Quaresma (quaresmajose)]

Build failures should be fixed with #468

[Ricardo Salveti (ricardosalveti)]

Please rebase.

[Wenmeng Liu (wenmliu)]

Please rebase.

done

[quic-yocto-ci]

Successfully created backport PR for wrynose:

• [Backport wrynose] libcamera: prefer udmabuf over dma-heaps #482