meta-freescale.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
From: "Carlos Rafael Giani" <crg7475@mailbox.org>
To: meta-freescale@lists.yoctoproject.org
Subject: Re: [meta-freescale] Enabling ION with CMA heap on imx6
Date: Tue, 20 Oct 2020 19:13:39 +0200	[thread overview]
Message-ID: <204c0784-76a9-7ae7-e59b-b2c5fdb234fa@mailbox.org> (raw)
In-Reply-To: <CAHtQpK6dYKQFHTTZ6o=kcN8jeT0HLytFT=aCKcOgLWO7VFfbrg@mail.gmail.com>

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.

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
> lists.yoctoproject.org <crg7475=mailbox.org@lists.yoctoproject.org>
> wrote:
>> On i.MX6 machines, it is currently not possible to use the ION
>> allocator. However, there is no hardware limitation that requires ION to
>> be disabled.
>>
>> 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:
>>
>> CONFIG_ION=y
>> CONFIG_ION_SYSTEM_HEAP=y
>> CONFIG_ION_CMA_HEAP=y
>>
>> 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.
>>
>> Opinions?
>  From the past experience I had with ION allocators in the past, I
> 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
> into consideration.
>
>>
>> 
>>
>

      reply	other threads:[~2020-10-20 17:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-20  8:19 Enabling ION with CMA heap on imx6 Carlos Rafael Giani
2020-10-20 11:31 ` [meta-freescale] " Otavio Salvador
2020-10-20 17:11   ` Carlos Rafael Giani
2020-10-20 11:38 ` Andrey Zhizhikin
2020-10-20 17:13   ` Carlos Rafael Giani [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=204c0784-76a9-7ae7-e59b-b2c5fdb234fa@mailbox.org \
    --to=crg7475@mailbox.org \
    --cc=meta-freescale@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).