RFC: PATCH: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls

2009-06-11 Thread Hans Verkuil
As per Mauro's request here is the patch adding the new core functionality.

To quote from my original pull request:

This time I've only added new functions and left the existing ones in place.
I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev 
functions to call the new s_config op if it is available. Existing subdev 
drivers never set this new op, so this code will not effect current 
behavior. But for new drivers that do set s_config it is important that it 
is called no matter what flavor of these functions is used.

At the end of the 2.6.31 cycle we can replace the current 
v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier 
patches.

Comments are welcome.

Hans

# HG changeset patch
# User Hans Verkuil hverk...@xs4all.nl
# Date 1244578353 -7200
# Node ID d9d3f747395109de316eadeed1d1d52b8440f84b
# Parent  ed3781a79c734f35b800d0b55d276cd62d793141
v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls

From: Hans Verkuil hverk...@xs4all.nl

Add a new s_config core ops call: this is called with the irq and platform
data to be used to initialize the subdev.

Added new v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev_board calls
that allows you to pass these new arguments.

The existing v4l2_i2c_new_subdev functions were modified to also call
s_config.

In the future the existing v4l2_i2c_new_subdev functions will be replaced
by a single v4l2_i2c_new_subdev function similar to v4l2_i2c_new_subdev_cfg
but without the irq and platform_data arguments.

Priority: normal

Signed-off-by: Hans Verkuil hverk...@xs4all.nl

diff -r ed3781a79c73 -r d9d3f7473951 linux/drivers/media/video/v4l2-common.c
--- a/linux/drivers/media/video/v4l2-common.c   Sat Jun 06 16:31:34 2009 +0400
+++ b/linux/drivers/media/video/v4l2-common.c   Tue Jun 09 22:12:33 2009 +0200
@@ -868,6 +868,17 @@
/* Decrease the module use count to match the first try_module_get. */
module_put(client-driver-driver.owner);
 
+   if (sd) {
+   /* We return errors from v4l2_subdev_call only if we have the
+  callback as the .s_config is not mandatory */
+   int err = v4l2_subdev_call(sd, core, s_config, 0, NULL);
+
+   if (err  err != -ENOIOCTLCMD) {
+   v4l2_device_unregister_subdev(sd);
+   sd = NULL;
+   }
+   }
+
 error:
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
/* If we have a client but no subdev, then something went wrong and
@@ -931,6 +942,17 @@
/* Decrease the module use count to match the first try_module_get. */
module_put(client-driver-driver.owner);
 
+   if (sd) {
+   /* We return errors from v4l2_subdev_call only if we have the
+  callback as the .s_config is not mandatory */
+   int err = v4l2_subdev_call(sd, core, s_config, 0, NULL);
+
+   if (err  err != -ENOIOCTLCMD) {
+   v4l2_device_unregister_subdev(sd);
+   sd = NULL;
+   }
+   }
+
 error:
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
/* If we have a client but no subdev, then something went wrong and
@@ -952,6 +974,150 @@
module_name, client_type, addrs);
 }
 EXPORT_SYMBOL_GPL(v4l2_i2c_new_probed_subdev_addr);
+
+/* Load an i2c sub-device. */
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
+struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev,
+   struct i2c_adapter *adapter, const char *module_name,
+   struct i2c_board_info *info, const unsigned short *probe_addrs)
+{
+   struct v4l2_subdev *sd = NULL;
+   struct i2c_client *client;
+
+   BUG_ON(!v4l2_dev);
+
+   if (module_name)
+   request_module(module_name);
+
+   /* Create the i2c client */
+   if (info-addr == 0  probe_addrs)
+   client = i2c_new_probed_device(adapter, info, probe_addrs);
+   else
+   client = i2c_new_device(adapter, info);
+
+   /* Note: by loading the module first we are certain that c-driver
+  will be set if the driver was found. If the module was not loaded
+  first, then the i2c core tries to delay-load the module for us,
+  and then c-driver is still NULL until the module is finally
+  loaded. This delay-load mechanism doesn't work if other drivers
+  want to use the i2c device, so explicitly loading the module
+  is the best alternative. */
+   if (client == NULL || client-driver == NULL)
+   goto error;
+
+   /* Lock the module so we can safely get the v4l2_subdev pointer */
+   if (!try_module_get(client-driver-driver.owner))
+   goto error;
+   sd = i2c_get_clientdata(client);
+
+   /* Register with the v4l2_device which increases the module's
+  use count as well. */
+   if 

Re: pull requests x patches at linux-media ML - Was: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2

2009-06-11 Thread Guennadi Liakhovetski
Hi Mauro, thanks for replying and for the explanation. I'll skip most of 
your message, and just keep the bits I'd like to reply to.

On Wed, 10 Jun 2009, Mauro Carvalho Chehab wrote:

 The same happens here: All patches added at the staging tree are sent to
 linuxtv-commits ML. So, they are there for discussions before my pull 
 requests.
 
 The main difference is that, in the case of Greg, his staging tree is a quilt
 one. On our case, our staging tree is mercurial.

Hm, I am not sure, is Greg's quilt tree publically available? And how many 
actually use it? Whereas your hg tree is publically available and it looks 
like a few do use it.

 We're currently merging about 900 patches per kernel window, on a window of
 about 10-12 weeks. This means about 90 patches per week, or about 13 patches
 per day (for a 7 days week), or 18 patches per day (for a 5 days week).
 
 So, if people just send one email per patch, this will increase our traffic by
 18 emails by day. It can be worse than that, if we consider that patches can 
 be
 replied, and that people use to write a patch 0 to describe a patch series.
 
 Considering about 50 messages per day, currently (today and yesterday's
 statistics - not sure those are typical days), this would increase the ML by
 about 36%. 

I still don't take this argument of increased traffic - I haven't seen a 
single complain please, don't increase the traffic, it'll make it worse 
for me.

 1) trivial patches (typo fixes, coding style, simple board additions, Kbuild
 fixes, etc);
 
 2) bug fix patches at drivers;
 
 3) new drivers;
 
 4) core changes.
 
 However, several driver maintainers don't care (or just forget about they) 
 for (1)
 type. Before patchwork, lots of such patches were lost forever in the middle 
 of
 dvb and v4l mailing lists. They are happy when someone (me) get those patches
 and apply at the tree or remind they to check and apply on their trees.
 
 patches of type (2) and (3) are in general sent via a driver maintainer and
 generally doesn't generate discussions.

I'm really happy we have subsistem maintainers that are such profecient in 
their work and such confident in their results that they don't need any 
reviews and discussions. I for one is not one of them, that's why I always 
first send my patches to the list.

 Also, for the developer, using the pull request is better, since they can
 better track when a patch series got merged.

I never argumented against pull requests, I'm suggesting they should 
follow patches posted to the list.

 The usage of a mix of PULL and PATCH requests has an extra trouble: it means
 that we'll receive most of the patches duplicated. So, it means that I need to
 manually mark all merged patches at patchwork queue, on _each_ pull request.

Yes, I see what you mean, but 1) you cannot avoid it, there are always 
patches from various authors, that they send to the ML, that some 
driver-maintainer will then pull through his or her tree and ask you to 
pull it. So, we really have to learn to proces this case efficiently.

 So, this adds an extra cost that will probably make life worse for everybody,
 with almost no gain (since there are really very few complaints about badly
 merged patches).
 
 That's said, I'm open to listen to opinions on how to improve our current 
 process

Well, I guess, I will have to subscribe to that hg-commit list (or 
whatever it's called), and use it. The problem is - it is a bit too late. 
But it's the best option available so far.

Another question, if you pull patches from someone's tree for review of 
one of those pull-requests (as you described in this mail, but I've 
deleted that piece already), how do you then quote the code if you want to 
comment on it? You export the patch again, hit reply on the pull-request, 
and paste the patch into it? And then add the quotation marks   
manually?...

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] ov511.c: video_register_device() return zero on success

2009-06-11 Thread Hans Verkuil
On Thursday 11 June 2009 06:40:14 Mauro Carvalho Chehab wrote:
 Em Wed, 10 Jun 2009 22:39:51 -0300
 Mauro Carvalho Chehab mche...@redhat.com escreveu:
 
  Em Sun, 31 May 2009 14:41:52 +0800
  Figo.zhang figo1...@gmail.com escreveu:
  
   video_register_device() return zero on success, it would not return a 
   positive integer.
   
   Signed-off-by: Figo.zhang figo1...@gmail.com
   --- 
drivers/media/video/ov511.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
   
   diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
   index 9af5532..816427e 100644
   --- a/drivers/media/video/ov511.c
   +++ b/drivers/media/video/ov511.c
   @@ -5851,7 +5851,7 @@ ov51x_probe(struct usb_interface *intf, const 
   struct usb_device_id *id)
 break;

 if (video_register_device(ov-vdev, VFL_TYPE_GRABBER,
   - unit_video[i]) = 0) {
   + unit_video[i]) == 0) {
 break;
 }
 }
  
  Nack.
  
  Errors are always negative. So, any zero or positive value indicates that 
  no error occurred.
  
  Yet, the logic for forcing ov51x to specific minor number seems broken: it 
  will
  end by registering the device twice, if used.
  
  So, that part of the function needs a rewrite. I'll fix it.
  
 
 Hmm... the issue seems more complex than I've imagined...
 
 When ov511 were written, it was assumed that video_register_device(dev, v, nr)
 would have the following behavior:
 
   if nr = -1, it would do dynamic minor allocation;
   if nr = 0, it would allocate to 'nr' minor or fail.
 
 With the original behavior.
 
 The ov511_probe registering loop is doing something like this (I did a cleanup
 to allow a better understand of the logic):
 
 snip
 #define OV511_MAX_UNIT_VIDEO 16
 ...
 static int unit_video[OV511_MAX_UNIT_VIDEO];
 ...
 module_param_array(unit_video, int, num_uv, 0);
 MODULE_PARM_DESC(unit_video,
   Force use of specific minor number(s). 0 is not allowed.);
 ...
 static int
 ov51x_probe(struct usb_interface *intf, const struct usb_device_id *id)
 {
 ...
 for (i = 0; i  OV511_MAX_UNIT_VIDEO; i++) {
 /* Minor 0 cannot be specified; assume user wants autodetect 
 */
 if (unit_video[i] == 0)
 break;
 
 if (video_register_device(ov-vdev, VFL_TYPE_GRABBER,
 unit_video[i]) = 0)
 goto register_succeded;
 }
 
 /* Use the next available one */
 if (video_register_device(ov-vdev, VFL_TYPE_GRABBER, -1)  0) {
 err(video_register_device failed);
 goto error;
 
 register_succeeded:
 dev_info(intf-dev, Device at %s registered to minor %d\n,
  ov-usb_path, ov-vdev-minor);
 /snip
 
 So, if you probe ov511 with a list of device numbers, for example:
 
 modprobe ov511 4,1,3
 
 And assuming that you have 5 ov511 devices, and connect they one by one,
 they'll gain the following device numbers (at the connection order):
 /dev/video4
 /dev/video1
 /dev/video3
 /dev/video0
 /dev/video2
 
 However, changeset 9133:
 
 changeset:   9133:64aed7485a43
 parent:  9073:4db9722caf4f
 user:Hans Verkuil hverk...@xs4all.nl
 date:Sat Oct 04 13:36:54 2008 +0200
 summary: v4l: disconnect kernel number from minor
 
 Changed the behavior video_register_device(dev, v, nr):
 
 + nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
 
 So, instead of accepting just -1 or nr, it will now do:
   if nr = -1, it will do dynamic minor allocation (as before);
   if nr = 0, it will also do dynamic minor allocation, but starting from 
 nr.
 
 So, the new code won't fail if nr is already allocated, but it will return the
 next unallocated nr.
 
 With the ov511 code, this means that you'll have, instead:
 
 /dev/video5
 /dev/video6
 /dev/video7
 /dev/video8
 /dev/video9
 
 So, changeset 9133 actually broke the ov511 probe original behavior.
 
 In order to restore the original behavior, the probe logic should be replaced
 by something else (like the approach taken by em28xx).
 
 Also, changeset 9133 may also cause other side effects on other drivers that
 were expecting the original behavior.
 
 To make things worse, the function comment doesn't properly explain the 
 current
 behavior.
 
 ---
 
 Figo,
 
 Since we are in the middle of a merge window, it is unlikely that I'll have
 enough time to properly fix it right now (since my priority right now is to
 merge the existing patches).
 
 As you started proposing a patch for it, maybe you could try to fix it and
 check about similar troubles on other drivers.
 
 Cheers,
 Mauro
 

Since I made that change I'm willing to look at this. Some comments definitely
need improving at the least. Also ivtv and cx18 rely on the current behavior,
so any changes need to be done carefully.

But one question first: isn't the current 

About V4L2_MEMORY_OVERLAY

2009-06-11 Thread Dongsoo, Nathaniel Kim
Hello everyone,

What I'm curious is about what is V4L2_MEMORY_OVERLAY for. Even though
I have been using overlay capability before, I always used
V4L2_MEMORY_MMAP instead of that. And our v4l2 api document tells
nothing about V4L2_MEMORY_MMAP (only [todo] is left..OMG ;-()

But looking into videobuf, I can see some codes implemented for
V4L2_MEMORY_OVERLAY. But I'm not sure about which point can make
driver available for V4L2_MEMORY_OVERLAY.

If the implementation of that method is still in progress, can I have
any information or chance to participate? Until then I might be using
V4L2_MEMORY_MMAP in my camera interface driver.
Cheers,

Nate



-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.com
--
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] ov511.c: video_register_device() return zero on success

2009-06-11 Thread Figo.zhang
On Thu, 2009-06-11 at 01:40 -0300, Mauro Carvalho Chehab wrote:
 Em Wed, 10 Jun 2009 22:39:51 -0300
 Mauro Carvalho Chehab mche...@redhat.com escreveu:
 
  Em Sun, 31 May 2009 14:41:52 +0800
  Figo.zhang figo1...@gmail.com escreveu:
  
   video_register_device() return zero on success, it would not return a 
   positive integer.
   
   Signed-off-by: Figo.zhang figo1...@gmail.com
   --- 
drivers/media/video/ov511.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
   
   diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
   index 9af5532..816427e 100644
   --- a/drivers/media/video/ov511.c
   +++ b/drivers/media/video/ov511.c
   @@ -5851,7 +5851,7 @@ ov51x_probe(struct usb_interface *intf, const 
   struct usb_device_id *id)
 break;

 if (video_register_device(ov-vdev, VFL_TYPE_GRABBER,
   - unit_video[i]) = 0) {
   + unit_video[i]) == 0) {
 break;
 }
 }
  
  Nack.
  
  Errors are always negative. So, any zero or positive value indicates that 
  no error occurred.
  
  Yet, the logic for forcing ov51x to specific minor number seems broken: it 
  will
  end by registering the device twice, if used.
  
  So, that part of the function needs a rewrite. I'll fix it.
  
 
 Hmm... the issue seems more complex than I've imagined...
 
 When ov511 were written, it was assumed that video_register_device(dev, v, nr)
 would have the following behavior:
 
   if nr = -1, it would do dynamic minor allocation;
   if nr = 0, it would allocate to 'nr' minor or fail.
 
 With the original behavior.
 
 The ov511_probe registering loop is doing something like this (I did a cleanup
 to allow a better understand of the logic):
 
 snip
 #define OV511_MAX_UNIT_VIDEO 16
 ...
 static int unit_video[OV511_MAX_UNIT_VIDEO];
 ...
 module_param_array(unit_video, int, num_uv, 0);
 MODULE_PARM_DESC(unit_video,
   Force use of specific minor number(s). 0 is not allowed.);
 ...
 static int
 ov51x_probe(struct usb_interface *intf, const struct usb_device_id *id)
 {
 ...
 for (i = 0; i  OV511_MAX_UNIT_VIDEO; i++) {
 /* Minor 0 cannot be specified; assume user wants autodetect 
 */
 if (unit_video[i] == 0)
 break;
 
 if (video_register_device(ov-vdev, VFL_TYPE_GRABBER,
 unit_video[i]) = 0)
 goto register_succeded;
 }
 
 /* Use the next available one */
 if (video_register_device(ov-vdev, VFL_TYPE_GRABBER, -1)  0) {
 err(video_register_device failed);
 goto error;
 
 register_succeeded:
 dev_info(intf-dev, Device at %s registered to minor %d\n,
  ov-usb_path, ov-vdev-minor);
 /snip
 
 So, if you probe ov511 with a list of device numbers, for example:
 
 modprobe ov511 4,1,3
 

you means specify the minior video
device: /dev/vidoe4,/dev/video1, /dev/video3 ? 

it maybe : modprobe ov511 unit_video=4,1,3
  
 And assuming that you have 5 ov511 devices, and connect they one by one,
 they'll gain the following device numbers (at the connection order):
 /dev/video4
 /dev/video1
 /dev/video3
 /dev/video0
 /dev/video2
 
 However, changeset 9133:
 
 changeset:   9133:64aed7485a43
 parent:  9073:4db9722caf4f
 user:Hans Verkuil hverk...@xs4all.nl
 date:Sat Oct 04 13:36:54 2008 +0200
 summary: v4l: disconnect kernel number from minor
 
 Changed the behavior video_register_device(dev, v, nr):
 
 + nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
 
 So, instead of accepting just -1 or nr, it will now do:
   if nr = -1, it will do dynamic minor allocation (as before);
   if nr = 0, it will also do dynamic minor allocation, but starting from 
 nr.
 
 So, the new code won't fail if nr is already allocated, but it will return the
 next unallocated nr.
 
 With the ov511 code, this means that you'll have, instead:
 
 /dev/video5
 /dev/video6
 /dev/video7
 /dev/video8
 /dev/video9
 
 So, changeset 9133 actually broke the ov511 probe original behavior.
 
 In order to restore the original behavior, the probe logic should be replaced
 by something else (like the approach taken by em28xx).
 
 Also, changeset 9133 may also cause other side effects on other drivers that
 were expecting the original behavior.
 
 To make things worse, the function comment doesn't properly explain the 
 current
 behavior.
 
 ---
 
 Figo,
 
 Since we are in the middle of a merge window, it is unlikely that I'll have
 enough time to properly fix it right now (since my priority right now is to
 merge the existing patches).
 
 As you started proposing a patch for it, maybe you could try to fix it and
 check about similar troubles on other drivers.
 
 Cheers,
 Mauro


in v2, if insmod without specify 'unit_video', it use autodetect video device.
if specify the 'unit_video', it 

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2

2009-06-11 Thread Guennadi Liakhovetski
On Wed, 10 Jun 2009, Mauro Carvalho Chehab wrote:

 Em Wed, 10 Jun 2009 23:36:32 +0200 (CEST)
 Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
 
  someone writes a script to intercept all hg pull requests from lmml 
  (procmail rule), forward that mail to a special media-patch list, and 
  extract and post as replies to that mail all individual patches? And that 
  list should be configured to only accept mails from that script or replies 
  to its mails, so, it'd be spam-free. And that list would also be used for 
  patch discussion. How does this sound?
 
 This can be done. If you write such script in perl or python [1], I can put 
 it to
 run at linuxtv. You'll likely need to handle also the pull request replies.
 
 [1] since we don't have procmail (or exim) installed there.

Hm, yeah, thanks, but I think, if I were to do this, I would just do a 
local script, that would

cp -al v4l-dvb pull
cd pull
hg pull -u tree-to-pull

for $mail in @mails {
hg extract $mail | mail ...
}

cd ..
rm -rf pull

and just mail the patches to me locally. But I don't think I'd be doing 
this, I don't have the time. I'll just subscribe to the commits ML and 
live with the fact, that the delta between patches in hg and in mainline 
git will grow, as more patches in hg wil have to be fixed by incremental 
patches, which you then will merge before importing into git...

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


[PATCH/RFC 0/4] various filter controls

2009-06-11 Thread Guennadi Liakhovetski
Hi all

I asked already before what controls to use for various image filters, 
have only got replies from one person (thanks, Nate), so, here come 
patches. One of them, adding the missing control could be applied, I 
think, if the affected file hasn't changed too much in the last month. 
Others will have to wait in my soc-camera - v4l2-subdev conversion queue 
until around 2.6.32 (I'll post a status mail shortly). But comments are 
welcome 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


[PATCH 1/4] V4L2: add a new V4L2_CID_BAND_STOP_FILTER integer control

2009-06-11 Thread Guennadi Liakhovetski
Add a new V4L2_CID_BAND_STOP_FILTER integer control, which either switches the
band-stop filter off, or sets it to a certain strength.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 include/linux/videodev2.h |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index ebb2ea6..f50ec61 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -894,8 +894,10 @@ enum v4l2_colorfx {
V4L2_COLORFX_SEPIA  = 2,
 };
 
+#define V4L2_CID_BAND_STOP_FILTER  (V4L2_CID_BASE+32)
+
 /* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+33)
 
 /*  MPEG-class control IDs defined by V4L2 */
 #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
-- 
1.6.2.4

--
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 2/4] ov772x: implement a band-stop filter support

2009-06-11 Thread Guennadi Liakhovetski
The V4L2_CID_BAND_STOP_FILTER control is used to switch the Banding 
Filter on OV772x cameras on and off and to set the minimum AEC value in 
BDBASE register. BDBASE default value is 0xff, which makes the use of the 
filter practically unnoticeable. Reducing BDBASE increases the effect, 
which may be interpreted as increasing the filter strength. Setting 
strength to 0 switches the filter completely off by clearing bit 5 in 
COM8.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/video/ov772x.c |   52 -
 1 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 1191597..4c550f9 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -403,8 +403,9 @@ struct ov772x_priv {
const struct ov772x_color_format *fmt;
const struct ov772x_win_size *win;
int   model;
-   unsigned int  flag_vflip:1;
-   unsigned int  flag_hflip:1;
+   unsigned shortflag_vflip:1;
+   unsigned shortflag_hflip:1;
+   unsigned shortband_filter;  /* 256 - BDBASE, 0 if 
(!COM8[5]) */
 };
 
 #define ENDMARKER { 0xff, 0xff }
@@ -569,6 +570,15 @@ static const struct v4l2_queryctrl ov772x_controls[] = {
.step   = 1,
.default_value  = 0,
},
+   {
+   .id = V4L2_CID_BAND_STOP_FILTER,
+   .type   = V4L2_CTRL_TYPE_INTEGER,
+   .name   = Band-stop filter,
+   .minimum= 0,
+   .maximum= 256,
+   .step   = 1,
+   .default_value  = 0,
+   },
 };
 
 
@@ -674,6 +684,9 @@ static int ov772x_g_ctrl(struct v4l2_subdev *sd, struct 
v4l2_control *ctrl)
case V4L2_CID_HFLIP:
ctrl-value = priv-flag_hflip;
break;
+   case V4L2_CID_BAND_STOP_FILTER:
+   ctrl-value = priv-band_filter;
+   break;
}
return 0;
 }
