RE: [PATCH 7/7] v4l: videobuf2: add CMA allocator

2010-12-06 Thread Marek Szyprowski
Hello,

On Saturday, December 04, 2010 11:47 PM Pawel Osciak wrote:

 Hi,
 please see my comments below.
 Also, if I could suggest something, please cut the code between
 functions, not inside them, it'll make it easier for others to find
 that location in the original code.

I always try to keep the code from the beginning of the function when I reply
and snip some not important parts of the mail. I must have missed something.

 On Wed, Dec 1, 2010 at 00:56, Marek Szyprowski m.szyprow...@samsung.com 
 wrote:
  Hello,
 
  On Wednesday, December 01, 2010 9:36 AM Jonghun Han wrote:
 
  Marek Szyprowski wrote:
  2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
   From: Pawel Osciak p.osc...@samsung.com
  
   Add support for the CMA contiguous memory allocator to videobuf2.
  
   Signed-off-by: Pawel Osciak p.osc...@samsung.com
   Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
   Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
   CC: Pawel Osciak pa...@osciak.com
   ---
 
  Hi Marek,
 
  snip
 
   +static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long 
   size)
 
  static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size,
                                                  const struct vb2_alloc_ctx
  *alloc_ctx)
  alloc_ctx can be useful for many cases.
 
  Yes, right, I will add it in the next version.
 
 
 Actually, I don't think so. Can you give an example of one of those
 many cases? There is no need to add unused arguments that can be
 useful in future just for the sake of future extensions, especially
 not in the kernel in such sensitive code. This function can
 potentially be called on each frame. And even more importantly, the
 whole allocator interface has been designed so that functions will not
 have to be vb2- or media-specific. Ideally, we should be able to hook
 up functions from mm and other modules. And such functions either use
 only vaddr and size, or have means of finding their contexts
 otherwise.
 If I remember correctly, this approach was actually suggested by
 Laurent and it makes a lot of sense. We want to be able to use third
 party kernel functions in allocators as much as possbile.

Allocator context is needed to set up IOMMU mapping and I don't see any reason
why to limit it only to mmap mode.

   +{
   +       struct vb2_cma_buf *buf;
   +       unsigned long paddr = 0;
   +       int ret;
   +
   +       buf = kzalloc(sizeof *buf, GFP_KERNEL);
   +       if (!buf)
   +               return ERR_PTR(-ENOMEM);
   +
   +       buf-vma = vb2_get_userptr(vaddr);
 
  vb2_get_vma looks good instead of vb2_get_userptr.
  How do you think about this ?
 
  Right, this will make the code easier to understand. Thanks for the hint!
 
 
 Actually, I don't think it's a good idea. I think you have the whole
 concept backwards.
 vb2 doesn't care what is returned from this function. All it wants is
 a cookie from this allocator. From the point of view where this
 function is used, it is get_userptr not get_vma, vb2 wants to get
 something describing a user pointer, but that does not have to mean a
 vma. Moreover, in any case, the core does not care at all what it is
 it is getting, since it *never uses it*. Changing the name of this
 function would actually make it confusing.

I've redesigned it in a bit different way, please see v6 patch series.

Best regards
--
Marek Szyprowski
Samsung Poland RD Center

--
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 7/7] v4l: videobuf2: add CMA allocator

2010-12-05 Thread Jonghun Han

Pawel Osciak wrote:

 -Original Message-
 From: Pawel Osciak [mailto:pa...@osciak.com]
 Sent: Sunday, December 05, 2010 7:47 AM
 To: Marek Szyprowski; Jonghun Han
 Cc: linux-media@vger.kernel.org; kyungmin.p...@samsung.com
 Subject: Re: [PATCH 7/7] v4l: videobuf2: add CMA allocator
 
 Hi,
 please see my comments below.
 Also, if I could suggest something, please cut the code between
 functions, not inside them, it'll make it easier for others to find
 that location in the original code.
 
 On Wed, Dec 1, 2010 at 00:56, Marek Szyprowski m.szyprow...@samsung.com
 wrote:
  Hello,
 
  On Wednesday, December 01, 2010 9:36 AM Jonghun Han wrote:
 
  Marek Szyprowski wrote:
  2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
   From: Pawel Osciak p.osc...@samsung.com
  
   Add support for the CMA contiguous memory allocator to videobuf2.
  
   Signed-off-by: Pawel Osciak p.osc...@samsung.com
   Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
   Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
   CC: Pawel Osciak pa...@osciak.com
   ---
 
  Hi Marek,
 
  snip
 
   +static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long
