All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.