lkml.org 
[lkml]   [2019]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm: export cma alloc and release
From
Date
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

\
 
 \ /
  Last update: 2019-10-07 19:07    [W:0.045 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site