@@ -700,6 +713,29 @@ static int ov772x_s_ctrl(struct v4l2_subdev *sd, struct 
v4l2_control *ctrl)
val ^= HFLIP_IMG;
ret = ov772x_mask_set(client, COM3, HFLIP_IMG, val);
break;
+   case V4L2_CID_BAND_STOP_FILTER:
+   if ((unsigned)ctrl-value  256)
+   ctrl-value = 256;
+   if (ctrl-value == priv-band_filter)
+   break;
+   if (!ctrl-value) {
+   /* Switch the filter off, it is on now */
+   ret = ov772x_mask_set(client, BDBASE, 0xff, 0xff);
+   if (!ret)
+   ret = ov772x_mask_set(client, COM8,
+ BNDF_ON_OFF, 0);
+   } else {
+   /* Switch the filter on, set AEC low limit */
+   val = 256 - ctrl-value;
+   ret = ov772x_mask_set(client, COM8,
+ BNDF_ON_OFF, BNDF_ON_OFF);
+   if (!ret)
+   ret = ov772x_mask_set(client, BDBASE,
+ 0xff, val);
+   }
+   if (!ret)
+   priv-band_filter = ctrl-value;
+   break;
}
 
return ret;
@@ -893,6 +929,18 @@ static int ov772x_set_params(struct i2c_client *client,
if (ret  0)
goto ov772x_set_fmt_error;
 
+   /*
+* set COM8
+*/
+   if (priv-band_filter) {
+   ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1);
+   if (!ret)
+   ret = ov772x_mask_set(client, BDBASE,
+ 0xff, 256 - priv-band_filter);
+   if (ret  0)
+   goto ov772x_set_fmt_error;
+   }
+
return ret;
 
 ov772x_set_fmt_error:
-- 
1.6.2.4

--
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 3/4] soc-camera: add support for camera-host controls

2009-06-11 Thread Guennadi Liakhovetski
Until now soc-camera only supported client (sensor) controls. This patch
enables camera-host drivers to implement their own controls too.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/video/soc_camera.c |   24 
 include/media/soc_camera.h   |4 
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 824c68b..8e987ca 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -633,6 +633,7 @@ static int soc_camera_queryctrl(struct file *file, void 
*priv,
 {
struct soc_camera_file *icf = file-private_data;
struct soc_camera_device *icd = icf-icd;
+   struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
int i;
 
WARN_ON(priv != file-private_data);
@@ -640,6 +641,15 @@ static int soc_camera_queryctrl(struct file *file, void 
*priv,
if (!qc-id)
return -EINVAL;
 
+   /* First check host controls */
+   for (i = 0; i  ici-ops-num_controls; i++)
+   if (qc-id == ici-ops-controls[i].id) {
+   memcpy(qc, (ici-ops-controls[i]),
+   sizeof(*qc));
+   return 0;
+   }
+
+   /* Then device controls */
for (i = 0; i  icd-ops-num_controls; i++)
if (qc-id == icd-ops-controls[i].id) {
memcpy(qc, (icd-ops-controls[i]),
@@ -656,6 +666,7 @@ static int soc_camera_g_ctrl(struct file *file, void *priv,
struct soc_camera_file *icf = file-private_data;
struct soc_camera_device *icd = icf-icd;
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+   int ret;
 
WARN_ON(priv != file-private_data);
 
@@ -672,6 +683,12 @@ static int soc_camera_g_ctrl(struct file *file, void *priv,
return 0;
}
 
+   if (ici-ops-get_ctrl) {
+   ret = ici-ops-get_ctrl(icd, ctrl);
+   if (ret != -ENOIOCTLCMD)
+   return ret;
+   }
+
return v4l2_device_call_until_err(ici-v4l2_dev, (__u32)icd, core, 
g_ctrl, ctrl);
 }
 
@@ -681,9 +698,16 @@ static int soc_camera_s_ctrl(struct file *file, void *priv,
struct soc_camera_file *icf = file-private_data;
struct soc_camera_device *icd = icf-icd;
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+   int ret;
 
WARN_ON(priv != file-private_data);
 
+   if (ici-ops-set_ctrl) {
+   ret = ici-ops-set_ctrl(icd, ctrl);
+   if (ret != -ENOIOCTLCMD)
+   return ret;
+   }
+
return v4l2_device_call_until_err(ici-v4l2_dev, (__u32)icd, core, 
s_ctrl, ctrl);
 }
 
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 3bc5b6b..2d116bb 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -83,7 +83,11 @@ struct soc_camera_host_ops {
int (*reqbufs)(struct soc_camera_file *, struct v4l2_requestbuffers *);
int (*querycap)(struct soc_camera_host *, struct v4l2_capability *);
int (*set_bus_param)(struct soc_camera_device *, __u32);
+   int (*get_ctrl)(struct soc_camera_device *, struct v4l2_control *);
+   int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
unsigned int (*poll)(struct file *, poll_table *);
+   const struct v4l2_queryctrl *controls;
+   int num_controls;
 };
 
 #define SOCAM_SENSOR_INVERT_PCLK   (1  0)
-- 
1.6.2.4

--
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 4/4] sh_mobile_ceu_camera: add a control for the camera low-pass filter

2009-06-11 Thread Guennadi Liakhovetski
Use the V4L2_CID_SHARPNESS control to switch SH-mobile camera low-pass filter.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---

Is this a suitable control for this filter?

 drivers/media/video/sh_mobile_ceu_camera.c |   54 +++-
 1 files changed, 53 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
b/drivers/media/video/sh_mobile_ceu_camera.c
index 7ac4d92..8274fb1 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -499,7 +499,6 @@ static int sh_mobile_ceu_set_bus_param(struct 
soc_camera_device *icd,
ceu_write(pcdev, CAPWR, (height  16) | width);
ceu_write(pcdev, CFLCR, 0); /* no scaling */
ceu_write(pcdev, CFSZR, (height  16) | cfszr_width);
-   ceu_write(pcdev, CLFCR, 0); /* no lowpass filter */
 
/* A few words about byte order (observed in Big Endian mode)
 *
@@ -784,6 +783,55 @@ static void sh_mobile_ceu_init_videobuf(struct 
videobuf_queue *q,
   icd);
 }
 
+static int sh_mobile_ceu_get_ctrl(struct soc_camera_device *icd,
+ struct v4l2_control *ctrl)
+{
+   struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+   struct sh_mobile_ceu_dev *pcdev = ici-priv;
+   u32 val;
+
+   switch (ctrl-id) {
+   case V4L2_CID_SHARPNESS:
+   val = ceu_read(pcdev, CLFCR);
+   ctrl-value = val ^ 1;
+   return 0;
+   }
+   return -ENOIOCTLCMD;
+}
+
+static int sh_mobile_ceu_set_ctrl(struct soc_camera_device *icd,
+ struct v4l2_control *ctrl)
+{
+   struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+   struct sh_mobile_ceu_dev *pcdev = ici-priv;
+
+   switch (ctrl-id) {
+   case V4L2_CID_SHARPNESS:
+   switch (icd-current_fmt-fourcc) {
+   case V4L2_PIX_FMT_NV12:
+   case V4L2_PIX_FMT_NV21:
+   case V4L2_PIX_FMT_NV16:
+   case V4L2_PIX_FMT_NV61:
+   ceu_write(pcdev, CLFCR, !ctrl-value);
+   return 0;
+   }
+   return -EINVAL;
+   }
+   return -ENOIOCTLCMD;
+}
+
+static const struct v4l2_queryctrl sh_mobile_ceu_controls[] = {
+   {
+   .id = V4L2_CID_SHARPNESS,
+   .type   = V4L2_CTRL_TYPE_BOOLEAN,
+   .name   = Low-pass filter,
+   .minimum= 0,
+   .maximum= 1,
+   .step   = 1,
+   .default_value  = 0,
+   },
+};
+
 static struct soc_camera_host_ops sh_mobile_ceu_host_ops = {
.owner  = THIS_MODULE,
.add= sh_mobile_ceu_add_device,
@@ -792,11 +840,15 @@ static struct soc_camera_host_ops sh_mobile_ceu_host_ops 
= {
.set_crop   = sh_mobile_ceu_set_crop,
.set_fmt= sh_mobile_ceu_set_fmt,
.try_fmt= sh_mobile_ceu_try_fmt,
+   .set_ctrl   = sh_mobile_ceu_set_ctrl,
+   .get_ctrl   = sh_mobile_ceu_get_ctrl,
.reqbufs= sh_mobile_ceu_reqbufs,
.poll   = sh_mobile_ceu_poll,
.querycap   = sh_mobile_ceu_querycap,
.set_bus_param  = sh_mobile_ceu_set_bus_param,
.init_videobuf  = sh_mobile_ceu_init_videobuf,
+   .controls   = sh_mobile_ceu_controls,
+   .num_controls   = ARRAY_SIZE(sh_mobile_ceu_controls),
 };
 
 static int __devinit sh_mobile_ceu_probe(struct platform_device *pdev)
-- 
1.6.2.4

--
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] flexcop-pci: add suspend/resume support

2009-06-11 Thread Patrick Boettcher

Hi Matthias,

On Tue, 26 May 2009, Matthias Schwarzott wrote:

This patch adds suspend/resume support to flexcop-pci driver.

I could only test this patch with the bare card, but without having a DVB-S
signal. I checked it with and without running szap (obviously getting no
lock).
It works fine here with suspend-to-disk on a tuxonice kernel.


As I'm notoriously out of time I haven't yet checked the functionality 
with suspend though I'm looking forward to do so, because it would 
extremely nice to use suspend2disk for shutting down rather than shutdown.



Setting of hw-filter in resume is done the same way as the watchdog does it:
Just looping over fc-demux.feed_list and running flexcop_pid_feed_control.
Where I am unsure is the order at resume. For now hw filters get started
first, then dma is re-started.

Do I need to give special care to irq handling?


Good question. I think starting the streaming the same way as it is done 
in normal operation would do the trick, but I'm not sure whether this is 
possible for suspend/resume. I need to try.


Thanks a lot for the patch, I will try to adapt it also for dvb-usb. Like 
that all dvb-usb-based device will become resumable in one shot :). But 
time will tell when. :/


Patrick.

--
  Mail: patrick.boettc...@desy.de
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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: dib0700 Nova-TD-Stick problem

2009-06-11 Thread Patrick Boettcher

Hi Soeren,

On Wed, 3 Jun 2009, soeren.m...@stud.uni-hannover.de wrote:


Soeren.Moch wrote:

For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream
errors, although the demod bit-error-rate (BER/UNC) was zero.

I could track down this problem to dib0700_streaming_ctrl:
When one channel is streaming and the other channel is switched on, the
stream of the already running channel gets broken.

I think this is a firmware bug and should be fixed there, but I attach a
driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW
1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to reduce
the urb count to 1, I consider this patch as quick hack, not a real
solution.

Probably the same problem exists with other dib0700 diversity/dual
devices, without a firmware fix a similar driver patch may be helpful.

Regards,
Soeren



Hi Patrick,

do you see any chance that somebody will fix the firmware?


:/ .

If not, can you take into consideration to remove the 
dib0700_streaming_ctrl callback as in the (again) attached patch so 
solve the switch-on problem?


I'd rather fix the streaming-enable command, which might be not correctly 
implemented. Need to check. :(


The patch runs flawlessly on my vdr system 
for weeks now. There are no negative side effects from reducing the urb 
count to 1.


Hmm, on fast systems certainly not, but once the system is loaded or old 
there might be data losses.


It would be nice to have other people trying this workaround on other 
cards so that we know that it really helps and not just solves the problem 
for you.


Patrick.

--
  Mail: patrick.boettc...@desy.de
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Hans Verkuil

 Karicheri, Muralidharan a écrit :

 We need
 streaming capability in the driver. This is how our driver works
 with mt9t031 sensor
  raw-bus (10 bit)
 vpfe-capture  - mt9t031 driver
  ||
  V  V
VPFEMT9T031

 VPFE hardware has internal timing and DMA controller to
 copy data frame by frame from the sensor output to SDRAM.
 The PCLK form the sensor is used to generate the internal
 timing.
 So, what is missing in the driver apart from the ability to specify
 a frame-rate?

 [MK] Does the mt9t031 output one frame (snapshot) like in a camera or
 can it output frame continuously along with PCLK, Hsync and Vsync
 signals like in a video streaming device. VPFE capture can accept frames
 continuously from the sensor synchronized to PCLK, HSYNC and VSYNC and
 output frames to application using QBUF/DQBUF. In our implementation, we
 have timing parameters for the sensor to do streaming at various
 resolutions and fps. So application calls S_STD to set these timings. I
 am not sure if this is an acceptable way of implementing it. Any
 comments?

 PCLK, HSYNC, VSYNC are generated by the CMOS sensor. I don't think you
 can set the timings. Depending on sensor settings, pixel clock speed etc
 .., the frame rate will vary.

 You could perhaps play with the CMOS sensor registers so that when
 settings a standard, the driver somehow set the various exposition
 parameter and pll settings to get a specified framerate.

 This will vary with each sensor and each platform (because of
 pixelclock). More over, chances are that it will be conflicting with
 other control.

 For example if you set a fixed gain and autoexpo, some sensor will see
 a drop in fps under low light conditions. I think this kind of
 arbitration  should be left to userspace.

 Unless the sensor supports a specific standard, I don't think the driver
 should try to make behind the scene modification to camera sensor
 register in response to a S_STD ioctl.

The S_STD call is hopelessly inadequate to deal with these types of
devices. What is needed is a new call that allows you to set the exact
timings you want: frame width/height, back/front porch, h/vsync width,
pixelclock. It is my opinion that the use of S_STD should be limited to
standard definition type inputs, and not used for other devices like
sensors or HD video.

Proposals for such a new ioctl are welcome :-)

Regards,

 Hans


 JP François


 Thanks

 Murali

 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/

 ___
 Davinci-linux-open-source mailing list
 davinci-linux-open-sou...@linux.davincidsp.com
 http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



 ___
 Davinci-linux-open-source mailing list
 davinci-linux-open-sou...@linux.davincidsp.com
 http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source




-- 
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: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/

2009-06-11 Thread Patrick Boettcher

Hi Trent,

On Wed, 27 May 2009, Trent Piepho wrote:


On Tue, 26 May 2009, Patrick Boettcher wrote:

MHz to 161 Mhz as welll as 439-447 MHz.  Probably wrong.  My guess is the
data sheet says, low band 48 to 154 MHz, mid band 161 MHz to 439 MHz,
etc., where 154 is the frequency of the last channel in the low band and
161 is the first channel in the mid band.  Then someone translated this to
code without really understanding what's going on.  It should probably be:

if  (params-frequency  44300) bs = 0x08;
else if (params-frequency  15750) bs = 0x0a;
elsebs = 0x09;

The tuner's limits should already be enforced elsewhere.  Or just convert
this to use dvb_pll.


Thanks for pointing this out, can you please provide a patch for that?
Preferably for the dvb_pll-solution?


I've done this, but found some more mistakes in the flexcop code wrt
frontend attachment.

In patch 7469 you changed a failure path dvb_frontend_detach(fc-fe) into
a fc-fe-ops-release(fc-fe), which isn't correct.  There is more stuff
dvb_frontend_detach() does besides call the main release method.

The various attach functions in flexcop-fe-tuner don't return success/fail,
which is a problem when frontend attachment partially fails.  For instance
if mt352 attachment works but dvb-pll attachment then fails the driver
will think everything is ok because fc-fe is non-NULL, but the tuner will
not work.  It makes more sense to consider this an error and clean up.

There are a couple other places where frontend attachment can partially
fail where I wasn't entirely sure what's right.  In
skystar2_rev27_attach(), after the s5h1420 demod is attached, attachment of
a ISL6421 LNB and ITD1000 tuner is attempted.  If these fail an error
message is printed but the rest of the code will consider the frontend to
be successfully attached.  Can the frontend work if the ISL6421 or ITD1000
didn't attach (which can happen if the driver isn't present even if the
hardware is fine)?  I'm guessing not and called these cases an error.  If
it's not an error, then the err() printout should probably be warning or
info level.

Does this patch to fix these problems look ok?


In fact, everything looks correct in my eyes. I'll ask Mauro to pull any 
minute from now.


I even have an explaination why the failing attach of the itd1000 was 
not errored out: when I did the development I was using a userspace 
proprietary driver to validate, for that I needed the demod to be 
attached...


Thanks for cleaning up this mess.

best regards,

Patrick.
--
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: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Hans de Goede



On 06/11/2009 11:33 AM, Hans Verkuil wrote:


On 06/11/2009 10:35 AM, Hans Verkuil wrote:


snip (a lot)


Hmm,

Why would we want the *application* to set things like this *at all* ?
with sensors hsync and vsync and other timing are something between
the bridge and the sensor, actaully in my experience the correct
hsync / vsync timings to program the sensor to are very much bridge
specific. So IMHO this should not be exposed to userspace at all.

All userspace should be able to control is the resolution and the
framerate. Although controlling the framerate in many cases also
means controlling the maximum exposure time. So in many cases
one cannot even control the framerate. (Asking for 30 fps in an
artificially illuminated room will get you a very dark, useless
picture, with most sensors). Yes this means that with cams with
use autoexposure (which is something which we really want where ever
possible), the framerate can and will change while streaming.


I think we have three possible use cases here:

- old-style standard definition video: use S_STD



Ack


- webcam-like devices: a combination of S_FMT and S_PARM I think? Correct
me if I'm wrong. S_STD is useless for this, right?



Ack


- video streaming devices like the davinci videoports where you can hook
up HDTV receivers or FPGAs: here you definitely need a new API to setup
the streaming parameters, and you want to be able to do that from the
application as well. Actually, sensors are also hooked up to these devices
in practice. And there you also want to be able to setup these parameters.
You will see this mostly (only?) on embedded platforms.



I agree we need an in kernel API for this, but why expose it to 
userspace, as you say this will only happen on embedded systems, 
shouldn't the info then go in a board_info file / struct ?


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


About v4l2 output interface

2009-06-11 Thread xie
Dear Dongsoo Nathaniel ~~

In the spec , I have readed this sentence :
Video output devices encode stills or image sequences as analog video
signal.
Can you give me a function-example about output interface in real life
~~ ?
Thanks ~

Best regards ~!~

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


About v4l2 output interface

2009-06-11 Thread xie
Dear Dongsoo Nathaniel ~~

Does the capture interface get the image and the output interface
display the image ~ ?

Best regards ~

--
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: About v4l2 output interface

2009-06-11 Thread Dongsoo, Nathaniel Kim
Sorry, I have no idea about that.
I have never been that far.

The only thing I ever heard about v4l2 output, is on ELC 2009
presentation list. You can find at following URL:
http://tree.celinuxforum.org/CelfPubWiki/ELC2009Presentations
Just look for Matthew Porter's presentation.

Or maintainer who is responsible for v4l2 output can help you I
guess.(but not me)
Cheers,

Nate


On Thu, Jun 11, 2009 at 7:06 PM, xieyili@gmail.com wrote:
 Dear Dongsoo Nathaniel ~~

 Does the capture interface get the image and the output interface
 display the image ~ ?

 Best regards ~





-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.com
--
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


I wish you good luck everyday

2009-06-11 Thread xie
Dear Dongsoo, Nathaniel ~~

Thanks very much for your help ~~ I am very Sorry to have taken up so
much of your time and you always be so patient. You must be an angel ~~

I am making progress with the help of yours ~ I wish you good luck
everyday with all my heart ~~


在 2009-06-11四的 19:21 +0900,Dongsoo, Nathaniel Kim写道:
 Sorry, I have no idea about that.
 I have never been that far.
 
 The only thing I ever heard about v4l2 output, is on ELC 2009
 presentation list. You can find at following URL:
 http://tree.celinuxforum.org/CelfPubWiki/ELC2009Presentations
 Just look for Matthew Porter's presentation.
 
 Or maintainer who is responsible for v4l2 output can help you I
 guess.(but not me)
 Cheers,
 
 Nate
 
 
 On Thu, Jun 11, 2009 at 7:06 PM, xieyili@gmail.com wrote:
  Dear Dongsoo Nathaniel ~~
 
  Does the capture interface get the image and the output interface
  display the image ~ ?
 
  Best regards ~
 
 
 
 
 

--
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: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Hans Verkuil



 On 06/11/2009 11:33 AM, Hans Verkuil wrote:

 On 06/11/2009 10:35 AM, Hans Verkuil wrote:

 snip (a lot)

 Hmm,

 Why would we want the *application* to set things like this *at all* ?
 with sensors hsync and vsync and other timing are something between
 the bridge and the sensor, actaully in my experience the correct
 hsync / vsync timings to program the sensor to are very much bridge
 specific. So IMHO this should not be exposed to userspace at all.

 All userspace should be able to control is the resolution and the
 framerate. Although controlling the framerate in many cases also
 means controlling the maximum exposure time. So in many cases
 one cannot even control the framerate. (Asking for 30 fps in an
 artificially illuminated room will get you a very dark, useless
 picture, with most sensors). Yes this means that with cams with
 use autoexposure (which is something which we really want where ever
 possible), the framerate can and will change while streaming.

 I think we have three possible use cases here:

 - old-style standard definition video: use S_STD


 Ack

 - webcam-like devices: a combination of S_FMT and S_PARM I think?
 Correct
 me if I'm wrong. S_STD is useless for this, right?


 Ack

 - video streaming devices like the davinci videoports where you can hook
 up HDTV receivers or FPGAs: here you definitely need a new API to setup
 the streaming parameters, and you want to be able to do that from the
 application as well. Actually, sensors are also hooked up to these
 devices
 in practice. And there you also want to be able to setup these
 parameters.
 You will see this mostly (only?) on embedded platforms.


 I agree we need an in kernel API for this, but why expose it to
 userspace, as you say this will only happen on embedded systems,
 shouldn't the info then go in a board_info file / struct ?

These timings are not fixed. E.g. a 720p60 video stream has different
timings compared to a 1080p60 stream. So you have to be able to switch
from userspace. It's like PAL and NTSC, but then many times worse :-)

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: dib0700 Nova-TD-Stick problem

2009-06-11 Thread Soeren . Moch

Hi Patrick!

Patrick Boettcher wrote:

Hi Soeren,

For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream
errors, although the demod bit-error-rate (BER/UNC) was zero.

I could track down this problem to dib0700_streaming_ctrl:
When one channel is streaming and the other channel is switched on, the
stream of the already running channel gets broken.

I think this is a firmware bug and should be fixed there, but I attach a
driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW
1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to reduce
the urb count to 1, I consider this patch as quick hack, not a real
solution.

Probably the same problem exists with other dib0700 diversity/dual
devices, without a firmware fix a similar driver patch may be helpful.

Regards,
Soeren



Hi Patrick,

do you see any chance that somebody will fix the firmware?


:/ .


If not, can you take into consideration to remove the
dib0700_streaming_ctrl callback as in the (again) attached patch so
solve the switch-on problem?


I'd rather fix the streaming-enable command, which might be not
correctly implemented. Need to check. :(


Since the dib0700_streaming_ctrl is more or less a firmware interface only,
I found nothing to patch there. I played with the enable bits but could not
find any working solution. But of course you know the driver code (and maybe
the firmware) better, and maybe somebody from dibcom can give any hint...

Since the streaming_control implementation within the dib0700 seemed to be
not fully usb compliant in the past (e.g. disconnect problem we have seen
a few month ago), it may be not the worst idea to remove this callback
entirely (after stream enable in the init phase). But I don't know for what
side effect the firmware uses this call...


The patch runs flawlessly on my vdr system for weeks now. There are no
negative side effects from reducing the urb count to 1.


Hmm, on fast systems certainly not, but once the system is loaded or old
there might be data losses.


My vdr system is based on a via epia board, so I use a C7 cpu (not known to
be the fastest at the market) and via usb controller. I can use one or both
of my dvb-t sticks (nova-t and nova-td) together at the same ehci controller,
I can record up to 3 dvb-t TS-streams simultaneously, I can use PIP decoding
to generate 100% cpu load (full-featured dvb card used for primary video
decode). I never observed any usb data loss with urb count set to 1 (the
fifo within the dib0700 (dib7000p?) seems to be big enough).
In contrast to that, without the patch it is impossible to watch TV on one
nova-td channel while vdr is constantly calling streaming_ctrl on/off for
epg scan on the other nova-td channel. _Without_ the patch I see data
loss/corruption.


It would be nice to have other people trying this workaround on other
cards so that we know that it really helps and not just solves the
problem for you.

Patrick.


Of course it would be nice to have other people testing this patch. So far
the urb count is reduced for all dib0700 devices while the streaming_ctrl
callback is removed for the stk7700d family of devices (nova-td and friends)
only.
I used this patch in 2.6.27.x and 2.6.29.x environments so far. I will try
to test 2.6.30 this weekend.
If anybody else can confirm that this patch works (or not), please send a
short report to the list.

Thanks,
S:oren


--
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 v2] tuner-xc2028: Fix 7 MHz DVB-T

2009-06-11 Thread Andy Walls
All,

The following patch should fix 7 MHz DVB-T with the XC3028 using the
DTV7 firmware from the xc3028-v27.fw firmware image.

Comments?

Regards,
Andy Walls

Signed-off-by: Andy Walls awa...@radix.net
Tested-by: Terry Wu terrywu2...@gmail.com

diff -r fad35ab59848 linux/drivers/media/common/tuners/tuner-xc2028.c
--- a/linux/drivers/media/common/tuners/tuner-xc2028.c  Fri Jun 05 08:42:27 
2009 -0400
+++ b/linux/drivers/media/common/tuners/tuner-xc2028.c  Thu Jun 11 06:52:55 
2009 -0400
@@ -1099,8 +1099,19 @@
}
 
/* All S-code tables need a 200kHz shift */
-   if (priv-ctrl.demod)
+   if (priv-ctrl.demod) {
demod = priv-ctrl.demod + 200;
+   /*
+* The DTV7 S-code table needs a 700 kHz shift.
+* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
+*
+* DTV7 is only used in Australia.  Germany or Italy may also
+* use this firmware after initialization, but a tune to a UHF
+* channel should then cause DTV78 to be used.
+*/
+   if (type  DTV7)
+   demod += 500;
+   }
 
return generic_set_freq(fe, p-frequency,
T_DIGITAL_TV, type, 0, demod);


--
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] soc_camera: Fix debug output of supported formats count

2009-06-11 Thread Guennadi Liakhovetski
On Thu, 2 Apr 2009, Stefan Herbrechtsmeier wrote:

 The supported formats count must be set to 0 after debug output
 right before the second pass.
 

Hi Stefan, could you please resend with your Sob?

Thanks
Guennadi

 diff --git a/linux/drivers/media/video/soc_camera.c 
 b/linux/drivers/media/video/soc_camera.c
 --- a/linux/drivers/media/video/soc_camera.c
 +++ b/linux/drivers/media/video/soc_camera.c
 @@ -236,11 +236,11 @@ static int soc_camera_init_user_formats(
   return -ENOMEM;
  
   icd-num_user_formats = fmts;
 - fmts = 0;
  
   dev_dbg(icd-dev, Found %d supported formats.\n, fmts);
  
   /* Second pass - actually fill data formats */
 + fmts = 0;
   for (i = 0; i  icd-num_formats; i++)
   if (!ici-ops-get_formats) {
   icd-user_formats[i].host_fmt = icd-formats + i;
 

---
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 3/4] soc-camera: add support for camera-host controls

2009-06-11 Thread Dongsoo, Nathaniel Kim
Hello Guennadi,

It's a very interesting patch. Actually some camera interfaces support
for various image effects and I was wondering how to use them in SoC
camera subsystem.

But here is a question. Is it possible to make a choice with the same
CID between icd and ici? I mean, if both of camera interface and
camera device are supporting for same CID how can user select any of
them to use? Sometimes, some image effects supported by camera
interface are not good so I want to use the same effect supported by
external camera ISP device.

I think, it might be possible but I can't see how.
Cheers,

Nate

On Thu, Jun 11, 2009 at 4:12 PM, Guennadi
Liakhovetskig.liakhovet...@gmx.de wrote:
 Until now soc-camera only supported client (sensor) controls. This patch
 enables camera-host drivers to implement their own controls too.

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
  drivers/media/video/soc_camera.c |   24 
  include/media/soc_camera.h       |    4 
  2 files changed, 28 insertions(+), 0 deletions(-)

 diff --git a/drivers/media/video/soc_camera.c 
 b/drivers/media/video/soc_camera.c
 index 824c68b..8e987ca 100644
 --- a/drivers/media/video/soc_camera.c
 +++ b/drivers/media/video/soc_camera.c
 @@ -633,6 +633,7 @@ static int soc_camera_queryctrl(struct file *file, void 
 *priv,
  {
        struct soc_camera_file *icf = file-private_data;
        struct soc_camera_device *icd = icf-icd;
 +       struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
        int i;

        WARN_ON(priv != file-private_data);
 @@ -640,6 +641,15 @@ static int soc_camera_queryctrl(struct file *file, void 
 *priv,
        if (!qc-id)
                return -EINVAL;

 +       /* First check host controls */
 +       for (i = 0; i  ici-ops-num_controls; i++)
 +               if (qc-id == ici-ops-controls[i].id) {
 +                       memcpy(qc, (ici-ops-controls[i]),
 +                               sizeof(*qc));
 +                       return 0;
 +               }
 +
 +       /* Then device controls */
        for (i = 0; i  icd-ops-num_controls; i++)
                if (qc-id == icd-ops-controls[i].id) {
                        memcpy(qc, (icd-ops-controls[i]),
 @@ -656,6 +666,7 @@ static int soc_camera_g_ctrl(struct file *file, void 
 *priv,
        struct soc_camera_file *icf = file-private_data;
        struct soc_camera_device *icd = icf-icd;
        struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
 +       int ret;

        WARN_ON(priv != file-private_data);

 @@ -672,6 +683,12 @@ static int soc_camera_g_ctrl(struct file *file, void 
 *priv,
                return 0;
        }

 +       if (ici-ops-get_ctrl) {
 +               ret = ici-ops-get_ctrl(icd, ctrl);
 +               if (ret != -ENOIOCTLCMD)
 +                       return ret;
 +       }
 +
        return v4l2_device_call_until_err(ici-v4l2_dev, (__u32)icd, core, 
 g_ctrl, ctrl);
  }

 @@ -681,9 +698,16 @@ static int soc_camera_s_ctrl(struct file *file, void 
 *priv,
        struct soc_camera_file *icf = file-private_data;
        struct soc_camera_device *icd = icf-icd;
        struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
 +       int ret;

        WARN_ON(priv != file-private_data);

 +       if (ici-ops-set_ctrl) {
 +               ret = ici-ops-set_ctrl(icd, ctrl);
 +               if (ret != -ENOIOCTLCMD)
 +                       return ret;
 +       }
 +
        return v4l2_device_call_until_err(ici-v4l2_dev, (__u32)icd, core, 
 s_ctrl, ctrl);
  }

 diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
 index 3bc5b6b..2d116bb 100644
 --- a/include/media/soc_camera.h
 +++ b/include/media/soc_camera.h
 @@ -83,7 +83,11 @@ struct soc_camera_host_ops {
        int (*reqbufs)(struct soc_camera_file *, struct v4l2_requestbuffers *);
        int (*querycap)(struct soc_camera_host *, struct v4l2_capability *);
        int (*set_bus_param)(struct soc_camera_device *, __u32);
 +       int (*get_ctrl)(struct soc_camera_device *, struct v4l2_control *);
 +       int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
        unsigned int (*poll)(struct file *, poll_table *);
 +       const struct v4l2_queryctrl *controls;
 +       int num_controls;
  };

  #define SOCAM_SENSOR_INVERT_PCLK       (1  0)
 --
 1.6.2.4





-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.com
--
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] ov511.c: video_register_device() return zero on success

2009-06-11 Thread Mauro Carvalho Chehab
Em Thu, 11 Jun 2009 08:36:00 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:


 Since I made that change I'm willing to look at this. Some comments definitely
 need improving at the least.

Thanks! Since the behavior changed, it is important to better document it.

 Also ivtv and cx18 rely on the current behavior,
 so any changes need to be done carefully.
 
 But one question first: isn't the current approach not better anyway than the
 old approach? In the past device creation would fail if you specified an
 explicit device kernel number that was already in use. Now it will attempt
 to fulfill the request and skip to the next free number otherwise. Seems a
 pretty good approach to me.

Well, the idea of not failing due to that is interesting. Yet, those force
parameters are provided to avoid that a different modprobe order would change
the device nodes. By doing something different than requested by the users 
without
even warning them about that doesn't sound nice. At least a KERN_ERR log
should be printed if the selected nr is different than the requested one.

In the specific case of ov511, however, it caused a regression, since the used
logic to get the next value of the array were based on the failure of
video_register_device(). As it doesn't fail anymore, the current logic is 
broken.

 There haven't been any complaints about this (probably also because nobody is
 using it).
 
 Let me know what you want and I can implement it. It's not that hard.

IMO, what should be done:

1) better comment the function;
2) generate a KERN_ERR at v4l2-dev, if the requested nr is not available;
3) replace ov511 logic to restore the old behavior (or improve it a little bit);
4) double check if similar regressions are present on other drivers. Since
ov511 is an old driver, I don't doubt that its logic is duplicated on other
devices.

Since ov511 is used for an usb device, extra care should be taken, since it
should be considered the possibility of successive hot plug/unplug. I wrote an
interesting logic for this at em28xx driver, that can be used as an alternative
to the current logic



Cheers,
Mauro
--
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] ov511.c: video_register_device() return zero on success

2009-06-11 Thread Hans Verkuil

 Em Thu, 11 Jun 2009 08:36:00 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:


 Since I made that change I'm willing to look at this. Some comments
 definitely
 need improving at the least.

 Thanks! Since the behavior changed, it is important to better document it.

 Also ivtv and cx18 rely on the current behavior,
 so any changes need to be done carefully.

 But one question first: isn't the current approach not better anyway
 than the
 old approach? In the past device creation would fail if you specified an
 explicit device kernel number that was already in use. Now it will
 attempt
 to fulfill the request and skip to the next free number otherwise. Seems
 a
 pretty good approach to me.

 Well, the idea of not failing due to that is interesting. Yet, those force
 parameters are provided to avoid that a different modprobe order would
 change
 the device nodes. By doing something different than requested by the users
 without
 even warning them about that doesn't sound nice. At least a KERN_ERR log
 should be printed if the selected nr is different than the requested one.

KERN_WARNING would be better, I think. It is not an error after all.

 In the specific case of ov511, however, it caused a regression, since the
 used
 logic to get the next value of the array were based on the failure of
 video_register_device(). As it doesn't fail anymore, the current logic is
 broken.

 There haven't been any complaints about this (probably also because
 nobody is
 using it).

 Let me know what you want and I can implement it. It's not that hard.

 IMO, what should be done:

 1) better comment the function;
 2) generate a KERN_ERR at v4l2-dev, if the requested nr is not available;
 3) replace ov511 logic to restore the old behavior (or improve it a little
 bit);
 4) double check if similar regressions are present on other drivers. Since
 ov511 is an old driver, I don't doubt that its logic is duplicated on
 other
 devices.