size)
 
  static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long
size,
                                                  const struct
vb2_alloc_ctx
  *alloc_ctx)
  alloc_ctx can be useful for many cases.
 
  Yes, right, I will add it in the next version.
 
 
 Actually, I don't think so. Can you give an example of one of those
 many cases? There is no need to add unused arguments that can be
 useful in future just for the sake of future extensions, especially
 not in the kernel in such sensitive code. This function can
 potentially be called on each frame. And even more importantly, the
 whole allocator interface has been designed so that functions will not
 have to be vb2- or media-specific. Ideally, we should be able to hook
 up functions from mm and other modules. And such functions either use
 only vaddr and size, or have means of finding their contexts
 otherwise.
 If I remember correctly, this approach was actually suggested by
 Laurent and it makes a lot of sense. We want to be able to use third
 party kernel functions in allocators as much as possbile.
 

Hi, 

What I mentioned many cases is related in VCMM(Virtual Contiguous Memory
Manager).
http://www.linuxsymposium.org/2010/view_abstract.php?content_key=64

When IOMMU(SYS.MMU) is used for device, each device uses its own device
virtual address 
not a physical address or virtual address. VCMM device id is needed to get
the device virtual address.
But in vb2_cma_get_userptr we cannot find the VCMM device id.
If vb2_alloc_ctx is added as argument in vb2_cma_get_userptr and VCMM device
id is set
in vb2_cma_conf on vb2_cma_init, we can find VCMM device id in
vb2_cma_get_userptr.

   +{
   +       struct vb2_cma_buf *buf;
   +       unsigned long paddr = 0;
   +       int ret;
   +
   +       buf = kzalloc(sizeof *buf, GFP_KERNEL);
   +       if (!buf)
   +               return ERR_PTR(-ENOMEM);
   +
   +       buf-vma = vb2_get_userptr(vaddr);
 
  vb2_get_vma looks good instead of vb2_get_userptr.
  How do you think about this ?
 
  Right, this will make the code easier to understand. Thanks for the
hint!
 
 
 Actually, I don't think it's a good idea. I think you have the whole
 concept backwards.
 vb2 doesn't care what is returned from this function. All it wants is
 a cookie from this allocator. From the point of view where this
 function is used, it is get_userptr not get_vma, vb2 wants to get
 something describing a user pointer, but that does not have to mean a
 vma. Moreover, in any case, the core does not care at all what it is
 it is getting, since it *never uses it*. Changing the name of this
 function would actually make it confusing.
 
 In other words: this function is an implementation of
 get_userptr_private_allocator_cookie allocator interface function
 and *not* a get_vma function implementation. It does not have to be
 a vma and the core does not care what it is anyway.
 

What I mentioned is vb2_get_userptr not
vb2_cma_get_userptr(vb2_mem_ops-get_userptr).
vb2_get_userptr is used in vb2_cma_get_userptr to find struct vm_area in
videobuf2-memops.c

Cookie concept is very nice. I absolutely agree with you.

   +       if (!buf-vma) {
   +               printk(KERN_ERR Failed acquiring VMA for vaddr
  0x%08lx\n,
   +                               vaddr);
   +               ret = -EINVAL;
   +               goto done;
   +       }
   +
   +       ret = vb2_contig_verify_userptr(buf-vma, vaddr, size,
paddr);
   +       if (ret) {
   +               vb2_put_userptr(buf-vma);
   +               goto done;
   +       }
   +
 
  In vb2_contig_verify_userptr, vma is re-found via find_vma although it
has
  been checked after vb2_get_userptr.
  Why double checking is needed ?
 
  I'm not sure. I must check this core again, maybe it can be simplified a
bit.
 
 I agree, it seems

Re: [PATCH 7/7] v4l: videobuf2: add CMA allocator

2010-12-04 Thread Pawel Osciak
Hi,
please see my comments below.
Also, if I could suggest something, please cut the code between
functions, not inside them, it'll make it easier for others to find
that location in the original code.

On Wed, Dec 1, 2010 at 00:56, Marek Szyprowski m.szyprow...@samsung.com wrote:
 Hello,

 On Wednesday, December 01, 2010 9:36 AM Jonghun Han wrote:

 Marek Szyprowski wrote:
 2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
  From: Pawel Osciak p.osc...@samsung.com
 
  Add support for the CMA contiguous memory allocator to videobuf2.
 
  Signed-off-by: Pawel Osciak p.osc...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
  CC: Pawel Osciak pa...@osciak.com
  ---

 Hi Marek,

 snip

  +static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size)

 static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size,
                                                 const struct vb2_alloc_ctx
 *alloc_ctx)
 alloc_ctx can be useful for many cases.

 Yes, right, I will add it in the next version.


