date:20090420

Re: [PATCH 0/5] soc-camera: convert to platform device

2009-04-20 Thread Guennadi Liakhovetski

On Mon, 20 Apr 2009, Magnus Damm wrote:

 On Fri, Apr 17, 2009 at 7:43 PM, Guennadi Liakhovetski
 g.liakhovet...@gmx.de wrote:
  On Fri, 17 Apr 2009, Magnus Damm wrote:
  On Fri, Apr 17, 2009 at 4:51 PM, Guennadi Liakhovetski
  g.liakhovet...@gmx.de wrote:
   On Fri, 17 Apr 2009, Magnus Damm wrote:
   On Wed, Apr 15, 2009 at 9:17 PM, Guennadi Liakhovetski
   g.liakhovet...@gmx.de wrote:
This patch series is a preparation for the v4l2-subdev conversion. 
Please,
review and test. My current patch-stack in the form of a
(manually-created) quilt-series is at
http://www.open-technology.de/download/20090415/ based on linux-next
history branch, commit ID in -base file. Don't be surprised, that
patch-set also contains a few not directly related patches.
  
   Testing on Migo-R board with 2.6.30-rc2-git-something and the
   following cherry-picked patches:
  
   0007-driver-core-fix-driver_match_device.patch
   0033-soc-camera-host-driver-cleanup.patch
   0034-soc-camera-remove-an-extra-device-generation-from-s.patch
   0035-soc-camera-simplify-register-access-routines-in-mul.patch
   and part of 0036 (avoiding rejects, ap325 seems broken btw)
  
   Have I broken it or is it unrelated?
 
  2.6.30-rc seems broken on Migo-R. A quick check suggests the following:
 
  Ok, before we come to Migo-R, what is with ap325? Have I broken it with
  this my series or is it a different problem?
 
 Not sure. I used 2.6.30-rc but I guess your patches are aimed at linux-next.
 
  V4L/DVB (10141): OK
  V4L/DVB (10672): BAD
  V4L/DVB (11024): BAD
 
  These seem to be pretty random snapshots... Are they all on Linus' master
  or on next or on v4l-dvb? You did pick up the
 
  0007-driver-core-fix-driver_match_device.patch
 
 Yeah, I tried that one. I'm not sure what was the problem, but it's gone now.
 
 Today I've tested the following on top of linux-2.6 (stable 2.6.30-rc)
 d91dfbb41bb2e9bdbfbd2cc7078ed7436eab027a
 
 0033-soc-camera-host-driver-cleanup.patch
 0034-soc-camera-remove-an-extra-device-generation-from-s.patch
 0035-soc-camera-simplify-register-access-routines-in-mul.patch
 
 So far OK.
 However, applying 0036- or v2 from the mailing list results in rejects
 (probably because linux-next vs linux-2.6 differences) but the files
 should not affect Migo-R.
 
 So with 0036 or v2 applied it builds ok for Migo-R, but I can't open
 /dev/video0 for some reason. Reverting the patch and only using
 0033-0035 above results in ok /dev/video0 opening.

