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@xxxxxxxxxxxxxx>
---
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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
