From: "Andrew F. Davis" <afd@ti.com>
To: John Stultz <john.stultz@linaro.org>
Cc: Alistair Strachan <astrachan@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
Chenbo Feng <fengc@google.com>,
lkml <linux-kernel@vger.kernel.org>,
Liam Mark <lmark@codeaurora.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
Date: Wed, 6 Mar 2019 15:45:40 -0600 [thread overview]
Message-ID: <62d91a79-58ee-b2a0-7fb8-d38f32660fd1@ti.com> (raw)
In-Reply-To: <CALAqxLVh9zU-96ZpOVFztS=WtpMWPEOqAo=zj+fhVVK78W50BQ@mail.gmail.com>
On 3/6/19 1:03 PM, John Stultz wrote:
> On Wed, Mar 6, 2019 at 10:18 AM Andrew F. Davis <afd@ti.com> wrote:
>>
>> On 3/5/19 2:54 PM, John Stultz wrote:
>>> From: "Andrew F. Davis" <afd@ti.com>
>>>
>>> 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.
>>>
>>> This code is an evoluiton of the Android ION implementation,
>>> and a big thanks is due to its authors/maintainers over time
>>> for their effort:
>>> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
>>> Laura Abbott, and many other contributors!
>>>
>>> Cc: Laura Abbott <labbott@redhat.com>
>>> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>>> Cc: Greg KH <gregkh@linuxfoundation.org>
>>> Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>> Cc: Liam Mark <lmark@codeaurora.org>
>>> Cc: Brian Starkey <Brian.Starkey@arm.com>
>>> Cc: Andrew F. Davis <afd@ti.com>
>>> Cc: Chenbo Feng <fengc@google.com>
>>> Cc: Alistair Strachan <astrachan@google.com>
>>> Cc: dri-devel@lists.freedesktop.org
>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>> [jstultz: reworded commit message, and lots of cleanups]
>>> Signed-off-by: John Stultz <john.stultz@linaro.org>
>>> ---
>>> v2:
>>> * Folded down fixes I had previously shared in implementing
>>> heaps
>>> * Make flags a u64 (Suggested by Laura)
>>> * Add PAGE_ALIGN() fix to the core alloc funciton
>>> * IOCTL fixups suggested by Brian
>>> * Added fixes suggested by Benjamin
>>> * Removed core stats mgmt, as that should be implemented by
>>> per-heap code
>>> * Changed alloc to return a dma-buf fd, rather then a buffer
>>> (as it simplifies error handling)
>>> ---
>>> MAINTAINERS | 16 ++++
>>> drivers/dma-buf/Kconfig | 8 ++
>>> drivers/dma-buf/Makefile | 1 +
>>> drivers/dma-buf/dma-heap.c | 191 ++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/dma-heap.h | 65 ++++++++++++++
>>> include/uapi/linux/dma-heap.h | 52 ++++++++++++
>>> 6 files changed, 333 insertions(+)
>>> create mode 100644 drivers/dma-buf/dma-heap.c
>>> create mode 100644 include/linux/dma-heap.h
>>> create mode 100644 include/uapi/linux/dma-heap.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index ac2e518..a661e19 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -4621,6 +4621,22 @@ F: include/linux/*fence.h
>>> F: Documentation/driver-api/dma-buf.rst
>>> T: git git://anongit.freedesktop.org/drm/drm-misc
>>>
>>> +DMA-BUF HEAPS FRAMEWORK
>>> +M: Laura Abbott <labbott@redhat.com>
>>> +R: Liam Mark <lmark@codeaurora.org>
>>> +R: Brian Starkey <Brian.Starkey@arm.com>
>>> +R: "Andrew F. Davis" <afd@ti.com>
>>
>> Quotes not needed in maintainers file.
>
> Whatever you say, "Andrew F. Davis", or whomever you really are! ;)
>
<_<
>_>
>
>>> +
>>> + if (heap_allocation.fd ||
>>> + heap_allocation.reserved0 ||
>>> + heap_allocation.reserved1 ||
>>> + heap_allocation.reserved2) {
>>
>> Seems too many reserved, I can understand one, but if we ever needed all
>> of these we would be better off just adding another alloc ioctl.
>
> Well, we have to have one u32 for padding. And I figured if we needed
> anything more then a u32, then we're in for 2 more.
>
> And I think the potential of the alignment and heap-private flags, I
> worry we might want to have something, but I guess we could just add
> a new ioctl and keep the support for the old one if folks prefer.
>
>>> +int dma_heap_add(struct dma_heap *heap)
>>> +{
>>> + struct device *dev_ret;
>>> + int ret;
>>> +
>>> + if (!heap->name || !strcmp(heap->name, "")) {
>>> + pr_err("dma_heap: Cannot add heap without a name\n");
>>
>> As these names end up as the dev name in the file system we may want to
>> check for invalid names, there is probably a helper for that somewhere.
>
> Hrm. I'll have to look.
>
>>> +struct dma_heap {
>>> + const char *name;
>>> + struct dma_heap_ops *ops;
>>> + unsigned int minor;
>>> + dev_t heap_devt;
>>> + struct cdev heap_cdev;
>>> +};
>>
>> Still not sure about this, all of the members in this struct are
>> strictly internally used by the framework. The users of this framework
>> should not have access to them and only need to deal with an opaque
>> pointer for tracking themselves (can store it in a private struct of
>> their own then container_of to get back out their struct).
>>
>> Anyway, not a big deal, and if it really bugs me enough I can always go
>> fix it later, it's all kernel internal so not a blocker here. :)
>
> I guess I'd just move the include/linux/dma-heap.h to
> drivers/dma-buf/heaps/ and keep it localized there.
> But whichever. Feel free to also send a patch and I can fold it down.
>
The dma-heap.h needs to stay where it is, I was thinking just move
struct dma_heap to inside drivers/dma-buf/dma-heap.c. I wouldn't worry
about changing anything right now though, I'll post a patch you can
squash in later one we confirm this whole dma-heap thing will get deemed
acceptable in the first place.
Thanks,
Andrew
> 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-03-06 21:45 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 20:54 [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) John Stultz
2019-03-05 20:54 ` [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework John Stultz
2019-03-06 16:12 ` Benjamin Gaignard
2019-03-06 16:57 ` John Stultz
2019-03-15 8:55 ` Christoph Hellwig
2019-03-06 16:27 ` Andrew F. Davis
2019-03-06 19:03 ` John Stultz
2019-03-06 21:45 ` Andrew F. Davis [this message]
2019-03-15 8:54 ` Christoph Hellwig
2019-03-15 20:24 ` Andrew F. Davis
2019-03-15 20:18 ` Laura Abbott
2019-03-15 20:49 ` Andrew F. Davis
2019-03-15 21:29 ` John Stultz
2019-03-15 22:44 ` Laura Abbott
2019-03-18 4:38 ` Sumit Semwal
2019-03-18 4:41 ` Sumit Semwal
2019-03-19 12:08 ` Brian Starkey
2019-03-19 15:24 ` Andrew F. Davis
2019-03-21 21:16 ` John Stultz
2019-03-27 14:53 ` Greg KH
2019-03-28 6:09 ` John Stultz
2019-03-05 20:54 ` [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers John Stultz
2019-03-13 20:18 ` Liam Mark
2019-03-13 21:48 ` Andrew F. Davis
2019-03-13 22:57 ` Liam Mark
2019-03-13 23:42 ` Andrew F. Davis
2019-03-15 9:06 ` Christoph Hellwig
2019-03-19 15:03 ` Andrew F. Davis
2019-03-21 20:01 ` John Stultz
2019-03-19 14:26 ` Brian Starkey
2019-03-21 20:11 ` John Stultz
2019-03-21 20:35 ` Andrew F. Davis
2019-03-21 20:43 ` Andrew F. Davis
2019-03-05 20:54 ` [RFC][PATCH 3/5 v2] dma-buf: heaps: Add system heap to dmabuf heaps John Stultz
2019-03-06 16:01 ` Benjamin Gaignard
2019-03-11 5:48 ` John Stultz
2019-03-13 20:20 ` Liam Mark
2019-03-13 22:49 ` John Stultz
2019-03-15 9:06 ` Christoph Hellwig
2019-03-05 20:54 ` [RFC][PATCH 4/5 v2] dma-buf: heaps: Add CMA heap to dmabuf heapss John Stultz
2019-03-06 16:05 ` Benjamin Gaignard
2019-03-21 20:15 ` John Stultz
2019-03-15 9:06 ` Christoph Hellwig
2019-03-15 20:08 ` John Stultz
2019-03-19 14:53 ` Brian Starkey
2019-03-05 20:54 ` [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test John Stultz
2019-03-06 16:14 ` Benjamin Gaignard
2019-03-06 16:35 ` Andrew F. Davis
2019-03-06 18:19 ` John Stultz
2019-03-06 18:32 ` Andrew F. Davis
2019-03-06 17:01 ` John Stultz
2019-03-15 20:07 ` Laura Abbott
2019-03-15 20:13 ` John Stultz
2019-03-15 20:49 ` Laura Abbott
2019-03-13 20:23 ` Liam Mark
2019-03-13 20:11 ` [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) Liam Mark
2019-03-13 22:30 ` John Stultz
2019-03-13 23:29 ` Liam Mark
2019-03-19 16:54 ` Benjamin Gaignard
2019-03-19 16:59 ` Andrew F. Davis
2019-03-19 21:58 ` Rob Clark
2019-03-19 22:36 ` John Stultz
2019-03-20 9:16 ` Benjamin Gaignard
2019-03-20 14:44 ` Andrew F. Davis
2019-03-20 15:59 ` Benjamin Gaignard
2019-03-20 16:11 ` John Stultz
2019-03-15 20:34 ` Laura Abbott
2019-03-15 23:15 ` Jerome Glisse
2019-03-16 0:16 ` John Stultz
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=62d91a79-58ee-b2a0-7fb8-d38f32660fd1@ti.com \
--to=afd@ti.com \
--cc=astrachan@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fengc@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--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).