RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Oops! I thought you are going to merge the pull request from Hans and send them for comments like you did for DM6467 patches. Please confirm. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Friday, July 10, 2009 4:51 PM To: 'Mauro Carvalho Chehab' Cc: Hans Verkuil; linux-media@vger.kernel.org Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Mauro, Thanks for your support. I will wait for the comments. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Friday, July 10, 2009 4:25 PM To: Karicheri, Muralidharan Cc: Hans Verkuil; linux-media@vger.kernel.org Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Thu, 9 Jul 2009 09:18:47 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Could you please let me know what your plans are for this pull request? Murali, The arm Maintainer should ack on the patches that touch arch/arm. After having it, I'll analyze the patches again and, if not too late, and if Russell acks on having this for 2.6.31, I'll send it upstream. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 10 Jul 2009 15:54:21 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Oops! I thought you are going to merge the pull request from Hans and send them for comments like you did for DM6467 patches. In the case of dm6467, I only noticed the lack of Russell ack after merging it at -hg. Due to that, I needed to do a hack on my local -git copy. It is much better if we do the opposite: get first the arm ack, and then merge everything on -hg and -git. In order to speedup the process, could you please send the two patches to Russell, c/c me and linux-media ML (one patch per email, inlined)? Thanks, Mauro. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Please excuse me to ask these silly questions. Since I am not much familiar with the process, I need some help here. The arm patches are attached in Hans original pull request. Is it Okay to 1) forward the same to Russel, cc you and request his comment or 2) forward the original patches I had sent to Hans. In the case of DaVinci drivers, Hans is integrating and sending pull request. So option 1) seems right to me. Any comments? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Friday, July 10, 2009 5:08 PM To: Karicheri, Muralidharan Cc: Karicheri, Muralidharan; Hans Verkuil; linux-media@vger.kernel.org Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Fri, 10 Jul 2009 15:54:21 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Oops! I thought you are going to merge the pull request from Hans and send them for comments like you did for DM6467 patches. In the case of dm6467, I only noticed the lack of Russell ack after merging it at -hg. Due to that, I needed to do a hack on my local -git copy. It is much better if we do the opposite: get first the arm ack, and then merge everything on -hg and -git. In order to speedup the process, could you please send the two patches to Russell, c/c me and linux-media ML (one patch per email, inlined)? Thanks, Mauro. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, I have forwarded the two patches to Russell as asked in your email. Let me if it doesn't look right. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Friday, July 10, 2009 4:20 PM To: Hans Verkuil Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Mon, 6 Jul 2009 20:24:44 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework - tvp514x: formatting comments as per kernel documentation - v4l: vpfe capture bridge driver for DM355 and DM6446 - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. Hopefully these changes can be merged into 2.6.31. I have attached two arch/arm patches that need to be applied to the git tree. These patches should be applied after merging this tree. I'm not seeing Rusell (arm maintainer) ack on those patches. Could you please send him those patches C/C me, and asking his ack? Btw. I'm still waiting for the fixes asked by him in order to forward the arm dm646x patch (and the rest of the series) upstream. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 10 Jul 2009 16:13:05 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Please excuse me to ask these silly questions. Since I am not much familiar with the process, I need some help here. The arm patches are attached in Hans original pull request. Is it Okay to 1) forward the same to Russel, cc you and request his comment or 2) forward the original patches I had sent to Hans. In the case of DaVinci drivers, Hans is integrating and sending pull request. So option 1) seems right to me. Kernel maintainers don't like to see more than one patch per email, since this breaks all merge scripts and require manual work. So, people should always send one patch per email. So, answering your question, (2) is the proper way. You should warn Russell that the merge will happen via my tree, to avoid merge conflicts between his and my tree. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 10 Jul 2009 16:35:09 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, I have forwarded the two patches to Russell as asked in your email. Let me if it doesn't look right. OK. The emails you sent him is the proper way ;) 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Could you please let me know what your plans are for this pull request? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Tuesday, July 07, 2009 10:42 AM To: 'Hans Verkuil'; linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Mauro, Will you be able to pull this for 2.6.31 ? Thanks. 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, July 06, 2009 2:25 PM To: linux-media@vger.kernel.org Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework - tvp514x: formatting comments as per kernel documentation - v4l: vpfe capture bridge driver for DM355 and DM6446 - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. Hopefully these changes can be merged into 2.6.31. I have attached two arch/arm patches that need to be applied to the git tree. These patches should be applied after merging this tree. I've compiled this driver against the latest Linus' git tree. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++ b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 321 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 198 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/Makefile |6 linux/drivers/media/video/tvp514x.c| 1154 - linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 20 files changed, 6284 insertions(+), 660 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro,
Will you be able to pull this for 2.6.31 ?
Thanks.
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, July 06, 2009 2:25 PM
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for
the following:
- tvp514x: Migration to sub-device framework
- tvp514x: formatting comments as per kernel documentation
- v4l: vpfe capture bridge driver for DM355 and DM6446
- v4l: ccdc hw device header file for vpfe capture
- v4l: dm355 ccdc module for vpfe capture driver
- v4l: dm644x ccdc module for vpfe capture driver
- v4l: ccdc types used across ccdc modules for vpfe capture driver
- v4l: common vpss module for video drivers
- v4l: Makefile and config files for vpfe capture driver
- v4l: davinci drivers should only be compiled for kernels = 2.6.31.
Hopefully these changes can be merged into 2.6.31.
I have attached two arch/arm patches that need to be applied to the git
tree.
These patches should be applied after merging this tree.
I've compiled this driver against the latest Linus' git tree.
Thanks,
Hans
diffstat:
b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110
b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++
b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++
b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++
b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 +
b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124
+
b/linux/drivers/media/video/davinci/vpss.c | 301 ++
b/linux/include/media/davinci/ccdc_types.h | 43
b/linux/include/media/davinci/dm355_ccdc.h | 321 ++
b/linux/include/media/davinci/dm644x_ccdc.h| 184 +
b/linux/include/media/davinci/vpfe_capture.h | 198 +
b/linux/include/media/davinci/vpfe_types.h | 51
b/linux/include/media/davinci/vpss.h | 69
linux/drivers/media/video/Kconfig | 49
linux/drivers/media/video/Makefile |2
linux/drivers/media/video/davinci/Makefile |6
linux/drivers/media/video/tvp514x.c| 1154 -
linux/drivers/media/video/tvp514x_regs.h | 10
linux/include/media/tvp514x.h |4
v4l/versions.txt |7
20 files changed, 6284 insertions(+), 660 deletions(-)
--
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��٥
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the
following:
- tvp514x: Migration to sub-device framework
- tvp514x: formatting comments as per kernel documentation
- v4l: vpfe capture bridge driver for DM355 and DM6446
- v4l: ccdc hw device header file for vpfe capture
- v4l: dm355 ccdc module for vpfe capture driver
- v4l: dm644x ccdc module for vpfe capture driver
- v4l: ccdc types used across ccdc modules for vpfe capture driver
- v4l: common vpss module for video drivers
- v4l: Makefile and config files for vpfe capture driver
- v4l: davinci drivers should only be compiled for kernels = 2.6.31.
Hopefully these changes can be merged into 2.6.31.
I have attached two arch/arm patches that need to be applied to the git tree.
These patches should be applied after merging this tree.
I've compiled this driver against the latest Linus' git tree.
Thanks,
Hans
diffstat:
b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110
b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++
b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++
b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++
b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 +
b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124 +
b/linux/drivers/media/video/davinci/vpss.c | 301 ++
b/linux/include/media/davinci/ccdc_types.h | 43
b/linux/include/media/davinci/dm355_ccdc.h | 321 ++
b/linux/include/media/davinci/dm644x_ccdc.h| 184 +
b/linux/include/media/davinci/vpfe_capture.h | 198 +
b/linux/include/media/davinci/vpfe_types.h | 51
b/linux/include/media/davinci/vpss.h | 69
linux/drivers/media/video/Kconfig | 49
linux/drivers/media/video/Makefile |2
linux/drivers/media/video/davinci/Makefile |6
linux/drivers/media/video/tvp514x.c| 1154 -
linux/drivers/media/video/tvp514x_regs.h | 10
linux/include/media/tvp514x.h |4
v4l/versions.txt |7
20 files changed, 6284 insertions(+), 660 deletions(-)
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
From: m-kariche...@ti.com
To: hverk...@xs4all.nl,
mche...@infradead.org
Cc: Muralidharan Karicheri m-kariche...@ti.com
Subject: [PATCH 8/11 - v3] DM6446 platform changes for vpfe capture driver
Date: Mon, 6 Jul 2009 13:32:37 -0400
From: Muralidharan Karicheri m-kariche...@ti.com
DM644x platform and board setup
This adds plarform and board setup changes required to support
vpfe capture driver on DM644x
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Reviewed by: Kevin Hilman khil...@deeprootsystems.com
Reviewed by: David Brownell davi...@pacbell.net
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Linus' GIT Tree
arch/arm/mach-davinci/board-dm644x-evm.c| 72 ++-
arch/arm/mach-davinci/dm644x.c | 56 +
arch/arm/mach-davinci/include/mach/dm644x.h |2 +
3 files changed, 128 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index d9d4045..151a622 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,7 +28,8 @@
#include linux/io.h
#include linux/phy.h
#include linux/clk.h
-
+#include linux/videodev2.h
+#include media/tvp514x.h
#include asm/setup.h
#include asm/mach-types.h
@@ -195,6 +196,72 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
};
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hans,
That was quick. Thanks for your support.
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, July 06, 2009 2:25 PM
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for
the following:
- tvp514x: Migration to sub-device framework
- tvp514x: formatting comments as per kernel documentation
- v4l: vpfe capture bridge driver for DM355 and DM6446
- v4l: ccdc hw device header file for vpfe capture
- v4l: dm355 ccdc module for vpfe capture driver
- v4l: dm644x ccdc module for vpfe capture driver
- v4l: ccdc types used across ccdc modules for vpfe capture driver
- v4l: common vpss module for video drivers
- v4l: Makefile and config files for vpfe capture driver
- v4l: davinci drivers should only be compiled for kernels = 2.6.31.
Hopefully these changes can be merged into 2.6.31.
I have attached two arch/arm patches that need to be applied to the git
tree.
These patches should be applied after merging this tree.
I've compiled this driver against the latest Linus' git tree.
Thanks,
Hans
diffstat:
b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110
b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++
b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++
b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++
b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 +
b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124
+
b/linux/drivers/media/video/davinci/vpss.c | 301 ++
b/linux/include/media/davinci/ccdc_types.h | 43
b/linux/include/media/davinci/dm355_ccdc.h | 321 ++
b/linux/include/media/davinci/dm644x_ccdc.h| 184 +
b/linux/include/media/davinci/vpfe_capture.h | 198 +
b/linux/include/media/davinci/vpfe_types.h | 51
b/linux/include/media/davinci/vpss.h | 69
linux/drivers/media/video/Kconfig | 49
linux/drivers/media/video/Makefile |2
linux/drivers/media/video/davinci/Makefile |6
linux/drivers/media/video/tvp514x.c| 1154 -
linux/drivers/media/video/tvp514x_regs.h | 10
linux/include/media/tvp514x.h |4
v4l/versions.txt |7
20 files changed, 6284 insertions(+), 660 deletions(-)
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
Em Fri, 26 Jun 2009 21:01:50 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the following: - ARM: DaVinci: DM646x Video: VPIF driver - ARM: DaVinci: DM646x Video: Add VPIF display driver - ARM: DaVinci: DM646x Video: Makefile and config files modifications for Display - ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking Note that these four patches depend on the attached platform patch that should be applied to the git tree first. If possible, it would be great if this (like the vpfe capture driver) can be merged for 2.6.31. One note about your changesets: Please, don't use both Reviewed-by and Signed-off-by. The first tag is meant for patches that you reviewed, but you are not part of the submission chain, while the second one means that you reviewed and you're submitting to a maintainer. I'm fixing this at the -git patches. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
On Sun, Jul 05, 2009 at 09:51:55AM -0300, Mauro Carvalho Chehab wrote:
Hmm... I'm not seeing Russel ack on the arch/arm patch. Russel, could you
please review the enclosed patch? Would this be ok for 2.6.31?
I'm not sure who this Russel is!
@@ -207,6 +220,40 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
...
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (mux_mode == 1)
+ val = ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
So what prevents this 'cpld_client' being removed mid-operation? What if
'cpld_client' isn't found for whatever reason?
+static struct platform_device vpif_display_dev = {
+ .name = vpif_display,
+ .id = -1,
+ .dev= {
+ .dma_mask = vpif_dma_mask,
+ .coherent_dma_mask = DMA_32BIT_MASK,
Shouldn't this be DMA_BIT_MASK(32) ?
--
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-dm646x
Em Sun, 5 Jul 2009 15:46:32 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Sun, Jul 05, 2009 at 09:51:55AM -0300, Mauro Carvalho Chehab wrote: Hmm... I'm not seeing Russel ack on the arch/arm patch. Russel, could you please review the enclosed patch? Would this be ok for 2.6.31? I'm not sure who this Russel is! Sorry for the typo, Russell. As double consonants are forbidden on my mother tong (except for ss), sometimes my fingers refuse to type a double consonant :) 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 14:39:55 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Thanks for responding...
You should note that I'm not asking you to remove that code, but just to
use
the already existing color balance ioctls, for the existing features, or
otherwise to discuss the need of extra controls.
Ok.
The case of image color controlling, we already have several controls:
#define V4L2_CID_SATURATION (V4L2_CID_BASE+2)
#define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14)
#define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15)
#define V4L2_CID_GAMMA (V4L2_CID_BASE+16)
#define V4L2_CID_GAIN (V4L2_CID_BASE+19)
Also, some got deprecated, since they were just duplicating existing
controls,
using a different way, as discussed at ML:
Ok. I need to investigate this when I support control IOCTLs in vpfe
capture. As of now control IOCTLs are not supported in vpfe capture.
#define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated */
#define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */
So, you basically need to rewrite your logic in order to control the device
in
terms of gain and red/blue balance.
Ok. I get it.
Hans had an issue with the way we implemented control IOCTL handling in the
driver. So the piece of code you had objected to is redundant. I will clean
it up or modify it when I support control IOCTLs handling in vpfe capture or
alternately remove it using a separate patch. So please go ahead and merge
the patches if everything else looks good.
I guess you didn't understand me. For me to pull from this pull request, I need
to be sure that no uneeded/duplicated/undocumented userspace controls are added
to V4L2 API.
So, we need to solve all PRIVATE controls:
$ grep PRIVATE /tmp/newpatches/hg_v4l-dvb-vpfe-cap_*
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_02.patch:+#define
VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_R_GAIN
(V4L2_CID_PRIVATE_BASE + 0)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GR_GAIN
(V4L2_CID_PRIVATE_BASE + 1)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GB_GAIN
(V4L2_CID_PRIVATE_BASE + 2)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_B_GAIN
(V4L2_CID_PRIVATE_BASE + 3)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_OFFSET
(V4L2_CID_PRIVATE_BASE + 4)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_MAX
(V4L2_CID_PRIVATE_BASE + 5)
(btw, the grep above also showed another of such control at the second patch)
Most of the above controls are duplicated, in the sense that the current color
controls (eventually with some math) are capable of controlling the color gains.
The CCDC_CID_MAX is not even implemented.
The VPFE_CMD_S_CCDC_RAW_PARAMS and CCDC_CID_OFFSET are not properly documented,
so, I have no idea about what you want to control with them.
One quick alternative for them, while they are being under discussions, would
be to put them into #if 0/#endif blocks, but you need to provide a patch to
solve it for me to merge VPFE
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro,
I will recreate the patches to take out these controls from
the code and take care of other comments you have and
request Hans to send you a pull request.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Thursday, July 02, 2009 7:39 AM
To: Karicheri, Muralidharan
Cc: Hans Verkuil; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 14:39:55 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Thanks for responding...
You should note that I'm not asking you to remove that code, but just to
use
the already existing color balance ioctls, for the existing features, or
otherwise to discuss the need of extra controls.
Ok.
The case of image color controlling, we already have several controls:
#define V4L2_CID_SATURATION (V4L2_CID_BASE+2)
#define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14)
#define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15)
#define V4L2_CID_GAMMA (V4L2_CID_BASE+16)
#define V4L2_CID_GAIN (V4L2_CID_BASE+19)
Also, some got deprecated, since they were just duplicating existing
controls,
using a different way, as discussed at ML:
Ok. I need to investigate this when I support control IOCTLs in vpfe
capture. As of now control IOCTLs are not supported in vpfe capture.
#define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated
*/
#define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated
*/
So, you basically need to rewrite your logic in order to control the
device
in
terms of gain and red/blue balance.
Ok. I get it.
Hans had an issue with the way we implemented control IOCTL handling in
the driver. So the piece of code you had objected to is redundant. I will
clean it up or modify it when I support control IOCTLs handling in vpfe
capture or alternately remove it using a separate patch. So please go ahead
and merge the patches if everything else looks good.
I guess you didn't understand me. For me to pull from this pull request, I
need
to be sure that no uneeded/duplicated/undocumented userspace controls are
added
to V4L2 API.
So, we need to solve all PRIVATE controls:
$ grep PRIVATE /tmp/newpatches/hg_v4l-dvb-vpfe-cap_*
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_02.patch:+#define
VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_R_GAIN
(V4L2_CID_PRIVATE_BASE + 0)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GR_GAIN
(V4L2_CID_PRIVATE_BASE + 1)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GB_GAIN
(V4L2_CID_PRIVATE_BASE + 2)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_B_GAIN
(V4L2_CID_PRIVATE_BASE + 3)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_OFFSET
(V4L2_CID_PRIVATE_BASE + 4)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_MAX
(V4L2_CID_PRIVATE_BASE + 5)
(btw, the grep above also showed another of such control at the second
patch)
Most of the above controls are duplicated, in the sense that the current
color
controls (eventually with some math) are capable of controlling the color
gains.
The CCDC_CID_MAX is not even implemented.
The VPFE_CMD_S_CCDC_RAW_PARAMS and CCDC_CID_OFFSET are not properly
documented,
so, I have no idea about what you want to control with them.
One quick alternative for them, while they are being under discussions,
would
be to put them into #if 0/#endif blocks, but you need to provide a patch to
solve it for me to merge VPFE
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Thu, 2 Jul 2009 10:13:08 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, I will recreate the patches to take out these controls from the code and take care of other comments you have and request Hans to send you a pull request. Ok. for me, it is also fine if you just send the new patches, provided that you ask me to pull together with the previous ones. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds
On Tuesday 30 June 2009 17:16:03 Mauro Carvalho Chehab wrote: Em Sat, 20 Jun 2009 14:30:41 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds for the following: - v4l2: add RDS API to videodev2.h - v4l2-spec: finalize the RDS specification. From: Hans Verkuil hverk...@xs4all.nl Priority: normal Signed-off-by: Hans Verkuil hverk...@xs4all.nl --- a/v4l2-spec/biblio.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/biblio.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -158,54 +158,23 @@ 1125-Line High-Definition Production/t 1125-Line High-Definition Production/title /biblioentry -biblioentry id=v4l - abbrevV4L/abbrev +biblioentry id=en50067 + abbrevENnbsp;50067/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorEuropean Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor /authorgroup - titleVideo4Linux API Specification/title - abstract - paraThis file is part of the Linux kernel sources under -filenameDocumentation/video4linux/filename./para - /abstract + titleSpecification of the radio data system (RDS) for VHF/FM sound broadcasting +in the frequency range from 87,5 to 108,0 MHz/title /biblioentry -biblioentry id=v4lprog - abbrevV4LPROG/abbrev +biblioentry id=nrsc4 + abbrevNRSC-4/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorNational Radio Systems Committee +(ulink url=http://www.nrscstandards.org;http://www.nrscstandards.org/ulink)/corpauthor /authorgroup - titleVideo4Linux Programming (a.k.a. The Video4Linux -Book)/title - abstract - paraAbout V4L emphasisdriver/emphasis programming. This -book is part of the Linux kernel DocBook documentation, for example at -ulink url=http://kernelnewbies.org/documents/; -http://kernelnewbies.org/documents//ulink. SGML sources are included -in the kernel sources./para - /abstract - copyright - year2000/year - holderAlan Cox/holder - /copyright + titleNTSC-4: United States RBDS Standard/title /biblioentry /bibliography Hmm.. why are you removing Alan Cox authorship, and adding other organizations there? AFAIK, they never submitted a contribution to V4L2 API, nor I have their and Alan Ack/SOB, that are required for such changes. These are the bibliography entries, not copyright statements or anything. The v4lprog bibliography entry is 1) unused, and 2) the document it refers to does not exist. Hence I removed it. It's a bogus entry, probably a left-over from a very old version of the v4l documentation. The nrsc4 bibliography entry points to the RBDS standard and is referred to from the RDS chapter. This is a bibliography and that has nothing to do with authorship or copyrights or anything like that. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
On Tuesday 30 June 2009 17:19:39 Mauro Carvalho Chehab wrote: Em Tue, 30 Jun 2009 10:06:17 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. I have added this in my vpfe-cap tree. 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] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? +#define CCDC_CID_MAX (V4L2_CID_PRIVATE_BASE + 5) This one doesn't seem to be used. - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. The other patches are ok. Hopefully these changes can be merged into 2.6.31. After having the entire series committed, I'll see if it is still possible to submit it. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 188 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/vpfe_capture.c | 27 linux/drivers/media/video/tvp514x.c| 879 ++ linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 21 files changed, 6346 insertions(+), 555 deletions(-) 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Thanks for looking into this. - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. +#define CCDC_CID_MAX (V4L2_CID_PRIVATE_BASE + 5) This one doesn't seem to be used. This is part of my TODO list as per comments from Hans. So could we merge this and later fix it as part another patch that adds control ioctl handling? - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. The other patches are ok. Hopefully these changes can be merged into 2.6.31. After having the entire series committed, I'll see if it is still possible to submit it. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 188 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/vpfe_capture.c | 27 linux/drivers/media/video/tvp514x.c| 879 ++ linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 21 files changed, 6346 insertions(+), 555 deletions(-) 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds
Em Sat, 20 Jun 2009 14:30:41 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds for the following: - v4l2: add RDS API to videodev2.h - v4l2-spec: finalize the RDS specification. From: Hans Verkuil hverk...@xs4all.nl Priority: normal Signed-off-by: Hans Verkuil hverk...@xs4all.nl --- a/v4l2-spec/biblio.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/biblio.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -158,54 +158,23 @@ 1125-Line High-Definition Production/t 1125-Line High-Definition Production/title /biblioentry -biblioentry id=v4l - abbrevV4L/abbrev +biblioentry id=en50067 + abbrevENnbsp;50067/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorEuropean Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor /authorgroup - titleVideo4Linux API Specification/title - abstract - paraThis file is part of the Linux kernel sources under -filenameDocumentation/video4linux/filename./para - /abstract + titleSpecification of the radio data system (RDS) for VHF/FM sound broadcasting +in the frequency range from 87,5 to 108,0 MHz/title /biblioentry -biblioentry id=v4lprog - abbrevV4LPROG/abbrev +biblioentry id=nrsc4 + abbrevNRSC-4/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorNational Radio Systems Committee +(ulink url=http://www.nrscstandards.org;http://www.nrscstandards.org/ulink)/corpauthor /authorgroup - titleVideo4Linux Programming (a.k.a. The Video4Linux -Book)/title - abstract - paraAbout V4L emphasisdriver/emphasis programming. This -book is part of the Linux kernel DocBook documentation, for example at -ulink url=http://kernelnewbies.org/documents/; -http://kernelnewbies.org/documents//ulink. SGML sources are included -in the kernel sources./para - /abstract - copyright - year2000/year - holderAlan Cox/holder - /copyright + titleNTSC-4: United States RBDS Standard/title /biblioentry /bibliography Hmm.. why are you removing Alan Cox authorship, and adding other organizations there? AFAIK, they never submitted a contribution to V4L2 API, nor I have their and Alan Ack/SOB, that are required for such changes. --- a/v4l2-spec/compat.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/compat.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -1273,9 +1273,8 @@ request code, thus older V4L2 devices wi request code, thus older V4L2 devices will respond with an EINVAL; to the new VIDIOC-QUERYCAP; ioctl./para - paraThere are new fields to identify the driver, a new (as -of yet unspecified) device function -constantV4L2_CAP_RDS_CAPTURE/constant, the + paraThere are new fields to identify the driver, a new RDS +device function constantV4L2_CAP_RDS_CAPTURE/constant, the constantV4L2_CAP_AUDIO/constant flag indicates if the device has any audio connectors, another I/O capability constantV4L2_CAP_ASYNCIO/constant can be flagged. In response to @@ -2291,6 +2290,15 @@ was renamed to structname id=v4l2-chip- /listitem listitem paraNew control constantV4L2_CID_COLORFX/constant was added./para + /listitem + /orderedlist + /section +section + titleV4L2 in Linux 2.6.32/title + orderedlist + listitem + paraFinalized the RDS capture API. See xref linkend=rds for +more information./para /listitem /orderedlist /section --- a/v4l2-spec/dev-rds.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/dev-rds.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -2,38 +2,154 @@ paraThe Radio Data System transmits supplementary information in binary format, for example the station name or travel -information, on a inaudible audio subcarrier of a radio program. This -interface aims at devices capable of receiving and decoding RDS +information, on an inaudible audio subcarrier of a radio program. This +interface is aimed at devices capable of receiving and decoding RDS information./para - paraThe V4L API defines its RDS API as follows./para + paraFor more information see the core RDS standard xref linkend=en50067 +and the RBDS standard xref linkend=nrsc4./para - paraFrom radio devices supporting it, RDS data can be read -with the func-read; function. The
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 10:06:17 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. In the specific case of the userspace API changes like the above, I prefer to have it merged at the original patch 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. I have done so. Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. In the specific case of the userspace API changes like the above, I prefer to have it merged at the original patch So do you expect anything from me on this or will be merged as is? I prefer the second option and I can send another patch to remove this code. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 11:50:29 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. I have done so. Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. In the specific case of the userspace API changes like the above, I prefer to have it merged at the original patch So do you expect anything from me on this or will be merged as is? I prefer the second option and I can send another patch to remove this code. Hmm... the second option is ok, provided that it is at the same pull request of the original patch. I don't want to duplicate controls for existing features. You should note that I'm not asking you to remove that code, but just to use the already existing color balance ioctls, for the existing features, or otherwise to discuss the need of extra controls. The case of image color controlling, we already have several controls: #define V4L2_CID_SATURATION (V4L2_CID_BASE+2) #define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14) #define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15) #define V4L2_CID_GAMMA (V4L2_CID_BASE+16) #define V4L2_CID_GAIN (V4L2_CID_BASE+19) Also, some got deprecated, since they were just duplicating existing controls, using a different way, as discussed at ML: #define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated */ #define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */ So, you basically need to rewrite your logic in order to control the device in terms of gain and red/blue balance. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Thanks for responding... You should note that I'm not asking you to remove that code, but just to use the already existing color balance ioctls, for the existing features, or otherwise to discuss the need of extra controls. Ok. The case of image color controlling, we already have several controls: #define V4L2_CID_SATURATION (V4L2_CID_BASE+2) #define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14) #define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15) #define V4L2_CID_GAMMA (V4L2_CID_BASE+16) #define V4L2_CID_GAIN (V4L2_CID_BASE+19) Also, some got deprecated, since they were just duplicating existing controls, using a different way, as discussed at ML: Ok. I need to investigate this when I support control IOCTLs in vpfe capture. As of now control IOCTLs are not supported in vpfe capture. #define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated */ #define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */ So, you basically need to rewrite your logic in order to control the device in terms of gain and red/blue balance. Ok. I get it. Hans had an issue with the way we implemented control IOCTL handling in the driver. So the piece of code you had objected to is redundant. I will clean it up or modify it when I support control IOCTLs handling in vpfe capture or alternately remove it using a separate patch. So please go ahead and merge the patches if everything else looks good. Thanks once again for your help. Regards, Murali 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Em Fri, 26 Jun 2009 08:52:58 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Friday 26 June 2009 08:17:05 Hans Verkuil wrote: On Thursday 25 June 2009 20:18:06 Karicheri, Muralidharan wrote: Hans, I have tried to pull the latest from git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git It is there, at for_linus branch. If you pull master branch, you'll just get a (probably outdated) copy of Linus tree. I can't see it part of this. Which GIT tree can I use to see the sub dev api changes or latest that went into 2.6.31? Is vpfe capture part of 2.6.31? Ah, it is not yet pulled into the git tree. Mauro did send a pull request for this to Linus, though. So I hope it will appear soon. Oops, I didn't look carefully enough. These API changes *are* merged in 2.6.31. I'm using Linus' git tree. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
On Friday 26 June 2009 08:17:05 Hans Verkuil wrote: On Thursday 25 June 2009 20:18:06 Karicheri, Muralidharan wrote: Hans, I have tried to pull the latest from git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git I can't see it part of this. Which GIT tree can I use to see the sub dev api changes or latest that went into 2.6.31? Is vpfe capture part of 2.6.31? Ah, it is not yet pulled into the git tree. Mauro did send a pull request for this to Linus, though. So I hope it will appear soon. Oops, I didn't look carefully enough. These API changes *are* merged in 2.6.31. I'm using Linus' git tree. Regards, Hans Regards, Hans Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Thursday, June 25, 2009 11:18 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 Hi, Mauro, I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture driver patches. So when do you think this will be merged? This has already been merged and is also in the 2.6.31 git tree. I'm very pleased that this is in as that will make life easier for several embedded system developments. Regards, Hans Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, June 20, 2009 9:11 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 Tuesday 23 June 2009 08:45:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - v4l2-spec: add missing V4L2_PIX_FMT_OV511 documentation. Added this patch: - v4l2-common: fix uninitialized variable Note that this variable was only uninitialized when compiled for kernels older than 2.6.26. Regards, Hans Hans, when you modify the videodev2.h header you should also do a 'make spec' to check whether the v4l2-spec still builds. It's easy to forget that, but it's important to keep the spec up to date. Thanks, Hans diffstat: pixfmt.sgml |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) -- 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 Tuesday 23 June 2009 08:45:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - v4l2-spec: add missing V4L2_PIX_FMT_OV511 documentation. Added this patch: - v4l2-common: fix uninitialized variable Note that this variable was only uninitialized when compiled for kernels older than 2.6.26. And this patch: - em28xx: enable new-style i2c API for kernels = 2.6.26, not 2.6.22. This fixes the em28xx driver when v4l-dvb is compiled for kernels 2.6.22-2.6.25. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the
following:
- ARM: DaVinci: DM646x Video: VPIF driver
- ARM: DaVinci: DM646x Video: Add VPIF display driver
- ARM: DaVinci: DM646x Video: Makefile and config files modifications for
Display
- ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking
Note that these four patches depend on the attached platform patch that
should be applied to the git tree first.
If possible, it would be great if this (like the vpfe capture driver) can be
merged for 2.6.31.
Thanks,
Hans
diffstat:
b/linux/drivers/media/video/davinci/Makefile |9
b/linux/drivers/media/video/davinci/vpif.c | 234 ++
b/linux/drivers/media/video/davinci/vpif.h | 632 +++
b/linux/drivers/media/video/davinci/vpif_display.c | 1664 +
b/linux/drivers/media/video/davinci/vpif_display.h | 175 ++
linux/drivers/media/video/Kconfig | 22
linux/drivers/media/video/Makefile |2
linux/drivers/media/video/davinci/vpif_display.c | 31
8 files changed, 2761 insertions(+), 8 deletions(-)
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
[PATCH] ARM: DaVinci: DM646x Video: Platform and board specific setup
From: Chaithrika U S chaithr...@ti.com
Platform specific display device setup for DM646x EVM
Add platform device and resource structures. Also define a platform specific
clock setup function that can be accessed by the driver to configure the clock
and CPLD.
Signed-off-by: Chaithrika U S chaithr...@ti.com
Signed-off-by: Manjunath Hadli m...@ti.com
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
arch/arm/mach-davinci/board-dm646x-evm.c| 122 +++
arch/arm/mach-davinci/dm646x.c | 62 ++
arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
3 files changed, 208 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index e17de63..eb4bd01 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -52,6 +52,19 @@
#define DM646X_EVM_PHY_MASK (0x2)
#define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+#define VIDCLKCTL_OFFSET (0x38)
+#define VSCLKDIS_OFFSET (0x6c)
+
+#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
+#define VCH2CLK_SYSCLK8 (BIT(9))
+#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
+#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
+#define VCH3CLK_SYSCLK8 (BIT(13))
+#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
+
+#define VIDCH2CLK (BIT(10))
+#define VIDCH3CLK (BIT(11))
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 0),
};
@@ -207,6 +220,40 @@ static struct at24_platform_data eeprom_info = {
.context = (void *)0x7f00,
};
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id cpld_video_id[] = {
+ { cpld_video, 0 },
+ { }
+};
+
+static struct i2c_driver cpld_video_driver = {
+ .driver = {
+ .name = cpld_video,
+ },
+ .probe = cpld_video_probe,
+ .remove = cpld_video_remove,
+ .id_table = cpld_video_id,
+};
+
+static void evm_init_cpld(void)
+{
+ i2c_add_driver(cpld_video_driver);
+}
+
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO(24c256, 0x50),
@@ -216,6 +263,9 @@ static struct i2c_board_info __initdata i2c_info[] = {
I2C_BOARD_INFO(pcf8574a, 0x38),
.platform_data = pcf_data,
},
+ {
+ I2C_BOARD_INFO(cpld_video, 0x3B),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
@@ -223,10 +273,81 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (mux_mode == 1)
+ val = ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+
+ value = __raw_readl(base + VIDCLKCTL_OFFSET);
+ value = ~(VCH2CLK_MASK);
+ value = ~(VCH3CLK_MASK);
+
+ if (hd = 1)
+ value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
+ else
+ value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
+
+ __raw_writel(value, base + VIDCLKCTL_OFFSET);
+
+ /* enable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value = ~(VIDCH3CLK |
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
On Friday 26 June 2009 21:01:50 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the following: - ARM: DaVinci: DM646x Video: VPIF driver - ARM: DaVinci: DM646x Video: Add VPIF display driver - ARM: DaVinci: DM646x Video: Makefile and config files modifications for Display - ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking Minor update: by request from Kevin I've removed the 'ARM: ' prefix in the patch subject lines. 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] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hi, Mauro, I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture driver patches. So when do you think this will be merged? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, June 20, 2009 9:11 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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-subdev2
Hans, I have tried to pull the latest from git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git I can't see it part of this. Which GIT tree can I use to see the sub dev api changes or latest that went into 2.6.31? Is vpfe capture part of 2.6.31? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Thursday, June 25, 2009 11:18 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 Hi, Mauro, I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture driver patches. So when do you think this will be merged? This has already been merged and is also in the 2.6.31 git tree. I'm very pleased that this is in as that will make life easier for several embedded system developments. Regards, Hans Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, June 20, 2009 9:11 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Mon, 22 Jun 2009 11:02:58 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Hi, Snip -/** +/* * struct tvp514x_decoder - TVP5146/47 decoder object - * @v4l2_int_device: Slave handle - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device + * @sd: Subdevice Slave handle * @tvp514x_regs: copy of hw's regs with preset values. * @pdata: Board specific - * @client: I2C client data - * @id: Entry from I2C table * @ver: Chip version - * @state: TVP5146/47 decoder state - detected or not-detected + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. * @pix: Current pixel format * @num_fmts: Number of formats * @fmt_list: Format list * @current_std: Current standard * @num_stds: Number of standards * @std_list: Standards list - * @route: input and output routing at chip level + * @input: Input routing at chip level + * @output: Output routing at chip level */ Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper format. Basically, it should be like this example: /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. **/ But kernel-doc-nano-HOWTO.txt says it should be of the form /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. */ Only one * followed by slash as */, not **/ as you have mentioned. Please confirm so that I can send you a patch to correct this. You're right. It seems that I was using an older version of the doc, since it used to be like above, on the past versions of the doc: commit f40b45a2e45b0f02aeedfcfbb28d8e2d4b8b86b1 Author: Randy Dunlap randy.dun...@oracle.com Date: Wed Feb 11 13:04:31 2009 -0800 kernel-doc: preferred ending marker and examples Fix kernel-doc-nano-HOWTO.txt to use */ as the ending marker in kernel-doc examples and state that */ is the preferred ending marker. Signed-off-by: Randy Dunlap randy.dun...@oracle.com Reported-by: Robert Love robert.w.l...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index d73fbd2..026ec7d 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt @@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-doc scripts, and any comment so marked must be in kernel-doc format. Do not use /** to be begin a comment block unless the comment block contains kernel-doc formatted comments. The closing comment marker for -kernel-doc comments can be either */ or **/. +kernel-doc comments can be either */ or **/, but */ is +preferred in the Linux kernel tree. Kernel-doc comments should be placed just before the function or data structure being described. @@ -63,7 +64,7 @@ Example kernel-doc function comment: * comment lines. * * The longer description can have multiple paragraphs. - **/ + */ The first line, with the short description, must be on a single line. @@ -85,7 +86,7 @@ Example kernel-doc data structure comment. * perhaps with more lines and words. * * Longer description of this structure. - **/ + */ The kernel-doc function comments describe each parameter to the function, in order, with the @name lines. -- 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-vpfe-cap
Hi, Snip -/** +/* * struct tvp514x_decoder - TVP5146/47 decoder object - * @v4l2_int_device: Slave handle - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device + * @sd: Subdevice Slave handle * @tvp514x_regs: copy of hw's regs with preset values. * @pdata: Board specific - * @client: I2C client data - * @id: Entry from I2C table * @ver: Chip version - * @state: TVP5146/47 decoder state - detected or not-detected + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. * @pix: Current pixel format * @num_fmts: Number of formats * @fmt_list: Format list * @current_std: Current standard * @num_stds: Number of standards * @std_list: Standards list - * @route: input and output routing at chip level + * @input: Input routing at chip level + * @output: Output routing at chip level */ Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper format. Basically, it should be like this example: /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. **/ But kernel-doc-nano-HOWTO.txt says it should be of the form /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. */ Only one * followed by slash as */, not **/ as you have mentioned. Please confirm so that I can send you a patch to correct this. -- 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-vpfe-cap
Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework Hmm... the kernel-doc format is wrong on all function description comment changes on tvp514x: -/** +/* * struct tvp514x_decoder - TVP5146/47 decoder object - * @v4l2_int_device: Slave handle - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device + * @sd: Subdevice Slave handle * @tvp514x_regs: copy of hw's regs with preset values. * @pdata: Board specific - * @client: I2C client data - * @id: Entry from I2C table * @ver: Chip version - * @state: TVP5146/47 decoder state - detected or not-detected + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. * @pix: Current pixel format * @num_fmts: Number of formats * @fmt_list: Format list * @current_std: Current standard * @num_stds: Number of standards * @std_list: Standards list - * @route: input and output routing at chip level + * @input: Input routing at chip level + * @output: Output routing at chip level */ Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper format. Basically, it should be like this example: /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. **/ - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. I'll try to analyze those remaining patches later today. Unfortunately, I'm very busy this weekend finishing some pending work. Hopefully these changes can be merged into 2.6.31. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 188 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/vpfe_capture.c | 27 linux/drivers/media/video/tvp514x.c| 879 ++ linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 21 files changed, 6346 insertions(+), 555 deletions(-) -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Em Sat, 20 Jun 2009 09:45:41 -0700 (PDT) Trent Piepho xy...@speakeasy.org escreveu: On Sat, 20 Jun 2009, Hans Verkuil wrote: - compat: fix __fls check for the arm architecture. This one isn't quite right. The __fls defined for arm in 2.6.27 (between v2.6.26-7260-g0c65f45 and v2.6.28-rc6-187-g94fc733) isn't the same as the __fls() used everwhere else in the kernel. This alternate fix should work. 01/01: compat: Fix __fls for certain ARM kernels http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=518b7754cd3d Agreed. I cherry-picked Hans patch and merged ~tap/fix tree to fix the __fls(). 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework Hmm... the kernel-doc format is wrong on all function description comment changes on tvp514x: I'm assuming this can be corrected in a separate patch later? I don't think this is a blocking issue. Muralidharan, can you take a look at this? Regards, Hans -/** +/* * struct tvp514x_decoder - TVP5146/47 decoder object - * @v4l2_int_device: Slave handle - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device + * @sd: Subdevice Slave handle * @tvp514x_regs: copy of hw's regs with preset values. * @pdata: Board specific - * @client: I2C client data - * @id: Entry from I2C table * @ver: Chip version - * @state: TVP5146/47 decoder state - detected or not-detected + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. * @pix: Current pixel format * @num_fmts: Number of formats * @fmt_list: Format list * @current_std: Current standard * @num_stds: Number of standards * @std_list: Standards list - * @route: input and output routing at chip level + * @input: Input routing at chip level + * @output: Output routing at chip level */ Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper format. Basically, it should be like this example: /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. **/ - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. I'll try to analyze those remaining patches later today. Unfortunately, I'm very busy this weekend finishing some pending work. Hopefully these changes can be merged into 2.6.31. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 188 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/vpfe_capture.c | 27 linux/drivers/media/video/tvp514x.c| 879 ++ linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 21 files changed, 6346 insertions(+), 555 deletions(-) -- 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-vpfe-cap
Em Sun, 21 Jun 2009 20:20:29 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework Hmm... the kernel-doc format is wrong on all function description comment changes on tvp514x: I'm assuming this can be corrected in a separate patch later? I don't think this is a blocking issue. Yes, sure this is not blocking. BTW, please, _never_ send me an email to a public list C/C a subscribers-only list: Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Is being held until the list moderator can review it for approval. Muralidharan, can you take a look at this? Regards, Hans -/** +/* * struct tvp514x_decoder - TVP5146/47 decoder object - * @v4l2_int_device: Slave handle - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device + * @sd: Subdevice Slave handle * @tvp514x_regs: copy of hw's regs with preset values. * @pdata: Board specific - * @client: I2C client data - * @id: Entry from I2C table * @ver: Chip version - * @state: TVP5146/47 decoder state - detected or not-detected + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. * @pix: Current pixel format * @num_fmts: Number of formats * @fmt_list: Format list * @current_std: Current standard * @num_stds: Number of standards * @std_list: Standards list - * @route: input and output routing at chip level + * @input: Input routing at chip level + * @output: Output routing at chip level */ Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper format. Basically, it should be like this example: /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. **/ - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. I'll try to analyze those remaining patches later today. Unfortunately, I'm very busy this weekend finishing some pending work. Hopefully these changes can be merged into 2.6.31. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 188 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/vpfe_capture.c | 27 linux/drivers/media/video/tvp514x.c| 879 ++ linux/drivers/media/video
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
On Sunday 21 June 2009 20:31:57 Mauro Carvalho Chehab wrote: Em Sun, 21 Jun 2009 20:20:29 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework Hmm... the kernel-doc format is wrong on all function description comment changes on tvp514x: I'm assuming this can be corrected in a separate patch later? I don't think this is a blocking issue. Yes, sure this is not blocking. BTW, please, _never_ send me an email to a public list C/C a subscribers-only list: Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Is being held until the list moderator can review it for approval. I knew about this, but since this is the official submission of the davinci vpfe capture driver I could hardly exclude that list from this pull request! Perhaps next time I should use a BCC instead, that might be a reasonable compromise. Muralidharan, can you take a look at this? Yes, please. Regards, Hans Regards, Hans -/** +/* * struct tvp514x_decoder - TVP5146/47 decoder object - * @v4l2_int_device: Slave handle - * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device + * @sd: Subdevice Slave handle * @tvp514x_regs: copy of hw's regs with preset values. * @pdata: Board specific - * @client: I2C client data - * @id: Entry from I2C table * @ver: Chip version - * @state: TVP5146/47 decoder state - detected or not-detected + * @streaming: TVP5146/47 decoder streaming - enabled or disabled. * @pix: Current pixel format * @num_fmts: Number of formats * @fmt_list: Format list * @current_std: Current standard * @num_stds: Number of standards * @std_list: Standards list - * @route: input and output routing at chip level + * @input: Input routing at chip level + * @output: Output routing at chip level */ Please read Documentation/kernel-doc-nano-HOWTO.txt for the proper format. Basically, it should be like this example: /** * foobar() - short function description of foobar * @arg1: Describe the first argument to foobar. * @arg2: Describe the second argument to foobar. * One can provide multiple line descriptions * for arguments. * * A longer description, with more discussion of the function foobar() * that might be useful to those using or modifying it. Begins with * empty comment line, and may include additional embedded empty * comment lines. * * The longer description can have multiple paragraphs. **/ - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. I'll try to analyze those remaining patches later today. Unfortunately, I'm very busy this weekend finishing some pending work. Hopefully these changes can be merged into 2.6.31. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi, Am Sonntag, den 21.06.2009, 15:31 -0300 schrieb Mauro Carvalho Chehab: Em Sun, 21 Jun 2009 20:20:29 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework Hmm... the kernel-doc format is wrong on all function description comment changes on tvp514x: I'm assuming this can be corrected in a separate patch later? I don't think this is a blocking issue. Yes, sure this is not blocking. BTW, please, _never_ send me an email to a public list C/C a subscribers-only list: Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Is being held until the list moderator can review it for approval. Muralidharan, can you take a look at this? [snip] this raises some other question. We need to have the links to the video4linux-list and to the dvb ML archives for many years in the future and ivtv was also an important list in the past and is still now and of course many others including those of our app developers too. I can see that people still pick up stuff I once got stuck on. In most cases users/contributors had their stuff finally run, but did not sign any patches for a bunch of devices. But there are also more important cases, like that one Igor tries to take care for now on that Compro stuff with that time new demodulator and tuner. (end of 2007) From my side, I was probably annoyed enough from that don't touch anything on dvb stuff, but else nobody did care either. Since, IMHO, we must provide free floating between the prior list archives, we likely need to more carefully think about what to allow and what not for cross posting. The linux-dvb ML is also only for subscribers and for sure we don't want to lose it, if it is about the archives. The same goes for video4linux and ivtv. For video4linux we know now that nobody ever cares for moderation, for ivtv I think it is taken into account that such traffic appears, for davinci I would not care until there is stated something different from the moderator, if any ;) Cheers, Hermann -- 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-vpfe-cap
Em Sun, 21 Jun 2009 20:38:53 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sunday 21 June 2009 20:31:57 Mauro Carvalho Chehab wrote: Em Sun, 21 Jun 2009 20:20:29 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sunday 21 June 2009 19:33:11 Mauro Carvalho Chehab wrote: Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework Hmm... the kernel-doc format is wrong on all function description comment changes on tvp514x: I'm assuming this can be corrected in a separate patch later? I don't think this is a blocking issue. Yes, sure this is not blocking. BTW, please, _never_ send me an email to a public list C/C a subscribers-only list: Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Is being held until the list moderator can review it for approval. I knew about this, but since this is the official submission of the davinci vpfe capture driver I could hardly exclude that list from this pull request! Perhaps next time I should use a BCC instead, that might be a reasonable compromise. The better would be to allow public posting on it, like what we did with linux-media. While they not open BCC could be a workaround. Yet, what would be the sense of copying just the pull requests without the revision comments? If reviews are not welcome there, why pull requests would be? 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
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 - v4l2-i2c-drv.h: add comment describing when not to use this header. - radio-tea5764: fix incorrect rxsubchans value - v4l2-spec: add missing documentation for the OV518 pixel format. - tcm825x: remove incorrect __exit_p wrapper - cx231xx: fix uninitialized variable. This replaces my previous v4l-dvb-misc pull request. The video_register_device patch in that older pull request is no longer present in this tree (instead I've posted a separate review request for that yesterday). I did add a few other trivial patches. Note that the first patch 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. Thanks, Hans diffstat: linux/drivers/media/dvb/siano/smscoreapi.c |4 - linux/drivers/media/radio/radio-tea5764.c |4 - linux/drivers/media/video/cx18/cx18-controls.c |2 linux/drivers/media/video/cx231xx/cx231xx-avcore.c |2 linux/drivers/media/video/cx2341x.c|2 linux/drivers/media/video/ivtv/ivtv-controls.c |2 linux/drivers/media/video/tcm825x.c|4 - linux/include/media/v4l2-i2c-drv.h |5 + v4l/compat.h |3 v4l2-apps/util/v4l2-ctl.cpp| 78 + v4l2-spec/pixfmt.sgml |5 + v4l2-spec/vidioc-g-modulator.sgml | 13 +-- 12 files changed, 110 insertions(+), 14 deletions(-) -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds for the following: - v4l2: add RDS API to videodev2.h - v4l2-spec: finalize the RDS specification. - bttv: set RDS capability if applicable. - saa6588: conform to the final RDS spec. - saa7134: set RDS capability if applicable. - radio-cadet: conform to the RDS spec. - radio-si470x: conform to the RDS spec. - v4l2-ctl: update to the latest RDS spec. This finalizes the RDS decoder specification. The only difference compared to my original RFC (1) is that I dropped the MMBS (or 'E block') support. As far as I can tell this service is discontinued in the US. I've added a note in the spec that if anyone needs this they should contact the list. Thanks, Hans (1) http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.html diffstat: linux/drivers/media/radio/radio-cadet.c |6 linux/drivers/media/radio/radio-si470x.c |9 - linux/drivers/media/video/bt8xx/bttv-driver.c |2 linux/drivers/media/video/saa6588.c | 60 ++- linux/drivers/media/video/saa7134/saa7134-core.c |4 linux/drivers/media/video/saa7134/saa7134-video.c |2 linux/drivers/media/video/saa7134/saa7134.h |1 linux/include/linux/videodev2.h | 23 ++ v4l2-apps/util/v4l2-ctl.cpp |4 v4l2-spec/biblio.sgml | 53 +- v4l2-spec/compat.sgml | 14 + v4l2-spec/dev-rds.sgml| 170 ++ v4l2-spec/v4l2.sgml |7 v4l2-spec/vidioc-g-tuner.sgml | 17 +- v4l2-spec/vidioc-querycap.sgml|2 15 files changed, 280 insertions(+), 94 deletions(-) -- 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-subdev2
On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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 Sat, 20 Jun 2009, Hans Verkuil wrote: - compat: fix __fls check for the arm architecture. This one isn't quite right. The __fls defined for arm in 2.6.27 (between v2.6.26-7260-g0c65f45 and v2.6.28-rc6-187-g94fc733) isn't the same as the __fls() used everwhere else in the kernel. This alternate fix should work. 01/01: compat: Fix __fls for certain ARM kernels http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=518b7754cd3d -- 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. Can you pull from this tree and just skip the last controversial patch? Or do you prefer me to redo this tree without that last patch? 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] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Tuesday 16 June 2009 02:03:54 Mauro Carvalho Chehab wrote:
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.
That's better, yes. I remember that at the time I wasn't sure what to do
here and I agree I made the wrong choice.
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.
I'll attempt that this weekend.
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] 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: [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: [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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
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. Thanks, Hans diffstat: linux/drivers/media/dvb/siano/smscoreapi.c |4 - linux/drivers/media/video/cx18/cx18-controls.c |2 linux/drivers/media/video/cx2341x.c|2 linux/drivers/media/video/ivtv/ivtv-controls.c |2 v4l/compat.h |3 v4l2-apps/util/v4l2-ctl.cpp| 78 + v4l2-spec/vidioc-g-modulator.sgml | 13 ++-- 7 files changed, 95 insertions(+), 9 deletions(-) -- 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 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. Regards, Hans Thanks, Hans diffstat: linux/drivers/media/dvb/siano/smscoreapi.c |4 - linux/drivers/media/video/cx18/cx18-controls.c |2 linux/drivers/media/video/cx2341x.c|2 linux/drivers/media/video/ivtv/ivtv-controls.c |2 v4l/compat.h |3 v4l2-apps/util/v4l2-ctl.cpp| 78 + v4l2-spec/vidioc-g-modulator.sgml | 13 ++-- 7 files changed, 95 insertions(+), 9 deletions(-) -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l: i2c modules must be linked before the v4l2 drivers This fixes the linking bug introduced in 2.6.30. I've also attached a diff with the same changes that applies directly to the 2.6.30 release. Thanks, Hans diffstat: Makefile | 70 +-- saa7134/Makefile |3 -- 2 files changed, 38 insertions(+), 35 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom diff -ur linux/drivers/media/video.org/Makefile linux/drivers/media/video/Makefile --- linux/drivers/media/video.org/Makefile 2009-06-12 08:42:20.0 +0200 +++ linux/drivers/media/video/Makefile 2009-06-12 00:45:46.0 +0200 @@ -12,6 +12,8 @@ videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o +# V4L2 core modules + obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o ifeq ($(CONFIG_COMPAT),y) obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o @@ -23,21 +25,15 @@ obj-$(CONFIG_VIDEO_DEV) += v4l1-compat.o endif -obj-$(CONFIG_VIDEO_TUNER) += tuner.o +# All i2c modules must come first: -obj-$(CONFIG_VIDEO_BT848) += bt8xx/ -obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o +obj-$(CONFIG_VIDEO_TUNER) += tuner.o obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o obj-$(CONFIG_VIDEO_TDA9875) += tda9875.o - obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o obj-$(CONFIG_VIDEO_SAA5246A) += saa5246a.o obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o -obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o -obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o -obj-$(CONFIG_VIDEO_W9966) += w9966.o - obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o @@ -54,11 +50,40 @@ obj-$(CONFIG_VIDEO_BT856) += bt856.o obj-$(CONFIG_VIDEO_BT866) += bt866.o obj-$(CONFIG_VIDEO_KS0127) += ks0127.o +obj-$(CONFIG_VIDEO_VINO) += indycam.o +obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o +obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o +obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o +obj-$(CONFIG_VIDEO_CS5345) += cs5345.o +obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o +obj-$(CONFIG_VIDEO_M52790) += m52790.o +obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o +obj-$(CONFIG_VIDEO_WM8775) += wm8775.o +obj-$(CONFIG_VIDEO_WM8739) += wm8739.o +obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o +obj-$(CONFIG_VIDEO_CX25840) += cx25840/ +obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o +obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o +obj-$(CONFIG_VIDEO_OV7670) += ov7670.o +obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o +obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o -obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o +obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o +obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o +obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o +obj-$(CONFIG_SOC_CAMERA_OV772X) += ov772x.o +obj-$(CONFIG_SOC_CAMERA_TW9910) += tw9910.o +# And now the v4l2 drivers: + +obj-$(CONFIG_VIDEO_BT848) += bt8xx/ +obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o +obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o +obj-$(CONFIG_VIDEO_W9966) += w9966.o obj-$(CONFIG_VIDEO_PMS) += pms.o -obj-$(CONFIG_VIDEO_VINO) += vino.o indycam.o +obj-$(CONFIG_VIDEO_VINO) += vino.o obj-$(CONFIG_VIDEO_STRADIS) += stradis.o obj-$(CONFIG_VIDEO_CPIA) += cpia.o obj-$(CONFIG_VIDEO_CPIA_PP) += cpia_pp.o @@ -69,17 +94,7 @@ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_USBVISION) += usbvision/ -obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o -obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o obj-$(CONFIG_VIDEO_PVRUSB2) += pvrusb2/ -obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o -obj-$(CONFIG_VIDEO_CS5345) += cs5345.o -obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o -obj-$(CONFIG_VIDEO_M52790) += m52790.o -obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o -obj-$(CONFIG_VIDEO_WM8775) += wm8775.o -obj-$(CONFIG_VIDEO_WM8739) += wm8739.o -obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o obj-$(CONFIG_VIDEO_OVCAMCHIP) += ovcamchip/ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/ obj-$(CONFIG_VIDEO_MXB) += mxb.o @@ -92,19 +107,12 @@ obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o -obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o -obj-$(CONFIG_VIDEO_CX25840) += cx25840/ -obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o -obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o -obj-$(CONFIG_VIDEO_OV7670) += ov7670.o - -obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_USB_DABUSB)+= dabusb.o obj-$(CONFIG_USB_OV511) += ov511.o @@ -134,24 +142,21 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ +obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o +obj-$(CONFIG_SOC_CAMERA)
Re: pull requests x patches at linux-media ML - Was: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hi Mauro, thanks for replying and for the explanation. I'll skip most of your message, and just keep the bits I'd like to reply to. On Wed, 10 Jun 2009, Mauro Carvalho Chehab wrote: The same happens here: All patches added at the staging tree are sent to linuxtv-commits ML. So, they are there for discussions before my pull requests. The main difference is that, in the case of Greg, his staging tree is a quilt one. On our case, our staging tree is mercurial. Hm, I am not sure, is Greg's quilt tree publically available? And how many actually use it? Whereas your hg tree is publically available and it looks like a few do use it. We're currently merging about 900 patches per kernel window, on a window of about 10-12 weeks. This means about 90 patches per week, or about 13 patches per day (for a 7 days week), or 18 patches per day (for a 5 days week). So, if people just send one email per patch, this will increase our traffic by 18 emails by day. It can be worse than that, if we consider that patches can be replied, and that people use to write a patch 0 to describe a patch series. Considering about 50 messages per day, currently (today and yesterday's statistics - not sure those are typical days), this would increase the ML by about 36%. I still don't take this argument of increased traffic - I haven't seen a single complain please, don't increase the traffic, it'll make it worse for me. 1) trivial patches (typo fixes, coding style, simple board additions, Kbuild fixes, etc); 2) bug fix patches at drivers; 3) new drivers; 4) core changes. However, several driver maintainers don't care (or just forget about they) for (1) type. Before patchwork, lots of such patches were lost forever in the middle of dvb and v4l mailing lists. They are happy when someone (me) get those patches and apply at the tree or remind they to check and apply on their trees. patches of type (2) and (3) are in general sent via a driver maintainer and generally doesn't generate discussions. I'm really happy we have subsistem maintainers that are such profecient in their work and such confident in their results that they don't need any reviews and discussions. I for one is not one of them, that's why I always first send my patches to the list. Also, for the developer, using the pull request is better, since they can better track when a patch series got merged. I never argumented against pull requests, I'm suggesting they should follow patches posted to the list. The usage of a mix of PULL and PATCH requests has an extra trouble: it means that we'll receive most of the patches duplicated. So, it means that I need to manually mark all merged patches at patchwork queue, on _each_ pull request. Yes, I see what you mean, but 1) you cannot avoid it, there are always patches from various authors, that they send to the ML, that some driver-maintainer will then pull through his or her tree and ask you to pull it. So, we really have to learn to proces this case efficiently. So, this adds an extra cost that will probably make life worse for everybody, with almost no gain (since there are really very few complaints about badly merged patches). That's said, I'm open to listen to opinions on how to improve our current process Well, I guess, I will have to subscribe to that hg-commit list (or whatever it's called), and use it. The problem is - it is a bit too late. But it's the best option available so far. Another question, if you pull patches from someone's tree for review of one of those pull-requests (as you described in this mail, but I've deleted that piece already), how do you then quote the code if you want to comment on it? You export the patch again, hit reply on the pull-request, and paste the patch into it? And then add the quotation marks manually?... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
On Wed, 10 Jun 2009, Mauro Carvalho Chehab wrote:
Em Wed, 10 Jun 2009 23:36:32 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
someone writes a script to intercept all hg pull requests from lmml
(procmail rule), forward that mail to a special media-patch list, and
extract and post as replies to that mail all individual patches? And that
list should be configured to only accept mails from that script or replies
to its mails, so, it'd be spam-free. And that list would also be used for
patch discussion. How does this sound?
This can be done. If you write such script in perl or python [1], I can put
it to
run at linuxtv. You'll likely need to handle also the pull request replies.
[1] since we don't have procmail (or exim) installed there.
Hm, yeah, thanks, but I think, if I were to do this, I would just do a
local script, that would
cp -al v4l-dvb pull
cd pull
hg pull -u tree-to-pull
for $mail in @mails {
hg extract $mail | mail ...
}
cd ..
rm -rf pull
and just mail the patches to me locally. But I don't think I'd be doing
this, I don't have the time. I'll just subscribe to the commits ML and
live with the fact, that the delta between patches in hg and in mainline
git will grow, as more patches in hg wil have to be fixed by incremental
patches, which you then will merge before importing into git...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull requests x patches at linux-media ML - Was: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Em Thu, 11 Jun 2009 08:23:37 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro, thanks for replying and for the explanation. I'll skip most of your message, and just keep the bits I'd like to reply to. On Wed, 10 Jun 2009, Mauro Carvalho Chehab wrote: The same happens here: All patches added at the staging tree are sent to linuxtv-commits ML. So, they are there for discussions before my pull requests. The main difference is that, in the case of Greg, his staging tree is a quilt one. On our case, our staging tree is mercurial. Hm, I am not sure, is Greg's quilt tree publically available? And how many actually use it? Whereas your hg tree is publically available and it looks like a few do use it. Well, he used to make it publicly available. We're currently merging about 900 patches per kernel window, on a window of about 10-12 weeks. This means about 90 patches per week, or about 13 patches per day (for a 7 days week), or 18 patches per day (for a 5 days week). So, if people just send one email per patch, this will increase our traffic by 18 emails by day. It can be worse than that, if we consider that patches can be replied, and that people use to write a patch 0 to describe a patch series. Considering about 50 messages per day, currently (today and yesterday's statistics - not sure those are typical days), this would increase the ML by about 36%. I still don't take this argument of increased traffic - I haven't seen a single complain please, don't increase the traffic, it'll make it worse for me. That's just what Hermann said. 1) trivial patches (typo fixes, coding style, simple board additions, Kbuild fixes, etc); 2) bug fix patches at drivers; 3) new drivers; 4) core changes. However, several driver maintainers don't care (or just forget about they) for (1) type. Before patchwork, lots of such patches were lost forever in the middle of dvb and v4l mailing lists. They are happy when someone (me) get those patches and apply at the tree or remind they to check and apply on their trees. patches of type (2) and (3) are in general sent via a driver maintainer and generally doesn't generate discussions. I'm really happy we have subsistem maintainers that are such profecient in their work and such confident in their results that they don't need any reviews and discussions. I for one is not one of them, that's why I always first send my patches to the list. Also, for the developer, using the pull request is better, since they can better track when a patch series got merged. I never argumented against pull requests, I'm suggesting they should follow patches posted to the list. The usage of a mix of PULL and PATCH requests has an extra trouble: it means that we'll receive most of the patches duplicated. So, it means that I need to manually mark all merged patches at patchwork queue, on _each_ pull request. Yes, I see what you mean, but 1) you cannot avoid it, there are always patches from various authors, that they send to the ML, that some driver-maintainer will then pull through his or her tree and ask you to pull it. So, we really have to learn to proces this case efficiently. The current process were built along the time and, up to now, it is the better we have. For sure it can be improved, but we need to take care to not transform it into some bureaucratic set of procedures that reduces our development speed and doesn't aggregate any value. So, this adds an extra cost that will probably make life worse for everybody, with almost no gain (since there are really very few complaints about badly merged patches). That's said, I'm open to listen to opinions on how to improve our current process Well, I guess, I will have to subscribe to that hg-commit list (or whatever it's called), and use it. The problem is - it is a bit too late. But it's the best option available so far. It is not that late, and you can always reply over the PULL requests, when you find an issue there. Another question, if you pull patches from someone's tree for review of one of those pull-requests (as you described in this mail, but I've deleted that piece already), how do you then quote the code if you want to comment on it? You export the patch again, hit reply on the pull-request, and paste the patch into it? And then add the quotation marks manually?... Well, I generally do: ./hgimport tree then I check each patch at /tmp/newpatches with less (or with kdiff3, if the patch is very complex). If I need to comment about a patch, I simply do: cat /tmp/newpatches/hg_v4l-dvb_1.patch|perl -ne 'print $_'|xclip and then I paste it at the email with a CTRL-V. The result is something like this: # HG changeset patch # User Andy Walls awa...@radix.net # Date 1243037266 14400 # Node ID
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
On Tue, 9 Jun 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check Do I understand this right, that these patches have not been posted to the list? At least I haven't found them in online and in my local archives. If it's really so, sorry, this doesn't seem very productive to me... We have discussed this with Mauro on IRC, he didn't agree with me, he thought it was acceptable in many cases... Sorry, cannot agree. Thanks Guennadi This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
On Wednesday 10 June 2009 20:17:53 Guennadi Liakhovetski wrote: On Tue, 9 Jun 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check Do I understand this right, that these patches have not been posted to the list? The idea is that you click on the link and look at the patches through the hg web frontend. At least I haven't found them in online and in my local archives. If it's really so, sorry, this doesn't seem very productive to me... We have discussed this with Mauro on IRC, he didn't agree with me, he thought it was acceptable in many cases... Sorry, cannot agree. Both methods (a pull request or a patch series) are used and personally I have no preference, although currently I have a script that simplifies these pull requests so I generally use that. A patch series makes it easier to reply with review comments, while I think a pull request reduces mailinglist traffic and actually makes it easier to do the actual reviews. Regards, Hans Thanks Guennadi This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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-subdev2
On Wed, 10 Jun 2009, Hans Verkuil wrote: On Wednesday 10 June 2009 20:17:53 Guennadi Liakhovetski wrote: On Tue, 9 Jun 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check Do I understand this right, that these patches have not been posted to the list? The idea is that you click on the link and look at the patches through the hg web frontend. And then? At least I haven't found them in online and in my local archives. If it's really so, sorry, this doesn't seem very productive to me... We have discussed this with Mauro on IRC, he didn't agree with me, he thought it was acceptable in many cases... Sorry, cannot agree. Both methods (a pull request or a patch series) are used and personally I have no preference, although currently I have a script that simplifies these pull requests so I generally use that. A patch series makes it easier to reply with review comments, while I think a pull request reduces mailinglist traffic and actually makes it easier to do the actual reviews. I think, patches posted to the list for reviews with a following pull request (if no rework needed of course) is the most reviewer-friendly, which is also what I so far have seen on all other lists I subscribe to (arm, ppc, usb, scsi, lkml, i2c,...). Have you seen those huge mailing threads from Greg K-H with all patches in his queue preceding his pull requests (I hope I reproduce his work flow correctly here, any mistakes are mine and unintended)? Are you really saying that it's equally convenient for you to review / reply to patch on ML and to patch in some repository from a pull request? Especially when there are multiple patches in that pull and you have to click through them all, jumping back and forth between your mail client and a browser?... If all are so much concerned about the ML traffic (which I don't understand either, filtering and ignoring uninteresting mails is easy enough these days), maybe we should split into devel and user? Sorry, I really don't understand. I'll go ask members of other MLs what they think about clicking through patches... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
On Wednesday 10 June 2009 22:20:03 Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Hans Verkuil wrote: On Wednesday 10 June 2009 20:17:53 Guennadi Liakhovetski wrote: On Tue, 9 Jun 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check Do I understand this right, that these patches have not been posted to the list? The idea is that you click on the link and look at the patches through the hg web frontend. And then? At least I haven't found them in online and in my local archives. If it's really so, sorry, this doesn't seem very productive to me... We have discussed this with Mauro on IRC, he didn't agree with me, he thought it was acceptable in many cases... Sorry, cannot agree. Both methods (a pull request or a patch series) are used and personally I have no preference, although currently I have a script that simplifies these pull requests so I generally use that. A patch series makes it easier to reply with review comments, while I think a pull request reduces mailinglist traffic and actually makes it easier to do the actual reviews. I think, patches posted to the list for reviews with a following pull request (if no rework needed of course) is the most reviewer-friendly, which is also what I so far have seen on all other lists I subscribe to (arm, ppc, usb, scsi, lkml, i2c,...). Have you seen those huge mailing threads from Greg K-H with all patches in his queue preceding his pull requests (I hope I reproduce his work flow correctly here, any mistakes are mine and unintended)? Are you really saying that it's equally convenient for you to review / reply to patch on ML and to patch in some repository from a pull request? Especially when there are multiple patches in that pull and you have to click through them all, jumping back and forth between your mail client and a browser?... If all are so much concerned about the ML traffic (which I don't understand either, filtering and ignoring uninteresting mails is easy enough these days), maybe we should split into devel and user? Sorry, I really don't understand. I'll go ask members of other MLs what they think about clicking through patches... Um, you are asking the wrong person. It's one of the two methods used on this list. Yes, pull requests are unusual compared to other lists (and so is the use of hg instead of git for that matter due to historical reasons). If Mauro says: use patch series, then I'll modify my workflow. If you prefer to see these subdev patches as a patch series, then I can do that for you. I have no preference myself. It's also a discussion I have no wish to go into. So if you see a pull request from me and prefer to have it as a patch series, just mail me and I'll do it. No problem. Regards, Hans Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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-subdev2
On Wed, 10 Jun 2009, hermann pitton wrote: on the pull requests is at least nothing new since years. Previously all patches were on video4linux and the linux-dvb ML and dealt with independently as far as possible. Because of all the hybrid devices that changed, but still someone having only analog TV reception likely doesn't want to read all about the digital stuff and in the other direction I assume in counts even more. So far the mercurial pull requests from the more active developers worked quite well. Historically seen you would have had a need at some point to see _all_ patches on both lists, if you follow the rule _all_ patches must be on the list(s). Now, with linux-media, everybody subscribed has the traffic of both of the old lists. Means for most people 50% are off topic. But the really funny thing comes now, we have with you and all the others suddenly about 70% of traffic on the list about cams :) I'm sure that more than 90% of the old v4l and dvb list members are not interested in that stuff at all :) Sure, and that's fine, because I'm not interested in them being not interested in that stuff at all:-) Now, how about this idea: someone writes a script to intercept all hg pull requests from lmml (procmail rule), forward that mail to a special media-patch list, and extract and post as replies to that mail all individual patches? And that list should be configured to only accept mails from that script or replies to its mails, so, it'd be spam-free. And that list would also be used for patch discussion. How does this sound? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
On Wed, 10 Jun 2009, Hans Verkuil wrote: Um, you are asking the wrong person. It's one of the two methods used on this list. Yes, pull requests are unusual compared to other lists (and so is the use of hg instead of git for that matter due to historical reasons). No, they are not unusual, but - they come _after_ all patches to be pulled have been posted (and reviewed) on the list. For exanple, on ARM, they have sub-maintainers for various ARM CPUs, those sub-maintainers collect patches from contributors for their platforms from the list, and post their own patches to the list too. After that they form pull requests with patches that have been reviewed on the list and that they (and everyone else) are happy about. If Mauro says: use patch series, then I'll modify my workflow. If you prefer to see these subdev patches as a patch series, then I can do that for you. I have no preference myself. It's also a discussion I have no wish to go into. So if you see a pull request from me and prefer to have it as a patch series, just mail me and I'll do it. No problem. This would help yes, thanks. Or - see my idea in an earlier mail in this thread. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Am Mittwoch, den 10.06.2009, 23:36 +0200 schrieb Guennadi Liakhovetski: On Wed, 10 Jun 2009, hermann pitton wrote: on the pull requests is at least nothing new since years. Previously all patches were on video4linux and the linux-dvb ML and dealt with independently as far as possible. Because of all the hybrid devices that changed, but still someone having only analog TV reception likely doesn't want to read all about the digital stuff and in the other direction I assume in counts even more. So far the mercurial pull requests from the more active developers worked quite well. Historically seen you would have had a need at some point to see _all_ patches on both lists, if you follow the rule _all_ patches must be on the list(s). Now, with linux-media, everybody subscribed has the traffic of both of the old lists. Means for most people 50% are off topic. But the really funny thing comes now, we have with you and all the others suddenly about 70% of traffic on the list about cams :) I'm sure that more than 90% of the old v4l and dvb list members are not interested in that stuff at all :) Sure, and that's fine, because I'm not interested in them being not interested in that stuff at all:-) Some do still follow ... ;) Now, how about this idea: someone writes a script to intercept all hg pull requests from lmml (procmail rule), forward that mail to a special media-patch list, and extract and post as replies to that mail all individual patches? And that list should be configured to only accept mails from that script or replies to its mails, so, it'd be spam-free. And that list would also be used for patch discussion. How does this sound? On v4l and dvb the most useful patches on the list for the users are those adding new devices on existing drivers. We don't have completely new drivers every day. To not lose them we have already patchwork employed and I'm not quite sure, if it really does what it should. The better is to have people dealing with all coming up 24/7 and issuing pull requests and pay with an additional SOB ;) for the rest of their live, but for the prize of having new bugs on always every new kernel because of API changes _others_ do need ... In opposite to linux-media in most cases, you are dealing with light sensors directly. Maybe this could make a difference. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull requests x patches at linux-media ML - Was: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
First of all, I'm renaming the thread, since we're not discussing the pull request per se. So, let's create a separate thread for it. Em Wed, 10 Jun 2009 23:18:52 +0200 hermann pitton hermann-pit...@arcor.de escreveu: Hi, Am Mittwoch, den 10.06.2009, 22:39 +0200 schrieb Hans Verkuil: On Wednesday 10 June 2009 22:20:03 Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Hans Verkuil wrote: On Wednesday 10 June 2009 20:17:53 Guennadi Liakhovetski wrote: On Tue, 9 Jun 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check Do I understand this right, that these patches have not been posted to the list? The idea is that you click on the link and look at the patches through the hg web frontend. And then? At least I haven't found them in online and in my local archives. If it's really so, sorry, this doesn't seem very productive to me... We have discussed this with Mauro on IRC, he didn't agree with me, he thought it was acceptable in many cases... Sorry, cannot agree. Both methods (a pull request or a patch series) are used and personally I have no preference, although currently I have a script that simplifies these pull requests so I generally use that. A patch series makes it easier to reply with review comments, while I think a pull request reduces mailinglist traffic and actually makes it easier to do the actual reviews. I think, patches posted to the list for reviews with a following pull request (if no rework needed of course) is the most reviewer-friendly, which is also what I so far have seen on all other lists I subscribe to (arm, ppc, usb, scsi, lkml, i2c,...). On LKML, several patches are sent as pull requests. Have you seen those huge mailing threads from Greg K-H with all patches in his queue preceding his pull requests (I hope I reproduce his work flow correctly here, any mistakes are mine and unintended)? The same happens here: All patches added at the staging tree are sent to linuxtv-commits ML. So, they are there for discussions before my pull requests. The main difference is that, in the case of Greg, his staging tree is a quilt one. On our case, our staging tree is mercurial. Are you really saying that it's equally convenient for you to review / reply to patch on ML and to patch in some repository from a pull request? Especially when there are multiple patches in that pull and you have to click through them all, jumping back and forth between your mail client and a browser?... If all are so much concerned about the ML traffic (which I don't understand either, filtering and ignoring uninteresting mails is easy enough these days), maybe we should split into devel and user? Sorry, I really don't understand. I'll go ask members of other MLs what they think about clicking through patches... Um, you are asking the wrong person. It's one of the two methods used on this list. Yes, pull requests are unusual compared to other lists (and so is the use of hg instead of git for that matter due to historical reasons). If Mauro says: use patch series, then I'll modify my workflow. If you prefer to see these subdev patches as a patch series, then I can do that for you. I have no preference myself. It's also a discussion I have no wish to go into. So if you see a pull request from me and prefer to have it as a patch series, just mail me and I'll do it. No problem. Regards, Hans on the pull requests is at least nothing new since years. Previously all patches were on video4linux and the linux-dvb ML and dealt with independently as far as possible. Because of all the hybrid devices that changed, but still someone having only analog TV reception likely doesn't want to read all about the digital stuff and in the other direction I assume in counts even more. So far the mercurial pull requests from the more active developers worked quite well. Historically seen you would have had a need at some point to see _all_ patches on both lists, if you follow the rule _all_ patches must be on the list(s). Now, with linux-media, everybody subscribed has the traffic of both of the old lists. Means for most people 50% are off topic. But the really funny thing comes now, we have with you and all the others suddenly about 70% of traffic on the list about cams :) I'm sure that more than 90% of the old v4l and dvb list members are not interested in that stuff at all :) We're currently merging about 900 patches per
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Em Wed, 10 Jun 2009 22:20:03 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Are you really saying that it's equally convenient for you to review / reply to patch on ML and to patch in some repository from a pull request? Especially when there are multiple patches in that pull and you have to click through them all, jumping back and forth between your mail client and a browser?... In my case (and I review 100% of the patches - so, I'm likely the worse case), reviewing they with a PULL request is faster, since I can just run hgimport script and see all of them locally even using tools like kdiff3. Also, I answer to just one email instead of tons of emails. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Em Wed, 10 Jun 2009 23:36:32 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: On Wed, 10 Jun 2009, hermann pitton wrote: on the pull requests is at least nothing new since years. Previously all patches were on video4linux and the linux-dvb ML and dealt with independently as far as possible. Because of all the hybrid devices that changed, but still someone having only analog TV reception likely doesn't want to read all about the digital stuff and in the other direction I assume in counts even more. So far the mercurial pull requests from the more active developers worked quite well. Historically seen you would have had a need at some point to see _all_ patches on both lists, if you follow the rule _all_ patches must be on the list(s). Now, with linux-media, everybody subscribed has the traffic of both of the old lists. Means for most people 50% are off topic. But the really funny thing comes now, we have with you and all the others suddenly about 70% of traffic on the list about cams :) I'm sure that more than 90% of the old v4l and dvb list members are not interested in that stuff at all :) Sure, and that's fine, because I'm not interested in them being not interested in that stuff at all:-) Now, how about this idea: someone writes a script to intercept all hg pull requests from lmml (procmail rule), forward that mail to a special media-patch list, and extract and post as replies to that mail all individual patches? And that list should be configured to only accept mails from that script or replies to its mails, so, it'd be spam-free. And that list would also be used for patch discussion. How does this sound? This can be done. If you write such script in perl or python [1], I can put it to run at linuxtv. You'll likely need to handle also the pull request replies. [1] since we don't have procmail (or exim) installed there. 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: pull requests x patches at linux-media ML - Was: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Am Mittwoch, den 10.06.2009, 21:13 -0300 schrieb Mauro Carvalho Chehab: First of all, I'm renaming the thread, since we're not discussing the pull request per se. So, let's create a separate thread for it. Em Wed, 10 Jun 2009 23:18:52 +0200 hermann pitton hermann-pit...@arcor.de escreveu: Hi, Am Mittwoch, den 10.06.2009, 22:39 +0200 schrieb Hans Verkuil: On Wednesday 10 June 2009 22:20:03 Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Hans Verkuil wrote: On Wednesday 10 June 2009 20:17:53 Guennadi Liakhovetski wrote: On Tue, 9 Jun 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check Do I understand this right, that these patches have not been posted to the list? The idea is that you click on the link and look at the patches through the hg web frontend. And then? At least I haven't found them in online and in my local archives. If it's really so, sorry, this doesn't seem very productive to me... We have discussed this with Mauro on IRC, he didn't agree with me, he thought it was acceptable in many cases... Sorry, cannot agree. Both methods (a pull request or a patch series) are used and personally I have no preference, although currently I have a script that simplifies these pull requests so I generally use that. A patch series makes it easier to reply with review comments, while I think a pull request reduces mailinglist traffic and actually makes it easier to do the actual reviews. I think, patches posted to the list for reviews with a following pull request (if no rework needed of course) is the most reviewer-friendly, which is also what I so far have seen on all other lists I subscribe to (arm, ppc, usb, scsi, lkml, i2c,...). On LKML, several patches are sent as pull requests. Have you seen those huge mailing threads from Greg K-H with all patches in his queue preceding his pull requests (I hope I reproduce his work flow correctly here, any mistakes are mine and unintended)? The same happens here: All patches added at the staging tree are sent to linuxtv-commits ML. So, they are there for discussions before my pull requests. The main difference is that, in the case of Greg, his staging tree is a quilt one. On our case, our staging tree is mercurial. Are you really saying that it's equally convenient for you to review / reply to patch on ML and to patch in some repository from a pull request? Especially when there are multiple patches in that pull and you have to click through them all, jumping back and forth between your mail client and a browser?... If all are so much concerned about the ML traffic (which I don't understand either, filtering and ignoring uninteresting mails is easy enough these days), maybe we should split into devel and user? Sorry, I really don't understand. I'll go ask members of other MLs what they think about clicking through patches... Um, you are asking the wrong person. It's one of the two methods used on this list. Yes, pull requests are unusual compared to other lists (and so is the use of hg instead of git for that matter due to historical reasons). If Mauro says: use patch series, then I'll modify my workflow. If you prefer to see these subdev patches as a patch series, then I can do that for you. I have no preference myself. It's also a discussion I have no wish to go into. So if you see a pull request from me and prefer to have it as a patch series, just mail me and I'll do it. No problem. Regards, Hans on the pull requests is at least nothing new since years. Previously all patches were on video4linux and the linux-dvb ML and dealt with independently as far as possible. Because of all the hybrid devices that changed, but still someone having only analog TV reception likely doesn't want to read all about the digital stuff and in the other direction I assume in counts even more. So far the mercurial pull requests from the more active developers worked quite well. Historically seen you would have had a need at some point to see _all_ patches on both lists, if you follow the rule _all_ patches must be on the list(s). Now, with linux-media, everybody subscribed has the traffic of both of the old lists. Means for most people 50% are off topic. But the really funny thing comes now, we have with you and all the others
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev
Em Tue, 9 Jun 2009 18:15:41 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev for the following: - v4l-dvb: replace the v4l2_i2c_new_*subdev* functions with v4l2_i2c_new_subdev() No, please! Let's keep the previously agreed strategy of not changing KABI on 2.6.31, in order to help fixing bug fixes that may eventually be present on 2.6.30 due to the large amount of changes due to V4L2 dev/subdev and I2C. We did a really large set of changes on 2.6.30, due to all those dev/subdev stuff. By deprecating functions that will be added on 2.6.30 on the next version (2.6.31), without even waiting for 2.6.30 regression list is not ok. Please come again with this only at the end of 2.6.31 kernel cycle. - v4l-dvb: add the s_config call to the core ops - v4l2-device: fix incorrect kernel check - v4l-dvb: add v4l2_i2c_new_subdev_board call If those are independent of the previous one, and are just adding new code, I'm ok on merging they. Yet, on a quick look at the the diff, it seems that they are changing the behavior of the existing functions [1]. Please double check and be sure that the diff will reflect just the new code addition. [1] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev/rev/ccc05f10e075 - v4l2: rename V4L2_I2C_ADDRS to I2C_ADDRS This one is OK, but I prefer to do this cleanup also later, to avoid needing to do backports if regressions are found close to this code 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- 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-davinci
Hans Verkuil escreveu:
On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the
following:
- v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std V4L2_STD_NTSC) || (std V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, setting value for SDTV format\n);
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, disabling all channels\n);
+ }
+
Hmm... Are you sure that the above check is ok? The standards you're allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like PAL/N,
PAL/N', PAL/60, PAL/M will stay away.
If what you want is all standards but SECAM, then the correct syntax would be
something like:
if (std (V4L2_STD_ALL ~V4L2_STD_SECAM))
- Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI (0x01)
+#define SD_STD_PAL_M (0x02)
+#define SD_STD_PAL_N (0x03)
Hmm... from the comments at the beginning of the .c file, it seems that the
hardware supports all standards but SECAM. The above register definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:
+static const struct adv7343_std_info
+ adv7343_composite_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
+ },
+};
+
+static const struct adv7343_std_info
+ adv7343_component_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
+ },
+};
Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both PAL and
NTSC? This seems wrong to my eyes.
Also, both tables have several supported standards missed.
Mauro,
Are there TVs in Brazil that are unable to handle standard NTSC-M on the
composite or S-Video inputs?
Yes. There are models that only handles PAL-M.
There are no encoders in v4l-dvb that do
something special for PAL-M.
Maybe because nobody tested they and reported an issue? Before I started
working on this,
most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
If you don't encode with PAL/M, then some TV sets won't work. Also, even
on TV sets that supports multiple standards, sometimes we need to
disable autodetection of NTSC, because this is broken on some TV sets.
I've personally experienced this trouble with two TV sets, including a
brand-new LCD1080p TV set I bought this year. On some conditions, if you
let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
changes to the other standard (missing the colors) for some seconds, and
then returns back. So, you have moments with colors and moments without.
It should also be noticed that there are several devices (TV sets, DVD
players, etc) manufactured abroad that people assumes that PAL/M color
carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the
color carriers are somewhat different, this produces a very annoying
effect: the color image will present a static image as a image with
colors moving, since there will be a frequency shift between the
horizontal frequency rate and the pixel sampling rate (that are derived
from the color carrier on several decoders), causing color detection
misleading at the pixels. So, the pixels at the boundary of a shape have
their colors oscillating.
I think these drivers should just use V4L2_STD_525_60 and V4L2_STD_625_50,
just like saa7127 does.
I have no device here with saa7127, so I'm not sure how this works with
other standards. But, expecially on encoding, you should be able to
produce the right standard. I can't see it producing a right standard if
you just use V4L2_STD_525_60 and V4L2_STD_625_50 with s-video. At least
on one place, you should say to the encoder what should be the color
carrier frequency and if it will encode with PAL, NTSC or SECAM.
By the way, what's the rationale of not allowing the driver to encode on
all supported formats?
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Hans, On Saturday 02 May 2009 17:24:10 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l-dvb: add missing DMA_BIT_MASK compat macro for kernels 2.6.24 - ivtv: fix compiler warning. - uvc: fix compile warning - tuner: remove tuner_i2c_address_check - v4l2: add v4l2_device_set_name() - ivtv: use v4l2_device_set_name. - v4l2-device: unregister i2c_clients when unregistering the v4l2_device. - ivtv: fix incorrect bit tests - ivtv/radio: fix V4L2_TUNER_MODE/V4L2_TUNER_SUB confusion - radio-fm16: cleanups - radio-fm16: fix g_tuner. - v4l2-spec: fix V4L2_TUNER_MODE_STEREO doc. Note that there are a few high-prio fixes: - ivtv: fix compiler warning. - uvc: fix compile warning - ivtv: fix incorrect bit tests - ivtv/radio: fix V4L2_TUNER_MODE/V4L2_TUNER_SUB confusion These should go into 2.6.30. Laurent, I've CC-ed you due to the uvc change. I should have applied the patch myself, sorry. I've been traveling a lot lately, hence the delay. Next time please send me a reminder, I would probably have done things a bit differently. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hi Mauro,
Hans Verkuil escreveu:
On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
for the
following:
- v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std V4L2_STD_NTSC) || (std V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, setting value for SDTV
format\n);
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, disabling all channels\n);
+ }
+
Hmm... Are you sure that the above check is ok? The standards you're
allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like
PAL/N,
PAL/N', PAL/60, PAL/M will stay away.
If what you want is all standards but SECAM, then the correct syntax
would be something like:
if (std (V4L2_STD_ALL ~V4L2_STD_SECAM))
- Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI (0x01)
+#define SD_STD_PAL_M (0x02)
+#define SD_STD_PAL_N (0x03)
Hmm... from the comments at the beginning of the .c file, it seems that
the
hardware supports all standards but SECAM. The above register
definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:
+static const struct adv7343_std_info
+ adv7343_composite_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
+ },
+};
+
+static const struct adv7343_std_info
+ adv7343_component_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
+ },
+};
Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both
PAL and
NTSC? This seems wrong to my eyes.
Also, both tables have several supported standards missed.
Mauro,
Are there TVs in Brazil that are unable to handle standard NTSC-M on the
composite or S-Video inputs?
Yes. There are models that only handles PAL-M.
There are no encoders in v4l-dvb that do
something special for PAL-M.
Maybe because nobody tested they and reported an issue? Before I started
working on this,
most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
To be fair, it is very hard to implement something you cannot test
yourself, and most people can only test PAL/NTSC.
All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
If you don't encode with PAL/M, then some TV sets won't work. Also, even
on TV sets that supports multiple standards, sometimes we need to
disable autodetection of NTSC, because this is broken on some TV sets.
I've personally experienced this trouble with two TV sets, including a
brand-new LCD1080p TV set I bought this year. On some conditions, if you
let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
changes to the other standard (missing the colors) for some seconds, and
then returns back. So, you have moments with colors and moments without.
It should also be noticed that there are several devices (TV sets, DVD
players, etc) manufactured abroad that people assumes that PAL/M color
carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the
color carriers are somewhat different, this produces a very annoying
effect: the color image will present a static image as a image with
colors moving, since there will be a frequency shift between the
horizontal frequency rate and the pixel sampling rate (that are derived
from the color carrier on several decoders), causing color detection
misleading at the pixels. So, the pixels at the boundary of a shape have
their colors oscillating.
Very interesting. I honestly thought that all TVs everywhere (except
perhaps very old ones) would be able to handle 'standard' PAL or NTSC on
their Composite and S-Video inputs.
I think these drivers should just use V4L2_STD_525_60 and
V4L2_STD_625_50,
just like saa7127 does.
I have no device here with saa7127, so I'm not sure how this works with
other standards.
Currently it does only PAL and NTSC. Although it can do SECAM it is never
actually enabled.
But, expecially on encoding, you should be able to
produce the right standard. I can't see it producing a right standard if
you just use V4L2_STD_525_60 and V4L2_STD_625_50 with s-video. At least
on one place, you should say to the encoder what should be the color
carrier frequency and
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans,
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, May 05, 2009 5:41 PM
To: Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; Chaithrika U S
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hi Mauro,
Hans Verkuil escreveu:
On Thursday 23 April 2009 13:35:02 Mauro Carvalho Chehab wrote:
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-
davinci
for the
following:
- v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id
std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std V4L2_STD_NTSC) || (std V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, setting value for SDTV
format\n);
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, disabling all channels\n);
+ }
+
Hmm... Are you sure that the above check is ok? The standards
you're
allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like
PAL/N,
PAL/N', PAL/60, PAL/M will stay away.
If what you want is all standards but SECAM, then the correct
syntax
would be something like:
if (std (V4L2_STD_ALL ~V4L2_STD_SECAM))
- Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI (0x01)
+#define SD_STD_PAL_M (0x02)
+#define SD_STD_PAL_N (0x03)
Hmm... from the comments at the beginning of the .c file, it seems
that
the
hardware supports all standards but SECAM. The above register
definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:
+static const struct adv7343_std_info
+ adv7343_composite_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A,
V4L2_STD_PAL,
+ },
+};
+
+static const struct adv7343_std_info
+ adv7343_component_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21,
V4L2_STD_PAL,
+ },
+};
Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for
both
PAL and
NTSC? This seems wrong to my eyes.
Also, both tables have several supported standards missed.
Mauro,
Are there TVs in Brazil that are unable to handle standard NTSC-M on
the
composite or S-Video inputs?
Yes. There are models that only handles PAL-M.
There are no encoders in v4l-dvb that do
something special for PAL-M.
Maybe because nobody tested they and reported an issue? Before I
started
working on this,
most drivers were broken with PAL/M: saa7113, cx88, ivtv, ...
To be fair, it is very hard to implement something you cannot test
yourself, and most people can only test PAL/NTSC.
All just check against 525 vs 625 line standards.
And I can't imagine that that will cause problems for Brazilian TVs.
If you don't encode with PAL/M, then some TV sets won't work. Also,
even
on TV sets that supports multiple standards, sometimes we need to
disable autodetection of NTSC, because this is broken on some TV
sets.
I've personally experienced this trouble with two TV sets, including
a
brand-new LCD1080p TV set I bought this year. On some conditions, if
you
let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and
changes to the other standard (missing the colors) for some seconds,
and
then returns back. So, you have moments with colors and moments
without.
It should also be noticed that there are several devices (TV sets,
DVD
players, etc) manufactured abroad that people assumes that PAL/M
color
carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since
the
color carriers are somewhat different, this produces a very annoying
effect: the color image will present a static image as a image with
colors moving, since there will be a frequency shift between the
horizontal frequency rate and the pixel sampling rate (that are
derived
from the color carrier on several decoders), causing color detection
misleading at the pixels. So, the pixels at the boundary of a shape
have
their colors oscillating.
Very interesting. I honestly thought that all TVs everywhere (except
perhaps very old ones) would be able to handle 'standard' PAL or NTSC
on
their Composite and S-Video inputs.
I think these drivers should just use V4L2_STD_525_60 and
V4L2_STD_625_50,
just like saa7127 does.
I have no device here
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
If you don't encode with PAL/M, then some TV sets won't work. Also, even on TV sets that supports multiple standards, sometimes we need to disable autodetection of NTSC, because this is broken on some TV sets. I've personally experienced this trouble with two TV sets, including a brand-new LCD1080p TV set I bought this year. On some conditions, if you let auto NTSC/PAL-M enabled, it miss-detects the color carrier, and changes to the other standard (missing the colors) for some seconds, and then returns back. So, you have moments with colors and moments without. It should also be noticed that there are several devices (TV sets, DVD players, etc) manufactured abroad that people assumes that PAL/M color carrier is equal to NTSC (AFAIK, the same occurs with PAL/Nc). Since the color carriers are somewhat different, this produces a very annoying effect: the color image will present a static image as a image with colors moving, since there will be a frequency shift between the horizontal frequency rate and the pixel sampling rate (that are derived from the color carrier on several decoders), causing color detection misleading at the pixels. So, the pixels at the boundary of a shape have their colors oscillating. Very interesting. I honestly thought that all TVs everywhere (except perhaps very old ones) would be able to handle 'standard' PAL or NTSC on their Composite and S-Video inputs. The difference between an NTSC-M system and PAL-M system is very slight: http://www.pembers.freeserve.co.uk/World-TV-Standards/Transmission-Systems.html since the 'M' determines most of the parameters. The color burst on the CVBS would be the only difference. I can see how color burst could be detected wrong on CVBS. I'm not sure how the chroma baseband signal in S-Video would get messed up though. Regards, Andy Chaithrika, can you take a look at this based on Mauro's input? 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l-dvb: add missing DMA_BIT_MASK compat macro for kernels 2.6.24 - ivtv: fix compiler warning. - uvc: fix compile warning - tuner: remove tuner_i2c_address_check - v4l2: add v4l2_device_set_name() - ivtv: use v4l2_device_set_name. - v4l2-device: unregister i2c_clients when unregistering the v4l2_device. - ivtv: fix incorrect bit tests - ivtv/radio: fix V4L2_TUNER_MODE/V4L2_TUNER_SUB confusion - radio-fm16: cleanups - radio-fm16: fix g_tuner. - v4l2-spec: fix V4L2_TUNER_MODE_STEREO doc. Note that there are a few high-prio fixes: - ivtv: fix compiler warning. - uvc: fix compile warning - ivtv: fix incorrect bit tests - ivtv/radio: fix V4L2_TUNER_MODE/V4L2_TUNER_SUB confusion These should go into 2.6.30. Laurent, I've CC-ed you due to the uvc change. Mauro, the handling of rxsubchans and audmode in tvaudio.c and bttv-audio-hook.c is broken (V4L2_TUNER_MODE and V4L2_TUNER_SUB are mixed-up). I did fix tvaudio.c but I have no boards to test it with and I also think that it can only be merged if bttv-audio-hook.c is also fixed. I will mail you my tvaudio.c diff. I don't have the time to work on bttv-audio-hook.c, unfortunately. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt |5 ++ linux/drivers/media/radio/radio-sf16fmi.c | 20 ++-- linux/drivers/media/radio/radio-sf16fmr2.c | 26 +++--- linux/drivers/media/video/ivtv/ivtv-driver.c | 16 +++--- linux/drivers/media/video/ivtv/ivtv-gpio.c |4 - linux/drivers/media/video/ivtv/ivtv-ioctl.c|5 +- linux/drivers/media/video/ivtv/ivtv-irq.c |2 linux/drivers/media/video/ivtv/ivtv-yuv.c |3 - linux/drivers/media/video/ivtv/ivtvfb.c|3 - linux/drivers/media/video/tuner-core.c | 52 - linux/drivers/media/video/uvc/uvc_driver.c |9 ++- linux/drivers/media/video/v4l2-common.c|4 - linux/drivers/media/video/v4l2-device.c| 29 +++ linux/include/media/v4l2-device.h | 21 linux/include/media/v4l2-subdev.h |5 ++ v4l/compat.h |2 v4l2-spec/Makefile |2 v4l2-spec/v4l2.sgml|2 v4l2-spec/vidioc-g-tuner.sgml |4 - 19 files changed, 107 insertions(+), 107 deletions(-) -- 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-davinci
On Sun, 19 Apr 2009 12:46:00 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: TI THS7303 video amplifier driver code - Analog Devices ADV7343 video encoder driver - v4l: improve consistency of the config menu. These new drivers for the davinci platform have been reviewed and OKed almost a month ago, so it's time to get these merged. Especially since the davinci display driver is also almost ready. Please, never copy a subscribers only list on pull requests. It is very annoying to receive such emails: From: davinci-linux-open-source-boun...@linux.davincidsp.com To: mche...@infradead.org Subject: Your message to Davinci-linux-open-source awaits moderator approval Date: Thu, 23 Apr 2009 06:35:25 -0500 Sender: davinci-linux-open-source-boun...@linux.davincidsp.com Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://linux.davincidsp.com/mailman/confirm/davinci-linux-open-source/cb8519a88f202b29b91bd0944d04b2ef2e67c239 -- 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
On Thu, 2 Apr 2009 18:16:42 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb Done. We should convert TUNER_SET_CONFIG to v4l2-subdev, in order to stop using the i2c command interface. I didn't checked, but I suspect that this is the last case of using the i2c command on v4l drivers. The removal of i2c command will probably make Jean happy as well, since this will also remove some legacy code from i2c core. This finalizes (I hope :-) ) the v4l2-subdev conversion. Most of these patches above remove code that's no longer needed. There are also some v4l2-subdev.h API improvements that I postponed until all the drivers were converted. These changes are trivial, but touch on a lot of files. Please let's avoid changing the internal API again on 2.6.31. We should focus on fixing the bugs during this cycle, since the changes were far above the usual, and affected all drivers. The other major change is that the old i2c autoprobing API is now used for kernels 2.6.26. This was 2.6.22, but a bug in i2c_new_probed_subdev prevent us from using the new i2c API for kernels 2.6.22-2.6.25. Actually it would be possible with 2.6.25, but since there were some other i2c API changes in 2.6.26 anyway I decided that it made life easier if we put the switchover point at 2.6.26. Ok. There are some other cleanups I could do, but all the important ones are now taken care of. I would like to take the opportunity to thank Jean Delvare for his support and his help in testing various drivers and working on ir-kbd-i2c, and Mauro for processing and merging all my patches. I feel a little guilty for burying Mauro in this big pile of patches :-) I also want to thank Andy Walls for doing the cx18 conversion, Mike Isely for doing the pvrusb2 conversion, Douglas Landgraf for doing the em28xx conversion, Trent Piepho for his reviews, Steve Toth for testing the cx23885 driver, Devin Heitmueller for converting au8522/au0828 and Sri Deevi for converting the cx231xx driver at short notice. I've no doubt forgotten people, for which I apologize. Thank you and all the others for the efforts. I expect you all to take extra care to fix all regressions that may eventually rise with those changes. In particular, please track the bugzillas at kernel.org. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sun, 5 Apr 2009 08:43:35 -0300, Mauro Carvalho Chehab wrote: On Thu, 2 Apr 2009 18:16:42 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb Done. We should convert TUNER_SET_CONFIG to v4l2-subdev, in order to stop using the i2c command interface. I didn't checked, but I suspect that this is the last case of using the i2c command on v4l drivers. The removal of i2c command will probably make Jean happy as well, since this will also remove some legacy code from i2c core. Oh yeah \o/ This finalizes (I hope :-) ) the v4l2-subdev conversion. Most of these patches above remove code that's no longer needed. There are also some v4l2-subdev.h API improvements that I postponed until all the drivers were converted. These changes are trivial, but touch on a lot of files. Please let's avoid changing the internal API again on 2.6.31. We should focus on fixing the bugs during this cycle, since the changes were far above the usual, and affected all drivers. The other major change is that the old i2c autoprobing API is now used for kernels 2.6.26. This was 2.6.22, but a bug in i2c_new_probed_subdev prevent us from using the new i2c API for kernels 2.6.22-2.6.25. Actually it would be possible with 2.6.25, but since there were some other i2c API changes in 2.6.26 anyway I decided that it made life easier if we put the switchover point at 2.6.26. Ok. There are some other cleanups I could do, but all the important ones are now taken care of. I would like to take the opportunity to thank Jean Delvare for his support and his help in testing various drivers and working on ir-kbd-i2c, and Mauro for processing and merging all my patches. I feel a little guilty for burying Mauro in this big pile of patches :-) I also want to thank Andy Walls for doing the cx18 conversion, Mike Isely for doing the pvrusb2 conversion, Douglas Landgraf for doing the em28xx conversion, Trent Piepho for his reviews, Steve Toth for testing the cx23885 driver, Devin Heitmueller for converting au8522/au0828 and Sri Deevi for converting the cx231xx driver at short notice. I've no doubt forgotten people, for which I apologize. Thank you and all the others for the efforts. I expect you all to take extra care to fix all regressions that may eventually rise with those changes. In particular, please track the bugzillas at kernel.org. Yes, I am totally committed to help fix any i2c issue that may arise as a consequence of the recent driver conversions. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - msp3400: remove i2c legacy code - saa7115: remove i2c legacy code - tvp5150: remove i2c legacy code. - tuner: remove i2c legacy code. - tvaudio: remove i2c legacy code - v4l: remove obsolete header and source - v4l2-common: remove legacy code - v4l2-subdev: move s_standby from core to tuner. - v4l2-subdev: add load_fw and use that instead of abusing core-init. - v4l2-subdev: move s_std from tuner to core. - v4l2: remove legacy fields in v4l2-i2c-drv.h. - v4l2: use old-style i2c API for kernels 2.6.26 instead of 2.6.22 - v4l2-common: add explicit v4l2_device pointer as first arg to new_(probed)_subdev - v4l2-common: add v4l2_i2c_new_probed_subdev_addr - v4l2: use v4l2_i2c_new_probed_subdev_addr where appropriate. - tvaudio.h: add static inline to retrieve the list of possible i2c addrs. - v4l: increase version numbers of drivers converted to v4l2_subdev. - v4l2-subdev: change prototype of s_crystal_freq. - mxb: fix copy-and-paste bug in mute. - v4l2-subdev: change s_routing prototype - ivtv/cx18: remove VIDIOC_INT_S_AUDIO_ROUTING debug support. - saa7146: fix incorrect comment. - v4l2-i2c-drv.h: fix compilation on kernel 2.6.25. This finalizes (I hope :-) ) the v4l2-subdev conversion. Most of these patches above remove code that's no longer needed. There are also some v4l2-subdev.h API improvements that I postponed until all the drivers were converted. These changes are trivial, but touch on a lot of files. The other major change is that the old i2c autoprobing API is now used for kernels 2.6.26. This was 2.6.22, but a bug in i2c_new_probed_subdev prevent us from using the new i2c API for kernels 2.6.22-2.6.25. Actually it would be possible with 2.6.25, but since there were some other i2c API changes in 2.6.26 anyway I decided that it made life easier if we put the switchover point at 2.6.26. There are some other cleanups I could do, but all the important ones are now taken care of. I would like to take the opportunity to thank Jean Delvare for his support and his help in testing various drivers and working on ir-kbd-i2c, and Mauro for processing and merging all my patches. I feel a little guilty for burying Mauro in this big pile of patches :-) I also want to thank Andy Walls for doing the cx18 conversion, Mike Isely for doing the pvrusb2 conversion, Douglas Landgraf for doing the em28xx conversion, Trent Piepho for his reviews, Steve Toth for testing the cx23885 driver, Devin Heitmueller for converting au8522/au0828 and Sri Deevi for converting the cx231xx driver at short notice. I've no doubt forgotten people, for which I apologize. This was a major project, but an important one and it puts the foundation in place of a much more powerful V4L2 framework. For me that's just as important, if not more so, as the removal of the old i2c autoprobing behavior. For 2.6.31 I intend to consolidate and build on this and hopefully start moving some functionality from the drivers into the core. I also hope that the TI modules and soc-camera can be converted to v4l2-subdev. I think that will be very useful indeed, since the reusability that v4l2-subdev offers is a major advantage. Thanks! Hans diffstat: a/linux/drivers/media/video/v4l2-subdev.c | 128 -- a/linux/include/media/v4l2-i2c-drv-legacy.h | 196 linux/Documentation/video4linux/v4l2-framework.txt | 19 - linux/drivers/media/common/saa7146_i2c.c|8 linux/drivers/media/dvb/frontends/au8522_decoder.c | 14 - linux/drivers/media/video/Makefile |2 linux/drivers/media/video/adv7170.c | 21 - linux/drivers/media/video/adv7175.c | 19 - linux/drivers/media/video/au0828/au0828-cards.c |8 linux/drivers/media/video/au0828/au0828-video.c | 12 linux/drivers/media/video/bt819.c | 17 - linux/drivers/media/video/bt856.c | 13 - linux/drivers/media/video/bt866.c | 13 - linux/drivers/media/video/bt8xx/bttv-cards.c| 82 ++ linux/drivers/media/video/bt8xx/bttv-driver.c | 29 +- linux/drivers/media/video/bt8xx/bttv-i2c.c |4 linux/drivers/media/video/bt8xx/bttvp.h |2 linux/drivers/media/video/cafe_ccic.c |2 linux/drivers/media/video/cs5345.c | 13 - linux/drivers/media/video/cs53l32a.c| 11 linux/drivers/media/video/cx18/cx18-audio.c |9 linux/drivers/media/video/cx18/cx18-av-core.c | 78 +++--- linux/drivers/media/video/cx18/cx18-av-core.h |5 linux/drivers/media/video/cx18/cx18-driver.c|4 linux/drivers/media/video/cx18/cx18-fileops.c |2 linux/drivers/media/video/cx18/cx18-gpio.c
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - cx25840: cleanup: remove intermediate 'ioctl' step - cx18: remove intermediate 'ioctl' step - v4l: replace 'ioctl' references in v4l i2c drivers - tuner: remove V4L1 code from this driver. - v4l2-subdev: add enum_framesizes and enum_frameintervals. - au8522: remove unused I2C_DRIVERID - cx25840: fix 'unused variable' warning. Basically a bunch of cleanups in preparation of the final phase. Note the removal of the V4L1 code in the tuner. Since all i2c drivers are now fully v4l2 the V4L1 code could be removed from this module. Thanks, Hans diffstat: drivers/media/dvb/frontends/au8522_decoder.c |1 drivers/media/video/cx18/cx18-av-audio.c | 122 - drivers/media/video/cx18/cx18-av-core.c | 29 -- drivers/media/video/cx18/cx18-av-core.h |9 drivers/media/video/cx18/cx18-av-vbi.c | 333 +-- drivers/media/video/cx25840/cx25840-audio.c | 121 - drivers/media/video/cx25840/cx25840-core.c | 26 -- drivers/media/video/cx25840/cx25840-core.h |8 drivers/media/video/cx25840/cx25840-vbi.c| 328 -- drivers/media/video/ks0127.c | 23 - drivers/media/video/saa7115.c|4 drivers/media/video/tuner-core.c | 146 --- drivers/media/video/tvp5150.c|8 drivers/media/video/vpx3220.c|8 include/media/v4l2-subdev.h |2 15 files changed, 490 insertions(+), 678 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx88
On Mon, 30 Mar 2009 13:38:51 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
On Monday 30 March 2009 13:31:55 Mauro Carvalho Chehab wrote:
On Sun, 29 Mar 2009 15:36:46 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx88 for the
following:
- cx88: convert to v4l2_subdev.
I only noticed this, when I tried to compile with an old kernel:
diff --git a/linux/drivers/media/video/cx88/cx88-video.c
b/linux/drivers/media/
video/cx88/cx88-video.c
snip/
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 22)
+ static struct i2c_board_info rtc_info = {
+ I2C_BOARD_INFO(isl1208, 0x6f)
+ };
+
request_module(rtc-isl1208);
+ core-i2c_rtc = i2c_new_device(core-i2c_adap, rtc_info);
+#else
+ request_module(rtc-isl1208);
+#endif
+ }
Where is the isl1208 driver? I can't see it.
It's an rtc (real-time clock) driver that's part of the drivers/rtc
subdirectory in the kernel. Apparently this particular board needs to set up
this rtc device by loading this driver for proper operation.
Hmm... weird...
For what purpose we need this driver? The other Isil drivers are power
control
drivers for DVB. If this is the case, we should move this code to cx88-dvb.
It's perfectly OK where it is. But since that driver was also converted to
the new style API we need to use i2c_new_device to load it since just calling
request_module will no longer work for this driver. Hence this change in the
code.
Ok.
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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - bttv: move saa6588 config to the helper chip config - saa7134: add RDS support. - saa6588: remove legacy code. Tested with my Terratec Cinergy 600 TV MK3. Thanks, Hans diffstat: Kconfig | 26 ++ bt8xx/Kconfig |1 + saa6588.c | 10 +++--- saa7134/Kconfig |1 + saa7134/saa7134-cards.c |1 + saa7134/saa7134-core.c | 11 +++ saa7134/saa7134-video.c | 37 + saa7134/saa7134.h |1 + 8 files changed, 69 insertions(+), 19 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx23885
On Sunday 29 March 2009 11:55:19 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx23885 for the following: - cx23885: convert to v4l2_device. - cx23885: bugfix error message if firmware is not found - cx23885: convert to v4l2_subdev. Thanks to Steven Toth for testing this on the HVR-1800! Hi Mauro, I've added this change as well: - cx25840: remove legacy code for old-style i2c API Regards, Hans Thanks, Hans diffstat: cx23885-417.c | 25 -- cx23885-cards.c |4 +- cx23885-core.c | 19 +++ cx23885-dvb.c |2 - cx23885-i2c.c | 95 ++-- cx23885-video.c | 66 ++ cx23885.h | 14 ++-- 7 files changed, 84 insertions(+), 141 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx88
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx88 for the following: - cx88: convert to v4l2_subdev. - wm8775: remove legacy code for old-style i2c API - tda9875: remove legacy code for old-style i2c API - tda7432: remove legacy code for old-style i2c API - v4l2: remove v4l2_subdev_command calls where they are no longer needed. Tested with the Hauppauge HVR-3000 and HVR-1300, and with a WinFast DTV1000-T (thanks, Jean!). Full commit message for the first patch: Convert cx88 to use v4l2_subdev since the old i2c autoprobing mechanism will be removed. Added code to explicitly load tvaudio where needed. Also fix the rtc-isl1208 support: since that driver no longer supports autoprobing it has to be loaded using the new i2c API. Thanks, Hans diffstat: cs5345.c |7 --- cx88/cx88-blackbird.c |4 ++-- cx88/cx88-cards.c | 40 cx88/cx88-core.c |7 +-- cx88/cx88-dvb.c|2 +- cx88/cx88-i2c.c| 39 ++- cx88/cx88-video.c | 44 cx88/cx88.h| 14 -- m52790.c |6 -- ovcamchip/ovcamchip_core.c |6 -- saa717x.c |7 --- tda7432.c | 10 +++--- tda9875.c | 10 +++--- tlv320aic23b.c |6 -- upd64031a.c|6 -- upd64083.c |6 -- vp27smpx.c |6 -- wm8739.c |6 -- wm8775.c | 11 +++ 19 files changed, 95 insertions(+), 142 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv for the following: - tvaudio: fix mute and s/g_tuner handling - tvaudio: add tda9875 support. - tvaudio: always call init_timer to prevent rmmod crash. - bttv: convert to v4l2_subdev since i2c autoprobing will disappear. Changes since the last version: - removed the card definition's has_saa6588 bitfield, but added a comment in the header that it should be added if needed. - update has_saa6588 in the bttv struct with the probe result and removed sd_saa6588. This makes it possible to use has_saa6588 if we need to check for the presence of a saa6588. - replaced the three msp3400, tda7432 and tvaudio options by a single audiodev option for 'no audio', 'autodetect', 'msp3400', 'tda7432' and 'tvaudio'. All review comments have been incorporated in this tree, so I think it is ready to be merged now. Thanks, Hans diffstat: bt8xx/bttv-cards.c | 187 +++- bt8xx/bttv-driver.c | 43 +-- bt8xx/bttv-i2c.c| 52 +- bt8xx/bttv.h|7 + bt8xx/bttvp.h |5 - tvaudio.c | 158 ++- 6 files changed, 341 insertions(+), 111 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv
On Saturday 28 March 2009 12:44:32 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv for the following: - tvaudio: fix mute and s/g_tuner handling - tvaudio: add tda9875 support. - tvaudio: always call init_timer to prevent rmmod crash. - bttv: convert to v4l2_subdev since i2c autoprobing will disappear. Changes since the last version: - removed the card definition's has_saa6588 bitfield, but added a comment in the header that it should be added if needed. - update has_saa6588 in the bttv struct with the probe result and removed sd_saa6588. This makes it possible to use has_saa6588 if we need to check for the presence of a saa6588. - replaced the three msp3400, tda7432 and tvaudio options by a single audiodev option for 'no audio', 'autodetect', 'msp3400', 'tda7432' and 'tvaudio'. All review comments have been incorporated in this tree, so I think it is ready to be merged now. Added this small one as well: - bttv: tda9875 is no longer used by bttv, so remove from bt8xx/Kconfig. Thanks, Hans Thanks, Hans diffstat: bt8xx/bttv-cards.c | 187 +++- bt8xx/bttv-driver.c | 43 +-- bt8xx/bttv-i2c.c| 52 +- bt8xx/bttv.h|7 + bt8xx/bttvp.h |5 - tvaudio.c | 158 ++- 6 files changed, 341 insertions(+), 111 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - saa7134: fix RTD Embedded Technologies VFG7350 support. - cs53l32a: remove legacy support. - dst_ca: fix compile warning. - dabusb: fix compile warning. Thanks, Hans diffstat: dvb/bt8xx/dst_ca.c |9 + video/cs53l32a.c| 10 +++--- video/dabusb.c |2 +- video/saa7134/saa6752hs.c |2 +- video/saa7134/saa7134-cards.c |8 video/saa7134/saa7134-core.c|5 +++-- video/saa7134/saa7134-empress.c |3 +-- video/saa7134/saa7134.h |1 + 8 files changed, 23 insertions(+), 17 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vino
Hi Hans, Sorry for not replying your mail earlier. I've been extremely busy with my studies for the last weeks and will be until June, so I really don't have the time for testing this (as the software setup on my Indy hardware is extremely outdated). If these need quicker attention you could ask someone from #mipslinux @ freenode IRC network to try this - there should be some people hanging there who have Indy hardware. -Mikael On Fri, 6 Mar 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vino for the following: - vino: convert to video_ioctl2. - vino: minor renames - saa7191: convert to v4l2-i2c-drv-legacy.h - vino/indycam/saa7191: convert to i2c modules to V4L2. - indycam: convert to v4l2_subdev - saa7191: convert to v4l2_subdev. - vino: introduce v4l2_device. - vino: convert to v4l2_subdev. - saa7191, indycam: remove compat code. - vino: fold i2c-algo-sgi code into vino. - vino: add note that this conversion is untested. Mikael, if possible can you test this? It would be very much appreciated. I also have your 64-bit fixes ready to commit to the repository kernel. All I need is your Signed-off-by line. Thanks, Hans diffstat: drivers/media/video/Kconfig |1 drivers/media/video/indycam.c | 381 +++-- drivers/media/video/indycam.h | 19 drivers/media/video/saa7191.c | 666 ++-- drivers/media/video/saa7191.h | 26 drivers/media/video/vino.c | 1619 +--- include/media/v4l2-chip-ident.h |6 7 files changed, 1127 insertions(+), 1591 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - ov7670: add missing delay.h include. - hdpvr: only build from 2.6.20. Thanks, Hans diffstat: linux/drivers/media/video/ov7670.c |1 + v4l/versions.txt |1 + 2 files changed, 2 insertions(+) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision
On Tuesday 17 March 2009 22:26:16 Dwaine Garden wrote: Invalid link for http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision? It's already been merged in the master, so use http://www.linuxtv.org/hg/v4l-dvb instead. Thanks for testing this! Regards, Hans From: Mauro Carvalho Chehab mche...@infradead.org To: Thierry MERLE thierry.me...@free.fr; Dwaine Garden dwainegar...@rogers.com Cc: Hans Verkuil hverk...@xs4all.nl; linux-media@vger.kernel.org Sent: Thursday, February 26, 2009 2:28:06 PM Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision On Sat, 21 Feb 2009 22:17:10 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision for the following: - v4l2-common: add v4l2_i2c_subdev_addr() - usbvision: convert to v4l2_device/v4l2_subdev. Thierry/Dwaine, Could you please check if everything is ok with usbvision after those patches? Thanks, Hans diffstat: drivers/media/video/usbvision/usbvision-core.c |2 drivers/media/video/usbvision/usbvision-i2c.c | 147 ++-- drivers/media/video/usbvision/usbvision-video.c | 63 -- drivers/media/video/usbvision/usbvision.h |8 - drivers/media/video/v4l2-common.c |9 + include/media/v4l2-common.h |2 6 files changed, 86 insertions(+), 145 deletions(-) Cheers, Mauro -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sat, 14 Mar 2009 16:49:40 +0100
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l2-device: add v4l2_device_disconnect
- v4l2: call v4l2_device_disconnect in USB drivers.
- tvaudio: add tda9875 support.
Hmm...
tvaudio: add tda9875 support.
From: Hans Verkuil hverk...@xs4all.nl
This change allows bttv to use tvaudio for this device. Since this device
has the same i2c address as the tda9874 we need to support both in the same
tvaudio driver. This makes it possible for tvaudio to detect which chip is
used. Originally the tda9875 was only available in the dedicated tda9875
driver, but that makes life very hard for bttv since loading tvaudio might
misdetect a tda9875 as a tda9874.
I think we've already discussed about this patch (it were part of your bttv RFC
tree): please remove the mute bug fix for the tda9875 addition.
@@ -1519,23 +1651,26 @@ static int tvaudio_g_ctrl(struct v4l2_su
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- ctrl-value=chip-muted;
+ if (!(desc-flags CHIP_HAS_INPUTSEL))
+ break;
+ ctrl-value = chip-muted;
return 0;
The other changesets are OK.
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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-common: remove incorrect MODULE test - au0828: fix compilation on kernels 2.6.20 and 2.6.21. - au8522: fix compilation warning. - mt9v022: fix compilation warning for kernels 2.6.26. Devin, please note the au changes I made. The au8522 change we've discussed already (normal_i2c isn't needed for old kernels), the au0828 change simply adds the linux/mm.h header which turns out to be needed on older kernels. Thanks, Hans diffstat: dvb/frontends/au8522_decoder.c |6 -- video/au0828/au0828-video.c|1 + video/mt9v022.c|4 video/v4l2-common.c|8 4 files changed, 13 insertions(+), 6 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Wed, Mar 18, 2009 at 3:46 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-common: remove incorrect MODULE test - au0828: fix compilation on kernels 2.6.20 and 2.6.21. - au8522: fix compilation warning. - mt9v022: fix compilation warning for kernels 2.6.26. Devin, please note the au changes I made. The au8522 change we've discussed already (normal_i2c isn't needed for old kernels), the au0828 change simply adds the linux/mm.h header which turns out to be needed on older kernels. Yeah, the au* changes look fine to me. I just didn't get a chance to cut the normal_i2c entry (I was slated to do it this week). Thanks, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-device: add v4l2_device_disconnect - v4l2: call v4l2_device_disconnect in USB drivers. - tvaudio: add tda9875 support. - bttv: convert to v4l2_device. - cx88: convert to v4l2_device. These patches prepare the bttv and cx88 drivers for the v4l2_subdev conversion. Note that this is not the actual conversion, it just prepares these drivers by introducing v4l2_device. The v4l2_device_disconnect was added thanks to Mike Isely who pointed out to me that the parent device can disappear after a disconnect. The tda9875 support in tvaudio is also needed before the bttv driver can be converted to v4l2_subdev as it is otherwise impossible to correctly probe for a tda9875 or tda9874. Mauro, I don't think I'll merge the tda7432 support into tvaudio. It is a nice-to-have, but not a requirement since there are no probing conflicts with that device. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt| 11 + drivers/media/dvb/bt8xx/dvb-bt8xx.c |2 drivers/media/video/bt8xx/bttv-driver.c | 47 +++-- drivers/media/video/bt8xx/bttv-i2c.c| 10 - drivers/media/video/bt8xx/bttv.h|3 drivers/media/video/bt8xx/bttvp.h |5 drivers/media/video/cx88/cx88-cards.c |8 drivers/media/video/cx88/cx88-core.c|4 drivers/media/video/cx88/cx88-i2c.c |8 drivers/media/video/cx88/cx88.h |8 drivers/media/video/tvaudio.c | 202 +--- drivers/media/video/usbvision/usbvision-video.c |2 drivers/media/video/v4l2-device.c | 15 + drivers/media/video/w9968cf.c |4 include/media/v4l2-device.h |6 15 files changed, 279 insertions(+), 56 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Saturday 14 March 2009 17:13:27 Mike Isely wrote: On Sat, 14 Mar 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-device: add v4l2_device_disconnect Any chance this is going to get into 2.6.29? I need to know. No, this won't go to 2.6.29. None of the drivers in 2.6.29 using this framework are USB drivers, so it's not needed there. Regards, Hans -Mike - v4l2: call v4l2_device_disconnect in USB drivers. - tvaudio: add tda9875 support. - bttv: convert to v4l2_device. - cx88: convert to v4l2_device. These patches prepare the bttv and cx88 drivers for the v4l2_subdev conversion. Note that this is not the actual conversion, it just prepares these drivers by introducing v4l2_device. The v4l2_device_disconnect was added thanks to Mike Isely who pointed out to me that the parent device can disappear after a disconnect. The tda9875 support in tvaudio is also needed before the bttv driver can be converted to v4l2_subdev as it is otherwise impossible to correctly probe for a tda9875 or tda9874. Mauro, I don't think I'll merge the tda7432 support into tvaudio. It is a nice-to-have, but not a requirement since there are no probing conflicts with that device. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt| 11 + drivers/media/dvb/bt8xx/dvb-bt8xx.c |2 drivers/media/video/bt8xx/bttv-driver.c | 47 +++-- drivers/media/video/bt8xx/bttv-i2c.c| 10 - drivers/media/video/bt8xx/bttv.h|3 drivers/media/video/bt8xx/bttvp.h |5 drivers/media/video/cx88/cx88-cards.c |8 drivers/media/video/cx88/cx88-core.c|4 drivers/media/video/cx88/cx88-i2c.c |8 drivers/media/video/cx88/cx88.h |8 drivers/media/video/tvaudio.c | 202 +--- drivers/media/video/usbvision/usbvision-video.c |2 drivers/media/video/v4l2-device.c | 15 + drivers/media/video/w9968cf.c |4 include/media/v4l2-device.h |6 15 files changed, 279 insertions(+), 56 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sat, 14 Mar 2009, Hans Verkuil wrote: On Saturday 14 March 2009 17:13:27 Mike Isely wrote: On Sat, 14 Mar 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-device: add v4l2_device_disconnect Any chance this is going to get into 2.6.29? I need to know. No, this won't go to 2.6.29. None of the drivers in 2.6.29 using this framework are USB drivers, so it's not needed there. I was going to configure the standalone version of the pvrusb2 driver to use the new framework for 2.6.29. That's why I needed to know. So I'll either configure the driver to not do this until it is built under 2.6.30 or just continue poking the structure directly for 2.6.29. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - cx23885: fix crash on non-netup cards - v4l2-dev: use parent field if the v4l2_device has no parent set. - cx25840: cx23885 detection was broken This takes care of two recently introduced bugs in cx23885 and adds a small improvement to v4l2-dev in preparation of the cx88 conversion to v4l2_device/v4l2_subdev. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt | 12 +++- drivers/media/video/cx23885/cx23885-core.c | 10 -- drivers/media/video/cx23885/cx23885-dvb.c|6 +- drivers/media/video/cx25840/cx25840-core.c |4 ++-- drivers/media/video/v4l2-dev.c |2 +- 5 files changed, 27 insertions(+), 7 deletions(-) tschai: ~/work/src/v4l/v4l-dvb $ vi linux/drivers/media/video/cx25840/cx25840-core.c -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sat, 14 Mar 2009 01:20:09 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 14 March 2009 01:14:38 Hans Verkuil wrote: On Saturday 14 March 2009 01:05:24 Mauro Carvalho Chehab wrote: On Fri, 13 Mar 2009 17:39:28 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, - cx25840: cx23885 detection was broken Please note that this patch were applied only at the -git pending tree, since it depends on cx231xx (it doesn't apply at the normal devel git tree). Probably, it is ok, since the breakage seemed to be caused by the cx231xx changes. Yes, it was the cx231xx changes that caused it. I've discussed this with Sri. He's clearly not quite familiar with the way linux development works. With a bit of luck I'll actually meet him during the Embedded Linux Conference in April and that'll give me a chance to 'educate' him :-) Erm, that came out wrong. I shouldn't mail late at night... :) I'm also a little tired due to the large amount of patch review, merge stuff, merge conflict solve, etc, I did all day long... I was thinking of showing him a nice presentation I did at work about the way kernel development works. I've shown it to others before who are new to kernel development and it's quite helpful. This is a good idea. Maybe you can add it at some public place for people to see it also. 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