Actually, I don't think so. Can you give an example of one of those
many cases? There is no need to add unused arguments that can be
useful in future just for the sake of future extensions, especially
not in the kernel in such sensitive code. This function can
potentially be called on each frame. And even more importantly, the
whole allocator interface has been designed so that functions will not
have to be vb2- or media-specific. Ideally, we should be able to hook
up functions from mm and other modules. And such functions either use
only vaddr and size, or have means of finding their contexts
otherwise.
If I remember correctly, this approach was actually suggested by
Laurent and it makes a lot of sense. We want to be able to use third
party kernel functions in allocators as much as possbile.

  +{
  +       struct vb2_cma_buf *buf;
  +       unsigned long paddr = 0;
  +       int ret;
  +
  +       buf = kzalloc(sizeof *buf, GFP_KERNEL);
  +       if (!buf)
  +               return ERR_PTR(-ENOMEM);
  +
  +       buf-vma = vb2_get_userptr(vaddr);

 vb2_get_vma looks good instead of vb2_get_userptr.
 How do you think about this ?

 Right, this will make the code easier to understand. Thanks for the hint!


Actually, I don't think it's a good idea. I think you have the whole
concept backwards.
vb2 doesn't care what is returned from this function. All it wants is
a cookie from this allocator. From the point of view where this
function is used, it is get_userptr not get_vma, vb2 wants to get
something describing a user pointer, but that does not have to mean a
vma. Moreover, in any case, the core does not care at all what it is
it is getting, since it *never uses it*. Changing the name of this
function would actually make it confusing.

In other words: this function is an implementation of
get_userptr_private_allocator_cookie allocator interface function
and *not* a get_vma function implementation. It does not have to be
a vma and the core does not care what it is anyway.

  +       if (!buf-vma) {
  +               printk(KERN_ERR Failed acquiring VMA for vaddr
 0x%08lx\n,
  +                               vaddr);
  +               ret = -EINVAL;
  +               goto done;
  +       }
  +
  +       ret = vb2_contig_verify_userptr(buf-vma, vaddr, size, paddr);
  +       if (ret) {
  +               vb2_put_userptr(buf-vma);
  +               goto done;
  +       }
  +

 In vb2_contig_verify_userptr, vma is re-found via find_vma although it has
 been checked after vb2_get_userptr.
 Why double checking is needed ?

 I'm not sure. I must check this core again, maybe it can be simplified a bit.

I agree, it seems that it should be enough to remove find_vma from the
gerneric verify contig function.

-- 
Best regards,
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


RE: [PATCH 7/7] v4l: videobuf2: add CMA allocator

2010-12-01 Thread Jonghun Han

Marek Szyprowski wrote:
2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
 From: Pawel Osciak p.osc...@samsung.com

 Add support for the CMA contiguous memory allocator to videobuf2.

 Signed-off-by: Pawel Osciak p.osc...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 CC: Pawel Osciak pa...@osciak.com
 ---

Hi Marek,

snip

 +static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size)

static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size, 
const struct vb2_alloc_ctx
*alloc_ctx)
alloc_ctx can be useful for many cases.

 +{
 +   struct vb2_cma_buf *buf;
 +   unsigned long paddr = 0;
 +   int ret;
 +
 +   buf = kzalloc(sizeof *buf, GFP_KERNEL);
 +   if (!buf)
 +   return ERR_PTR(-ENOMEM);
 +
 +   buf-vma = vb2_get_userptr(vaddr);

vb2_get_vma looks good instead of vb2_get_userptr.
How do you think about this ?

 +   if (!buf-vma) {
 +   printk(KERN_ERR Failed acquiring VMA for vaddr
0x%08lx\n,
 +   vaddr);
 +   ret = -EINVAL;
 +   goto done;
 +   }
 +
 +   ret = vb2_contig_verify_userptr(buf-vma, vaddr, size, paddr);
 +   if (ret) {
 +   vb2_put_userptr(buf-vma);
 +   goto done;
 +   }
 +

In vb2_contig_verify_userptr, vma is re-found via find_vma although it has
been checked after vb2_get_userptr.
Why double checking is needed ?

 +   buf-size = size;
 +   buf-paddr = paddr;
 +
 +   return buf;
 +
 +done:
 +   kfree(buf);
 +   return ERR_PTR(ret);
 +}
 +

