[PULL] soc-camera fix for 2.6.33
The following changes since commit 92dcffb916d309aa01778bf8963a6932e4014d07: Linus Torvalds (1): Linux 2.6.33-rc5 are available in the git repository at: ssh://linuxtv.org/git/gliakhovetski/fixes.git master Kuninori Morimoto (1): soc-camera: mt9t112: modify exiting conditions from standby mode drivers/media/video/mt9t112.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 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
BUG: latest dvb-apps do not compile due to MA's faulty implementation of the gotox utility
Hi, in order to make the latest dvb-apps compile cleanly 2 things need to be done: 1. the already compiled gotox binary needs to be deleted 2. the following patch needs to be applied: --- a/util/gotox/Makefile +++ b/util/gotox/Makefile @@ -1,5 +1,7 @@ # Makefile for linuxtv.org dvb-apps/util/gotox +objects = gotox.o + binaries = gotox inst_bin = $(binaries) @@ -13,3 +15,7 @@ .PHONY: all all: $(binaries) + +$(binaries): $(objects) + +include ../../Make.rules Cheers CS -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
Hi Németh
On Tue, 9 Feb 2010, Guennadi Liakhovetski wrote:
Ok, I modified your patch a bit, how about the below version? If you
agree, I'll commit it in that form (after converting to utf-8):
From: Márton Németh nm...@freemail.hu
The first two parameters of soc_camera_limit_side() are usually pointers
to struct v4l2_rect elements. They are signed, so adjust the prototype
accordingly.
This will remove the following sparse warning (see make C=1):
* incorrect type in argument 1 (different signedness)
expected unsigned int *start
got signed int *noident
as well as a couple more signedness mismatches.
Signed-off-by: Márton Németh nm...@freemail.hu
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
please confirm, if you agree with my version of your patch, or I'll have
to leave it out from my pull request.
Thanks
Guennadi
---
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 1a34d29..e5bae4c 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -325,7 +325,7 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
if (ret 0)
return ret;
- dev_dbg(client-dev, Frame %ux%u pixel\n, rect.width, rect.height);
+ dev_dbg(client-dev, Frame %dx%d pixel\n, rect.width, rect.height);
mt9v022-rect = rect;
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index bd297f5..d477e30 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -796,7 +796,7 @@ static int acquire_dma_channel(struct mx3_camera_dev
*mx3_cam)
* FIXME: learn to use stride != width, then we can keep stride properly
aligned
* and support arbitrary (even) widths.
*/
-static inline void stride_align(__s32 *width)
+static inline void stride_align(__u32 *width)
{
if (((*width + 7) ~7) 4096)
*width = (*width + 7) ~7;
@@ -844,7 +844,7 @@ static int mx3_camera_set_crop(struct soc_camera_device
*icd,
* So far only direct camera-to-memory is supported
*/
if (channel_change_requested(icd, rect)) {
- int ret = acquire_dma_channel(mx3_cam);
+ ret = acquire_dma_channel(mx3_cam);
if (ret 0)
return ret;
}
diff --git a/drivers/media/video/rj54n1cb0c.c
b/drivers/media/video/rj54n1cb0c.c
index 9277194..bbd9c11 100644
--- a/drivers/media/video/rj54n1cb0c.c
+++ b/drivers/media/video/rj54n1cb0c.c
@@ -555,15 +555,15 @@ static int rj54n1_commit(struct i2c_client *client)
return ret;
}
-static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
-u32 *out_w, u32 *out_h);
+static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+s32 *out_w, s32 *out_h);
static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
struct v4l2_rect *rect = a-c;
- unsigned int dummy = 0, output_w, output_h,
+ int dummy = 0, output_w, output_h,
input_w = rect-width, input_h = rect-height;
int ret;
@@ -577,7 +577,7 @@ static int rj54n1_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
output_w = (input_w * 1024 + rj54n1-resize / 2) / rj54n1-resize;
output_h = (input_h * 1024 + rj54n1-resize / 2) / rj54n1-resize;
- dev_dbg(client-dev, Scaling for %ux%u : %u = %ux%u\n,
+ dev_dbg(client-dev, Scaling for %dx%d : %u = %dx%d\n,
input_w, input_h, rj54n1-resize, output_w, output_h);
ret = rj54n1_sensor_scale(sd, input_w, input_h, output_w, output_h);
@@ -638,8 +638,8 @@ static int rj54n1_g_fmt(struct v4l2_subdev *sd,
* the output one, updates the window sizes and returns an error or the
resize
* coefficient on success. Note: we only use the Fixed Scaling on this
camera.
*/
-static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
-u32 *out_w, u32 *out_h)
+static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+s32 *out_w, s32 *out_h)
{
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
@@ -749,7 +749,7 @@ static int rj54n1_sensor_scale(struct v4l2_subdev *sd,
u32 *in_w, u32 *in_h,
* improve the image quality or stability for larger frames (see comment
* above), but I didn't check the framerate.
*/
- skip = min(resize / 1024, (unsigned)15);
+ skip = min(resize / 1024, 15U);
inc_sel = 1 skip;
@@ -819,7 +819,7 @@ static int rj54n1_sensor_scale(struct v4l2_subdev *sd,
u32 *in_w, u32 *in_h,
*out_w = output_w;
Re: [PATCH 2/5] sony-tuner: Subdev conversion from wis-sony-tuner
On Friday 12 February 2010 01:33:07 Pete Eberlein wrote:
From: Pete Eberlein p...@sensoray.com
This is a subdev conversion of the go7007 wis-sony-tuner i2c driver,
and places it with the other tuner drivers. This obsoletes the
wis-sony-tuner driver in the go7007 staging directory.
Thanks! Here is a quick review...
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r 2d2a250ca33b -r 628119533574
linux/Documentation/video4linux/CARDLIST.tuner
--- a/linux/Documentation/video4linux/CARDLIST.tuner Wed Feb 10 11:25:59
2010 -0800
+++ b/linux/Documentation/video4linux/CARDLIST.tuner Thu Feb 11 15:21:11
2010 -0800
@@ -81,3 +81,6 @@
tuner=81 - Partsnic (Daewoo) PTI-5NF05
tuner=82 - Philips CU1216L
tuner=83 - NXP TDA18271
+tuner=84 - Sony PAL+SECAM (BTF-PG472Z)
+tuner=85 - Sony NTSC_JP (BTF-PK467Z)
+tuner=86 - Sony NTSC (BTF-PB463Z)
diff -r 2d2a250ca33b -r 628119533574 linux/drivers/media/common/tuners/Kconfig
--- a/linux/drivers/media/common/tuners/Kconfig Wed Feb 10 11:25:59
2010 -0800
+++ b/linux/drivers/media/common/tuners/Kconfig Thu Feb 11 15:21:11
2010 -0800
@@ -179,4 +179,12 @@
help
A driver for the silicon tuner MAX2165 from Maxim.
+config MEDIA_TUNER_SONY
+ tristate Sony TV tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ A driver for the Sony tuners BTF-PG472Z, BTF-PK467Z, BTF-PB463Z.
+
+
endif # MEDIA_TUNER_CUSTOMISE
diff -r 2d2a250ca33b -r 628119533574
linux/drivers/media/common/tuners/Makefile
--- a/linux/drivers/media/common/tuners/Makefile Wed Feb 10 11:25:59
2010 -0800
+++ b/linux/drivers/media/common/tuners/Makefile Thu Feb 11 15:21:11
2010 -0800
@@ -24,6 +24,7 @@
obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_SONY) += sony-tuner.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff -r 2d2a250ca33b -r 628119533574
linux/drivers/media/common/tuners/sony-tuner.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/common/tuners/sony-tuner.c Thu Feb 11 15:21:11
2010 -0800
@@ -0,0 +1,695 @@
+/*
+ * Copyright (C) 2005-2006 Micronas USA Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tuner.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include media/v4l2-i2c-drv.h
The v4l2-i2c-drv.h is to be used only for drivers that also need to be compiled
for kernels 2.6.26. If I am not mistaken that is the case for this driver,
right? I remember you mentioning that customers of yours use this on such old
kernels. Just making sure.
+
+MODULE_DESCRIPTION(Sony TV Tuner driver);
+MODULE_LICENSE(GPL v2);
+
+/* #define MPX_DEBUG */
+
+/* AS(IF/MPX) pin: LOW HIGH/OPEN
+ * IF/MPX address: 0x42/0x40 0x43/0x44
+ */
+#define IF_I2C_ADDR 0x43
+#define MPX_I2C_ADDR 0x44
+
+static v4l2_std_id force_band;
+static char force_band_str[] = -;
+module_param_string(force_band, force_band_str, sizeof(force_band_str),
0644);
+static int force_mpx_mode = -1;
+module_param(force_mpx_mode, int, 0644);
+
+/* Store tuner info in the same format as tuner.c, so maybe we can put the
+ * Sony tuner support in there. */
+struct sony_tunertype {
+ char *name;
This probably should be const char *.
+ unsigned char Vendor; /* unused here */
+ unsigned char Type; /* unused here */
+
+ unsigned short thresh1; /* band switch VHF_LO = VHF_HI */
+ unsigned short thresh2; /* band switch VHF_HI = UHF */
+ unsigned char VHF_L;
+ unsigned char VHF_H;
+ unsigned char UHF;
+ unsigned char config;
+ unsigned short IFPCoff;
+};
+
+/* This array is indexed by (tuner_type - TUNER_SONY_BTF_PG472Z) */
+static struct sony_tunertype sony_tuners[] = {
This probably should be const as well.
+ { Sony PAL+SECAM (BTF-PG472Z), 0, 0,
+ 16*144.25, 16*427.25, 0x01, 0x02, 0x04, 0xc6, 623},
+ { Sony NTSC_JP (BTF-PK467Z), 0, 0,
+ 16*220.25, 16*467.25, 0x01, 0x02, 0x04, 0xc6,
Re: [PATCH v2 2/2] radio: Add radio-timb to the Kconfig and Makefile
On Wednesday 03 February 2010 10:58:14 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: On Wednesday 27 January 2010 17:22:10 Richard Röjfors wrote: This patch adds radio-timb to the Makefile and Kconfig. +config RADIO_TIMBERDALE + tristate Enable the Timberdale radio driver + depends on MFD_TIMBERDALE VIDEO_V4L2 HAS_IOMEM I think you need a dependency on I2C as well. It is not needed. VIDEO_V4L2 already takes care of properly handling it. Where does that happen? I don't see how VIDEO_V4L2 can know when a driver requires I2C. It's not a universal requirement, after all. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] tw2804: video decoder subdev conversion
On Friday 12 February 2010 01:33:12 Pete Eberlein wrote:
From: Pete Eberlein p...@sensoray.com
This is a subdev conversion of wis-tw2804 video decoder from the
staging go7007 directory. This obsoletes the wis-tw2804 driver.
Review below...
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r f7edcbfeb63c -r 024987c00f06 linux/drivers/media/video/Kconfig
--- a/linux/drivers/media/video/Kconfig Wed Feb 10 15:06:05 2010 -0800
+++ b/linux/drivers/media/video/Kconfig Thu Feb 11 14:34:39 2010 -0800
@@ -368,6 +368,12 @@
To compile this driver as a module, choose M here: the
module will be called saa7191.
+config VIDEO_TW2804
+ tristate Techwell 2804 video decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ Support for the Techwell 2804 video decoder.
+
config VIDEO_TVP514X
tristate Texas Instruments TVP514x video decoder
depends on VIDEO_V4L2 I2C
diff -r f7edcbfeb63c -r 024987c00f06 linux/drivers/media/video/Makefile
--- a/linux/drivers/media/video/Makefile Wed Feb 10 15:06:05 2010 -0800
+++ b/linux/drivers/media/video/Makefile Thu Feb 11 14:34:39 2010 -0800
@@ -71,6 +71,7 @@
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
+obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o
diff -r f7edcbfeb63c -r 024987c00f06 linux/drivers/media/video/tw2804.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/video/tw2804.c Thu Feb 11 14:34:39 2010 -0800
@@ -0,0 +1,398 @@
+/*
+ * Copyright (C) 2005-2006 Micronas USA Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include linux/ioctl.h
+#include media/v4l2-device.h
+#include media/v4l2-i2c-drv.h
+
+MODULE_DESCRIPTION(TW2804 I2C subdev driver);
+MODULE_LICENSE(GPL v2);
+
+struct tw2804 {
+ struct v4l2_subdev sd;
+ int channel;
+ v4l2_std_id norm;
+ int brightness;
+ int contrast;
+ int saturation;
+ int hue;
+};
+
+static inline struct tw2804 *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct tw2804, sd);
+}
+
+static u8 global_registers[] =
const
+{
+ 0x39, 0x00,
+ 0x3a, 0xff,
+ 0x3b, 0x84,
+ 0x3c, 0x80,
+ 0x3d, 0x80,
+ 0x3e, 0x82,
+ 0x3f, 0x82,
+ 0xff, 0xff, /* Terminator (reg 0xff does not exist) */
+};
+
+static u8 channel_registers[] =
const
+{
+ 0x01, 0xc4,
+ 0x02, 0xa5,
+ 0x03, 0x20,
+ 0x04, 0xd0,
+ 0x05, 0x20,
+ 0x06, 0xd0,
+ 0x07, 0x88,
+ 0x08, 0x20,
+ 0x09, 0x07,
+ 0x0a, 0xf0,
+ 0x0b, 0x07,
+ 0x0c, 0xf0,
+ 0x0d, 0x40,
+ 0x0e, 0xd2,
+ 0x0f, 0x80,
+ 0x10, 0x80,
+ 0x11, 0x80,
+ 0x12, 0x80,
+ 0x13, 0x1f,
+ 0x14, 0x00,
+ 0x15, 0x00,
+ 0x16, 0x00,
+ 0x17, 0x00,
+ 0x18, 0xff,
+ 0x19, 0xff,
+ 0x1a, 0xff,
+ 0x1b, 0xff,
+ 0x1c, 0xff,
+ 0x1d, 0xff,
+ 0x1e, 0xff,
+ 0x1f, 0xff,
+ 0x20, 0x07,
+ 0x21, 0x07,
+ 0x22, 0x00,
+ 0x23, 0x91,
+ 0x24, 0x51,
+ 0x25, 0x03,
+ 0x26, 0x00,
+ 0x27, 0x00,
+ 0x28, 0x00,
+ 0x29, 0x00,
+ 0x2a, 0x00,
+ 0x2b, 0x00,
+ 0x2c, 0x00,
+ 0x2d, 0x00,
+ 0x2e, 0x00,
+ 0x2f, 0x00,
+ 0x30, 0x00,
+ 0x31, 0x00,
+ 0x32, 0x00,
+ 0x33, 0x00,
+ 0x34, 0x00,
+ 0x35, 0x00,
+ 0x36, 0x00,
+ 0x37, 0x00,
+ 0xff, 0xff, /* Terminator (reg 0xff does not exist) */
+};
+
+static int write_reg(struct v4l2_subdev *sd, u8 reg, u8 value, int channel)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_write_byte_data(client, reg | (channel 6), value);
+}
+
+static int write_regs(struct v4l2_subdev *sd, u8 *regs, int channel)
+{
+ int i;
+
+ for (i = 0; regs[i] != 0xff; i += 2)
+ if (write_reg(sd, regs[i], regs[i + 1], channel) 0)
+ return -1;
+ return 0;
+}
+
+static int tw2804_s_config(struct v4l2_subdev *sd,
+
Re: [PATCH 4/5]
On Friday 12 February 2010 01:33:20 Pete Eberlein wrote:
From: Pete Eberlein p...@sensoray.com
This is a subdev conversion of wis-tw9903 video decoder from the
staging go7007 directory. This obsoletes the wis-tw9903 driver.
Review below...
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r 024987c00f06 -r 378d3bc9a3d6 linux/drivers/media/video/Kconfig
--- a/linux/drivers/media/video/Kconfig Thu Feb 11 14:34:39 2010 -0800
+++ b/linux/drivers/media/video/Kconfig Thu Feb 11 14:48:26 2010 -0800
@@ -374,6 +374,12 @@
---help---
Support for the Techwell 2804 video decoder.
+config VIDEO_TW9903
+ tristate Techwell 9903 video decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ Support for the Techwell 9903 video decoder.
+
config VIDEO_TVP514X
tristate Texas Instruments TVP514x video decoder
depends on VIDEO_V4L2 I2C
diff -r 024987c00f06 -r 378d3bc9a3d6 linux/drivers/media/video/Makefile
--- a/linux/drivers/media/video/Makefile Thu Feb 11 14:34:39 2010 -0800
+++ b/linux/drivers/media/video/Makefile Thu Feb 11 14:48:26 2010 -0800
@@ -72,6 +72,7 @@
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
+obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o
diff -r 024987c00f06 -r 378d3bc9a3d6 linux/drivers/media/video/tw9903.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/video/tw9903.c Thu Feb 11 14:48:26 2010 -0800
@@ -0,0 +1,370 @@
+/*
+ * Copyright (C) 2005-2006 Micronas USA Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include linux/ioctl.h
+#include media/v4l2-device.h
+#include media/v4l2-i2c-drv.h
+
+MODULE_DESCRIPTION(TW9903 I2C subdev driver);
+MODULE_LICENSE(GPL v2);
+
+struct tw9903 {
+ struct v4l2_subdev sd;
+ v4l2_std_id norm;
+ int brightness;
+ int contrast;
+#if 0 /* keep */
+ int saturation;
+#endif
+ int hue;
+};
+
+static inline struct tw9903 *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct tw9903, sd);
+}
+
+static u8 initial_registers[] =
const
+{
+ 0x02, 0x44, /* input 1, composite */
+ 0x03, 0x92, /* correct digital format */
+ 0x04, 0x00,
+ 0x05, 0x80, /* or 0x00 for PAL */
+ 0x06, 0x40, /* second internal current reference */
+ 0x07, 0x02, /* window */
+ 0x08, 0x14, /* window */
+ 0x09, 0xf0, /* window */
+ 0x0a, 0x81, /* window */
+ 0x0b, 0xd0, /* window */
+ 0x0c, 0x8c,
+ 0x0d, 0x00, /* scaling */
+ 0x0e, 0x11, /* scaling */
+ 0x0f, 0x00, /* scaling */
+ 0x10, 0x00, /* brightness */
+ 0x11, 0x60, /* contrast */
+ 0x12, 0x01, /* sharpness */
+ 0x13, 0x7f, /* U gain */
+ 0x14, 0x5a, /* V gain */
+ 0x15, 0x00, /* hue */
+ 0x16, 0xc3, /* sharpness */
+ 0x18, 0x00,
+ 0x19, 0x58, /* vbi */
+ 0x1a, 0x80,
+ 0x1c, 0x0f, /* video norm */
+ 0x1d, 0x7f, /* video norm */
+ 0x20, 0xa0, /* clamping gain (working 0x50) */
+ 0x21, 0x22,
+ 0x22, 0xf0,
+ 0x23, 0xfe,
+ 0x24, 0x3c,
+ 0x25, 0x38,
+ 0x26, 0x44,
+ 0x27, 0x20,
+ 0x28, 0x00,
+ 0x29, 0x15,
+ 0x2a, 0xa0,
+ 0x2b, 0x44,
+ 0x2c, 0x37,
+ 0x2d, 0x00,
+ 0x2e, 0xa5, /* burst PLL control (working: a9) */
+ 0x2f, 0xe0, /* 0xea is blue test frame -- 0xe0 for normal */
+ 0x31, 0x00,
+ 0x33, 0x22,
+ 0x34, 0x11,
+ 0x35, 0x35,
+ 0x3b, 0x05,
+ 0x06, 0xc0, /* reset device */
+ 0x00, 0x00, /* Terminator (reg 0x00 is read-only) */
+};
+
+static int write_reg(struct v4l2_subdev *sd, u8 reg, u8 value)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_write_byte_data(client, reg, value);
+}
+
+static int write_regs(struct v4l2_subdev *sd, u8 *regs)
+{
+ int i;
+
+ for (i = 0; regs[i] != 0x00; i += 2)
+ if (write_reg(sd, regs[i], regs[i + 1]) 0)
+ return -1;
+ return 0;
+}
+
+static int
Re: [PATCH 5/5] ov7640: sensor driver subdev conversion
On Friday 12 February 2010 01:33:27 Pete Eberlein wrote:
From: Pete Eberlein p...@sensoray.com
This is a subdev conversion of wis-ov7640 sensor driver from the
staging go7007 directory. This obsoletes the wis-ov7640 driver.
Review below...
BTW: note that the gspca/ov519.c driver also has support for this sensor.
Unfortunately, the gspca subdrivers do not use v4l2_subdev. It might be
useful though as a reference. gspca should really start to use v4l2_subdev
where possible.
Priority: normal
Signed-off-by: Pete Eberlein p...@sensoray.com
diff -r 378d3bc9a3d6 -r 6d0a37622c1b linux/drivers/media/video/Kconfig
--- a/linux/drivers/media/video/Kconfig Thu Feb 11 14:48:26 2010 -0800
+++ b/linux/drivers/media/video/Kconfig Thu Feb 11 14:57:40 2010 -0800
@@ -309,6 +309,13 @@
To compile this driver as a module, choose M here: the
module will be called ks0127.
+config VIDEO_OV7640
+ tristate OmniVision OV7640 sensor support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
Replace 'Video4Linux2 sensor-level' with just 'sensor'.
+ OV7640 camera. It currently only works with the GO7007 driver.
Why does it only work with go7007? Oh, I see: it's only a hardcoded list of
registers.
+
config VIDEO_OV7670
tristate OmniVision OV7670 sensor support
depends on I2C VIDEO_V4L2
diff -r 378d3bc9a3d6 -r 6d0a37622c1b linux/drivers/media/video/Makefile
--- a/linux/drivers/media/video/Makefile Thu Feb 11 14:48:26 2010 -0800
+++ b/linux/drivers/media/video/Makefile Thu Feb 11 14:57:40 2010 -0800
@@ -67,6 +67,7 @@
obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
diff -r 378d3bc9a3d6 -r 6d0a37622c1b linux/drivers/media/video/ov7640.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/video/ov7640.c Thu Feb 11 14:57:40 2010 -0800
@@ -0,0 +1,141 @@
+/*
+ * Copyright (C) 2005-2006 Micronas USA Inc.
You probably want to add a copyright line of your own for the drivers you
worked on.
You should also clearly state in this driver that it is setup specifically
for the go7007.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+MODULE_DESCRIPTION(OmniVision ov7640 sensor driver);
+MODULE_LICENSE(GPL v2);
+
+struct ov7640_info {
+ struct v4l2_subdev sd;
+ int brightness;
+ int contrast;
+ int saturation;
+ int hue;
+};
+
+static inline struct ov7640_info *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov7640_info, sd);
+}
+
+
+static u8 initial_registers[] =
const
+{
+ 0x12, 0x80,
+ 0x12, 0x54,
+ 0x14, 0x24,
+ 0x15, 0x01,
+ 0x28, 0x20,
+ 0x75, 0x82,
+ 0xFF, 0xFF, /* Terminator (reg 0xFF is unused) */
Please document at least how this sensor is set up for the go7007.
+};
+
+static int write_regs(struct i2c_client *client, u8 *regs)
+{
+ int i;
+
+ for (i = 0; regs[i] != 0xFF; i += 2)
+ if (i2c_smbus_write_byte_data(client, regs[i], regs[i + 1]) 0)
+ return -1;
+ return 0;
+}
+
+
+static int ov7640_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_OV7640, 0);
+}
I recommend added g_chip_ident as well to the tw drivers.
+
+/* --- */
+
+static const struct v4l2_subdev_core_ops ov7640_core_ops = {
+ .g_chip_ident = ov7640_g_chip_ident,
+};
+
+static const struct v4l2_subdev_ops ov7640_ops = {
+ .core = ov7640_core_ops,
+};
+
+/* --- */
+
+static int ov7640_probe(struct i2c_client
Fwd: problem with my webcam
This is an uvcvideo issue and possible libv4l. Let's ask the list instead. Regards, Erik -- Forwarded message -- From: Jörg Schleede joerg.schle...@cae.de Date: 2010/2/12 Subject: problem with my webcam To: erik.and...@gmail.com erik.and...@gmail.com Hallo erik, i have an notebook from asus k51v with an builtin webcam. I think the Webcam was glued in . This webcam was false built in so that the picture stands upside down. The Webcam use the driver uvcvideo.ko . Now my Question: How can I rotate the Picture to 180 degree. Can I give the driver or v4l a parameter to do this? kind regards, Jörg Schleede -- This email was Anti Virus checked by CAE -- 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: zr364xx: Aiptek DV8800 (neo): 08ca:2062: Fails on subsequent zr364xx_open()
Hi Antoine,
Antoine Jacquet wrote:
Hi Thomas,
Looks like the device does not like to be fed with the (full) init
METHOD2 on every open()...
Since the VIDIOC_QUERYCAP worked it should not be the wrong METHOD.
Someone reported similar behavior recently, and was apparently able to
fix the issue by adding more delay between open/close sequences.
No search tags to find it on the list, can You remember device model?
Could you try the attached patch to see if it solves the issue?
Didn't work, same -110 errors, sorry, no v4l-dvb git here, vdr production
machine on 2.6.32.7.
If not, we can also try to add some mdelay() after each usb_control_msg().
1. Patch with optimized delay below, slow but works, 1st try was delaying subsequent msg
at open sequence i=6, worked until the last 2 open() before capture start.
From the windows snoopy log I sent yesterday I can see only 1-2 URBs with relevant delay of ~1s but
cannot see the sequence point.
What is error -22, can not find it in errno.h?
2. Picture with (640-320) lines alignment error with ekiga+cheese
*attached*, wether cam is configured internally for 640x480 or 320x240, not affecting.
setting the driver to mode=2 fails with libv4l jpeg decoding errors. I try to
correct this.
3. Driver oops on modprobe -r or device firmware crash,
I need to unplug first or null pointer fault occours (mutex locks), see below
Regards,
Antoine
y
tom
--- drivers/media/video/zr364xx.c.orig 2009-12-18 23:27:07.0 +0100
+++ drivers/media/video/zr364xx.c 2010-02-12 12:57:54.0 +0100
@@ -205,40 +205,41 @@
struct zr364xx_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
const struct zr364xx_fmt *fmt;
};
/* function used to send initialisation commands to the camera */
static int send_control_msg(struct usb_device *udev, u8 request, u16 value,
u16 index, unsigned char *cp, u16 size)
{
int status;
unsigned char *transfer_buffer = kmalloc(size, GFP_KERNEL);
if (!transfer_buffer) {
dev_err(udev-dev, kmalloc(%d) failed\n, size);
return -ENOMEM;
}
memcpy(transfer_buffer, cp, size);
+ mdelay(300);
status = usb_control_msg(udev,
usb_sndctrlpipe(udev, 0),
request,
USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE, value, index,
transfer_buffer, size, CTRL_TIMEOUT);
kfree(transfer_buffer);
if (status 0)
dev_err(udev-dev,
Failed sending control message, error %d.\n, status);
return status;
}
/* Control messages sent to the camera to initialize it
* and launch the capture */
typedef struct {
@@ -1248,40 +1249,41 @@
/* open the camera */
static int zr364xx_open(struct file *file)
{
struct video_device *vdev = video_devdata(file);
struct zr364xx_camera *cam = video_drvdata(file);
struct usb_device *udev = cam-udev;
int i, err;
DBG(%s\n, __func__);
mutex_lock(cam-open_lock);
if (cam-users) {
err = -EBUSY;
goto out;
}
for (i = 0; init[cam-method][i].size != -1; i++) {
+// if (i == 6) mdelay(1000);
err =
send_control_msg(udev, 1, init[cam-method][i].value,
0, init[cam-method][i].bytes,
init[cam-method][i].size);
if (err 0) {
dev_err(cam-udev-dev,
error during open sequence: %d\n, i);
goto out;
}
}
cam-skip = 2;
cam-users++;
file-private_data = vdev;
cam-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
cam-fmt = formats;
videobuf_queue_vmalloc_init(cam-vb_vidq, zr364xx_video_qops,
NULL, cam-slock,
cam-type,
usb 1-2: new high speed USB device using ehci_hcd and address 7
usb 1-2: New USB device found, idVendor=08ca, idProduct=2062
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: DV 8800
usb 1-2: Manufacturer: AIPTEK
usb 1-2: configuration #1 chosen from 1 choice
zr364xx probing...
zr364xx 1-2:1.0: Zoran 364xx compatible webcam plugged
zr364xx 1-2:1.0: model 08ca:2062 detected
usb 1-2: 320x240 mode selected
zr364xx dev: 880039379000, udev 8800388d1800 interface 880039380a00
zr364xx num endpoints 3
zr364xx board init: 880039379000
zr364xx valloc 880039379028, idx 0, pdata c900019ef000
zr364xx zr364xx_start_readpipe: start pipe IN x81
zr364xx submitting URB 8800393a1900
zr364xx : board initialized
usb 1-2: Zoran 364xx controlling
Re: New Hauppauge HVR-2200 Revision?
Anyway, apart from the problems noted above it is fine. I'm not sure what the criteria is for merging support for this card into the main repository, but I would view it as worthy of merging even with these problems outstanding. Many thanks, Frank. Interestingly, so far it only seems to affect the second adapter. The first one is still working. Odd. Francis, I find the whole ber/unc values puzzling, essentially they shouldn't happen assuming a good clean DVB-T signal. I'm going to look into this very shortly, along with a broad locking feature I want to change in the demod. I've had one or two other people comment on the -stable tree and in general they're pretty happy, including myself, which means that I'll be generating a pull request to have these changes merged very shortly (1-2 weeks). Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Proposal for a V4L2 Media Controller mini-summit
Hi all, During the Linux Plumbers Conference in September 2009 I organized a V4L-DVB mini-summit. The focus of that summit was on discussing a framework through which we could support all the functionality that the video hardware of modern embedded devices provides. It was a very successful summit and a lot of work has been done since that time. See this posting for to get an idea of what was discussed for those who were not present: http://www.mail-archive.com/linux-media@vger.kernel.org/msg10136.html Since that time we have added a new API to support HDTV formats, a new event API is almost ready, a lot of work is being done on the media controller API with omap3 as guinea pig and Samsung has done work on the memory handling of V4L2. From April 12th to 14th the CELF Embedded Linux Conference is held in San Francisco, and it is co-located with the Linux Foundation Collaboration Summit (April 14th-16th). Links to these conferences are here: http://www.embeddedlinuxconference.com/elc_2010/index.html http://events.linuxfoundation.org/events/collaboration-summit I will be doing a presentation on the new framework during the ELC. Since this conference is about 6 months after the mini-summit I consider this a good time to organize a new V4L2 Media Controller mini-summit to discuss progress and future work in this area. I think that particular attention should be given to how we are going to do memory handling. The proposals from Samsung have received very little attention and we should discuss those in more detail. I do not know on which dates exactly such a summit can take place. There are three possibilities: April 10-11/12 April 12-14 April 14/15-16 I think that registering for the ELC gives to free access to the Collaboration Summit, but I'm waiting for a confirmation on that. I'm not keen on the center option (12-14 April) since that often means that you don't see a lot of the conference itself. And the ELC is generally quite interesting. There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) 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
[Fwd: + timberdale-fix-mfd-build.patch added to -mm tree]
Mensagem original Assunto: + timberdale-fix-mfd-build.patch added to -mm tree Data: Thu, 11 Feb 2010 16:43:31 -0800 De: a...@linux-foundation.org Para: mm-comm...@vger.kernel.org CC: randy.dun...@oracle.com, mche...@redhat.com, richard.rojf...@pelagicore.com, sa...@linux.intel.com The patch titled timberdale: fix mfd build has been added to the -mm tree. Its filename is timberdale-fix-mfd-build.patch Before you just go and hit reply, please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ -- Subject: timberdale: fix mfd build From: Randy Dunlap randy.dun...@oracle.com Fix mfd/timberdale build error -- add depends GPIOLIB. include/linux/spi/max7301.h:14: error: field 'chip' has incomplete type build-r7353.out:make[3]: *** [drivers/mfd/timberdale.o] Error 1 Repairs commit ff7a26e08a16bb31158d830dbf60db2ff47019ab Author: Richard RC3B6jfors richard.rojf...@pelagicore.com AuthorDate: Thu Feb 4 08:18:52 2010 -0300 Commit: Mauro Carvalho Chehab mche...@redhat.com CommitDate: Fri Feb 5 12:25:37 2010 -0200 V4L/DVB: mfd: Add support for the timberdale FPGA Signed-off-by: Randy Dunlap randy.dun...@oracle.com Cc: Richard Rojfors richard.rojf...@pelagicore.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/mfd/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/mfd/Kconfig~timberdale-fix-mfd-build drivers/mfd/Kconfig --- a/drivers/mfd/Kconfig~timberdale-fix-mfd-build +++ a/drivers/mfd/Kconfig @@ -382,7 +382,7 @@ config AB4500_CORE config MFD_TIMBERDALE tristate Support for the Timberdale FPGA select MFD_CORE - depends on PCI + depends on PCI GPIOLIB ---help--- This is the core driver for the timberdale FPGA. This device is a multifunction device which exposes numerous platform devices. _ Patches currently in -mm which might be from randy.dun...@oracle.com are linux-next.patch msi-laptop-depends-on-rfkill.patch dib3000mc-reduce-large-stack-usage.patch dib7000p-reduce-large-stack-usage.patch timberdale-fix-mfd-build.patch i2c-fix-xiic-build-error.patch mfgpt-move-clocksource-menu.patch elf-coredump-replace-elf_core_extra_-macros-by-functions-fix.patch xen-add-kconfig-menu.patch gpio-add-driver-for-max7300-i2c-gpio-extender.patch doc-console-doc-should-read-bind-unbind-instead-of-bind-bind.patch documentation-timers-split-txt-and-source-files.patch documentation-laptop-split-txt-and-source-files.patch documentation-fs-split-txt-and-source-files.patch documentation-vm-split-txt-and-source-files.patch cgroups-subsystem-module-unloading-fix.patch memcg-move-charges-of-anonymous-swap-fix.patch memcg-improve-performance-in-moving-swap-charge-fix.patch cgroup-implement-eventfd-based-generic-api-for-notifications-kconfig-fix.patch reiser4-export-remove_from_page_cache-fix.patch mutex-subsystem-synchro-test-module-add-missing-header-file.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: saa7134 and üPD61151 MPEG2 coder
On Tuesday 09 February 2010 06:41:50 Dmitri Belimov wrote:
Hi Hans
This is my last state for review.
After small time I'll finish process of initialize the encoder.
Configure some register, upload two firmware for video and for audio.
Configure the frontends.
I have the questions.
For configuring audio frontend need know samplerate of audio.
saa7134 can only 32kHz
saa7131/3/5 on I2S 32кГц from SIF source and 32/44.1/48 from external i.e.
RCA stereo audio input.
Hardcode 32kHz or need a function for determine mode of audio??
See struct v4l2_subdev_audio_ops: it has a s_clock_freq op for precisely that
purpose. The saa7134 should call that whenever it sets a new samplerate.
Other question. For configure VideoFrontend need know 50 or 60Hz
Now I use videomode from h structure. I think more correct detect it
on saa7134.
Whether it is 50 or 60 Hz depends on the video standard that you receive via
the s_std core op. Just implement that and when you get a new standard you
can use something like this: is_60hz = (std V4L2_STD_525_60) ? 1 : 0;
Some more review comments:
linux/drivers/media/video/saa7134/saa7134.h:
@@ -355,6 +377,10 @@
unsigned char empress_addr;
unsigned char rds_addr;
+ /* SPI info */
+ struct saa7134_software_spi spi;
+ struct spi_board_info spi_conf;
Make this a struct spi_board_info *. This struct is too large: it is only used
in one board but all elements of the board array will suddenly get this whole
struct increasing the memory footprint substantially. In this case you can just
make it a pointer, that will work just as well.
+
unsigned inttda9887_conf;
unsigned inttuner_config;
linux/drivers/media/video/v4l2-common.c, in v4l2_spi_subdev_init():
+ /* initialize name */
+ snprintf(sd-name, sizeof(sd-name), %s,
+ spi-dev.driver-name);
Use strlcpy here.
saa7134-spi.c:
static inline u32 getmiso(struct spi_device *dev)
{
struct saa7134_spi_gpio *sb = to_sb(dev);
unsigned long status;
status = saa7134_get_gpio(sb-controller_data);
if ( status (1 sb-controller_data-spi.miso))
return 1;
else
return 0;
}
Simplify to:
static inline u32 getmiso(struct spi_device *dev)
{
struct saa7134_spi_gpio *sb = to_sb(dev);
u32 status;
status = saa7134_get_gpio(sb-controller_data);
return !!(status (1 sb-controller_data-spi.miso));
}
Also note that saa7134_get_gpio should return an u32 since unsigned long is
64 bits when compiled on a 64-bit kernel, which is probably not what you want.
saa7134_spi_unregister can be a void function as the result code is always 0.
There seems to be some old stuff in upd61151.h. Please remove what is not
needed.
In upd61151.c I highly recommend that all functions will use struct v4l2_subdev
*sd
as argument. Only at the lowest level should you go from sd to spi. Among
others this allows you to use the standard v4l2_info/dbg etc. logging functions.
Don't use RESULT_SUCCESS. Just return 0.
Remove upd61151_init. The init op is rarely needed and should in general not
be used.
Remove those emacs editor comments at the end of the files. That's bad practice.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Requested feedback on V4L2 driver design
Laurent, First let me thank you for taking time to review this. I have made comments below to address your concerns. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Thursday, February 11, 2010 7:23 PM To: Maupin, Chase Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver design (May contain non-TIers); linux- me...@vger.kernel.org Subject: Re: Requested feedback on V4L2 driver design Hi Chase, On Monday 08 February 2010 16:08:37 Maupin, Chase wrote: All, Texas Instruments (TI) is working on the design for the V4L2 capture and display drivers for our next generation system-on-chip (SoC) processor and would like to solicit your feedback. Thank you very much for requesting feedback on the system design. I personally appreciate this, and I'm pretty sure that the feeling is shared by most of the Linux kernel developers. If you have additional questions or need more information please feel free to contact us (we have setup a mailing list at vpss_driver_des...@list.ti.com) so we can answer them. I'll answer here as the instructions provided in the wiki to subscribe to the vpss_driver_design mailing list are incorrect (http://list.ti.com/ isn't accessible, the name has no A record associated to it). I've CC'ed the list in case subscription wouldn't be required to post. The page for subscribing to the list requires a my.TI login which you can setup at https://myportal.ti.com/portal/dt?provider=TIPassLoginSingleContainerlt=mytij5=2j3=1goto=https%3A%2F%2Fmy.ti.com%3A443%2Fcgi-bin%2Fhome.pl%3FDCMP%3DTIHeaderTracking%26HQS%3DOther%2BOT%2Bhdr_my_ti. However, your reply to the list should be fine without subscribing. 1. Multi-core design OMAP3 was already a dual-core system, OMAP4 (I assume all this is about the OMAP4 processors family) seems to push the concept one step further. With its heterogeneous multi-core design (ARM master CPU and slave DSPs), the OMAP architecture delivers high performances at the cost of higher development time and effort as users need to write software for completely different cores, usually using different toolchains. This is in my opinion a good (or at least acceptable) trade-off between CPU power, development time and power consumption (DSPs being more efficient at signal processing at the cost of a higher development complexity). I'm a bit puzzled, however, by how the VPSS MCU will help improving the situation compared to the OMAP3 design. The VPSS MCU will provide an API that will expose a fixed subset of the hardware capabilities. This is only a guess, but I suppose the firmware will be fairly generic, and that TI will provide customized versions to big customers tailored for their needs and use cases. The official kernel drivers will then need to be changed, and those changes will have no chance to be accepted in the mainline kernel. This will lead to forks and fragmentation of the developers base among the big players in the embedded markets. What will be the compensation for that ? How will the VPSS MCU provide higher performances than the OMAP3 model ? The firmware on the VPSS MCU will be able to configure/control all of the functionality that the VPSS MCU has and will be the same for all customers. The only part that may change is the proxy driver of the firmware. The proxy driver is the piece that will be responsible for taking the commands from the driver and telling the firmware to execute the operation. The initial version of the proxy will support all the standard V4L2 operations. As new operations (such as on the fly video scaling) are added to the V4L2 API the firmware may require an update to the proxy driver to handle these requests, but the underlying code will remain the same. For customers who wish to use features of the VPSS that are not supported by the current V4L2 APIs there are OpenMax components being developed that can also talk to the VPSS and support the full set of features of the VPSS. These components allow for additional use cases such as transferring data directly from other processing blocks such as the DSP to the VPSS without ever returning to the host processor (tunneling). However, the OpenMax API does not integrate with most existing software such as applications that use V4L2 drivers for video capture and display. What this means is that we will not be creating a bunch of one-off drivers for customers who want to use features that are not part of the V4L2 APIs. Instead those customers will be able to use the OpenMax components. The Linux V4L2
Re: DTV2000 H Plus issues
Here is another patch, with a few minor changes. It depends on the
previously posted patches, so those should be applied first.
diff -r -d -N -U4 v4l-dvb-28f5eca12bb0.old/linux/drivers/media/common/tuners/xc4000.c v4l-dvb-28f5eca12bb0/linux/drivers/media/common/tuners/xc4000.c
--- v4l-dvb-28f5eca12bb0.old/linux/drivers/media/common/tuners/xc4000.c 2010-02-12 19:14:24.0 +0100
+++ v4l-dvb-28f5eca12bb0/linux/drivers/media/common/tuners/xc4000.c 2010-02-12 19:20:35.0 +0100
@@ -256,8 +256,9 @@
};
static int xc4000_readreg(struct xc4000_priv *priv, u16 reg, u16 *val);
static int xc4000_TunerReset(struct dvb_frontend *fe);
+static void xc_debug_dump(struct xc4000_priv *priv);
static int xc_send_i2c_data(struct xc4000_priv *priv, u8 *buf, int len)
{
struct i2c_msg msg = { .addr = priv-i2c_props.addr,
@@ -332,12 +333,14 @@
(i2c_sequence[index + 1] != 0xFF)) {
len = i2c_sequence[index] * 256 + i2c_sequence[index+1];
if (len == 0x) {
/* RESET command */
- result = xc4000_TunerReset(fe);
index += 2;
+#if 0 /* not needed, as already called by check_firmware() */
+ result = xc4000_TunerReset(fe);
if (result != XC_RESULT_SUCCESS)
return result;
+#endif
} else if (len 0x8000) {
/* WAIT command */
xc_wait(len 0x7FFF);
index += 2;
@@ -472,14 +475,8 @@
return 0;
}
-/* WAS THERE
-static int xc_get_buildversion(struct xc4000_priv *priv, u16 *buildrev)
-{
- return xc4000_readreg(priv, XREG_BUILD, buildrev);
-}*/
-
static int xc_get_hsync_freq(struct xc4000_priv *priv, u32 *hsync_freq_hz)
{
u16 regData;
int result;
@@ -516,14 +513,12 @@
}
return lockState;
}
-#define XC_TUNE_ANALOG 0
-#define XC_TUNE_DIGITAL 1
-static int xc_tune_channel(struct xc4000_priv *priv, u32 freq_hz, int mode)
+static int xc_tune_channel(struct xc4000_priv *priv, u32 freq_hz)
{
- int found = 0;
- int result = 0;
+ int found = 1;
+ int result;
dprintk(1, %s(%u)\n, __func__, freq_hz);
/* Don't complain when the request fails because of i2c stretching */
@@ -533,13 +528,23 @@
if (result != XC_RESULT_SUCCESS)
return 0;
- if (mode == XC_TUNE_ANALOG) {
- if (WaitForLock(priv) == 1)
- found = 1;
+ /* wait for lock only in analog TV mode */
+ if ((priv-cur_fw.type (FM | DTV6 | DTV7 | DTV78 | DTV8)) == 0) {
+ if (WaitForLock(priv) == 0)
+ found = 0;
}
+ /* Wait for stats to stabilize.
+ * Frame Lines needs two frame times after initial lock
+ * before it is valid.
+ */
+ xc_wait(debug ? 100 : 10);
+
+ if (debug)
+ xc_debug_dump(priv);
+
return found;
}
static int xc4000_readreg(struct xc4000_priv *priv, u16 reg, u16 *val)
@@ -1108,17 +1113,8 @@
u16 quality;
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
- if (!(priv-cur_fw.type BASE))
- return;
-
- /* Wait for stats to stabilize.
- * Frame Lines needs two frame times after initial lock
- * before it is valid.
- */
- xc_wait(100);
-
xc_get_ADC_Envelope(priv, adc_envelope);
dprintk(1, *** ADC envelope (0-1023) = %d\n, adc_envelope);
xc_get_frequency_error(priv, freq_error_hz);
@@ -1269,12 +1265,10 @@
/* goto fail; */
}
}
- xc_tune_channel(priv, priv-freq_hz, XC_TUNE_DIGITAL);
+ xc_tune_channel(priv, priv-freq_hz);
- if (debug)
- xc_debug_dump(priv);
ret = 0;
fail:
mutex_unlock(priv-lock);
@@ -1470,12 +1464,10 @@
goto fail;
}
}
- xc_tune_channel(priv, priv-freq_hz, XC_TUNE_ANALOG);
+ xc_tune_channel(priv, priv-freq_hz);
- if (debug)
- xc_debug_dump(priv);
ret = 0;
fail:
mutex_unlock(priv-lock);
@@ -1549,9 +1541,9 @@
mutex_lock(priv-lock);
/* Avoid firmware reload on slow devices */
- if (!no_poweroff priv-cur_fw.type != XC_POWERED_DOWN) {
+ if (!no_poweroff (priv-cur_fw.type BASE) != 0) {
/* force reset and firmware reload */
priv-cur_fw.type = XC_POWERED_DOWN;
if (xc_write_reg(priv, XREG_POWER_DOWN, 0)
@@ -1560,8 +1552,9 @@
xc4000: %s() unable to shutdown tuner\n,
__func__);
ret = -EREMOTEIO;
}
+ xc_wait(20);
}
mutex_unlock(priv-lock);
@@ -1638,9 +1631,10 @@
instance = hybrid_tuner_request_state(struct xc4000_priv, priv,
hybrid_tuner_instance_list,
i2c, cfg-i2c_address, xc4000);
- priv-card_type = cfg-card_type;
+ if (cfg-card_type != XC4000_CARD_GENERIC)
+ priv-card_type = cfg-card_type;
switch (instance) {
case 0:
goto fail;
break;
@@ -1703,12 +1697,21 @@
memcpy(fe-ops.tuner_ops, xc4000_tuner_ops,
sizeof(struct dvb_tuner_ops));
+ if (instance == 1) {
+ int ret;
+ mutex_lock(priv-lock);
+ ret = xc4000_fwupload(fe);
+ mutex_unlock(priv-lock);
+ if (ret != XC_RESULT_SUCCESS)
+ goto fail2;
+ }
+
return fe;
fail:
mutex_unlock(xc4000_list_mutex);
-
+fail2:
xc4000_release(fe);
return NULL;
}
EXPORT_SYMBOL(xc4000_attach);
diff -r -d -N -U4 v4l-dvb-28f5eca12bb0.old/linux/drivers/media/video/tuner-core.c
Re: DTV2000 H Plus issues
A correction to the previous post: this line: if (WaitForLock(priv) == 0) should actually be: if (WaitForLock(priv) != 1) It does not have an effect on the operation of the driver, though, since the value set depending on this line is not used. -- 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: Proposal for a V4L2 Media Controller mini-summit
On Fri, 12 Feb 2010, Hans Verkuil wrote: Since that time we have added a new API to support HDTV formats, a new event API is almost ready, a lot of work is being done on the media controller API with omap3 as guinea pig and Samsung has done work on the memory handling of V4L2. From April 12th to 14th the CELF Embedded Linux Conference is held in San Francisco, and it is co-located with the Linux Foundation Collaboration Summit (April 14th-16th). Links to these conferences are here: http://www.embeddedlinuxconference.com/elc_2010/index.html http://events.linuxfoundation.org/events/collaboration-summit I will be doing a presentation on the new framework during the ELC. Since this conference is about 6 months after the mini-summit I consider this a good time to organize a new V4L2 Media Controller mini-summit to discuss progress and future work in this area. I think that particular attention should be given to how we are going to do memory handling. The proposals from Samsung have received very little attention and we should discuss those in more detail. I do not know on which dates exactly such a summit can take place. There are three possibilities: April 10-11/12 April 12-14 April 14/15-16 I think that registering for the ELC gives to free access to the Collaboration Summit, but I'm waiting for a confirmation on that. I'm not keen on the center option (12-14 April) since that often means that you don't see a lot of the conference itself. And the ELC is generally quite interesting. There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) I would be interested in principle in taking part in such a mini-summit, but: for me personally Europe is more easily accessible than the US, I could also consider the US, but to increase the chances for me to get there I'd need to know a couple of months in advance, getting a visa takes time, sorting out finances too. Also, 6 months is a good term, but does this mean, that there is going to be one more meeting in another 6 months? 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://jusst.de/hg/mantis-v4l-dvb
Manu Abraham wrote:
On Thu, Feb 11, 2010 at 11:44 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Manu Abraham wrote:
changeset 14166
http://jusst.de/hg/mantis-v4l-dvb/rev/c2391fa88112
Mantis: Remote Control for Mantis
+ ir_input_init(rc_dev, rc_state, IR_TYPE_OTHER);
...
+struct ir_scancode_table ir_codes_mantis_vp2040_table = {
+ .scan = ir_codes_mantis_vp2040,
+ .size = ARRAY_SIZE(ir_codes_mantis_vp2040),
+};
+EXPORT_SYMBOL_GPL(ir_codes_mantis_vp2040_table);
The non-declaration of the IR protocol and the definition of
incomplete IR codes is deprecated. Please, create a table with
the IR protocol type and add the IR address to each IR scancode
at the ir codes tables.
Please look at em28xx-input to see how to implement it right.
The change is minimal:
- at the driver, you'll need to make sure that you're
using the full IR scan code, instead of just the 8 bits for IR cmd;
- at the table: you need to use IR address+command scan code,
and declare the protocol associated with the table;
Huh ? em28xx uses a I2C based implementation for the IR.
There's no address associated with the IR stuff on the mantis, which
is on something say like COM 0/1, which is more similar, rather than
an I2C device or a polling based device.
This is true only for the old devices. The em2860/em2880 devices support
NEC and RC5. Newer chips (like em2884) also support RC6.
Anyway, the changes are not in the way the device communicates with the chip,
but
the way it is presented to IR core, and how the keycodes are decoded.
If you take a look on em28xx-input, you'll see, for example:
static int default_polling_getkey(struct em28xx_IR *ir,
struct em28xx_ir_poll_result *poll_result);
This routine gets 4 bytes from the device and stores both the RC address and
RC command (at rc_address and rc_data[0] fields).
The routine that generates the keypress events is:
static void em28xx_ir_handle_key(struct em28xx_IR *ir);
As the driver still work with the legacy keytables, it is easy to check where's
the difference between handling an incomplete or a complete keycode:
if (ir-full_code)
ir_input_keydown(ir-input, ir-ir,
poll_result.rc_address 8 |
poll_result.rc_data[0]);
else
ir_input_keydown(ir-input, ir-ir,
poll_result.rc_data[0]);
So, basically, new drivers and new keycodes should use the entire RC code
(address + data) to the input subsystem.
Also the protocol is not something that can be seen externally, It
is all internal to the firmware on the micro. The micro auto detect's
the relevant protocol. ie, what it outputs is all data, no messages.
That's even better. Yet, if you're using just the IR cmd, people won't
be able to use another IR with the device.
I don't follow what you tend to imply ..
- at the driver: instead of using IR_TYPE_OTHER, just pass the
value that comes from the IR table.
A correct implementation allows the replacement of the IR by
universal ones, at userspace, the key re-definition and, if
the driver supports more protocol, the protocol changes,
all provided by the new IR input class.
Ah, i now understand what you are trying to say.. Unfortunately you
can't do a protocol conversion or anything likewise on the Mantis IR
device. It is all in hardware and the protocol type is all auto
detected. All what you can change is the UART settings such as BPS,
Parity and STOP bit. There's nothing the user can do to change
anything in there.
To put it short: whatever remote you use, if it is a supported remote
by the firmware, it will output the relevant keycode directly, not
messages such that the message needs to be decoded further.
Yes, but the IR core allows replacing the keycode - scancode from
the driver. This allows some usecases, like:
- using a different IR;
- using the same IR, but customizing the keys;
- using a different IR to control several different devices,
where only some keys will be handled by the device.
I think I need to add add a macro to export the IR table, replacing
all *_table definitions, in order to avoid patches submitted with
the legacy way (and to remove a false-positive on checkpatch.pl).
Also there are some coding style troubles here, including bad
whitespaces. By running make whitespace, you'll be clearing most
of the warnings.
Ok, I will take a look, tomorrow evening.
Regards,
Manu
--
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: Proposal for a V4L2 Media Controller mini-summit
On Friday 12 February 2010 20:28:43 Guennadi Liakhovetski wrote: On Fri, 12 Feb 2010, Hans Verkuil wrote: Since that time we have added a new API to support HDTV formats, a new event API is almost ready, a lot of work is being done on the media controller API with omap3 as guinea pig and Samsung has done work on the memory handling of V4L2. From April 12th to 14th the CELF Embedded Linux Conference is held in San Francisco, and it is co-located with the Linux Foundation Collaboration Summit (April 14th-16th). Links to these conferences are here: http://www.embeddedlinuxconference.com/elc_2010/index.html http://events.linuxfoundation.org/events/collaboration-summit I will be doing a presentation on the new framework during the ELC. Since this conference is about 6 months after the mini-summit I consider this a good time to organize a new V4L2 Media Controller mini-summit to discuss progress and future work in this area. I think that particular attention should be given to how we are going to do memory handling. The proposals from Samsung have received very little attention and we should discuss those in more detail. I do not know on which dates exactly such a summit can take place. There are three possibilities: April 10-11/12 April 12-14 April 14/15-16 I think that registering for the ELC gives to free access to the Collaboration Summit, but I'm waiting for a confirmation on that. I'm not keen on the center option (12-14 April) since that often means that you don't see a lot of the conference itself. And the ELC is generally quite interesting. There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) I would be interested in principle in taking part in such a mini-summit, but: for me personally Europe is more easily accessible than the US, I could also consider the US, but to increase the chances for me to get there I'd need to know a couple of months in advance, getting a visa takes time, sorting out finances too. Also, 6 months is a good term, but does this mean, that there is going to be one more meeting in another 6 months? That is at least my intention. Most likely during/before/after the 2010 Plumbers Conference which is held in Cambridge, MA, USA, November 3-5. There will also be an Embedded Linux Conference this fall in Europe. And I think I heard that that will be held in Cambridge, UK (so don't mix those two up :-) ). It is likely that I will be there as well. In general: if people are interested in an interim meeting between European developers, then just let me know. I should be able to organize something like that at the Tandberg offices in Norway, for example. 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Feb 12 19:00:21 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14198:14021dfc00f3 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-rc5-armv5-davinci: ERRORS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-rc5-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] sony-tuner: Subdev conversion from wis-sony-tuner
On Fri, 2010-02-12 at 12:29 +0100, Hans Verkuil wrote:
On Friday 12 February 2010 01:33:07 Pete Eberlein wrote:
From: Pete Eberlein p...@sensoray.com
This is a subdev conversion of the go7007 wis-sony-tuner i2c driver,
and places it with the other tuner drivers. This obsoletes the
wis-sony-tuner driver in the go7007 staging directory.
Thanks! Here is a quick review...
Thanks, please have a look at my questions below:
+#include media/v4l2-i2c-drv.h
The v4l2-i2c-drv.h is to be used only for drivers that also need to be
compiled
for kernels 2.6.26. If I am not mistaken that is the case for this driver,
right? I remember you mentioning that customers of yours use this on such old
kernels. Just making sure.
My company, Sensoray, doesn't have any products that use this tuner.
This driver was orignally written by Micronas to support their go7007
chip in the Plextor TV402U models. I don't have the datasheet or know
much about tuners anyway. I used the v4l2-i2c-drv.h since it seems like
a good idea at the time. What should I use instead?
+static int sony_tuner_g_frequency(struct v4l2_subdev *sd,
+ struct v4l2_frequency *freq)
+{
+ struct sony_tuner *t = to_state(sd);
+
+ freq-frequency = t-freq;
You need to check both the tuner and type field of struct v4l2_frequency here.
What should I check v4l2_frequency-tuner against? The v4l2 docs say
that it should be the same as the struct v4l2_tuner index field, which
only the parent device driver knows.
+static int sony_tuner_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner
*vt)
+{
+ struct sony_tuner *t = to_state(sd);
+
+ memset(vt, 0, sizeof(*vt));
No need to memset, that's already been done by the v4l core.
Ok.
You should check the vt-index field here.
The parent device driver knows the index and checks it already. However
this could be a problem if there are multiple tuner that use this subdev
driver. Is there some function to tell a tuner subdev what its index
should be?
+ strcpy(vt-name, Television);
Please use strlcpy.
Ok.
+ vt-type = V4L2_TUNER_ANALOG_TV;
+ vt-rangelow = 0UL; /* does anything use these? */
+ vt-rangehigh = 0xUL;
If you know the minimum and maximum frequencies then you should set them
here. Applications that scan for channel will typically use this.
I don't know the frequencies to use. There are some numbers in the
struct sony_tunertype sony_tuners[], but I'm not sure what they mean.
Regards,
Hans
Thanks for your review.
Pete
--
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: Proposal for a V4L2 Media Controller mini-summit
Hi Hans, Hans Verkuil wrote: On Friday 12 February 2010 20:28:43 Guennadi Liakhovetski wrote: On Fri, 12 Feb 2010, Hans Verkuil wrote: Since that time we have added a new API to support HDTV formats, a new event API is almost ready, a lot of work is being done on the media controller API with omap3 as guinea pig and Samsung has done work on the memory handling of V4L2. From April 12th to 14th the CELF Embedded Linux Conference is held in San Francisco, and it is co-located with the Linux Foundation Collaboration Summit (April 14th-16th). Links to these conferences are here: http://www.embeddedlinuxconference.com/elc_2010/index.html http://events.linuxfoundation.org/events/collaboration-summit I will be doing a presentation on the new framework during the ELC. Since this conference is about 6 months after the mini-summit I consider this a good time to organize a new V4L2 Media Controller mini-summit to discuss progress and future work in this area. I think that particular attention should be given to how we are going to do memory handling. The proposals from Samsung have received very little attention and we should discuss those in more detail. I do not know on which dates exactly such a summit can take place. There are three possibilities: April 10-11/12 April 12-14 April 14/15-16 I think that registering for the ELC gives to free access to the Collaboration Summit, but I'm waiting for a confirmation on that. I'm not keen on the center option (12-14 April) since that often means that you don't see a lot of the conference itself. And the ELC is generally quite interesting. There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) I would be interested in principle in taking part in such a mini-summit, but: for me personally Europe is more easily accessible than the US, I could also consider the US, but to increase the chances for me to get there I'd need to know a couple of months in advance, getting a visa takes time, sorting out finances too. Also, 6 months is a good term, but does this mean, that there is going to be one more meeting in another 6 months? I'm also interested, but, for me, being in US or in Europe requires me some months in advance for planning. That is at least my intention. Most likely during/before/after the 2010 Plumbers Conference which is held in Cambridge, MA, USA, November 3-5. It is probably hard for me to get budget for 2 international travels per year. So, except if I can get some sponsor, I probably won't be able to be on the interim meeting. I'm planning to be on LPC, so we can schedule the subsystem mini-summit to happen in Cambridge, MA, US, in November. There will also be an Embedded Linux Conference this fall in Europe. And I think I heard that that will be held in Cambridge, UK (so don't mix those two up :-) ). It is likely that I will be there as well. In general: if people are interested in an interim meeting between European developers, then just let me know. I should be able to organize something like that at the Tandberg offices in Norway, for example. I can also try the same. If there are enough interested people, I may be able to organize a meeting on Red Hat's office in Sao Paulo, Brazil. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]Add support for SMT7020 to cx88
Am 11.02.2010 22:06, schrieb Helmut Auer: From: Helmut Auer hel...@helmutauer.de This patch (originally written by Dirk Herrendoerfer) adds support for the built-in dvb device of a Samsung SMT7020s (x86 based STB) to the cx88 family. (see http://www.linuxtv.org/pipermail/linux-dvb/2007-January/015208.html) Signed-off-by: Helmut Auer hel...@helmutauer.de What do I have to do to get some attention ? -- Helmut Auer, hel...@helmutauer.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] sony-tuner: Subdev conversion from wis-sony-tuner
On Friday 12 February 2010 21:17:45 Pete Eberlein wrote:
On Fri, 2010-02-12 at 12:29 +0100, Hans Verkuil wrote:
On Friday 12 February 2010 01:33:07 Pete Eberlein wrote:
From: Pete Eberlein p...@sensoray.com
This is a subdev conversion of the go7007 wis-sony-tuner i2c driver,
and places it with the other tuner drivers. This obsoletes the
wis-sony-tuner driver in the go7007 staging directory.
Thanks! Here is a quick review...
Thanks, please have a look at my questions below:
+#include media/v4l2-i2c-drv.h
The v4l2-i2c-drv.h is to be used only for drivers that also need to be
compiled
for kernels 2.6.26. If I am not mistaken that is the case for this driver,
right? I remember you mentioning that customers of yours use this on such
old
kernels. Just making sure.
My company, Sensoray, doesn't have any products that use this tuner.
This driver was orignally written by Micronas to support their go7007
chip in the Plextor TV402U models. I don't have the datasheet or know
much about tuners anyway. I used the v4l2-i2c-drv.h since it seems like
a good idea at the time. What should I use instead?
We way i2c devices are handled changed massively in kernel 2.6.26. In order to
stay backwards compatible with older kernels the v4l2-i2c-drv.h header was
introduced. However, this is a bit of a hack and any i2c driver that does not
need it shouldn't use it.
So only if an i2c driver is *never* used by parent drivers that have to support
kernels 2.6.26, then can it drop the v4l2-i2c-drv.h. An example of such an
i2c driver is tvp514x.c.
Eventually support for such old kernels will be dropped and the v4l2-i2c-drv.h
header will disappear altogether, but that's not going to happen anytime soon.
What this means for go7007 is that you have to decide whether you want this
go7007 driver to work only for kernels = 2.6.26, or whether it should also
work for older kernels. My understanding is that Sensoray wants to be able to
compile go7007 for older kernels. In that case the use of v4l2-i2c-drv.h is
correct. Note that this is not about whether any of *Sensoray's* products use
a particular i2c device, but whether the *go7007* driver uses it.
I hope this clarifies this.
+static int sony_tuner_g_frequency(struct v4l2_subdev *sd,
+ struct v4l2_frequency *freq)
+{
+ struct sony_tuner *t = to_state(sd);
+
+ freq-frequency = t-freq;
You need to check both the tuner and type field of struct v4l2_frequency
here.
What should I check v4l2_frequency-tuner against? The v4l2 docs say
that it should be the same as the struct v4l2_tuner index field, which
only the parent device driver knows.
Oops, you are correct. That test belongs in the parent driver. Sorry about that.
+static int sony_tuner_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner
*vt)
+{
+ struct sony_tuner *t = to_state(sd);
+
+ memset(vt, 0, sizeof(*vt));
No need to memset, that's already been done by the v4l core.
Ok.
You should check the vt-index field here.
The parent device driver knows the index and checks it already. However
this could be a problem if there are multiple tuner that use this subdev
driver. Is there some function to tell a tuner subdev what its index
should be?
You are correct again, my mistake.
+ strcpy(vt-name, Television);
Please use strlcpy.
Ok.
+ vt-type = V4L2_TUNER_ANALOG_TV;
+ vt-rangelow = 0UL; /* does anything use these? */
+ vt-rangehigh = 0xUL;
If you know the minimum and maximum frequencies then you should set them
here. Applications that scan for channel will typically use this.
I don't know the frequencies to use. There are some numbers in the
struct sony_tunertype sony_tuners[], but I'm not sure what they mean.
Ah, I thought you had a datasheet for this tuner. In that case I would set
rangelow to 16 and rangehigh to 16 * 999.99.
Regards,
Hans
Regards,
Hans
Thanks for your review.
Pete
--
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
[PATCH -next] media/video/tlg2300: fix build when CONFIG_PM=n
From: Randy Dunlap randy.dun...@oracle.com
When CONFIG_PM is not enabled, tlg2300 has build errors,
so handle that case, mostly via stubs.
drivers/media/video/tlg2300/pd-alsa.c:237: error: 'struct poseidon' has no
member named 'msg'
drivers/media/video/tlg2300/pd-main.c:412: error: implicit declaration of
function 'find_old_poseidon'
drivers/media/video/tlg2300/pd-main.c:418: error: implicit declaration of
function 'set_map_flags'
drivers/media/video/tlg2300/pd-main.c:462: error: implicit declaration of
function 'get_pd'
Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Cc: Huang Shijie shij...@gmail.com
Cc: Kang Yong kangy...@telegent.com
Cc: Zhang Xiaobing xbzh...@telegent.com
---
drivers/media/video/tlg2300/pd-common.h |4
drivers/media/video/tlg2300/pd-main.c | 19 ++-
2 files changed, 18 insertions(+), 5 deletions(-)
--- linux-next-20100212.orig/drivers/media/video/tlg2300/pd-common.h
+++ linux-next-20100212/drivers/media/video/tlg2300/pd-common.h
@@ -254,7 +254,11 @@ void destroy_video_device(struct video_d
extern int debug_mode;
void set_debug_mode(struct video_device *vfd, int debug_mode);
+#ifdef CONFIG_PM
#define in_hibernation(pd) (pd-msg.event == PM_EVENT_FREEZE)
+#else
+#define in_hibernation(pd) (0)
+#endif
#define get_pm_count(p) (atomic_read((p)-interface-pm_usage_cnt))
#define log(a, ...) printk(KERN_DEBUG \t[ %s : %.3d ] a\n, \
--- linux-next-20100212.orig/drivers/media/video/tlg2300/pd-main.c
+++ linux-next-20100212/drivers/media/video/tlg2300/pd-main.c
@@ -255,6 +255,11 @@ out:
return ret;
}
+static inline struct poseidon *get_pd(struct usb_interface *intf)
+{
+ return usb_get_intfdata(intf);
+}
+
#ifdef CONFIG_PM
/* one-to-one map : poseidon{} usb_device{}'s port */
static inline void set_map_flags(struct poseidon *pd, struct usb_device *udev)
@@ -303,11 +308,6 @@ static inline int is_working(struct pose
return get_pm_count(pd) 0;
}
-static inline struct poseidon *get_pd(struct usb_interface *intf)
-{
- return usb_get_intfdata(intf);
-}
-
static int poseidon_suspend(struct usb_interface *intf, pm_message_t msg)
{
struct poseidon *pd = get_pd(intf);
@@ -366,6 +366,15 @@ static void hibernation_resume(struct wo
if (pd-pm_resume)
pd-pm_resume(pd);
}
+#else /* CONFIG_PM is not enabled: */
+static inline struct poseidon *find_old_poseidon(struct usb_device *udev)
+{
+ return NULL;
+}
+
+static inline void set_map_flags(struct poseidon *pd, struct usb_device *udev)
+{
+}
#endif
static bool check_firmware(struct usb_device *udev, int *down_firmware)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] radio_timberdale: depends on I2c
From: Randy Dunlap randy.dun...@oracle.com RADIO_TIMBERDALE selects RADIO_SAA7706H, but RADIO_SAA7706H depends on I2C, so make RADIO_TIMBERDALE depend on I2C also; otherwise there are build errors: drivers/media/radio/saa7706h.c:139: error: implicit declaration of function 'i2c_master_send' drivers/media/radio/saa7706h.c:148: error: implicit declaration of function 'i2c_transfer' drivers/media/radio/saa7706h.c:372: error: implicit declaration of function 'i2c_check_functionality' drivers/media/radio/saa7706h.c:375: error: implicit declaration of function 'i2c_adapter_id' drivers/media/radio/saa7706h.c:438: error: implicit declaration of function 'i2c_add_driver' drivers/media/radio/saa7706h.c:443: error: implicit declaration of function 'i2c_del_driver' Signed-off-by: Randy Dunlap randy.dun...@oracle.com Cc: Mocean Laboratories i...@mocean-labs.com --- drivers/media/radio/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20100212.orig/drivers/media/radio/Kconfig +++ linux-next-20100212/drivers/media/radio/Kconfig @@ -444,6 +444,7 @@ config RADIO_TEF6862 config RADIO_TIMBERDALE tristate Enable the Timberdale radio driver depends on MFD_TIMBERDALE VIDEO_V4L2 + depends on I2C # for RADIO_SAA7706H select RADIO_TEF6862 select RADIO_SAA7706H ---help--- -- 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: [linux-dvb] Twinhan dtv 3030 mantis
Hi, I managed to create the missing .h-file by looking at some other ones. Unfortunately, the module still doesn't work. But there has been progress, now the module loads automagically when i boot the computer. Is there anything I can do to help you debug? If I let it load the module during boot I get the following lines in syslog with grep Mantis Mantis :05:02.0: PCI INT A - GSI 23 (level, low) - IRQ 23 DVB: registering new adapter (Mantis DVB adapter) Mantis: probe of :05:02.0 failed with error -1 I activated debug-info by setting verbose to 9 in mantis_cards. I'm using linux kernel 2.6.31-19-generic which is the latest in ubuntu. The following is what I can read from syslog when I blacklist mantis and then modprobe it. found a VP-3030 PCI DVB-T device on (05:02.0), Mantis :05:02.0: PCI INT A - GSI 23 (level, low) - IRQ 23 Mantis Rev 1 [1822:0024], irq: 23, latency: 64 memory: 0x0, mmio: 0xf86b2000 mantis_stream_control (0): Set stream to HIF mantis_i2c_init (0): Initializing I2C .. mantis_i2c_init (0): Disabling I2C interrupt mantis_i2c_xfer (0): Messages:2 mantis_i2c_write: Address=[0x50] W[ 08 ] mantis_i2c_read: Address=[0x50] R[ 00 08 ca 1a 4d f6 ] MAC Address=[00:08:ca:1a:4d:f6] mantis_dma_init (0): Mantis DMA init mantis_alloc_buffers (0): DMA=0x361c cpu=0xf61c size=65536 mantis_alloc_buffers (0): RISC=0x3649f000 cpu=0xf649f000 size=1000 mantis_calc_lines (0): Mantis RISC block bytes=[4096], line bytes=[2048], line count=[32] mantis_dvb_init (0): dvb_register_adapter DVB: registering new adapter (Mantis DVB adapter) mantis_dvb_init (0): dvb_dmx_init mantis_dvb_init (0): dvb_dmxdev_init gpio_set_bits (0): Set Bit 13 to 0 gpio_set_bits (0): GPIO Value 00 mantis_frontend_power (0): Power ON gpio_set_bits (0): Set Bit 12 to 1 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 12 to 1 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 13 to 1 gpio_set_bits (0): GPIO Value 3000 vp3030_frontend_init (0): Probing for 10353 (DVB-T) mantis_i2c_xfer (0): Messages:2 Byte MODE: Byte 0 RXD=0x1f7f0080 [00] mantis_dvb_init (0): !!! NO Frontends found !!! mantis_dvb_init (0): ERROR! Adapter unregistered mantis_pci_probe (0): ERROR: Mantis DVB initialization failed -1 Mantis: probe of :05:02.0 failed with error -1 Any help is greatly appreciated! Regards, Niklas Claesson -- 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: Proposal for a V4L2 Media Controller mini-summit
On Friday 12 February 2010 15:50:08 Hans Verkuil wrote: I do not know on which dates exactly such a summit can take place. There are three possibilities: April 10-11/12 April 12-14 April 14/15-16 I think that registering for the ELC gives to free access to the Collaboration Summit, but I'm waiting for a confirmation on that. This is confirmed. I quote: There is no fee for the Collaboration Summit, but it is invitation only to control attendance. However, if you register for ELC, you are automatically accepted for attendance at the Collab Summit. So essentially, one registration fee (for ELC) covers both. I also received confirmation that the Linux Foundation can reserve a room for a summit meeting from April 14-16 (so during the Collaboration Summit). So let's target those dates for a summit meeting. It fits nicely with the actual Embedded Linux Conference, I think. Regards, Hans I'm not keen on the center option (12-14 April) since that often means that you don't see a lot of the conference itself. And the ELC is generally quite interesting. There is another alternative and that is that I organize a mini-summit in May in Lysaker (near Oslo, Norway) at the Tandberg offices. But frankly I think that it is more fun to do this during/before/after a conference. If only because there are a lot of linux kernel experts on hand during such a conference that you can ask for help if needed. Please let me know asap if you are interested in attending such a mini-summit and what dates are possible for you: a: April 10-11 (or 12) b: April 12-14 c: April 14 (or 15)-16 d: Somewhere in May (suggestions for dates are welcome) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner
On Friday 12 February 2010 23:36:20 Pete Eberlein wrote: On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote: +#include media/v4l2-i2c-drv.h The v4l2-i2c-drv.h is to be used only for drivers that also need to be compiled for kernels 2.6.26. If I am not mistaken that is the case for this driver, right? I remember you mentioning that customers of yours use this on such old kernels. Just making sure. My company, Sensoray, doesn't have any products that use this tuner. This driver was orignally written by Micronas to support their go7007 chip in the Plextor TV402U models. I don't have the datasheet or know much about tuners anyway. I used the v4l2-i2c-drv.h since it seems like a good idea at the time. What should I use instead? We way i2c devices are handled changed massively in kernel 2.6.26. In order to stay backwards compatible with older kernels the v4l2-i2c-drv.h header was introduced. However, this is a bit of a hack and any i2c driver that does not need it shouldn't use it. So only if an i2c driver is *never* used by parent drivers that have to support kernels 2.6.26, then can it drop the v4l2-i2c-drv.h. An example of such an i2c driver is tvp514x.c. Eventually support for such old kernels will be dropped and the v4l2-i2c-drv.h header will disappear altogether, but that's not going to happen anytime soon. What this means for go7007 is that you have to decide whether you want this go7007 driver to work only for kernels = 2.6.26, or whether it should also work for older kernels. My understanding is that Sensoray wants to be able to compile go7007 for older kernels. In that case the use of v4l2-i2c-drv.h is correct. Note that this is not about whether any of *Sensoray's* products use a particular i2c device, but whether the *go7007* driver uses it. I hope this clarifies this. Yes it does, thank you. We do want to allow our customers to use the go7007 driver with our products on older kernels, so I would like to keep the v4l2-i2c-drv.h for now. I've addressed your other comments in the revised patch: I've two small comments. See below. I also realized that this is really two drivers in one: one driver for the actual tuner device and one for the mpx device which seems similar in functionality to the vp27smpx.c driver. I will look at it again tomorrow, but I might decide that it is better to split it up into two drivers: one for the tuner and one for the mpx. Regards, Hans From: Pete Eberlein p...@sensoray.com This is a subdev conversion of the go7007 wis-sony-tuner i2c driver, and places it with the other tuner drivers. This obsoletes the wis-sony-tuner driver in the go7007 staging directory. Priority: normal Signed-off-by: Pete Eberlein p...@sensoray.com diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/Documentation/video4linux/CARDLIST.tuner --- a/linux/Documentation/video4linux/CARDLIST.tuner Wed Feb 10 11:25:59 2010 -0800 +++ b/linux/Documentation/video4linux/CARDLIST.tuner Fri Feb 12 14:27:39 2010 -0800 @@ -81,3 +81,6 @@ tuner=81 - Partsnic (Daewoo) PTI-5NF05 tuner=82 - Philips CU1216L tuner=83 - NXP TDA18271 +tuner=84 - Sony PAL+SECAM (BTF-PG472Z) +tuner=85 - Sony NTSC_JP (BTF-PK467Z) +tuner=86 - Sony NTSC (BTF-PB463Z) diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/drivers/media/common/tuners/Kconfig --- a/linux/drivers/media/common/tuners/Kconfig Wed Feb 10 11:25:59 2010 -0800 +++ b/linux/drivers/media/common/tuners/Kconfig Fri Feb 12 14:27:39 2010 -0800 @@ -179,4 +179,12 @@ help A driver for the silicon tuner MAX2165 from Maxim. +config MEDIA_TUNER_SONY + tristate Sony TV tuner + depends on VIDEO_MEDIA I2C + default m if MEDIA_TUNER_CUSTOMISE + help + A driver for the Sony tuners BTF-PG472Z, BTF-PK467Z, BTF-PB463Z. + + endif # MEDIA_TUNER_CUSTOMISE diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/drivers/media/common/tuners/Makefile --- a/linux/drivers/media/common/tuners/Makefile Wed Feb 10 11:25:59 2010 -0800 +++ b/linux/drivers/media/common/tuners/Makefile Fri Feb 12 14:27:39 2010 -0800 @@ -24,6 +24,7 @@ obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o +obj-$(CONFIG_MEDIA_TUNER_SONY) += sony-tuner.o EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core EXTRA_CFLAGS += -Idrivers/media/dvb/frontends diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/drivers/media/common/tuners/sony-tuner.c --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux/drivers/media/common/tuners/sony-tuner.c Fri Feb 12 14:27:39 2010 -0800 @@ -0,0 +1,677 @@ +/* + * Copyright (C) 2005-2006 Micronas USA Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License (Version
[PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner
On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote: +#include media/v4l2-i2c-drv.h The v4l2-i2c-drv.h is to be used only for drivers that also need to be compiled for kernels 2.6.26. If I am not mistaken that is the case for this driver, right? I remember you mentioning that customers of yours use this on such old kernels. Just making sure. My company, Sensoray, doesn't have any products that use this tuner. This driver was orignally written by Micronas to support their go7007 chip in the Plextor TV402U models. I don't have the datasheet or know much about tuners anyway. I used the v4l2-i2c-drv.h since it seems like a good idea at the time. What should I use instead? We way i2c devices are handled changed massively in kernel 2.6.26. In order to stay backwards compatible with older kernels the v4l2-i2c-drv.h header was introduced. However, this is a bit of a hack and any i2c driver that does not need it shouldn't use it. So only if an i2c driver is *never* used by parent drivers that have to support kernels 2.6.26, then can it drop the v4l2-i2c-drv.h. An example of such an i2c driver is tvp514x.c. Eventually support for such old kernels will be dropped and the v4l2-i2c-drv.h header will disappear altogether, but that's not going to happen anytime soon. What this means for go7007 is that you have to decide whether you want this go7007 driver to work only for kernels = 2.6.26, or whether it should also work for older kernels. My understanding is that Sensoray wants to be able to compile go7007 for older kernels. In that case the use of v4l2-i2c-drv.h is correct. Note that this is not about whether any of *Sensoray's* products use a particular i2c device, but whether the *go7007* driver uses it. I hope this clarifies this. Yes it does, thank you. We do want to allow our customers to use the go7007 driver with our products on older kernels, so I would like to keep the v4l2-i2c-drv.h for now. I've addressed your other comments in the revised patch: From: Pete Eberlein p...@sensoray.com This is a subdev conversion of the go7007 wis-sony-tuner i2c driver, and places it with the other tuner drivers. This obsoletes the wis-sony-tuner driver in the go7007 staging directory. Priority: normal Signed-off-by: Pete Eberlein p...@sensoray.com diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/Documentation/video4linux/CARDLIST.tuner --- a/linux/Documentation/video4linux/CARDLIST.tunerWed Feb 10 11:25:59 2010 -0800 +++ b/linux/Documentation/video4linux/CARDLIST.tunerFri Feb 12 14:27:39 2010 -0800 @@ -81,3 +81,6 @@ tuner=81 - Partsnic (Daewoo) PTI-5NF05 tuner=82 - Philips CU1216L tuner=83 - NXP TDA18271 +tuner=84 - Sony PAL+SECAM (BTF-PG472Z) +tuner=85 - Sony NTSC_JP (BTF-PK467Z) +tuner=86 - Sony NTSC (BTF-PB463Z) diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/drivers/media/common/tuners/Kconfig --- a/linux/drivers/media/common/tuners/Kconfig Wed Feb 10 11:25:59 2010 -0800 +++ b/linux/drivers/media/common/tuners/Kconfig Fri Feb 12 14:27:39 2010 -0800 @@ -179,4 +179,12 @@ help A driver for the silicon tuner MAX2165 from Maxim. +config MEDIA_TUNER_SONY + tristate Sony TV tuner + depends on VIDEO_MEDIA I2C + default m if MEDIA_TUNER_CUSTOMISE + help + A driver for the Sony tuners BTF-PG472Z, BTF-PK467Z, BTF-PB463Z. + + endif # MEDIA_TUNER_CUSTOMISE diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/drivers/media/common/tuners/Makefile --- a/linux/drivers/media/common/tuners/MakefileWed Feb 10 11:25:59 2010 -0800 +++ b/linux/drivers/media/common/tuners/MakefileFri Feb 12 14:27:39 2010 -0800 @@ -24,6 +24,7 @@ obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o +obj-$(CONFIG_MEDIA_TUNER_SONY) += sony-tuner.o EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core EXTRA_CFLAGS += -Idrivers/media/dvb/frontends diff -r 27ee8e515b18 -r 1cf1bf4e616f linux/drivers/media/common/tuners/sony-tuner.c --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux/drivers/media/common/tuners/sony-tuner.cFri Feb 12 14:27:39 2010 -0800 @@ -0,0 +1,677 @@ +/* + * Copyright (C) 2005-2006 Micronas USA Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License (Version 2) as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software Foundation, + * Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. + */ + +#include linux/module.h +#include
Re: [PATCH 2/5 v2] sony-tuner: Subdev conversion from wis-sony-tuner
On Sat, 2010-02-13 at 00:17 +0100, Hans Verkuil wrote: On Friday 12 February 2010 23:36:20 Pete Eberlein wrote: On Fri, 2010-02-12 at 22:03 +0100, Hans Verkuil wrote: My company, Sensoray, doesn't have any products that use this tuner. This driver was orignally written by Micronas to support their go7007 chip in the Plextor TV402U models. I don't have the datasheet or know much about tuners anyway. So only if an i2c driver is *never* used by parent drivers that have to support kernels 2.6.26, then can it drop the v4l2-i2c-drv.h. An example of such an i2c driver is tvp514x.c. I've addressed your other comments in the revised patch: I've two small comments. See below. I also realized that this is really two drivers in one: one driver for the actual tuner device and one for the mpx device which seems similar in functionality to the vp27smpx.c driver. I will look at it again tomorrow, but I might decide that it is better to split it up into two drivers: one for the tuner and one for the mpx. Pete and Hans, The Sony VAIO GigaPocket cards (ivtv driver) that I have seen on the 'Net have these part numbers: Sony Part # 859863200 Tuner Model # BTF-PJ401Z Sony Part # 859860400 Tuner Model # BTF-PJ301Z Any idea how applicable this driver is to these tuners? I was about to add a tuner-cards.c entry for tuner-simple.c to handle using Eric Anderson's experimental results. Regards, Andy Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
On Thu, 2010-02-11 at 20:11 -0800, Greg KH wrote:
On Wed, Feb 10, 2010 at 10:34:56AM -0500, Andy Walls wrote:
On Tue, 2010-02-09 at 22:12 -0500, Devin Heitmueller wrote:
On Tue, Feb 9, 2010 at 10:05 PM, Richard Lemieux rlem...@cooptel.qc.ca
wrote:
Andy,
This is a great answer! Thanks very much. When I get into this
situation
again
I will know what to look for.
A possible reason why I got into this problem in the first place is
that I
tried
many combinations of parameters with mplayer and azap in order to learn
how
to use the USB tuner in both the ATSC and the NTSC mode. I will look
back
in the terminal history to see if I can find anything.
I think the key to figuring out the bug at this point is you finding a
sequence where you can reliably reproduce the oops. If we have that,
then I can start giving you some code to try which we can see if it
addresses the problem.
For example, I would start by giving you a fix which results in us not
calling the firmware release if the request_firmware() call failed,
but it wouldn't be much help if you could not definitively tell me if
the problem is fixed.
For the oops analysis here:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15954
I will also note that the file scope fw_lock mutex is rather
inconsistently used in
linux/drivers/base/fw_class.c:firmware_loading_store(). (I guess for
not wanting to consume the timeout interval with sleeping?)
The mutex protects case 1:, but all other cases appear to be only
protected by atomic status bit checks that can fall through to
fw_load_abort() which complete()'s the fw_priv-completion.
Also not that in the _request_firmware() this sequence is the only place
a once good fw_priv-fw pointer is set to NULL:
mutex_lock(fw_lock);
if (!fw_priv-fw-size || test_bit(FW_STATUS_ABORT,
fw_priv-status)) {
retval = -ENOENT;
release_firmware(fw_priv-fw);
*firmware_p = NULL;
}
fw_priv-fw = NULL; --- The only place it is set
to NULL
mutex_unlock(fw_lock);
So if the timeout timer fires at nearly the same time as udev coming in
and say I'm done loading without holding the mutex, one can run into
the Ooops. Not only that, I think the above code can leak memory under
some circumstances when the if clause is not satisfied.
I think this really is a firmware_class.c issue. I think the just
right firmware loading timeouts and the particular computer system
responsiveness, make this Ooops possible. However, I'm amazed that a
single person has tripped it more than once.
Revising the locking in linux/drivers/base/firmware_class.c should fix
the problem.
I don't believe this comment in the code now:
/* fw_lock could be moved to 'struct firmware_priv' but since it is just
* guarding for corner cases a global lock should be OK */
static DEFINE_MUTEX(fw_lock);
struct firmware_priv {
char *fw_id;
...
And since f_priv is dynamically created and destroyed by
request_firmware() I see no harm in
1. moving the mutex into struct firmware_priv
2. just always just grabbing an almost never contended mutex
3. getting rid of the file scope fw_lock.
except grabbing a mutex() while the timeout timer is running during
loading, means one *could* sleep for a while consuming the timeout
interval.
That sounds reasonable to me, care to make up a patch for this?
Yes. But it will take me a while. I don't have a git tree, because I
don't have high bandwidth internet yet. (The cable company's been
delayed in laying cable to my home due to repeated snowstorms.)
I just didn't want the problem to fall through the cracks. I'll submit
something to bugzilla for now. If a user complains of this rare Ooops
when loading firmware, the current workaround is to lengthen the timeout
via sysfs.
Regards,
Andy
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch] Kworld 315U remote support part2
Here is the rest of the patch for the Kworld remote support. Hopefully I got all the formatting correct this time. Signed-off-by: Franklin Meng fmeng2...@yahoo.com diff -r 14021dfc00f3 linux/drivers/media/video/em28xx/em28xx-cards.c --- a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu Feb 11 23:11:30 2010 -0200 +++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Fri Feb 12 21:31:41 2010 -0800 @@ -1329,6 +1329,7 @@ .decoder= EM28XX_SAA711X, .has_dvb= 1, .dvb_gpio = em2882_kworld_315u_digital, + .ir_codes = ir_codes_kworld_315u_table, .xclk = EM28XX_XCLK_FREQUENCY_12MHZ, .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE, /* Analog mode - still not ready */ diff -r 14021dfc00f3 linux/include/media/ir-common.h --- a/linux/include/media/ir-common.h Thu Feb 11 23:11:30 2010 -0200 +++ b/linux/include/media/ir-common.h Fri Feb 12 21:31:41 2010 -0800 @@ -163,4 +163,5 @@ extern struct ir_scancode_table ir_codes_gadmei_rm008z_table; extern struct ir_scancode_table ir_codes_nec_terratec_cinergy_xs_table; extern struct ir_scancode_table ir_codes_winfast_usbii_deluxe_table; +extern struct ir_scancode_table ir_codes_kworld_315u_table; #endif -- 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
