Message-ID: <CAKMK7uHWajeGRRw44nd+EHQvFeXimpLf2YPczXogEOa47iQw+A@mail.gmail.com>
Date:   Tue, 5 Nov 2019 14:58:18 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     "Andrew F. Davis" <afd@...com>
Cc:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Sandeep Patil <sspatil@...gle.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        Liam Mark <lmark@...eaurora.org>, Yue Hu <huyue2@...ong.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Hridya Valsaraju <hridya@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Pratik Patel <pratikp@...eaurora.org>
Subject: Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules

On Tue, Nov 5, 2019 at 2:30 PM Andrew F. Davis <afd@...com> wrote:
>
> On 11/5/19 4:42 AM, Daniel Vetter 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@...ll.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 :-)
>
> Not sure what you mean here, hopefully all the heaps can be "in-tree"
> some day.
>
> https://patchwork.kernel.org/patch/10863957/

No idea this is good or bad, where's the userspace for it?

> Plus some non-caching heaps and one that forces early allocation of our
> PAT (gart like) IP.

Hm, so essentially we'd need to move _all_ drm allocators into dma-buf
heaps, for all drivers? Can't just do this for TI only ...

> All this stuff is going into our evil vendor tree next cycle (if not
> upstream by then :)), if we want some of these "specialty" heaps to go
> into generic kernel builds at some point they will need to be modules if
> the core is.
>
> Although I am still thinking Heaps should be always built in + system +
> CMA heaps, then the rando heaps could be modules if needed.

Yeah that's what I'd expected to happen. Speciality heaps for when you
have the relevant something unusual (and I'm not sure whether upstream
does want something unusual really, the above examples from you sound
a bit strange).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Powered by blists - more mailing lists