RFC: PATCH: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls
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
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
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
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
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
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
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
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
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
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
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
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
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)
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/
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)
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
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
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
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
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)
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
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
Re: [PATCH] soc_camera: Fix debug output of supported formats count
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
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
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
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
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
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
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
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
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
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)
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)
- 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)
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)
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)
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
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
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
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
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
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
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
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
Re: Terratec DT USB XS Diversity/DiB0070+vdr: URB status: Value too large for defined data type+USB reset
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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/
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
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
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
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
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
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
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
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
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.
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
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