I've just double checked all video_register_device calls and ov511.c is
the only one with this behavior.

Regards,

Hans


 Since ov511 is used for an usb device, extra care should be taken, since
 it
 should be considered the possibility of successive hot plug/unplug. I
 wrote an
 interesting logic for this at em28xx driver, that can be used as an
 alternative
 to the current logic



-- 
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: [PATCH 1/4] V4L2: add a new V4L2_CID_BAND_STOP_FILTER integer control

2009-06-11 Thread Guennadi Liakhovetski
On Thu, 11 Jun 2009, Laurent Pinchart wrote:

 Hi Guennadi,
 
 On Thursday 11 June 2009 09:12:37 Guennadi Liakhovetski wrote:
  Add a new V4L2_CID_BAND_STOP_FILTER integer control, which either switches
  the band-stop filter off, or sets it to a certain strength.
 
 I'm quoting your e-mail from 2009-05-27:
 
  COMJ[2] - Band filter enable. After adjust frame rate to match indoor
  light frequency, this bit enable a different exposure algorithm to cut
  light band induced by fluorescent light.
 
 As Nate pointed out, that seems to some kind of anti-flicker control and not 
 a 
 band stop filter.

Well, it _is_ a band-stop filter, at least this is how it is referred to 
in the docs. It might be serving as an anti-flicker control, don't know, 
if that's going to be the consensus, we can rename it, sure.

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


[PATCH 1/4] lgs8gxx: lgs8913 fake signal strength option default on

2009-06-11 Thread David Wong
lgs8gxx: lgs8913 fake signal strength option default on. Original
calculation is too slow.

Signed-off-by: David T.L. Wong davidtlwong at gmail.com
diff -r ed3781a79c73 -r b13db1935c48 linux/drivers/media/dvb/frontends/lgs8gxx.c
--- a/linux/drivers/media/dvb/frontends/lgs8gxx.c	Sat Jun 06 16:31:34 2009 +0400
+++ b/linux/drivers/media/dvb/frontends/lgs8gxx.c	Thu Jun 11 18:59:34 2009 +0800
@@ -37,14 +37,14 @@
 	} while (0)
 
 static int debug;
-static int fake_signal_str;
+static int fake_signal_str = 1;
 
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).);
 
 module_param(fake_signal_str, int, 0644);
 MODULE_PARM_DESC(fake_signal_str, fake signal strength for LGS8913.
-Signal strength calculation is slow.(default:off).);
+Signal strength calculation is slow.(default:on).);
 
 /* LGS8GXX internal helper functions */
 



[PATCH 3/4] lgs8gxx: add lgs8g75 support

2009-06-11 Thread David Wong
lgs8gxx: add lgs8g75 demodulator support

Signed-off-by: David T.L. Wong davidtlwong at gmail.com
diff -r af8ce23f588e -r a92510aad9e2 linux/drivers/media/dvb/frontends/lgs8gxx.c
--- a/linux/drivers/media/dvb/frontends/lgs8gxx.c	Thu Jun 11 19:05:08 2009 +0800
+++ b/linux/drivers/media/dvb/frontends/lgs8gxx.c	Thu Jun 11 19:07:15 2009 +0800
@@ -1,9 +1,9 @@
 /*
- *Support for Legend Silicon DMB-TH demodulator
- *LGS8913, LGS8GL5
+ *Support for Legend Silicon GB20600 (a.k.a DMB-TH) demodulator
+ *LGS8913, LGS8GL5, LGS8G75
  *experimental support LGS8G42, LGS8G52
  *
- *Copyright (C) 2007,2008 David T.L. Wong davidtlw...@gmail.com
+ *Copyright (C) 2007-2009 David T.L. Wong davidtlw...@gmail.com
  *Copyright (C) 2008 Sirius International (Hong Kong) Limited
  *Timothy Lee timothy@siriushk.com (for initial work on LGS8GL5)
  *
@@ -46,6 +46,42 @@
 MODULE_PARM_DESC(fake_signal_str, fake signal strength for LGS8913.
 Signal strength calculation is slow.(default:on).);
 
+static const u8 lgs8g75_initdat[] = {
+	0x01, 0x30, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+	0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+	0xE4, 0xF5, 0xA8, 0xF5, 0xB8, 0xF5, 0x88, 0xF5,
+	0x89, 0xF5, 0x87, 0x75, 0xD0, 0x00, 0x11, 0x50,
+	0x11, 0x50, 0xF4, 0xF5, 0x80, 0xF5, 0x90, 0xF5,
+	0xA0, 0xF5, 0xB0, 0x75, 0x81, 0x30, 0x80, 0x01,
+	0x32, 0x90, 0x80, 0x12, 0x74, 0xFF, 0xF0, 0x90,
+	0x80, 0x13, 0x74, 0x1F, 0xF0, 0x90, 0x80, 0x23,
+	0x74, 0x01, 0xF0, 0x90, 0x80, 0x22, 0xF0, 0x90,
+	0x00, 0x48, 0x74, 0x00, 0xF0, 0x90, 0x80, 0x4D,
+	0x74, 0x05, 0xF0, 0x90, 0x80, 0x09, 0xE0, 0x60,
+	0x21, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x1B, 0x12,
+	0x00, 0xDD, 0x14, 0x60, 0x15, 0x12, 0x00, 0xDD,
+	0x14, 0x60, 0x0F, 0x12, 0x00, 0xDD, 0x14, 0x60,
+	0x09, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x03, 0x12,
+	0x00, 0xDD, 0x90, 0x80, 0x42, 0xE0, 0x60, 0x0B,
+	0x14, 0x60, 0x0C, 0x14, 0x60, 0x0D, 0x14, 0x60,
+	0x0E, 0x01, 0xB3, 0x74, 0x04, 0x01, 0xB9, 0x74,
+	0x05, 0x01, 0xB9, 0x74, 0x07, 0x01, 0xB9, 0x74,
+	0x0A, 0xC0, 0xE0, 0x74, 0xC8, 0x12, 0x00, 0xE2,
+	0xD0, 0xE0, 0x14, 0x70, 0xF4, 0x90, 0x80, 0x09,
+	0xE0, 0x70, 0xAE, 0x12, 0x00, 0xF6, 0x12, 0x00,
+	0xFE, 0x90, 0x00, 0x48, 0xE0, 0x04, 0xF0, 0x90,
+	0x80, 0x4E, 0xF0, 0x01, 0x73, 0x90, 0x80, 0x08,
+	0xF0, 0x22, 0xF8, 0x7A, 0x0C, 0x79, 0xFD, 0x00,
+	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD9,
+	0xF6, 0xDA, 0xF2, 0xD8, 0xEE, 0x22, 0x90, 0x80,
+	0x65, 0xE0, 0x54, 0xFD, 0xF0, 0x22, 0x90, 0x80,
+	0x65, 0xE0, 0x44, 0xC2, 0xF0, 0x22
+};
+
 /* LGS8GXX internal helper functions */
 
 static int lgs8gxx_write_reg(struct lgs8gxx_state *priv, u8 reg, u8 data)
@@ -55,7 +91,7 @@
 	struct i2c_msg msg = { .flags = 0, .buf = buf, .len = 2 };
 
 	msg.addr = priv-config-demod_address;
-	if (reg = 0xC0)
+	if (priv-config-prod != LGS8GXX_PROD_LGS8G75  reg = 0xC0)
 		msg.addr += 0x02;
 
 	if (debug = 2)
@@ -84,7 +120,7 @@
 	};
 
 	dev_addr = priv-config-demod_address;
-	if (reg = 0xC0)
+	if (priv-config-prod != LGS8GXX_PROD_LGS8G75  reg = 0xC0)
 		dev_addr += 0x02;
 	msg[1].addr =  msg[0].addr = dev_addr;
 
@@ -112,19 +148,36 @@
 	return 0;
 }
 
+static int wait_reg_mask(struct lgs8gxx_state *priv, u8 reg, u8 mask,
+	u8 val, u8 delay, u8 tries)
+{
+	u8 t;
+	int i;
+
+	for (i = 0; i  tries; i++) {
+		lgs8gxx_read_reg(priv, reg, t);
+
+		if ((t  mask) == val)
+			return 0;
+		msleep(delay);
+	}
+
+	return 1;
+}
+
 static int lgs8gxx_set_ad_mode(struct lgs8gxx_state *priv)
 {
 	const struct lgs8gxx_config *config = priv-config;
 	u8 if_conf;
 
-	if_conf = 0x10; /* AGC output on; */
+	if_conf = 0x10; /* AGC output on, RF_AGC output off; */
 
 	if_conf |=
 		((config-ext_adc) ? 0x80 : 0x00) |
 		((config-if_neg_center) ? 0x04 : 0x00) |
 		((config-if_freq == 0) ? 0x08 : 0x00) | /* Baseband */
-		((config-ext_adc  config-adc_signed) ? 0x02 : 0x00) |
-		((config-ext_adc  config-if_neg_edge) ? 0x01 : 0x00);
+		((config-adc_signed) ? 0x02 : 0x00) |
+		((config-if_neg_edge) ? 0x01 : 0x00);
 
 	if (config-ext_adc 
 		(config-prod == LGS8GXX_PROD_LGS8G52)) {
@@ -157,39 +210,82 @@
 	}
 	dprintk(AFC_INIT_FREQ = 0x%08X\n, v32);
 
-	lgs8gxx_write_reg(priv, 0x09, 0xFF  (v32));
-	lgs8gxx_write_reg(priv, 0x0A, 0xFF  (v32  8));
-	lgs8gxx_write_reg(priv, 0x0B, 0xFF  (v32  16));
-	lgs8gxx_write_reg(priv, 0x0C, 0xFF  (v32  24));
+	if (priv-config-prod == LGS8GXX_PROD_LGS8G75) {
+		lgs8gxx_write_reg(priv, 0x08, 0xFF  (v32));
+		lgs8gxx_write_reg(priv, 0x09, 0xFF  (v32  8));
+		lgs8gxx_write_reg(priv, 0x0A, 0xFF  (v32  16));
+		lgs8gxx_write_reg(priv, 0x0B, 0xFF  (v32  24));
+	} else {
+		lgs8gxx_write_reg(priv, 0x09, 0xFF  (v32));
+		lgs8gxx_write_reg(priv, 0x0A, 0xFF  (v32  8));
+		lgs8gxx_write_reg(priv, 0x0B, 0xFF  (v32  16));
+		lgs8gxx_write_reg(priv, 0x0C, 0xFF  (v32  24));
+	}
 
 	return 0;
 }
 
+static int 

[PATCH 4/4] cx23885: add card Magic-Pro ProHDTV Extreme 2

2009-06-11 Thread David Wong
cx23885: add card Magic-Pro  ProHDTV Extreme 2 PCI-E.

