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;
Date:   Tue, 5 Nov 2019 10:42:59 +0100
From:   Daniel Vetter <daniel@ffwll.ch>
To:     John Stultz <john.stultz@linaro.org>
Cc:     Daniel Vetter <daniel@ffwll.ch>,
        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
Message-ID: <20191105094259.GX10326@phenom.ffwll.local>
Mail-Followup-To: John Stultz <john.stultz@linaro.org>,
        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>
References: <20191025234834.28214-1-john.stultz@linaro.org>
 <20191104095823.GD10326@phenom.ffwll.local>
 <CALAqxLW_CoAn-KXki0dGKK+vo-R4CTnjt1Azrw=mRdL8BUFGWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALAqxLW_CoAn-KXki0dGKK+vo-R4CTnjt1Azrw=mRdL8BUFGWw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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:
> > > Now that the DMA BUF heaps core code has been queued, I wanted
> > > to send out some of the pending changes that I've been working
> > > on.
> > >
> > > For use with Android and their GKI effort, it is desired that
> > > DMA BUF heaps are able to be loaded as modules. This is required
> > > for migrating vendors off of ION which was also recently changed
> > > to support modules.
> > >
> > > So this patch series simply provides the necessary exported
> > > symbols and allows the system and CMA drivers to be built
> > > as modules.
> > >
> > > Due to the fact that dmabuf's allocated from a heap may
> > > be in use for quite some time, there isn't a way to safely
> > > unload the driver once it has been loaded. Thus these
> > > drivers do no implement module_exit() functions and will
> > > show up in lsmod as "[permanent]"
> > >
> > > Feedback and thoughts on this would be greatly appreciated!
> >
> > Do we actually want this?
> 
> I guess that always depends on the definition of "we" :)
> 
> > I figured if we just state that vendors should set up all the right
> > dma-buf heaps in dt, is that not enough?
> 
> 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?

> 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 :-)

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

> > 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. 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 :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch