Revert changing the DMA allocator via public API and use environment variables #1344

dNechita · 2025-09-05T13:28:57Z

PR Description

"This reverts the functionality that allowed users to change the DMA allocator type through the public API. The use case is niche and rarely needed at present. The existing functionality supported two options: the default 'system' and 'cma,linux'—the latter being non-standard and system-dependent (see #1329), often requiring a custom string. Supporting this through the public API adds unnecessary complexity and risks future breakage. Instead, I am introducing an alternative approach for changing the DMA allocator that avoids impacting the API.

PR Type

Bug fix (a change that fixes an issue)
New feature (a change that adds new functionality)
Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

I have conducted a self-review of my own code changes
I have commented new code, particularly complex or unclear areas
I have checked that I did not introduce new warnings or errors (CI output)
I have checked that components that use libiio did not get broken
I have updated the documentation accordingly (GitHub Pages, READMEs, etc)

rgetz · 2025-09-06T16:15:04Z

As I said in the original PR:

Just going on record - I think this is a bad design decision, and it going to make things more complicated to use going forward. The goal of the kernel is to abstract hardware from userspace, and allow common code to be run on any architecture. This is the opposite of that.

Originally posted by @rgetz in #1264 (comment)

I think this is still the same.

README_BUILD.md

nunojsa · 2025-09-11T08:48:13Z

local-dmabuf.c

+ * Environment variable format:
+ * - LIBIIO_DMA_HEAP_PATH=heap_name (applies to all devices)
+ * - LIBIIO_DMA_HEAP_PATH=heap_name:device1 (applies only to device1)
+ * - LIBIIO_DMA_HEAP_PATH=heap_name:device1,device2 (applies to device1 and device2)


Hmm, I would make this way more simple for now. I guess the ENV var is ok (even though I would likely go for the compile time option) but make it simple. Meaning, just give in the allocator name. For now this is a system thing and we don't really need to have a per device setting. Let's deal with this when we really have an use case for that.

The above is one of the reasons why I would likely go with a build option. ATM, this is kind of a system level decision and the build option would be the simpler approach for that. But as I said, I guess I can live with the env var (even though that brings a runtime penalty - but not when streaming at least).

nunojsa · 2025-09-11T08:52:24Z

I think this is still the same.

Unfortunately, there's no way in the kernel to do that (AFAIK) and I feel it would not be trivial to abstract what every device needs in terms of DMA mappings (and it would be for sure time consuming). We know we have users needing something like this so I feel this PR is a good compromise (As I said, I was also not convinced with what we previously had).

And as I said before, this is really no different than what we already had (I mean, assuming that we always want the "system" heap).

nunojsa · 2025-09-11T08:55:59Z

I mean, for peace of mind, @dNechita you can also try to look at some v4l2/media userspace tools in github and search for the dmabuf path . Some of these devices are also using dmabufs so we might see if they are doing something more clever. (if handling this at all in userspace).

8291539 ("task: Implement iio_buffer_params struct and make CMA selectable at runtime") implemented iio_buffer_params, replacing idx with a struct. In the python binding, the change broke usage since dropped optional idx with required params. Define the struct in python, defaulting .idx to 0 and .dma_allocator = IIO_DMA_ALLOCATOR_SYSTEM, and make optional, to restore compatibility with legacy code (idx was hardly set). In case #1344 does not revert iio_buffer_params. Signed-off-by: Jorge Marques <[email protected]>

dNechita · 2025-11-14T09:41:16Z

I mean, for peace of mind, @dNechita you can also try to look at some v4l2/media userspace tools in github and search for the dmabuf path . Some of these devices are also using dmabufs so we might see if they are doing something more clever. (if handling this at all in userspace).

In libcamera there's a list of predefined paths and code can try to use one or a combination of paths.
List of paths: https://github.com/kbingham/libcamera/blob/6d19c813b0a74770165e032e7f527c36b838e456/src/libcamera/dma_buf_allocator.cpp#L48:L51
Opens the paths (one or multiple):
https://github.com/kbingham/libcamera/blob/6d19c813b0a74770165e032e7f527c36b838e456/src/libcamera/dma_buf_allocator.cpp#L99:L110
Usage example:
https://github.com/kbingham/libcamera/blob/6d19c813b0a74770165e032e7f527c36b838e456/src/libcamera/software_isp/software_isp.cpp#L79

