[PATCH v2] dma-buf: heaps: init heaps in subsys_initcall

[PATCH v2] dma-buf: heaps: init heaps in subsys_initcall

[Shuosheng Huang]

Some built-in modules will failed to use dma-buf heap to allocate
memory if the heap drivers are too late to be initialized.
To fix this issue, move initialization of dma-buf heap drivers in
subsys_initcall() which is more earlier to be called.

Signed-off-by: Shuosheng Huang <huangshuosheng@allwinnertech.com>
---
 drivers/dma-buf/heaps/cma_heap.c    | 2 +-
 drivers/dma-buf/heaps/system_heap.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 0c05b79870f9..e051403a346d 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -400,6 +400,6 @@ static int add_default_cma_heap(void)
 
 	return ret;
 }
-module_init(add_default_cma_heap);
+subsys_initcall(add_default_cma_heap);
 MODULE_DESCRIPTION("DMA-BUF CMA Heap");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74ef966..3d6927657ec9 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -435,5 +435,5 @@ static int system_heap_create(void)
 
 	return 0;
 }
-module_init(system_heap_create);
+subsys_initcall(system_heap_create);
 MODULE_LICENSE("GPL v2");
-- 
2.29.0

Re: [PATCH v2] dma-buf: heaps: init heaps in subsys_initcall

[John Stultz]

On Thu, Oct 21, 2021 at 6:49 PM Shuosheng Huang
<huangshuosheng@allwinnertech.com> wrote:
>
> Some built-in modules will failed to use dma-buf heap to allocate
> memory if the heap drivers are too late to be initialized.
> To fix this issue, move initialization of dma-buf heap drivers in
> subsys_initcall() which is more earlier to be called.

Hey! Thanks so much for sending this out! I appreciate it!

So the change looks pretty straightforward to me, however, the
rationale for it is where we hit problems.

With the upstream kernel, there are not yet any modules that directly
allocate from dmabuf heaps. So in the context of the upstream kernel,
the reasoning doesn't make much sense.

Now, I know folks have their own drivers that want to allocate from
dmabuf heaps, but those haven't been submitted upstream yet.
So maybe can you submit those patches that need this along with this
change so it would make sense as part of a patch series? It would be
trivial to justify including this patch then.

thanks
-john

Re: [PATCH v2] dma-buf: heaps: init heaps in subsys_initcall

[Christian König]

Am 22.10.21 um 04:56 schrieb John Stultz:
> On Thu, Oct 21, 2021 at 6:49 PM Shuosheng Huang
> <huangshuosheng@allwinnertech.com> wrote:
>> Some built-in modules will failed to use dma-buf heap to allocate
>> memory if the heap drivers are too late to be initialized.
>> To fix this issue, move initialization of dma-buf heap drivers in
>> subsys_initcall() which is more earlier to be called.
> Hey! Thanks so much for sending this out! I appreciate it!
>
> So the change looks pretty straightforward to me, however, the
> rationale for it is where we hit problems.
>
> With the upstream kernel, there are not yet any modules that directly
> allocate from dmabuf heaps. So in the context of the upstream kernel,
> the reasoning doesn't make much sense.

I was already wondering which driver does that.

> Now, I know folks have their own drivers that want to allocate from
> dmabuf heaps, but those haven't been submitted upstream yet.
> So maybe can you submit those patches that need this along with this
> change so it would make sense as part of a patch series? It would be
> trivial to justify including this patch then.

Yes, agree. This patch here alone has no justification to be upstream.

Regards,
Christian.

>
> thanks
> -john