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>
In-Reply-To: <20191104095823.GD10326@phenom.ffwll.local>
From:   John Stultz <john.stultz@linaro.org>
Date:   Mon, 4 Nov 2019 10:57:44 -0800
Message-ID: <CALAqxLW_CoAn-KXki0dGKK+vo-R4CTnjt1Azrw=mRdL8BUFGWw@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 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.

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.

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.

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

thanks
-john