Signed-off-by: David T.L. Wong davidtlwong at gmail.com
diff -r a92510aad9e2 -r 7195cfbca974 linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c	Thu Jun 11 19:07:15 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c	Thu Jun 11 20:04:04 2009 +0800
@@ -202,6 +202,10 @@
 		.name		= Mygica X8506 DMB-TH,
 		.portb		= CX23885_MPEG_DVB,
 	},
+	[CX23885_BOARD_MAGICPRO_PROHDTVE2] = {
+		.name		= Magic-Pro ProHDTV Extreme 2,
+		.portb		= CX23885_MPEG_DVB,
+	},
 };
 const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
 
@@ -325,6 +329,10 @@
 		.subvendor = 0x14f1,
 		.subdevice = 0x8651,
 		.card  = CX23885_BOARD_MYGICA_X8506,
+	}, {
+		.subvendor = 0x14f1,
+		.subdevice = 0x8657,
+		.card  = CX23885_BOARD_MAGICPRO_PROHDTVE2,
 	},
 };
 const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -716,8 +724,9 @@
 		cx23885_gpio_set(dev, GPIO_9);
 		break;
 	case CX23885_BOARD_MYGICA_X8506:
+	case CX23885_BOARD_MAGICPRO_PROHDTVE2:
 		/* GPIO-1 reset XC5000 */
-		/* GPIO-2 reset LGS8GL5 */
+		/* GPIO-2 reset LGS8GL5 / LGS8G75 */
 		cx_set(GP0_IO, 0x0006);
 		cx_clear(GP0_IO, 0x0006);
 		mdelay(100);
@@ -828,6 +837,7 @@
 		ts2-src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
 		break;
 	case CX23885_BOARD_MYGICA_X8506:
+	case CX23885_BOARD_MAGICPRO_PROHDTVE2:
 		ts1-gen_ctrl_val  = 0x5; /* Parallel */
 		ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
 		ts1-src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
diff -r a92510aad9e2 -r 7195cfbca974 linux/drivers/media/video/cx23885/cx23885-dvb.c
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c	Thu Jun 11 19:07:15 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c	Thu Jun 11 20:04:04 2009 +0800
@@ -441,6 +441,26 @@
 	.if_khz = 5380,
 };
 
+static struct lgs8gxx_config magicpro_prohdtve2_lgs8g75_config = {
+	.prod = LGS8GXX_PROD_LGS8G75,
+	.demod_address = 0x19,
+	.serial_ts = 0,
+	.ts_clk_pol = 1,
+	.ts_clk_gated = 1,
+	.if_clk_freq = 30400, /* 30.4 MHz */
+	.if_freq = 6500, /* 6.50 MHz */
+	.if_neg_center = 1,
+	.ext_adc = 0,
+	.adc_signed = 1,
+	.adc_vpp = 2, /* 1.6 Vpp */
+	.if_neg_edge = 1,
+};
+
+static struct xc5000_config magicpro_prohdtve2_xc5000_config = {
+	.i2c_address = 0x61,
+	.if_khz = 6500,
+};
+
 static int dvb_register(struct cx23885_tsport *port)
 {
 	struct cx23885_dev *dev = port-dev;
@@ -779,6 +799,19 @@
 mygica_x8506_xc5000_config);
 		}
 		break;
+	case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+		i2c_bus = dev-i2c_bus[0];
+		i2c_bus2 = dev-i2c_bus[1];
+		fe0-dvb.frontend = dvb_attach(lgs8gxx_attach,
+			magicpro_prohdtve2_lgs8g75_config,
+			i2c_bus-i2c_adap);
+		if (fe0-dvb.frontend != NULL) {
+			dvb_attach(xc5000_attach,
+fe0-dvb.frontend,
+i2c_bus2-i2c_adap,
+magicpro_prohdtve2_xc5000_config);
+		}
+		break;
 	default:
 		printk(KERN_INFO %s: The frontend of your DVB/ATSC card 
 			 isn't supported yet\n,
diff -r a92510aad9e2 -r 7195cfbca974 linux/drivers/media/video/cx23885/cx23885.h
--- a/linux/drivers/media/video/cx23885/cx23885.h	Thu Jun 11 19:07:15 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885.h	Thu Jun 11 20:04:04 2009 +0800
@@ -77,6 +77,7 @@
 #define CX23885_BOARD_HAUPPAUGE_HVR125520
 #define CX23885_BOARD_HAUPPAUGE_HVR121021
 #define CX23885_BOARD_MYGICA_X8506 22
+#define CX23885_BOARD_MAGICPRO_PROHDTVE2   23
 
 #define GPIO_0 0x0001
 #define GPIO_1 0x0002


RE: [PATCH] adding support for setting bus parameters in sub device

2009-06-11 Thread Karicheri, Muralidharan


 Why force all platforms to set it if the driver is perfectly capable do
 this itself? As I said - this is not a platform-specific feature, it's
 chip-specific. What good would it make to have all platforms using
 mt9t031 to specify, that yes, the chip can use both falling and rising
 pclk edge, but only active high vsync and hsync?

???

You will just tell the chip what to use. So you set 'use falling edge' and
either set 'active high vsync/hsync' or just leave that out since you know
the mt9t031 has that fixed. You don't specify in the platform data what the
chip can support, that's not relevant. You know what the host expects and
you pass that information on to the chip.

A board designer knows what the host supports, knows what the sensor
supports, and knows if he added any inverters on the board, and based on
all that information he can just setup these parameters for the sensor
chip. Settings that are fixed on the sensor chip he can just ignore, he
only need to specify those settings that the sensor really needs.

[MK] I agree with Hans. Looking my experience with various platforms, this is 
true. We have following decoders connected to the VPFE bus working in our 
internal release kernel. In all these cases, the bus parameters are fixed given 
a board and the platform. Given below are the list of boards, and decoders 
connected and bus available

DM6446 -Bayer RGB bus(10 bit connected to MSB), Vsync, Hsync, PCLK
  (MT9T001)
 -YUV bus (embedded sync / separate sync), PCLK, Vsync, HSync, Field
  (TVP5146) - 8/10 bit data bus
DM355 - Same as above 
- VPFE Also supports YUV bus with 16 bit bus (8 bit, Y and 8 bit 
  Cb/Cr), but no decoders tested with this interface.
DM365 - Bayer RGB bus Same as above
- YUV bus - similar to that in DM355
- TVP7002 - connected through 16 bit YUV bus with embedded sync 
  (BT.1120)

  BTW, looking at the code there doesn't seem to be a bus type (probably
  only Bayer is used), correct? How is the datawidth negotiation done? Is
  the largest available width chosen? I assume that the datawidth is
  generally fixed by the host? I don't quite see how that can be
  negotiated since what is chosen there is linked to how the video data
  is transferred to memory. E.g., chosing a bus width of 8 or 10 bits can
  be the difference between transferring 8 bit or 16 bit data (with 6
  bits padding) when the image is transferred to memory. If I would
  implement negotiation I would probably limit it to those one-bit
  settings and not include bus type and width.

 Well, this is indeed hairy. And hardware developers compete in creativity
 making us invent new and new algorithms:-( I think, so far _practically_
 I have only worked with the following setups:

 8 bit parallel with syncs and clocks. Data can be either Bayer or YUV.
 This is most usual in my practice so far.

 10 bit parallel (PXA270) with syncs and clocks bus with an 8 bit sensor
 connected to most significant lanes... This is achieved by providing an
 additional I2C controlled switch...

 10 bit parallel with a 10 bit sensor, data 0-extended to 16 bit, raw
 Bayer.

 15 bit parallel bus (i.MX31) with 8 bit sensor connected to least
 significant lanes, because i.MX31 is smart enough to use them correctly.

 ATM this is a part of soc-camera pixel format negotiation code, you can
 look at various .set_bus_param() methods in sensor drivers. E.g., look in
 mt9m001 and mt9v022 for drivers, using external bus-width switches...

 Now, I do not know how standard these various data packing methods on the
 bus are, I think, we will have to give it a good thought when designing
 an API, comments from developers familiar with various setups are much
 appreciated.

I think we should not attempt to be too fancy with this part of the API.
Something like the pixel format API in the v4l2 spec which is basically
just a random number with an associated format specification and no attempt
and trying high-level format descriptions. In this case a simple enum might
be enough. I'm not even sure whether we should specify the bus width but
instead have it implicit in the bus type.

[MK] VPFE at least need to know if YUV bus has sync embedded or separate sync 
lines as well if it 10 bit or 8 bit. Similarly it needs 16 bit for interfacing 
with TVP7002.  For Raw Bayer, it needs to know the size of valid data on the 
bus and where the MSB of the sensor is connected (this can be specified in the 
platform data of the bridge driver, and is not applicable for sensor device). 
So data width information could either be explicit in the bus type or could be 
specified in width parameter. Both works for our driver.

What about embedded sync bool I have added in the latest patch? This can be 
removed too if it is explicit in the bus type. But my preference is to keep 
them as per my latest patch. I am also not sure if query capability will be 
really useful versus defining them per 

Re: pull requests x patches at linux-media ML - Was: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2

2009-06-11 Thread Mauro Carvalho Chehab
Em Thu, 11 Jun 2009 08:23:37 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:

 Hi Mauro, thanks for replying and for the explanation. I'll skip most of 
 your message, and just keep the bits I'd like to reply to.
 
 On Wed, 10 Jun 2009, Mauro Carvalho Chehab wrote:
 
  The same happens here: All patches added at the staging tree are sent to
  linuxtv-commits ML. So, they are there for discussions before my pull 
  requests.
  
  The main difference is that, in the case of Greg, his staging tree is a 
  quilt
  one. On our case, our staging tree is mercurial.
 
 Hm, I am not sure, is Greg's quilt tree publically available? And how many 
 actually use it? Whereas your hg tree is publically available and it looks 
 like a few do use it.

Well, he used to make it publicly available.

  We're currently merging about 900 patches per kernel window, on a window of
  about 10-12 weeks. This means about 90 patches per week, or about 13 patches
  per day (for a 7 days week), or 18 patches per day (for a 5 days week).
  
  So, if people just send one email per patch, this will increase our traffic 
  by
  18 emails by day. It can be worse than that, if we consider that patches 
  can be
  replied, and that people use to write a patch 0 to describe a patch series.
  
  Considering about 50 messages per day, currently (today and yesterday's
  statistics - not sure those are typical days), this would increase the ML by
  about 36%. 
 
 I still don't take this argument of increased traffic - I haven't seen a 
 single complain please, don't increase the traffic, it'll make it worse 
 for me.

That's just what Hermann said.

  1) trivial patches (typo fixes, coding style, simple board additions, Kbuild
  fixes, etc);
  
  2) bug fix patches at drivers;
  
  3) new drivers;
  
  4) core changes.
  
  However, several driver maintainers don't care (or just forget about they) 
  for (1)
  type. Before patchwork, lots of such patches were lost forever in the 
  middle of
  dvb and v4l mailing lists. They are happy when someone (me) get those 
  patches
  and apply at the tree or remind they to check and apply on their trees.
  
  patches of type (2) and (3) are in general sent via a driver maintainer and
  generally doesn't generate discussions.
 
 I'm really happy we have subsistem maintainers that are such profecient in 
 their work and such confident in their results that they don't need any 
 reviews and discussions. I for one is not one of them, that's why I always 
 first send my patches to the list.
 
  Also, for the developer, using the pull request is better, since they can
  better track when a patch series got merged.
 
 I never argumented against pull requests, I'm suggesting they should 
 follow patches posted to the list.
 
  The usage of a mix of PULL and PATCH requests has an extra trouble: it means
  that we'll receive most of the patches duplicated. So, it means that I need 
  to
  manually mark all merged patches at patchwork queue, on _each_ pull request.
 
 Yes, I see what you mean, but 1) you cannot avoid it, there are always 
 patches from various authors, that they send to the ML, that some 
 driver-maintainer will then pull through his or her tree and ask you to 
 pull it. So, we really have to learn to proces this case efficiently.

The current process were built along the time and, up to now, it is the better
we have. For sure it can be improved, but we need to take care to not transform
it into some bureaucratic set of procedures that reduces our development speed
and doesn't aggregate any value.

  So, this adds an extra cost that will probably make life worse for 
  everybody,
  with almost no gain (since there are really very few complaints about badly
  merged patches).
  
  That's said, I'm open to listen to opinions on how to improve our current 
  process
 
 Well, I guess, I will have to subscribe to that hg-commit list (or 
 whatever it's called), and use it. The problem is - it is a bit too late. 
 But it's the best option available so far.

It is not that late, and you can always reply over the PULL requests, when you 
find an issue there.

 Another question, if you pull patches from someone's tree for review of 
 one of those pull-requests (as you described in this mail, but I've 
 deleted that piece already), how do you then quote the code if you want to 
 comment on it? You export the patch again, hit reply on the pull-request, 
 and paste the patch into it? And then add the quotation marks   
 manually?...

Well, I generally do:

./hgimport tree

then I check each patch at /tmp/newpatches with less (or with kdiff3, if the 
patch is very complex).

If I need to comment about a patch, I simply do:

cat /tmp/newpatches/hg_v4l-dvb_1.patch|perl -ne 'print  $_'|xclip

and then I paste it at the email with a CTRL-V.

The result is something like this:

 
 # HG changeset patch
 # User Andy Walls awa...@radix.net
 # Date 1243037266 14400
 # Node ID 

RE: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Karicheri, Muralidharan
Hi,

In our experience, I have following cases where we need to set the device to 
capture/display at certain resolution and fps.

Capture side
-
1) IP Netcam applications. If the solution uses Micron sensors such as 
MT9T001/031/P031 etc, application will require to do streaming at various 
resolution ranging from VGA, SVGA to UXGA or 480p, 576p to 1080p. In these case 
what we have implemented is a table of timings looked up by the STD string. 
Though this is not a standard, it helps in achieving streaming at desired frame 
rate. The exposure used is to get the desired frame rate and video quality. The 
VPFE has modules to fine tune the image quality.

2) TVP7002 decoder chip has following table for various analog video standard 
that it supports.
SDTV(YPbPr component) - 480i/576i
EDTV (YPbPr component) - 480p/576p
HDTV (YPbPr component) - 7...@50/60, 10...@50/60, 10...@50/60
PC graphics (RGB Component) - VGA to UXGA

3) TVP5146/TVP5147 - supports NTSC/PAL standards from SDTV

4) camera applications that do preview and take snapshots. We don't support it 
in Linux, but have solutions based on other OS.

Display side

1)VPBE (video processing back end) can support NTSC/PAL timing signals directly 
from the SOC.

2) By connecting a daughter card that does voltage translation, to the digital 
LCD port of VPBE, it can support PC graphics timings. Examples are logic PD 
LCD/ Avnet LCD kits that can be connected using these daughter card.

3) The Digital LCD port of VPBE can generate BT.656/BT.1120 timings. So you 
could connect a encoder chip such as THS8200 to generate 720P/1080 YPbPr 
component outputs. This can support any encoder chip that can accepts YUV data 
or RGB666 or RGB888 data along with timings signals and output PC graphic or 
YPbPr component output or standard NTSC/PAL outputs.

As you can see, S_STD can be used only for 3) on the capture side and 1) on the 
display side since it doesn't specify all the above timings and is not quite 
useful. So we need an API that can do the following...

Query available timings settings from the encoder/decoder/sensors. Since these 
timings are not relevant to application domain, it can be defined in either in 
the driver and only expose following as part of the query. Driver uses this to 
look up the correct timing. 

1) resolution (VGA, 720p, 1080p, 576p etc)
2) frame rate 

Set the timing by specifying
Detect the signal for capture similar to QUERYSTD??
Get the current timing...

Is VIDIOC_S_PARM  G_PARM added for this purpose. May be this might need to be 
enhanced for this purpose to add the resolution as well or add a new set of 
APIs...


Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
email: m-kariche...@ti.com

-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Thursday, June 11, 2009 6:40 AM
To: Hans de Goede
Cc: Jean-Philippe François; Karicheri, Muralidharan; davinci-linux-open-
sou...@linux.davincidsp.com; Muralidharan Karicheri; Guennadi Liakhovetski;
linux-media@vger.kernel.org
Subject: Re: mt9t031 (was RE: [PATCH] adding support for setting bus
parameters in sub device)




 On 06/11/2009 11:33 AM, Hans Verkuil wrote:

 On 06/11/2009 10:35 AM, Hans Verkuil wrote:

 snip (a lot)

 Hmm,

 Why would we want the *application* to set things like this *at all* ?
 with sensors hsync and vsync and other timing are something between
 the bridge and the sensor, actaully in my experience the correct
 hsync / vsync timings to program the sensor to are very much bridge
 specific. So IMHO this should not be exposed to userspace at all.

 All userspace should be able to control is the resolution and the
 framerate. Although controlling the framerate in many cases also
 means controlling the maximum exposure time. So in many cases
 one cannot even control the framerate. (Asking for 30 fps in an
 artificially illuminated room will get you a very dark, useless
 picture, with most sensors). Yes this means that with cams with
 use autoexposure (which is something which we really want where ever
 possible), the framerate can and will change while streaming.

 I think we have three possible use cases here:

 - old-style standard definition video: use S_STD


 Ack

 - webcam-like devices: a combination of S_FMT and S_PARM I think?
 Correct
 me if I'm wrong. S_STD is useless for this, right?


 Ack

 - video streaming devices like the davinci videoports where you can hook
 up HDTV receivers or FPGAs: here you definitely need a new API to setup
 the streaming parameters, and you want to be able to do that from the
 application as well. Actually, sensors are also hooked up to these
 devices
 in practice. And there you also want to be able to setup these
 parameters.
 You will see this mostly (only?) on embedded platforms.


 I agree we need an in kernel API for this, but why expose it to
 userspace, as 

RE: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Karicheri, Muralidharan


 - video streaming devices like the davinci videoports where you can hook
 up HDTV receivers or FPGAs: here you definitely need a new API to setup
 the streaming parameters, and you want to be able to do that from the
 application as well. Actually, sensors are also hooked up to these
devices
 in practice. And there you also want to be able to setup these parameters.
 You will see this mostly (only?) on embedded platforms.


I agree we need an in kernel API for this, but why expose it to
userspace, as you say this will only happen on embedded systems,
shouldn't the info then go in a board_info file / struct ?

No we still need a way for application to set these timings at the device. For 
example, it needs to tell a TVP7002 device to scan at 720p/1080p similar to 
S_STD. From user prespective, it is just like S_STD. See my email on the 
details...

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: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Karicheri, Muralidharan
On Wed, 10 Jun 2009, Karicheri, Muralidharan wrote:

 So how do I know what frame-rate I get? Sensor output frame rate depends
 on the resolution of the frame, blanking, exposure time etc.

This is not supported.

I am still not clear. You had said in an earlier email that it can support 
streaming. That means application can stream frames from the capture device.
I know you don't have support for setting a specific frame rate, but it must be 
outputting frame at some rate right?

Here is my usecase.

open capture device,
set resolutions (say VGA) for capture (S_FMT ???)
request buffer for streaming  mmap  QUERYBUF
start streaming (STREAMON)
DQBUF/QBUF in a loop - get VGA buffers at some fps.
STREAMOFF
close device

Is this possible with mt9t031 available currently in the tree? This requires 
sensor device output frames continuously on the bus using PCLK/HSYNC/VSYNC 
timing to the bridge device connected to the bus. Can you give a use case like 
above that you are using. I just want to estimate how much effort is required 
to add this support in the mt9t031 driver.

Thanks

Murali

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: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Guennadi Liakhovetski
On Thu, 11 Jun 2009, Karicheri, Muralidharan wrote:

 On Wed, 10 Jun 2009, Karicheri, Muralidharan wrote:
 
  So how do I know what frame-rate I get? Sensor output frame rate depends
  on the resolution of the frame, blanking, exposure time etc.
 
 This is not supported.
 
 I am still not clear. You had said in an earlier email that it can 
 support streaming. That means application can stream frames from the 
 capture device.
 I know you don't have support for setting a specific frame rate, but it 
 must be outputting frame at some rate right?

I am sorry, I do not know how I can explain myself clearer.

Yes, you can stream video with mt9t031.

No, you neither get the framerate measured by the driver nor can you set a 
specific framerate. Frames are produced as fast as it goes, depending on 
clock settings, frame size, black areas, autoexposure.

Thanks
Guennadi

 
 Here is my usecase.
 
 open capture device,
 set resolutions (say VGA) for capture (S_FMT ???)
 request buffer for streaming  mmap  QUERYBUF
 start streaming (STREAMON)
 DQBUF/QBUF in a loop - get VGA buffers at some fps.
 STREAMOFF
 close device
 
 Is this possible with mt9t031 available currently in the tree? This requires 
 sensor device output frames continuously on the bus using PCLK/HSYNC/VSYNC 
 timing to the bridge device connected to the bus. Can you give a use case 
 like above that you are using. I just want to estimate how much effort is 
 required to add this support in the mt9t031 driver.
 
 Thanks
 
 Murali
 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
 

---
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: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

2009-06-11 Thread Karicheri, Muralidharan

I am sorry, I do not know how I can explain myself clearer.

Thanks for helping me to understand better :)
Yes, you can stream video with mt9t031.

No, you neither get the framerate measured by the driver nor can you set a
specific framerate. Frames are produced as fast as it goes, depending on
clock settings, frame size, black areas, autoexposure.

Ok. It is now clear to me. 

Thanks for all your help.

Thanks
Guennadi


 Here is my usecase.

 open capture device,
 set resolutions (say VGA) for capture (S_FMT ???)
 request buffer for streaming  mmap  QUERYBUF
 start streaming (STREAMON)
 DQBUF/QBUF in a loop - get VGA buffers at some fps.
 STREAMOFF
 close device

 Is this possible with mt9t031 available currently in the tree? This
requires sensor device output frames continuously on the bus using
PCLK/HSYNC/VSYNC timing to the bridge device connected to the bus. Can you
give a use case like above that you are using. I just want to estimate how
much effort is required to add this support in the mt9t031 driver.

 Thanks

 Murali

 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/


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


[PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture driver

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

common types used across CCDC modules

No change from last version

Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository

 include/media/davinci/ccdc_types.h |   43 
 1 files changed, 43 insertions(+), 0 deletions(-)
 create mode 100644 include/media/davinci/ccdc_types.h

diff --git a/include/media/davinci/ccdc_types.h 
b/include/media/davinci/ccdc_types.h
new file mode 100644
index 000..5773874
--- /dev/null
+++ b/include/media/davinci/ccdc_types.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ *
+ **/
+#ifndef _CCDC_TYPES_H
+#define _CCDC_TYPES_H
+enum ccdc_pixfmt {
+   CCDC_PIXFMT_RAW,
+   CCDC_PIXFMT_YCBCR_16BIT,
+   CCDC_PIXFMT_YCBCR_8BIT
+};
+
+enum ccdc_frmfmt {
+   CCDC_FRMFMT_PROGRESSIVE,
+   CCDC_FRMFMT_INTERLACED
+};
+
+/* PIXEL ORDER IN MEMORY from LSB to MSB */
+/* only applicable for 8-bit input mode  */
+enum ccdc_pixorder {
+   CCDC_PIXORDER_YCBYCR,
+   CCDC_PIXORDER_CBYCRY,
+};
+
+enum ccdc_buftype {
+   CCDC_BUFTYPE_FLD_INTERLEAVED,
+   CCDC_BUFTYPE_FLD_SEPARATED
+};
+#endif
-- 
1.6.0.4

--
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 6/10 - v2] Makefile and config files for vpfe capture driver

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

