> -----Original Message----- > From: h...@infradead.org [mailto:h...@infradead.org] > Sent: 2019年1月28日 16:00 > To: Peng Fan <peng....@nxp.com> > Cc: h...@infradead.org; Stefano Stabellini <sstabell...@kernel.org>; > m...@redhat.com; jasow...@redhat.com; xen-de...@lists.xenproject.org; > linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; > virtualizat...@lists.linux-foundation.org; l...@kernel.org; jgr...@suse.com; > boris.ostrov...@oracle.com; Andy Duan <fugang.d...@nxp.com> > Subject: Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain > > On Fri, Jan 25, 2019 at 09:45:26AM +0000, Peng Fan wrote: > > Just have a question, > > > > Since vmalloc_to_page is ok for cma area, no need to take cma and per > > device cma into consideration right? > > The CMA area itself it a physical memory region. If it is a non-highmem > region you can call virt_to_page on the virtual addresses for it. If it is in > highmem it doesn't even have a kernel virtual address by default. > > > we only need to implement a piece code to handle per device specific > > region using RESERVEDMEM_OF_DECLARE, just like: > > RESERVEDMEM_OF_DECLARE(rpmsg-dma, "rpmsg-dma-pool", > > rmem_rpmsg_dma_setup); And implement the device_init call back and > > build a map between page and phys. > > Then in rpmsg driver, scatter list could use page structure, no need > > vmalloc_to_page for per device dma. > > > > Is this the right way? > > I think this should work fine. If you have the cycles for it I'd actually > love to > be able to have generic CMA DT glue for non DMA API driver allocations, as > there obviously is a need for it. So basically the same as above, just added > to kernel/cma.c as a generic API.
Thanks for the hints. I'll try to add that. Thanks, Peng.
