Some exporters may use DMA map/unmap APIs in dma-buf ops, which require enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as a parameter.
Reported-by: Tomasz Stanislawski t.stanislaws@samsung.com Signed-off-by: Sumit Semwal sumit.semwal@ti.com --- drivers/base/dma-buf.c | 7 +++++-- include/linux/dma-buf.h | 8 +++++--- 2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 8afe2dd..c9a945f 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -271,16 +271,19 @@ EXPORT_SYMBOL_GPL(dma_buf_map_attachment); * dma_buf_ops. * @attach: [in] attachment to unmap buffer from * @sg_table: [in] scatterlist info of the buffer to unmap + * @direction: [in] direction of DMA transfer * */ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, - struct sg_table *sg_table) + struct sg_table *sg_table, + enum dma_data_direction direction) { if (WARN_ON(!attach || !attach->dmabuf || !sg_table)) return;
mutex_lock(&attach->dmabuf->lock); - attach->dmabuf->ops->unmap_dma_buf(attach, sg_table); + attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, + direction); mutex_unlock(&attach->dmabuf->lock);
} diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 86f6241..847b026 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -63,7 +63,8 @@ struct dma_buf_ops { struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *, enum dma_data_direction); void (*unmap_dma_buf)(struct dma_buf_attachment *, - struct sg_table *); + struct sg_table *, + enum dma_data_direction); /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY * if the call would block. */ @@ -122,7 +123,8 @@ void dma_buf_put(struct dma_buf *dmabuf);
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *, enum dma_data_direction); -void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *); +void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *, + enum dma_data_direction); #else
static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, @@ -166,7 +168,7 @@ static inline struct sg_table *dma_buf_map_attachment( }
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, - struct sg_table *sg) + struct sg_table *sg, enum dma_data_direction write) { return; }
On Fri, Jan 27, 2012 at 03:13:28PM +0530, Sumit Semwal wrote:
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as a parameter.
Reported-by: Tomasz Stanislawski t.stanislaws@samsung.com Signed-off-by: Sumit Semwal sumit.semwal@ti.com
Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch
Hi Sumit,
On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as a parameter.
Reported-by: Tomasz Stanislawski t.stanislaws@samsung.com Signed-off-by: Sumit Semwal sumit.semwal@ti.com
drivers/base/dma-buf.c | 7 +++++-- include/linux/dma-buf.h | 8 +++++--- 2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 8afe2dd..c9a945f 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -271,16 +271,19 @@ EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
- dma_buf_ops.
- @attach: [in] attachment to unmap buffer from
- @sg_table: [in] scatterlist info of the buffer to unmap
*/
- @direction: [in] direction of DMA transfer
void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
struct sg_table *sg_table)
struct sg_table *sg_table,enum dma_data_direction direction){ if (WARN_ON(!attach || !attach->dmabuf || !sg_table)) return;
mutex_lock(&attach->dmabuf->lock);
- attach->dmabuf->ops->unmap_dma_buf(attach, sg_table);
- attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
direction);} diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 86f6241..847b026 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -63,7 +63,8 @@ struct dma_buf_ops { struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *, enum dma_data_direction); void (*unmap_dma_buf)(struct dma_buf_attachment *,
struct sg_table *);
struct sg_table *,enum dma_data_direction);*/
- if the call would block.
@@ -122,7 +123,8 @@ void dma_buf_put(struct dma_buf *dmabuf);
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *, enum dma_data_direction); -void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *); +void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *, + enum dma_data_direction); #else
static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, @@ -166,7 +168,7 @@ static inline struct sg_table *dma_buf_map_attachment( }
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, - struct sg_table *sg)
struct sg_table *sg, enum dma_data_direction write)
s/write/dir/ (or direction) ?
{ return; }
Hi Laurent,
On Jan 30, 2012 7:48 PM, "Laurent Pinchart" < laurent.pinchart@ideasonboard.com> wrote:
Hi Sumit,
On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as a parameter.
Reported-by: Tomasz Stanislawski t.stanislaws@samsung.com Signed-off-by: Sumit Semwal sumit.semwal@ti.com
drivers/base/dma-buf.c | 7 +++++-- include/linux/dma-buf.h | 8 +++++--- 2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 8afe2dd..c9a945f 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -271,16 +271,19 @@ EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
- dma_buf_ops.
- @attach: [in] attachment to unmap buffer from
- @sg_table: [in] scatterlist info of the buffer to unmap
*/
- @direction: [in] direction of DMA transfer
void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
struct sg_table *sg_table)
struct sg_table *sg_table,enum dma_data_direction direction){ if (WARN_ON(!attach || !attach->dmabuf || !sg_table)) return;
mutex_lock(&attach->dmabuf->lock);
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table);
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,direction); mutex_unlock(&attach->dmabuf->lock);} diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 86f6241..847b026 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -63,7 +63,8 @@ struct dma_buf_ops { struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *, enum dma_data_direction); void (*unmap_dma_buf)(struct dma_buf_attachment *,
struct sg_table *);
struct sg_table *,enum dma_data_direction); /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY * if the call would block. */@@ -122,7 +123,8 @@ void dma_buf_put(struct dma_buf *dmabuf);
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *, enum dma_data_direction); -void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct
sg_table
*); +void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *, + enum dma_data_direction); #else
static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, @@ -166,7 +168,7 @@ static inline struct sg_table *dma_buf_map_attachment( }
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, - struct sg_table
*sg)
struct sg_table *sg, enum dma_data_direction
write)
s/write/dir/ (or direction) ?
:-) sure.
{ return; }
-- Regards,
Laurent Pinchart
Best regards, -Sumit.
Hi Sumit,
On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
struct sg_table *sg)
struct sg_table *sg, enum dma_data_direction write)
On a second thought, would it make sense to store the direction in struct dma_buf_attachment in dma_buf_map_attachment(), and pass the value directly to the .unmap_dma_buf() instead of requiring the dma_buf_unmap_attachment() caller to remember it ? Or is an attachment allowed to map the buffer several times with different directions ?
On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
Hi Sumit,
On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
struct sg_table *sg)
struct sg_table *sg, enum dma_data_direction write)On a second thought, would it make sense to store the direction in struct dma_buf_attachment in dma_buf_map_attachment(), and pass the value directly to the .unmap_dma_buf() instead of requiring the dma_buf_unmap_attachment() caller to remember it ? Or is an attachment allowed to map the buffer several times with different directions ?
Current dma api functions already require you to supply the direction argument on unmap and I think for cpu access I'm also leaning towards an interface where the importer has to supply the direction argument for both begin_access and end_access. So for consistency reasons I'm leaning towards adding it to unmap. -Daniel
Hi Daniel,
On Tuesday 31 January 2012 11:36:02 Daniel Vetter wrote:
On Tue, Jan 31, 2012 at 10:42:59AM +0100, Laurent Pinchart wrote:
Hi Sumit,
On Friday 27 January 2012 10:43:28 Sumit Semwal wrote:
[snip]
static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
struct sg_table *sg)
struct sg_table *sg, enum dma_data_directionwrite)
On a second thought, would it make sense to store the direction in struct dma_buf_attachment in dma_buf_map_attachment(), and pass the value directly to the .unmap_dma_buf() instead of requiring the dma_buf_unmap_attachment() caller to remember it ? Or is an attachment allowed to map the buffer several times with different directions ?
Current dma api functions already require you to supply the direction argument on unmap
If I understand it correctly, that's mostly because the DMA API doesn't keep track of DMA mappings in a way that it can store the direction on map(), and use it on unmap(). In this case we have an attachment object that we can use to cache the information.
and I think for cpu access I'm also leaning towards an interface where the importer has to supply the direction argument for both begin_access and end_access. So for consistency reasons I'm leaning towards adding it to unmap.
I'm OK with keeping the direction as an argument to unmap() if you think that's better.
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Laurent Pinchart -
Semwal, Sumit -
Sumit Semwal