snip

BRs,

--
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 7/7] v4l: videobuf2: add CMA allocator

2010-12-01 Thread Marek Szyprowski
Hello,

On Wednesday, December 01, 2010 9:36 AM Jonghun Han wrote:

 Marek Szyprowski wrote:
 2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
  From: Pawel Osciak p.osc...@samsung.com
 
  Add support for the CMA contiguous memory allocator to videobuf2.
 
  Signed-off-by: Pawel Osciak p.osc...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
  CC: Pawel Osciak pa...@osciak.com
  ---
 
 Hi Marek,
 
 snip
 
  +static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size)
 
 static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size,
 const struct vb2_alloc_ctx
 *alloc_ctx)
 alloc_ctx can be useful for many cases.

Yes, right, I will add it in the next version.

  +{
  +   struct vb2_cma_buf *buf;
  +   unsigned long paddr = 0;
  +   int ret;
  +
  +   buf = kzalloc(sizeof *buf, GFP_KERNEL);
  +   if (!buf)
  +   return ERR_PTR(-ENOMEM);
  +
  +   buf-vma = vb2_get_userptr(vaddr);
 
 vb2_get_vma looks good instead of vb2_get_userptr.
 How do you think about this ?

Right, this will make the code easier to understand. Thanks for the hint!

  +   if (!buf-vma) {
  +   printk(KERN_ERR Failed acquiring VMA for vaddr
 0x%08lx\n,
  +   vaddr);
  +   ret = -EINVAL;
  +   goto done;
  +   }
  +
  +   ret = vb2_contig_verify_userptr(buf-vma, vaddr, size, paddr);
  +   if (ret) {
  +   vb2_put_userptr(buf-vma);
  +   goto done;
  +   }
  +
 
 In vb2_contig_verify_userptr, vma is re-found via find_vma although it has
 been checked after vb2_get_userptr.
 Why double checking is needed ?

I'm not sure. I must check this core again, maybe it can be simplified a bit.

Best regards
--
Marek Szyprowski
Samsung Poland RD Center

--
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 7/7] v4l: videobuf2: add CMA allocator

2010-11-24 Thread Sewoon Park
Hi~
Simply comments below

Marek Szyprowski Saturday, November 20, 2010 12:56 AM Wrote:

snip
 +/*
 + * videobuf2-cma.h - CMA memory allocator for videobuf2
 + *
 + * Copyright (C) 2010 Samsung Electronics
 + *
 + * Author: Pawel Osciak p.osc...@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation.
 + */
 +
 +static inline unsigned long vb2_cma_plane_paddr(struct vb2_buffer *vb,
 + unsigned int plane_no)
 +{
 + return (unsigned long)vb2_plane_cookie(vb, plane_no);

vb2_plane_cookie() function is in the videobuf2-core.
So, this header file should include media/videobuf2-core.h

 +}
 +
 +struct vb2_alloc_ctx *vb2_cma_init(struct device *dev, const char *type,
 + unsigned long alignment);
 +void vb2_cma_cleanup(struct vb2_alloc_ctx *alloc_ctx);
 +
 +struct vb2_alloc_ctx **vb2_cma_init_multi(struct device *dev,
 +   unsigned int num_planes, const char *types[],
 +   unsigned long alignments[]);
 +void vb2_cma_cleanup_multi(struct vb2_alloc_ctx **alloc_ctxes);
 +
 +struct vb2_alloc_ctx *vb2_cma_init(struct device *dev, const char *type,
 + unsigned long alignment);
 +void vb2_cma_cleanup(struct vb2_alloc_ctx *alloc_ctx);
 +
 --
 1.7.1.569.g6f426
 
 --
 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

--
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


[PATCH 7/7] v4l: videobuf2: add CMA allocator

2010-11-19 Thread Marek Szyprowski
From: Pawel Osciak p.osc...@samsung.com

