Messages in this thread | | | Subject | Re: [PATCH] mm: export cma alloc and release | From | Mark Salyzyn <> | Date | Mon, 7 Oct 2019 10:06:40 -0700 |
| |
On 10/7/19 9:53 AM, Christoph Hellwig wrote: > On Mon, Oct 07, 2019 at 09:50:31AM -0700, Mark Salyzyn wrote: >> On 10/5/19 1:37 AM, Christoph Hellwig wrote: >>> On Thu, Oct 03, 2019 at 09:55:28AM +0100, Catalin Marinas wrote: >>>> Aren't drivers supposed to use the DMA API for such allocations rather >>>> than invoking cma_*() directly? >>> Yes, they are. >> We have an engineer assigned to rewriting the ion memory driver to use >> dma_buf interfaces. Hopefully that effort will solve the problem of >> requiring these interfaces to be exported so that that driver (and others) >> can be modularized. >> >> Thanks for the reviews, drop this patch from the list and we will regroup, >> and accept that standing code in the kernel can not be modularized for the >> moment. > How is that different from the "DMA-BUF Heaps (destaging ION)" series > floating around?
IDK, I am asking around because I am only superficially aware of that effort. Please view this as the left hand does not know what the right hand is doing. My issue was with a series of out-of-tree drivers that use the calls, and noted that currently the ion driver is using them as well, as rationalization for a 'user' for the export. I am pushing back on those out-of-tree drivers to switch their CMA interfaces to a modern approach as a result of these reviews; the result of this review had a positive effect because I was considering exporting them in the Android distro as a minimum, and now I am soundly rejecting that approach.
Sincerely -- Mark Salyzyn
| |