Makefile and config files for the driver

This adds Makefile and Kconfig changes to build vpfe capture driver.

Added configuration variable for vpss driver based on last review

Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository

 drivers/media/video/Kconfig  |   49 ++
 drivers/media/video/Makefile |1 +
 drivers/media/video/davinci/Makefile |9 ++
 3 files changed, 59 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/Makefile

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9d48da2..ee6806c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -479,6 +479,55 @@ config VIDEO_VIVI
  Say Y here if you want to test video apps or debug V4L devices.
  In doubt, say N.
 
+config VIDEO_VPSS_SYSTEM
+   tristate VPSS System module driver
+   depends on ARCH_DAVINCI
+   help
+ Support for vpss system module for video driver
+   default y
+
+config VIDEO_VPFE_CAPTURE
+   tristate VPFE Video Capture Driver
+   depends on VIDEO_V4L2  ARCH_DAVINCI
+   select VIDEOBUF_DMA_CONTIG
+   help
+ Support for DM VPFE based frame grabber. This is the
+ common V4L2 module for following DMXXX SoCs from Texas
+ Instruments:- DM6446  DM355.
+
+ To compile this driver as a module, choose M here: the
+ module will be called vpfe-capture.
+
+config VIDEO_DM6446_CCDC
+   tristate DM6446 CCDC HW module
+   depends on ARCH_DAVINCI_DM644x  VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces
+  with decoder modules such as TVP5146 over BT656 or
+  sensor module such as MT9T001 over a raw interface. This
+  module configures the interface and CCDC/ISIF to do
+  video frame capture from slave decoders.
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
+
+config VIDEO_DM355_CCDC
+   tristate DM355 CCDC HW module
+   depends on ARCH_DAVINCI_DM355  VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables DM355 CCD hw module. DM355 CCDC hw interfaces
+  with decoder modules such as TVP5146 over BT656 or
+  sensor module such as MT9T001 over a raw interface. This
+  module configures the interface and CCDC/ISIF to do
+  video frame capture from a slave decoders
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
+
 source drivers/media/video/bt8xx/Kconfig
 
 config VIDEO_PMS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 3f1a035..bc8ac8e 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -147,6 +147,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9V022)+= mt9v022.o
 obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
 obj-$(CONFIG_SOC_CAMERA_PLATFORM)  += soc_camera_platform.o
 obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
+obj-$(CONFIG_ARCH_DAVINCI)+= davinci/
 
 obj-$(CONFIG_VIDEO_AU0828) += au0828/
 
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
new file mode 100644
index 000..b84a405
--- /dev/null
+++ b/drivers/media/video/davinci/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the davinci video device drivers.
+#
+
+# Capture: DM6446 and DM355
+obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o
+obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
+obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
+obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
-- 
1.6.0.4

--
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 8/10 - v2] DM6446 platform changes for vpfe capture driver

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

DM644x platform and board setup

This adds plarform and board setup changes required to support
vpfe capture driver on DM644x

Added registration of vpss platform driver based on last comment

Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree

 arch/arm/mach-davinci/board-dm644x-evm.c|   68 ++-
 arch/arm/mach-davinci/dm644x.c  |   56 ++
 arch/arm/mach-davinci/include/mach/dm644x.h |2 +
 3 files changed, 124 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d9d4045..13b73a7 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,7 +28,8 @@
 #include linux/io.h
 #include linux/phy.h
 #include linux/clk.h
-
+#include linux/videodev2.h
+#include media/tvp514x.h
 #include asm/setup.h
 #include asm/mach-types.h
 
@@ -195,6 +196,57 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
 };
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = COMPOSITE,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = SVIDEO,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+   {
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+   {
+   .name = tvp5146,
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   },
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = DM6446 EVM,
+   .ccdc = DM6446 CCDC,
+};
+
 static struct platform_device rtc_dev = {
.name   = rtc_davinci_evm,
.id = -1,
@@ -447,6 +499,13 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
 };
 
+#define TVP5146_I2C_ADDR   (0x5D)
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
+
 /*
  * MSP430 supports RTC, card detection, input from IR remote, and
  * a bit more.  It triggers interrupts on GPIO(7) from pressing
@@ -558,9 +617,12 @@ static struct i2c_board_info __initdata i2c_info[] =  {
I2C_BOARD_INFO(24c256, 0x50),
.platform_data  = eeprom_info,
},
+   {
+   I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),
+   .platform_data = tvp5146_pdata,
+   },
/* ALSO:
 * - tvl320aic33 audio codec (0x1b)
-* - tvp5146 video decoder (0x5d)
 */
 };
 
@@ -591,6 +653,8 @@ static struct davinci_uart_config uart_config __initdata = {
 static void __init
 davinci_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm644x_set_vpfe_config(vpfe_cfg);
dm644x_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 1b3aec8..444c4df 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -549,6 +549,59 @@ static struct platform_device dm644x_edma_device = {
.resource   = edma_resources,
 };
 
+static struct resource dm644x_vpss_resources[] = {
+   {
+   /* VPSS Base address */
+   .name   = vpss,
+   .start  = 0x01c73400,
+   .end= 0x01c73400 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm644x_vpss_device = {
+   .name   = vpss,
+   .id = -1,
+   .dev.platform_data  = dm644x_vpss,
+   .num_resources  = ARRAY_SIZE(dm644x_vpss_resources),
+   .resource   = dm644x_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+   {
+   .start  = IRQ_VDINT0,
+   .end= IRQ_VDINT0,
+ 

[PATCH 7/10 - v2] DM355 platform changes for vpfe capture driver

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

DM355 platform and board setup

This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.

Added registration of vpss platform driver based on last review

Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree

 arch/arm/mach-davinci/board-dm355-evm.c|   72 +++-
 arch/arm/mach-davinci/dm355.c  |   83 
 arch/arm/mach-davinci/include/mach/dm355.h |2 +
 arch/arm/mach-davinci/include/mach/mux.h   |9 +++
 4 files changed, 163 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index 5ac2f56..cf87e21 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -20,6 +20,8 @@
 #include linux/io.h
 #include linux/gpio.h
 #include linux/clk.h
+#include linux/videodev2.h
+#include media/tvp514x.h
 #include linux/spi/spi.h
 #include linux/spi/eeprom.h
 
@@ -134,12 +136,23 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
 }
 
+#define TVP5146_I2C_ADDR   0x5D
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
+
 static struct i2c_board_info dm355evm_i2c_info[] = {
-   { I2C_BOARD_INFO(dm355evm_msp, 0x25),
+   {   I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
-   /* plus irq */ },
+   },
+   {
+   I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),
+   .platform_data = tvp5146_pdata,
+   },
+   /* { plus irq  }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
-   /* { I2C_BOARD_INFO(tvp5146, 0x5d), }, */
 };
 
 static void __init evm_init_i2c(void)
@@ -178,6 +191,57 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources  = ARRAY_SIZE(dm355evm_dm9000_rsrc),
 };
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = COMPOSITE,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = SVIDEO,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+   {
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+   {
+   .name = tvp5146,
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   }
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = DM355 EVM,
+   .ccdc = DM355 CCDC,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
dm355evm_dm9000,
davinci_nand_device,
@@ -189,6 +253,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm355_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm355_set_vpfe_config(vpfe_cfg);
dm355_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9baeed3..3263af8 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -481,6 +481,14 @@ INT_CFG(DM355,  INT_EDMA_TC1_ERR, 4,1,1, 
false)
 EVT_CFG(DM355,  EVT8_ASP1_TX,0,1,0, false)
 EVT_CFG(DM355,  EVT9_ASP1_RX,1,1,0, false)
 EVT_CFG(DM355,  EVT26_MMC0_RX,   2,1,0, false)
+
+MUX_CFG(DM355, VIN_PCLK,   0,   14,1,1, false)
+MUX_CFG(DM355, VIN_CAM_WEN,0,   13,1,1, false)
+MUX_CFG(DM355, VIN_CAM_VD, 0,   12,1,1, false)
+MUX_CFG(DM355, VIN_CAM_HD, 0,   11,1,1, false)
+MUX_CFG(DM355, VIN_YIN_EN, 0,   10,1,1, false)
+MUX_CFG(DM355, VIN_CINL_EN,0,   0,   0xff, 0x55,false)
+MUX_CFG(DM355, VIN_CINH_EN,0,   8, 3,3, false)
 #endif
 };
 
@@ -623,6 +631,67 @@ static struct platform_device dm355_edma_device = {
.resource   = 

[PATCH 10/10 - v2] common vpss module for video drivers

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

common voss module for video drivers

This is a new module added for vpss library functions that are
used for configuring vpss system module. All video drivers will
include vpss.h header file and call functions defined in this
module to configure vpss system module.


Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/davinci/vpss.c |  290 
 include/media/davinci/vpss.h   |   69 +
 2 files changed, 359 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpss.c
 create mode 100644 include/media/davinci/vpss.h

diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
new file mode 100644
index 000..def021e
--- /dev/null
+++ b/drivers/media/video/davinci/vpss.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * common vpss driver for all video drivers.
+ */
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/compiler.h
+#include linux/io.h
+#include mach/hardware.h
+#include media/davinci/vpss.h
+
+/* DM644x defines */
+#define DM644X_SBL_PCR_VPSS(4)
+
+/* vpss BL register offsets */
+#define DM355_VPSSBL_CCDCMUX   0x1c
+/* vpss CLK register offsets */
+#define DM355_VPSSCLK_CLKCTRL  0x04
+/* masks and shifts */
+#define VPSS_HSSISEL_SHIFT 4
+
+/*
+ * vpss operations. Depends on platform. Not all functions are available
+ * on all platforms. The api, first check if a functio is available before
+ * invoking it. In the probe, the function ptrs are intialized based on
+ * vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
+ */
+struct vpss_hw_ops {
+   /* enable clock */
+   int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
+   /* select input to ccdc */
+   void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
+   /* clear wbl overlflow bit */
+   int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+};
+
+/* vpss configuration */
+struct vpss_oper_config {
+   __iomem void *vpss_bl_regs_base;
+   __iomem void *vpss_regs_base;
+   struct resource *r1;
+   resource_size_t len1;
+   struct resource *r2;
+   resource_size_t len2;
+   char vpss_name[32];
+   spinlock_t vpss_lock;
+   struct vpss_hw_ops hw_ops;
+};
+
+static struct vpss_oper_config oper_cfg;
+
+/* register access routines */
+static inline u32 bl_regr(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline void bl_regw(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline u32 vpss_regr(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_regs_base + offset);
+}
+
+static inline void vpss_regw(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+}
+
+static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   bl_regw(src_sel  VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
+}
+
+int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   if (!oper_cfg.hw_ops.select_ccdc_source)
+   return -1;
+
+   dm355_select_ccdc_source(src_sel);
+   return 0;
+}
+EXPORT_SYMBOL(vpss_select_ccdc_source);
+
+static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+   u32 mask = 1, val;
+
+   if (wbl_sel  VPSS_PCR_AEW_WBL_0 ||
+   wbl_sel  VPSS_PCR_CCDC_WBL_O)
+   return -1;
+
+   /* writing a 0 clear the overflow */
+   mask = ~(mask  wbl_sel);
+   val = bl_regr(DM644X_SBL_PCR_VPSS)  mask;
+   bl_regw(val, DM644X_SBL_PCR_VPSS);
+   return 0;
+}
+
+int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+   if (!oper_cfg.hw_ops.clear_wbl_overflow)
+   return -1;
+
+   return oper_cfg.hw_ops.clear_wbl_overflow(wbl_sel);
+}
+EXPORT_SYMBOL(vpss_clear_wbl_overflow);
+
+/*
+ *  dm355_enable_clock - Enable VPSS Clock
+ *  @clock_sel: CLock to be 

[PATCH 9/10 - v2] remove outdated video driver files of dm6446

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

Remove outdated driver files from davinci git tree

No change from last patch

Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree

 drivers/media/video/ccdc_davinci.c |  124 
 drivers/media/video/davinci_vpfe.c | 1136 
 include/media/ccdc_davinci.h   |  144 -
 include/media/davinci_vpfe.h   |  121 
 4 files changed, 0 insertions(+), 1525 deletions(-)
 delete mode 100644 drivers/media/video/ccdc_davinci.c
 delete mode 100644 drivers/media/video/davinci_vpfe.c
 delete mode 100644 include/media/ccdc_davinci.h
 delete mode 100644 include/media/davinci_vpfe.h

diff --git a/drivers/media/video/ccdc_davinci.c 
b/drivers/media/video/ccdc_davinci.c
deleted file mode 100644
index d3cd333..000
--- a/drivers/media/video/ccdc_davinci.c
+++ /dev/null
@@ -1,124 +0,0 @@
-/*
- *
- *
- * Copyright (C) 2006 Texas Instruments Inc
- *
- * 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; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-/* ccdc_davinci.c */
-
-#include media/ccdc_davinci.h
-#define debug_print(x...)  //printk(x)
-void ccdc_reset()
-{
-   int i;
-   /* disable CCDC */
-   ccdc_enable(0);
-   /* set all registers to default value */
-   for (i = 0; i = 0x94; i += 4) {
-   regw(0, i);
-   }
-   regw(0, PCR);
-   regw(0, SYN_MODE);
-   regw(0, HD_VD_WID);
-   regw(0, PIX_LINES);
-   regw(0, HORZ_INFO);
-   regw(0, VERT_START);
-   regw(0, VERT_LINES);
-   regw(0x00ff, CULLING);
-   regw(0, HSIZE_OFF);
-   regw(0, SDOFST);
-   regw(0, SDR_ADDR);
-   regw(0, VDINT);
-   regw(0, REC656IF);
-   regw(0, CCDCFG);
-   regw(0, FMTCFG);
-   regw(0, VP_OUT);
-}
-
-void ccdc_setwin(ccdc_params_ycbcr * params)
-{
-   int horz_start, horz_nr_pixels;
-   int vert_start, vert_nr_lines;
-
-   /* configure horizonal and vertical starts and sizes */
-   horz_start = params-win.left  1;
-   horz_nr_pixels = (params-win.width 1) - 1;
-   regw((horz_start  16) | horz_nr_pixels, HORZ_INFO);
-
-   vert_start = params-win.top;
-
-   if (params-frm_fmt == CCDC_FRMFMT_INTERLACED) {
-   vert_nr_lines = (params-win.height  1) - 1;
-   vert_start = 1;
-   } else {
-   vert_nr_lines = params-win.height - 1;
-   }
-   regw((vert_start  16) | vert_start, VERT_START);
-   regw(vert_nr_lines, VERT_LINES);
-}
-
-void ccdc_config_ycbcr(ccdc_params_ycbcr * params)
-{
-   u32 syn_mode;
-
-   /* first reset the CCDC  */
-   /* all registers have default values after reset */
-   /* This is important since we assume default values to be set in */
-   /* a lot of registers that we didn't touch   */
-   ccdc_reset();
-
-   /* configure pixel format */
-   syn_mode = (params-pix_fmt  0x3)  12;
-
-   /* configure video frame format */
-   syn_mode |= (params-frm_fmt  0x1)  7;
-
-   /* setup BT.656 sync mode */
-   if (params-bt656_enable) {
-   regw(3, REC656IF);
-
-   /* configure the FID, VD, HD pin polarity */
-   /* fld,hd pol positive, vd negative, 8-bit pack mode */
-   syn_mode |= 0x0F04;
-   } else {/* y/c external sync mode */
-   syn_mode |= ((params-fid_pol  0x1)  4);
-   syn_mode |= ((params-hd_pol  0x1)  3);
-   syn_mode |= ((params-vd_pol  0x1)  2);
-   }
-
-   /* configure video window */
-   ccdc_setwin(params);
-
-   /* configure the order of y cb cr in SD-RAM */
-   regw((params-pix_order  11) | 0x8000, CCDCFG);
-
-   /* configure the horizontal line offset */
-   /* this is done by rounding up width to a multiple of 16 pixels */
-   /* and multiply by two to account for y:cb:cr 4:2:2 data */
-   regw(((params-win.width * 2) + 31)  0xffe0, HSIZE_OFF);
-
-   /* configure the memory line offset */
-   if (params-buf_type == CCDC_BUFTYPE_FLD_INTERLEAVED) {
-   /* two fields are interleaved in memory */
-   regw(0x0249, SDOFST);
- 

[PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

DM644x CCDC hw module

This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE

Following are some of the major comments addressed :-
1) removed vpss configration from this module to a standalone
   vpss module that can be used by other video drivers as well
2) replaced magic numbers with #defines
3) cleaned up and refractored ccdc_config_raw()
4) embedded config part of the variables inside
   ccdc_params_raw to help in memcpy.
5) avoided generic names for ccdc types in include file by
   prefixing with  ccdc_

Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/dm644x_ccdc.c  |  876 
 drivers/media/video/davinci/dm644x_ccdc_regs.h |  145 
 include/media/davinci/dm644x_ccdc.h|  184 +
 3 files changed, 1205 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/dm644x_ccdc.c
 create mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h
 create mode 100644 include/media/davinci/dm644x_ccdc.h

diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
b/drivers/media/video/davinci/dm644x_ccdc.c
new file mode 100644
index 000..4f81f69
--- /dev/null
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -0,0 +1,876 @@
+/*
+ * Copyright (C) 2006-2009 Texas Instruments Inc
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * CCDC hardware module for DM6446
+ * --
+ *
+ * This module is for configuring CCD controller of DM6446 VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Raw Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application includes dm644x_ccdc.h and vpfe_capture.h header
+ * files.  The setparams() API is called by vpfe_capture driver
+ * to configure module parameters. This file is named DM644x so that other
+ * variants such DM6443 may be supported using the same module.
+ *
+ * TODO: Test Raw bayer parameter settings and bayer capture
+ *  Split module parameter structure to module specific ioctl structs
+ *  investigate if enum used for user space type definition
+ *  to be replaced by #defines or integer
+ */
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/videodev2.h
+#include media/davinci/dm644x_ccdc.h
+#include media/davinci/vpss.h
+#include dm644x_ccdc_regs.h
+#include ccdc_hw_device.h
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .config_params = {
+   .data_sz = CCDC_DATA_10BITS,
+   },
+};
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+   .frm_fmt = CCDC_FRMFMT_INTERLACED,
+   .win = CCDC_WIN_PAL,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .bt656_enable = 1,
+   .pix_order = CCDC_PIXORDER_CBYCRY,
+   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
+};
+
+#define CCDC_MAX_RAW_YUV_FORMATS   2
+
+/* Raw Bayer formats */
+static u32 ccdc_raw_bayer_pix_formats[] =
+   {V4L2_PIX_FMT_SBGGR8, V4L2_PIX_FMT_SBGGR16};
+
+/* Raw YUV formats */
+static u32 ccdc_raw_yuv_pix_formats[] =
+   {V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+
+static void *__iomem ccdc_base_addr;
+static int ccdc_addr_size;
+static enum vpfe_hw_if_type ccdc_if_type;
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+   return 

[PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver

2009-06-11 Thread m-karicheri2
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

DM355 CCDC hw module

Adds ccdc hw module for DM355 CCDC. This registers with the bridge
driver a set of hw_ops for configuring the CCDC for a specific
decoder device connected to vpfe.

Following are some of the major comments addressed :-
1) removed vpss configration from this module to a standalone
   vpss module that can be used by other video drivers as well
2) replaced magic numbers with #defines
3) cleaned up and refractored ccdc_config_raw()
4) embedded config part of the variables inside
   ccdc_params_raw to help in memcpy.
5) avoided generic names for ccdc types in include file by
   prefixing with  ccdc_

Reviewed By Hans Verkuil. 
Reviewed By Laurent Pinchart.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/dm355_ccdc.c  | 1161 +
 drivers/media/video/davinci/dm355_ccdc_regs.h |  310 +++
 include/media/davinci/dm355_ccdc.h|  336 +++
 3 files changed, 1807 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/dm355_ccdc.c
 create mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h
 create mode 100644 include/media/davinci/dm355_ccdc.h

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
new file mode 100644
index 000..1e7152e
--- /dev/null
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -0,0 +1,1161 @@
+/*
+ * Copyright (C) 2005-2009 Texas Instruments Inc
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * CCDC hardware module for DM355
+ * --
+ *
+ * This module is for configuring DM355 CCD controller of VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application include dm355_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ *  2) Split module parameter structure to module specific ioctl structs
+ *  3) add support for lense shading correction
+ *  4) investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/videodev2.h
+#include media/davinci/dm355_ccdc.h
+#include media/davinci/vpss.h
+#include dm355_ccdc_regs.h
+#include ccdc_hw_device.h
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .gain = {
+   .r_ye = 256,
+   .gb_g = 256,
+   .gr_cy = 256,
+   .b_mg = 256
+   },
+   .config_params = {
+   .datasft = 2,
+   .data_sz = CCDC_DATA_10BITS,
+   .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+   .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+   .alaw = {
+   .gama_wd = 2,
+   },
+   .blk_clamp = {
+   .sample_pixel = 1,
+   .dc_sub = 25
+   },
+   .col_pat_field0 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
+   .col_pat_field1 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
+   },
+};
+
+
+/* Object for CCDC ycbcr mode */
+static struct 

Re: Terratec DT USB XS Diversity/DiB0070+vdr: URB status: Value too large for defined data type+USB reset

2009-06-11 Thread Marco Borm

Hi Patrick,

FYI: I tried 2.6.30 now and its still not working.


Marco

Patrick Boettcher wrote:

Hi Marco,

On Tue, 2 Jun 2009, Marco Borm wrote:
Definitely interesting. This is a known issue for the dib0700 
device, which happens on some USB host controllers. Actually which 
one do you use?


USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller

Hmm, looks bad: http://www.google.com/search?q=dib0700+sb700
But I am wondering if this could really be some bigger linux 
USB-stack problem, because it runs with Linux/totem for hours 
(mplayer was wrong). For me it looks like vdr uses some feature the 
driver doesn't handle correctly. Isn't the EOVERFLOW some local error 
value from the usb stack generates if some given buffer was to small?


:(. It is a long story for the SB700 ATI HC ... It turned out for 
DiBcom that ATI fixed the HC-driver for Windows to make things work 
correctly.


At some point in time they provided a patch for Linux and it was 
actually included in 2.6.21 or 22 .


There is some work going on on 2.6.30 for almost similar problems for 
another device, maybe it is worth to either:


1) try out latest 2.6.30 releases



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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-06-11 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Thu Jun 11 19:00:03 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   11930:ed3781a79c73
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: WARNINGS
linux-2.6.28-armv5: WARNINGS
linux-2.6.29.1-armv5: OK
linux-2.6.30-rc7-armv5: OK
linux-2.6.27-armv5-ixp: WARNINGS
linux-2.6.28-armv5-ixp: WARNINGS
linux-2.6.29.1-armv5-ixp: WARNINGS
linux-2.6.30-rc7-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-rc7-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-rc7-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-rc7-m32r: OK
linux-2.6.22.19-mips: ERRORS
linux-2.6.26-mips: ERRORS
linux-2.6.27-mips: ERRORS
linux-2.6.28-mips: ERRORS
linux-2.6.29.1-mips: ERRORS
linux-2.6.30-rc7-mips: ERRORS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-rc7-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: OK
linux-2.6.30-rc7-x86_64: WARNINGS
sparse (linux-2.6.29.1): OK
sparse (linux-2.6.30-rc7): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The V4L2 specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

--
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] dvb: Fix broken link in get_dvb_firmware for nxt2004 (A180)

2009-06-11 Thread Jan Ceuleers
Due to a reorganisation of AVermedia's websites, get_dvb_firmware
no longer works for nxt2004. Fix it.

Signed-off-by: Jan Ceuleers jan.ceule...@computer.org
--- a/Documentation/dvb/get_dvb_firmware.orig2009-06-07 
14:38:20.0 +0200
+++ b/Documentation/dvb/get_dvb_firmware 2009-06-07 14:38:55.0 +0200
@@ -317,7 +317,7 @@

 sub nxt2004 {
 my $sourcefile = AVerTVHD_MCE_A180_Drv_v1.2.2.16.zip;
-my $url = http://www.aver.com/support/Drivers/$sourcefile;;
+my $url = http://www.avermedia-usa.com/support/Drivers/$sourcefile;;
 my $hash = 111cb885b1e009188346d72acfed024c;
 my $outfile = dvb-fe-nxt2004.fw;
 my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
--
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: s5h1411_readreg: readreg error (ret == -5)

2009-06-11 Thread Mike Isely
On Thu, 11 Jun 2009, Steven Toth wrote:

 Mike Isely wrote:
  On Sun, 7 Jun 2009, Roger wrote:
  
   From looking at linux/drivers/media/dvb/frontends/s5h1411.c,  The
   s5h1411_readreg wants to see 2 but is getting -5 from the i2c bus.
   
   --- Snip ---
   
   s5h1411_readreg: readreg error (ret == -5)
   pvrusb2: unregistering DVB devices
   device: 'dvb0.net0': device_unregister
   
   --- Snip ---
   
   What exactly does this mean?
  
  Roger:
  
  It means that the module attempted an I2C transfer and the transfer failed.
  The I2C adapter within the pvrusb2 driver will return either the number of
  bytes that it transferred or a failure code.  The failure code, as is normal
  convention in the kernel, will be a negated errno value.  Thus the expected
  value of 2 would be the fact that it probably tried a 2 byte transfer, while
  the actual value returned of -5 indicate an EIO error, which is what the
  pvrusb2 driver will return when the underlying I2C transaction has failed.
  
  Of course the real question is not that it failed but why it failed.  And
  for that I unfortunately do not have an answer.  It's possible that the
  s5h1411 driver did something that the chip didn't like and the chip
  responded by going deaf on the I2C bus.  More than a few I2C-driven parts
  can behave this way.  It's also possible that the part might have been busy
  and unable to respond - but usually in that case the driver for such a part
  will be written with this in mind and will know how / when to communicate
  with the hardware.
 
 Roger:
 
 Another possibility, although I don't know the PVRUSB2 driver too well, the
 s5h1411 is being held in reset when the driver unloads _AFTER_ the last active
 use was analog video (assuming the s5h1411 is floated in reset as the FX2
 input port might be shared with the analog encoder)

Good point.  The pvrusb2 driver is not currently doing anything specific 
- or at least deliberate - via the FX2 to move that part in/out of 
reset.  (Of course, I am issuing FX2 commands to shift modes and that 
might in turn be triggering other things.)  But even if I did do 
something specific, what kind of impact is that likely to do on the 
corresponding, blissfully ignorant, driver?

This actually drives towards a larger issue - the pvrusb2 driver works 
with various V4L-only sub-devices, e.g. cx25840, which have no relevance 
in digital mode but I can't really control when that corresponding 
driver is enabled / disabled.  So if I have to take an extra step to 
physically disable a chip when in digital mode, then this might impact 
the sub-driver which otherwise is going to have no clue what is really 
going on.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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 v2] tuner-xc2028: Fix 7 MHz DVB-T

2009-06-11 Thread Mauro Carvalho Chehab
Em Thu, 11 Jun 2009 06:57:50 -0400
Andy Walls awa...@radix.net escreveu:

 All,
 
 The following patch should fix 7 MHz DVB-T with the XC3028 using the
 DTV7 firmware from the xc3028-v27.fw firmware image.

DTV7 and DTV78 support were added and tested in Australia by Christopher
Pascoe, as can be seen on his tree that it is known to work in Australia:


http://linuxtv.org/hg/~pascoe/xc-test/file/d4f7804a393c/linux/drivers/media/video/tuner-xc2028.c

On that time, he did some experimental tests and observed what should be the
real offset.

His code does this:

} else { /* DTV */
offset = 2750;
+   /*
+* We must adjust the offset by 500kHz in two cases in order
+* to correctly center the IF output:
+* 1) When the ZARLINK456 or DIBCOM52 tables were explicitly
+*selected and a 7MHz channel is tuned;
+* 2) When tuning a VHF channel with DTV78 firmware.
+*/
+   if (((priv-cur_fw.type  DTV7) 
+(priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
+   ((priv-cur_fw.type  DTV78)  freq  47000))
offset -= 50; 

So, it selects ZARLINK456 or DIBCOM52, depending on the demod IF, and corrects
the offset to be 225Hz for DTV7 or DTV78 firmwares and VHF.

This is exactly what we're doing with the current code:

else if (priv-cur_fw.type  DTV7)
offset = 225;
else/* DTV8 or DTV78 */
offset = 275;

/*
 * We must adjust the offset by 500kHz  when
 * tuning a 7MHz VHF channel with DTV78 firmware
 * (used in Australia, Italy and Germany)
 */
if ((priv-cur_fw.type  DTV78)  freq  47000)
offset -= 50;

So, I suspect that the current code is correct.

For us to double check if any other change at the code didn't break for
Australia (and other DTV7/DTV78 countries), it would be really cool if people
could report about success or failure with tuner xc3028 on those countries.

For now, I'll mark this patch as RFC at patchwork.

Unfortunately, we've lost the contact with Christopher, since AFAIK, he moved
to another country.

Cheers,
Mauro.

 
 Comments?
 
 Regards,
 Andy Walls
 
 Signed-off-by: Andy Walls awa...@radix.net
 Tested-by: Terry Wu terrywu2...@gmail.com
 
 diff -r fad35ab59848 linux/drivers/media/common/tuners/tuner-xc2028.c
 --- a/linux/drivers/media/common/tuners/tuner-xc2028.cFri Jun 05 
 08:42:27 2009 -0400
 +++ b/linux/drivers/media/common/tuners/tuner-xc2028.cThu Jun 11 
 06:52:55 2009 -0400
 @@ -1099,8 +1099,19 @@
   }
  
   /* All S-code tables need a 200kHz shift */
 - if (priv-ctrl.demod)
 + if (priv-ctrl.demod) {
   demod = priv-ctrl.demod + 200;
 + /*
 +  * The DTV7 S-code table needs a 700 kHz shift.
 +  * Thanks to Terry Wu terrywu2...@gmail.com for reporting this
 +  *
 +  * DTV7 is only used in Australia.  Germany or Italy may also
 +  * use this firmware after initialization, but a tune to a UHF
 +  * channel should then cause DTV78 to be used.
 +  */
 + if (type  DTV7)
 + demod += 500;
 + }
  
   return generic_set_freq(fe, p-frequency,
   T_DIGITAL_TV, type, 0, demod);
 
 




Cheers,
Mauro
--
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: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Hans Verkuil
On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
 Hi all,
 
 With Linux 2.6.30 the BTTV driver for my WinTV card claims
 
   bttv0: audio absent, no audio device found!
 
 and audio does not work. This worked up to and including 2.6.29. Is this a
 known issue? Does anyone have a fix or a patch for me to try?

You've no doubt compiled the bttv driver into the kernel and not as a module.

I've just pushed a fix for this to my tree: 
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

Regards,

Hans

 
 Cheers,
 
   - Udo
 
 
 Output for 2.6.29:
 --
 Linux video capture interface: v2.00
 bttv: driver version 0.9.17 loaded
 bttv: using 8 buffers with 2080k (520 pages) each for capture
 bttv: Bt8xx card found (0).
 bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
 bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
 bttv0: using: Hauppauge (bt878) [card=10,autodetected]
 IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
 bttv0: gpio: en=, out= in=00db [init]
 bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
 tuner' 0-0042: chip found @ 0x84 (bt878 #0 [sw])
 tda9887 0-0042: creating new instance
 tda9887 0-0042: tda988[5/6/7] found
 tuner' 0-0061: chip found @ 0xc2 (bt878 #0 [sw])
 tveeprom 0-0050: Hauppauge model 37284, rev B221, serial# 3546046
 tveeprom 0-0050: tuner model is Philips FM1216 (idx 21, type 5)
 tveeprom 0-0050: TV standards PAL(B/G) (eeprom 0x04)
 tveeprom 0-0050: audio processor is MSP3410D (idx 5)
 tveeprom 0-0050: has radio
 bttv0: Hauppauge eeprom indicates model#37284
 bttv0: tuner type=5
 tuner-simple 0-0061: creating new instance
 tuner-simple 0-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 bttv0: registered device video0
 bttv0: registered device vbi0
 bttv0: registered device radio0
 bttv0: PLL: 28636363 = 35468950 .. ok
 
 Output for 2.6.30:
 --
 Linux video capture interface: v2.00
 bttv: driver version 0.9.18 loaded
 bttv: using 8 buffers with 2080k (520 pages) each for capture
 bttv: Bt8xx card found (0).
 bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
 bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
 bttv0: using: Hauppauge (bt878) [card=10,autodetected]
 IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
 bttv0: gpio: en=, out= in=00db [init]
 bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
 tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046
 tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5)
 tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04)
 tveeprom 1-0050: audio processor is MSP3410D (idx 5)
 tveeprom 1-0050: has radio
 bttv0: Hauppauge eeprom indicates model#37284
 bttv0: tuner type=5
 tuner 1-0042: chip found @ 0x84 (bt878 #0 [sw])
 tda9887 1-0042: creating new instance
 tda9887 1-0042: tda988[5/6/7] found
 tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw])
 tuner-simple 1-0061: creating new instance
 tuner-simple 1-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 bttv0: audio absent, no audio device found!
 bttv0: registered device video0
 bttv0: registered device vbi0
 bttv0: registered device radio0
 
 
 



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Hans Verkuil
On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
 On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
  Hi all,
  
  With Linux 2.6.30 the BTTV driver for my WinTV card claims
  
  bttv0: audio absent, no audio device found!
  
  and audio does not work. This worked up to and including 2.6.29. Is this a
  known issue? Does anyone have a fix or a patch for me to try?
 
 You've no doubt compiled the bttv driver into the kernel and not as a module.
 
 I've just pushed a fix for this to my tree: 
 http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

I've also attached a diff against 2.6.30 since the patch in my tree is against
the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.

Hans


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--- drivers/media/video/Makefile.org	2009-06-11 21:51:05.0 +0200
+++ drivers/media/video/Makefile	2009-06-11 21:54:48.0 +0200
@@ -12,6 +12,8 @@
 
 videodev-objs	:=	v4l2-dev.o v4l2-ioctl.o v4l2-device.o
 
+# V4L2 core modules
+
 obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o
 ifeq ($(CONFIG_COMPAT),y)
   obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o
@@ -23,21 +25,16 @@
   obj-$(CONFIG_VIDEO_DEV) += v4l1-compat.o
 endif
 
-obj-$(CONFIG_VIDEO_TUNER) += tuner.o
+# All i2c modules must come first:
 
-obj-$(CONFIG_VIDEO_BT848) += bt8xx/
+obj-$(CONFIG_VIDEO_TUNER) += tuner.o
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_TDA9875) += tda9875.o
-
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_SAA5246A) += saa5246a.o
 obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o
-obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o
-obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o
-obj-$(CONFIG_VIDEO_W9966) += w9966.o
-
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
@@ -54,11 +51,40 @@
 obj-$(CONFIG_VIDEO_BT856) += bt856.o
 obj-$(CONFIG_VIDEO_BT866) += bt866.o
 obj-$(CONFIG_VIDEO_KS0127) += ks0127.o
+obj-$(CONFIG_VIDEO_VINO) += indycam.o
+obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
+obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
+obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
+obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
+obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
+obj-$(CONFIG_VIDEO_M52790) += m52790.o
+obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o
+obj-$(CONFIG_VIDEO_WM8775) += wm8775.o
+obj-$(CONFIG_VIDEO_WM8739) += wm8739.o
+obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
+obj-$(CONFIG_VIDEO_CX25840) += cx25840/
+obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
+obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV7670) 	+= ov7670.o
+obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
+obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
 
-obj-$(CONFIG_VIDEO_ZORAN) += zoran/
+obj-$(CONFIG_SOC_CAMERA_MT9M001)	+= mt9m001.o
+obj-$(CONFIG_SOC_CAMERA_MT9M111)	+= mt9m111.o
+obj-$(CONFIG_SOC_CAMERA_MT9T031)	+= mt9t031.o
+obj-$(CONFIG_SOC_CAMERA_MT9V022)	+= mt9v022.o
+obj-$(CONFIG_SOC_CAMERA_OV772X)		+= ov772x.o
+obj-$(CONFIG_SOC_CAMERA_TW9910)		+= tw9910.o
 
+# And now the v4l2 drivers:
+
+obj-$(CONFIG_VIDEO_BT848) += bt8xx/
+obj-$(CONFIG_VIDEO_ZORAN) += zoran/
+obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o
+obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o
+obj-$(CONFIG_VIDEO_W9966) += w9966.o
 obj-$(CONFIG_VIDEO_PMS) += pms.o
-obj-$(CONFIG_VIDEO_VINO) += vino.o indycam.o
+obj-$(CONFIG_VIDEO_VINO) += vino.o
 obj-$(CONFIG_VIDEO_STRADIS) += stradis.o
 obj-$(CONFIG_VIDEO_CPIA) += cpia.o
 obj-$(CONFIG_VIDEO_CPIA_PP) += cpia_pp.o
@@ -69,17 +95,7 @@
 obj-$(CONFIG_VIDEO_EM28XX) += em28xx/
 obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/
 obj-$(CONFIG_VIDEO_USBVISION) += usbvision/
-obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
-obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
 obj-$(CONFIG_VIDEO_PVRUSB2) += pvrusb2/
-obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
-obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
-obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
-obj-$(CONFIG_VIDEO_M52790) += m52790.o
-obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o
-obj-$(CONFIG_VIDEO_WM8775) += wm8775.o
-obj-$(CONFIG_VIDEO_WM8739) += wm8739.o
-obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
 obj-$(CONFIG_VIDEO_OVCAMCHIP) += ovcamchip/
 obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
 obj-$(CONFIG_VIDEO_MXB) += mxb.o
@@ -92,19 +108,12 @@
 obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o
 obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
 obj-$(CONFIG_VIDEO_BTCX)  += btcx-risc.o
-obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
 
 obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
 
-obj-$(CONFIG_VIDEO_CX25840) += cx25840/
-obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
-obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
 
 obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
-obj-$(CONFIG_VIDEO_OV7670) 	+= ov7670.o
-
-obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
 
 obj-$(CONFIG_USB_DABUSB)+= dabusb.o
 obj-$(CONFIG_USB_OV511) += ov511.o
@@ -134,19 +143,14 @@
 

Re: [PATCH 9/10 - v2] remove outdated video driver files of dm6446

2009-06-11 Thread Kevin Hilman
m-kariche...@ti.com writes:

 From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

 Remove outdated driver files from davinci git tree

Can you add another patch that removes the old Kconfig/Makfile entries
as well (of course, this only applied to davinci git and not mainline.)

Also, can't we drop the Kconfig/Makefile stuff for tvp5146.c also?

Thanks,

Kevin

 No change from last patch

 Reviewed By Hans Verkuil.
 Reviewed By Laurent Pinchart.

 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
 Applies to Davinci GIT Tree

  drivers/media/video/ccdc_davinci.c |  124 
  drivers/media/video/davinci_vpfe.c | 1136 
 
  include/media/ccdc_davinci.h   |  144 -
  include/media/davinci_vpfe.h   |  121 
  4 files changed, 0 insertions(+), 1525 deletions(-)
  delete mode 100644 drivers/media/video/ccdc_davinci.c
  delete mode 100644 drivers/media/video/davinci_vpfe.c
  delete mode 100644 include/media/ccdc_davinci.h
  delete mode 100644 include/media/davinci_vpfe.h

 diff --git a/drivers/media/video/ccdc_davinci.c 
 b/drivers/media/video/ccdc_davinci.c
 deleted file mode 100644
 index d3cd333..000
 --- a/drivers/media/video/ccdc_davinci.c
 +++ /dev/null
 @@ -1,124 +0,0 @@
 -/*
 - *
 - *
 - * Copyright (C) 2006 Texas Instruments Inc
 - *
 - * 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; either version 2 of the License, or
 - * (at your option) any later version.
 - *
 - * This program is distributed in the hope that it will be useful,
 - * but WITHOUT ANY WARRANTY; without even the implied warranty of
 - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 - * GNU General Public License for more details.
 - *
 - * You should have received a copy of the GNU General Public License
 - * along with this program; if not, write to the Free Software
 - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 - */
 -/* ccdc_davinci.c */
 -
 -#include media/ccdc_davinci.h
 -#define debug_print(x...)//printk(x)
 -void ccdc_reset()
 -{
 - int i;
 - /* disable CCDC */
 - ccdc_enable(0);
 - /* set all registers to default value */
 - for (i = 0; i = 0x94; i += 4) {
 - regw(0, i);
 - }
 - regw(0, PCR);
 - regw(0, SYN_MODE);
 - regw(0, HD_VD_WID);
 - regw(0, PIX_LINES);
 - regw(0, HORZ_INFO);
 - regw(0, VERT_START);
 - regw(0, VERT_LINES);
 - regw(0x00ff, CULLING);
 - regw(0, HSIZE_OFF);
 - regw(0, SDOFST);
 - regw(0, SDR_ADDR);
 - regw(0, VDINT);
 - regw(0, REC656IF);
 - regw(0, CCDCFG);
 - regw(0, FMTCFG);
 - regw(0, VP_OUT);
 -}
 -
 -void ccdc_setwin(ccdc_params_ycbcr * params)
 -{
 - int horz_start, horz_nr_pixels;
 - int vert_start, vert_nr_lines;
 -
 - /* configure horizonal and vertical starts and sizes */
 - horz_start = params-win.left  1;
 - horz_nr_pixels = (params-win.width 1) - 1;
 - regw((horz_start  16) | horz_nr_pixels, HORZ_INFO);
 -
 - vert_start = params-win.top;
 -
 - if (params-frm_fmt == CCDC_FRMFMT_INTERLACED) {
 - vert_nr_lines = (params-win.height  1) - 1;
 - vert_start = 1;
 - } else {
 - vert_nr_lines = params-win.height - 1;
 - }
 - regw((vert_start  16) | vert_start, VERT_START);
 - regw(vert_nr_lines, VERT_LINES);
 -}
 -
 -void ccdc_config_ycbcr(ccdc_params_ycbcr * params)
 -{
 - u32 syn_mode;
 -
 - /* first reset the CCDC  */
 - /* all registers have default values after reset */
 - /* This is important since we assume default values to be set in */
 - /* a lot of registers that we didn't touch   */
 - ccdc_reset();
 -
 - /* configure pixel format */
 - syn_mode = (params-pix_fmt  0x3)  12;
 -
 - /* configure video frame format */
 - syn_mode |= (params-frm_fmt  0x1)  7;
 -
 - /* setup BT.656 sync mode */
 - if (params-bt656_enable) {
 - regw(3, REC656IF);
 -
 - /* configure the FID, VD, HD pin polarity */
 - /* fld,hd pol positive, vd negative, 8-bit pack mode */
 - syn_mode |= 0x0F04;
 - } else {/* y/c external sync mode */
 - syn_mode |= ((params-fid_pol  0x1)  4);
 - syn_mode |= ((params-hd_pol  0x1)  3);
 - syn_mode |= ((params-vd_pol  0x1)  2);
 - }
 -
 - /* configure video window */
 - ccdc_setwin(params);
 -
 - /* configure the order of y cb cr in SD-RAM */
 - regw((params-pix_order  11) | 0x8000, CCDCFG);
 -
 - /* configure the horizontal line offset */
 - /* this is done by rounding up width to a multiple of 16 pixels */
 - /* and multiply by two to account for y:cb:cr 4:2:2 data */
 - 

Re: [PATCH 7/10 - v2] DM355 platform changes for vpfe capture driver

2009-06-11 Thread David Brownell
On Thursday 11 June 2009, m-kariche...@ti.com wrote:
 +   I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),

Minor nit:  just use 0x5d instead of defining TVP5146_I2C_ADDR.
Fix in a v3, iff you make one.

--
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/10 - v2] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver

2009-06-11 Thread David Brownell
On Thursday 11 June 2009, m-kariche...@ti.com wrote:
 VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446
 
 This is the version v2 of the patch series. This is the reworked
 version of the driver based on comments received against the last
 version of the patch.

I'll be glad to see this get to mainline ... it's seeming closer
and closer!

What's the merge plan though?  I had hopes for 2.6.31.real-soon
but several of the later patches comment

   Applies to Davinci GIT Tree

which implies not -next.  DM355 patches are in the -next tree.

Is this just an oversight (tracking -next can be a PITA!) or is
there some other dependency?

- dave

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


[PULL] http://linuxtv.org/hg/~dougsland/video4linux

2009-06-11 Thread Douglas Schilling Landgraf
Hello Mauro,

  Please pull from
http://linuxtv.org/hg/~dougsland/video4linux for the following:

  - dvb: Fix broken link in get_dvb_firmware for nxt2004 (A180)
  - tvp514x: try_count off by one
  - v4l: generate KEY_CAMERA instead of BTN_0 key events on
