Messages in this thread | | | Subject | Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes | From | Laura Abbott <> | Date | Fri, 18 Jan 2019 14:45:02 -0800 |
| |
On 1/18/19 1:32 PM, Liam Mark wrote: > On Fri, 18 Jan 2019, Laura Abbott wrote: > >> On 1/18/19 10:37 AM, 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@codeaurora.org> >>> --- >>> include/linux/dma-buf.h | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h >>> index 58725f890b5b..59bf33e09e2d 100644 >>> --- a/include/linux/dma-buf.h >>> +++ b/include/linux/dma-buf.h >>> @@ -308,6 +308,8 @@ struct dma_buf { >>> * @dev: device attached to the buffer. >>> * @node: list of dma_buf_attachment. >>> * @priv: exporter specific attachment data. >>> + * @dma_map_attrs: DMA mapping attributes to be used in >>> + * dma_buf_map_attachment() and dma_buf_unmap_attachment(). >>> * >>> * This structure holds the attachment information between the dma_buf >>> buffer >>> * and its user device(s). The list contains one attachment struct per >>> device >>> @@ -323,6 +325,7 @@ struct dma_buf_attachment { >>> struct device *dev; >>> struct list_head node; >>> void *priv; >>> + unsigned long dma_map_attrs; >>> }; >>> /** >>> >> >> Did you miss part of this patch? This only adds it to the structure but >> doesn't >> add it to any API. The same commment applies to the follow up patch, >> I don't quite see how it's being used. >> > > Were you asking for a cleaner DMA-buf API to set this field or were you > asking for a change to an upstream client to make use of this field? > > I have clients set the dma_map_attrs field directly on their > dma_buf_attachment struct before calling dma_buf_map_attachment (if they > need this functionality). > Of course this is all being used in Android for out of tree drivers, but > I assume it is just as useful to everyone else who has cached ION buffers > which aren't always accessed by the CPU. > > My understanding is that AOSP Android on Hikey 960 also is currently > suffering from too many CMOs due to dma_map_attachemnt always applying > CMOs, so this support should help them avoid it. >
Ahhhh I see how you intend this to be used now! I was missing that clients would do attachment->dma_map_attrs = blah and that was how it would be stored as opposed to passing it in at the top level for dma_buf_map. I'll give this some more thought but I think it could work if Sumit is okay with the approach.
Thanks, Laura
| |