Did you have video drivers build in or as modules? If modules - in which 
order did you load them? Unfortunately, at the moment it might be 
important:-( What's in dmesg after loading all drivers?

 What are your dependencies?
 
 I'll try out your 20090415/series on top of the matching linux-next for now.

Thanks
Guennadi
---
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: libv4l release: 0.5.97: the whitebalance release!

2009-04-20 Thread Hans de Goede




On 04/20/2009 06:43 AM, Erik Andrén wrote:


Hans de Goede wrote:


On 04/19/2009 09:20 PM, Erik Andrén wrote:

2009/4/19 Hans de Goedehdego...@redhat.com:

On 04/18/2009 04:40 PM, Erik Andrén wrote:

Hans de Goede wrote:

On 04/17/2009 09:27 PM, Erik Andrén wrote:

Hans de Goede wrote:

On 04/16/2009 10:46 PM, Adam Baker wrote:

On Thursday 16 Apr 2009, Hans de Goede wrote:

On 04/16/2009 12:26 AM, Adam Baker wrote:

On Wednesday 15 Apr 2009, Hans de Goede wrote:

Currently only whitebalancing is enabled and only on Pixarts
(pac)
webcams (which benefit tremendously from this). To test this
with
other
webcams (after instaling this release) do:

export LIBV4LCONTROL_CONTROLS=15
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp

Strangely while those instructions give me a whitebalance control
for the
sq905 based camera I can't get it to appear for a pac207 based
camera
regardless of whether LIBV4LCONTROL_CONTROLS is set.

Thats weird, there is a small bug in the handling of pac207
cams with usb id 093a:2476 causing libv4l to not automatically
enable whitebalancing (and the control) for cams with that id,
but if you have LIBV4LCONTROL_CONTROLS set (exported!) both
when loading v4l2ucp (you must preload v4l2convert.so!) and
when loading your viewer, then it should work.


I've tested it by plugging in the sq905 camera, verifying the
whitebablance
control is present and working, unplugging the sq905 and
plugging in
the
pac207 and using up arrow to restart v4l2ucp and svv so I think
I've
eliminated most finger trouble possibilities. The pac207 is id
093a:2460 so
not the problem id. I'll have to investigate more thoroughly later.


Does the pac207 perhaps have a / in its card string (see v4l-info
output) ?
if so try out this patch:
http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a


I have the same issue as Adam when trying to test this with my
gspca_stv06xx based Quickcam Web camera i. e no whitebalancing
controls show up. I'm attaching a dump which logs all available
pixformats and v4l2ctrls showing that libv4l is properly loaded.
(And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15).

Best regards,
Erik


Ah, you are using v4l2-ctl, not v4l2ucp, and that uses
V4L2_CTRL_FLAG_NEXT_CTRL
control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL
(which is
a bug). I'm not sure when I'll have time to fix this. Patches welcome,
or in
the mean time use v4l2ucp to play with the controls.


Actually, I've tried to use both without finding the controls.
I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary?


Apparently there are different versions of v4l2ucp in different distro's
and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See
Adam Baker's patch later in this thread. Which I will apply to my
tree after I've reviewed it (when I find some time currently I've a
lot of
$work$ )


Applying Adam Bakers patch makes the control appear _but_ I can't seem
to make out any difference when any of the whitebalancing and
normalize options, regardless of how i tweak the max / min values.


Did you also do the
export LIBV4LCONTROL_CONTROLS=15

In the terminal from where you are starting the viewing application ?



Yes.



Hmm,

Then the camera you are using probably already has some whitebalancing
itself using the same algorithm. What happens if you enable normalize
and then lower the high bound significantly? If that doesn't do anything
either then somehow things are not working.

Regards,

Hans
--
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: libv4l release: 0.5.97: the whitebalance release!

2009-04-20 Thread Erik Andrén

2009/4/20 Hans de Goede hdego...@redhat.com:


 On 04/20/2009 06:43 AM, Erik Andrén wrote:

 Hans de Goede wrote:

 On 04/19/2009 09:20 PM, Erik Andrén wrote:

 2009/4/19 Hans de Goedehdego...@redhat.com:

 On 04/18/2009 04:40 PM, Erik Andrén wrote:

 Hans de Goede wrote:

 On 04/17/2009 09:27 PM, Erik Andrén wrote:

 Hans de Goede wrote:

 On 04/16/2009 10:46 PM, Adam Baker wrote:

 On Thursday 16 Apr 2009, Hans de Goede wrote:

 On 04/16/2009 12:26 AM, Adam Baker wrote:

 On Wednesday 15 Apr 2009, Hans de Goede wrote:

 Currently only whitebalancing is enabled and only on Pixarts
 (pac)
 webcams (which benefit tremendously from this). To test this
 with
 other
 webcams (after instaling this release) do:

 export LIBV4LCONTROL_CONTROLS=15
 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp

 Strangely while those instructions give me a whitebalance
 control
 for the
 sq905 based camera I can't get it to appear for a pac207 based
 camera
 regardless of whether LIBV4LCONTROL_CONTROLS is set.

 Thats weird, there is a small bug in the handling of pac207
 cams with usb id 093a:2476 causing libv4l to not automatically
 enable whitebalancing (and the control) for cams with that id,
 but if you have LIBV4LCONTROL_CONTROLS set (exported!) both
 when loading v4l2ucp (you must preload v4l2convert.so!) and
 when loading your viewer, then it should work.

 I've tested it by plugging in the sq905 camera, verifying the
 whitebablance
 control is present and working, unplugging the sq905 and
 plugging in
 the
 pac207 and using up arrow to restart v4l2ucp and svv so I think
 I've
 eliminated most finger trouble possibilities. The pac207 is id
 093a:2460 so
 not the problem id. I'll have to investigate more thoroughly
 later.

 Does the pac207 perhaps have a / in its card string (see v4l-info
 output) ?
 if so try out this patch:
 http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a

 I have the same issue as Adam when trying to test this with my
 gspca_stv06xx based Quickcam Web camera i. e no whitebalancing
 controls show up. I'm attaching a dump which logs all available
 pixformats and v4l2ctrls showing that libv4l is properly loaded.
 (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15).

 Best regards,
 Erik

 Ah, you are using v4l2-ctl, not v4l2ucp, and that uses
 V4L2_CTRL_FLAG_NEXT_CTRL
 control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL
 (which is
 a bug). I'm not sure when I'll have time to fix this. Patches
 welcome,
 or in
 the mean time use v4l2ucp to play with the controls.

 Actually, I've tried to use both without finding the controls.
 I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary?

 Apparently there are different versions of v4l2ucp in different
 distro's
 and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See
 Adam Baker's patch later in this thread. Which I will apply to my
 tree after I've reviewed it (when I find some time currently I've a
 lot of
 $work$ )

 Applying Adam Bakers patch makes the control appear _but_ I can't seem
 to make out any difference when any of the whitebalancing and
 normalize options, regardless of how i tweak the max / min values.

 Did you also do the
 export LIBV4LCONTROL_CONTROLS=15

 In the terminal from where you are starting the viewing application ?


 Yes.


 Hmm,

 Then the camera you are using probably already has some whitebalancing
 itself using the same algorithm. What happens if you enable normalize
 and then lower the high bound significantly? If that doesn't do anything
 either then somehow things are not working.