input devices
  - se401: Fix unsafe use of sprintf with identical source/destination
  - usbvision-core.c: vfree does its own NULL check
  - dsbr100: change radio-muted to radio-status, update suspend/resume
  - dsbr100: no need to pass curfreq value to dsbr100_setfreq()
  - dsbr100: remove usb_dsbr100_open/close calls
  - dsbr100: remove radio-users counter
  - V4L: return -ENOMEM

Thanks,
Douglas
--
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


2.6.30: missing audio device in bttv

2009-06-11 Thread Udo A. Steinberg
Hi all,

With Linux 2.6.30 the BTTV driver for my WinTV card claims

bttv0: audio absent, no audio device found!

and audio does not work. This worked up to and including 2.6.29. Is this a
known issue? Does anyone have a fix or a patch for me to try?

Cheers,

- Udo


Output for 2.6.29:
--
Linux video capture interface: v2.00
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=, out= in=00db [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tuner' 0-0042: chip found @ 0x84 (bt878 #0 [sw])
tda9887 0-0042: creating new instance
tda9887 0-0042: tda988[5/6/7] found
tuner' 0-0061: chip found @ 0xc2 (bt878 #0 [sw])
tveeprom 0-0050: Hauppauge model 37284, rev B221, serial# 3546046
tveeprom 0-0050: tuner model is Philips FM1216 (idx 21, type 5)
tveeprom 0-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 0-0050: audio processor is MSP3410D (idx 5)
tveeprom 0-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner-simple 0-0061: creating new instance
tuner-simple 0-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
bttv0: PLL: 28636363 = 35468950 .. ok

Output for 2.6.30:
--
Linux video capture interface: v2.00
bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=, out= in=00db [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046
tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5)
tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 1-0050: audio processor is MSP3410D (idx 5)
tveeprom 1-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner 1-0042: chip found @ 0x84 (bt878 #0 [sw])
tda9887 1-0042: creating new instance
tda9887 1-0042: tda988[5/6/7] found
tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
bttv0: audio absent, no audio device found!
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0



-- 
Dipl.-Inf. Udo Steinberg
Technische Universität Dresden http://os.inf.tu-dresden.de/~us15
Institute for System Architecture  Tel: +49 351 463 38401
D-01062 DresdenFax: +49 351 463 38284


signature.asc
Description: PGP signature


Re: cx18, s5h1409: chronic bit errors, only under Linux

2009-06-11 Thread David Ward

On 06/10/2009 10:32 AM, Steven Toth wrote:

David Ward wrote:
Comcast checked the outlet on channels 2 (41 dB) and 83 (39 dB).  I 
looked afterwards and saw that the first of those is analog 
programming, but the second just appears as analog noise on my TV 
set. (??)  I asked them to check a specific ATSC channel, but it 
seems that their meter was fixed to those two frequencies, which 
doesn't really help.  The ATSC rebroadcasts by Comcast are on high 
frequencies; the program I am testing primarily is on channel 79 
(tunes at 555 MHz).


I need to make a correction here.  I am receiving all programming over 
digital cable.  I mistakenly thought that rebroadcasts of over-the-air 
signals on a cable network followed all the ATSC specifications 
(including the modulation scheme) over the particular carrier 
frequency.  Now I understand that like all other digital cable channels, 
local channels are broadcasted using QAM rather than 8VSB (but then they 
also include PSIP data as required by the FCC).  So the SNR requirements 
for QAM-256 are the ones that should apply to my situation.  That's a 
big misunderstanding on my part...my bad.


Which of these three values is UNC/BER and which is snr? I don't 
understand, I need you to be more specific.


Sorry for not being clear.  I tested again thoroughly under both Linux 
and Windows before writing this response.


Linux is tuning almost all channels at a SNR approximately 3 dB less 
than under Windows.  That is why I now believe this is a tuner driver 
problem.  I composed a table for myself with average SNRs per channel 
while running both Windows and Linux to determine this, both with the 
tuner card connected directly to the household cable, and connected 
behind the splitter in my house.


Under Windows, channels with low frequencies have an SNR of ~35 dB, and 
channels with high frequency have an SNR of ~33 dB, when connected 
directly to the household input.  The splitter at most gives me a loss 
of 1 dB but often makes no difference.


Again, sorry for not making that clear.  I think the 3 dB difference is 
the real issue at play here, and is the reason I'm writing this message 
to this list, rather than one intended for household wiring issues.


Did you get a chance to review the signal monitor to determine whether 
it was 64 or 256?


All channels are 256-QAM -- reported as such by both Linux and Windows.

If you have any way to attenuate the signal then you'll find that very 
quickly the windows 30.5 will drop just a little and you'll begin to 
see real uncorrectable errors. I alluded to this yesterday. With 30.5 
your just a fraction above 'working' reliably.


If you were to insert attenuation through some barrel connectors, or 
join some other cables together to impede the RF, you'd see that 30.5 
drop quickly and the errors would begin to appear. I suspect this will 
still occur, as I mentioned yesterday.


The windows drivers is working slightly better for you but it's still 
no where near good enough RF for reliable 24x7x365 viewing. You'll 
find the RF on your local cable rings varies during an average day. It 
certainly does for me on various products. What looks great today 
(when you're on the edge) can look ugly at 9pm in the evening or 7am 
thursday morning.


I wouldn't expect pristine recordings with Microsoft MCE (or other 
apps) (for any random moment in the week) with a 30.5 reading.


Based on our discussion until now, the difference between 30.5 dB and 
33.5 dB should be very significant, and I hope would warrant an 
investigation into the cause (possibly asking Hauppauge/Conexant to 
compare details of your tuner drivers against theirs?  I understand they 
provide support to the Linux community).  As you said, if Windows was 
only picking up the channels at 30.5 dB, then I shouldn't expect much 
more than I am getting now, as I would be riding on a thin line between 
errors and no errors.


Sorry for not being accurate in some of my earlier messages, and thanks 
for being patient with me.


David
--
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: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Udo A. Steinberg
On Thu, 11 Jun 2009 22:18:10 +0200 Hans Verkuil (HV) wrote:

HV On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
HV  Hi all,
HV  
HV  With Linux 2.6.30 the BTTV driver for my WinTV card claims
HV  
HVbttv0: audio absent, no audio device found!
HV  
HV  and audio does not work. This worked up to and including 2.6.29. Is
HV  this a known issue? Does anyone have a fix or a patch for me to try?
HV 
HV You've no doubt compiled the bttv driver into the kernel and not as a
HV module.
HV 
HV I've just pushed a fix for this to my tree:
HV http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

Yes, I've compiled bttv into the kernel. I've (hopefully correctly) ported
the commit http://www.linuxtv.org/hg/~hverkuil/v4l-dvb/rev/820630b2b12f
to 2.6.30. Now I'm getting:

bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=, out= in=00db [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-1/1-0018/ir0 [bt878 #0 [sw]]
i2c-adapter i2c-1: sendbytes: NAK bailout.
tveeprom 1-0050: Huh, no eeprom present (err=-5)?
tveeprom 1-0050: Encountered bad packet header [00]. Corrupt or not a Hauppauge 
eeprom.
bttv0: Hauppauge eeprom indicates model#0
bttv0: tuner absent
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 = 35468950

Cheers,

- Udo


signature.asc
Description: PGP signature


Re: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Hans Verkuil
On Thursday 11 June 2009 23:38:17 Udo A. Steinberg wrote:
 On Thu, 11 Jun 2009 22:18:10 +0200 Hans Verkuil (HV) wrote:
 
 HV On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
 HV  Hi all,
 HV  
 HV  With Linux 2.6.30 the BTTV driver for my WinTV card claims
 HV  
 HV  bttv0: audio absent, no audio device found!
 HV  
 HV  and audio does not work. This worked up to and including 2.6.29. Is
 HV  this a known issue? Does anyone have a fix or a patch for me to try?
 HV 
 HV You've no doubt compiled the bttv driver into the kernel and not as a
 HV module.
 HV 
 HV I've just pushed a fix for this to my tree:
 HV http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
 
 Yes, I've compiled bttv into the kernel. I've (hopefully correctly) ported
 the commit http://www.linuxtv.org/hg/~hverkuil/v4l-dvb/rev/820630b2b12f
 to 2.6.30. Now I'm getting:
 
 bttv: driver version 0.9.18 loaded
 bttv: using 8 buffers with 2080k (520 pages) each for capture
 bttv: Bt8xx card found (0).
 bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
 bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
 bttv0: using: Hauppauge (bt878) [card=10,autodetected]
 IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
 bttv0: gpio: en=, out= in=00db [init]
 bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
 ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-1/1-0018/ir0 [bt878 #0 [sw]]
 i2c-adapter i2c-1: sendbytes: NAK bailout.
 tveeprom 1-0050: Huh, no eeprom present (err=-5)?
 tveeprom 1-0050: Encountered bad packet header [00]. Corrupt or not a 
 Hauppauge eeprom.
 bttv0: Hauppauge eeprom indicates model#0
 bttv0: tuner absent
 bttv0: registered device video0
 bttv0: registered device vbi0
 bttv0: PLL: 28636363 = 35468950

Hmm, my patch needs a bit more work. But to get your setup working try to
revert the change you made and do just this:

Go to drivers/media/video/Makefile and move this line:

obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o

in front of this line:

obj-$(CONFIG_VIDEO_BT848) += bt8xx/

Recompile and see if that is working.

I got the tveeprom error as well when I tested with ivtv, but I thought that
had something to do with the ivtv driver. Apparently not, so I need to dig a
bit more into these dependencies.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Mauro Carvalho Chehab
Em Thu, 11 Jun 2009 22:22:50 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
  On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
   Hi all,
   
   With Linux 2.6.30 the BTTV driver for my WinTV card claims
   
 bttv0: audio absent, no audio device found!
   
   and audio does not work. This worked up to and including 2.6.29. Is this a
   known issue? Does anyone have a fix or a patch for me to try?
  
  You've no doubt compiled the bttv driver into the kernel and not as a 
  module.
  
  I've just pushed a fix for this to my tree: 
  http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
 
 I've also attached a diff against 2.6.30 since the patch in my tree is against
 the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.


 # All i2c modules must come first:

Argh! this is an ugly solution. This can be an workaround for 2.6.30, but the
proper solution is to make sure that i2c core got initialized before any i2c
client.

Jean,

is there any patch meant to fix the usage of i2c when I2C and drivers are 
compiled with 'Y' ?




Cheers,
Mauro
--
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: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Hans Verkuil
On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
 Em Thu, 11 Jun 2009 22:22:50 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
  On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
   On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
Hi all,

With Linux 2.6.30 the BTTV driver for my WinTV card claims

bttv0: audio absent, no audio device found!

and audio does not work. This worked up to and including 2.6.29. Is 
this a
known issue? Does anyone have a fix or a patch for me to try?
   
   You've no doubt compiled the bttv driver into the kernel and not as a 
   module.
   
   I've just pushed a fix for this to my tree: 
   http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
  
  I've also attached a diff against 2.6.30 since the patch in my tree is 
  against
  the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.
 
 
  # All i2c modules must come first:
 
 Argh! this is an ugly solution. This can be an workaround for 2.6.30, but the
 proper solution is to make sure that i2c core got initialized before any i2c
 client.
 
 Jean,
 
 is there any patch meant to fix the usage of i2c when I2C and drivers are 
 compiled with 'Y' ?

No, the i2c core is initialized just fine, but the msp3400 module is later in
the init sequence than bttv. So when bttv initializes and tries to find and
init the msp3400 module it won't find it.

There is something weird going on with either the tveeprom module and/or the
ir-kbd-i2c module. I'm looking into that.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: s5h1411_readreg: readreg error (ret == -5)

2009-06-11 Thread Roger
On Thu, 2009-06-11 at 13:48 -0500, Mike Isely wrote:
 On Thu, 11 Jun 2009, Steven Toth wrote:
 
  Mike Isely wrote:
   On Sun, 7 Jun 2009, Roger wrote:
   
From looking at linux/drivers/media/dvb/frontends/s5h1411.c,  The
s5h1411_readreg wants to see 2 but is getting -5 from the i2c bus.

--- Snip ---

s5h1411_readreg: readreg error (ret == -5)
pvrusb2: unregistering DVB devices
device: 'dvb0.net0': device_unregister

--- Snip ---

What exactly does this mean?
   
   Roger:
   
   It means that the module attempted an I2C transfer and the transfer 
   failed.
   The I2C adapter within the pvrusb2 driver will return either the number of
   bytes that it transferred or a failure code.  The failure code, as is 
   normal
   convention in the kernel, will be a negated errno value.  Thus the 
   expected
   value of 2 would be the fact that it probably tried a 2 byte transfer, 
   while
   the actual value returned of -5 indicate an EIO error, which is what the
   pvrusb2 driver will return when the underlying I2C transaction has failed.
   
   Of course the real question is not that it failed but why it failed.  And
   for that I unfortunately do not have an answer.  It's possible that the
   s5h1411 driver did something that the chip didn't like and the chip
   responded by going deaf on the I2C bus.  More than a few I2C-driven parts
   can behave this way.  It's also possible that the part might have been 
   busy
   and unable to respond - but usually in that case the driver for such a 
   part
   will be written with this in mind and will know how / when to communicate
   with the hardware.
  
  Roger:
  
  Another possibility, although I don't know the PVRUSB2 driver too well, the
  s5h1411 is being held in reset when the driver unloads _AFTER_ the last 
  active
  use was analog video (assuming the s5h1411 is floated in reset as the FX2
  input port might be shared with the analog encoder)
 
 Good point.  The pvrusb2 driver is not currently doing anything specific 
 - or at least deliberate - via the FX2 to move that part in/out of 
 reset.  (Of course, I am issuing FX2 commands to shift modes and that 
 might in turn be triggering other things.)  But even if I did do 
 something specific, what kind of impact is that likely to do on the 
 corresponding, blissfully ignorant, driver?
 
 This actually drives towards a larger issue - the pvrusb2 driver works 
 with various V4L-only sub-devices, e.g. cx25840, which have no relevance 
 in digital mode but I can't really control when that corresponding 
 driver is enabled / disabled.  So if I have to take an extra step to 
 physically disable a chip when in digital mode, then this might impact 
 the sub-driver which otherwise is going to have no clue what is really 
 going on.
 
   -Mike
 
 
 -- 
 
 Mike Isely
 isely @ isely (dot) net
 PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8


Just a freak accidental view of dmesg, and I found it absolutely loaded
with the following repeated errors (until the point I reloaded the
pvrusb2 modules this morning along with the cold boot of the HVR-1950
usb device).

All I have to say is, I've never seen this many s5h1411 related errors
ever.  I've set options pvrusb2 debug=19.  So I think I'm onto
something?

reg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_readreg: readreg error (ret == -5)
s5h1411_writereg: writereg 

Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/

2009-06-11 Thread Trent Piepho
On Thu, 11 Jun 2009, Patrick Boettcher wrote:
 On Wed, 27 May 2009, Trent Piepho wrote:
  On Tue, 26 May 2009, Patrick Boettcher wrote:
  Does this patch to fix these problems look ok?

 In fact, everything looks correct in my eyes. I'll ask Mauro to pull any
 minute from now.

 I even have an explaination why the failing attach of the itd1000 was
 not errored out: when I did the development I was using a userspace
 proprietary driver to validate, for that I needed the demod to be
 attached...

 Thanks for cleaning up this mess.

Now that that patch is done, here is the rest of the series with dvb-pll
conversions.  There is an additional patch to the flexcop card detecting
code.  The #if defined(CONFIG_...) stuff didn't take into account code
being compiled into the kernel.

Here's the series:

01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b

02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7

03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a

04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90

05/08: b2c2: fix frontends compiled into kernel
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e

06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1

07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6

08/08: b2c2: Use dvb-pll for Cablestar2
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0


 b2c2/flexcop-fe-tuner.c |  283 +++-
 frontends/dvb-pll.c |   75 
 frontends/dvb-pll.h |4
 3 files changed, 172 insertions(+), 190 deletions(-)
--
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: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Udo A. Steinberg
On Thu, 11 Jun 2009 23:46:48 +0200 Hans Verkuil (HV) wrote:

HV Hmm, my patch needs a bit more work. But to get your setup working try to
HV revert the change you made and do just this:
HV 
HV Go to drivers/media/video/Makefile and move this line:
HV 
HV obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
HV 
HV in front of this line:
HV 
HV obj-$(CONFIG_VIDEO_BT848) += bt8xx/
HV 
HV Recompile and see if that is working.
HV 
HV I got the tveeprom error as well when I tested with ivtv, but I thought
HV that had something to do with the ivtv driver. Apparently not, so I need
HV to dig a bit more into these dependencies.

Switching those two lines seems to improve the dependencies for my setup.
However, audio still does not work. Furthermore, switching channels in
tvtime now hangs for up to 5 seconds. strace -r shows that it spends a lot
of time in the second ioctl.

0.85 ioctl(4, VIDIOC_G_TUNER, 0xbfef1d70) = 0
0.000385 select(5, [4], NULL, NULL, {3, 0}) = 1 (in [4], left {2, 988069})
0.012006 ioctl(4, VIDIOC_DQBUF, 0xbfef1dc4) = 0

The current dmesg output is as follows:

bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=, out= in=00db [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046
tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5)
tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 1-0050: audio processor is MSP3410D (idx 5)
tveeprom 1-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner 1-0042: chip found @ 0x84 (bt878 #0 [sw])
tda9887 1-0042: creating new instance
tda9887 1-0042: tda988[5/6/7] found
tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
msp3400 1-0040: MSP3410D-B4 found @ 0x80 (bt878 #0 [sw])
msp3400 1-0040: msp3400 supports nicam, mode is autodetect
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0

Cheers,

- Udo


signature.asc
Description: PGP signature


Re: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446

2009-06-11 Thread Alexey Klimov
Hello,

Very small suggestion, please see below.

On Thu, Jun 11, 2009 at 9:00 PM, m-kariche...@ti.com wrote:
 From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

 Re-sending since previous one missed a file (vpfe_types.h)

 VPFE Capture bridge driver

 This is version, v2 of vpfe capture bridge driver for doing video
 capture on DM355 and DM6446 evms. The ccdc hw modules register with the
 driver and are used for configuring the CCD Controller for a specific
 decoder interface. The driver also registers the sub devices required
 for a specific evm. More than one sub devices can be registered.
 This allows driver to switch dynamically to capture video from
 any sub device that is registered. Currently only one sub device
 (tvp5146) is supported. But in future this driver is expected
 to do capture from sensor devices such as Micron's MT9T001,MT9T031
 and MT9P031 etc. The driver currently supports MMAP based IO.

 Following are the updates based on review comments:-
        1) minor number is allocated dynamically
        2) updates to QUERYCAP handling
        3) eliminated intermediate vpfe pixel format
        4) refactored few functions
        5) reworked isr routines for reducing indentation
        6) reworked vpfe_check_format and added a documentation
           for algorithm
        7) fixed memory leak in probe()

 TODO list :
        1) load sub device from bridge driver. Hans has enhanced
        the v4l2-subdevice framework to do this. Will be updated
        soon to pick this.


 Reviewed By Hans Verkuil.
 Reviewed By Laurent Pinchart.

 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
 Applies to v4l-dvb repository

  drivers/media/video/davinci/vpfe_capture.c | 2252 
 
  include/media/davinci/vpfe_capture.h       |  183 +++
  include/media/davinci/vpfe_types.h         |   51 +
  3 files changed, 2486 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/davinci/vpfe_capture.c
  create mode 100644 include/media/davinci/vpfe_capture.h
  create mode 100644 include/media/davinci/vpfe_types.h


