[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <776ec196-08dd-4308-4484-b6ef91d3d4e9@amd.com>
Date: Fri, 22 Oct 2021 08:32:45 +0200
From: Christian König <christian.koenig@....com>
To: John Stultz <john.stultz@...aro.org>,
Shuosheng Huang <huangshuosheng@...winnertech.com>
Cc: Sumit Semwal <sumit.semwal@...aro.org>,
Liam Mark <lmark@...eaurora.org>,
Laura Abbott <labbott@...hat.com>,
Brian Starkey <Brian.Starkey@....com>,
linux-media <linux-media@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] dma-buf: heaps: init heaps in subsys_initcall
Am 22.10.21 um 04:56 schrieb John Stultz:
> On Thu, Oct 21, 2021 at 6:49 PM Shuosheng Huang
> <huangshuosheng@...winnertech.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
Powered by blists - more mailing lists