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

2011-03-21 Thread Guennadi Liakhovetski
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 
> Reported-by: Hans Verkuil 

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 
> +#include 
>  
> -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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2011-03-21 Thread Pawel Osciak
Hi Guennadi,

On Mon, Mar 21, 2011 at 03:47, Guennadi Liakhovetski
 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 
>> Reported-by: Hans Verkuil 
>
> 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,
-- 
Pawel Osciak
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html