Yes, this happened in the past. However, the benefits of DMA-BUF outweigh this IMO. I also have the libimxdmabuffer library to encapsulate such details.
toggle quoted messageShow quoted text
The alternative is to rely on IPU/VPU/etc. specific allocators, which come with more significant downsides.
On 20.10.20 13:38, Andrey Zhizhikin wrote:
On Tue, Oct 20, 2020 at 10:19 AM Carlos Rafael Giani via
On i.MX6 machines, it is currently not possible to use the ION From the past experience I had with ION allocators in the past, I
allocator. However, there is no hardware limitation that requires ION to
If ION were enabled, with a CMA heap, then it would be possible for
userspace to allocate DMA-BUF buffers. I could then enable the ion
packageconfig in the libimxdmabuffer recipe.
The defconfig only needs these additions:
I tried it out, worked fine.
Using DMA-BUF for allocating physically contiguous memory (via CMA) is
preferable over using other allocators (like the ones from the VPU, IPU
etc.) since it allows for proper buffer sharing, ownership transfer, is
based on FDs (though physical address are accessible via an NXP
extension), and there are extensions in OpenCL, OpenGL etc. for
importing DMA-BUF. V4L2 also has DMA-BUF support.
would try to refrain from using it. It is still residing in staging
folder, which means that the API compatibility is not guaranteed. I
had an experience where Application used ION in 4.4.y kernel, and
should be re-written when 4.9.y kernel has been released due to
significant changes in the ION UAPI.
I would personally not recommend using it until it would be moved from
staging to drivers.
If one plans to base development on ION API - this should be taken