* [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
@ 2012-01-27 9:34 Sumit Semwal
2012-01-27 9:36 ` Semwal, Sumit
0 siblings, 1 reply; 9+ messages in thread
From: Sumit Semwal @ 2012-01-27 9:34 UTC (permalink / raw
To: dri-devel, linaro-mm-sig, linux-media; +Cc: Sumit Semwal
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction while unmapping.
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/Kconfig | 2 +-
drivers/base/dma-buf.c | 7 +++++--
include/linux/dma-buf.h | 8 +++++---
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 7be9f79..5edc5db 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -179,7 +179,7 @@ config GENERIC_CPU_DEVICES
source "drivers/base/regmap/Kconfig"
config DMA_SHARED_BUFFER
- bool
+ bool "Temporary mechanism to enable build of dma-buf"
default n
select ANON_INODES
depends on EXPERIMENTAL
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;
}
--
1.7.5.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
2012-01-27 9:34 [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op Sumit Semwal
@ 2012-01-27 9:36 ` Semwal, Sumit
0 siblings, 0 replies; 9+ messages in thread
From: Semwal, Sumit @ 2012-01-27 9:36 UTC (permalink / raw
To: dri-devel, linaro-mm-sig, linux-media; +Cc: Sumit Semwal
Please ignore! I will send out a new version in a minute.
Thanks and best regards,
~Sumit.
On Fri, Jan 27, 2012 at 3:04 PM, Sumit Semwal <sumit.semwal@ti.com> wrote:
> Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
> enum dma_data_direction while unmapping.
>
> 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/Kconfig | 2 +-
> drivers/base/dma-buf.c | 7 +++++--
> include/linux/dma-buf.h | 8 +++++---
> 3 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 7be9f79..5edc5db 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -179,7 +179,7 @@ config GENERIC_CPU_DEVICES
> source "drivers/base/regmap/Kconfig"
>
> config DMA_SHARED_BUFFER
> - bool
> + bool "Temporary mechanism to enable build of dma-buf"
> default n
> select ANON_INODES
> depends on EXPERIMENTAL
> 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;
> }
> --
> 1.7.5.4
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
@ 2012-01-27 9:43 Sumit Semwal
2012-01-27 15:49 ` Daniel Vetter
2012-01-30 14:19 ` Laurent Pinchart
0 siblings, 2 replies; 9+ messages in thread
From: Sumit Semwal @ 2012-01-27 9:43 UTC (permalink / raw
To: dri-devel, linaro-mm-sig, linux-media; +Cc: t.stanislaws, Sumit Semwal
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;
}
--
1.7.5.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
2012-01-27 9:43 Sumit Semwal
@ 2012-01-27 15:49 ` Daniel Vetter
2012-01-30 14:19 ` Laurent Pinchart
1 sibling, 0 replies; 9+ messages in thread
From: Daniel Vetter @ 2012-01-27 15:49 UTC (permalink / raw
To: Sumit Semwal; +Cc: dri-devel, linaro-mm-sig, linux-media, t.stanislaws
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>
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
2012-01-27 9:43 Sumit Semwal
2012-01-27 15:49 ` Daniel Vetter
@ 2012-01-30 14:19 ` Laurent Pinchart
2012-01-31 5:49 ` Semwal, Sumit
1 sibling, 1 reply; 9+ messages in thread
From: Laurent Pinchart @ 2012-01-30 14:19 UTC (permalink / raw
To: Sumit Semwal; +Cc: dri-devel, linaro-mm-sig, linux-media, t.stanislaws
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) ?
> {
> return;
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
2012-01-30 14:19 ` Laurent Pinchart
@ 2012-01-31 5:49 ` Semwal, Sumit
2012-01-31 9:42 ` Laurent Pinchart
0 siblings, 1 reply; 9+ messages in thread
From: Semwal, Sumit @ 2012-01-31 5:49 UTC (permalink / raw
To: Laurent Pinchart; +Cc: t.stanislaws, linaro-mm-sig, dri-devel, linux-media
[-- Attachment #1.1: Type: text/plain, Size: 3562 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 4700 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
2012-01-31 5:49 ` Semwal, Sumit
@ 2012-01-31 9:42 ` Laurent Pinchart
2012-01-31 10:36 ` Daniel Vetter
0 siblings, 1 reply; 9+ messages in thread
From: Laurent Pinchart @ 2012-01-31 9:42 UTC (permalink / raw
To: Semwal, Sumit; +Cc: dri-devel, t.stanislaws, linux-media, linaro-mm-sig
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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
2012-01-31 9:42 ` Laurent Pinchart
@ 2012-01-31 10:36 ` Daniel Vetter
2012-02-02 10:04 ` Laurent Pinchart
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Vetter @ 2012-01-31 10:36 UTC (permalink / raw
To: Laurent Pinchart
Cc: Semwal, Sumit, t.stanislaws, linaro-mm-sig, dri-devel,
linux-media
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
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op
2012-01-31 10:36 ` Daniel Vetter
@ 2012-02-02 10:04 ` Laurent Pinchart
0 siblings, 0 replies; 9+ messages in thread
From: Laurent Pinchart @ 2012-02-02 10:04 UTC (permalink / raw
To: Daniel Vetter
Cc: Semwal, Sumit, t.stanislaws, linaro-mm-sig, dri-devel,
linux-media
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_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
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.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-02-02 10:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-27 9:34 [PATCH] dma-buf: add dma_data_direction to unmap dma_buf_op Sumit Semwal
2012-01-27 9:36 ` Semwal, Sumit
-- strict thread matches above, loose matches on Subject: below --
2012-01-27 9:43 Sumit Semwal
2012-01-27 15:49 ` Daniel Vetter
2012-01-30 14:19 ` Laurent Pinchart
2012-01-31 5:49 ` Semwal, Sumit
2012-01-31 9:42 ` Laurent Pinchart
2012-01-31 10:36 ` Daniel Vetter
2012-02-02 10:04 ` Laurent Pinchart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).