Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191025234834.28214-1-john.stultz@linaro.org>
 <20191104095823.GD10326@phenom.ffwll.local> <CALAqxLW_CoAn-KXki0dGKK+vo-R4CTnjt1Azrw=mRdL8BUFGWw@mail.gmail.com>
 <20191105094259.GX10326@phenom.ffwll.local>
In-Reply-To: <20191105094259.GX10326@phenom.ffwll.local>
From:   John Stultz <john.stultz@linaro.org>
Date:   Tue, 5 Nov 2019 09:41:44 -0800
Message-ID: <CALAqxLWvNOL=Exybb25GgYQujyJcPNTsFuaBnjLQPKTkVAi6Xw@mail.gmail.com>
Subject: Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules
To:     Daniel Vetter <daniel@ffwll.ch>
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

> > 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.


> > With Android's GKI effort, there needs to be one kernel that works on
> > all the devices, and they are using modules to try to minimize the
> > amount of memory spent on functionality that isn't universally needed.
> > So on devices that don't need the CMA heap, they'd probably prefer not
> > to load the CMA dmabuf heap driver, so it would be best if it could be
> > built as a module.  If we want to build the CMA heap as a module, the
> > symbols it uses need to be exported.
>
> Yeah, I guess I'm disagreeing on whether dma-buf heaps are core or not.

That's fine to dispute. I'm not really in a place to assert one way or
not, but the Android folks have made their ION system and CMA heaps
loadable via a module, so it would seem like having the dmabuf system
and CMA heaps be modular would be useful to properly replace that
usage.

For instance, the system heap as a module probably doesn't make much
sense, as most boards that want to use the dmabuf heaps interface are
likely to use that as well.  CMA is more optional as not all boards
will use that one, so it might make sense to avoid loading it.

Sandeep: Can you chime in here as to how critical having the system
and cma heaps be modules are?


> > > Exporting symbols for no real in-tree users feels fishy.
> >
> > I'm submitting an in-tree user here. So I'm not sure what you mean?  I
> > suspect you're thinking there is some hidden/nefarious plan here, but
> > really there isn't.
>
> I was working under the assumption that you're only exporting the symbols
> for other heaps, and keep the current ones in-tree.

No. I'm trying to allow the (hopefully-soon-to-be-in-tree) system and
cma heap drivers to be loaded from a module.
If other heaps need exports, they can submit their heaps upstream and
argue for the exported symbols themselves.

> Are there even any
> out-of-tree dma-buf heaps still? out-of-tree and legit different use-case
> I mean ofc, not just out-of-tree because inertia :-)

So as Andrew mentioned, he has some dmabuf heaps he's working on at
TI.  From what I've heard the qualcomm folks like the dmabuf heaps
approach, but I'm not sure if they've taken a pass at converting their
vendor ION heaps to it yet.

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.

thanks
-john