snip

 +/* vpfe capture driver file operations */
 +static struct v4l2_file_operations vpfe_fops = {
 +       .owner = THIS_MODULE,
 +       .open = vpfe_open,
 +       .release = vpfe_release,
 +       .ioctl = video_ioctl2,
 +       .mmap = vpfe_mmap,
 +       .poll = vpfe_poll
 +};
 +
 +/*
 + * vpfe_check_format()
 + * This function adjust the input pixel format as per hardware
 + * capabilities and update the same in pixfmt.
 + * Following algorithm used :-
 + *
 + *     If given pixformat is not in the vpfe list of pix formats or not
 + *     supported by the hardware, current value of pixformat in the device
 + *     is used
 + *     If given field is not supported, then current field is used. If field
 + *     is different from current, then it is matched with that from sub 
 device.
 + *     Minimum height is 2 lines for interlaced or tb field and 1 line for
 + *     progressive. Maximum height is clamped to active active lines of scan
 + *     Minimum width is 32 bytes in memory and width is clamped to active
 + *     pixels of scan.
 + *     bytesperline is a multiple of 32.
 + */
 +static const struct vpfe_pixel_format *
 +       vpfe_check_format(struct vpfe_device *vpfe_dev,
 +                         struct v4l2_pix_format *pixfmt)
 +{
 +       u32 min_height = 1, min_width = 32, max_width, max_height;
 +       const struct vpfe_pixel_format *vpfe_pix_fmt;
 +       u32 pix;
 +       int temp, found;
 +
 +       vpfe_pix_fmt = vpfe_lookup_pix_format(pixfmt-pixelformat);
 +       if (NULL == vpfe_pix_fmt) {
 +               /*
 +                * use current pixel format in the vpfe device. We
 +                * will find this pix format in the table
 +                */
 +               pixfmt-pixelformat = vpfe_dev-fmt.fmt.pix.pixelformat;
 +               vpfe_pix_fmt = vpfe_lookup_pix_format(pixfmt-pixelformat);
 +       }
 +
 +       /* check if hw supports it */
 +       temp = 0;
 +       found = 0;
 +       while (ccdc_dev-hw_ops.enum_pix(pix, temp) = 0) {
 +               if (vpfe_pix_fmt-fmtdesc.pixelformat == pix) {
 +                       found = 1;
 +                       break;
 +               }
 +               temp++;
 +       }
 +
 +       if (!found) {
 +               /* use current pixel format */
 +               pixfmt-pixelformat = vpfe_dev-fmt.fmt.pix.pixelformat;
 +               /*
 +                * Since this is currently used in the vpfe device, we
 +                * will find this pix format in the table
 +                */
 +               vpfe_pix_fmt = vpfe_lookup_pix_format(pixfmt-pixelformat);
 +       }
 +
 +       /* check what field format is supported */
 +       if (pixfmt-field == V4L2_FIELD_ANY) {
 +               /* if field is any, use current value as default */
 +               pixfmt-field = vpfe_dev-fmt.fmt.pix.field;
 +       }
 +
 +       /*
 +        * if field is 

Re: [PATCH] ov511.c: video_register_device() return zero on success

2009-06-11 Thread Mauro Carvalho Chehab
Em Thu, 11 Jun 2009 14:39:56 +0800
Figo.zhang figo1...@gmail.com escreveu:

 in v2, if insmod without specify 'unit_video', it use autodetect video device.
 if specify the 'unit_video', it will try to detect start from nr.
 
 Signed-off-by: Figo.zhang figo1...@gmail.com
 --- 
  drivers/media/video/ov511.c |   32 +---
  1 files changed, 17 insertions(+), 15 deletions(-)
 
 diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
 index 9af5532..293695f 100644
 --- a/drivers/media/video/ov511.c
 +++ b/drivers/media/video/ov511.c
 @@ -180,7 +180,7 @@ module_param(force_palette, int, 0);
  MODULE_PARM_DESC(force_palette, Force the palette to a specific value);
  module_param(backlight, int, 0);
  MODULE_PARM_DESC(backlight, For objects that are lit from behind);
 -static unsigned int num_uv;
 +static unsigned int num_uv = 0;

Never initialize a static var with 0. This just increases the module size. On
Linux, all static vars already initialized with 0.

  module_param_array(unit_video, int, num_uv, 0);
  MODULE_PARM_DESC(unit_video,
Force use of specific minor number(s). 0 is not allowed.);
 @@ -5845,22 +5845,24 @@ ov51x_probe(struct usb_interface *intf, const struct 
 usb_device_id *id)
   ov-vdev-parent = intf-dev;
   video_set_drvdata(ov-vdev, ov);
  
 - for (i = 0; i  OV511_MAX_UNIT_VIDEO; i++) {
 - /* Minor 0 cannot be specified; assume user wants autodetect */
 - if (unit_video[i] == 0)
 - break;
 -
 - if (video_register_device(ov-vdev, VFL_TYPE_GRABBER,
 - unit_video[i]) = 0) {
 - break;
 + /*if num_uv is zero, it autodetect*/
 + if(num_uv == 0){
 + if ((ov-vdev-minor == -1) 
 + video_register_device(ov-vdev, VFL_TYPE_GRABBER, -1)  
 0) {
 + err(video_register_device failed);
 + goto error;
   }
 - }
 + }else {
 + for (i = 0; i  num_uv; i++) {
 + /* Minor 0 cannot be specified; assume user wants 
 autodetect */
 + if (unit_video[i] == 0)
 + break;
  
 - /* Use the next available one */
 - if ((ov-vdev-minor == -1) 
 - video_register_device(ov-vdev, VFL_TYPE_GRABBER, -1)  0) {
 - err(video_register_device failed);
 - goto error;
 + if (video_register_device(ov-vdev, VFL_TYPE_GRABBER,
 + unit_video[i]) == 0) {
 + break;
 + }
 + }
   }
  
   dev_info(intf-dev, Device at %s registered to minor %d\n,
 
 

Thanks for the trial, but it is still broken (and also have lots of coding
style errors - Please always check your patches with checkpatch.pl).

Due to the hot plug/hot unplug nature of usb devices, the logic for it should
be more complex, since it should need to control the removal/reinsertion of a
device.

Since Douglas helped me with patchwork stuff (thanks, Douglas!), I found some
time for fixing it. Since I don't have any ov511 camera here, it would be nice
if people with this camera can do a review.

---

ov511: Fix unit_video parameter behavior

Fix a regression caused by changeset 9133:64aed7485a43 - v4l: disconnect kernel 
number from minor

Before the above changeset, ov511_probe used to allow forcing to use a certain
specific set of video devices, like:

modprobe ov511 unit_video=4,1,3 num_uv=3

So, assuming that you have 5 ov511 devices, and connect they one by one,
they'll gain the following device numbers (at the connection order):
/dev/video4
/dev/video1
/dev/video3
/dev/video0
/dev/video2

However, this was changed due to this change at video_register_device():

+ nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);

With the previous behavior, a trial to register on an already allocated mirror
would fail, and a loop would get the next requested minor. However, the current
behavior is to get the next available minor instead of failing. Due to that,
this means that the above modprobe parameter will give, instead:

/dev/video5
/dev/video6
/dev/video7
/dev/video8
/dev/video9

In order to restore the original behavior, a static var were added, storing the
amount of already registered devices.

While there, it also fixes the locking of the probe/disconnect functions.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/linux/drivers/media/video/ov511.c 
b/linux/drivers/media/video/ov511.c
--- a/linux/drivers/media/video/ov511.c
+++ b/linux/drivers/media/video/ov511.c
@@ -112,6 +112,8 @@ static int framedrop= -1;
 static int fastset;
 static int force_palette;
 static int backlight;
+/* Bitmask marking allocated devices from 0 to OV511_MAX_UNIT_VIDEO */
+static unsigned long ov511_devused;
 static int unit_video[OV511_MAX_UNIT_VIDEO];
 static int remove_zeros;
 

Re: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Hans Verkuil
On Friday 12 June 2009 00:35:26 Udo A. Steinberg wrote:
 On Thu, 11 Jun 2009 23:46:48 +0200 Hans Verkuil (HV) wrote:
 
 HV Hmm, my patch needs a bit more work. But to get your setup working try to
 HV revert the change you made and do just this:
 HV 
 HV Go to drivers/media/video/Makefile and move this line:
 HV 
 HV obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
 HV 
 HV in front of this line:
 HV 
 HV obj-$(CONFIG_VIDEO_BT848) += bt8xx/
 HV 
 HV Recompile and see if that is working.
 HV 
 HV I got the tveeprom error as well when I tested with ivtv, but I thought
 HV that had something to do with the ivtv driver. Apparently not, so I need
 HV to dig a bit more into these dependencies.
 
 Switching those two lines seems to improve the dependencies for my setup.
 However, audio still does not work. Furthermore, switching channels in
 tvtime now hangs for up to 5 seconds. strace -r shows that it spends a lot
 of time in the second ioctl.
 
 0.85 ioctl(4, VIDIOC_G_TUNER, 0xbfef1d70) = 0
 0.000385 select(5, [4], NULL, NULL, {3, 0}) = 1 (in [4], left {2, 988069})
 0.012006 ioctl(4, VIDIOC_DQBUF, 0xbfef1dc4) = 0
 
 The current dmesg output is as follows:
 
 bttv: driver version 0.9.18 loaded
 bttv: using 8 buffers with 2080k (520 pages) each for capture
 bttv: Bt8xx card found (0).
 bttv :06:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
 bttv0: Bt878 (rev 2) at :06:00.0, irq: 21, latency: 32, mmio: 0x50001000
 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
 bttv0: using: Hauppauge (bt878) [card=10,autodetected]
 IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
 bttv0: gpio: en=, out= in=00db [init]
 bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
 tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046
 tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5)
 tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04)
 tveeprom 1-0050: audio processor is MSP3410D (idx 5)
 tveeprom 1-0050: has radio
 bttv0: Hauppauge eeprom indicates model#37284
 bttv0: tuner type=5
 tuner 1-0042: chip found @ 0x84 (bt878 #0 [sw])
 tda9887 1-0042: creating new instance
 tda9887 1-0042: tda988[5/6/7] found
 tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw])
 tuner-simple 1-0061: creating new instance
 tuner-simple 1-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 msp3400 1-0040: MSP3410D-B4 found @ 0x80 (bt878 #0 [sw])
 msp3400 1-0040: msp3400 supports nicam, mode is autodetect
 bttv0: registered device video0
 bttv0: registered device vbi0
 bttv0: registered device radio0

Hmm, this looks OK.

I've fixed the problem in my original patch. I've attached the new version.
It works fine with ivtv, the problems with reading the eeprom are now
fixed. Please test and if it still doesn't work then I'll have to install
my bttv card in my PC and test again. But that will be tomorrow evening.

BTW, it would be nice if you can confirm that everything is working fine
if you compile bttv as a module. Just to make sure that this is related
to the in-kernel build. The other person who had this problem (and who
had a very similar card) said that it was working after moving that line
in the Makefile.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--- drivers/media/video/Makefile.org	2009-06-11 21:51:05.0 +0200
+++ drivers/media/video/Makefile	2009-06-12 00:45:46.0 +0200
@@ -12,6 +12,8 @@
 
 videodev-objs	:=	v4l2-dev.o v4l2-ioctl.o v4l2-device.o
 
+# V4L2 core modules
+
 obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o
 ifeq ($(CONFIG_COMPAT),y)
   obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o
@@ -23,21 +25,15 @@
   obj-$(CONFIG_VIDEO_DEV) += v4l1-compat.o
 endif
 
-obj-$(CONFIG_VIDEO_TUNER) += tuner.o
+# All i2c modules must come first:
 
-obj-$(CONFIG_VIDEO_BT848) += bt8xx/
-obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_TUNER) += tuner.o
 obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_TDA9875) += tda9875.o
-
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_SAA5246A) += saa5246a.o
 obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o
-obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o
-obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o
-obj-$(CONFIG_VIDEO_W9966) += w9966.o
-
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
@@ -54,11 +50,40 @@
 obj-$(CONFIG_VIDEO_BT856) += bt856.o
 obj-$(CONFIG_VIDEO_BT866) += bt866.o
 obj-$(CONFIG_VIDEO_KS0127) += ks0127.o
+obj-$(CONFIG_VIDEO_VINO) += indycam.o
+obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
+obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
+obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
+obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
+obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
+obj-$(CONFIG_VIDEO_M52790) += m52790.o
+obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o
+obj-$(CONFIG_VIDEO_WM8775) += wm8775.o

Re: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Mauro Carvalho Chehab
Em Fri, 12 Jun 2009 00:26:13 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
  Em Thu, 11 Jun 2009 22:22:50 +0200
  Hans Verkuil hverk...@xs4all.nl escreveu:
  
   On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
 Hi all,
 
 With Linux 2.6.30 the BTTV driver for my WinTV card claims
 
   bttv0: audio absent, no audio device found!
 
 and audio does not work. This worked up to and including 2.6.29. Is 
 this a
 known issue? Does anyone have a fix or a patch for me to try?

You've no doubt compiled the bttv driver into the kernel and not as a 
module.

I've just pushed a fix for this to my tree: 
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
   
   I've also attached a diff against 2.6.30 since the patch in my tree is 
   against
   the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.
  
  
   # All i2c modules must come first:
  
  Argh! this is an ugly solution. This can be an workaround for 2.6.30, but 
  the
  proper solution is to make sure that i2c core got initialized before any i2c
  client.
  
  Jean,
  
  is there any patch meant to fix the usage of i2c when I2C and drivers are 
  compiled with 'Y' ?
 
 No, the i2c core is initialized just fine,

I remember I had to commit a patch moving drivers/media to be compiled after to
i2c core due to a similar problem (git changeset 
a357482a1e8fdd39f0a58c33ed2ffd0f1becb825).

 but the msp3400 module is later in
 the init sequence than bttv. So when bttv initializes and tries to find and
 init the msp3400 module it won't find it.

 
 There is something weird going on with either the tveeprom module and/or the
 ir-kbd-i2c module. I'm looking into that.

I suspect that we'll need to work with the initialization order after the new
i2c binding model to avoid such troubles.

I remember that we had a similar issue with alsa and saa7134. At the end, Linus 
[1]
had to do add this, as a quick hack (unfortunately, it is still there - it
seems that alsa guys forgot about that issue):

late_initcall(saa7134_alsa_init);

On that time, he suggested the usage of subsys_initcall() for alsa. I suspect
that we'll need to do the same for I2C and for V4L core. I'm not sure what
would be the alternative to be done with i2c ancillary drivers.

Maybe one alternative would be to use fs_initcall, that seems to be already
used by some non-fs related calls, like cpu governor [2].

[1] http://lkml.org/lkml/2007/3/23/285
[2] http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?i=fs_initcall


Cheers,
Mauro
--
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: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Hans Verkuil
On Friday 12 June 2009 01:07:46 Mauro Carvalho Chehab wrote:
 Em Fri, 12 Jun 2009 00:26:13 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
  On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
   Em Thu, 11 Jun 2009 22:22:50 +0200
   Hans Verkuil hverk...@xs4all.nl escreveu:
   
On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
 On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
  Hi all,
  
  With Linux 2.6.30 the BTTV driver for my WinTV card claims
  
  bttv0: audio absent, no audio device found!
  
  and audio does not work. This worked up to and including 2.6.29. Is 
  this a
  known issue? Does anyone have a fix or a patch for me to try?
 
 You've no doubt compiled the bttv driver into the kernel and not as a 
 module.
 
 I've just pushed a fix for this to my tree: 
 http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

I've also attached a diff against 2.6.30 since the patch in my tree is 
against
the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.
   
   
# All i2c modules must come first:
   
   Argh! this is an ugly solution. This can be an workaround for 2.6.30, but 
   the
   proper solution is to make sure that i2c core got initialized before any 
   i2c
   client.
   
   Jean,
   
   is there any patch meant to fix the usage of i2c when I2C and drivers are 
   compiled with 'Y' ?
  
  No, the i2c core is initialized just fine,
 
 I remember I had to commit a patch moving drivers/media to be compiled after 
 to
 i2c core due to a similar problem (git changeset 
 a357482a1e8fdd39f0a58c33ed2ffd0f1becb825).
 
  but the msp3400 module is later in
  the init sequence than bttv. So when bttv initializes and tries to find and
  init the msp3400 module it won't find it.
 
  
  There is something weird going on with either the tveeprom module and/or the
  ir-kbd-i2c module. I'm looking into that.
 
 I suspect that we'll need to work with the initialization order after the new
 i2c binding model to avoid such troubles.
 
 I remember that we had a similar issue with alsa and saa7134. At the end, 
 Linus [1]
 had to do add this, as a quick hack (unfortunately, it is still there - it
 seems that alsa guys forgot about that issue):
 
 late_initcall(saa7134_alsa_init);
 
 On that time, he suggested the usage of subsys_initcall() for alsa. I suspect
 that we'll need to do the same for I2C and for V4L core. I'm not sure what
 would be the alternative to be done with i2c ancillary drivers.
 
 Maybe one alternative would be to use fs_initcall, that seems to be already
 used by some non-fs related calls, like cpu governor [2].

As long as the i2c modules come first there shouldn't be any problem. That's
pretty easy to arrange. So the i2c core inits first, then i2c drivers, then
v4l2 drivers. That's the proper order.

The ir-kbd-i2c module needed to be after the v4l2 modules since that still
relies on autoprobing. If it comes first, then it seems to mess up tveeprom
for some reason. Once ir-kbd-i2c no longer does autoprobing, then it probably
should move back to the other i2c modules.

Regards,

Hans

 
 [1] http://lkml.org/lkml/2007/3/23/285
 [2] http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?i=fs_initcall
 
 
 Cheers,
 Mauro
 
 ___
 v4l-dvb-maintainer mailing list
 v4l-dvb-maintai...@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
 
 



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 10/10 - v2] common vpss module for video drivers

2009-06-11 Thread Alexey Klimov
Hello,

On Thu, Jun 11, 2009 at 9:00 PM, m-kariche...@ti.com wrote:
 From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com

 common voss module for video drivers

 This is a new module added for vpss library functions that are
 used for configuring vpss system module. All video drivers will
 include vpss.h header file and call functions defined in this
 module to configure vpss system module.


 Reviewed By Hans Verkuil.
 Reviewed By Laurent Pinchart.

 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
  drivers/media/video/davinci/vpss.c |  290 
 
  include/media/davinci/vpss.h       |   69 +
  2 files changed, 359 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/davinci/vpss.c
  create mode 100644 include/media/davinci/vpss.h

 diff --git a/drivers/media/video/davinci/vpss.c 
 b/drivers/media/video/davinci/vpss.c
 new file mode 100644
 index 000..def021e
 --- /dev/null
 +++ b/drivers/media/video/davinci/vpss.c
 @@ -0,0 +1,290 @@
 +/*
 + * Copyright (C) 2009 Texas Instruments.
 + *
 + * 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; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 + *
 + * common vpss driver for all video drivers.
 + */
 +#include linux/kernel.h
 +#include linux/sched.h
 +#include linux/init.h
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/spinlock.h
 +#include linux/compiler.h
 +#include linux/io.h
 +#include mach/hardware.h
 +#include media/davinci/vpss.h
 +
 +/* DM644x defines */
 +#define DM644X_SBL_PCR_VPSS            (4)
 +
 +/* vpss BL register offsets */
 +#define DM355_VPSSBL_CCDCMUX           0x1c
 +/* vpss CLK register offsets */
 +#define DM355_VPSSCLK_CLKCTRL          0x04
 +/* masks and shifts */
 +#define VPSS_HSSISEL_SHIFT             4
 +
 +/*
 + * vpss operations. Depends on platform. Not all functions are available
 + * on all platforms. The api, first check if a functio is available before
 + * invoking it. In the probe, the function ptrs are intialized based on
 + * vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
 + */
 +struct vpss_hw_ops {
 +       /* enable clock */
 +       int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
 +       /* select input to ccdc */
 +       void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
 +       /* clear wbl overlflow bit */
 +       int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
 +};
 +
 +/* vpss configuration */
 +struct vpss_oper_config {
 +       __iomem void *vpss_bl_regs_base;
 +       __iomem void *vpss_regs_base;
 +       struct resource         *r1;
 +       resource_size_t         len1;
 +       struct resource         *r2;
 +       resource_size_t         len2;
 +       char vpss_name[32];
 +       spinlock_t vpss_lock;
 +       struct vpss_hw_ops hw_ops;
 +};
 +
 +static struct vpss_oper_config oper_cfg;
 +
 +/* register access routines */
 +static inline u32 bl_regr(u32 offset)
 +{
 +       return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
 +}
 +
 +static inline void bl_regw(u32 val, u32 offset)
 +{
 +       __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
 +}
 +
 +static inline u32 vpss_regr(u32 offset)
 +{
 +       return __raw_readl(oper_cfg.vpss_regs_base + offset);
 +}
 +
 +static inline void vpss_regw(u32 val, u32 offset)
 +{
 +       __raw_writel(val, oper_cfg.vpss_regs_base + offset);
 +}
 +
 +static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
 +{
 +       bl_regw(src_sel  VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
 +}
 +
 +int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
 +{
 +       if (!oper_cfg.hw_ops.select_ccdc_source)
 +               return -1;
 +
 +       dm355_select_ccdc_source(src_sel);
 +       return 0;
 +}
 +EXPORT_SYMBOL(vpss_select_ccdc_source);
 +
 +static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
 +{
 +       u32 mask = 1, val;
 +
 +       if (wbl_sel  VPSS_PCR_AEW_WBL_0 ||
 +           wbl_sel  VPSS_PCR_CCDC_WBL_O)
 +               return -1;
 +
 +       /* writing a 0 clear the overflow */
 +       mask = ~(mask  wbl_sel);
 +       val = bl_regr(DM644X_SBL_PCR_VPSS)  mask;
 +       bl_regw(val, DM644X_SBL_PCR_VPSS);
 +       return 0;
 +}
 +
 +int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
 +{
 +       if (!oper_cfg.hw_ops.clear_wbl_overflow)
 +      

Re: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

2009-06-11 Thread Udo A. Steinberg
On Fri, 12 Jun 2009 01:01:59 +0200 Hans Verkuil (HV) wrote:

HV I've fixed the problem in my original patch. I've attached the new
HV version. It works fine with ivtv, the problems with reading the eeprom
HV are now fixed. Please test and if it still doesn't work then I'll have
HV to install my bttv card in my PC and test again. But that will be
HV tomorrow evening.

Reading the eeprom works with your patch.

HV BTW, it would be nice if you can confirm that everything is working fine
HV if you compile bttv as a module. Just to make sure that this is related
HV to the in-kernel build. The other person who had this problem (and who
HV had a very similar card) said that it was working after moving that line
HV in the Makefile.

That works, too.

Meanwhile I've figured out that the audio problems are related to ALSA. The
BTTV audio signal is fed via a cable to the line-in of my on-board sound.
I've verified that there is audio going over that cable. So I'll talk to the
ALSA folks about the issue.

Thanks for your help, Hans.

Cheers,

- Udo


signature.asc
Description: PGP signature


GPL code for Omnivision USB video camera available.

2009-06-11 Thread Erik de Castro Lopo
Hi all,

I have a driver for a USB video camera that I'd like to see added to
the mainline kernel, mainly so I don't have to fix breakage due to
constant changes in the kernel :-).

The code is GPL and is available here:

http://stage.bcode.com/erikd/ovcamchip

and the history of this code is here:

http://stage.bcode.com/erikd/ovcamchip/README

My problem is that I am way too busy to sheperd this into the kernel
myself. If someone is willing to work on getting this in, I can send
them a camera to keep. If getting paid is more likely to help someone
focus on the task then that is also a possibility.

Any takers? Please email me privately.

Cheers,
Erik
-- 
===
erik de castro lopo
senior design engineer

bCODE
level 2, 2a glen street
milsons point
sydney nsw 2061
australia

tel +61 (0)2 9954 4411
fax +61 (0)2 9954 4422
www.bcode.com
--
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 3/4] soc-camera: add support for camera-host controls

2009-06-11 Thread Dongsoo, Nathaniel Kim
Hello Guennadi,

So let's assume that camera interface device can process
V4L2_CID_SHARPNESS and even external camera device can process that,
then according to your patch both of camera interface and external
camera device can be issued to process V4L2_CID_SHARPNESS which I
guess will make image sharpened twice. Am I getting the patch right?

If I'm getting right, it might be better to give user make a choice
through platform data or some sort of variable which can make a choice
between camera interface and camera device to process the CID. It
could be just in aspect of manufacturer mind, we do love to make a
choice between same features in different devices in easy way. So
never mind if my idea is not helpful making your driver elegant :-)
Cheers,

Nate


On Thu, Jun 11, 2009 at 9:16 PM, Guennadi
Liakhovetskig.liakhovet...@gmx.de wrote:
 On Thu, 11 Jun 2009, Dongsoo, Nathaniel Kim wrote:

 Hello Guennadi,

 It's a very interesting patch. Actually some camera interfaces support
 for various image effects and I was wondering how to use them in SoC
 camera subsystem.

 But here is a question. Is it possible to make a choice with the same
 CID between icd and ici? I mean, if both of camera interface and
 camera device are supporting for same CID how can user select any of
 them to use? Sometimes, some image effects supported by camera
 interface are not good so I want to use the same effect supported by
 external camera ISP device.

 I think, it might be possible but I can't see how.

  @@ -681,9 +698,16 @@ static int soc_camera_s_ctrl(struct file *file, void 
  *priv,
         struct soc_camera_file *icf = file-private_data;
         struct soc_camera_device *icd = icf-icd;
         struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
  +       int ret;
 
         WARN_ON(priv != file-private_data);
 
  +       if (ici-ops-set_ctrl) {
  +               ret = ici-ops-set_ctrl(icd, ctrl);
  +               if (ret != -ENOIOCTLCMD)
  +                       return ret;
  +       }
  +
         return v4l2_device_call_until_err(ici-v4l2_dev, (__u32)icd, core, 
  s_ctrl, ctrl);
   }

 Should be easy to see in the patch. Host's s_ctrl is called first. It can
 return -ENOIOCTLCMD then sensor's control will be called too. Ot the host
 may choose to call sensor's control itself, which, however, is
 discouraged.

 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/




-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.com
--
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