From: John Stultz <john.stultz@linaro.org>
To: "Andrew F. Davis" <afd@ti.com>
Cc: Chenbo Feng <fengc@google.com>,
Alistair Strachan <astrachan@google.com>,
Liam Mark <lmark@codeaurora.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework
Date: Mon, 25 Feb 2019 10:41:44 -0800 [thread overview]
Message-ID: <CALAqxLVL1vqU8WnJcaQbt0Xx568DztgD+=vcJX48xcAFkjeKzg@mail.gmail.com> (raw)
In-Reply-To: <20190225143604.27511-1-afd@ti.com>
On Mon, Feb 25, 2019 at 6:36 AM Andrew F. Davis <afd@ti.com> wrote:
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
>
> Each heap is given its own device node, which a user can allocate
> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
>
> Hello all,
>
> I had a little less time over the weekend than I thought I would to
> clean this up more and finish the first set of user heaps, but wanted
> to get this out anyway.
>
> ION in its current form assumes a lot about the memory it exports and
> these assumptions lead to restrictions on the full range of operations
> dma-buf's can produce. Due to this if we are to add this as an extension
> of the core dma-buf then it should only be the user-space advertisement
> and allocation front-end. All dma-buf exporting and operation need to be
> placed in the control of the exporting heap. The core becomes rather
> small, just a few hundred lines you see here. This is not to say we
> should not provide helpers to make the heap exporters more simple, but
> they should only be helpers and not enforced by the core framework.
>
> Basic use model here is an exporter (dedicated heap memory driver, CMA,
> System, etc.) registers with the framework by providing a struct
> dma_heap_info which gives us the needed info to export this heap to
> userspace as a device node. Next a user will request an allocation,
> the IOCTL is parsed and the request made to a heap provided alloc() op.
> The heap should return the filled out struct dma_heap_buffer, including
> exporting the buffer as a dma-buf. This dma-buf we then return to the
> user as a fd. Buffer free is still a bit open as we need to update some
> stats and free some memory, but the release operation is controlled by
> the heap exporter, so some hook will have to be created.
>
> It all needs a bit more work, and I'm sure I'll find missing parts when
> I add some more heaps, but hopefully this framework is simple enough that
> it does not impede the implementation of all functionality once provided
> by ION (shrinker, delayed free), nor any new functionality needed for
> future heap exporting devices.
Overall looks pretty good! I'll take a stab today at reworking my
stack on top of this starting patch.
thanks
-john
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-02-25 18:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 14:36 [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework Andrew F. Davis
2019-02-25 18:41 ` John Stultz [this message]
2019-02-26 0:20 ` John Stultz
2019-02-26 14:02 ` Andrew F. Davis
2019-02-26 0:55 ` John Stultz
2019-02-26 14:04 ` Andrew F. Davis
2019-02-26 3:53 ` Sumit Semwal
2019-02-26 14:28 ` Andrew F. Davis
2019-02-26 6:20 ` John Stultz
2019-02-26 14:46 ` Andrew F. Davis
2019-02-26 19:21 ` John Stultz
2019-02-26 23:40 ` John Stultz
2019-02-27 16:38 ` Andrew F. Davis
2019-02-27 21:55 ` John Stultz
2019-02-28 15:20 ` Andrew F. Davis
2019-03-01 23:49 ` John Stultz
2019-02-26 14:12 ` Benjamin Gaignard
2019-02-26 15:05 ` Andrew F. Davis
2019-02-26 15:22 ` Linus Walleij
2019-02-27 23:22 ` Laura Abbott
2019-02-28 0:14 ` John Stultz
2019-03-01 12:06 ` Brian Starkey
2019-03-04 14:53 ` Andrew F. Davis
2019-03-05 1:16 ` John Stultz
2019-03-05 18:05 ` Andrew F. Davis
2019-03-05 18:45 ` John Stultz
2019-03-05 18:22 ` Brian Starkey
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='CALAqxLVL1vqU8WnJcaQbt0Xx568DztgD+=vcJX48xcAFkjeKzg@mail.gmail.com' \
--to=john.stultz@linaro.org \
--cc=afd@ti.com \
--cc=astrachan@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fengc@google.com \
--cc=lmark@codeaurora.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).