> -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 2019年1月28日 16:00 > To: Peng Fan <[email protected]> > Cc: [email protected]; Stefano Stabellini <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; Andy Duan <[email protected]> > 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.