I don't think this sensor/camera has any whitebalancing as the image
quality is fine in normal daylight but gets yellowtones when using
lightbulbs.
I'll add some printks to libv4l to verify that the whitebalance
processing routines are actually called and get back to you with the
results.

Best regards,
Erik

 Regards,

 Hans

--
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 0/5] soc-camera: convert to platform device

2009-04-20 Thread Magnus Damm

On Mon, Apr 20, 2009 at 4:22 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 On Mon, 20 Apr 2009, Magnus Damm wrote:
 On Fri, Apr 17, 2009 at 7:43 PM, Guennadi Liakhovetski
 g.liakhovet...@gmx.de wrote:
  On Fri, 17 Apr 2009, Magnus Damm wrote:
  On Fri, Apr 17, 2009 at 4:51 PM, Guennadi Liakhovetski
  g.liakhovet...@gmx.de wrote:
   On Fri, 17 Apr 2009, Magnus Damm wrote:
   On Wed, Apr 15, 2009 at 9:17 PM, Guennadi Liakhovetski
   g.liakhovet...@gmx.de wrote:
This patch series is a preparation for the v4l2-subdev conversion. 
Please,
review and test. My current patch-stack in the form of a
(manually-created) quilt-series is at
http://www.open-technology.de/download/20090415/ based on linux-next
history branch, commit ID in -base file. Don't be surprised, that
patch-set also contains a few not directly related patches.

 Today I've tested the following on top of linux-2.6 (stable 2.6.30-rc)
 d91dfbb41bb2e9bdbfbd2cc7078ed7436eab027a

 0033-soc-camera-host-driver-cleanup.patch
 0034-soc-camera-remove-an-extra-device-generation-from-s.patch
 0035-soc-camera-simplify-register-access-routines-in-mul.patch

 So far OK.
 However, applying 0036- or v2 from the mailing list results in rejects
 (probably because linux-next vs linux-2.6 differences) but the files
 should not affect Migo-R.

 So with 0036 or v2 applied it builds ok for Migo-R, but I can't open
 /dev/video0 for some reason. Reverting the patch and only using
 0033-0035 above results in ok /dev/video0 opening.

 Did you have video drivers build in or as modules? If modules - in which
 order did you load them? Unfortunately, at the moment it might be
 important:-( What's in dmesg after loading all drivers?

They are compiled-in. No modules.

 What are your dependencies?

 I'll try out your 20090415/series on top of the matching linux-next for now.

So linux-next fa169db2b277ebafa466d625ed2d16b2d2a4bc82 with
20090415/series applies without any rejects and compiles just fine for
Migo-R. However, during runtime I experience the same problem as with
2.6.30-rc plus 0033-0035 + 0036 or v2:

/ # /mplayer -flip -vf mirror -quiet tv://
MPlayer dev-SVN-rUNKNOWN-4.2-SH4-LINUX_v0701 (C) 2000-2008 MPlayer Team

Playing tv://.
TV file format detected.
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski olschew...@zpr.uni-koeln.de
 comment: first try, more to come ;-)
