[2/2] videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t

Message ID 1300109904-3991-2-git-send-email-pawel@osciak.com (mailing list archive)
State Superseded, archived
Headers

Commit Message

Pawel Osciak March 14, 2011, 1:38 p.m. UTC
  dma_addr_t may not fit into void* on some architectures. To be safe, make
vb2_dma_contig_cookie() return a pointer to dma_addr_t and dereference it
in vb2_dma_contig_plane_paddr() back to dma_addr_t.

Signed-off-by: Pawel Osciak <pawel@osciak.com>
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
---
 drivers/media/video/videobuf2-dma-contig.c |    2 +-
 include/media/videobuf2-dma-contig.h       |    9 ++++++---
 2 files changed, 7 insertions(+), 4 deletions(-)
  

Comments

Guennadi Liakhovetski March 21, 2011, 10:47 a.m. UTC | #1
On Mon, 14 Mar 2011, Pawel Osciak wrote:

> dma_addr_t may not fit into void* on some architectures. To be safe, make
> vb2_dma_contig_cookie() return a pointer to dma_addr_t and dereference it
> in vb2_dma_contig_plane_paddr() back to dma_addr_t.
> 
> Signed-off-by: Pawel Osciak <pawel@osciak.com>
> Reported-by: Hans Verkuil <hverkuil@xs4all.nl>

Right, it is correct, that this patch is submitted as "2/2" with 
"sh_mobile_ceu_camera: Do not call vb2's mem_ops directly" being "1/2." 
The only slight difficulty is, that this patch should go directly to 
Mauro or via some vb2 tree, if one exists, whereas "1/2" I would normally 
take via my tree. Hence the question: should I take them both via my tree, 
or should I only take "1/2" and we take care to merge this one after it? 
Assuming, there are no objections against this one.

Thanks
Guennadi

> ---
>  drivers/media/video/videobuf2-dma-contig.c |    2 +-
>  include/media/videobuf2-dma-contig.h       |    9 ++++++---
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c
> index 90495b7..58205d5 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -78,7 +78,7 @@ static void *vb2_dma_contig_cookie(void *buf_priv)
>  {
>  	struct vb2_dc_buf *buf = buf_priv;
>  
> -	return (void *)buf->paddr;
> +	return &buf->paddr;
>  }
>  
>  static void *vb2_dma_contig_vaddr(void *buf_priv)
> diff --git a/include/media/videobuf2-dma-contig.h b/include/media/videobuf2-dma-contig.h
> index 1d6188d..7e6c68b 100644
> --- a/include/media/videobuf2-dma-contig.h
> +++ b/include/media/videobuf2-dma-contig.h
> @@ -14,11 +14,14 @@
>  #define _MEDIA_VIDEOBUF2_DMA_COHERENT_H
>  
>  #include <media/videobuf2-core.h>
> +#include <linux/dma-mapping.h>
>  
> -static inline unsigned long vb2_dma_contig_plane_paddr(
> -		struct vb2_buffer *vb, unsigned int plane_no)
> +static inline dma_addr_t
> +vb2_dma_contig_plane_paddr(struct vb2_buffer *vb, unsigned int plane_no)
>  {
> -	return (unsigned long)vb2_plane_cookie(vb, plane_no);
> +	dma_addr_t *paddr = vb2_plane_cookie(vb, plane_no);
> +
> +	return *paddr;
>  }
>  
>  void *vb2_dma_contig_init_ctx(struct device *dev);
> -- 
> 1.7.4.1
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
Pawel Osciak March 21, 2011, 1:38 p.m. UTC | #2
Hi Guennadi,

On Mon, Mar 21, 2011 at 03:47, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> On Mon, 14 Mar 2011, Pawel Osciak wrote:
>
>> dma_addr_t may not fit into void* on some architectures. To be safe, make
>> vb2_dma_contig_cookie() return a pointer to dma_addr_t and dereference it
>> in vb2_dma_contig_plane_paddr() back to dma_addr_t.
>>
>> Signed-off-by: Pawel Osciak <pawel@osciak.com>
>> Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
>
> Right, it is correct, that this patch is submitted as "2/2" with
> "sh_mobile_ceu_camera: Do not call vb2's mem_ops directly" being "1/2."
> The only slight difficulty is, that this patch should go directly to
> Mauro or via some vb2 tree, if one exists, whereas "1/2" I would normally
> take via my tree. Hence the question: should I take them both via my tree,
> or should I only take "1/2" and we take care to merge this one after it?
> Assuming, there are no objections against this one.

I attached 2/2 for reference, please take 1/2 and I will take care to
ask Mauro to pull 2/2, unless you prefer to pull both.

Thanks,
  

Patch

diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c
index 90495b7..58205d5 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -78,7 +78,7 @@  static void *vb2_dma_contig_cookie(void *buf_priv)
 {
 	struct vb2_dc_buf *buf = buf_priv;
 
-	return (void *)buf->paddr;
+	return &buf->paddr;
 }
 
 static void *vb2_dma_contig_vaddr(void *buf_priv)
diff --git a/include/media/videobuf2-dma-contig.h b/include/media/videobuf2-dma-contig.h
index 1d6188d..7e6c68b 100644
--- a/include/media/videobuf2-dma-contig.h
+++ b/include/media/videobuf2-dma-contig.h
@@ -14,11 +14,14 @@ 
 #define _MEDIA_VIDEOBUF2_DMA_COHERENT_H
 
 #include <media/videobuf2-core.h>
+#include <linux/dma-mapping.h>
 
-static inline unsigned long vb2_dma_contig_plane_paddr(
-		struct vb2_buffer *vb, unsigned int plane_no)
+static inline dma_addr_t
+vb2_dma_contig_plane_paddr(struct vb2_buffer *vb, unsigned int plane_no)
 {
-	return (unsigned long)vb2_plane_cookie(vb, plane_no);
+	dma_addr_t *paddr = vb2_plane_cookie(vb, plane_no);
+
+	return *paddr;
 }
 
 void *vb2_dma_contig_init_ctx(struct device *dev);