In a dmabuf v4l2 demo, it attempts to first open "linux,cma" and then "linux,reserved":
https://github.com/emfend/dmabuf-v4l2-demo/blob/main/dmabuf.c#L17:L31

I haven't found anything that does an automated detection other than having a hardcoded list of DMA paths and trying them one by one.

nunojsa · 2025-11-14T09:57:21Z

In a dmabuf v4l2 demo, it attempts to first open "linux,cma" and then "linux,reserved":

Seems to be we should also try linux,reserved as that is also CMA (just renamed in a different way).

I haven't found anything that does an automated detection other than having a hardcoded list of DMA paths and trying them one by one.

yeah, that was my feeling already. It goes along with what I was thinking in here:

#1329 (comment)

So, I think cameras are a very typical case where CMA memory is used but I think we could still have the same logic. Just try to open one of this (by the given order):

"/dev/dma_heap/linux,cma" },
"/dev/dma_heap/reserved" },
"/dev/dma_heap/system" },

In the future (if needed), we can still add some ENV variable to opt out from the above behavior. Meaning, to explicitly select one type of backing memory.

This reverts commit 9e6895c.

This reverts commit 95dc678.

This reverts commit 58e333d.

This reverts commit 733a681.

This reverts commit 5f52c98.

This reverts commit aa867f0.

…ble at runtime" This reverts commit 8291539.

This reverts commit a7d0450.

Signed-off-by: Dan Nechita <[email protected]>

nunojsa

I think the below could actually make sense (taking inspiration from libcamera):

#1344 (comment)

But I guess that can be implemented aftwerwards

local-dmabuf.c

nunojsa

Just some minor stuff from me

nunojsa · 2025-11-21T09:27:36Z

local-dmabuf.c

+		"linux,cma",
+		"default-pool"
+	};
+	static const size_t num_accepted_heaps = sizeof(accepted_heaps) / sizeof(accepted_heaps[0]);


I would imagine libiio defines somewhere ARRAY_SIZE(). If we have it, use it. Also there's no point in making it const and more important static. Why keeping that memory around after the call?

I found ARRAY_SIZE() definition. Also, I removed the const and static.

nunojsa · 2025-11-21T09:30:41Z

local-dmabuf.c

+		"\"reserved\", \"linux,cma\", \"default-pool\". "
+		"Defaulting to \"system\"\n", env_value);
+
+	return "system";


Not sure if this should not be an error given that the user indeed made an error and given that this happens locally one cannot easily realize what's the issue.

That said, up to you

If I were the user, I would like to get an error instead of the library doing some else silently.
Updated.

nunojsa · 2025-11-21T09:32:51Z

local-dmabuf.c

+	/* Determine DMA heap path from global environment variable */
+	heap_name = get_dma_heap_name();
+
+	ret = snprintf(dma_heap_path, sizeof(dma_heap_path), "/dev/dma_heap/%s", heap_name);


If we go the path of defaulting to "system" in case of error, you can just call get_dma_heap_name() inline in snprintf()

Not applicable anymore.

This feature is targeted for users who experiment with or require alternative DMA allocators. It is to be determined if the feature becomes popular enough to be exposed through the public API or not. Signed-off-by: Dan Nechita <[email protected]>

Describe the LIBIIO_DMA_HEAP_PATH environment variable and provide an usage example. Signed-off-by: Dan Nechita <[email protected]>

xR3b0rn · 2025-11-25T14:01:16Z

I really like the precision and effort you put into such issues. High quality there - looking forward to test this. Thanks!

dNechita · 2025-11-26T07:37:11Z

I really like the precision and effort you put into such issues. High quality there - looking forward to test this. Thanks!

Thank you!

dNechita requested a review from nunojsa September 5, 2025 13:28

dNechita requested review from cristina-suteu and mhennerich as code owners September 5, 2025 13:28

dNechita changed the title ~~Reverse cma go for env var approach~~ Revert changing the DMA allocator via public API and use environment variables Sep 5, 2025

dNechita mentioned this pull request Sep 5, 2025