v4l2: unable to open '/dev/video0': No such device or address
v4l2: ioctl set mute failed: Bad file descriptor
v4l2: 0 frames successfully processed, 0 frames dropped.


Exiting... (End of file)
/ #

Removing 0036 unbreaks the code and mplayer/capture.c works as expected.

I also tried out v2 of your soc-camera-platform patch but it still
does not work.

Can you please test on your Migo-R board? I'd be happy to assist you
in setting up your environment.

/ magnus
--
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 0/5] soc-camera: convert to platform device

2009-04-20 Thread Guennadi Liakhovetski

On Mon, 20 Apr 2009, Magnus Damm wrote:

 So linux-next fa169db2b277ebafa466d625ed2d16b2d2a4bc82 with
 20090415/series applies without any rejects and compiles just fine for
 Migo-R. However, during runtime I experience the same problem as with
 2.6.30-rc plus 0033-0035 + 0036 or v2:
 
 / # /mplayer -flip -vf mirror -quiet tv://
 MPlayer dev-SVN-rUNKNOWN-4.2-SH4-LINUX_v0701 (C) 2000-2008 MPlayer Team
 
 Playing tv://.
 TV file format detected.
 Selected driver: v4l2
  name: Video 4 Linux 2 input
  author: Martin Olschewski olschew...@zpr.uni-koeln.de
  comment: first try, more to come ;-)
 v4l2: unable to open '/dev/video0': No such device or address
 v4l2: ioctl set mute failed: Bad file descriptor
 v4l2: 0 frames successfully processed, 0 frames dropped.
 
 
 Exiting... (End of file)
 / #
 
 Removing 0036 unbreaks the code and mplayer/capture.c works as expected.
 
 I also tried out v2 of your soc-camera-platform patch but it still
 does not work.
 
 Can you please test on your Migo-R board? I'd be happy to assist you
 in setting up your environment.

I did test it and it worked - exactly as you say - with the entire patch 
stack + v2 of soc-camera: convert to platform device, the only 
difference that I can see so far, is that I used modules. So, you can 
either look in dmesg for driver initialisation whether ov772x and tw9910 
have found theit i2c chips, or just wait until I test a monolitic build 
myself. It can be problematic if the i2c-host driver initialises too 
late... If you want to test a modular build it would be enough to just 
have sh_mobile_ceu_camera.ko as a module, the rest can stay built in.

Thanks
Guennadi
---
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 0/5] soc-camera: convert to platform device

2009-04-20 Thread Magnus Damm

On Mon, Apr 20, 2009 at 5:14 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 On Mon, 20 Apr 2009, Magnus Damm wrote:
 Can you please test on your Migo-R board? I'd be happy to assist you
 in setting up your environment.

 I did test it and it worked - exactly as you say - with the entire patch
 stack + v2 of soc-camera: convert to platform device, the only
 difference that I can see so far, is that I used modules. So, you can
 either look in dmesg for driver initialisation whether ov772x and tw9910
 have found theit i2c chips, or just wait until I test a monolitic build
 myself. It can be problematic if the i2c-host driver initialises too
 late... If you want to test a modular build it would be enough to just
 have sh_mobile_ceu_camera.ko as a module, the rest can stay built in.

I prefer to wait then. Please consider the built-in case broken.

Usually I get some output similar to this during boot:

camera 0-0: SuperH Mobile CEU driver attached to camera 0
camera 0-0: ov7725 Product ID 77:21 Manufacturer ID 7f:a2
camera 0-0: SuperH Mobile CEU driver detached from camera 0

But with the convert to platform device patch appied I see nothing like that.

The migor_defconfig should give you the static non-module
configuration that is broken.

Cheers,

/ magnus
--
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][RFC] videobuf-dma-config: zero copy USERPTR support

2009-04-20 Thread Magnus Damm

From: Magnus Damm d...@igel.co.jp

Zero copy video frame capture from user space using V4L2 USERPTR.

This patch adds USERPTR support to the videobuf-dma-contig buffer code.
Since videobuf-dma-contig is designed to handle physically contiguous
memory, this patch modifies the videobuf-dma-contig code to only accept
a pointer physically contiguous memory. For now only VM_PFNMAP vmas are
supported, so forget hotplug.

On SuperH Mobile we use this approach for our V4L2 CEU driver together
with various multimedia accelerator blocks that are exported to user 
space using UIO. The UIO kernel code exports physically contiugous memory
to user space and lets the user space application mmap() this memory and
pass a pointer using the USERPTR interface for V4L2 zero copy operation.

