Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2246,11 +2246,13 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device *pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2266,9 +2268,9 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_info.vid_dev = vid_dev;
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
- vout-vid_info.id = k + 1;
+ vout-vid_info.id = k + vout_count;
vid_dev-num_videos++;
/* Setup the default configuration for the video devices
@@ -2289,7 +2291,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count) 0) {
printk(KERN_ERR VOUT_NAME : could not register \
Video for Linux device\n);
vfd-minor = -1;
2009/4/22 Shah, Hardik hardik.s...@ti.com:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, April 22, 2009 1:53 PM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh
R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565
4. Supports Alpha blending.
5. Supports Color keying both source and destination.
6. Supports rotation with RGB565 and RGB32 pixels formats.
7. Supports cropping.
8. Supports Background color setting.
9. Works on latest DSS2 library from Tomi
http://www.bat.org/~tomba/git/linux-omap-dss.git/
10. 1/4x scaling added. Detail testing left
TODOS
1. Ioctls needs to be added for color space conversion matrix
coefficient programming.
2. To be tested on DVI resolutions.
Comments fixed from community.
1. V4L2 Driver for OMAP3/3 DSS.
2. Conversion of the custom ioctls to standard V4L2 ioctls like alpha
blending,
color keying, rotation and back ground color setting
3. Re-organised the code as per community comments.
4. Added proper copyright year.
5. Added module name in printk
6. Kconfig option copy/paste error
7. Module param desc addded.
8. Query control implemented using standard query_fill
9. Re-arranged if-else constructs.
10. Changed to use mutex instead of semaphore.
11. Removed dual usage of rotation angles.
12. Implemented function to convert the V4L2 angle to DSS angle.
13. Y-position was set half by video driver for TV output
Now its done by DSS so removed that.
14. Minor cleanup
15. Added support to pass the page offset to application.
14. Minor cleanup
15. Added support to pass the page
Re: PID discontinuity problems on TT C-2300
Anyone? Zitat von Jan Schneider j...@horde.org: Hi, I tried to get help from the MythTV community to no avail. Maybe it's a hardware/driver/dvb subsystem problem, I have no idea. I see two symptoms, some recordings are generated empty, i.e. Myth thinks it has recorded something, but there is no video file created. Sometimes, recordings just stop in the middle. This is the only case where I get a useful log entry *at all*. But it doesn't say anything more than: 2009-04-22 23:03:07.318 DVBRec(1:0): PID 0x215 discontinuity detected with different PIDs. This message is continuously being logged until the end of the scheduled recordings, sometime interrupted by a single: 2009-04-22 23:03:11.220 AddTSPacket: Out of sync!!! Need to wait for next payloa dStart PID: 0x10, continuity counter: 15 (expected 12). Please help me someone, no component of this system is logging *anything* useful, this used to work one day, and I'm running out of ideas and motivation into frustration. Beside several things I also tried running a recent v4l-dvb hg checkout. No change. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- 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 Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers
From d8f37b4340ea4cfd28d6e620f1b3224d946b9fab Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Thu, 30 Apr 2009 12:31:21 +0800
Subject: [PATCH] sensor pseduo driver in camera imaging on Intel moorestown
platform.
The moorestown platform with dual cameras will have one the same side as
the display and the second on the oppsoite side of the display. The pseduo
driver provides the uniform interface for isp kernel driver.
Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
drivers/media/video/Makefile |1 +
drivers/media/video/mrstci/Kconfig |1 +
drivers/media/video/mrstci/include/ci_sensor_ioc.h | 57 +
drivers/media/video/mrstci/include/sensordev.h | 119 +++
drivers/media/video/mrstci/mrstsensor/Kconfig |9 +
drivers/media/video/mrstci/mrstsensor/Makefile |3 +
drivers/media/video/mrstci/mrstsensor/mrstsensor.c | 1094
.../media/video/mrstci/mrstsensor/sensordev_priv.h | 37 +
8 files changed, 1321 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mrstci/include/ci_sensor_ioc.h
create mode 100644 drivers/media/video/mrstci/include/sensordev.h
create mode 100644 drivers/media/video/mrstci/mrstsensor/Kconfig
create mode 100644 drivers/media/video/mrstci/mrstsensor/Makefile
create mode 100644 drivers/media/video/mrstci/mrstsensor/mrstsensor.c
create mode 100644 drivers/media/video/mrstci/mrstsensor/sensordev_priv.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f06f1cb..34a3461 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_VIDEO_AU0828) += au0828/
obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/
obj-$(CONFIG_VIDEO_MRST_ISP) += mrstci/mrstisp/
+obj-$(CONFIG_VIDEO_MRST_SENSOR) += mrstci/mrstsensor/
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/video/mrstci/Kconfig
b/drivers/media/video/mrstci/Kconfig
index 8f0a620..bf01447 100644
--- a/drivers/media/video/mrstci/Kconfig
+++ b/drivers/media/video/mrstci/Kconfig
@@ -10,6 +10,7 @@ if VIDEO_MRSTCI VIDEO_V4L2
source drivers/media/video/mrstci/mrstisp/Kconfig
+source drivers/media/video/mrstci/mrstsensor/Kconfig
endif # VIDEO_MRSTCI
diff --git a/drivers/media/video/mrstci/include/ci_sensor_ioc.h
b/drivers/media/video/mrstci/include/ci_sensor_ioc.h
new file mode 100644
index 000..80d3b0f
--- /dev/null
+++ b/drivers/media/video/mrstci/include/ci_sensor_ioc.h
@@ -0,0 +1,57 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+/* Sensor IOCTL */
+#ifndef _SENSOR_IOC_H
+#define_SENSOR_IOC_H
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#define SENSOR_MAGIC 0x83
+
+#define SENIOC_QUERYCAP _IOR(SENSOR_MAGIC, 0, struct ci_sensor_caps)
+#define SENIOC_G_CONFIG _IOR(SENSOR_MAGIC, 1, struct ci_sensor_config)
+#define SENIOC_S_CONFIG _IOW(SENSOR_MAGIC, 2, struct ci_sensor_config)
+#define SENIOC_STREAM_ON _IO(SENSOR_MAGIC, 3)
+#define SENIOC_STREAM_OFF _IO(SENSOR_MAGIC, 4)
+#define SENIOC_G_REG _IOWR(SENSOR_MAGIC, 5, struct ci_sensor_reg)
+#define SENIOC_S_REG _IOW(SENSOR_MAGIC, 6, struct ci_sensor_reg)
+/* Get current focus position */
+#define SENIOC_MDI_G_FOCUS _IOR(SENSOR_MAGIC, 9, unsigned int)
+/* Set focus to the given position */
+#define SENIOC_MDI_S_FOCUS _IOW(SENSOR_MAGIC, 10, unsigned int)
+/* Trigger a forced calibration of focus hardware */
+#define SENIOC_MDI_CALIBRATE _IO(SENSOR_MAGIC, 11)
+#define SENIOC_MDI_MAX_STEP _IOR(SENSOR_MAGIC, 12, unsigned int)
+/* Get the max step hardware can support */
+#define SENIOC_ENUMPARM _IOWR(SENSOR_MAGIC, 13, struct ci_sensor_parm)
+#define SENIOC_G_PARM _IOWR(SENSOR_MAGIC, 14, struct ci_sensor_parm)
+#define SENIOC_S_PARM _IOW(SENSOR_MAGIC, 15, struct ci_sensor_parm)
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/drivers/media/video/mrstci/include/sensordev.h
b/drivers/media/video/mrstci/include/sensordev.h
new file mode 100644
index 000..f4cf603
--- /dev/null
+++ b/drivers/media/video/mrstci/include/sensordev.h
@@ -0,0 +1,119 @@
+/*
+ * Support for Moorestown Langwell
[PATCH 4/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers
From 115b53d1f5016363667cad629b327491d6a026da Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Thu, 30 Apr 2009 13:24:15 +0800
Subject: [PATCH] 5MP camera sensor driver (ov5630, RAW sensor) on Interl
Moorestown
platform.
Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
drivers/media/video/Makefile |1 +
drivers/media/video/mrstci/Kconfig |2 +
drivers/media/video/mrstci/mrstov5630/Kconfig |9 +
drivers/media/video/mrstci/mrstov5630/Makefile |4 +
drivers/media/video/mrstci/mrstov5630/ov5630.c | 783
drivers/media/video/mrstci/mrstov5630/ov5630.h | 673 +
.../media/video/mrstci/mrstov5630/ov5630_motor.c | 212 ++
.../media/video/mrstci/mrstov5630/ov5630_motor.h | 79 ++
8 files changed, 1763 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mrstci/mrstov5630/Kconfig
create mode 100644 drivers/media/video/mrstci/mrstov5630/Makefile
create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630.c
create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630.h
create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630_motor.c
create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630_motor.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index eed3965..348eda8 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -154,6 +154,7 @@ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/
obj-$(CONFIG_VIDEO_MRST_ISP) += mrstci/mrstisp/
obj-$(CONFIG_VIDEO_MRST_SENSOR) += mrstci/mrstsensor/
obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstci/mrstov2650/
+obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstci/mrstov5630/
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/video/mrstci/Kconfig
b/drivers/media/video/mrstci/Kconfig
index 1ad479b..803813b 100644
--- a/drivers/media/video/mrstci/Kconfig
+++ b/drivers/media/video/mrstci/Kconfig
@@ -13,5 +13,7 @@ source drivers/media/video/mrstci/mrstisp/Kconfig
source drivers/media/video/mrstci/mrstsensor/Kconfig
source drivers/media/video/mrstci/mrstov2650/Kconfig
+
+source drivers/media/video/mrstci/mrstov5630/Kconfig
endif # VIDEO_MRSTCI
diff --git a/drivers/media/video/mrstci/mrstov5630/Kconfig
b/drivers/media/video/mrstci/mrstov5630/Kconfig
new file mode 100644
index 000..7a5a50b
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_OV5630
+ tristate Moorestown OV5630 RAW Sensor
+ depends on I2C VIDEO_MRST_ISP VIDEO_MRST_SENSOR
+
+ ---help---
+ Say Y here if your platform support OV5630 RAW Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov2650.ko.
diff --git a/drivers/media/video/mrstci/mrstov5630/Makefile
b/drivers/media/video/mrstci/mrstov5630/Makefile
new file mode 100644
index 000..9b953fd
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630/Makefile
@@ -0,0 +1,4 @@
+mrstov5630-objs= ov5630_motor.o ov5630.o
+obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstov5630.o
+
+EXTRA_CFLAGS += -I$(src)/../include
diff --git a/drivers/media/video/mrstci/mrstov5630/ov5630.c
b/drivers/media/video/mrstci/mrstov5630/ov5630.c
new file mode 100644
index 000..30d6a51
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630/ov5630.c
@@ -0,0 +1,783 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+
+#include sensordev.h
+#include ov5630.h
+#include ov5630_motor.h
+
+static int ov5630_set_res(struct i2c_client *c, const int w, const int h);
+static struct ov5630_format_struct {
+ __u8 *desc;
+ __u32 pixelformat;
+ struct regval_list
[PATCH 5/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers
From eb2cf7ea5a94412e0c0e2655d0d091b15a7d7ef0 Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Thu, 30 Apr 2009 13:27:34 +0800
Subject: [PATCH] 1.3MP camera sensor driver (ov9665) on Intel moorestown
platform.
Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
drivers/media/video/Makefile |1 +
drivers/media/video/mrstci/Kconfig |3 +
drivers/media/video/mrstci/mrstov9665/Kconfig |9 +
drivers/media/video/mrstci/mrstov9665/Makefile |3 +
drivers/media/video/mrstci/mrstov9665/mrstov9665.c | 694
drivers/media/video/mrstci/mrstov9665/ov9665.h | 244 +++
6 files changed, 954 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mrstci/mrstov9665/Kconfig
create mode 100644 drivers/media/video/mrstci/mrstov9665/Makefile
create mode 100644 drivers/media/video/mrstci/mrstov9665/mrstov9665.c
create mode 100644 drivers/media/video/mrstci/mrstov9665/ov9665.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 348eda8..060f95d 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -155,6 +155,7 @@ obj-$(CONFIG_VIDEO_MRST_ISP) += mrstci/mrstisp/
obj-$(CONFIG_VIDEO_MRST_SENSOR) += mrstci/mrstsensor/
obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstci/mrstov2650/
obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstci/mrstov5630/
+obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstci/mrstov9665/
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/video/mrstci/Kconfig
b/drivers/media/video/mrstci/Kconfig
index 803813b..da81c3e 100644
--- a/drivers/media/video/mrstci/Kconfig
+++ b/drivers/media/video/mrstci/Kconfig
@@ -15,5 +15,8 @@ source drivers/media/video/mrstci/mrstsensor/Kconfig
source drivers/media/video/mrstci/mrstov2650/Kconfig
source drivers/media/video/mrstci/mrstov5630/Kconfig
+
+source drivers/media/video/mrstci/mrstov9665/Kconfig
+
endif # VIDEO_MRSTCI
diff --git a/drivers/media/video/mrstci/mrstov9665/Kconfig
b/drivers/media/video/mrstci/mrstov9665/Kconfig
new file mode 100644
index 000..56aaffb
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov9665/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_OV9665
+ tristate Moorestown OV9665 SoC Sensor
+ depends on I2C VIDEO_MRST_ISP VIDEO_MRST_SENSOR
+
+ ---help---
+ Say Y here if your platform support OV9665 SoC Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov9665.ko.
diff --git a/drivers/media/video/mrstci/mrstov9665/Makefile
b/drivers/media/video/mrstci/mrstov9665/Makefile
new file mode 100644
index 000..871b6bf
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov9665/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_MRST_OV9665) += mrstov9665.o
+
+EXTRA_CFLAGS += -I$(src)/../include
diff --git a/drivers/media/video/mrstci/mrstov9665/mrstov9665.c
b/drivers/media/video/mrstci/mrstov9665/mrstov9665.c
new file mode 100644
index 000..badc449
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov9665/mrstov9665.c
@@ -0,0 +1,694 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+
+#include sensordev.h
+#include ov9665.h
+static struct ov9665_format_struct {
+ __u8 *desc;
+ __u32 pixelformat;
+ struct regval_list *regs;
+} ov9665_formats[] = {
+ {
+ .desc = YUYV 4:2:2,
+ .pixelformat= SENSOR_MODE_BT601,
+ .regs = NULL,
+ },
+};
+#define N_OV9665_FMTS ARRAY_SIZE(ov9665_formats)
+
+static struct ov9665_res_struct {
+ __u8 *desc;
+ int res;
+ int width;
+ int height;
+ unsigned vflag;
+#define VARIO_EN 1
+#define
[PATCH 3/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers
From 852df51762e8de89e3a78a86d8863700999eaeaa Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Thu, 30 Apr 2009 13:18:21 +0800
Subject: [PATCH] 2MP camera sensor driver (ov2650) on Intel Moorestown platform.
Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
drivers/media/video/Makefile |1 +
drivers/media/video/mrstci/Kconfig |1 +
drivers/media/video/mrstci/mrstov2650/Kconfig |9 +
drivers/media/video/mrstci/mrstov2650/Makefile |3 +
drivers/media/video/mrstci/mrstov2650/mrstov2650.c | 877
drivers/media/video/mrstci/mrstov2650/ov2650.h | 716
6 files changed, 1607 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mrstci/mrstov2650/Kconfig
create mode 100644 drivers/media/video/mrstci/mrstov2650/Makefile
create mode 100644 drivers/media/video/mrstci/mrstov2650/mrstov2650.c
create mode 100644 drivers/media/video/mrstci/mrstov2650/ov2650.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 34a3461..eed3965 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -153,6 +153,7 @@ obj-$(CONFIG_VIDEO_AU0828) += au0828/
obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/
obj-$(CONFIG_VIDEO_MRST_ISP) += mrstci/mrstisp/
obj-$(CONFIG_VIDEO_MRST_SENSOR) += mrstci/mrstsensor/
+obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstci/mrstov2650/
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/video/mrstci/Kconfig
b/drivers/media/video/mrstci/Kconfig
index bf01447..1ad479b 100644
--- a/drivers/media/video/mrstci/Kconfig
+++ b/drivers/media/video/mrstci/Kconfig
@@ -12,5 +12,6 @@ source drivers/media/video/mrstci/mrstisp/Kconfig
source drivers/media/video/mrstci/mrstsensor/Kconfig
+source drivers/media/video/mrstci/mrstov2650/Kconfig
endif # VIDEO_MRSTCI
diff --git a/drivers/media/video/mrstci/mrstov2650/Kconfig
b/drivers/media/video/mrstci/mrstov2650/Kconfig
new file mode 100644
index 000..cdd985b
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov2650/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_OV2650
+ tristate Moorestown OV2650 SoC Sensor
+ depends on I2C VIDEO_MRST_ISP VIDEO_MRST_SENSOR
+
+ ---help---
+ Say Y here if your platform support OV2650 SoC Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov2650.ko.
diff --git a/drivers/media/video/mrstci/mrstov2650/Makefile
b/drivers/media/video/mrstci/mrstov2650/Makefile
new file mode 100644
index 000..fb16d57
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov2650/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov2650.o
+
+EXTRA_CFLAGS += -I$(src)/../include
\ No newline at end of file
diff --git a/drivers/media/video/mrstci/mrstov2650/mrstov2650.c
b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c
new file mode 100644
index 000..af036cc
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c
@@ -0,0 +1,877 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+
+#include sensordev.h
+#include ov2650.h
+
+static struct ov2650_format_struct {
+ __u8 *desc;
+ __u32 pixelformat;
+ struct regval_list *regs;
+} ov2650_formats[] = {
+ {
+ .desc = YUYV 4:2:2,
+ .pixelformat= SENSOR_MODE_BT601,
+ .regs = NULL,
+ },
+};
+#define N_OV2650_FMTS ARRAY_SIZE(ov2650_formats)
+
+static struct ov2650_res_struct {
+ __u8 *desc;
+ int res;
+ int width;
+ int height;
+ unsigned vflag;
+#define VARIO_EN 1
+#define VARIO_DIS 0
+ struct regval_list *regs;
+}
Re:TechnoTrend C-1501 - Locking issues on 388Mhz
I have TT DVB-C 1501 and I test it with the patch and it work now for like a charm. I have problem by 386MHz frequency as it doesn't detect any channels on it. now it work very good and stable. -Amir PS: I have send this email before (yesterday) but I didn't receive see it in the mailing list. -- 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/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shah, Hardik
Sent: Thursday, April 30, 2009 11:51 AM
To: InKi Dae
Cc: tomi.valkei...@nokia.com; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2246,11 +2246,13 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device
*pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2266,9 +2268,9 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_info.vid_dev = vid_dev;
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
- vout-vid_info.id = k + 1;
+ vout-vid_info.id = k + vout_count;
vid_dev-num_videos++;
/* Setup the default configuration for the video devices
@@ -2289,7 +2291,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count)
0) {
printk(KERN_ERR VOUT_NAME : could not register \
Video for Linux device\n);
vfd-minor = -1;
2009/4/22 Shah, Hardik hardik.s...@ti.com:
[Shah, Hardik] Yes this is correct,
I will apply this patch. I already found it and fixed it in different way but
any way I will apply your patch.
[Shah, Hardik] Further on this inki. Solving this bug will give rise to couple
of more bugs related to global_alpha and pixel formats. That also is fixed. You
can refer
http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=summary
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, April 22, 2009 1:53 PM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav,
Brijesh
R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24,
RGB565
4. Supports Alpha blending.
5. Supports Color keying both source and destination.
6. Supports rotation with RGB565 and RGB32 pixels formats.
7. Supports
Re: Nova-T 500 does not survive reboot
On Thu, 2009-04-30 at 10:16 +, Eduard Huguet wrote: I can remenber that other guy posted about this issue some time ago, but I can't find the link. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/2423/focus=2591 I guess. nico getting used to gmame :o) -- 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
TVP514x: Migration to sub-device framework
From: Vaibhav Hiremath hvaib...@ti.com
This is first version of sub-device framework based
TVP514x decoder driver. Earlier version of TVP514x driver is based
on V4L2-int framework.
Initial version reviewed by Hans Verkuil.
NOTE: Please note that this patch has not been tested on any board,
only compilation/build tested.
I will consolidate all the review comments and will incorporate
in the next version, which should also be include validation
of these changes on any of the supported boards.
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration master driver to validate this driver.
- validate on Davinci and OMAP boards.
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/tvp514x.c | 787 ++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 310 insertions(+), 491 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4262e60..d42cef2 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,10 @@
#include linux/i2c.h
#include linux/delay.h
#include linux/videodev2.h
-#include media/v4l2-int-device.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
#include media/tvp514x.h
#include tvp514x_regs.h
@@ -49,10 +52,10 @@ static int debug;
module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, Debug level (0-1));
-#define dump_reg(client, reg, val) \
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n, reg, val); \
+ val = tvp514x_read_reg(sd, reg);\
+ v4l2_info(sd, Reg(0x%.2X): 0x%.2X\n, reg, val); \
} while (0)
/**
@@ -65,14 +68,6 @@ enum tvp514x_std {
};
/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
- STATE_NOT_DETECTED,
- STATE_DETECTED
-};
-
-/**
* struct tvp514x_std_info - Structure to store standard informations
* @width: Line width in pixels
* @height:Number of active lines
@@ -89,33 +84,27 @@ struct tvp514x_std_info {
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
/**
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
* @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @state: TVP5146/47 decoder state - enabled or disabled.
* @pix: Current pixel format
* @num_fmts: Number of formats
* @fmt_list: Format list
* @current_std: Current standard
* @num_stds: Number of standards
* @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device v4l2_int_device;
- struct v4l2_int_slave tvp514x_slave;
+ struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
- struct i2c_client *client;
-
- struct i2c_device_id *id;
int ver;
- enum tvp514x_state state;
+ int state;
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +113,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
- struct v4l2_routing route;
+ /*
+* Input and Output Routing parameters
+*/
+ unsigned int input;
+ unsigned int output;
};
/* TVP514x default register values */
@@ -240,35 +232,22 @@ static struct tvp514x_std_info tvp514x_std_list[] = {
},
/* Standard: need to add for additional standard */
};
-/*
- * Control structure for Auto Gain
- * This is temporary data, will get replaced once
- * v4l2_ctrl_query_fill supports it.
- */
-static const struct v4l2_queryctrl tvp514x_autogain_ctrl = {
- .id = V4L2_CID_AUTOGAIN,
- .name = Gain, Automatic,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .minimum = 0,
- .maximum = 1,
- .step = 1,
- .default_value = 1,
-};
/*
* Read a value from a register in an TVP5146/47 decoder device.
* Returns value read if successful, or non-zero (-1) otherwise.
*/
-static int
Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Thank you Shah, Hardik.
I have patched your driver through that git.
but your patch recognizes video2 layer as video1 device node in case
that DSS2 has fb0 and fb1.
you said my patch will give rise to couple of more bugs related to
global_alpha and pixel formats
maybe that would be because of vout-vid_info.id = k + vout_count;
so I have applied your patch to my way.
this patch is more flexible and recognizes video2 layer correctly as
video2 device node.
--
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2204,7 +2204,7 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device *pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -2212,6 +2212,8 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
struct omap2video_device *vid_dev = container_of(v4l2_dev, struct
omap2video_device, v4l2_dev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2225,12 +2227,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_dev = vid_dev;
- /* Select video2 if only 1 overlay is controlled by V4L2 */
- if (pdev-num_resources == 1)
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 2];
- else
- /* Else select video1 and video2 one by one. */
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
vout-vid_info.id = k + 1;
vid_dev-num_videos++;
@@ -2253,7 +2250,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count) 0) {
printk(KERN_ERR VOUT_NAME : could not register
Video for Linux device\n);
vfd-minor = -1
-
2009/4/30 Shah, Hardik hardik.s...@ti.com:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shah, Hardik
Sent: Thursday, April 30, 2009 11:51 AM
To: InKi Dae
Cc: tomi.valkei...@nokia.com; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer
count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or
video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@
[PATCH] radio_si470x: Drop unused label
Fix this warning: /home/nicola/v4l-dvb/v4l/radio-si470x.c: In function 'si470x_fops_release': /home/nicola/v4l-dvb/v4l/radio-si470x.c:1218: warning: label 'unlock' defined but not used Priority: normal Signed-off-by: Nicola Soranzo nsora...@tiscali.it --- diff -r 83712d149893 -r 97be9e920832 linux/drivers/media/radio/radio-si470x.c --- a/linux/drivers/media/radio/radio-si470x.c Wed Apr 29 18:01:48 2009 -0300 +++ b/linux/drivers/media/radio/radio-si470x.c Thu Apr 30 16:10:24 2009 +0200 @@ -1214,8 +1214,6 @@ retval = si470x_stop(radio); usb_autopm_put_interface(radio-intf); } - -unlock: mutex_unlock(radio-disconnect_lock); done: -- 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] v4l2: fill the reserved fields of VIDIOC_REQBUFS ioctl
On Wed, 29 Apr 2009, [UTF-8] N??meth M??rton wrote: The parameter of VIDIOC_REQBUFS is a pointer to struct v4l2_requestbuffers. This structure has reserved fields which has to be filled with zeros according to the V4L2 API specification, revision 0.24 [1]. As I read the spec, the reserved fields can be used for input from user space if the buffer is of type V4L2_BUF_TYPE_PRIVATE or higher. -- 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: Nova-T 500 does not survive reboot
On Thu, 2009-04-30 at 13:56 +0200, soeren.m...@stud.uni-hannover.de wrote: Apr 29 22:42:41 favia kernel: [ 72.272045] ehci_hcd :07:01.2: force halt; handhake c2666814 4000 - -110 [...] Do you know if the issue is the same with a Nova-TD stick? If it is, then I could be able to use debugging as an excuse to buy one, and then add 2 tuners to the system when all is done :o) I had the same ehci_hcd force halt error when I was debugging the Nova-TD dual-stream-switchon-problem: http://www.mail-archive.com/linux-media@vger.kernel.org/msg04643.html Reducing the urb count to 1 (as included in the patch) solved the ehci_hcd force halt issue for me. I mention that the URB part is a quick hack. You were asking for opinions on that, and apparently did not get any feedback. Time for another call? Nico -- 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: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)
On Thu, 30 Apr 2009, Wolfram Sang wrote:
Hi all,
I recently found an elta media dc8212 camera (usb-id: 0x093a:0x010e) in a pile
of old hardware. When looking for linux-support (out of curiosity, I don't need
the cam), I saw that there is activity regarding these types of camera
(mr97310) right now. As I am currently busy in other departments of the kernel,
I was wondering if somebody here is interested in getting the camera to do
further research? If so, just drop me a mail and I will send it free-of-charge.
Regards,
Wolfram
PS: The camera still works. Just checked with another OS on a friend's machine.
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hi,
If you want to do such a thing, I think it is very kind of you. As for
myself, I suspect that I already have three or four similar cameras, and
so I probably do not really need another one. Also, judging from your
e-mail address you are in Germany and I am in the US, making it a less
desirable prospect to ship such an object for such a distance.
Therefore, I would offer the suggestion that the camera should go to Kyle
Guin, who wrote the kernel support, or, if he is also in the US (I do not
know where he lives) then perhaps to Thomas Kaiser, who lives a bit closer
to you. I think that all three of us are equally interested but as I said
I do not believe that I need another one of these cameras. In case that I
have missed someone else who might be interested, that is inadvertent on
my part.
Judging from the Vendor:Product number which you report, it is one of the
small MR97310 cameras for which the OEM driver was called the CIF
driver. Indeed, these cameras are not supported right now, so the matter
is interesting.
I do suspect at this point that the clue to getting these cameras to work
is probably to be found in the initialization sequence. I did manage
(finally!) to get one of my old test machines running Windows to accept a
driver installation and to give me a sniff or two. My preliminary analysis
from that experience is, first, the initialization sequence is a bit
different, and, second, the frame data seems to look different from what I
get with the current initialization sequence on Linux. I also tried to
convert a couple of frame data outputs from a sniff log back into binary
format, to see if I could get something out which looks like a picture. I
think I did. Not a very good picture, but it seems that I got something
more than mere noise. I also found out that some of my small cameras with
the same ID will stream, and some will not. Those which will not stream
have a rather strange failure mode: they go through all the motions, but
they produce nothing but a string of repetitions of the SOF marker -- and
this with the OEM driver software, too. But you say that yours actually
worked.
Finally, I would ask one question:
In the libgphoto2 driver for these cameras, I have a listing for
{Elta Medi@ digi-cam, GP_DRIVER_STATUS_EXPERIMENTAL, 0x093a, 0x010e},
Do you think this is the same camera, or a different one? Yours has a
model number, and my listing does not. Elta could of course have produced
two different cameras with the same guts inside, and sold them under two
different model descriptions. I have seen lots of that kind of thing from
other camera vendors. So should there be a separate entry listing this one
by model number? The reason I do not know the answers to such questions
is that, obviously, I have never seen either one of these two cameras. The
first one was reported to me, just like the one which you are offering to
us.
Also might you be interested to try it out as a still camera, with
libgphoto2, before surrendering it to someone else?
Theodore Kilgore
--
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: scan file for cz-Praha
2009/4/30 Christoph Pfister christophpfis...@gmail.com: From a kaffeine user ... Christoph cz-Praha Description: Binary data
patch: s2255drv: urb completion routine fixes
From: Dean Anderson d...@sensoray.com
Error count in read pipe completion corrected.
URB not resubmitted if shutting down.
URB not freed in completion routine if new urb_submit_fails.
(URB is freed on shutdown).
Signed-off-by: Dean Anderson d...@sensoray.com
--- v4l-dvb-83712d149893/linux/drivers/media/video/s2255drv.c.orig
2009-04-30 07:34:34.0 -0700
+++ v4l-dvb-83712d149893/linux/drivers/media/video/s2255drv.c 2009-04-30
07:27:10.0 -0700
@@ -2240,8 +2240,10 @@ static void read_pipe_completion(struct
return;
}
status = purb-status;
- if (status != 0) {
- dprintk(2, read_pipe_completion: err\n);
+ /* if shutting down, do not resubmit, exit immediately */
+ if (status == -ESHUTDOWN) {
+ dprintk(2, read_pipe_completion: err shutdown\n);
+ pipe_info-err_count++;
return;
}
@@ -2250,9 +2252,13 @@ static void read_pipe_completion(struct
return;
}
- s2255_read_video_callback(dev, pipe_info);
+ if (status == 0)
+ s2255_read_video_callback(dev, pipe_info);
+ else {
+ pipe_info-err_count++;
+ dprintk(1, s2255drv: failed URB %d\n, status);
+ }
- pipe_info-err_count = 0;
pipe = usb_rcvbulkpipe(dev-udev, dev-read_endpoint);
/* reuse urb */
usb_fill_bulk_urb(pipe_info-stream_urb, dev-udev,
@@ -2264,7 +2270,6 @@ static void read_pipe_completion(struct
if (pipe_info-state != 0) {
if (usb_submit_urb(pipe_info-stream_urb, GFP_KERNEL)) {
dev_err(dev-udev-dev, error submitting urb\n);
- usb_free_urb(pipe_info-stream_urb);
}
} else {
dprintk(2, read pipe complete state 0\n);
--
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] v4l2: fill the reserved fields of VIDIOC_REQBUFS ioctl
On Thu, 30 Apr 2009, Trent Piepho wrote:
On Wed, 29 Apr 2009, [UTF-8] N??meth M??rton wrote:
The parameter of VIDIOC_REQBUFS is a pointer to struct v4l2_requestbuffers.
This structure has reserved fields which has to be filled with zeros
according to the V4L2 API specification, revision 0.24 [1].
As I read the spec, the reserved fields can be used for input from user
space if the buffer is of type V4L2_BUF_TYPE_PRIVATE or higher.
Here is a patch that fixes this problem, along with the S_FMT problem you
patched earlier. TRY_FMT had the same problem as S_FMT, so I fixed that
one as well too.
v4l2-ioctl: Clear buffer type specific trailing fields/padding
From: Trent Piepho xy...@speakeasy.org
Some ioctls have structs that are a different size depending on what type
of buffer is being used. If the buffer type leaves a field unused or has
padding space at the end, this space should be zeroed out.
The problems with S_FMT and REQBUFS were original identified and patched by
M??rton N??meth nm...@freemail.hu.
Priority: normal
Signed-off-by: Trent Piepho xy...@speakeasy.org
diff -r 7b786cb576e5 -r 82ef5d6e29e3 linux/drivers/media/video/v4l2-ioctl.c
--- a/linux/drivers/media/video/v4l2-ioctl.cThu Apr 30 09:14:13 2009 -0700
+++ b/linux/drivers/media/video/v4l2-ioctl.cThu Apr 30 09:15:56 2009 -0700
@@ -42,6 +42,12 @@
if (vfd-debug V4L2_DEBUG_IOCTL_ARG) \
printk(KERN_DEBUG %s: fmt, vfd-name, ## arg);\
} while (0)
+
+/* Zero out the end of the struct pointed to by p. Everthing after, but
+ * not including, the specified field is cleared. */
+#define CLEAR_AFTER_FIELD(p, field) \
+ memset((u8 *)(p) + offsetof(typeof(*(p)), field) + sizeof((p)-field), \
+ 0, sizeof(*(p)) - offsetof(typeof(*(p)), field) - sizeof((p)-field))
struct std_descr {
v4l2_std_id std;
@@ -783,44 +789,53 @@ static long __video_do_ioctl(struct file
switch (f-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
+ CLEAR_AFTER_FIELD(f, fmt.pix);
v4l_print_pix_fmt(vfd, f-fmt.pix);
if (ops-vidioc_s_fmt_vid_cap)
ret = ops-vidioc_s_fmt_vid_cap(file, fh, f);
break;
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
+ CLEAR_AFTER_FIELD(f, fmt.win);
if (ops-vidioc_s_fmt_vid_overlay)
ret = ops-vidioc_s_fmt_vid_overlay(file,
fh, f);
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+ CLEAR_AFTER_FIELD(f, fmt.pix);
v4l_print_pix_fmt(vfd, f-fmt.pix);
if (ops-vidioc_s_fmt_vid_out)
ret = ops-vidioc_s_fmt_vid_out(file, fh, f);
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
+ CLEAR_AFTER_FIELD(f, fmt.win);
if (ops-vidioc_s_fmt_vid_out_overlay)
ret = ops-vidioc_s_fmt_vid_out_overlay(file,
fh, f);
break;
case V4L2_BUF_TYPE_VBI_CAPTURE:
+ CLEAR_AFTER_FIELD(f, fmt.vbi);
if (ops-vidioc_s_fmt_vbi_cap)
ret = ops-vidioc_s_fmt_vbi_cap(file, fh, f);
break;
case V4L2_BUF_TYPE_VBI_OUTPUT:
+ CLEAR_AFTER_FIELD(f, fmt.vbi);
if (ops-vidioc_s_fmt_vbi_out)
ret = ops-vidioc_s_fmt_vbi_out(file, fh, f);
break;
case V4L2_BUF_TYPE_SLICED_VBI_CAPTURE:
+ CLEAR_AFTER_FIELD(f, fmt.sliced);
if (ops-vidioc_s_fmt_sliced_vbi_cap)
ret = ops-vidioc_s_fmt_sliced_vbi_cap(file,
fh, f);
break;
case V4L2_BUF_TYPE_SLICED_VBI_OUTPUT:
+ CLEAR_AFTER_FIELD(f, fmt.sliced);
if (ops-vidioc_s_fmt_sliced_vbi_out)
ret = ops-vidioc_s_fmt_sliced_vbi_out(file,
fh, f);
break;
case V4L2_BUF_TYPE_PRIVATE:
+ /* CLEAR_AFTER_FIELD(f, fmt.raw_data); - does nothing
*/
if (ops-vidioc_s_fmt_type_private)
ret = ops-vidioc_s_fmt_type_private(file,
fh, f);
@@ -837,46 +852,55 @@ static long __video_do_ioctl(struct file
Re: [PATCH 2/5] V4L2 patches for Intel Moorestown Camera Imaging Drivers
Hello,
do you mind if i make few comments?
Really, looks like
http://patchwork.kernel.org/project/linux-media/list/
didnt catch your [1/5] patch.
On Thu, Apr 30, 2009 at 12:22 PM, Zhang, Xiaolin
xiaolin.zh...@intel.com wrote:
From d8f37b4340ea4cfd28d6e620f1b3224d946b9fab Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Thu, 30 Apr 2009 12:31:21 +0800
Subject: [PATCH] sensor pseduo driver in camera imaging on Intel moorestown
platform.
The moorestown platform with dual cameras will have one the same side as
the display and the second on the oppsoite side of the display. The pseduo
driver provides the uniform interface for isp kernel driver.
Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
drivers/media/video/Makefile | 1 +
drivers/media/video/mrstci/Kconfig | 1 +
drivers/media/video/mrstci/include/ci_sensor_ioc.h | 57 +
drivers/media/video/mrstci/include/sensordev.h | 119 +++
drivers/media/video/mrstci/mrstsensor/Kconfig | 9 +
drivers/media/video/mrstci/mrstsensor/Makefile | 3 +
drivers/media/video/mrstci/mrstsensor/mrstsensor.c | 1094
.../media/video/mrstci/mrstsensor/sensordev_priv.h | 37 +
8 files changed, 1321 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mrstci/include/ci_sensor_ioc.h
create mode 100644 drivers/media/video/mrstci/include/sensordev.h
create mode 100644 drivers/media/video/mrstci/mrstsensor/Kconfig
create mode 100644 drivers/media/video/mrstci/mrstsensor/Makefile
create mode 100644 drivers/media/video/mrstci/mrstsensor/mrstsensor.c
create mode 100644 drivers/media/video/mrstci/mrstsensor/sensordev_priv.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f06f1cb..34a3461 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_VIDEO_AU0828) += au0828/
obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/
obj-$(CONFIG_VIDEO_MRST_ISP) += mrstci/mrstisp/
+obj-$(CONFIG_VIDEO_MRST_SENSOR) += mrstci/mrstsensor/
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/video/mrstci/Kconfig
b/drivers/media/video/mrstci/Kconfig
index 8f0a620..bf01447 100644
--- a/drivers/media/video/mrstci/Kconfig
+++ b/drivers/media/video/mrstci/Kconfig
@@ -10,6 +10,7 @@ if VIDEO_MRSTCI VIDEO_V4L2
source drivers/media/video/mrstci/mrstisp/Kconfig
+source drivers/media/video/mrstci/mrstsensor/Kconfig
endif # VIDEO_MRSTCI
diff --git a/drivers/media/video/mrstci/include/ci_sensor_ioc.h
b/drivers/media/video/mrstci/include/ci_sensor_ioc.h
new file mode 100644
index 000..80d3b0f
--- /dev/null
+++ b/drivers/media/video/mrstci/include/ci_sensor_ioc.h
@@ -0,0 +1,57 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+/* Sensor IOCTL */
+#ifndef _SENSOR_IOC_H
+#define _SENSOR_IOC_H
+
+#ifdef __cplusplus
+extern C {
+#endif
Looks interesting. Why is this workaround for C++ here?
+
+#define SENSOR_MAGIC 0x83
+
+#define SENIOC_QUERYCAP _IOR(SENSOR_MAGIC, 0, struct ci_sensor_caps)
+#define SENIOC_G_CONFIG _IOR(SENSOR_MAGIC, 1, struct ci_sensor_config)
+#define SENIOC_S_CONFIG _IOW(SENSOR_MAGIC, 2, struct ci_sensor_config)
+#define SENIOC_STREAM_ON _IO(SENSOR_MAGIC, 3)
+#define SENIOC_STREAM_OFF _IO(SENSOR_MAGIC, 4)
+#define SENIOC_G_REG _IOWR(SENSOR_MAGIC, 5, struct ci_sensor_reg)
+#define SENIOC_S_REG _IOW(SENSOR_MAGIC, 6, struct ci_sensor_reg)
+/* Get current focus position */
+#define SENIOC_MDI_G_FOCUS _IOR(SENSOR_MAGIC, 9, unsigned int)
+/* Set focus to the given position */
+#define SENIOC_MDI_S_FOCUS _IOW(SENSOR_MAGIC, 10, unsigned int)
+/* Trigger a forced calibration of focus hardware */
+#define SENIOC_MDI_CALIBRATE _IO(SENSOR_MAGIC, 11)
+#define SENIOC_MDI_MAX_STEP _IOR(SENSOR_MAGIC, 12, unsigned int)
+/* Get the max step hardware can support */
+#define SENIOC_ENUMPARM _IOWR(SENSOR_MAGIC, 13, struct ci_sensor_parm)
+#define SENIOC_G_PARM _IOWR(SENSOR_MAGIC, 14, struct ci_sensor_parm)
Re: Nova-T 500 does not survive reboot
On Thu, 2009-04-30 at 16:08 +0100, Nicolas Will wrote: I mention that the URB part is a quick hack. *you* mention, I wouldn't dare... ;o) Nico -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Apr 30 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11658:83712d149893 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-rc3-armv5: WARNINGS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc3-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc3-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc3-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-rc3-m32r: WARNINGS linux-2.6.22.19-mips: WARNINGS linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29.1-mips: WARNINGS linux-2.6.30-rc3-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc3-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-rc3-x86_64: WARNINGS fw/apps: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Digital compact cameras that can be used as video devices?
Thanks for your advice, I learned a lot. I will look into all the options to the extent time (and my knowledge) allows for, and hopefully come up with something good. Thanks! Robin -- 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] radio_si470x: Drop unused label
(added Tobias and Mauro on c/c) On Thu, Apr 30, 2009 at 6:16 PM, Nicola Soranzo nsora...@tiscali.it wrote: Fix this warning: /home/nicola/v4l-dvb/v4l/radio-si470x.c: In function 'si470x_fops_release': /home/nicola/v4l-dvb/v4l/radio-si470x.c:1218: warning: label 'unlock' defined but not used Priority: normal Signed-off-by: Nicola Soranzo nsora...@tiscali.it --- diff -r 83712d149893 -r 97be9e920832 linux/drivers/media/radio/radio-si470x.c --- a/linux/drivers/media/radio/radio-si470x.c Wed Apr 29 18:01:48 2009 -0300 +++ b/linux/drivers/media/radio/radio-si470x.c Thu Apr 30 16:10:24 2009 +0200 @@ -1214,8 +1214,6 @@ retval = si470x_stop(radio); usb_autopm_put_interface(radio-intf); } - -unlock: mutex_unlock(radio-disconnect_lock); done: Looks good. Thank you. When i built latest up-to-date git kernel i noticed that this warning showed there also. Probably, it's better this patch reach 2.6.30 kernel. Now we are at rc4. -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hello, On Mon, Apr 20, 2009 at 3:59 AM, Mike Isely is...@isely.net wrote: On Mon, 20 Apr 2009, Alexey Klimov wrote: [...] When trying to compile v4l-dvb tree under 2.6.30-rc2 (up-to-date) i have such error with pvr2 module: CC [M] /w/new/v4l-dvb/v4l/pvrusb2-hdw.o /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_upload_firmware1': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:1474: error: implicit declaration of function 'usb_settoggle' /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_hdw_load_modules': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:2133: warning: format not a string literal and no format arguments make[3]: *** [/w/new/v4l-dvb/v4l/pvrusb2-hdw.o] Error 1 make[2]: *** [_module_/w/new/v4l-dvb/v4l] Error 2 It's probably due to this git commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3444b26afa145148951112534f298bdc554ec789 I don't have idea how to fix it fast and correctly. This might explain things a bit. The following thread took place on linux-usb on 7-April: Well, looks like it explains everything. quote On Tue, 7 Apr 2009, Greg KH wrote: On Tue, Apr 07, 2009 at 05:31:55PM +, David Vrabel wrote: Wireless USB endpoint state has a sequence number and a current window and not just a single toggle bit. So allow HCDs to provide a endpoint_reset method and call this or clear the software toggles as required (after a clear halt). usb_settoggle() and friends are then HCD internal and are moved into core/hcd.h. You remove this api, yet the pvrusb2 driver used it, and you don't seem to have resolved the issue where it was calling it: diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c b/drivers/media/video/pvrusb2/pvrusb2-hdw.c index fa304e5..b86682d 100644 --- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c @@ -1418,7 +1418,6 @@ static int pvr2_upload_firmware1(struct pvr2_hdw *hdw) return ret; } - usb_settoggle(hdw-usb_dev, 0 0xf, !(0 USB_DIR_IN), 0); usb_clear_halt(hdw-usb_dev, usb_sndbulkpipe(hdw-usb_dev, 0 0x7f)); pipe = usb_sndctrlpipe(hdw-usb_dev, 0); Should usb_reset_endpoint() be called here instead? Speaking as the maintainer of that driver, I'm OK with accepting this as-is for now. This is a sequence that should not interfere with normal driver operation. I will look at this further a little later (not likely before the merge window closes) and if this change turns out to cause a problem I'll make a follow-up fix upstream. Acked-By: Mike Isely is...@pobox.com -Mike /quote So the kernel already has this; it just needs to be pulled back into v4l-dvb. It's an obvious trivial thing for now and I've acked it there. Obviously we're getting had here because you're compiling against a kernel snapshot that's been changed but v4l-dvb doesn't have the corresponding change in its local copy of the pvrusb2 driver. Part of the fun of synchronizing changes from different trees :-( Well, good to know that this thing is already fixed. I'm very sorry for the mess. -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-core: Fix potential mutex_unlock without mutex_lock in dvb_dvr_read
On Thu, 30 Apr 2009 22:42:06 +0100
Simon Arlott si...@fire.lp0.eu wrote:
diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
b/drivers/media/dvb/dvb-core/dmxdev.c
index c35fbb8..d6d098a 100644
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -247,7 +247,7 @@ static ssize_t dvb_dvr_read(struct file *file, char
__user *buf, size_t count,
int ret;
if (dmxdev-exit) {
- mutex_unlock(dmxdev-mutex);
+ //mutex_unlock(dmxdev-mutex);
return -ENODEV;
}
Is there any value in retaining all the commented-out lock operations,
or can we zap 'em?
I'm assuming they should really be there - it's just not practical
because the call to dvb_dmxdev_buffer_read is likely to block waiting
for data.
well.. such infomation is much better communicated via a nice comment,
rather than mystery-dead-code?
--
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] dvb-core: Fix potential mutex_unlock without mutex_lock in dvb_dvr_read
On 30/04/09 21:18, Andrew Morton wrote:
On Thu, 23 Apr 2009 18:32:13 +0100
Simon Arlott si...@fire.lp0.eu wrote:
dvb_dvr_read may unlock the dmxdev mutex and return -ENODEV,
except this function is a file op and will never be called
with the mutex held.
There's existing mutex_lock and mutex_unlock around the actual
read but it's commented out. These should probably be uncommented
but the read blocks and this could block another non-blocking
reader on the mutex instead.
This change comments out the extra mutex_unlock.
Signed-off-by: Simon Arlott si...@fire.lp0.eu
---
This has been on my TODO list for far too long... I did come
up with a mutex_trylock/mutex_lock_interruptible version but
claiming that it'll block when it may not doesn't make sense
(and any blocking read would cause all non-blocking reads to
continually return -EWOULDBLOCK until there is data).
drivers/media/dvb/dvb-core/dmxdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
b/drivers/media/dvb/dvb-core/dmxdev.c
index c35fbb8..d6d098a 100644
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -247,7 +247,7 @@ static ssize_t dvb_dvr_read(struct file *file, char
__user *buf, size_t count,
int ret;
if (dmxdev-exit) {
-mutex_unlock(dmxdev-mutex);
+//mutex_unlock(dmxdev-mutex);
return -ENODEV;
}
Is there any value in retaining all the commented-out lock operations,
or can we zap 'em?
I'm assuming they should really be there - it's just not practical
because the call to dvb_dmxdev_buffer_read is likely to block waiting
for data.
---
a/drivers/media/dvb/dvb-core/dmxdev.c~dvb-core-fix-potential-mutex_unlock-without-mutex_lock-in-dvb_dvr_read-fix
+++ a/drivers/media/dvb/dvb-core/dmxdev.c
@@ -244,19 +244,13 @@ static ssize_t dvb_dvr_read(struct file
{
struct dvb_device *dvbdev = file-private_data;
struct dmxdev *dmxdev = dvbdev-priv;
- int ret;
- if (dmxdev-exit) {
- //mutex_unlock(dmxdev-mutex);
+ if (dmxdev-exit)
return -ENODEV;
- }
- //mutex_lock(dmxdev-mutex);
- ret = dvb_dmxdev_buffer_read(dmxdev-dvr_buffer,
- file-f_flags O_NONBLOCK,
- buf, count, ppos);
- //mutex_unlock(dmxdev-mutex);
- return ret;
+ return dvb_dmxdev_buffer_read(dmxdev-dvr_buffer,
+ file-f_flags O_NONBLOCK,
+ buf, count, ppos);
}
static int dvb_dvr_set_buffer_size(struct dmxdev *dmxdev,
_
--
Simon Arlott
--
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] dvb-core: Fix potential mutex_unlock without mutex_lock in dvb_dvr_read
On Thu, Apr 30, 2009 at 5:48 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Thu, 30 Apr 2009 22:42:06 +0100
Simon Arlott si...@fire.lp0.eu wrote:
diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
b/drivers/media/dvb/dvb-core/dmxdev.c
index c35fbb8..d6d098a 100644
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -247,7 +247,7 @@ static ssize_t dvb_dvr_read(struct file *file, char
__user *buf, size_t count,
int ret;
if (dmxdev-exit) {
- mutex_unlock(dmxdev-mutex);
+ //mutex_unlock(dmxdev-mutex);
return -ENODEV;
}
Is there any value in retaining all the commented-out lock operations,
or can we zap 'em?
I'm assuming they should really be there - it's just not practical
because the call to dvb_dmxdev_buffer_read is likely to block waiting
for data.
well.. such infomation is much better communicated via a nice comment,
rather than mystery-dead-code?
I'm doing some review of the locking in dvb core as a result of a race
condition I found earlier in the week. I'll take a look at this too
when I get a few minutes.
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: remove driver_data direct access of struct device
From: Greg Kroah-Hartman gre...@suse.de
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/media/dvb/firewire/firedtv-1394.c |4 ++--
drivers/media/dvb/firewire/firedtv-dvb.c|2 +-
drivers/media/video/pvrusb2/pvrusb2-sysfs.c | 22 +++---
3 files changed, 14 insertions(+), 14 deletions(-)
--- a/drivers/media/dvb/firewire/firedtv-1394.c
+++ b/drivers/media/dvb/firewire/firedtv-1394.c
@@ -225,7 +225,7 @@ fail_free:
static int node_remove(struct device *dev)
{
- struct firedtv *fdtv = dev-driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(dev);
fdtv_dvb_unregister(fdtv);
@@ -242,7 +242,7 @@ static int node_remove(struct device *de
static int node_update(struct unit_directory *ud)
{
- struct firedtv *fdtv = ud-device.driver_data;
+ struct firedtv *fdtv = dev_get_drvdata(ud-device);
if (fdtv-isochannel = 0)
cmp_establish_pp_connection(fdtv, fdtv-subunit,
--- a/drivers/media/dvb/firewire/firedtv-dvb.c
+++ b/drivers/media/dvb/firewire/firedtv-dvb.c
@@ -268,7 +268,7 @@ struct firedtv *fdtv_alloc(struct device
if (!fdtv)
return NULL;
- dev-driver_data= fdtv;
+ dev_set_drvdata(dev, fdtv);
fdtv-device= dev;
fdtv-isochannel= -1;
fdtv-voltage = 0xff;
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -539,7 +539,7 @@ static void class_dev_destroy(struct pvr
sfp-attr_unit_number);
}
pvr2_sysfs_trace(Destroying class_dev id=%p,sfp-class_dev);
- sfp-class_dev-driver_data = NULL;
+ dev_set_drvdata(sfp-class_dev, NULL);
device_unregister(sfp-class_dev);
sfp-class_dev = NULL;
}
@@ -549,7 +549,7 @@ static ssize_t v4l_minor_number_show(str
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -561,7 +561,7 @@ static ssize_t bus_info_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_bus_info(sfp-channel.hdw));
@@ -572,7 +572,7 @@ static ssize_t hdw_name_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_type(sfp-channel.hdw));
@@ -583,7 +583,7 @@ static ssize_t hdw_desc_show(struct devi
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
pvr2_hdw_get_desc(sfp-channel.hdw));
@@ -595,7 +595,7 @@ static ssize_t v4l_radio_minor_number_sh
char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -607,7 +607,7 @@ static ssize_t unit_number_show(struct d
struct device_attribute *attr, char *buf)
{
struct pvr2_sysfs *sfp;
- sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+ sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
pvr2_hdw_get_unit_number(sfp-channel.hdw));
@@ -635,7 +635,7 @@ static void class_dev_create(struct pvr2
class_dev-parent = usb_dev-dev;
sfp-class_dev = class_dev;
- class_dev-driver_data = sfp;
+ dev_set_drvdata(class_dev, sfp);
ret = device_register(class_dev);
if (ret) {
Re: [linux-dvb] Can't scan transponders with Terratec Cinergy HT PCI board
Hi Charles, Am Donnerstag, den 30.04.2009, 13:54 +0200 schrieb Charles: Hello, I installed my Terratec Cinergy HT PCI DVB-T board on Ubuntu 9.04 I guess HT PCI can mean a lot, like My Cinema, WinFast and the like ... using your tutorial (http://www.linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers) and when trying to scan transponders, no result was found: $ ls -l /dev/dvb/adapter0 total 0 crw-rw+ 1 root video 212, 1 2009-04-30 12:19 demux0 crw-rw+ 1 root video 212, 2 2009-04-30 12:19 dvr0 crw-rw+ 1 root video 212, 0 2009-04-30 12:19 frontend0 crw-rw+ 1 root video 212, 3 2009-04-30 12:19 net0 $ scan /usr/share/dvb/dvb-t/fr-Nantes scanning /usr/share/dvb/dvb-t/fr-Nantes using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 49800 0 2 9 3 1 0 0 initial transponder 50600 0 2 9 3 1 0 0 initial transponder 52200 0 2 9 3 1 0 0 initial transponder 53000 0 2 9 3 1 0 0 initial transponder 65800 0 2 9 3 1 0 0 initial transponder 80200 0 2 9 3 1 0 0 Can't tell offhand if the zl10353 eventually has this problem too, which is well known on the tda10046. Please try to add plus 167 kHz to your initial scan file for Nantes, like you can see it here for one of the Lyon transmitters. # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy # R1 : Canal 56 T 754167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # R2 : Canal 36 T 594167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # R3 : Canal 21 T 474167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # R4 : Canal 54 T 738167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # R5 : Canal 27 T 522167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # R6 : Canal 24 T 498167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE At least we can exclude this then. Cheers, Hermann tune to: 49800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 49800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! tune to: 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! tune to: 52200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 52200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! tune to: 53000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 53000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! tune to: 65800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 65800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! tune to: 80200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE WARNING: tuning failed!!! tune to: 80200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed) WARNING: tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done. $ dvbscan /usr/share/dvb/dvb-t/fr-Nantes Unable to query frontend status $ w_scan -ft -X w_scan version 20081106 Info: using DVB adapter auto detection. Found DVB-T frontend. Using adapter /dev/dvb/adapter0/frontend0 -_-_-_-_ Getting frontend capabilities-_-_-_-_ frontend Zarlink ZL10353 DVB-T supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 177500: 184500: 191500: 198500: 205500: 212500: 219500: 226500: 474000: 482000: 49: 498000: 506000: 514000: 522000: 53: 538000: 546000: 554000: 562000: 57: 578000: 586000: 594000: 602000: 61: 618000: 626000: 634000: 642000: 65: 658000: 666000: 674000: 682000: 69: 698000: 706000: 714000: 722000: 73: 738000: 746000: 754000: 762000: 77: 778000: 786000: 794000: 802000: 81: 818000: 826000: 834000: 842000: 85: 858000: ERROR: Sorry - i couldn't get any working frequency/transponder
Re: [PATCH] pvrusb2: Don't use the internal i2c client list
On Thu, 30 Apr 2009, Jean Delvare wrote:
The i2c core used to maintain a list of client for each adapter. This
is a duplication of what the driver core already does, so this list
will be removed as part of a future cleanup. Anyone using this list
must stop doing so.
For pvrusb2, I propose the following change, which should lead to an
equally informative output. The only difference is that i2c clients
which are not a v4l2 subdev won't show up, but I guess this case is
not supposed to happen anyway.
It will happen for anything i2c used by v4l which itself is not really a
part of v4l. That would include, uh, lirc.
I will review and test this first chance I get which should be tomorrow.
-Mike
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mike Isely is...@pobox.com
---
Mike, can you please review and test this patch? Thanks.
linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c | 56
+--
1 file changed, 13 insertions(+), 43 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-04-30 16:52:32.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c 2009-04-30
17:20:37.0 +0200
@@ -4920,65 +4920,35 @@ static unsigned int pvr2_hdw_report_clie
unsigned int tcnt = 0;
unsigned int ccnt;
struct i2c_client *client;
- struct list_head *item;
- void *cd;
const char *p;
unsigned int id;
- ccnt = scnprintf(buf, acnt, Associated v4l2-subdev drivers:);
+ ccnt = scnprintf(buf, acnt, Associated v4l2-subdev drivers and I2C
clients:\n);
tcnt += ccnt;
v4l2_device_for_each_subdev(sd, hdw-v4l2_dev) {
id = sd-grp_id;
p = NULL;
if (id ARRAY_SIZE(module_names)) p = module_names[id];
if (p) {
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, %s, p);
+ ccnt = scnprintf(buf + tcnt, acnt - tcnt, %s:, p);
tcnt += ccnt;
} else {
ccnt = scnprintf(buf + tcnt, acnt - tcnt,
- (unknown id=%u), id);
+(unknown id=%u):, id);
tcnt += ccnt;
}
- }
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, \n);
- tcnt += ccnt;
-
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, I2C clients:\n);
- tcnt += ccnt;
-
- mutex_lock(hdw-i2c_adap.clist_lock);
- list_for_each(item, hdw-i2c_adap.clients) {
- client = list_entry(item, struct i2c_client, list);
- ccnt = scnprintf(buf + tcnt, acnt - tcnt,
-%s: i2c=%02x, client-name, client-addr);
- tcnt += ccnt;
- cd = i2c_get_clientdata(client);
- v4l2_device_for_each_subdev(sd, hdw-v4l2_dev) {
- if (cd == sd) {
- id = sd-grp_id;
- p = NULL;
- if (id ARRAY_SIZE(module_names)) {
- p = module_names[id];
- }
- if (p) {
- ccnt = scnprintf(buf + tcnt,
- acnt - tcnt,
- subdev=%s, p);
- tcnt += ccnt;
- } else {
- ccnt = scnprintf(buf + tcnt,
- acnt - tcnt,
- subdev= id %u),
- id);
- tcnt += ccnt;
- }
- break;
- }
+ client = v4l2_get_subdevdata(sd);
+ if (client) {
+ ccnt = scnprintf(buf + tcnt, acnt - tcnt,
+ %s @ %02x\n, client-name,
+ client-addr);
+ tcnt += ccnt;
+ } else {
+ ccnt = scnprintf(buf + tcnt, acnt - tcnt,
+ no i2c client\n);
+ tcnt += ccnt;
}
- ccnt = scnprintf(buf + tcnt, acnt - tcnt, \n);
- tcnt += ccnt;
}
- mutex_unlock(hdw-i2c_adap.clist_lock);
return tcnt;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[pull] http://linuxtv.org/hg/~tap/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~tap/v4l-dvb for the following 4 changesets: 01/04: compat: Add DMA_BIT_MASK() macro http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=486add0e3f1f 02/04: zoran: fix bug when enumerating format -1 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=f144948f22c8 03/04: v4l2-ioctl: Check buffer types using g_fmt instead of try_fmt http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b54857195e2c 04/04: v4l2-ioctl: Clear buffer type specific trailing fields/padding http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=7cbf08aeb840 linux/drivers/media/video/v4l2-ioctl.c | 45 - linux/drivers/media/video/zoran/zoran_driver.c | 30 +++- v4l/compat.h |7 ++- 3 files changed, 55 insertions(+), 27 deletions(-) Thanks, Trent -- 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: Digital compact cameras that can be used as video devices?
Hi, Am Donnerstag, den 30.04.2009, 21:15 +0200 schrieb Robin van Kleeff: Thanks for your advice, I learned a lot. I will look into all the options to the extent time (and my knowledge) allows for, and hopefully come up with something good. Thanks! Robin Theodore obviously has very good insight here, but Devin seemed to be a bit too pessimistic. At least something to look further into. A immediate problem I can imagine is, if you use some such over a capture card, that you don't get the microphone switched on and must have something else connected to the sound card for it. Playback of recorded videos with sound should work from such a device over the capture card, like connected to any recent TV. (preferably the capture card should have analog audio out in that case) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Thu, 2009-04-30 at 20:07 -0500, Britney Fransen wrote:
I have updated the patch from
http://www.linuxtv.org/pipermail/linux-dvb/2008-December/030786.html
to add QAM64 support to the HVR-950Q. It is working well for me.
What needs to happen to get this included in v4l-dvb?
Well, one specific problem is that the patch submission is missing a
Signed-off-by:. Please see:
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1
for what that means and for answers to your more general question.
I'd also expect Devin would need to review and comment on it as he's
done a lot of HVR-950q work lately (IIRC).
Regards,
Andy
Thanks,
Britney
--- linux/drivers/media/dvb/frontends/au8522_dig.c.orig 2009-04-30
14:27:14.417542844 -0500
+++ linux/drivers/media/dvb/frontends/au8522_dig.c2009-04-30
16:57:37.439472504 -0500
@@ -367,11 +367,90 @@ static struct {
{ 0x8231, 0x13 },
};
-/* QAM Modulation table */
+/* QAM64 Modulation table */
static struct {
u16 reg;
u16 data;
-} QAM_mod_tab[] = {
+} QAM64_mod_tab[] = {
+{ 0x80a3, 0x09 },
+{ 0x80a4, 0x00 },
+{ 0x8081, 0xc4 },
+{ 0x80a5, 0x40 },
+{ 0x80aa, 0x77 },
+{ 0x80ad, 0x77 },
+{ 0x80a6, 0x67 },
+{ 0x8262, 0x20 },
+{ 0x821c, 0x30 },
+{ 0x80b8, 0x3e },
+{ 0x80b9, 0xf0 },
+{ 0x80ba, 0x01 },
+{ 0x80bb, 0x18 },
+{ 0x80bc, 0x50 },
+{ 0x80bd, 0x00 },
+{ 0x80be, 0xea },
+{ 0x80bf, 0xef },
+{ 0x80c0, 0xfc },
+{ 0x80c1, 0xbd },
+{ 0x80c2, 0x1f },
+{ 0x80c3, 0xfc },
+{ 0x80c4, 0xdd },
+{ 0x80c5, 0xaf },
+{ 0x80c6, 0x00 },
+{ 0x80c7, 0x38 },
+{ 0x80c8, 0x30 },
+{ 0x80c9, 0x05 },
+{ 0x80ca, 0x4a },
+{ 0x80cb, 0xd0 },
+{ 0x80cc, 0x01 },
+{ 0x80cd, 0xd9 },
+{ 0x80ce, 0x6f },
+{ 0x80cf, 0xf9 },
+{ 0x80d0, 0x70 },
+{ 0x80d1, 0xdf },
+{ 0x80d2, 0xf7 },
+{ 0x80d3, 0xc2 },
+{ 0x80d4, 0xdf },
+{ 0x80d5, 0x02 },
+{ 0x80d6, 0x9a },
+{ 0x80d7, 0xd0 },
+{ 0x8250, 0x0d },
+{ 0x8251, 0xcd },
+{ 0x8252, 0xe0 },
+{ 0x8253, 0x05 },
+{ 0x8254, 0xa7 },
+{ 0x8255, 0xff },
+{ 0x8256, 0xed },
+{ 0x8257, 0x5b },
+{ 0x8258, 0xae },
+{ 0x8259, 0xe6 },
+{ 0x825a, 0x3d },
+{ 0x825b, 0x0f },
+{ 0x825c, 0x0d },
+{ 0x825d, 0xea },
+{ 0x825e, 0xf2 },
+{ 0x825f, 0x51 },
+{ 0x8260, 0xf5 },
+{ 0x8261, 0x06 },
+{ 0x821a, 0x00 },
+{ 0x8546, 0x40 },
+{ 0x8210, 0xc7 },
+{ 0x8211, 0xaa },
+{ 0x8212, 0xab },
+{ 0x8213, 0x02 },
+{ 0x8502, 0x00 },
+{ 0x8121, 0x04 },
+{ 0x8122, 0x04 },
+{ 0x852e, 0x10 },
+{ 0x80a4, 0xca },
+{ 0x80a7, 0x40 },
+{ 0x8526, 0x01 },
+};
+
+/* QAM256 Modulation table */
+static struct {
+ u16 reg;
+ u16 data;
+} QAM256_mod_tab[] = {
{ 0x80a3, 0x09 },
{ 0x80a4, 0x00 },
{ 0x8081, 0xc4 },
@@ -464,12 +543,19 @@ static int au8522_enable_modulation(stru
au8522_set_if(fe, state-config-vsb_if);
break;
case QAM_64:
+dprintk(%s() QAM 64\n, __func__);
+for (i = 0; i ARRAY_SIZE(QAM64_mod_tab); i++)
+au8522_writereg(state,
+QAM64_mod_tab[i].reg,
+QAM64_mod_tab[i].data);
+au8522_set_if(fe, state-config-qam_if);
+break;
case QAM_256:
- dprintk(%s() QAM 64/256\n, __func__);
- for (i = 0; i ARRAY_SIZE(QAM_mod_tab); i++)
+dprintk(%s() QAM 256\n, __func__);
+for (i = 0; i ARRAY_SIZE(QAM256_mod_tab); i++)
au8522_writereg(state,
- QAM_mod_tab[i].reg,
- QAM_mod_tab[i].data);
+ QAM256_mod_tab[i].reg,
+ QAM256_mod_tab[i].data);
au8522_set_if(fe, state-config-qam_if);
break;
default:
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Enabling of the Winfast TV2000 XP Global TV capture card remote control
Mauro, I have nothing important and nobody cared about the oops on the Compro T750F stuff, on which I was not involved, but I would like to have a warning in for the Asus 3in1 not to use a rotor with it. I was somewhat alerted by GPL m$ mediaportal not to use a rotor on cards, except you know exactly they can stand it. The Asus 3in1, still OEM only, but consumer cards are ready, has only support for 500 mA current. The LNB supply on it seems to have protection against over current usage and Asus also does not give any warnings for such cards in that direction. Most likely no trouble ever. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
I'm the original author of the patch. I included a Signed-off-by:
line when I submitted it (see the email Britney linked to). As far as
I can tell, the only modification to the patch is the file it is
applied to. This is exactly what I did after analog support was
merged, but I never submitted it since there didn't seem to be any
interest. For the record, I've been using this patch for several
months now without problems and would love to see it merged.
Frank
On Thu, Apr 30, 2009 at 7:21 PM, Andy Walls awa...@radix.net wrote:
On Thu, 2009-04-30 at 20:07 -0500, Britney Fransen wrote:
I have updated the patch from
http://www.linuxtv.org/pipermail/linux-dvb/2008-December/030786.html
to add QAM64 support to the HVR-950Q. It is working well for me.
What needs to happen to get this included in v4l-dvb?
Well, one specific problem is that the patch submission is missing a
Signed-off-by:. Please see:
http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1
for what that means and for answers to your more general question.
I'd also expect Devin would need to review and comment on it as he's
done a lot of HVR-950q work lately (IIRC).
Regards,
Andy
Thanks,
Britney
--- linux/drivers/media/dvb/frontends/au8522_dig.c.orig 2009-04-30
14:27:14.417542844 -0500
+++ linux/drivers/media/dvb/frontends/au8522_dig.c 2009-04-30
16:57:37.439472504 -0500
@@ -367,11 +367,90 @@ static struct {
{ 0x8231, 0x13 },
};
-/* QAM Modulation table */
+/* QAM64 Modulation table */
static struct {
u16 reg;
u16 data;
-} QAM_mod_tab[] = {
+} QAM64_mod_tab[] = {
+ { 0x80a3, 0x09 },
+ { 0x80a4, 0x00 },
+ { 0x8081, 0xc4 },
+ { 0x80a5, 0x40 },
+ { 0x80aa, 0x77 },
+ { 0x80ad, 0x77 },
+ { 0x80a6, 0x67 },
+ { 0x8262, 0x20 },
+ { 0x821c, 0x30 },
+ { 0x80b8, 0x3e },
+ { 0x80b9, 0xf0 },
+ { 0x80ba, 0x01 },
+ { 0x80bb, 0x18 },
+ { 0x80bc, 0x50 },
+ { 0x80bd, 0x00 },
+ { 0x80be, 0xea },
+ { 0x80bf, 0xef },
+ { 0x80c0, 0xfc },
+ { 0x80c1, 0xbd },
+ { 0x80c2, 0x1f },
+ { 0x80c3, 0xfc },
+ { 0x80c4, 0xdd },
+ { 0x80c5, 0xaf },
+ { 0x80c6, 0x00 },
+ { 0x80c7, 0x38 },
+ { 0x80c8, 0x30 },
+ { 0x80c9, 0x05 },
+ { 0x80ca, 0x4a },
+ { 0x80cb, 0xd0 },
+ { 0x80cc, 0x01 },
+ { 0x80cd, 0xd9 },
+ { 0x80ce, 0x6f },
+ { 0x80cf, 0xf9 },
+ { 0x80d0, 0x70 },
+ { 0x80d1, 0xdf },
+ { 0x80d2, 0xf7 },
+ { 0x80d3, 0xc2 },
+ { 0x80d4, 0xdf },
+ { 0x80d5, 0x02 },
+ { 0x80d6, 0x9a },
+ { 0x80d7, 0xd0 },
+ { 0x8250, 0x0d },
+ { 0x8251, 0xcd },
+ { 0x8252, 0xe0 },
+ { 0x8253, 0x05 },
+ { 0x8254, 0xa7 },
+ { 0x8255, 0xff },
+ { 0x8256, 0xed },
+ { 0x8257, 0x5b },
+ { 0x8258, 0xae },
+ { 0x8259, 0xe6 },
+ { 0x825a, 0x3d },
+ { 0x825b, 0x0f },
+ { 0x825c, 0x0d },
+ { 0x825d, 0xea },
+ { 0x825e, 0xf2 },
+ { 0x825f, 0x51 },
+ { 0x8260, 0xf5 },
+ { 0x8261, 0x06 },
+ { 0x821a, 0x00 },
+ { 0x8546, 0x40 },
+ { 0x8210, 0xc7 },
+ { 0x8211, 0xaa },
+ { 0x8212, 0xab },
+ { 0x8213, 0x02 },
+ { 0x8502, 0x00 },
+ { 0x8121, 0x04 },
+ { 0x8122, 0x04 },
+ { 0x852e, 0x10 },
+ { 0x80a4, 0xca },
+ { 0x80a7, 0x40 },
+ { 0x8526, 0x01 },
+};
+
+/* QAM256 Modulation table */
+static struct {
+ u16 reg;
+ u16 data;
+} QAM256_mod_tab[] = {
{ 0x80a3, 0x09 },
{ 0x80a4, 0x00 },
{ 0x8081, 0xc4 },
@@ -464,12 +543,19 @@ static int au8522_enable_modulation(stru
au8522_set_if(fe, state-config-vsb_if);
break;
case QAM_64:
+ dprintk(%s() QAM 64\n, __func__);
+ for (i = 0; i ARRAY_SIZE(QAM64_mod_tab); i++)
+ au8522_writereg(state,
+ QAM64_mod_tab[i].reg,
+ QAM64_mod_tab[i].data);
+ au8522_set_if(fe, state-config-qam_if);
+ break;
case QAM_256:
- dprintk(%s() QAM 64/256\n, __func__);
- for (i = 0; i ARRAY_SIZE(QAM_mod_tab); i++)
+ dprintk(%s() QAM 256\n, __func__);
+ for (i = 0; i ARRAY_SIZE(QAM256_mod_tab); i++)
au8522_writereg(state,
- QAM_mod_tab[i].reg,
- QAM_mod_tab[i].data);
+ QAM256_mod_tab[i].reg,
+ QAM256_mod_tab[i].data);
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Apr 30, 2009, at 8:55 PM, Frank Dischner wrote: As far as I can tell, the only modification to the patch is the file it is applied to. Frank, you are correct. The only change I made was to the new _dig.c file that I believe changed with analog support. Do you want to resubmit the patch with your Signed-off-by: line? I don't think mine was/will be accepted into Patchwork because I omitted the Signed- off-by:. Thanks for the info Andy. Britney -- 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: [ivtv-users] Delay loading v4l-cx25840.fw
On Wed, 2009-04-29 at 21:18 -0400, Andy Walls wrote: On Wed, 2009-04-29 at 13:33 +0200, Hans Verkuil wrote: On Wed, 2009-04-29 at 21:50 +1200, Michael Cree wrote: On 29/04/2009, at 6:19 PM, Hans Verkuil wrote: What does surprise me here is that the fw is loaded right after the driver was loaded, which does suggest that some process is opening one of the device nodes since the fw load is only done on the first open. On my systems (Fedora 9 10) IIRC it happens early too. I've always assumed it was either udev or hal or some some other automatic process that mucks with device nodes. It would be nice if you could track down who is messing around with those device nodes. I'll work on it. It looks like something that is aware of v4l device nodes (see below) - I'm wagering hald. I've found it. It's hald-probe-video4linux: [11539.917539] cx18-0: info: cx18_v4l2_open: called for stream encoder MPEG by pid 22870 (hald-probe-vide) ppid 1981 (hald-runner) [11540.333557] cx18-0: info: cx18_v4l2_open: called for stream encoder PCM audio by pid 22907 (hald-probe-vide) ppid 1981 (hald-runner) [11540.337019] cx18-0: info: cx18_v4l2_open: called for stream encoder VBI by pid 22923 (hald-probe-vide) ppid 1981 (hald-runner) [11540.386051] cx18-0: info: cx18_v4l2_open: called for stream encoder YUV by pid 22929 (hald-probe-vide) ppid 1981 (hald-runner) [11540.401658] cx18-0: info: cx18_v4l2_open: called for stream encoder radio by pid 22930 (hald-probe-vide) ppid 1981 (hald-runner) # locate hald-probe-vide /usr/libexec/hald-probe-video4linux It's not restricted to boot. It happens on modprobe, probably cued by udev or some other hotplug mechanism. If you modprobe ivtv with file and ioctl debugging on, does that give an indication of what is done with the device nodes? For the cx18 driver on a Fedora 10 system something runs through the /dev/video* nodes and /dev/radio* doing VIDIOC_QUERYCAP. I suspect the behavior will be the same for ivtv. I'll test on my other system when I get a chance. Depending on what process is doing what with the device nodes I may be able to optimize the driver for that. It's really annoying to have this fw loaded at boot time, esp. if you have one or more PVR-500 cards. Well thinking about this, this is a system level issue: 1. People want to avoid unnecessary waits at boot (or module insertion time) 2. Hardware detection mechanisms want to query what new hardware is as soon as it appears. 3. Hardware queries from userspace should (or need to) avoid IO bound operations that consume CPU. 4. Kernel drivers should be able to satsify hardware queries without starting up an IO bound operation that consumes CPU. Hans, it sounds like your media_controller device node idea is really what we need to get implemented here for user space to do queires on hardware. This problem obviously affects more than the ivtv driver so I'd recommend against an ivtv band-aid. We'd also want to coordinate with the hald folks and other user space app/plumbing developers, as this likely affects a few v4l2 drivers. It sounds like an LPC agenda item to me... Regards, Andy -- 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] videobuf-dma-contig: zero copy USERPTR support V2
On Tue, Apr 28, 2009 at 6:01 PM, Magnus Damm magnus.d...@gmail.com wrote:
This is V2 of the V4L2 videobuf-dma-contig USERPTR zero copy patch.
I guess the V4L2 specific bits are pretty simple.
As for the minor mm modifications below,
--- 0001/mm/memory.c
+++ work/mm/memory.c 2009-04-28 14:56:43.0 +0900
@@ -3009,7 +3009,6 @@ int in_gate_area_no_task(unsigned long a
#endif /* __HAVE_ARCH_GATE_AREA */
-#ifdef CONFIG_HAVE_IOREMAP_PROT
int follow_phys(struct vm_area_struct *vma,
unsigned long address, unsigned int flags,
unsigned long *prot, resource_size_t *phys)
Is it ok with the memory management guys to always build follow_phys()?
@@ -3063,7 +3062,9 @@ unlock:
out:
return ret;
}
+EXPORT_SYMBOL(follow_phys);
+#ifdef CONFIG_HAVE_IOREMAP_PROT
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write)
{
How about exporting follow_phys()? This because the user
videobuf-dma-contig.c can be built as a module.
Should I use EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL()?
Any comments?
Thanks,
/ magnus
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Thu, Apr 30, 2009 at 10:17 PM, Britney Fransen britney.fran...@gmail.com wrote: On Apr 30, 2009, at 8:55 PM, Frank Dischner wrote: As far as I can tell, the only modification to the patch is the file it is applied to. Frank, you are correct. The only change I made was to the new _dig.c file that I believe changed with analog support. Do you want to resubmit the patch with your Signed-off-by: line? I don't think mine was/will be accepted into Patchwork because I omitted the Signed-off-by:. Thanks for the info Andy. Britney -- 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 Hello, Structurally the patch looks sane, although I want to have a closer look at the actual modulation table values themselves before I merge this in. In the meantime, if Frank could please resubmit this patch against the current tip, I will get it into my tree with some other patches queuing up, do some testing, and issue a PULL request. Thanks, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Thu, Apr 30, 2009 at 10:17 PM, Britney Fransen
britney.fran...@gmail.com wrote:
On Apr 30, 2009, at 8:55 PM, Frank Dischner wrote:
As far as
I can tell, the only modification to the patch is the file it is
applied to.
Frank, you are correct. The only change I made was to the new _dig.c file
that I believe changed with analog support. Do you want to resubmit the
patch with your Signed-off-by: line? I don't think mine was/will be
accepted into Patchwork because I omitted the Signed-off-by:.
Thanks for the info Andy.
Britney
--
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
One more comment: when resubmitting this patch, please change the
modulation values by removing the top bit from the register numbers.
In other words, change:
+ { 0x80a3, 0x09 },
to
+ { 0x00a3, 0x09 },
The top bit is actually not part of the register number, and it now
gets set automatically by the au8522_writereg() routine (I made this
change when I did the analog support). I am going to take a pass over
all the registers in au8522_dig.c at some point, but it doesn't make
sense for any new code to set it.
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] FM1216ME_MK3 some changes
Am Mittwoch, den 29.04.2009, 21:14 -0400 schrieb Andy Walls: On Wed, 2009-04-29 at 20:12 +1000, Dmitri Belimov wrote: Hi, Am Dienstag, den 28.04.2009, 19:59 +1000 schrieb Dmitri Belimov: On Tue, 28 Apr 2009 15:18:32 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Mon, 27 Apr 2009 19:29:05 +1000 Dmitri Belimov d.beli...@gmail.com wrote: Hi All Step by step. This is patch for change only range of FM1216ME_MK3. Slow tunning is not a big problem. Dmitri, I'll mark those patches as RFC at patchwork until the end of those discussions. After that, please send it again into a new thread. You mark patch with TOP AGC not this. I think need discuss about FM1216ME_MK3 because I'll have a big patch for support control TOP AGC (sensitivity) of this tuner. It can be bad for compatible tuners. hmm, in Europe, that TOP AGC did not ever made much difference and it is an insmod option since ever. I can't tell for Sibiria and initially that tuner had no SECAM-DK support officially at all. There are no good/much_better tuners for FTA at all and never have been ;) Some examples, user success reports, to make it more easily to understand? I think it can only change some _very little_ under already worst conditions. This is my idea for RFC about TOP AGC: 1. Add gain variable to tuner structure. 2. Add V4L2_CID_GAIN control to saa7134 and disable this control. 3. Add workaround to simple_post_tune function for write sensitivity level to the tuner. 4. Enable V4L2_CID_GAIN control when module load if card is right. My expirience not so good, step 4 segfault the kernel. How to we can make it? Our windows end-user programm control the sensitivity of each TV channel and change when channel changed. What you think about it?? Dmitri, From my understanding the take over point is the signal strength level that you want the second stage (an IF demod chip like the TDA9887) to take over automatic gain control from the first stage (a tuner chip like the TUA6030). The objective is to set the TOP to achieve maximum gain in the first stage while avoiding clipping in the first stage. When the input signal level is smaller than the TOP, the first stage gain is at a maximum, and the second stage is performing automatic gain control internally. When the input signal level becomes greater than the TOP, the first stage gain needs to be reduced by an AGC, and the second stage gain remains constant. As I understand it, it would be best to set the first stage (TUA6030 or similar) to External AGC and set the take over point in the second stage (the TDA9887), if the pins between the chips are wired up properly inside the tuner. This should coordinate the AGC in both the first stage and second stage of the tuner, as the second stage will be providing the gain control to the first stage as needed when the signal reaches the TOP. http://www.comsec.com/usrp/microtune/NF_tutorial.pdf It allows you to achieve maximum gain in the first stage to minimize overall receiver noise figure, and avoid clipping the input signal in the first stage (TUA6030) with a proper TOP setting in the second stage (TDA9887). The TOP setting in the second stage needs to take into account IF SAW filter attenuation of course. Do the circuit board traces in the FM1216ME_MK3 support the TDA9887 controlling the gain of the first stage? (I've never opened an equivalent NTSC tuner assembly to take a look.) equivalent NTSC tuners _do not_ exist at all. I don't forget all the time we spend to find out that some of them are Intercarrier only! Also, the tda988x stuff is underneath the tuner PCB. I cut one off for those interested in line tracing ... Without port2=0 you don't get any SECAM-L into the sound trap. It needs amplification from minus 40 dB AM for the first sound carrier, and then of course you prefer the second with NICAM. If not, then, if I understand things correctly, you need to set the first stage and second stage TOP settings so that they refer to about the same signal level before the IF SAW filter. I would think AGC TOP settings, for both stages of the tuner, are tuner-dependent and relatively constant once you figure out what they should be. Do you have a different understanding or insight? Regards, Andy Since I have some m$ system again after 9 years, not used within the last three months, I would prefer to get it demonstrated there at first. I leave on the first BSOD. Cheers, Hermann If TV card is not touch V4L2_CTRL_FLAG_DISABLED in this control. The programm can't change AGC TOP. And write default value to AGC TOP like now. diff -r 43dbc8ebb5a2 linux/drivers/media/common/tuners/tuner-simple.c --- a/linux/drivers/media/common/tuners/tuner-simple.c Tue Jan 27
Recommendation for supported DVB-S/S2 USB
Hi, Can anyone recommend a stable USB DVB-S/S2 tuner? Thanks, Bob Ingraham -- 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
Support for Skystar S2 and Twinhan AD-SP200/VP-1027
Hi All, Running Fedora Core 10 (2.6.27) and have looked through the wiki for support for: - Skystar S2 (DVB-S2) PCI - Twinhan AD-SP200/VP-1027 (DVB-S) PCI I'm guessing the wiki is out of date with regards to current status. Are there patches or a snapshot I can pull that has stable support for either of these cards? Thanks, Bob Ingraham -- 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