[draft] feat(local): Make DMA allocator freely configurable #1339

Closed

dNechita force-pushed the reverse-cma-go-for-env-var-approach branch from 62acb6c to 5dc525a Compare September 5, 2025 13:43

nunojsa reviewed Sep 11, 2025

View reviewed changes

schwesinger mentioned this pull request Oct 6, 2025

Fix file chosing for CMA #1329

Closed

gastmaier mentioned this pull request Nov 12, 2025

Implement BufferParams in the python binding #1367

Draft

8 tasks

dNechita force-pushed the reverse-cma-go-for-env-var-approach branch 2 times, most recently from c4cd63a to 0578731 Compare November 14, 2025 10:52

dNechita added 9 commits November 20, 2025 13:33

Revert "iiod: ops: update call iio_device_create_buffer()"

0208b97

This reverts commit 9e6895c.

Revert "utils: update call iio_device_create_buffer()"

dc1522b

This reverts commit 95dc678.

Revert "examples: update call iio_device_create_buffer()"

6c8025e

This reverts commit 58e333d.

Revert "iiod: fix struct iio_buffer_params not being handled"

8d1af00

This reverts commit 733a681.

Revert "buffer: add reserved space to struct iio_buffer_params"

411b247

This reverts commit 5f52c98.

Revert "task: Added -C option in iio_rwdev.c and iio_stresstest.c"

6edfed9

This reverts commit aa867f0.

Revert "task: Implement iio_buffer_params struct and make CMA selecta…

9422931

…ble at runtime" This reverts commit 8291539.

Revert "task: Added struct iio_buffer_params for future use"

e0c3680

This reverts commit a7d0450.

man: Remove references of 'cma'

4b121f0

Signed-off-by: Dan Nechita <[email protected]>

dNechita force-pushed the reverse-cma-go-for-env-var-approach branch from 0578731 to 4342d0e Compare November 20, 2025 11:35

dNechita requested a review from nunojsa November 20, 2025 12:07

nunojsa reviewed Nov 20, 2025

View reviewed changes

dNechita force-pushed the reverse-cma-go-for-env-var-approach branch from 4342d0e to cda2eea Compare November 21, 2025 07:40

dNechita requested a review from nunojsa November 21, 2025 07:52

nunojsa reviewed Nov 21, 2025

View reviewed changes

dNechita added 2 commits November 24, 2025 13:19

README_BUILD: Document DMA path environment var

8f82357

Describe the LIBIIO_DMA_HEAP_PATH environment variable and provide an usage example. Signed-off-by: Dan Nechita <[email protected]>

dNechita force-pushed the reverse-cma-go-for-env-var-approach branch from cda2eea to 8f82357 Compare November 24, 2025 11:35

nunojsa approved these changes Nov 24, 2025

View reviewed changes

dNechita merged commit 1f80205 into main Nov 24, 2025
34 checks passed

dNechita deleted the reverse-cma-go-for-env-var-approach branch November 24, 2025 13:00

Revert changing the DMA allocator via public API and use environment variables #1344

Revert changing the DMA allocator via public API and use environment variables #1344

Uh oh!

Conversation

dNechita commented Sep 5, 2025

PR Description

PR Type

PR Checklist

Uh oh!

rgetz commented Sep 6, 2025

Uh oh!

Uh oh!

nunojsa Sep 11, 2025

Choose a reason for hiding this comment

Uh oh!

nunojsa commented Sep 11, 2025

Uh oh!

nunojsa commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dNechita commented Nov 14, 2025

Uh oh!

nunojsa commented Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nunojsa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nunojsa left a comment

Choose a reason for hiding this comment

Uh oh!

nunojsa Nov 21, 2025

Choose a reason for hiding this comment

Uh oh!

dNechita Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

nunojsa Nov 21, 2025

Choose a reason for hiding this comment

Uh oh!

dNechita Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

nunojsa Nov 21, 2025

Choose a reason for hiding this comment

Uh oh!

dNechita Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

xR3b0rn commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dNechita commented Nov 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

nunojsa commented Sep 11, 2025 •

edited

Loading

nunojsa commented Nov 14, 2025 •

edited

Loading

xR3b0rn commented Nov 25, 2025 •

edited

Loading