With this approach we support zero copy capture, hardware scaling and
various forms of hardware encoding.

Hopefully this patch is useful for other SoCs. For user space example
code I suggest having a look at the USERPTR implementation in capture.c.

Any comments? Does anyone need to use memory backed by struct page?

Signed-off-by: Magnus Damm d...@igel.co.jp
---

 drivers/media/video/videobuf-dma-contig.c |  138 +++--
 1 file changed, 131 insertions(+), 7 deletions(-)

--- 0001/drivers/media/video/videobuf-dma-contig.c
+++ work/drivers/media/video/videobuf-dma-contig.c  2009-04-20 
18:04:32.0 +0900
@@ -17,6 +17,8 @@
 #include linux/init.h
 #include linux/module.h
 #include linux/mm.h
+#include linux/hugetlb.h
+#include linux/pagemap.h
 #include linux/dma-mapping.h
 #include media/videobuf-dma-contig.h
 
@@ -25,6 +27,7 @@ struct videobuf_dma_contig_memory {
void *vaddr;
dma_addr_t dma_handle;
unsigned long size;
+   int is_userptr;
 };
 
 #define MAGIC_DC_MEM 0x0733ac61
@@ -108,6 +111,117 @@ static struct vm_operations_struct video
.close= videobuf_vm_close,
 };
 
+static void videobuf_dma_contig_user_put(struct videobuf_dma_contig_memory 
*mem)
+{
+   mem-is_userptr = 0;
+   mem-dma_handle = 0;
+   mem-size = 0;
+}
+
+/* modelled after follow_phys() in mm/memory.c */
+static int get_pfn(struct vm_area_struct *vma,
+  unsigned long address, unsigned long *pfnp)
+{
+   struct mm_struct *mm = vma-vm_mm;
+   pgd_t *pgd;
+   pud_t *pud;
+   pmd_t *pmd;
+   pte_t *ptep, pte;
+   spinlock_t *ptl;
+
+   if (!(vma-vm_flags  (VM_IO | VM_PFNMAP)))
+   goto no_page_table;
+
+   pgd = pgd_offset(mm, address);
+   if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
+   goto no_page_table;
+
+   pud = pud_offset(pgd, address);
+   if (pud_none(*pud) || unlikely(pud_bad(*pud)))
+   goto no_page_table;
+
+   pmd = pmd_offset(pud, address);
+   if (pmd_none(*pmd) || unlikely(pmd_bad(*pmd)))
+   goto no_page_table;
+
+   /* We cannot handle huge page PFN maps. Luckily they don't exist. */
+   if (pmd_huge(*pmd))
+   goto no_page_table;
+
+   ptep = pte_offset_map_lock(mm, pmd, address, ptl);
+   if (!ptep)
+   goto no_page_table;
+
+   pte = *ptep;
+   if (!pte_present(pte))
+   goto unlock;
+
+   *pfnp = pte_pfn(pte);
+   pte_unmap_unlock(ptep, ptl);
+   return 0;
+unlock:
+   pte_unmap_unlock(ptep, ptl);
+no_page_table:
+   return -EINVAL;
+}
+
+
+static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem,
+   struct videobuf_buffer *vb)
+{
+   struct mm_struct *mm = current-mm;
+   struct vm_area_struct *vma;
+   unsigned long prev_pfn, this_pfn;
+   unsigned long pages_done, user_address;
+   int ret;
+
+   mem-size = PAGE_ALIGN(vb-size);
+   mem-is_userptr = 0;
+   ret = -EINVAL;
+
+   down_read(mm-mmap_sem);
+
+   vma = find_vma(mm, vb-baddr);
+   if (!vma)
+   goto out_up;
+
+   if ((vb-baddr + mem-size)  vma-vm_end)
+   goto out_up;
+
+   pages_done = 0;
+   prev_pfn = 0; /* kill warning */
+   user_address = vb-baddr;
+
+   while (pages_done  (mem-size  PAGE_SHIFT)) {
+   ret = get_pfn(vma, user_address, this_pfn);
+   if (ret)
+   break;
+
+   if (pages_done == 0) {
+   prev_pfn = this_pfn;
+   mem-dma_handle = this_pfn  PAGE_SHIFT;
+   } else {
+   if (this_pfn != (prev_pfn + 1))
+   ret = -EFAULT;
+   }
+
+   if (ret)
+   break;
+
+   prev_pfn = this_pfn;
+   user_address += PAGE_SIZE;
+   pages_done++;
+   }
+
+   if (!ret  pages_done)
+   mem-is_userptr = 1;
+
+ out_up:
+   up_read(current-mm-mmap_sem);
+
+   return ret;
+}
+
 static void *__videobuf_alloc(size_t size)

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

