From: John Stultz <john.stultz@linaro.org> 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> Subject: Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules Date: Mon, 4 Nov 2019 10:57:44 -0800 [thread overview] Message-ID: <CALAqxLW_CoAn-KXki0dGKK+vo-R4CTnjt1Azrw=mRdL8BUFGWw@mail.gmail.com> (raw) In-Reply-To: <20191104095823.GD10326@phenom.ffwll.local> 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
WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org> To: Daniel Vetter <daniel@ffwll.ch> Cc: Sandeep Patil <sspatil@google.com>, Chenbo Feng <fengc@google.com>, Alistair Strachan <astrachan@google.com>, Liam Mark <lmark@codeaurora.org>, lkml <linux-kernel@vger.kernel.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>, Mike Rapoport <rppt@linux.ibm.com>, Pratik Patel <pratikp@codeaurora.org> Subject: Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules Date: Mon, 4 Nov 2019 10:57:44 -0800 [thread overview] Message-ID: <CALAqxLW_CoAn-KXki0dGKK+vo-R4CTnjt1Azrw=mRdL8BUFGWw@mail.gmail.com> (raw) In-Reply-To: <20191104095823.GD10326@phenom.ffwll.local> 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-04 18:57 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-25 23:48 [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules John Stultz 2019-10-25 23:48 ` John Stultz 2019-10-25 23:48 ` [RFC][PATCH 1/2] mm: cma: Export cma symbols for cma heap as a module John Stultz 2019-10-25 23:48 ` John Stultz 2019-10-28 7:46 ` Christoph Hellwig 2019-10-28 18:39 ` John Stultz 2019-10-28 18:39 ` John Stultz 2019-10-28 22:23 ` John Stultz 2019-10-28 22:23 ` John Stultz 2019-10-28 19:12 ` sspatil 2019-10-28 19:12 ` sspatil 2019-10-28 20:03 ` John Stultz 2019-10-28 20:03 ` John Stultz 2019-10-28 22:26 ` John Stultz 2019-10-28 22:26 ` John Stultz 2019-10-25 23:48 ` [RFC][PATCH 2/2] dma-buf: heaps: Allow system & cma heaps to be configured as a modules John Stultz 2019-10-25 23:48 ` John Stultz 2019-11-04 9:45 ` Brian Starkey 2019-11-04 9:45 ` Brian Starkey 2019-11-04 10:24 ` Daniel Vetter 2019-11-04 10:24 ` Daniel Vetter 2019-11-04 19:00 ` John Stultz 2019-11-04 19:00 ` John Stultz 2019-11-04 9:58 ` [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules Daniel Vetter 2019-11-04 9:58 ` Daniel Vetter 2019-11-04 18:57 ` John Stultz [this message] 2019-11-04 18:57 ` John Stultz 2019-11-05 9:42 ` Daniel Vetter 2019-11-05 9:42 ` Daniel Vetter 2019-11-05 13:30 ` Andrew F. Davis 2019-11-05 13:30 ` Andrew F. Davis 2019-11-05 13:58 ` Daniel Vetter 2019-11-05 13:58 ` Daniel Vetter 2019-11-05 17:41 ` John Stultz 2019-11-05 17:41 ` John Stultz 2019-11-05 19:18 ` Daniel Vetter 2019-11-05 19:18 ` Daniel Vetter 2019-11-05 19:47 ` John Stultz 2019-11-05 19:47 ` John Stultz 2019-11-05 20:21 ` Daniel Vetter 2019-11-05 20:21 ` Daniel Vetter 2019-11-12 0:56 ` Sandeep Patil 2019-11-12 0:56 ` Sandeep Patil 2019-11-12 0:49 ` Sandeep Patil 2019-11-12 0:49 ` Sandeep Patil
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CALAqxLW_CoAn-KXki0dGKK+vo-R4CTnjt1Azrw=mRdL8BUFGWw@mail.gmail.com' \ --to=john.stultz@linaro.org \ --cc=afd@ti.com \ --cc=akpm@linux-foundation.org \ --cc=astrachan@google.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=fengc@google.com \ --cc=hridya@google.com \ --cc=huyue2@yulong.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lmark@codeaurora.org \ --cc=pratikp@codeaurora.org \ --cc=rppt@linux.ibm.com \ --cc=sspatil@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.