Add support for the CMA contiguous memory allocator to videobuf2.

Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
 drivers/media/video/Kconfig |5 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/videobuf2-cma.c |  250 +++
 include/media/videobuf2-cma.h   |   31 +
 4 files changed, 287 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/videobuf2-cma.c
 create mode 100644 include/media/videobuf2-cma.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9315c0a..eec6c3f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -65,6 +65,11 @@ config VIDEOBUF2_VMALLOC
select VIDEOBUF2_MEMOPS
tristate
 
+config VIDEOBUF2_CMA
+   depends on CMA
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_MEMOPS
+   tristate
 #
 # Multimedia Video device configuration
 #
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ede588d..82635fc 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_VIDEOBUF2_CORE)+= 
videobuf2-core.o
 obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
 obj-$(CONFIG_VIDEOBUF2_VMALLOC)+= videobuf2-vmalloc.o
 obj-$(CONFIG_VIDEOBUF2_DMA_COHERENT)   += videobuf2-dma-coherent.o
+obj-$(CONFIG_VIDEOBUF2_CMA)+= videobuf2-cma.o
 
 obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
 
diff --git a/drivers/media/video/videobuf2-cma.c 
b/drivers/media/video/videobuf2-cma.c
new file mode 100644
index 000..157d7ac
--- /dev/null
+++ b/drivers/media/video/videobuf2-cma.c
@@ -0,0 +1,250 @@
+/*
+ * videobuf2-cma.c - CMA memory allocator for videobuf2
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ *
+ * Author: Pawel Osciak p.osc...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/cma.h
+#include linux/mm.h
+#include linux/sched.h
+#include linux/file.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+struct vb2_cma_conf {
+   struct vb2_alloc_ctxalloc_ctx;
+   struct device   *dev;
+   const char  *type;
+   unsigned long   alignment;
+};
+
+struct vb2_cma_buf {
+   struct vb2_cma_conf *conf;
+   dma_addr_t  paddr;
+   unsigned long   size;
+   unsigned intrefcount;
+   struct vm_area_struct   *vma;
+};
+
+static void *vb2_cma_alloc(const struct vb2_alloc_ctx *alloc_ctx,
+   unsigned long size)
+{
+   struct vb2_cma_conf *conf =
+   container_of(alloc_ctx, struct vb2_cma_conf, alloc_ctx);
+   struct vb2_cma_buf *buf;
+
+   buf = kzalloc(sizeof *buf, GFP_KERNEL);
+   if (!buf)
+   return ERR_PTR(-ENOMEM);
+
+   buf-paddr = cma_alloc(conf-dev, conf-type, size, conf-alignment);
+   if (IS_ERR((void *)buf-paddr)) {
+   printk(KERN_ERR cma_alloc of size %ld failed\n, size);
+   kfree(buf);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   buf-conf = conf;
+   buf-size = size;
+   buf-refcount++;
+
+   printk(KERN_DEBUG Allocated cma mem of size %ld at paddr=0x%08x\n,
+   buf-size, buf-paddr);
+
+   return buf;
+}
+
+static void vb2_cma_put(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   buf-refcount--;
+
+   if (0 == buf-refcount) {
+   cma_free(buf-paddr);
+   kfree(buf);
+   }
+}
+
+static unsigned long vb2_cma_cookie(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   return buf-paddr;
+}
+
+static unsigned int vb2_cma_num_users(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   return buf-refcount;
+}
+
+static void vb2_cma_vm_open(struct vm_area_struct *vma)
+{
+   struct vb2_cma_buf *buf = vma-vm_private_data;
+
+   printk(KERN_DEBUG %s cma_priv: %p, refcount: %d, 
+   vma: %08lx-%08lx\n, __func__, buf, buf-refcount,
+   vma-vm_start, vma-vm_end);
+
+   buf-refcount++;
+}
+
+static void vb2_cma_vm_close(struct vm_area_struct *vma)
+{
+   struct vb2_cma_buf *buf = vma-vm_private_data;
+
+   printk(KERN_DEBUG %s cma_priv: %p, refcount: %d, 
+   vma: %08lx-%08lx\n, __func__, buf, buf-refcount,
+   vma-vm_start, vma-vm_end);
+
+   vb2_cma_put(buf);
+}
+
+static const struct vm_operations_struct vb2_cma_vm_ops = {
+   .open = vb2_cma_vm_open,

[PATCH 7/7] v4l: videobuf2: add CMA allocator

2010-11-17 Thread Marek Szyprowski
From: Pawel Osciak p.osc...@samsung.com

Add support for the CMA contiguous memory allocator to videobuf2.

Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
 drivers/media/video/Kconfig |5 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/videobuf2-cma.c |  250 +++
 include/media/videobuf2-cma.h   |   31 +
 4 files changed, 287 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/videobuf2-cma.c
 create mode 100644 include/media/videobuf2-cma.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9315c0a..eec6c3f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -65,6 +65,11 @@ config VIDEOBUF2_VMALLOC
select VIDEOBUF2_MEMOPS
tristate
 
+config VIDEOBUF2_CMA
+   depends on CMA
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_MEMOPS
+   tristate
 #
 # Multimedia Video device configuration
 #
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index baa74e7..6f917ee 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_VIDEOBUF2_CORE)+= 
videobuf2-core.o
 obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
 obj-$(CONFIG_VIDEOBUF2_VMALLOC)+= videobuf2-vmalloc.o
 obj-$(CONFIG_VIDEOBUF2_DMA_COHERENT)   += videobuf2-dma_coherent.o
+obj-$(CONFIG_VIDEOBUF2_CMA)+= videobuf2-cma.o
 
 obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
 
diff --git a/drivers/media/video/videobuf2-cma.c 
b/drivers/media/video/videobuf2-cma.c
new file mode 100644
index 000..157d7ac
--- /dev/null
+++ b/drivers/media/video/videobuf2-cma.c
@@ -0,0 +1,250 @@
+/*
+ * videobuf2-cma.c - CMA memory allocator for videobuf2
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ *
+ * Author: Pawel Osciak p.osc...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/cma.h
+#include linux/mm.h
+#include linux/sched.h
+#include linux/file.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+struct vb2_cma_conf {
+   struct vb2_alloc_ctxalloc_ctx;
+   struct device   *dev;
+   const char  *type;
+   unsigned long   alignment;
+};
+
+struct vb2_cma_buf {
+   struct vb2_cma_conf *conf;
+   dma_addr_t  paddr;
+   unsigned long   size;
+   unsigned intrefcount;
+   struct vm_area_struct   *vma;
+};
+
+static void *vb2_cma_alloc(const struct vb2_alloc_ctx *alloc_ctx,
+   unsigned long size)
+{
+   struct vb2_cma_conf *conf =
+   container_of(alloc_ctx, struct vb2_cma_conf, alloc_ctx);
+   struct vb2_cma_buf *buf;
+
+   buf = kzalloc(sizeof *buf, GFP_KERNEL);
+   if (!buf)
+   return ERR_PTR(-ENOMEM);
+
+   buf-paddr = cma_alloc(conf-dev, conf-type, size, conf-alignment);
+   if (IS_ERR((void *)buf-paddr)) {
+   printk(KERN_ERR cma_alloc of size %ld failed\n, size);
+   kfree(buf);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   buf-conf = conf;
+   buf-size = size;
+   buf-refcount++;
+
+   printk(KERN_DEBUG Allocated cma mem of size %ld at paddr=0x%08x\n,
+   buf-size, buf-paddr);
+
+   return buf;
+}
+
+static void vb2_cma_put(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   buf-refcount--;
+
+   if (0 == buf-refcount) {
+   cma_free(buf-paddr);
+   kfree(buf);
+   }
+}
+
+static unsigned long vb2_cma_cookie(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   return buf-paddr;
+}
+
+static unsigned int vb2_cma_num_users(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   return buf-refcount;
+}
+
+static void vb2_cma_vm_open(struct vm_area_struct *vma)
+{
+   struct vb2_cma_buf *buf = vma-vm_private_data;
+
+   printk(KERN_DEBUG %s cma_priv: %p, refcount: %d, 
+   vma: %08lx-%08lx\n, __func__, buf, buf-refcount,
+   vma-vm_start, vma-vm_end);
+
+   buf-refcount++;
+}
+
+static void vb2_cma_vm_close(struct vm_area_struct *vma)
+{
+   struct vb2_cma_buf *buf = vma-vm_private_data;
+
+   printk(KERN_DEBUG %s cma_priv: %p, refcount: %d, 
+   vma: %08lx-%08lx\n, __func__, buf, buf-refcount,
+   vma-vm_start, vma-vm_end);
+
+   vb2_cma_put(buf);
+}
+
+static const struct vm_operations_struct vb2_cma_vm_ops = {
+   .open = vb2_cma_vm_open,