2009-04-20 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Dongsoo Kim
 Sent: Sunday, April 19, 2009 12:06 PM
 To: Hans Verkuil
 Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre
 Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Hello Hans and Hiremath,

 One of my recent job is making S3C64XX camera interface driver (even
 though other jobs of mine are not finished yet...;-()
 And, what a incident! S3C64XX has also similar H/W block in camera
 interface.
 Resizer in S3C camera interface can be used in system wide like the
 one in Omap3.

[Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the 
configuration part of it? What all configuration is exported to the user?

 But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE
 and
 TYPE_VIDEO_OUTPUT.
 I thought that is was enough. Actually I took omap video out (vout?)
 for reference :-)

[Hiremath, Vaibhav] I have also implemented the driver is the same way and also 
working with Hans to get it reviewed. But there are some configuration like 
coeff., luma enhancement, etc... need to export to the user, where we need to 
add mechanism in V4L2 framework.

Since we have one more device where we are demanding for M-to-M operation, I 
think it is important to go through it. Can you share some documents of your IP 
for better understanding.

 Cheers,

 Nate

 2009. 04. 19, 오전 12:53, Hans Verkuil 작성:

  On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
  Thanks,
  Vaibhav Hiremath

  APPROACH 3 -
  --

  .

  (Any other approach which I could not think of would be

  appreciated)

  I would prefer second approach, since this will provide
 standard
  interface to applications independent on underneath hardware.

  There may be many number of such configuration parameters
 required

  for

  different such devices, we need to work on this and come up
 with

  some

  standard capability fields covering most of available devices.

  Does anybody have some other opinions on this?
  Any suggestions will be helpful here,

  FYI: I have very little time to look at this for the next 2-3
 weeks.
  As you
  know I'm working on the last pieces of the v4l2_subdev
 conversion
  for 2.6.30
  that should be finished this week. After that I'm attending the
  Embedded
  Linux Conference in San Francisco.

  But I always thought that something like this would be just a
  regular video
  device that can do both 'output' and 'capture'. For a resizer I
  would
  expect that you set the 'output' size (the size of your source
  image) and
  the 'capture' size (the size of the resized image), then just
 send
  the
  frames to the device (== resizer) and get them back on the
 capture
  side.

  [Hiremath, Vaibhav] Yes, it is possible to do that.

  Hans,

  I went through the link referred by Sergio and I think we should
  inherit
  some implementation for CODECs here for such devices.

  V4L2_BUF_TYPE_CODECIN - To access the input format.
  V4L2_BUF_TYPE_CODECOUT - To access the output format.

  It makes sense, since such memory-to-memory devices will mostly
 being
  used from codecs context. And this would be more clear from user
  application.

  To be honest, I don't see the need for this. I think
  TYPE_VIDEO_CAPTURE and
  TYPE_VIDEO_OUTPUT are perfectly fine.

  And as acknowledged by you, we can use VIDIOC_S_FMT for setting
  parameters.

  One thing I am not able to convince myself is that, using priv
  field
  for custom configuration.

  I agree. Especially since you cannot use it as a pointer to
 addition
  information.

  I would prefer and recommend capability based
  interface, where application will query the capability of the
  device for
  luma enhancement, filter coefficients (number of coeff and
 depth),
  interpolation type, etc...

  This way we can make sure that, any such future devices can be
  adapted by
  this framework.

  The big question is how many of these capabilities are 'generic'
 and
  how
  many are very much hardware specific. I am leaning towards using
 the
  extended control API for this. It's a bit awkward to implement in
  drivers
  at the moment, but that should improve in the future when a lot of
 the
  control handling code will move into the new core framework.

  I really need to know more about the sort of features that omap/
  davinci
  offer (and preferably also for similar devices by other
  manufacturers).

  Hans,
  Have you get a chance to look at Video-Buf layer issues I
 mentioned
  in
  original draft?

  I've asked Magnus Damm to take a look at this. I know he did some
  work in
  this area and

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

2009-04-20 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Saturday, April 18, 2009 9:24 PM
 To: Hiremath, Vaibhav
 Cc: linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto;
 DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
  Thanks,
  Vaibhav Hiremath

APPROACH 3 -
--

.
  It makes sense, since such memory-to-memory devices will mostly
 being
  used from codecs context. And this would be more clear from user
  application.

 To be honest, I don't see the need for this. I think
 TYPE_VIDEO_CAPTURE and
 TYPE_VIDEO_OUTPUT are perfectly fine.

[Hiremath, Vaibhav] Agreed, and you will also find implementation of driver 
aligned to this which I have shared with you.

  And as acknowledged by you, we can use VIDIOC_S_FMT for setting
  parameters.

  One thing I am not able to convince myself is that, using priv
 field
  for custom configuration.

 I agree. Especially since you cannot use it as a pointer to addition
 information.

  I would prefer and recommend capability based
  interface, where application will query the capability of the
 device for
  luma enhancement, filter coefficients (number of coeff and depth),
  interpolation type, etc...

  This way we can make sure that, any such future devices can be
 adapted by
  this framework.

 The big question is how many of these capabilities are 'generic' and
 how
 many are very much hardware specific. I am leaning towards using the
 extended control API for this. It's a bit awkward to implement in
 drivers
 at the moment, but that should improve in the future when a lot of
 the
 control handling code will move into the new core framework.

 I really need to know more about the sort of features that
 omap/davinci
 offer (and preferably also for similar devices by other
 manufacturers).

[Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will discuss 
this in detail and try to get closure on it.

Again I would request you to join me and mauro on IRC chat, I will be staying 
online tomorrow.

 Regards,

   Hans

 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

2009-04-20 Thread Dongsoo, Nathaniel Kim

Hello Vaibhav,

This is user manual of S3C6400 (not much different from S3C6410)
http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf

That SoC is from my company but not from the same division of mine.
Actually I'm doing this driver job without any request from chip
delivering division. I'm doing this because this is so challenging and
want better generic driver :-)

Take a look at the user manual and please let me know your opinion.
In my understanding scaler and some camera interface feature in
S3C64XX are very similar to the features in Omap3.

Cheers,

Nate

On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:

Thanks,
Vaibhav Hiremath

-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Dongsoo Kim
Sent: Sunday, April 19, 2009 12:06 PM
To: Hans Verkuil
Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre
Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
under V4L2 framework

Hello Hans and Hiremath,

One of my recent job is making S3C64XX camera interface driver (even
though other jobs of mine are not finished yet...;-()
And, what a incident! S3C64XX has also similar H/W block in camera
interface.
Resizer in S3C camera interface can be used in system wide like the
one in Omap3.

[Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify
the configuration part of it? What all configuration is exported to the user?

But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE
and
TYPE_VIDEO_OUTPUT.
I thought that is was enough. Actually I took omap video out (vout?)
for reference :-)

[Hiremath, Vaibhav] I have also implemented the driver is the same way and
also working with Hans to get it reviewed. But there are some configuration
like coeff., luma enhancement, etc... need to export to the user, where we
need to add mechanism in V4L2 framework.

Since we have one more device where we are demanding for M-to-M operation, I
think it is important to go through it. Can you share some documents of your
IP for better understanding.

Cheers,

Nate

2009. 04. 19, 오전 12:53, Hans Verkuil 작성:

On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
Thanks,
Vaibhav Hiremath

APPROACH 3 -
--

(Any other approach which I could not think of would be

appreciated)

I would prefer second approach, since this will provide
standard
interface to applications independent on underneath hardware.

There may be many number of such configuration parameters
required

for

different such devices, we need to work on this and come up
with

some

standard capability fields covering most of available devices.

Does anybody have some other opinions on this?
Any suggestions will be helpful here,

FYI: I have very little time to look at this for the next 2-3
weeks.
As you
know I'm working on the last pieces of the v4l2_subdev
conversion
for 2.6.30
that should be finished this week. After that I'm attending the
Embedded
Linux Conference in San Francisco.

But I always thought that something like this would be just a
regular video
device that can do both 'output' and 'capture'. For a resizer I
would
expect that you set the 'output' size (the size of your source
image) and
the 'capture' size (the size of the resized image), then just
send
the
frames to the device (== resizer) and get them back on the
capture
side.

[Hiremath, Vaibhav] Yes, it is possible to do that.

Hans,

I went through the link referred by Sergio and I think we should
inherit
some implementation for CODECs here for such devices.

V4L2_BUF_TYPE_CODECIN - To access the input format.
V4L2_BUF_TYPE_CODECOUT - To access the output format.

It makes sense, since such memory-to-memory devices will mostly
being
used from codecs context. And this would be more clear from user
application.

To be honest, I don't see the need for this. I think
TYPE_VIDEO_CAPTURE and
TYPE_VIDEO_OUTPUT are perfectly fine.

And as acknowledged by you, we can use VIDIOC_S_FMT for setting
parameters.

One thing I am not able to convince myself is that, using priv
field
for custom configuration.

I agree. Especially since you cannot use it as a pointer to
addition
information.

I would prefer and recommend capability based
interface, where application will query the capability of the
device for
luma enhancement, filter coefficients (number of coeff and
depth),
interpolation type, etc...

This way we can make sure that, any such future devices can be
adapted by
this framework.

The big question

RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

2009-04-20 Thread Hiremath, Vaibhav

Thanks,
Vaibhav Hiremath

 -Original Message-
 From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com]
 Sent: Monday, April 20, 2009 4:15 PM
 To: Hiremath, Vaibhav
 Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez,
 Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux-
 o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R;
 R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
 Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
 under V4L2 framework

 Hello Vaibhav,

 This is user manual of S3C6400 (not much different from S3C6410)
 http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64
 00X_UserManual_rev1-0_2008-02_661558um.pdf

 That SoC is from my company but not from the same division of mine.
 Actually I'm doing this driver job without any request from chip
 delivering division. I'm doing this because this is so challenging
 and
 want better generic driver :-)

 Take a look at the user manual and please let me know your opinion.
 In my understanding scaler and some camera interface feature in
 S3C64XX are very similar to the features in Omap3.

