[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191014090729.lwusl5zxa32a7uua@DESKTOP-E1NTVVP.localdomain>
Date: Mon, 14 Oct 2019 09:07:29 +0000
From: Brian Starkey <Brian.Starkey@....com>
To: "Andrew F. Davis" <afd@...com>
CC: Ayan Halder <Ayan.Halder@....com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Sudipto Paul <Sudipto.Paul@....com>,
Vincent Donnefort <Vincent.Donnefort@....com>,
Chenbo Feng <fengc@...gle.com>,
Alistair Strachan <astrachan@...gle.com>,
Liam Mark <lmark@...eaurora.org>,
lkml <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@...radead.org>,
DRI mailing list <dri-devel@...ts.freedesktop.org>,
Hridya Valsaraju <hridya@...gle.com>, nd <nd@....com>,
Pratik Patel <pratikp@...eaurora.org>
Subject: Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
Hi Andrew,
On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
> The CMA driver that registers these nodes will have to be expanded to
> export them using this framework as needed. We do something similar to
> export SRAM nodes:
>
> https://lkml.org/lkml/2019/3/21/575
>
> Unlike the system/default-cma driver which can be centralized in the
> tree, these extra exporters will probably live out in other subsystems
> and so are added in later steps.
>
> Andrew
I was under the impression that the "cma_for_each_area" loop in patch
4 would do that (add_cma_heaps). Is it not the case?
Thanks,
-Brian
Powered by blists - more mailing lists