Re: tcm825x.c: migrating to sub-device framework?
Hans Verkuil wrote: On Sunday 14 June 2009 14:44:53 Hans Verkuil wrote: On Sunday 14 June 2009 12:14:38 Hans Verkuil wrote: On Wednesday 06 May 2009 20:31:33 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com This patch converts TVP514x driver to sub-device framework from V4L2-int framework. Now that tvp514x is converted to using v4l2_subdev (pending a few small final tweaks) there is only one driver left that uses the v4l2-int-device.h API: tcm825x.c. There's also the OMAP 2 camera driver (master), drivers/media/video/omap24xxcam.c. The tcm825x is the slave driver that is used in conjunction with omap24xxcam on N800 and N810. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: dib3000mc.c and dib7000p.c compiler warnings
Hi Hans, On Sun, 14 Jun 2009, Hans Verkuil wrote: Hi Patrick, The daily build reports these warnings for dib3000mc.c and dib7000p.c: /marune/build/v4l-dvb-master/v4l/dib3000mc.c: In function 'dib3000mc_i2c_enumeration': /marune/build/v4l-dvb-master/v4l/dib3000mc.c:863: warning: the frame size of 1508 bytes is larger than 1024 bytes /marune/build/v4l-dvb-master/v4l/dib7000p.c: In function 'dib7000p_i2c_enumeration': /marune/build/v4l-dvb-master/v4l/dib7000p.c:1341: warning: the frame size of 1568 bytes is larger than 1024 bytes In both cases a big state struct is allocated on the stack. Would it be possible to optimize that? I agree that this is ugly and in fact I already have a solution for that. But it's not ready as a patch nor can it published :(. I won't be able to work on it before mid-July. But then I will provide a solution. thanks for raising this important problem, 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: Fwd: [PATCH 2/2] uvc: Added two webcams with 'No FID' quirk.
On Friday 12 June 2009 18:53:29 Robert Krakora wrote:
From: Robert Krakora rob.krak...@messagenetsystems.com
Added two webcams with 'No FID' quirk.
Priority: normal
Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com
diff -r bff77ec33116 linux/drivers/media/video/uvc/uvc_driver.c
--- a/linux/drivers/media/video/uvc/uvc_driver.cThu Jun 11
18:44:23 2009 -0300
+++ b/linux/drivers/media/video/uvc/uvc_driver.cFri Jun 12
11:35:04 2009 -0400
@@ -1919,6 +1919,24 @@
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_STREAM_NO_FID },
+ /* Suyin Corp. HP Webcam */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x064e,
+ .idProduct= 0xa110,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_STREAM_NO_FID },
+ /* Creative Live! Cam Optia AF */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x041e,
+ .idProduct= 0x406d,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_STREAM_NO_FID },
NAK. Those cameras have been reported to work without the FID quirk. Please
double-check. If the quirk is required on your side I'd like to see logs.
Best regards,
Laurent Pinchart
--
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/2] uvc: Fix for no return value check of uvc_ctrl_set() which calls mutex_lock_interruptible()
On Friday 12 June 2009 18:51:03 Robert Krakora wrote: From: Robert Krakora rob.krak...@messagenetsystems.com Fix for no return value check of uvc_ctrl_set() which calls mutex_lock_interruptible(). Priority: normal Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com Acked-by: Laurent Pinchart laurent.pinch...@skynet.be I'd appreciate if you would at least CC me when submitting patches related to the Linux UVC driver in the future. Regards, Laurent Pinchart -- 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
RFC: remove video_register_device_index, add video_register_device_range
Hi all, While looking at the video_register_device changes that broke ov511 I realized that the video_register_device_index function is never called from drivers. It will always assign a default index number. I also don't see a good use-case for giving it an explicit index. My proposal is to remove this API. Since it is never called, nothing will change effectively. I'm never happy with unused functions. However, I think we do need a new video_register_device_range function. This would be identical to video_register_device, but with an additional count argument: this allows drivers to select a kernel number in the range of nr to nr + count - 1. If cnt == -1, then the maximum is the compiled-in maximum. So video_register_device would call video_register_device_range(...nr, 1), thus restoring the original behavior, while ivtv and cx18 can call video_register_device_range(...nr, -1), thus keeping the current behavior. Comments? 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: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Em Thu, 11 Jun 2009 15:35:14 -0700 (PDT) Trent Piepho xy...@speakeasy.org escreveu: 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 Nice patches. Are those tested with real cards? In particular, I loved this: +/* Can we use the specified front-end? Remember that if we are compiled + * into the kernel we can't call code that's in modules. */ +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ + (defined(CONFIG_DVB_##fe##_MODULE) defined(MODULE))) IMO, you should add it on a dvb core header. Then, a cleanup patch would be to simplify all those frontend tests all over all the dvb drivers code. Patrick, I think you have some skystar boards. I'd appreciate if you can review those patches before applying it. 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 V2] poll method lose race condition
hi Mauro,
is it ok for this v2?
Best Regards,
Figo.zhang
2009/6/1 Figo.zhang figo1...@gmail.com
bttv-driver.c,cx23885-video.c,cx88-video.c: poll method lose
race condition for capture video.
In v2, use the clear logic.Thanks to Trent Piepho's help.
Signed-off-by: Figo.zhang figo1...@gmail.com
---
drivers/media/video/bt8xx/bttv-driver.c | 20
drivers/media/video/cx23885/cx23885-video.c | 15
+++
drivers/media/video/cx88/cx88-video.c | 15
+++
3 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index 23b7499..8d20528 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -3152,6 +3152,7 @@ static unsigned int bttv_poll(struct
file *file, poll_table *wait)
struct bttv_fh *fh = file-private_data;
struct bttv_buffer *buf;
enum v4l2_field field;
+ unsigned int rc = POLLERR;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!
check_alloc_btres(fh-btv,fh,RESOURCE_VBI))
@@ -3160,9 +3161,10 @@ static unsigned int bttv_poll(struct
file *file, poll_table *wait)
}
if (check_btres(fh,RESOURCE_VIDEO_STREAM)) {
+ mutex_lock(fh-cap.vb_lock);
/* streaming capture */
if (list_empty(fh-cap.stream))
- return POLLERR;
+ return done;
buf = list_entry(fh-cap.stream.next,struct
bttv_buffer,vb.stream);
} else {
/* read() capture */
@@ -3170,16 +3172,16 @@ static unsigned int bttv_poll(struct
file *file, poll_table *wait)
if (NULL == fh-cap.read_buf) {
/* need to capture a new frame */
if
(locked_btres(fh-btv,RESOURCE_VIDEO_STREAM))
- goto err;
+ goto done;
fh-cap.read_buf =
videobuf_sg_alloc(fh-cap.msize);
if (NULL == fh-cap.read_buf)
- goto err;
+ goto done;
fh-cap.read_buf-memory =
V4L2_MEMORY_USERPTR;
field = videobuf_next_field(fh-cap);
if (0 !=
fh-cap.ops-buf_prepare(fh-cap,fh-cap.read_buf,field)) {
kfree (fh-cap.read_buf);
fh-cap.read_buf = NULL;
- goto err;
+ goto done;
}
fh-cap.ops-buf_queue(fh-cap,fh-cap.read_buf);
fh-cap.read_off = 0;
@@ -3191,11 +3193,13 @@ static unsigned int bttv_poll(struct
file *file, poll_table *wait)
poll_wait(file, buf-vb.done, wait);
if (buf-vb.state == VIDEOBUF_DONE ||
buf-vb.state == VIDEOBUF_ERROR)
- return POLLIN|POLLRDNORM;
- return 0;
-err:
+ rc = POLLIN|POLLRDNORM;
+ else
+ rc = 0;
+
+done:
mutex_unlock(fh-cap.vb_lock);
- return POLLERR;
+ return rc;
}
static int bttv_open(struct file *file)
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 68068c6..f542493 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -796,6 +796,7 @@ static unsigned int video_poll(struct file
*file,
{
struct cx23885_fh *fh = file-private_data;
struct cx23885_buffer *buf;
+ unsigned int rc = POLLERR;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!res_get(fh-dev, fh, RESOURCE_VBI))
@@ -803,23 +804,29 @@ static unsigned int video_poll(struct
file *file,
return videobuf_poll_stream(file, fh-vbiq,
wait);
}
+ mutex_lock(fh-vidq.vb_lock);
if (res_check(fh, RESOURCE_VIDEO)) {
Re: RFC: remove video_register_device_index, add video_register_device_range
Em Mon, 15 Jun 2009 13:25:28 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi all,
While looking at the video_register_device changes that broke ov511 I realized
that the video_register_device_index function is never called from drivers. It
will always assign a default index number. I also don't see a good use-case
for giving it an explicit index. My proposal is to remove this API. Since it
is never called, nothing will change effectively. I'm never happy with unused
functions.
It sounds ok to me.
However, I think we do need a new video_register_device_range function. This
would be identical to video_register_device, but with an additional count
argument: this allows drivers to select a kernel number in the range of
nr to nr + count - 1. If cnt == -1, then the maximum is the compiled-in
maximum.
So video_register_device would call video_register_device_range(...nr, 1),
thus restoring the original behavior, while ivtv and cx18 can call
video_register_device_range(...nr, -1), thus keeping the current behavior.
I don't think that this is needed. The issue with ov511 is that it was using
the error condition of video_register to identify how much ov511 devices were
already registered.
I already fixed it by adding an explicit device number count on it, just like
all the other drivers. With this, ov511 will behave like the other drivers.
With the current implementation, it should honor the explicit minor order
passed via modprobe parameter, as before.
There's one small change on the behavior that it is also present on all other
devices that allow users to explicit the desired minor order: instead of
failing if that device is already used, it will get the next available one.
IMO, this is better than just failing. So, the only remaining issue is that
video_register should print a warning if it had to get a different minor than
specified.
In other words, the enclosed patch seems to be a good approach to close this
issue
Cheers,
Mauro
---
v4l2-dev: Print a warning if need to use a different minor than specified
From: Mauro Carvalho Chehab mche...@redhat.com
video_register_device has two behaviors: dynamic minor attribution or
forced minor attribution. The latter mode is used to allow users to
force probing a device using a certain minor order. Even for the last
case, video_register_device won't fail if that minor is already used
but, instead, it will seek for the next available minor, without warning
users about that.
While don't fail due to a busy minor seems the better behavior, it
should be printing a warning when this happen.
While here, let's remove video_register_device_index(), since no driver
is using it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
linux/drivers/media/video/v4l2-dev.c | 31 ---
linux/include/media/v4l2-dev.h |5 ++---
2 files changed, 18 insertions(+), 18 deletions(-)
--- master.orig/linux/drivers/media/video/v4l2-dev.c
+++ master/linux/drivers/media/video/v4l2-dev.c
@@ -384,23 +384,18 @@ static int get_index(struct video_device
return i == VIDEO_NUM_DEVICES ? -ENFILE : i;
}
-int video_register_device(struct video_device *vdev, int type, int nr)
-{
- return video_register_device_index(vdev, type, nr, -1);
-}
-EXPORT_SYMBOL(video_register_device);
/**
- * video_register_device_index - register video4linux devices
+ * video_register_device - register video4linux devices
* @vdev: video device structure we want to register
* @type: type of device to register
* @nr: which device number (0 == /dev/video0, 1 == /dev/video1, ...
* -1 == first free)
- * @index: stream number based on parent device;
- * -1 if auto assign, requested number otherwise
*
* The registration code assigns minor numbers based on the type
- * requested. -ENFILE is returned in all the device slots for this
+ * requested. If the requested one is already used, get the next
+ * available one and prints a warning.
+ * -ENFILE is returned in all the device slots for this
* category are full. If not then the minor field is set and the
* driver initialize function is called (if non %NULL).
*
@@ -416,10 +411,10 @@ EXPORT_SYMBOL(video_register_device);
*
* %VFL_TYPE_RADIO - A radio card
*/
-int video_register_device_index(struct video_device *vdev, int type, int nr,
- int index)
+int video_register_device(struct video_device *vdev, const int type,
+ const int desirednr)
{
- int i = 0;
+ int i = 0, nr;
int ret;
int minor_offset = 0;
int minor_cnt = VIDEO_NUM_DEVICES;
@@ -493,7 +488,8 @@ int video_register_device_index(struct v
/* Pick a minor number */
mutex_lock(videodev_lock);
- nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
+ nr =
Re: RFC: remove video_register_device_index, add video_register_device_range
On Monday 15 June 2009 15:44:21 Mauro Carvalho Chehab wrote:
Em Mon, 15 Jun 2009 13:25:28 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi all,
While looking at the video_register_device changes that broke ov511 I
realized
that the video_register_device_index function is never called from drivers.
It
will always assign a default index number. I also don't see a good use-case
for giving it an explicit index. My proposal is to remove this API. Since it
is never called, nothing will change effectively. I'm never happy with
unused
functions.
It sounds ok to me.
However, I think we do need a new video_register_device_range function. This
would be identical to video_register_device, but with an additional count
argument: this allows drivers to select a kernel number in the range of
nr to nr + count - 1. If cnt == -1, then the maximum is the compiled-in
maximum.
So video_register_device would call video_register_device_range(...nr, 1),
thus restoring the original behavior, while ivtv and cx18 can call
video_register_device_range(...nr, -1), thus keeping the current behavior.
I don't think that this is needed. The issue with ov511 is that it was using
the error condition of video_register to identify how much ov511 devices were
already registered.
I already fixed it by adding an explicit device number count on it, just like
all the other drivers. With this, ov511 will behave like the other drivers.
With the current implementation, it should honor the explicit minor order
passed via modprobe parameter, as before.
There's one small change on the behavior that it is also present on all other
devices that allow users to explicit the desired minor order: instead of
failing if that device is already used, it will get the next available one.
IMO, this is better than just failing. So, the only remaining issue is that
video_register should print a warning if it had to get a different minor than
specified.
The sticking point for me is that warning since for cx18/ivtv it is OK if you
get something else then you specified (since it is a starting index meant to
distinguish mpeg encoders from raw video inputs, from mpeg decoders, etc.).
So generating a warning for those two drivers is not correct.
Perhaps we should add a V4L2_FL_KNUM_OFFSET flag for the struct video_device
flags field that tell the register function that 'nr' should be interpreted
as a kernel number offset, and not as a preferred number. In the latter case
you generate a warning, in the first case you don't.
I think it isn't a bad idea to use a flag. It reflects the two possible use
cases: one for drivers that create multiple video (or vbi) devices and use the
kernel number to reflect the purpose of each video device, and the other where
the user wants a specific kernel number. In the latter case the driver creates
a single video device.
I don't want to see a lot of kernel warnings each time an ivtv or cx18 driver
is loaded. Those warnings do not apply to those drivers.
BTW: please note that my v4l-dvb-misc tree contains a patch to clean up the
comments/variable names in v4l2-dev.c. You might want to pull that in first.
Regards,
Hans
In other words, the enclosed patch seems to be a good approach to close this
issue
Cheers,
Mauro
---
v4l2-dev: Print a warning if need to use a different minor than specified
From: Mauro Carvalho Chehab mche...@redhat.com
video_register_device has two behaviors: dynamic minor attribution or
forced minor attribution. The latter mode is used to allow users to
force probing a device using a certain minor order. Even for the last
case, video_register_device won't fail if that minor is already used
but, instead, it will seek for the next available minor, without warning
users about that.
While don't fail due to a busy minor seems the better behavior, it
should be printing a warning when this happen.
While here, let's remove video_register_device_index(), since no driver
is using it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
linux/drivers/media/video/v4l2-dev.c | 31 ---
linux/include/media/v4l2-dev.h |5 ++---
2 files changed, 18 insertions(+), 18 deletions(-)
--- master.orig/linux/drivers/media/video/v4l2-dev.c
+++ master/linux/drivers/media/video/v4l2-dev.c
@@ -384,23 +384,18 @@ static int get_index(struct video_device
return i == VIDEO_NUM_DEVICES ? -ENFILE : i;
}
-int video_register_device(struct video_device *vdev, int type, int nr)
-{
- return video_register_device_index(vdev, type, nr, -1);
-}
-EXPORT_SYMBOL(video_register_device);
/**
- * video_register_device_index - register video4linux devices
+ * video_register_device - register video4linux devices
* @vdev: video device structure we want to register
* @type: type of device to register
* @nr: which device number (0 ==
[PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev
From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron Signed-off-by: Jonathan Cameron ji...@cam.ac.uk --- This is my first cut at a merge of the various ov7670 drivers to work with Guennadi Liakhovetski's work on moving soc-camera over to v4l2-subdev framework. Thanks to Darius Augulis for many of the register settings, though a few sets marked as untested in his driver don't seem to work. I'm not entirely happy with the mapping of various parameters onto the standard v4l controls and would greatly appreciate any suggestions about these. There are still a lot of magic numbers in here but I've tried to identify the purposes of as many as possible. At the moment I've deliberately kept it separate in naming etc from the in tree ov7670 driver as I don't want to go breaking that driver. Is there anyone out there who has the hardware and would consider doing the relevant board support code and testing? All comments welcome. drivers/media/video/Kconfig |6 + drivers/media/video/Makefile |1 + drivers/media/video/ov7670_soc.c | 1475 ++ include/media/ov7670_soc.h | 21 + 4 files changed, 1503 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9ff760c..4580d7a 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -746,6 +746,12 @@ config SOC_CAMERA_OV772X help This is a ov772x camera driver +config SOC_CAMERA_OV7670_SOC + tristate ov7670 soc camera support + depends on SOC_CAMERA I2C + help + This is an ov7670 soc camera driver + config MX1_VIDEO bool diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 7aefac6..1249326 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -141,6 +141,7 @@ 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_OV7670_SOC)+= ov7670_soc.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o # soc-camera host drivers have to be linked after camera drivers diff --git a/drivers/media/video/ov7670_soc.c b/drivers/media/video/ov7670_soc.c new file mode 100644 index 000..5494427 --- /dev/null +++ b/drivers/media/video/ov7670_soc.c @@ -0,0 +1,1475 @@ +/* + * A V4L2 driver for OmniVision OV7670 cameras via soc interface + * + * Copyright 2006 One Laptop Per Child Association, Inc. Written + * by Jonathan Corbet with substantial inspiration from Mark + * McClelland's ovcamchip code. + * + * Copyright 2006-7 Jonathan Corbet cor...@lwn.net + * + * Copyright 2008-9 Jonathan Cameron ji...@cam.ac.uk + * + * Copyright 2008 Darius Augulis augulis.dar...@gmail.com + * + * This file may be distributed under the terms of the GNU General + * Public License, version 2. + * + * Todo: Add control for auto saturation control + * Inversion of sync signals etc. + * Driver 2 had a qqvga mode, but register settings don't seem to + * be right so I've removed it. + * + * Queries for review: + * 1) Here I'm using brightness controls for what are effectively shutter + * timings. How should this be done? + */ +#include linux/init.h +#include linux/module.h +#include linux/slab.h +#include linux/videodev2.h +#include media/v4l2-common.h +#include media/v4l2-chip-ident.h +#include linux/i2c.h +#include linux/gpio.h +#include linux/delay.h +#include media/soc_camera.h +#include media/ov7670_soc.h + +#define MAX_WIDTH 640 +#define MAX_HEIGHT 480 + +/* Registers */ +#defineREG_GAIN0x00/* Gain lower 8 bits (rest in vref) */ +#define REG_BLUE 0x01/* blue gain */ +#define REG_RED0x02/* red gain */ +#define REG_VREF 0x03/* Pieces of GAIN, VSTART, VSTOP */ +#define REG_COM1 0x04/* Control 1 */ +#defineCOM1_CCIR656 0x40 /* CCIR656 enable */ + +#define REG_AECHH 0x07/* AEC MS 5 bits */ + +#define REG_COM2 0x09/* Control 2 */ +#defineCOM2_SSLEEP 0x10 /* Soft sleep mode */ +#define REG_PID0x0a/* Product ID MSB */ +#define REG_VER0x0b/* Product ID LSB */ +#define REG_COM3 0x0c/* Control 3 */ +#defineCOM3_SWAP 0x40/* Byte swap */ +#defineCOM3_SCALEEN 0x08/* Enable scaling */ +#defineCOM3_DCWEN0x04/* Enable downsamp/crop/window */ +#define REG_COM4 0x0d/* Control 4 */ +#define REG_COM5 0x0e/* All reserved */ +#define REG_COM6 0x0f/* Control 6 */ +#define REG_AECH 0x10/* More bits of AEC value */
Re: s5h1411_readreg: readreg error (ret == -5)
hermann pitton wrote: [snip] The most undiscovered configurations seem to be such ones about antenna inputs and their switching. Again according to Hartmut, and he did not know exactly what is going on here, some for us and him at this point unknown checksums are used to derive even that information :( For what I can see, and I might be of course still wrong, we can also not determine plain digital tuner types, digital demodulator types of any kind and the type of possibly present second and third tuners, but at least their addresses, regularly shared by multiple chips, become often visible. (some OEMs have only 0xff still for all that) forgot, and not any LNB supplies behind some i2c bridges, shared or not on whatever. The use of Hauppauge eeproms I consider advisory at best. Yes, they have reasonably good fields to identify tuners, IR but a number of recent silicon additions (last 3 years) to the product line is not fully implemented in the eeproms. Some of the important feature decisions is done purely in software based on sub id for example. In general I agree with Hermann's comments, that is, where possible making maximum use of the eeprom. -- Steven Toth - Kernel Labs http://www.kernellabs.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
[RESEND][PATCH] video: Initial support for ADV7180
This is an initial driver for Analog Devices ADV7180 Video Decoder.
So far it only supports query standard.
Signed-off-by: Richard Röjfors richard.rojfors@mocean-labs.com
---
Index: linux-2.6.30-rc7/drivers/media/video/adv7180.c
===
--- linux-2.6.30-rc7/drivers/media/video/adv7180.c (revision 0)
+++ linux-2.6.30-rc7/drivers/media/video/adv7180.c (revision 867)
@@ -0,0 +1,221 @@
+/*
+ * adv7180.c Analog Devices ADV7180 video decoder driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/i2c-id.h
+#include media/v4l2-ioctl.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+
+#define ADV7180_INPUT_CONTROL_REG 0x00
+#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM 0x00
+#define ADV7180_AUTODETECT_ENABLE_REG 0x07
+#define ADV7180_AUTODETECT_DEFAULT 0x7f
+
+
+#define ADV7180_STATUS1_REG 0x10
+#define ADV7180_STATUS1_AUTOD_MASK 0x70
+#define ADV7180_STATUS1_AUTOD_NTSM_M_J 0x00
+#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
+#define ADV7180_STATUS1_AUTOD_PAL_M0x20
+#define ADV7180_STATUS1_AUTOD_PAL_60 0x30
+#define ADV7180_STATUS1_AUTOD_PAL_B_G 0x40
+#define ADV7180_STATUS1_AUTOD_SECAM0x50
+#define ADV7180_STATUS1_AUTOD_PAL_COMB 0x60
+#define ADV7180_STATUS1_AUTOD_SECAM_5250x70
+
+#define ADV7180_IDENT_REG 0x11
+#define ADV7180_ID_7180 0x18
+
+
+static unsigned short normal_i2c[] = { 0x42 1, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+struct adv7180_state {
+ struct v4l2_subdev sd;
+};
+
+static v4l2_std_id determine_norm(struct i2c_client *client)
+{
+ u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
+
+ switch (status1 ADV7180_STATUS1_AUTOD_MASK) {
+ case ADV7180_STATUS1_AUTOD_NTSM_M_J:
+ return V4L2_STD_NTSC_M_JP;
+ case ADV7180_STATUS1_AUTOD_NTSC_4_43:
+ return V4L2_STD_NTSC_443;
+ case ADV7180_STATUS1_AUTOD_PAL_M:
+ return V4L2_STD_PAL_M;
+ case ADV7180_STATUS1_AUTOD_PAL_60:
+ return V4L2_STD_PAL_60;
+ case ADV7180_STATUS1_AUTOD_PAL_B_G:
+ return V4L2_STD_PAL;
+ case ADV7180_STATUS1_AUTOD_SECAM:
+ return V4L2_STD_SECAM;
+ case ADV7180_STATUS1_AUTOD_PAL_COMB:
+ return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
+ case ADV7180_STATUS1_AUTOD_SECAM_525:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7180_state, sd);
+}
+
+static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ *(v4l2_std_id *)std = determine_norm(client);
+ return 0;
+}
+
+static int adv7180_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+ return -EINVAL;
+}
+
+static int adv7180_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+ return -EINVAL;
+}
+
+static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_ADV7180, 0);
+}
+
+static int adv7180_log_status(struct v4l2_subdev *sd)
+{
+ v4l2_info(sd, Normal operation\n);
+ return 0;
+}
+
+static irqreturn_t adv7180_irq(int irq, void *devid)
+{
+ return IRQ_NONE;
+}
+
+static const struct v4l2_subdev_video_ops adv7180_video_ops = {
+ .querystd = adv7180_querystd,
+};
+
+static const struct v4l2_subdev_core_ops adv7180_core_ops = {
+ .log_status = adv7180_log_status,
+ .g_chip_ident = adv7180_g_chip_ident,
+ .g_ctrl = adv7180_g_ctrl,
+ .s_ctrl = adv7180_s_ctrl,
+};
+
+static const struct v4l2_subdev_ops adv7180_ops = {
+ .core = adv7180_core_ops,
+ .video = adv7180_video_ops,
+};
+
+/*
+ * Generic i2c probe
+ * concerning the addresses: i2c wants 7 bit (without the r/w bit), so '1'
+ */
+
+static int
Re: [PULL] http://linuxtv.org/hg/~dougsland/em28xx/
Just wanted to thank Douglas Landgraf for the help he provided me with getting the em28xx driver working with the Kworld 315U tuner device (digital only at this time). As time permits, I hope to get the analog inputs and tuner to work too (if anyone want to help please let me know). Thanks, Franklin Meng --- On Sat, 6/6/09, Douglas Schilling Landgraf dougsl...@gmail.com wrote: From: Douglas Schilling Landgraf dougsl...@gmail.com Subject: [PULL] http://linuxtv.org/hg/~dougsland/em28xx/ To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab mche...@infradead.org, fmeng2...@yahoo.com Date: Saturday, June 6, 2009, 1:11 PM Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/em28xx for the following: - em28xx: Add Kworld 315 entry - em28xx: set up tda9887_conf in em28xx_card_setup() 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
RE: [PATCH RFC] adding support for setting bus parameters in sub device
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
As for the pins/signals, I wonder if per-signal polarity/edge is
enough. If this is going to be used by/replace the soc_camera
interface then we also need to know if the signal is present or not.
For instance, I have a SuperH board using my CEU driver together with
one OV7725 camera or one TW9910 video decoder. Some revisions of the
board do not route the field signal between the SuperH on-chip CEU and
the TW9910. Both the CEU and the TW9910 support this signal, it just
happen to be missing.
[MK]In that case can't the driver just ignore the field polarity? I assume that
drivers implement the parameter that has support in hardware. So it is not an
issue.
I think we need a way to include this board
specific property somehow.
/ magnus
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zr364xx.c: vfree does its own NULL check
hi Mauro, is it ok for this patch? Best Regards, Figo.zhang On Sat, 2009-06-06 at 17:16 +0800, Figo.zhang wrote: vfree() does it's own NULL checking, no need for explicit check before calling it. Signed-off-by: Figo.zhang figo1...@gmail.com --- drivers/media/video/zr364xx.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/zr364xx.c b/drivers/media/video/zr364xx.c index ac169c9..fc976f4 100644 --- a/drivers/media/video/zr364xx.c +++ b/drivers/media/video/zr364xx.c @@ -882,9 +882,11 @@ static void zr364xx_disconnect(struct usb_interface *intf) video_unregister_device(cam-vdev); cam-vdev = NULL; kfree(cam-buffer); - if (cam-framebuf) - vfree(cam-framebuf); + cam-buffer = NULL; + vfree(cam-framebuf); + cam-framebuf = NULL; kfree(cam); + cam = NULL; } -- 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] soc_camera: Fix debug output of supported formats count
The supported formats count must be set to 0 after debug output
right before the second pass.
Signed-off-by: Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de
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
@@ -238,11 +238,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;
--
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: Did I miss any other patches or RFCs that need to be reviewed?
Hans, Thanks for your review. I will get back to you if I need more information on your comments. You have reviewed the following patches in this series... 1,7,8,10 Following are part of this series which requires review as well. [PATCH 2/10 - v2] ccdc hw device header file for vpfe capture [PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver [PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver [PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture driver (not much to review in the below patch ) PATCH 6/10 - v2] Makefile and config files for vpfe capture driver regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: davinci-linux-open-source-bounces+m- karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source- bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Hans Verkuil Sent: Sunday, June 14, 2009 10:37 AM To: linux-media@vger.kernel.org Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux- o...@vger.kernel.org Subject: Did I miss any other patches or RFCs that need to be reviewed? Hi all, I think I've finally finished reviewing all the pending patches. Are there any that I've missed? Or are there other postings that need my attention? Please let me know, otherwise I assume that I'm (finally!) up to date. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446
+ /* set the default image parameters in the device */ + ret = vpfe_config_image_format(vpfe_dev, + vpfe_standards[vpfe_dev- std_index].std_id); + if (ret) + goto unlock_out; Why you check ret value and go to label below? Probably you can remove if-check and goto here. Ok. + +unlock_out: + mutex_unlock(vpfe_dev-lock); ; return -EIO? Ok. -- Best regards, Klimov Alexey -- 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
= dm644x_clear_wbl_overflow; + else + return -ENODEV; Do you need clean up procedure if you return error here? I mean - calls to release_mem_region, release_mem_region, etc Oops! I need to add that. Thanks. + spin_lock_init(oper_cfg.vpss_lock); + dev_info(pdev-dev, %s vpss probe success\n, oper_cfg.vpss_name); + return 0; +fail3: + release_mem_region(oper_cfg.r2-start, oper_cfg.len2); +fail2: + iounmap(oper_cfg.vpss_bl_regs_base); +fail1: + release_mem_region(oper_cfg.r1-start, oper_cfg.len1); + return status; +} -- Best regards, Klimov Alexey -- 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: Did I miss any other patches or RFCs that need to be reviewed?
On Monday 15 June 2009 18:24:53 Karicheri, Muralidharan wrote:
Hans,
Thanks for your review. I will get back to you if I need more
information on your comments.
You have reviewed the following patches in this series...
1,7,8,10
Those were the only ones I had any comments on. So I'm happy with the
others.
Regards,
Hans
Following are part of this series which requires review as well.
[PATCH 2/10 - v2] ccdc hw device header file for vpfe capture
[PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver
[PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver
[PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture driver
(not much to review in the below patch )
PATCH 6/10 - v2] Makefile and config files for vpfe capture driver
regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-bounces+m-
karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-
bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Hans Verkuil
Sent: Sunday, June 14, 2009 10:37 AM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
o...@vger.kernel.org
Subject: Did I miss any other patches or RFCs that need to be reviewed?
Hi all,
I think I've finally finished reviewing all the pending patches.
Are there any that I've missed? Or are there other postings that need my
attention?
Please let me know, otherwise I assume that I'm (finally!) up to date.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
{.n�+���+%�ݶ��w��{.n�+{��g��^n�r���z���hz��z�ޗ�+��+zf���h���~i�z_���j:+v���)ߣ�m
--
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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 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:Mon Jun 15 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11975:144d8d0cebc5 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-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-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-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-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-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-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-x86_64: WARNINGS sparse (linux-2.6.30): 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec 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
RE: Did I miss any other patches or RFCs that need to be reviewed?
Hans,
That is great!
Once I change the code based on the comments, do you think there is a chance to
get the driver to be merged to 2.6.31 (If so, how soon should I be ready with
the next version, v3 of the patch) or do we need to wait until 2.6.32?
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, June 15, 2009 1:56 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; linux-o...@vger.kernel.org
Subject: Re: Did I miss any other patches or RFCs that need to be reviewed?
On Monday 15 June 2009 18:24:53 Karicheri, Muralidharan wrote:
Hans,
Thanks for your review. I will get back to you if I need more
information on your comments.
You have reviewed the following patches in this series...
1,7,8,10
Those were the only ones I had any comments on. So I'm happy with the
others.
Regards,
Hans
Following are part of this series which requires review as well.
[PATCH 2/10 - v2] ccdc hw device header file for vpfe capture
[PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver
[PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver
[PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture
driver
(not much to review in the below patch )
PATCH 6/10 - v2] Makefile and config files for vpfe capture driver
regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-bounces+m-
karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-
source-
bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Hans
Verkuil
Sent: Sunday, June 14, 2009 10:37 AM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
o...@vger.kernel.org
Subject: Did I miss any other patches or RFCs that need to be reviewed?
Hi all,
I think I've finally finished reviewing all the pending patches.
Are there any that I've missed? Or are there other postings that need my
attention?
Please let me know, otherwise I assume that I'm (finally!) up to date.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
���{.n�+���+%�ݶ��w��{.n�+{��g�^n�r���z���h���z��z�ޗ�
+��+zf���h���~iz_��j:+v���)ߣ�m
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Re: [PATCH] zl10353 and qt1010: fix stack corruption bug
Hei Jan,
On 06/10/2009 09:21 AM, Jan Nikitenko wrote:
This patch fixes stack corruption bug present in dump_regs function of
zl10353 and qt1010 drivers:
the buffer buf is one byte smaller than required - there is 4 chars
for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
and 1 byte for zero ending the string required, i.e. 53 bytes, but
only 52 were provided.
The one byte missing in stack based buffer buf can cause stack
corruption possibly leading to kernel oops, as discovered originally
with af9015 driver.
Signed-off-by: Jan Nikitenko jan.nikite...@gmail.com
---
Antti Palosaari wrote:
On 06/10/2009 01:39 AM, Jan Nikitenko wrote:
Solved with [PATCH] af9015: fix stack corruption bug.
This error leads to the zl10353.c and there it was copied to qt1010.c
and af9015.c.
Antti, thanks for pointing out that the same problem was also in
zl10353.c and qt1010.c. Include your Sign-off-by, please.
I tried to test that patch (from patchwork) to ensure it is OK before
ack, but I found it does not apply for reason or other. It looks correct
for my eyes. Please check what's wrong and apply new patch.
[cr...@localhost v4l-dvb]$ patch -p1
af9015-fix-stack-corruption-bug.patch
patching file linux/drivers/media/dvb/dvb-usb/af9015.c
[cr...@localhost v4l-dvb]$ patch -p1
zl10353-and-qt1010-fix-stack-corruption-bug.patch
patching file linux/drivers/media/common/tuners/qt1010.c
Hunk #1 FAILED at 65.
1 out of 1 hunk FAILED -- saving rejects to file
linux/drivers/media/common/tuners/qt1010.c.rej
patching file linux/drivers/media/dvb/frontends/zl10353.c
Hunk #1 FAILED at 102.
1 out of 1 hunk FAILED -- saving rejects to file
linux/drivers/media/dvb/frontends/zl10353.c.rej
[cr...@localhost v4l-dvb]$ hg diff
diff -r 148b4c93a728 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Mon Jun 15 14:15:33 2009
-0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Mon Jun 15 21:55:55 2009
+0300
@@ -541,7 +541,7 @@
/* dump eeprom */
static int af9015_eeprom_dump(struct dvb_usb_device *d)
{
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
u8 reg, val;
for (reg = 0; ; reg++) {
[cr...@localhost v4l-dvb]$ hg head
changeset: 11978:148b4c93a728
tag: tip
parent: 11975:144d8d0cebc5
parent: 11977:8b416ba3ac89
user:Mauro Carvalho Chehab mche...@redhat.com
date:Mon Jun 15 14:15:33 2009 -0300
summary: merge: http://www.linuxtv.org/hg/~dougsland/em28xx
regards
Antti
--
http://palosaari.fi/
--
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] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Hi Hans,
Em Mon, 15 Jun 2009 13:27:42 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote:
On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the
following:
- ivtv/cx18: fix regression: class controls are no longer seen
- v4l2-ctl: add modulator get/set options.
- v4l2-spec: update VIDIOC_G/S_MODULATOR section.
- compat: fix __fls check for the arm architecture.
- smscoreapi: fix compile warning
The first one is a high prio bug as it is a 2.6.30 regression. Mike, once
this is merged in the git tree this one can be queued for the 2.6.30
stable
series.
The other changes are small stuff.
Added one more minor change:
- v4l2-i2c-drv.h: add comment describing when not to use this header.
The above patches seem ok.
And added this one as well:
- v4l2-dev: fix some confusing variable names and comments
# HG changeset patch
# User Hans Verkuil hverk...@xs4all.nl
# Date 1245063581 -7200
# Node ID 083bb5ad197e4c49430de2b26f3115743fe5cc27
# Parent 743225159afab6d79a0d6095bc302f9922305c33
v4l2-dev: fix some confusing variable names and comments
From: Hans Verkuil hverk...@xs4all.nl
Some variable names and comments were rather misleading when it came
to the distinction between kernel numbers and minor numbers. This should
clarify things.
Priority: normal
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
--- a/linux/drivers/media/video/v4l2-dev.cSun Jun 14 12:12:11 2009 +0200
+++ b/linux/drivers/media/video/v4l2-dev.cMon Jun 15 12:59:41 2009 +0200
@@ -419,10 +419,10 @@ int video_register_device_index(struct v
int video_register_device_index(struct video_device *vdev, int type, int nr,
int index)
{
- int i = 0;
+ int minor;
int ret;
int minor_offset = 0;
- int minor_cnt = VIDEO_NUM_DEVICES;
+ int kernel_nrs = VIDEO_NUM_DEVICES;
const char *name_base;
void *priv = video_get_drvdata(vdev);
@@ -470,52 +470,52 @@ int video_register_device_index(struct v
switch (type) {
case VFL_TYPE_GRABBER:
minor_offset = 0;
- minor_cnt = 64;
+ kernel_nrs = 64;
break;
case VFL_TYPE_RADIO:
minor_offset = 64;
- minor_cnt = 64;
+ kernel_nrs = 64;
break;
case VFL_TYPE_VTX:
minor_offset = 192;
- minor_cnt = 32;
+ kernel_nrs = 32;
break;
case VFL_TYPE_VBI:
minor_offset = 224;
- minor_cnt = 32;
+ kernel_nrs = 32;
break;
default:
minor_offset = 128;
- minor_cnt = 64;
- break;
- }
-#endif
-
- /* Pick a minor number */
+ kernel_nrs = 64;
+ break;
+ }
+#endif
+
+ /* Pick a kernel number */
mutex_lock(videodev_lock);
- nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
- if (nr == minor_cnt)
- nr = find_first_zero_bit(video_nums[type], minor_cnt);
- if (nr == minor_cnt) {
+ nr = find_next_zero_bit(video_nums[type], kernel_nrs, nr == -1 ? 0 :
nr);
+ if (nr == kernel_nrs)
+ nr = find_first_zero_bit(video_nums[type], kernel_nrs);
+ if (nr == kernel_nrs) {
printk(KERN_ERR could not get a free kernel number\n);
mutex_unlock(videodev_lock);
return -ENFILE;
}
#ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
/* 1-on-1 mapping of kernel number to minor number */
- i = nr;
+ minor = nr;
#else
/* The kernel number and minor numbers are independent */
- for (i = 0; i VIDEO_NUM_DEVICES; i++)
- if (video_device[i] == NULL)
+ for (minor = 0; minor VIDEO_NUM_DEVICES; minor++)
+ if (video_device[minor] == NULL)
break;
- if (i == VIDEO_NUM_DEVICES) {
+ if (minor == VIDEO_NUM_DEVICES) {
mutex_unlock(videodev_lock);
printk(KERN_ERR could not get a free minor\n);
return -ENFILE;
}
#endif
- vdev-minor = i + minor_offset;
+ vdev-minor = minor + minor_offset;
vdev-num = nr;
set_bit(nr, video_nums[type]);
/* Should not happen since we thought this minor was free */
The progressive changes at video_register_device() created a mess on this
function, that reflected on ov511 driver, but it is also present on the others.
By looking on this patch, it is obfuscating the function even more. Creating
more
confusion on it, due to some reasons:
1) The name kernel number doesn't seem much appropriate. Any number used in
kernel can be called as a kernel number.
2) minor and major devices are
Re: RFC: remove video_register_device_index, add video_register_device_range
Em Mon, 15 Jun 2009 16:02:40 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: The sticking point for me is that warning since for cx18/ivtv it is OK if you get something else then you specified (since it is a starting index meant to distinguish mpeg encoders from raw video inputs, from mpeg decoders, etc.). So generating a warning for those two drivers is not correct. Ok. Perhaps we should add a V4L2_FL_KNUM_OFFSET flag for the struct video_device flags field that tell the register function that 'nr' should be interpreted as a kernel number offset, and not as a preferred number. In the latter case you generate a warning, in the first case you don't. Hmm... V4L2_FL_KNUM_OFFSET seems a too obfuscated name. Also, such flag would be needed by just the register function, so, IMO, a parameter would work better. Also, am I wrong or is there anything wrong with the flags? The only place I'm seeing this being used is here: $ grep 'vdev-flags' v4l/*.[ch] v4l/v4l2-dev.c: set_bit(V4L2_FL_UNREGISTERED, vdev-flags); It is being set, but no code seems to actually test for it. So, IMO, we can just remove this field. One alternative would be to implement it as something like: +int __must_check __video_register_device(struct video_device *vdev, + const int type, const int nr, int warn_if_skip); #define video_register_device(vdev, type, nr) __video_register_device(vdev, type, nr, 0) I think it isn't a bad idea to use a flag. It reflects the two possible use cases: one for drivers that create multiple video (or vbi) devices and use the kernel number to reflect the purpose of each video device, and the other where the user wants a specific kernel number. In the latter case the driver creates a single video device. I don't want to see a lot of kernel warnings each time an ivtv or cx18 driver is loaded. Those warnings do not apply to those drivers. BTW: please note that my v4l-dvb-misc tree contains a patch to clean up the comments/variable names in v4l2-dev.c. You might want to pull that in first. Please see my comments for your v4l-dvb-misc tree pull request. Let's first work on that changeset, and then we can discuss better about the warning issue. Regards, Han 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
TT-S1500 budget-ci registeration
Hello to all, I'm currently testing a TT-S1500 budget card with the TT budget CI adapter with vl4 tree and kernel 2.6.28. When I modprobe budget_ci, the CI adapter seems to be detected but not registered in /dev/dvb/adapter3/ca0 as I would have expected it to be. Instead I see the following output: [ 148.664846] input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci:00/:00:1e.0/:11:09.0/input/input5 Any suggestions/ideas what the cause may be and how I can attempt to solve this? Thanks Thomas -- 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: GPL code for Omnivision USB video camera available.
On 06/15/2009 03:01 AM, Erik de Castro Lopo wrote: On Sat, 13 Jun 2009 18:12:10 +1000 Hans de Goedehdego...@redhat.com wrote: Getting ovfx2 support into the mainline kernel sounds like a good idea! I'm not such a big fan of merging the driver as is though, as it does its own buffer management (and ioctl handling, usb interrupt handling, locking, etc). I understand completely. Good! For adding the ovfx2 driver, you could start by copying ov519.c, which already has setup and control code fro most ov sensors and then rewrite the bridge part to be ovfx2 code, then later we can try to move the sensor code to a shared c file for the ov519 and ovfx2 driver, depending on how much you needed to change the sensor code. Or you could add support for the ovfx2 to the ov519 driver. Note I've recently being doing quite a bit of work on the ov519 driver, adding support for the ov511 and ov518 and adding more controls. I'll make a mercurial tree available with my latest code in it asap. Ok, there's the rub. I am simply way too busy at the moment to push this through myself. I was hoping I could contract someone to take the existing code and massage it into shape ready for merging. I would prefer it if that someone was already a V4L hacker, but if I can't find anyone with pre-existing V4L experience I'll find someone local with general Linux kernel/driver experience. Well I can't offer you contracting, as I simply do not have the spare time to make such promises, but as any good hacker: will work for hardware on a I'll do my best but no promises made basis. I'm actually spending quite a bit of time lately on v4l stuff again, and I'm sure willing to spend some time on this. I can even promise you I'll bump it to the top of the list of my v4l projects. For a general idea how deep I'm involved in v4l webcam support see: https://fedoraproject.org/wiki/Features/BetterWebcamSupport 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: RFC: remove video_register_device_index, add video_register_device_range
On Monday 15 June 2009 21:51:13 Mauro Carvalho Chehab wrote:
Em Mon, 15 Jun 2009 16:02:40 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
The sticking point for me is that warning since for cx18/ivtv it is OK if
you
get something else then you specified (since it is a starting index meant to
distinguish mpeg encoders from raw video inputs, from mpeg decoders, etc.).
So generating a warning for those two drivers is not correct.
Ok.
Perhaps we should add a V4L2_FL_KNUM_OFFSET flag for the struct video_device
flags field that tell the register function that 'nr' should be interpreted
as a kernel number offset, and not as a preferred number. In the latter case
you generate a warning, in the first case you don't.
Hmm... V4L2_FL_KNUM_OFFSET seems a too obfuscated name. Also, such flag would
be needed by just the register function, so, IMO, a parameter would work
better.
That was the idea with the video_register_device_range() proposal. I don't want
to modify all existing video_register_device() calls.
Also, am I wrong or is there anything wrong with the flags?
The only place I'm seeing this being used is here:
$ grep 'vdev-flags' v4l/*.[ch]
v4l/v4l2-dev.c: set_bit(V4L2_FL_UNREGISTERED, vdev-flags);
It is being set, but no code seems to actually test for it. So, IMO, we can
just remove this field.
No, it is used a lot through the video_is_unregistered() inline in
media/v4l2-dev.h.
One alternative would be to implement it as something like:
+int __must_check __video_register_device(struct video_device *vdev,
+ const int type, const int nr, int
warn_if_skip);
#define video_register_device(vdev, type, nr) __video_register_device(vdev,
type, nr, 0)
Hmm, that's an option. Although I'd make it a static inline:
static inline int __must_check video_register_device(...)
{
return __video_register_device(vdev, type, nr, 1);
}
Regards,
Hans
I think it isn't a bad idea to use a flag. It reflects the two possible use
cases: one for drivers that create multiple video (or vbi) devices and use
the
kernel number to reflect the purpose of each video device, and the other
where
the user wants a specific kernel number. In the latter case the driver
creates
a single video device.
I don't want to see a lot of kernel warnings each time an ivtv or cx18
driver
is loaded. Those warnings do not apply to those drivers.
BTW: please note that my v4l-dvb-misc tree contains a patch to clean up the
comments/variable names in v4l2-dev.c. You might want to pull that in first.
Please see my comments for your v4l-dvb-misc tree pull request. Let's first
work on that changeset, and then we can discuss better about the warning
issue.
Regards,
Han
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
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Monday 15 June 2009 21:48:32 Mauro Carvalho Chehab wrote:
Hi Hans,
Em Mon, 15 Jun 2009 13:27:42 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote:
On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for
the
following:
- ivtv/cx18: fix regression: class controls are no longer seen
- v4l2-ctl: add modulator get/set options.
- v4l2-spec: update VIDIOC_G/S_MODULATOR section.
- compat: fix __fls check for the arm architecture.
- smscoreapi: fix compile warning
The first one is a high prio bug as it is a 2.6.30 regression. Mike,
once
this is merged in the git tree this one can be queued for the 2.6.30
stable
series.
The other changes are small stuff.
Added one more minor change:
- v4l2-i2c-drv.h: add comment describing when not to use this header.
The above patches seem ok.
And added this one as well:
- v4l2-dev: fix some confusing variable names and comments
# HG changeset patch
# User Hans Verkuil hverk...@xs4all.nl
# Date 1245063581 -7200
# Node ID 083bb5ad197e4c49430de2b26f3115743fe5cc27
# Parent 743225159afab6d79a0d6095bc302f9922305c33
v4l2-dev: fix some confusing variable names and comments
From: Hans Verkuil hverk...@xs4all.nl
Some variable names and comments were rather misleading when it came
to the distinction between kernel numbers and minor numbers. This should
clarify things.
Priority: normal
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
--- a/linux/drivers/media/video/v4l2-dev.c Sun Jun 14 12:12:11 2009 +0200
+++ b/linux/drivers/media/video/v4l2-dev.c Mon Jun 15 12:59:41 2009 +0200
@@ -419,10 +419,10 @@ int video_register_device_index(struct v
int video_register_device_index(struct video_device *vdev, int type, int
nr,
int index)
{
- int i = 0;
+ int minor;
int ret;
int minor_offset = 0;
- int minor_cnt = VIDEO_NUM_DEVICES;
+ int kernel_nrs = VIDEO_NUM_DEVICES;
const char *name_base;
void *priv = video_get_drvdata(vdev);
@@ -470,52 +470,52 @@ int video_register_device_index(struct v
switch (type) {
case VFL_TYPE_GRABBER:
minor_offset = 0;
- minor_cnt = 64;
+ kernel_nrs = 64;
break;
case VFL_TYPE_RADIO:
minor_offset = 64;
- minor_cnt = 64;
+ kernel_nrs = 64;
break;
case VFL_TYPE_VTX:
minor_offset = 192;
- minor_cnt = 32;
+ kernel_nrs = 32;
break;
case VFL_TYPE_VBI:
minor_offset = 224;
- minor_cnt = 32;
+ kernel_nrs = 32;
break;
default:
minor_offset = 128;
- minor_cnt = 64;
- break;
- }
-#endif
-
- /* Pick a minor number */
+ kernel_nrs = 64;
+ break;
+ }
+#endif
+
+ /* Pick a kernel number */
mutex_lock(videodev_lock);
- nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
- if (nr == minor_cnt)
- nr = find_first_zero_bit(video_nums[type], minor_cnt);
- if (nr == minor_cnt) {
+ nr = find_next_zero_bit(video_nums[type], kernel_nrs, nr == -1 ? 0 :
nr);
+ if (nr == kernel_nrs)
+ nr = find_first_zero_bit(video_nums[type], kernel_nrs);
+ if (nr == kernel_nrs) {
printk(KERN_ERR could not get a free kernel number\n);
mutex_unlock(videodev_lock);
return -ENFILE;
}
#ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
/* 1-on-1 mapping of kernel number to minor number */
- i = nr;
+ minor = nr;
#else
/* The kernel number and minor numbers are independent */
- for (i = 0; i VIDEO_NUM_DEVICES; i++)
- if (video_device[i] == NULL)
+ for (minor = 0; minor VIDEO_NUM_DEVICES; minor++)
+ if (video_device[minor] == NULL)
break;
- if (i == VIDEO_NUM_DEVICES) {
+ if (minor == VIDEO_NUM_DEVICES) {
mutex_unlock(videodev_lock);
printk(KERN_ERR could not get a free minor\n);
return -ENFILE;
}
#endif
- vdev-minor = i + minor_offset;
+ vdev-minor = minor + minor_offset;
vdev-num = nr;
set_bit(nr, video_nums[type]);
/* Should not happen since we thought this minor was free */
The progressive changes at video_register_device() created a mess on this
function, that reflected on ov511 driver, but it is also present on the
others.
By looking on this patch, it is obfuscating the function even more. Creating
more
confusion on it, due to some reasons:
1) The name kernel number doesn't seem much appropriate. Any number used in
Re: Did I miss any other patches or RFCs that need to be reviewed?
On Monday 15 June 2009 20:44:15 Karicheri, Muralidharan wrote: Hans, That is great! Once I change the code based on the comments, do you think there is a chance to get the driver to be merged to 2.6.31 (If so, how soon should I be ready with the next version, v3 of the patch) or do we need to wait until 2.6.32? If you want to have a chance to get this in 2.6.31 then you have to be quick, and even then I can't guarantee anything. It will depend on Mauro to a large extent. The 2.6.31 merge window is now open but will close in 1-2 weeks. After that it depends on Mauro whether he will allow it to be merged. It's a pretty tight schedule, I'm afraid. 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: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446
Hans,
I am not clear about some of your comments. Please see below with a [MK] prefix.
+static int debug;
+static u32 numbuffers = 3;
+static u32 bufsize = (720 * 576 * 2);
+
+module_param(numbuffers, uint, S_IRUGO);
+module_param(bufsize, uint, S_IRUGO);
+module_param(debug, int, 0644);
+
+
+/* Set interface params based on client interface */
+static int vpfe_set_hw_if_params(struct vpfe_device *vpfe_dev)
+{
+struct vpfe_subdev_info *subdev = vpfe_dev-current_subdev;
+struct v4l2_routing *route =
+(subdev-routes[vpfe_dev-current_input]);
+
+switch (route-output) {
+case OUTPUT_10BIT_422_EMBEDDED_SYNC:
+vpfe_dev-vpfe_if_params.if_type = VPFE_BT656;
+break;
+case OUTPUT_20BIT_422_SEPERATE_SYNC:
+vpfe_dev-vpfe_if_params.if_type = VPFE_YCBCR_SYNC_16;
+break;
+case OUTPUT_10BIT_422_SEPERATE_SYNC:
+vpfe_dev-vpfe_if_params.if_type = VPFE_YCBCR_SYNC_8;
+break;
+default:
+v4l2_err(vpfe_dev-v4l2_dev, decoder output
+ not supported, %d\n, route-output);
+return -EINVAL;
+}
+
+/* set if client specific interface param is available */
+if (subdev-pdata) {
+/* each client will have different interface requirements */
+if (!strcmp(subdev-name, tvp5146)) {
+struct tvp514x_platform_data *pdata = subdev-pdata;
+
+if (pdata-hs_polarity)
+vpfe_dev-vpfe_if_params.hdpol =
+VPFE_PINPOL_POSITIVE;
+else
+vpfe_dev-vpfe_if_params.hdpol =
+VPFE_PINPOL_NEGATIVE;
+
+if (pdata-vs_polarity)
+vpfe_dev-vpfe_if_params.vdpol =
+VPFE_PINPOL_POSITIVE;
+else
+vpfe_dev-vpfe_if_params.hdpol =
+VPFE_PINPOL_NEGATIVE;
This won't work. Instead this should be data associated with the
platform_data.
I.e. the platform_data for the dm355/dm6446 contains not only the subdev
information, but for each subdev also the information on how to setup the
vpfe
polarities. You cannot derive that information from what subdevs are used
since
the board designer might have added e.g. inverters or something like that.
Such
information can only come from the platform_data.
[MK] I know this code is not correct. But I was waiting for the discussion on
my bus parameter patch to make this change. Currently TVP514x driver that you
have reviewed configure output bus based on route-output parameter set by
s_route(). This doesn't make sense. The input param make sense since
application can choose between Composite and S-Video inputs. There is only one
bus going out of the sub device to vpfe. So the output selection @ sub device
is redundant. I think the output is part of as the bus parameter structure I
added in the bus parameter patch which is under review. It can be read by
TVP514x from the platform data (using the structure added by my patch) and can
be overridden by s_bus(). Do you expect the bridge driver and sub devices
having platform data for bus type (For example, BT.656)? It appears to be
required only for sub device and bridge driver can configure the ccdc based on
sub device bus type. But for polarities I need to define them for both sides.
comments?
+} else {
+v4l2_err(vpfe_dev-v4l2_dev, No interface params
+ defined for subdevice, %d\n, route-output);
+return -EFAULT;
+}
+}
+return ccdc_dev-hw_ops.set_hw_if_params(vpfe_dev-vpfe_if_params);
+}
+
+/*
+
+struct vpfe_fh *fh;
+
+v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_open\n);
+
+if (!vpfe_dev-cfg-num_subdevs) {
+v4l2_err(vpfe_dev-v4l2_dev, No decoder registered\n);
+return -ENODEV;
+}
Why would this be an error? I might have an FPGA connected instead or some
other non-i2c device that doesn't require any setup from this driver.
[MK] What you mean by this? Are you saying an FPGA logic will implement the
decoder hardware? That is quite possible, so also it could be non-i2c. But my
understanding was that sub device can be anything that basically implement the
sub device API and need not always be an i2c device. So for FPGA or some other
bus based device, the bridge device doesn't care how the command to change
input, detect standard etc are communicated by the sub device driver to its
hardware. It could be writing into some FPGA register or sending a proprietary
protocol command. Is my understanding correct? In that case each of the above
(FPGA or non-i2c) is a sub device and at least one sub device should be
available before application can do
RE: Did I miss any other patches or RFCs that need to be reviewed?
Hans,
I will do my best to push v3 of this patch this week.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, June 15, 2009 5:46 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; linux-o...@vger.kernel.org
Subject: Re: Did I miss any other patches or RFCs that need to be reviewed?
On Monday 15 June 2009 20:44:15 Karicheri, Muralidharan wrote:
Hans,
That is great!
Once I change the code based on the comments, do you think there is a
chance to get the driver to be merged to 2.6.31 (If so, how soon should I
be ready with the next version, v3 of the patch) or do we need to wait
until 2.6.32?
If you want to have a chance to get this in 2.6.31 then you have to be
quick, and even then I can't guarantee anything. It will depend on Mauro to
a large extent. The 2.6.31 merge window is now open but will close in 1-2
weeks. After that it depends on Mauro whether he will allow it to be
merged.
It's a pretty tight schedule, I'm afraid.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: TT-S1500 budget-ci registeration
Thomas Kernen wrote: Hello to all, I'm currently testing a TT-S1500 budget card with the TT budget CI adapter with vl4 tree and kernel 2.6.28. When I modprobe budget_ci, the CI adapter seems to be detected but not registered in /dev/dvb/adapter3/ca0 as I would have expected it to be. Instead I see the following output: [ 148.664846] input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci:00/:00:1e.0/:11:09.0/input/input5 Any suggestions/ideas what the cause may be and how I can attempt to solve this? Thanks Thomas -- And I realised I cut and pasted the wrong line: I was expecting to see budget_ci: CI interface initialised after the other line but nothing of the like did appear. Nor any line indicating an error. As one can see from the lspci the drivers claim to be in use: 11:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Device 1017 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 123 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 23 Region 0: Memory at d022 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_ci dvb Kernel modules: budget-ci Am I missing a point here? I can't find anything that addresses this in the LinuxTV wiki or in the archives of the mailing list. Thanks Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/10 - v2] DM355 platform changes for vpfe capture driver
On Tuesday 16 June 2009 00:24:34 Karicheri, Muralidharan wrote: Hans, Please see my response below. snip A general remark: currently you link your inputs directly to a subdev. This approach has two disadvantages: 1) It doesn't work if there are no subdevs at all (e.g. because everything goes through an fpga). [MK] Not sure what you mean here. If there is an FPGA, there should be something to make a selection between FPGA vs the rest of the decoders. FPGA will have an input and there should be some way it reports the detected standard etc. So why can't it be implemented by a sub device (may be less configuration since most of the logic is in FPGA). Hopefully my previous reply explains what I meant. I wasn't clear here either. 2) It fixes the reported order of the inputs to the order of the subdevs. [MK]Is that an issue? I don't see why. It's a minor issue. But applications typically enumerate inputs to present a list to the user which inputs there are. And if there are a lot then it can be useful to have them in a specific order. Either to group the inputs based on some criterium or to reflect the labeling on the box. It's a nice-to-have, I admit. I think it is better to have a separate array of input descriptions that refer to a subdev when an input is associated with that subdev. [MK] Are suggesting an link from input array entry into sub device entry input index? Yes. How do you translate the input from application to a sub device or FPGA input? What if there are two composite inputs on two different sub devices? A Composite 1 input would point to subdev 1 and the Composite 2 input would point to subdev 2. Or do you mean something else? (I'm not sure I entirely understand your question) flexible that way, and I actually think that the vpfe driver will be simplified as well. [MK], Not sure at this point. The advantage is that the ENUMINPUT and S/G_INPUT functions can do a simple lookup in the input array and immediately find the subdev index. Rather than iterating over all subdevs and counting the number of inputs in order to find which input belongs to which subdev. This is probably a stronger argument than my others are :-) Regards, Hans Murali m-karich...@ti.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 -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Hi,
Am Montag, den 15.06.2009, 23:35 +0200 schrieb Hans Verkuil:
On Monday 15 June 2009 21:48:32 Mauro Carvalho Chehab wrote:
Hi Hans,
Em Mon, 15 Jun 2009 13:27:42 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote:
On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for
the
following:
- ivtv/cx18: fix regression: class controls are no longer seen
- v4l2-ctl: add modulator get/set options.
- v4l2-spec: update VIDIOC_G/S_MODULATOR section.
- compat: fix __fls check for the arm architecture.
- smscoreapi: fix compile warning
The first one is a high prio bug as it is a 2.6.30 regression. Mike,
once
this is merged in the git tree this one can be queued for the 2.6.30
stable
series.
The other changes are small stuff.
Added one more minor change:
- v4l2-i2c-drv.h: add comment describing when not to use this header.
The above patches seem ok.
And added this one as well:
- v4l2-dev: fix some confusing variable names and comments
# HG changeset patch
# User Hans Verkuil hverk...@xs4all.nl
# Date 1245063581 -7200
# Node ID 083bb5ad197e4c49430de2b26f3115743fe5cc27
# Parent 743225159afab6d79a0d6095bc302f9922305c33
v4l2-dev: fix some confusing variable names and comments
From: Hans Verkuil hverk...@xs4all.nl
Some variable names and comments were rather misleading when it came
to the distinction between kernel numbers and minor numbers. This should
clarify things.
Priority: normal
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
--- a/linux/drivers/media/video/v4l2-dev.cSun Jun 14 12:12:11
2009 +0200
+++ b/linux/drivers/media/video/v4l2-dev.cMon Jun 15 12:59:41
2009 +0200
@@ -419,10 +419,10 @@ int video_register_device_index(struct v
int video_register_device_index(struct video_device *vdev, int type, int
nr,
int index)
{
- int i = 0;
+ int minor;
int ret;
int minor_offset = 0;
- int minor_cnt = VIDEO_NUM_DEVICES;
+ int kernel_nrs = VIDEO_NUM_DEVICES;
const char *name_base;
void *priv = video_get_drvdata(vdev);
@@ -470,52 +470,52 @@ int video_register_device_index(struct v
switch (type) {
case VFL_TYPE_GRABBER:
minor_offset = 0;
- minor_cnt = 64;
+ kernel_nrs = 64;
break;
case VFL_TYPE_RADIO:
minor_offset = 64;
- minor_cnt = 64;
+ kernel_nrs = 64;
break;
case VFL_TYPE_VTX:
minor_offset = 192;
- minor_cnt = 32;
+ kernel_nrs = 32;
break;
case VFL_TYPE_VBI:
minor_offset = 224;
- minor_cnt = 32;
+ kernel_nrs = 32;
break;
default:
minor_offset = 128;
- minor_cnt = 64;
- break;
- }
-#endif
-
- /* Pick a minor number */
+ kernel_nrs = 64;
+ break;
+ }
+#endif
+
+ /* Pick a kernel number */
mutex_lock(videodev_lock);
- nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
- if (nr == minor_cnt)
- nr = find_first_zero_bit(video_nums[type], minor_cnt);
- if (nr == minor_cnt) {
+ nr = find_next_zero_bit(video_nums[type], kernel_nrs, nr == -1 ? 0 :
nr);
+ if (nr == kernel_nrs)
+ nr = find_first_zero_bit(video_nums[type], kernel_nrs);
+ if (nr == kernel_nrs) {
printk(KERN_ERR could not get a free kernel number\n);
mutex_unlock(videodev_lock);
return -ENFILE;
}
#ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
/* 1-on-1 mapping of kernel number to minor number */
- i = nr;
+ minor = nr;
#else
/* The kernel number and minor numbers are independent */
- for (i = 0; i VIDEO_NUM_DEVICES; i++)
- if (video_device[i] == NULL)
+ for (minor = 0; minor VIDEO_NUM_DEVICES; minor++)
+ if (video_device[minor] == NULL)
break;
- if (i == VIDEO_NUM_DEVICES) {
+ if (minor == VIDEO_NUM_DEVICES) {
mutex_unlock(videodev_lock);
printk(KERN_ERR could not get a free minor\n);
return -ENFILE;
}
#endif
- vdev-minor = i + minor_offset;
+ vdev-minor = minor + minor_offset;
vdev-num = nr;
set_bit(nr, video_nums[type]);
/* Should not happen since we thought this minor was free */
The progressive changes at video_register_device() created a mess on this
function, that reflected on ov511 driver, but it is also present on the
others.
By looking on this patch, it is obfuscating the function even more.
Creating more
confusion on it, due to
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Em Mon, 15 Jun 2009 23:35:59 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
By looking on this patch, it is obfuscating the function even more.
Creating more
confusion on it, due to some reasons:
1) The name kernel number doesn't seem much appropriate. Any number used
in
kernel can be called as a kernel number.
Actually, that is apparently what the number X is called in a node like
/dev/videoX. I didn't make up that term, it's what I found when reading
'man udev'. Since udev deals extensively with these concepts I borrowed the
udev terminology for this. If someone knows a better word, then I'm happy
to use that.
Ah, now I see where you got this. Yet, this is what man udev says:
$number, %n
The kernel number for this device. For example, ’sda3’ has
kernel number of ’3’
$major, %M
The kernel major number for the device.
$minor %m
The kernel minor number for the device.
See, on all all tree is calls kernel [something] number. Seems confusing
enough to avoid those names at the V4L2 core. Also, even the man needed to give
an example, showing that this nomenclature may not be widely understood.
Maybe we can just call it as dev_number and properly explain its meaning.
That's said, the logic of when minor range is not fixed seems broken, as it
will change only an internal representation of the device. So the module
parameters that reflect at nr var won't work as expected.
No, they work exactly as expected: if you set nr to 1 then you get a
/dev/video1
node no matter what the FIXED_MINOR_RANGES setting is (provided there isn't
already a /dev/video1 node, in which case it will find the next available
kernel number).
So, the current code seems too complex and broken.
No, it's neither too complex nor broken, although it clearly needs still more
comments.
The code is complex. For example, take a look at this:
#ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
...
#else
/* The kernel number and minor numbers are independent */
for (i = 0; i VIDEO_NUM_DEVICES; i++)
if (video_device[i] == NULL)
break;
if (i == VIDEO_NUM_DEVICES) {
..
return -ENFILE;
}
#endif
vdev-minor = i + minor_offset;
...
/* Should not happen since we thought this minor was free */
WARN_ON(video_device[vdev-minor] != NULL);
when !FIXED_MINOR_RANGES, you're return if all video_device[i] are used. Then,
you do a WARN_ON(video_device[i + minor_offset]) instead of video_device[i].
People need to look back at the code to identify that minor_offset is equal to
0 when !FIXED_MINOR_RANGES.
Also, by letting the function to allocate a device even when video_device !=
NULL seems broken. It should instead call WARN and return with -EINVAL.
The presence of the #if's, plus the high number of phases at the same
function make it harder to read and understand. The code will be more readable
if we break it into a few static functions (that will be inline anyway, due to
gcc optimizer).
Just as reference, the behavior before changeset 9133 is:
switch (type) {
case VFL_TYPE_GRABBER:
base = MINOR_VFL_TYPE_GRABBER_MIN;
...
}
i = base + nr;
vfd-minor = i;
where nr is auto-selected for negative values, or just used above otherwise.
That's said, IMO, we need to rework at the function, making it simpler, and
fixing the behavior where the user wants to select a minor.
The user doesn't select a minor number, the user selects a kernel number.
With udev minor numbers have become completely uninteresting and unless
FIXED_MINOR_RANGES is set each node will be assigned the first free minor
number.
OK, now I see what you're meaning.
With respect to the code, I still think it does too much into just one
function. It may make sense to break the code into more functions to allow an
easier understanding.
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
[PATCH] FM1216MK5 FM radio patch
Hi Next code for implement Philips FM1216MK5. 1. Implement get_stereo function. 2. Add correct data byte for FM radio mode. diff -r bff77ec33116 linux/drivers/media/common/tuners/tuner-simple.c --- a/linux/drivers/media/common/tuners/tuner-simple.c Thu Jun 11 18:44:23 2009 -0300 +++ b/linux/drivers/media/common/tuners/tuner-simple.c Tue Jun 16 05:27:52 2009 +1000 @@ -145,6 +145,8 @@ case TUNER_LG_NTSC_TAPE: case TUNER_TCL_MF02GIP_5N: return ((status TUNER_SIGNAL) == TUNER_STEREO_MK3); + case TUNER_PHILIPS_FM1216MK5: + return status | TUNER_STEREO; default: return status TUNER_STEREO; } @@ -514,6 +516,10 @@ case TUNER_PHILIPS_FM1256_IH3: case TUNER_TCL_MF02GIP_5N: buffer[3] = 0x19; + break; + case TUNER_PHILIPS_FM1216MK5: + buffer[2] = 0x88; + buffer[3] = 0x09; break; case TUNER_TNF_5335MF: buffer[3] = 0x11; Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com With my best regards, Dmitry.diff -r bff77ec33116 linux/drivers/media/common/tuners/tuner-simple.c --- a/linux/drivers/media/common/tuners/tuner-simple.c Thu Jun 11 18:44:23 2009 -0300 +++ b/linux/drivers/media/common/tuners/tuner-simple.c Tue Jun 16 05:27:52 2009 +1000 @@ -145,6 +145,8 @@ case TUNER_LG_NTSC_TAPE: case TUNER_TCL_MF02GIP_5N: return ((status TUNER_SIGNAL) == TUNER_STEREO_MK3); + case TUNER_PHILIPS_FM1216MK5: + return status | TUNER_STEREO; default: return status TUNER_STEREO; } @@ -514,6 +516,10 @@ case TUNER_PHILIPS_FM1256_IH3: case TUNER_TCL_MF02GIP_5N: buffer[3] = 0x19; + break; + case TUNER_PHILIPS_FM1216MK5: + buffer[2] = 0x88; + buffer[3] = 0x09; break; case TUNER_TNF_5335MF: buffer[3] = 0x11; Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-no-audio
Em Sun, 14 Jun 2009 20:30:18 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/em28xx-no-audio for the following: - em28xx: don't create audio device if not supported This should correct the problems you noticed with the previous patch in the misc-fixes tree. Applied, thanks. Tested with Kworld 2800d and HVR-950. Would be useful if somebody who had an em28xx device with the USB audio class could test as well. Tested with a Hauppauge WinTV USB2, with msp3445-bg i2s chip, no AC97: [ 6680.635866] em28xx: New device WinTV USB2 @ 480 Mbps (2040:4200, interface 0, class 0) [ 6680.635894] em28xx #0: Identified as Hauppauge WinTV USB 2 (card=4) [ 6680.636116] em28xx #0: chip ID is em2840 [ 6680.755380] em28xx #0: i2c eeprom 00: 1a eb 67 95 40 20 00 42 20 00 1c 03 82 18 6a 18 [ 6680.755410] em28xx #0: i2c eeprom 10: 00 00 24 57 6e 00 00 00 60 00 00 00 02 00 00 00 [ 6680.755436] em28xx #0: i2c eeprom 20: 1e 00 10 10 00 00 00 00 00 00 00 00 00 00 00 00 [ 6680.755463] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 01 01 00 00 00 00 [ 6680.755489] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6680.755515] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6680.755540] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 18 03 30 00 30 00 [ 6680.755566] em28xx #0: i2c eeprom 70: 30 00 32 00 38 00 31 00 39 00 33 00 34 00 38 00 [ 6680.755592] em28xx #0: i2c eeprom 80: 00 00 18 03 57 00 69 00 6e 00 54 00 56 00 20 00 [ 6680.755618] em28xx #0: i2c eeprom 90: 55 00 53 00 42 00 32 00 00 00 00 00 00 00 00 00 [ 6680.755644] em28xx #0: i2c eeprom a0: 84 12 00 00 05 50 1a 7f 08 56 23 1c a4 16 16 8d [ 6680.755670] em28xx #0: i2c eeprom b0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 40 14 05 [ 6680.755697] em28xx #0: i2c eeprom c0: 2b 00 74 02 01 0c 03 79 d5 00 00 00 00 00 00 00 [ 6680.755723] em28xx #0: i2c eeprom d0: 84 12 00 00 05 50 1a 7f 08 56 23 1c a4 16 16 8d [ 6680.755749] em28xx #0: i2c eeprom e0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 40 14 05 [ 6680.755775] em28xx #0: i2c eeprom f0: 2b 00 74 02 01 0c 03 79 d5 00 00 00 00 00 00 00 [ 6680.755803] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xf44042ea [ 6680.755808] em28xx #0: EEPROM info: [ 6680.755811] em28xx #0: I2S audio, sample rate=32k [ 6680.755815] em28xx #0: 500mA max power [ 6680.755820] em28xx #0: Table at 0x24, strings=0x1882, 0x186a, 0x [ 6680.775332] tveeprom 1-0050: Hauppauge model 42012, rev C186, serial# 2819348 [ 6680.775341] tveeprom 1-0050: tuner model is Philips FQ1236 MK3 (idx 86, type 43) [ 6680.775347] tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08) [ 6680.775353] tveeprom 1-0050: audio processor is MSP3445 (idx 12) [ 6680.775358] tveeprom 1-0050: has radio [ 6680.856348] msp3400 1-0044: MSP3445G-B8 found @ 0x88 (em28xx #0) [ 6680.856355] msp3400 1-0044: msp3400 supports radio, mode is autodetect and autoselect [ 6680.875282] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [ 6680.938362] tuner 1-0043: chip found @ 0x86 (em28xx #0) [ 6680.969181] tda9887 1-0043: creating new instance [ 6680.969188] tda9887 1-0043: tda988[5/6/7] found [ 6680.969194] tuner 1-0043: type set to tda9887 [ 6680.969199] tuner 1-0043: tv freq set to 0.00 [ 6680.969205] tuner 1-0043: TV freq (0.00) out of range (44-958) [ 6680.980394] tuner 1-0043: em28xx #0 tuner I2C addr 0x86 with type 74 used for 0x0e [ 6680.998131] tuner 1-0063: Setting mode_mask to 0x0e [ 6680.998139] tuner 1-0063: chip found @ 0xc6 (em28xx #0) [ 6680.998144] tuner 1-0063: tuner 0x63: Tuner type absent [ 6680.998159] tuner 1-0043: Calling set_type_addr for type=43, addr=0x63, mode=0x06, config=0x00 [ 6680.998166] tuner 1-0043: set addr discarded for type 74, mask e. Asked to change tuner at addr 0x63, with mask 6 [ 6680.998174] tuner 1-0063: Calling set_type_addr for type=43, addr=0x63, mode=0x06, config=0x00 [ 6680.998179] tuner 1-0063: defining GPIO callback [ 6681.031219] tuner-simple 1-0063: creating new instance [ 6681.031228] tuner-simple 1-0063: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) [ 6681.031236] tuner 1-0063: type set to Philips NTSC MK3 (FM1236MK3 or FM1236/F) [ 6681.031242] tuner 1-0063: tv freq set to 400.00 [ 6681.050237] tuner 1-0063: em28xx #0 tuner I2C addr 0xc6 with type 43 used for 0x0e [ 6681.060247] tuner 1-0043: switching to v4l2 [ 6681.060255] tuner 1-0043: tv freq set to 567.25 [ 6681.070203] tuner 1-0063: switching to v4l2 [ 6681.070210] tuner 1-0063: tv freq set to 567.25 [ 6681.090443] em28xx #0: Config register raw data: 0x20 [ 6681.090448] em28xx #0: I2S Audio (3 sample rates) [ 6681.090452] em28xx #0: No AC97 audio processor [ 6681.261112] tvp5150 1-005c: tvp5150am1 detected. [ 6683.142855] em28xx #0: v4l2 driver version 0.1.2 [ 6683.560549] em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 [ 6683.560560] tuner 1-0043: Putting
Re: [RESEND][PATCH] video: Initial support for ADV7180
Em Mon, 15 Jun 2009 17:13:28 +0200
Richard Röjfors richard.rojfors@mocean-labs.com escreveu:
This is an initial driver for Analog Devices ADV7180 Video Decoder.
So far it only supports query standard.
Hmm... it seems too preliminar for merging. Also, as this is an i2c ancillary
driver, it would be interesting if you could send it together with the bridge
or platform driver that uses it.
Cheers,
Mauro.
Signed-off-by: Richard Röjfors richard.rojfors@mocean-labs.com
---
Index: linux-2.6.30-rc7/drivers/media/video/adv7180.c
===
--- linux-2.6.30-rc7/drivers/media/video/adv7180.c(revision 0)
+++ linux-2.6.30-rc7/drivers/media/video/adv7180.c(revision 867)
@@ -0,0 +1,221 @@
+/*
+ * adv7180.c Analog Devices ADV7180 video decoder driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/i2c-id.h
+#include media/v4l2-ioctl.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+
+#define ADV7180_INPUT_CONTROL_REG0x00
+#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM0x00
+#define ADV7180_AUTODETECT_ENABLE_REG0x07
+#define ADV7180_AUTODETECT_DEFAULT 0x7f
+
+
+#define ADV7180_STATUS1_REG 0x10
+#define ADV7180_STATUS1_AUTOD_MASK 0x70
+#define ADV7180_STATUS1_AUTOD_NTSM_M_J 0x00
+#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
+#define ADV7180_STATUS1_AUTOD_PAL_M 0x20
+#define ADV7180_STATUS1_AUTOD_PAL_60 0x30
+#define ADV7180_STATUS1_AUTOD_PAL_B_G0x40
+#define ADV7180_STATUS1_AUTOD_SECAM 0x50
+#define ADV7180_STATUS1_AUTOD_PAL_COMB 0x60
+#define ADV7180_STATUS1_AUTOD_SECAM_525 0x70
+
+#define ADV7180_IDENT_REG 0x11
+#define ADV7180_ID_7180 0x18
+
+
+static unsigned short normal_i2c[] = { 0x42 1, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+struct adv7180_state {
+ struct v4l2_subdev sd;
+};
+
+static v4l2_std_id determine_norm(struct i2c_client *client)
+{
+ u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
+
+ switch (status1 ADV7180_STATUS1_AUTOD_MASK) {
+ case ADV7180_STATUS1_AUTOD_NTSM_M_J:
+ return V4L2_STD_NTSC_M_JP;
+ case ADV7180_STATUS1_AUTOD_NTSC_4_43:
+ return V4L2_STD_NTSC_443;
+ case ADV7180_STATUS1_AUTOD_PAL_M:
+ return V4L2_STD_PAL_M;
+ case ADV7180_STATUS1_AUTOD_PAL_60:
+ return V4L2_STD_PAL_60;
+ case ADV7180_STATUS1_AUTOD_PAL_B_G:
+ return V4L2_STD_PAL;
+ case ADV7180_STATUS1_AUTOD_SECAM:
+ return V4L2_STD_SECAM;
+ case ADV7180_STATUS1_AUTOD_PAL_COMB:
+ return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
+ case ADV7180_STATUS1_AUTOD_SECAM_525:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7180_state, sd);
+}
+
+static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ *(v4l2_std_id *)std = determine_norm(client);
+ return 0;
+}
+
+static int adv7180_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+ return -EINVAL;
+}
+
+static int adv7180_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+ return -EINVAL;
+}
+
+static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_ADV7180, 0);
+}
+
+static int adv7180_log_status(struct v4l2_subdev *sd)
+{
+ v4l2_info(sd, Normal operation\n);
+ return 0;
+}
+
+static irqreturn_t adv7180_irq(int irq, void *devid)
+{
+ return IRQ_NONE;
+}
+
+static const struct v4l2_subdev_video_ops adv7180_video_ops = {
+ .querystd = adv7180_querystd,
+};
+
+static const struct v4l2_subdev_core_ops adv7180_core_ops = {
+ .log_status =
[PATCH 43/64] media: remove driver_data direct access of struct device
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: Mauro Carvalho Chehab mche...@infradead.org
Acked-by: Mike Isely is...@pobox.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/media/dvb/firewire/firedtv-1394.c |4 ++--
drivers/media/dvb/firewire/firedtv-dvb.c|2 +-
drivers/media/video/pvrusb2/pvrusb2-sysfs.c | 22 +++---
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/dvb/firewire/firedtv-1394.c
b/drivers/media/dvb/firewire/firedtv-1394.c
index 4e20765..2b6eeea 100644
--- a/drivers/media/dvb/firewire/firedtv-1394.c
+++ b/drivers/media/dvb/firewire/firedtv-1394.c
@@ -225,7 +225,7 @@ fail_free:
static int node_remove(struct device *dev)
{
- struct firedtv *fdtv = dev-driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(dev);
fdtv_dvb_unregister(fdtv);
@@ -242,7 +242,7 @@ static int node_remove(struct device *dev)
static int node_update(struct unit_directory *ud)
{
- struct firedtv *fdtv = ud-device.driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(ud-device);
if (fdtv-isochannel = 0)
cmp_establish_pp_connection(fdtv, fdtv-subunit,
diff --git a/drivers/media/dvb/firewire/firedtv-dvb.c
b/drivers/media/dvb/firewire/firedtv-dvb.c
index 9d308dd..5742fde 100644
--- a/drivers/media/dvb/firewire/firedtv-dvb.c
+++ b/drivers/media/dvb/firewire/firedtv-dvb.c
@@ -268,7 +268,7 @@ struct firedtv *fdtv_alloc(struct device *dev,
if (!fdtv)
return NULL;
- dev-driver_data= fdtv;
+ dev_set_drvdata(dev, fdtv);
fdtv-device= dev;
fdtv-isochannel= -1;
fdtv-voltage = 0xff;
diff --git a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
index 299c1cb..6c23456 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -539,7 +539,7 @@ static void class_dev_destroy(struct pvr2_sysfs *sfp)
sfp-attr_unit_number);
}
pvr2_sysfs_trace(Destroying class_dev id=%p,sfp-class_dev);
- sfp-class_dev-driver_data = NULL;
+ dev_set_drvdata(sfp-class_dev, NULL);
device_unregister(sfp-class_dev);
sfp-class_dev = NULL;
}
@@ -549,7 +549,7 @@ static ssize_t v4l_minor_number_show(struct device
*class_dev,
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -561,7 +561,7 @@ static ssize_t bus_info_show(struct device *class_dev,
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_bus_info(sfp-channel.hdw));
@@ -572,7 +572,7 @@ static ssize_t hdw_name_show(struct device *class_dev,
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_type(sfp-channel.hdw));
@@ -583,7 +583,7 @@ static ssize_t hdw_desc_show(struct device *class_dev,
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_desc(sfp-channel.hdw));
@@ -595,7 +595,7 @@ static ssize_t v4l_radio_minor_number_show(struct device
*class_dev,
char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -607,7 +607,7 @@ static ssize_t unit_number_show(struct device *class_dev,
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp =
