[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ae73c39-9049-bcf6-775f-b0817ba0ec5f@redhat.com>
Date: Sat, 19 Jan 2019 08:50:41 -0800
From: Laura Abbott <labbott@...hat.com>
To: Christoph Hellwig <hch@...radead.org>,
Liam Mark <lmark@...eaurora.org>
Cc: sumit.semwal@...aro.org, arve@...roid.com, tkjos@...roid.com,
maco@...roid.com, joel@...lfernandes.org, christian@...uner.io,
devel@...verdev.osuosl.org, dri-devel@...ts.freedesktop.org,
linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
afd@...com, john.stultz@...aro.org
Subject: Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping
attributes
On 1/19/19 2:25 AM, Christoph Hellwig wrote:
> On Fri, Jan 18, 2019 at 10:37:46AM -0800, Liam Mark wrote:
>> Add support for configuring dma mapping attributes when mapping
>> and unmapping memory through dma_buf_map_attachment and
>> dma_buf_unmap_attachment.
>>
>> Signed-off-by: Liam Mark <lmark@...eaurora.org>
>
> And who is going to decide which ones to pass? And who documents
> which ones are safe?
>
> I'd much rather have explicit, well documented dma-buf flags that
> might get translated to the DMA API flags, which are not error checked,
> not very well documented and way to easy to get wrong.
>
I'm not sure having flags in dma-buf really solves anything
given drivers can use the attributes directly with dma_map
anyway, which is what we're looking to do. The intention
is for the driver creating the dma_buf attachment to have
the knowledge of which flags to use.
Thanks,
Laura
Powered by blists - more mailing lists