From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ayan Halder Subject: Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION) Date: Fri, 18 Oct 2019 18:51:50 +0000 Message-ID: <20191018185150.GA27705@arm.com> References: <20190924162217.GA12974@arm.com> <20191009173742.GA2682@arm.com> <20191014090729.lwusl5zxa32a7uua@DESKTOP-E1NTVVP.localdomain> <20191018095516.inwes5avdeixl5nr@DESKTOP-E1NTVVP.localdomain> <20191018184123.GA10634@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20191018184123.GA10634@arm.com> Content-Language: en-US Content-ID: <642C8E9FFFC88D46B6E706AB8CD6778A@eurprd08.prod.outlook.com> Sender: linux-kernel-owner@vger.kernel.org To: Brian Starkey Cc: Sudipto Paul , Vincent Donnefort , lkml , Chenbo Feng , Alistair Strachan , Liam Mark , "Andrew F. Davis" , Christoph Hellwig , DRI mailing list , Hridya Valsaraju , nd , Pratik Patel , "john.stultz@linaro.org" List-Id: dri-devel@lists.freedesktop.org ++ john.stultz@linaro.org (Sorry, somehow I am missing your email while sending. :( ) On Fri, Oct 18, 2019 at 06:41:24PM +0000, Ayan Halder wrote: > On Fri, Oct 18, 2019 at 09:55:17AM +0000, Brian Starkey wrote: > > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote: > > > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote: > > > > On 10/17/19 3:14 PM, John Stultz wrote: > > > > > But if the objection stands, do you have a proposal for an altern= ative > > > > > way to enumerate a subset of CMA heaps? > > > > > > > > > When in staging ION had to reach into the CMA framework as the othe= r > > > > direction would not be allowed, so cma_for_each_area() was added. I= f > > > > DMA-BUF heaps is not in staging then we can do the opposite, and ha= ve > > > > the CMA framework register heaps itself using our framework. That w= ay > > > > the CMA system could decide what areas to export or not (maybe base= d on > > > > a DT property or similar). > > >=20 > > > Ok. Though the CMA core doesn't have much sense of DT details either, > > > so it would probably have to be done in the reserved_mem logic, which > > > doesn't feel right to me. > > >=20 > > > I'd probably guess we should have some sort of dt binding to describe > > > a dmabuf cma heap and from that node link to a CMA node via a > > > memory-region phandle. Along with maybe the default heap as well? Not > > > eager to get into another binding review cycle, and I'm not sure what > > > non-DT systems will do yet, but I'll take a shot at it and iterate. > > >=20 > > > > The end result is the same so we can make this change later (it has= to > > > > come after DMA-BUF heaps is in anyway). > > >=20 > > > Well, I'm hesitant to merge code that exposes all the CMA heaps and > > > then add patches that becomes more selective, should anyone depend on > > > the initial behavior. :/ > >=20 > > How about only auto-adding the system default CMA region (cma->name =3D= =3D > > "reserved")? > >=20 > > And/or the CMA auto-add could be behind a config option? It seems a > > shame to further delay this, and the CMA heap itself really is useful. > > > A bit of a detour, comming back to the issue why the following node > was not getting detected by the dma-buf heaps framework. >=20 > reserved-memory { > #address-cells =3D <2>; > #size-cells =3D <2>; > ranges; >=20 > display_reserved: framebuffer@60000000 { > compatible =3D "shared-dma-pool"; > linux,cma-default; > reusable; <<<<<<<<<<<<-----------This was missing= in our > earlier node > reg =3D <0 0x60000000 0 0x08000000>; > }; > =20 > Quoting reserved-memory.txt :- > "The operating system can use the memory in this region with the limitati= on that > the device driver(s) owning the region need to be able to reclaim it bac= k" >=20 > Thus as per my observation, without 'reusable', rmem_cma_setup() > returns -EINVAL and the reserved-memory is not added as a cma region. >=20 > With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as fo= llows :- >=20 > [ 0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110 cma_init_reserved_a= reas+0xec/0x22c > [ 0.458415] Modules linked in: = =20 > [ 0.461470] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc4-01377-= g51dbcf03884c-dirty #15 =20 > [ 0.470017] Hardware name: ARM Juno development board (r0) (DT) = =20 > [ 0.475953] pstate: 80000005 (Nzcv daif -PAN -UAO) = =20 > [ 0.480755] pc : cma_init_reserved_areas+0xec/0x22c =20 > [ 0.485643] lr : cma_init_reserved_areas+0xe8/0x22c=20 > <----snip register dump ---> >=20 > [ 0.600646] Unable to handle kernel paging request at virtual address = ffff7dffff800000 > [ 0.608591] Mem abort info: > [ 0.611386] ESR =3D 0x96000006 > <---snip uninteresting bits ---> > [ 0.681069] pc : cma_init_reserved_areas+0x114/0x22c > [ 0.686043] lr : cma_init_reserved_areas+0xe8/0x22c >=20 >=20 > I am looking into this now. My final objective is to get "/dev/dma_heap/f= ramebuffer" > (as a cma heap). > Any leads? >=20 > > Cheers, > > -Brian > >=20 > > >=20 > > > So, , I'll start on the rework for the CMA bits. > > >=20 > > > That said, I'm definitely wanting to make some progress on this patch > > > series, so maybe we can still merge the core/helpers/system heap and > > > just hold the cma heap for a rework on the enumeration bits. That way > > > we can at least get other folks working on switching their vendor > > > heaps from ION. > > >=20 > > > Sumit: Does that sound ok? Assuming no other objections, can you take > > > the v11 set minus the CMA heap patch? > > >=20 > > > thanks > > > -john > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel