From: Daniel Vetter <daniel@ffwll.ch>
To: John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
Sandeep Patil <sspatil@google.com>,
Mike Rapoport <rppt@linux.ibm.com>,
Chenbo Feng <fengc@google.com>,
Alistair Strachan <astrachan@google.com>,
Liam Mark <lmark@codeaurora.org>, Yue Hu <huyue2@yulong.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Andrew F . Davis" <afd@ti.com>,
Hridya Valsaraju <hridya@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pratik Patel <pratikp@codeaurora.org>
Subject: Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules
Date: Tue, 5 Nov 2019 21:21:48 +0100 [thread overview]
Message-ID: <CAKMK7uETgyRSerpjDvkF=b5SCf-Vj++uHFs6ckui6ZbFP-Si3g@mail.gmail.com> (raw)
In-Reply-To: <CALAqxLV+MfESanq+PenRUNR_w6KZT1KQ7suPjmiT-bdAFx83EA@mail.gmail.com>
On Tue, Nov 5, 2019 at 8:48 PM John Stultz <john.stultz@linaro.org> wrote:
>
> On Tue, Nov 5, 2019 at 11:19 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Nov 5, 2019 at 6:41 PM John Stultz <john.stultz@linaro.org> wrote:
> > > On Tue, Nov 5, 2019 at 1:43 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote:
> > > > > On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > On Fri, Oct 25, 2019 at 11:48:32PM +0000, John Stultz wrote:
> > > > > So even if the heaps are configured via DT (which at the moment there
> > > > > is no such binding, so that's not really a valid method yet), there's
> > > > > still the question of if the heap is necessary/makes sense on the
> > > > > device. And the DT would only control the availability of the heap
> > > > > interface, not if the heap driver is loaded or not.
> > > >
> > > > Hm I thought the cma regions are configured in DT? How does that work if
> > > > it's not using DT?
> > >
> > > So yea, CMA regions are either configured by DT or setup at build time
> > > (I think there's a cmdline option to set it up as well).
> > >
> > > But the CMA regions and the dmabuf cma heap driver are separate
> > > things. The latter uses the former.
> >
> > Huh, I assumed the plan is that whenever there's a cma region, we want
> > to instantiate a dma-buf heap for it? Why/when would we not want to do
> > that?
>
> Not quite. Andrew noted that we may not want to expose all CMA regions
> via dmabuf heaps, so right now we only expose the default region. I
> have follow on patches that I sent out earlier (which requires a
> to-be-finalized DT binding) which allows us to specify which other CMA
> regions to expose.
Why do we not want to expose them all? I figured if there's a cma
heap, then a device you have needs it, and if that's the case you
might want to allocate for that device from the heap? Maybe link to
the discussion?
> > > > > On the HiKey/HiKey960 boards, we have to allocate contiguous buffers
> > > > > for the display framebuffer. So gralloc uses ION to allocate from the
> > > > > CMA heap. However on the db845c, it has no such restrictions, so the
> > > > > CMA heap isn't necessary.
> > > >
> > > > Why do you have a CMA region for the 2nd board if you don't need it?
> > > > _That_ sounds like some serious memory waster, not a few lines of code
> > > > loaded for nothing :-)
> > >
> > > ??? That's not what I said above. If the db845c doesn't need CMA it
> > > won't have a CMA region.
> > >
> > > The issue at hand is that we may want to avoid loading the dmabuf CMA
> > > heap driver on a board that doesn't use CMA.
> >
> > So the CMA core code is also a module, or how does that work? Not
>
> No. CMA core isn't available as a module.
>
> > loading the cma dma-buf heap, but keeping all the other cma code
> > around feels slightly silly. Do we have numbers that justify this
> > silliness?
>
> I agree that is maybe not the most critical item on the list, but its
> one of many that do add up over time.
>
> Again, I'll defer to Sandeep or other folks on the Google side to help
> with the importance here. Mostly I'm trying to ensure there is
> functional parity to ION so we don't give folks any reason they could
> object to deprecating it.
>
> > > The main reason I'm only submitting system and CMA is because those
> > > are the only two I personally have a user for (HiKey/HiKey960 boards).
> > > It's my hope that once we deprecate ION in Android, vendors will
> > > migrate and we'll be able to push them to upstream their heaps as
> > > well.
> >
> > I think for upstream I'd want to see those other heaps first. If
> > they're mostly driver allocators exposed as heaps, then I think we
> > need something different than heap modules, maybe allow dma-buf to
> > allocate from drivers instead. But afaiui all such driver allocators
> > we have in upstream are cma regions only right now.
>
> I'm sorry, I'm not sure I understand what you mean here (I'm not sure
> what action I should be taking). Could you clarify this point?
I'm not sold on the use-case for this, but maybe if I see the actual
use-cases I might be swayed. A very basic/minimal "register a new
dma-buf heap" function should be all that's really needed for android,
so maybe we can start with that?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2019-11-05 20:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 23:48 [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules John Stultz
2019-10-25 23:48 ` [RFC][PATCH 1/2] mm: cma: Export cma symbols for cma heap as a module John Stultz
2019-10-28 7:46 ` Christoph Hellwig
2019-10-28 18:39 ` John Stultz
2019-10-28 22:23 ` John Stultz
2019-10-28 19:12 ` sspatil
2019-10-28 20:03 ` John Stultz
2019-10-28 22:26 ` John Stultz
2019-10-25 23:48 ` [RFC][PATCH 2/2] dma-buf: heaps: Allow system & cma heaps to be configured as a modules John Stultz
2019-11-04 9:45 ` Brian Starkey
2019-11-04 10:24 ` Daniel Vetter
2019-11-04 19:00 ` John Stultz
2019-11-04 9:58 ` [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules Daniel Vetter
2019-11-04 18:57 ` John Stultz
2019-11-05 9:42 ` Daniel Vetter
2019-11-05 13:30 ` Andrew F. Davis
2019-11-05 13:58 ` Daniel Vetter
2019-11-05 17:41 ` John Stultz
2019-11-05 19:18 ` Daniel Vetter
2019-11-05 19:47 ` John Stultz
2019-11-05 20:21 ` Daniel Vetter [this message]
2019-11-12 0:56 ` Sandeep Patil
2019-11-12 0:49 ` Sandeep Patil
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='CAKMK7uETgyRSerpjDvkF=b5SCf-Vj++uHFs6ckui6ZbFP-Si3g@mail.gmail.com' \
--to=daniel@ffwll.ch \
--cc=afd@ti.com \
--cc=akpm@linux-foundation.org \
--cc=astrachan@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fengc@google.com \
--cc=hridya@google.com \
--cc=huyue2@yulong.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lmark@codeaurora.org \
--cc=pratikp@codeaurora.org \
--cc=rppt@linux.ibm.com \
--cc=sspatil@google.com \
/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).