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> <CALAqxLWvNOL=Exybb25GgYQujyJcPNTsFuaBnjLQPKTkVAi6Xw@mail.gmail.com>
 <CAKMK7uFSBNqVWy0N-GH7CzH-R7c9CVb97LgCffdMzGCgvVan4Q@mail.gmail.com>
In-Reply-To: <CAKMK7uFSBNqVWy0N-GH7CzH-R7c9CVb97LgCffdMzGCgvVan4Q@mail.gmail.com>
From:   John Stultz <john.stultz@linaro.org>
Date:   Tue, 5 Nov 2019 11:47:53 -0800
Message-ID: <CALAqxLV+MfESanq+PenRUNR_w6KZT1KQ7suPjmiT-bdAFx83EA@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 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.

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

thanks
-john