[Hiremath, Vaibhav] Thanks for the link, I will go though it and get back to 
you.

 Cheers,

 Nate

 On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com
 wrote:

  Thanks,
  Vaibhav Hiremath

  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Dongsoo Kim
  Sent: Sunday, April 19, 2009 12:06 PM
  To: Hans Verkuil
  Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre
  Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu);
 linux-
  o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh
 R;
  R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam
  Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support
  under V4L2 framework

  Hello Hans and Hiremath,

  One of my recent job is making S3C64XX camera interface driver
 (even
  though other jobs of mine are not finished yet...;-()
  And, what a incident! S3C64XX has also similar H/W block in
 camera
  interface.
  Resizer in S3C camera interface can be used in system wide like
 the
  one in Omap3.

  [Hiremath, Vaibhav] Can you share the spec for the same; I wanted
 to verify the configuration part of it? What all configuration is
 exported to the user?

  But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE
  and
  TYPE_VIDEO_OUTPUT.
  I thought that is was enough. Actually I took omap video out
 (vout?)
  for reference :-)

  [Hiremath, Vaibhav] I have also implemented the driver is the same
 way and also working with Hans to get it reviewed. But there are
 some configuration like coeff., luma enhancement, etc... need to
 export to the user, where we need to add mechanism in V4L2
 framework.

  Since we have one more device where we are demanding for M-to-M
 operation, I think it is important to go through it. Can you share
 some documents of your IP for better understanding.

  Cheers,

  Nate

  2009. 04. 19, 오전 12:53, Hans Verkuil 작성:

   On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote:
   Thanks,
   Vaibhav Hiremath

   APPROACH 3 -
   --

   .

   (Any other approach which I could not think of would be

   appreciated)

   I would prefer second approach, since this will provide
  standard
   interface to applications independent on underneath
 hardware.

   There may be many number of such configuration parameters
  required

   for

   different such devices, we need to work on this and come up
  with

   some

   standard capability fields covering most of available
 devices.

   Does anybody have some other opinions on this?
   Any suggestions will be helpful here,

   FYI: I have very little time to look at this for the next 2-3
  weeks.
   As you
   know I'm working on the last pieces of the v4l2_subdev
  conversion
   for 2.6.30
   that should be finished this week. After that I'm attending
 the
   Embedded
   Linux Conference in San Francisco.

   But I always thought that something like this would be just a
   regular video
   device that can do both 'output' and 'capture'. For a resizer
 I
   would
   expect that you set the 'output' size (the size of your
 source
   image) and
   the 'capture' size (the size of the resized image), then just
  send
   the
   frames to the device (== resizer) and get them back on the
  capture
   side.

   [Hiremath, Vaibhav] Yes, it is possible to do that.

   Hans,

   I went through the link referred by Sergio and I think we
 should
   inherit
   some implementation for CODECs here for such devices.

   V4L2_BUF_TYPE_CODECIN - To access the input format.
   V4L2_BUF_TYPE_CODECOUT - To access the output format.

   It makes sense, since such memory-to-memory devices will
 mostly
  being
   used from codecs context. And this would be more clear from
 user

62 matches

Mail list logo