Re: Add driver for Aptina Micron mt9p031 sensor.
On 26 July 2011 22:22, Clayton Shotwell shotty...@gmail.com wrote: Javier, I was wondering what the status was of your patches and when you thought they might get added into the mainstream kernel. I am working on integrating the mt9p031 into a little project I am doing. Please let me know when you get a chance. Hi, they are currently sitting in Laurent's tree. According to him, there are a couple of things that must be fixed before submitting them to mainline. But I don't know anything else. Maybe Laurent himself could clarify what is the status right now. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] adp1653: check error code of adp1653_init_controls
Potentially the adp1653_init_controls could return an error. In our case the
error was ignored, meanwhile it means incorrect initialization of V4L2
controls.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/adp1653.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c
index 8ad89ff..3379e6d 100644
--- a/drivers/media/video/adp1653.c
+++ b/drivers/media/video/adp1653.c
@@ -429,7 +429,11 @@ static int adp1653_probe(struct i2c_client *client,
flash-subdev.internal_ops = adp1653_internal_ops;
flash-subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- adp1653_init_controls(flash);
+ ret = adp1653_init_controls(flash);
+ if (ret) {
+ kfree(flash);
+ return ret;
+ }
ret = media_entity_init(flash-subdev.entity, 0, NULL, 0);
if (ret 0)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adp1653: check error code of adp1653_init_controls
On Wed, Jul 27, 2011 at 10:58:02AM +0300, Andy Shevchenko wrote:
Potentially the adp1653_init_controls could return an error. In our case the
error was ignored, meanwhile it means incorrect initialization of V4L2
controls.
Hi, Andy!
Many thanks for the another patch! I'll add this to my next pull req as
well.
Just FYI: As this is clearly a regular patch for the V4L2 subsystem, I think
cc'ing the linux-kernel list isn't necessary.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/adp1653.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c
index 8ad89ff..3379e6d 100644
--- a/drivers/media/video/adp1653.c
+++ b/drivers/media/video/adp1653.c
@@ -429,7 +429,11 @@ static int adp1653_probe(struct i2c_client *client,
flash-subdev.internal_ops = adp1653_internal_ops;
flash-subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- adp1653_init_controls(flash);
+ ret = adp1653_init_controls(flash);
+ if (ret) {
+ kfree(flash);
+ return ret;
+ }
ret = media_entity_init(flash-subdev.entity, 0, NULL, 0);
if (ret 0)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Parallel CMOS Image Sensor with UART Control Interface
Hi James, On Wednesday 27 July 2011 07:41:59 James wrote: On Wed, Jul 27, 2011 at 3:40 AM, Sakari Ailus sakari.ai...@iki.fi wrote: On Mon, Jul 25, 2011 at 04:43:21PM +0800, James wrote: Dear all, Does anyone came across a v4l2 Linux Device Driver for an Image Sensor that uses Parallel CMOS H/V and can only be control by UART interface instead of the common I2C or SPI interface? A similar sensor is the STMicroelectronics VL5510 Image Sensor although it support all 3 types of control interface. (http://www.st.com/internet/automotive/product/178477.jsp) Most or all the drivers found I found under drivers/media/video uses the I2C or SPI interface instead I'm new to writing driver and need a reference v4l2 driver for this type of image sensor to work with OMAP3530 ISP port on Gumstix's Overo board. I just need a very simple v4l2 driver that can extract the image from the sensor and control over it via the UART control interface. Any help is very much appreciated. Hi James, I think there has been a recent discussion on a similar topic under the subject RE: FW: OMAP 3 ISP. The way to do this would be to implement platform subdevs in V4L2 core, which I think we don't have quite yet. Cc Laurent and Michael. Hi Sakari, Thanks for pointing me to the discussion thread. I found it from the archive at http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3270 0/focus=32721 I read through the threads and see that I'm indeed in similar situation with Alex. We both have sensor that output CMOS H/V image and only have UART/RS232 for control of the sensor operations via sending/reading packet of bytes. i.e. AGC, contrast, brightness etc.. Since the thread ended on 29-Jun, is there anymore update or information? As I've a MT9V032 camera with Gusmtix Overo, I was hoping to rely on the MT9V032 driver as a starting point and adapt it for the VL5510 sensor using only the UART interface. As a quick hack, to start with, you can still use an I2C subdev driver. Just remove all I2C-related code from the driver, and register a fake I2C device in board code. That will let you at least develop the driver and test the UART interface. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
From: Javier Martin javier.mar...@vista-silicon.com The MT9P031 is a parallel 12-bit 5MP sensor from Aptina (formerly Micron) controlled through I2C. The driver creates a V4L2 subdevice. It currently supports skipping, cropping, automatic binning, and gain, exposure, h/v flip and test pattern controls. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 961 + include/media/mt9p031.h | 19 + 4 files changed, 988 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h Hi Javier, I've finally been able to spend some time on your MT9P031 driver, and here is the result. I would like to push the driver to mainline for v3.2. Could you please review it ? I still need to have a look at the PLL code to see if we can compute the PLL registers values at runtime instead of using a table-based approach. BTW, do you plan to maintain the driver ? diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 176ac49..81252ec 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -467,6 +467,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- + This is a Video4Linux2 sensor-level driver for the Aptina + (Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 6cca52a..b9e9bb3 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..18e9a3c --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,961 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Laurent Pinchart laurent.pinch...@ideasonboard.com + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * 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. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#define MT9P031_PIXEL_ARRAY_WIDTH 2752 +#define MT9P031_PIXEL_ARRAY_HEIGHT 2004 + +#define MT9P031_CHIP_VERSION 0x00 +#defineMT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START 0x01 +#defineMT9P031_ROW_START_MIN 0 +#defineMT9P031_ROW_START_MAX 2004 +#defineMT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#defineMT9P031_COLUMN_START_MIN0 +#defineMT9P031_COLUMN_START_MAX2750 +#defineMT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT 0x03 +#defineMT9P031_WINDOW_HEIGHT_MIN 2 +#defineMT9P031_WINDOW_HEIGHT_MAX 2006 +#defineMT9P031_WINDOW_HEIGHT_DEF 1944 +#define MT9P031_WINDOW_WIDTH 0x04 +#defineMT9P031_WINDOW_WIDTH_MIN2 +#defineMT9P031_WINDOW_WIDTH_MAX2752 +#defineMT9P031_WINDOW_WIDTH_DEF2592 +#define MT9P031_HORIZONTAL_BLANK 0x05 +#defineMT9P031_HORIZONTAL_BLANK_MIN0 +#defineMT9P031_HORIZONTAL_BLANK_MAX4095 +#define MT9P031_VERTICAL_BLANK 0x06 +#define
Re: Camera Support
On Tuesday 26 July 2011 21:43:38 Sakari Ailus wrote: On Wed, Jul 27, 2011 at 12:53:44AM +0530, Sriram V wrote: Hi, OMAP3 ISP Supports 2 camera ports (csi and parallel) Does the existing ISP drivers support both of them at the same time. As far as I can see, the answer is yes. However, the CCDC block implements the parallel receiver, so the image processing functions of the ISP wouldn't be available for the data received from the CSI(2) receiver when the parallel interface is in use. Don't the parallel and serial interfaces share some pins ? Please also note that serial receivers are not available on the OMAP35x/DM37xx. They're only available (at least according to TI) on the OMAP34xx/OMAP36xx. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 05/11] omap3isp: Use *_dec_not_zero instead of *_add_unless
atomic_dec_not_zero is defined for each architecture through
linux/atomic.h to provide the functionality of
atomic_add_unless(x, -1, 0).
Signed-off-by: Sven Eckelmann s...@narfation.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-media@vger.kernel.org
---
drivers/media/video/omap3isp/ispstat.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispstat.c
b/drivers/media/video/omap3isp/ispstat.c
index b44cb68..81b1ec9 100644
--- a/drivers/media/video/omap3isp/ispstat.c
+++ b/drivers/media/video/omap3isp/ispstat.c
@@ -652,7 +652,7 @@ static int isp_stat_buf_process(struct ispstat *stat, int
buf_state)
{
int ret = STAT_NO_BUF;
- if (!atomic_add_unless(stat-buf_err, -1, 0)
+ if (!atomic_dec_not_zero(stat-buf_err)
buf_state == STAT_BUF_DONE stat-state == ISPSTAT_ENABLED) {
ret = isp_stat_buf_queue(stat);
isp_stat_buf_next(stat);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Laurent, Thanks for the patch. I have a few comments below. On Wed, Jul 27, 2011 at 11:13:01AM +0200, Laurent Pinchart wrote: From: Javier Martin javier.mar...@vista-silicon.com The MT9P031 is a parallel 12-bit 5MP sensor from Aptina (formerly Micron) controlled through I2C. The driver creates a V4L2 subdevice. It currently supports skipping, cropping, automatic binning, and gain, exposure, h/v flip and test pattern controls. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9p031.c | 961 + include/media/mt9p031.h | 19 + 4 files changed, 988 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9p031.c create mode 100644 include/media/mt9p031.h Hi Javier, I've finally been able to spend some time on your MT9P031 driver, and here is the result. I would like to push the driver to mainline for v3.2. Could you please review it ? I still need to have a look at the PLL code to see if we can compute the PLL registers values at runtime instead of using a table-based approach. BTW, do you plan to maintain the driver ? diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 176ac49..81252ec 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -467,6 +467,13 @@ config VIDEO_OV7670 OV7670 VGA camera. It currently only works with the M88ALP01 controller. +config VIDEO_MT9P031 + tristate Aptina MT9P031 support + depends on I2C VIDEO_V4L2 + ---help--- + This is a Video4Linux2 sensor-level driver for the Aptina + (Micron) mt9p031 5 Mpixel camera. + config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 6cca52a..b9e9bb3 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c new file mode 100644 index 000..18e9a3c --- /dev/null +++ b/drivers/media/video/mt9p031.c @@ -0,0 +1,961 @@ +/* + * Driver for MT9P031 CMOS Image Sensor from Aptina + * + * Copyright (C) 2011, Laurent Pinchart laurent.pinch...@ideasonboard.com + * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com + * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de + * + * Based on the MT9V032 driver and Bastian Hecht's code. + * + * 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. + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h + +#include media/mt9p031.h +#include media/v4l2-chip-ident.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#define MT9P031_PIXEL_ARRAY_WIDTH2752 +#define MT9P031_PIXEL_ARRAY_HEIGHT 2004 + +#define MT9P031_CHIP_VERSION 0x00 +#define MT9P031_CHIP_VERSION_VALUE 0x1801 +#define MT9P031_ROW_START0x01 +#define MT9P031_ROW_START_MIN 0 +#define MT9P031_ROW_START_MAX 2004 +#define MT9P031_ROW_START_DEF 54 +#define MT9P031_COLUMN_START 0x02 +#define MT9P031_COLUMN_START_MIN0 +#define MT9P031_COLUMN_START_MAX2750 +#define MT9P031_COLUMN_START_DEF16 +#define MT9P031_WINDOW_HEIGHT0x03 +#define MT9P031_WINDOW_HEIGHT_MIN 2 +#define MT9P031_WINDOW_HEIGHT_MAX 2006 +#define MT9P031_WINDOW_HEIGHT_DEF 1944 +#define MT9P031_WINDOW_WIDTH 0x04 +#define MT9P031_WINDOW_WIDTH_MIN2 +#define MT9P031_WINDOW_WIDTH_MAX2752 +#define MT9P031_WINDOW_WIDTH_DEF2592 +#define MT9P031_HORIZONTAL_BLANK 0x05 +#define
RE: Parallel CMOS Image Sensor with UART Control Interface
Hi All, I want to say that in the beginning I encountered the same problem, but with the support of Laurent and other guys, today on my system OMAP3 ISP successfully passes registration. To my yet, I still cannot connect my video source because it's missing, but I successfully configure pipeline with use MC User space API. Regards, Alex Gershgorin -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, July 27, 2011 11:59 AM To: James Cc: Sakari Ailus; linux-media@vger.kernel.org; michael.jo...@matrix-vision.de; Alex Gershgorin Subject: Re: Parallel CMOS Image Sensor with UART Control Interface Hi James, On Wednesday 27 July 2011 07:41:59 James wrote: On Wed, Jul 27, 2011 at 3:40 AM, Sakari Ailus sakari.ai...@iki.fi wrote: On Mon, Jul 25, 2011 at 04:43:21PM +0800, James wrote: Dear all, Does anyone came across a v4l2 Linux Device Driver for an Image Sensor that uses Parallel CMOS H/V and can only be control by UART interface instead of the common I2C or SPI interface? A similar sensor is the STMicroelectronics VL5510 Image Sensor although it support all 3 types of control interface. (http://www.st.com/internet/automotive/product/178477.jsp) Most or all the drivers found I found under drivers/media/video uses the I2C or SPI interface instead I'm new to writing driver and need a reference v4l2 driver for this type of image sensor to work with OMAP3530 ISP port on Gumstix's Overo board. I just need a very simple v4l2 driver that can extract the image from the sensor and control over it via the UART control interface. Any help is very much appreciated. Hi James, I think there has been a recent discussion on a similar topic under the subject RE: FW: OMAP 3 ISP. The way to do this would be to implement platform subdevs in V4L2 core, which I think we don't have quite yet. Cc Laurent and Michael. Hi Sakari, Thanks for pointing me to the discussion thread. I found it from the archive at http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3270 0/focus=32721 I read through the threads and see that I'm indeed in similar situation with Alex. We both have sensor that output CMOS H/V image and only have UART/RS232 for control of the sensor operations via sending/reading packet of bytes. i.e. AGC, contrast, brightness etc.. Since the thread ended on 29-Jun, is there anymore update or information? As I've a MT9V032 camera with Gusmtix Overo, I was hoping to rely on the MT9V032 driver as a starting point and adapt it for the VL5510 sensor using only the UART interface. As a quick hack, to start with, you can still use an I2C subdev driver. Just remove all I2C-related code from the driver, and register a fake I2C device in board code. That will let you at least develop the driver and test the UART interface. -- Regards, Laurent Pinchart __ Information from ESET NOD32 Antivirus, version of virus signature database 6327 (20110726) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6328 (20110727) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Firmware extraction for IT9135 based devices
MvH
Benjamin Larsson
From b3cbee633f5a6403c2460892e64adcb88f6ae4a6 Mon Sep 17 00:00:00 2001
From: Benjamin Larsson benja...@southpole.se
Date: Wed, 27 Jul 2011 13:43:38 +0200
Subject: [PATCH 1/1] Firmware extraction for IT9135 based devices
Signed-off-by: Benjamin Larsson benja...@southpole.se
---
Documentation/dvb/get_dvb_firmware | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index c466f58..65ebe20 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -27,7 +27,8 @@ use IO::Handle;
or51211, or51132_qam, or51132_vsb, bluebird,
opera1, cx231xx, cx18, cx23885, pvrusb2, mpc718,
af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
- lme2510c_s7395_old, drxk, drxk_terratec_h5);
+ lme2510c_s7395_old, drxk, drxk_terratec_h5,
+it9135 );
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -665,6 +666,26 @@ sub drxk_terratec_h5 {
$fwfile
}
+sub it9135 {
+my $url = http://kworld.server261.com/kworld/CD/ITE_TiVme/V1.00/;;
+my $zipfile = Driver_V10.323.1.0412.100412.zip;
+my $hash = 79b597dc648698ed6820845c0c9d0d37;
+my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 0);
+my $drvfile = Driver_V10.323.1.0412.100412/Data/x86/IT9135BDA.sys;
+my $fwfile = dvb-usb-it9137-01.fw;
+
+checkstandard();
+
+wgetfile($zipfile, $url . $zipfile);
+verify($zipfile, $hash);
+unzip($zipfile, $tmpdir);
+extract($tmpdir/$drvfile, 69632, 5731, $fwfile);
+
+$fwfile
+}
+
+
+
# ---
# Utilities
--
1.7.1
Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Gueannadi, On 07/20/2011 10:43 AM, Guennadi Liakhovetski wrote: A possibility to preallocate and initialise buffers of different sizes in V4L2 is required for an efficient implementation of asnapshot mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF and defines respective data structures. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- It's been almost a month since v2, the only comments were a request to increase the reserved space in the new ioctl() and to improve documentation. The reserved field is increased in this version, documentation also has been improved in multiple locations. I think, documentation can be further improved at any time, but if there are no objections against the actual contents of this patch, maybe we can commit this version. I still don't see v3.0;-), so, maybe we even can push it for 3.1. A trivial comparison with v2 shows the size of the reserved field as the only change in the API, and the compatibility fix as the only two functional changes. v3: addressed multiple comments by Sakari Ailus 1. increased reserved field in struct v4l2_create_buffers to 8 32-bit ints 2. multiple documentation fixes and improvements 3. fixed misplaced case VIDIOC_PREPARE_BUF in ioctl 32-bit compatibility processing v2: 1. add preliminary Documentation 2. add flag V4L2_BUFFER_FLAG_NO_CACHE_CLEAN 3. remove VIDIOC_DESTROY_BUFS 4. rename SUBMIT to VIDIOC_PREPARE_BUF 5. add reserved field to struct v4l2_create_buffers 6. cache handling flags moved to struct v4l2_buffer for processing during VIDIOC_PREPARE_BUF 7. VIDIOC_PREPARE_BUF now uses struct v4l2_buffer as its argument Documentation/DocBook/media/v4l/io.xml | 17 +++ Documentation/DocBook/media/v4l/v4l2.xml |2 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 152 .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96 drivers/media/video/v4l2-compat-ioctl32.c | 68 - drivers/media/video/v4l2-ioctl.c | 32 include/linux/videodev2.h | 16 ++ include/media/v4l2-ioctl.h |2 + 8 files changed, 377 insertions(+), 8 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 227e7ac..6249d0e 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -927,6 +927,23 @@ ioctl is called./entry Applications set or clear this flag before calling the constantVIDIOC_QBUF/constant ioctl./entry /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry + entry0x0400/entry + entryCaches do not have to be invalidated for this buffer. +Typically applications shall use this flag, if the data, captured in the buffer +is not going to br touched by the CPU, instead the buffer will, probably, be +passed on to a DMA-capable hardware unit for further processing or output. +/entry + /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry + entry0x0800/entry + entryCaches do not have to be cleaned for this buffer. +Typically applications shall use this flag for output buffers, if the data +in this buffer has not been created by the CPU, but by some DMA-capable unit, +in which case caches have not been used./entry + /row /tbody /tgroup /table diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 0d05e87..06bb179 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -462,6 +462,7 @@ and discussions on the V4L mailing list./revremark sub-close; sub-ioctl; !-- All ioctls go here. -- +sub-create-bufs; sub-cropcap; sub-dbg-g-chip-ident; sub-dbg-g-register; @@ -504,6 +505,7 @@ and discussions on the V4L mailing list./revremark sub-queryctrl; sub-query-dv-preset; sub-querystd; +sub-prepare-buf; sub-reqbufs; sub-s-hw-freq-seek; sub-streamon; diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml new file mode 100644 index 000..5f0158c --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -0,0 +1,152 @@ +refentry id=vidioc-create-bufs + refmeta +refentrytitleioctl VIDIOC_CREATE_BUFS/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_CREATE_BUFS/refname +refpurposeCreate buffers for Memory Mapped or User Pointer I/O/refpurpose + /refnamediv + +
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Laurent, I really was looking forward to your patch. Tomorrow i have the day off, so I will look at this on Friday. I will review and test your patch and send you my comments. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB-T issues w/ kernel 3.0
Hello, I'm wondering, whether there are known issues with the new kernel version just b/c of https://forums.gentoo.org/viewtopic.php?p=6766690#6766690 and https://bugs.kde.org/show_bug.cgi?id=278561 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- 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 v3] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
Hi Alina,
Em 22-07-2011 15:35, Alina Friedrichsen escreveu:
Since many, many kernel releases my Hauppauge WinTV HVR-1400 doesn't work
anymore, and nobody feels responsible to fix it.
No. The problem is that fixing it would require someone to travel around the
globe with several different boards, in order to see how the driver works on
each Country (or having a DTV generator capable of simulating the Country
differences on a reliable way). In particular, Australia requires a different
setting than Europe. The code tries to figure out that, but I'm starting to
suspect that with a few demods, such adjustments are different.
Btw, what's the video standard that you're using? DTV7? Does your device use
a xc3028 or xc3028xl? Whats's your demod and board?
The code to get it work is still in there, it's only commented out.
My patch to enable it was rejected, because somebody had fear that it could
break other cards.
So here is a new patch, that allows you to select the frequency adjustment
code by a module parameter. Default is the old code, so it can't break
anything.
Signed-off-by: Alina Friedrichsen x-al...@gmx.net
---
diff -urN linux-3.0.orig/drivers/media/common/tuners/tuner-xc2028.c
linux-3.0/drivers/media/common/tuners/tuner-xc2028.c
--- linux-3.0.orig/drivers/media/common/tuners/tuner-xc2028.c 2011-07-22
04:17:23.0 +0200
+++ linux-3.0/drivers/media/common/tuners/tuner-xc2028.c 2011-07-22
20:15:08.212540252 +0200
@@ -54,6 +54,11 @@
MODULE_PARM_DESC(firmware_name, Firmware file name. Allows overriding the
default firmware name\n);
+static int freq_magic;
+module_param(freq_magic, int, 0644);
+MODULE_PARM_DESC(freq_magic, Selects the frequency adjustment code
+ for XC3028. Set it to 1 if tuning fails.);
While I really prefer to fix the code, I might accept a hack like that, if
better named, and properly described. It is more like an alternate way
to set the tuner, and for sure it won't solve all cases where the tuning
fails.
AFAIK, the driver only has problem with DTV7. So, the hack should not be applied
for other standards.
+
static LIST_HEAD(hybrid_tuner_instance_list);
static DEFINE_MUTEX(xc2028_list_mutex);
@@ -967,34 +972,36 @@
* newer firmwares
*/
-#if 1
- /*
- * The proper adjustment would be to do it at s-code table.
- * However, this didn't work, as reported by
- * Robert Lowery rglow...@exemail.com.au
- */
-
- if (priv-cur_fw.type DTV7)
- offset += 50;
-
-#else
- /*
- * Still need tests for XC3028L (firmware 3.2 or upper)
- * So, for now, let's just comment the per-firmware
- * version of this change. Reports with xc3028l working
- * with and without the lines bellow are welcome
- */
+ if (!freq_magic) {
+ /*
+ * The proper adjustment would be to do it at s-code
+ * table. However, this didn't work, as reported by
+ * Robert Lowery rglow...@exemail.com.au
+ */
- if (priv-firm_version 0x0302) {
if (priv-cur_fw.type DTV7)
offset += 50;
+
} else {
- if (priv-cur_fw.type DTV7)
- offset -= 30;
- else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8
*/
- offset += 20;
+ /*
+ * Still need tests for XC3028L (firmware 3.2 or upper)
+ * So, for now, let's just comment the per-firmware
+ * version of this change. Reports with xc3028l working
+ * with and without the lines bellow are welcome
+ */
+
+ if (priv-firm_version 0x0302) {
+ if (priv-cur_fw.type DTV7)
+ offset += 50;
+ } else {
+ if (priv-cur_fw.type DTV7)
+ offset -= 30;
+ else if (type != ATSC) {
+ /* DVB @6MHz, DTV 8 and DTV 7/8 */
+ offset += 20;
+ }
+ }
}
-#endif
}
div = (freq - offset + DIV / 2) / DIV;
--
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
Re: DVB-T issues w/ kernel 3.0
2011/7/27 Toralf Förster toralf.foers...@gmx.de: Hello, I'm wondering, whether there are known issues with the new kernel version just b/c of https://forums.gentoo.org/viewtopic.php?p=6766690#6766690 and https://bugs.kde.org/show_bug.cgi?id=278561 Hello Toralf, I don't think you're the first person to report this issue. That said, I don't think any developers have seen it, so it would be a very useful exercise if you could bisect the kernel and figure out which patch introduced the problem. Once we know what patch introduced the problem we will have a much better idea what action needs to be taken to address it. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-T issues w/ kernel 3.0
Le mercredi 27 juillet 2011 17:30:50 Toralf Förster, vous avez écrit : Hello, I'm wondering, whether there are known issues with the new kernel version just b/c of https://forums.gentoo.org/viewtopic.php?p=6766690#6766690 and https://bugs.kde.org/show_bug.cgi?id=278561 On a tangential note, what actual version is VLC there? VLC 1.2.0 git DVB plugin is a complete rewrite from VLC 1.1.x, using Linux DVBv5 (the so called S2API)... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: DVB-T issues w/ kernel 3.0
Am 27. Juli 2011 16:37 schrieb Devin Heitmueller dheitmuel...@kernellabs.com: 2011/7/27 Toralf Förster toralf.foers...@gmx.de: Hello, I'm wondering, whether there are known issues with the new kernel version just b/c of https://forums.gentoo.org/viewtopic.php?p=6766690#6766690 and https://bugs.kde.org/show_bug.cgi?id=278561 Hello Toralf, I don't think you're the first person to report this issue. That said, I don't think any developers have seen it, so it would be a very useful exercise if you could bisect the kernel and figure out which patch introduced the problem. Once we know what patch introduced the problem we will have a much better idea what action needs to be taken to address it. It's about dib0700 driver also reported here: http://www.spinics.net/lists/linux-media/msg35763.html few days ago. Quote: The drivers from 2011-02-05 does not run, but the drivers from 2010-10-16 runs perfectly. should give at least a startingpoint/timeframe for bisecting ... allthough would be more usefull if based linuxtv git. -- 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 v3] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
On Wed, Jul 27, 2011 at 10:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Btw, what's the video standard that you're using? DTV7? Does your device use a xc3028 or xc3028xl? Whats's your demod and board? It was in the first sentence of his email. He's got an HVR-1400, which uses the xc3028L and dib7000p. It's also worth noting that he isn't the first person to complain about tuning offset problems with the xc3028L. Just look at the rather nasty hack some random user did for the EVGA inDtube (which is xc3208L/s5h1409). http://linuxtv.org/wiki/index.php/EVGA_inDtube Bear in mind that it worked when I added the original support. Somebody caused a regression since then though. In short, I can appreciate why the user is frustrated. The xc3028L support worked at one point and then somebody broke the xc3028 driver. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-T issues w/ kernel 3.0
On Wed, Jul 27, 2011 at 10:57 AM, Steffen Barszus steffenbpu...@googlemail.com wrote: Quote: The drivers from 2011-02-05 does not run, but the drivers from 2010-10-16 runs perfectly. should give at least a startingpoint/timeframe for bisecting ... allthough would be more usefull if based linuxtv git. Bear in mind the user was using the s2-liplianin branch and *not* the mainline linux_media tree. Hence anybody who does a bisect should be sure the starting/ending points are accurate. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [resend] usbvision: disable scaling for Nogatech MicroCam
Em 22-07-2011 18:44, Ondrej Zary escreveu: On Friday 22 July 2011 23:31:46 Devin Heitmueller wrote: On Fri, Jul 22, 2011 at 5:22 PM, Ondrej Zary li...@rainbow-software.org wrote: Seems that this bug is widespread - the same problem appears also in guvcview and adobe flash. I think that the driver is broken too - it should return corrected resolution in TRY_FMT. Well, if the driver does not return the resolution it is actually capturing in, then that indeed is a driver bug. That's a different issue though than what your patch proposed. You should make the TRY_FMT call specifying an invalid resolution and see if it returns the real resolution the device will capture at. If it doesn't, then fix *that* bug. It does not, there's no code that would do that. I actually fixed that only to find out that the scaling is unusable at least with the MicroCam because of black horizontal lines that appear in the image (amount of the lines depend on the scaling factor). So I just disabled the scaling completely for MicroCam. I also don't know if the multiple-of-64 width limit is valid for all usbvision devices - that's why I haven't posted patch to fix this. The application needs to know the capturing resolution, so it's possible that it does properly handle the driver passing back the real resolution and the driver is at fault, in which case no change is needed to the app at all. Well, for sure you don't need to touch at s_fmt, as it calls try_fmt. Also, if the problem is that the scaler requrires that the vertical resolution to be multiple of some limit, a patch like the one bellow would do a better job: diff --git a/drivers/media/video/usbvision/usbvision-video.c b/drivers/media/video/usbvision/usbvision-video.c index 5a74f5e..6907eff 100644 --- a/drivers/media/video/usbvision/usbvision-video.c +++ b/drivers/media/video/usbvision/usbvision-video.c @@ -922,6 +922,9 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv, RESTRICT_TO_RANGE(vf-fmt.pix.width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH); RESTRICT_TO_RANGE(vf-fmt.pix.height, MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT); + /* FIXME: please correct the minimum resolution here */ + vf-fmt.pix.width = ~0x01; + vf-fmt.pix.bytesperline = vf-fmt.pix.width* usbvision-palette.bytes_per_pixel; vf-fmt.pix.sizeimage = vf-fmt.pix.bytesperline*vf-fmt.pix.height; Some scalers require an even vertical resolution. So, you'll need to adjust the above, according with the restrictions you may have on the scaler your webcam has. Btw, V4L2 core defines a macro for such type of adjustments. For example, em28xx uses it as: /* width must even because of the YUYV format height must be even because of interlacing */ v4l_bound_align_image(width, 48, maxw, 1, height, 32, maxh, 1, 0); ( So, a better fix would be to remove the RESTRICT_TO_RANGE() calls, and use the v4l_bound_align_image() macro instead, filled with the needed restrictions, like: v4l_bound_align_image(width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH, 1, height, MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT, 0); - [usbvision] Fix width/height scaling limits It assumes that both just width is required to be even number. NOT TESTED. Signed-of-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/usbvision/usbvision-video.c b/drivers/media/video/usbvision/usbvision-video.c index 5a74f5e..41d3b47 100644 --- a/drivers/media/video/usbvision/usbvision-video.c +++ b/drivers/media/video/usbvision/usbvision-video.c @@ -919,8 +919,11 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv, /* robustness */ if (format_idx == USBVISION_SUPPORTED_PALETTES) return -EINVAL; - RESTRICT_TO_RANGE(vf-fmt.pix.width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH); - RESTRICT_TO_RANGE(vf-fmt.pix.height, MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT); + + v4l_bound_align_image(vf-fmt.pix.width, + MIN_FRAME_WIDTH, MAX_FRAME_WIDTH, 1, + vf-fmt.pix.height, + MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT, 0, 0); vf-fmt.pix.bytesperline = vf-fmt.pix.width* usbvision-palette.bytes_per_pixel; -- 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 v3] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
Em 27-07-2011 11:58, Devin Heitmueller escreveu:
On Wed, Jul 27, 2011 at 10:34 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Btw, what's the video standard that you're using? DTV7? Does your device use
a xc3028 or xc3028xl? Whats's your demod and board?
It was in the first sentence of his email. He's got an HVR-1400,
which uses the xc3028L and dib7000p.
Hmm...
case CX23885_BOARD_HAUPPAUGE_HVR1400:
i2c_bus = dev-i2c_bus[0];
fe0-dvb.frontend = dvb_attach(dib7000p_attach,
i2c_bus-i2c_adap,
0x12, hauppauge_hvr1400_dib7000_config);
if (fe0-dvb.frontend != NULL) {
struct dvb_frontend *fe;
struct xc2028_config cfg = {
.i2c_adap = dev-i2c_bus[1].i2c_adap,
.i2c_addr = 0x64,
};
static struct xc2028_ctrl ctl = {
.fname = XC3028L_DEFAULT_FIRMWARE,
.max_len = 64,
.demod = 5000,
/* This is true for all demods with
v36 firmware? */
.type= XC2028_D2633,
};
The entry for xc2028 there seems to be wrong! it is specifying a magic value for
.demod, instead of using one of the defined values for it.
On a quick look, this seems to be the only case where the macro is not used:
$ grep -E demod\s+\= `find drivers/media/ -type f`
drivers/media/video/cx231xx/cx231xx-cards.c:.demod = 0;
drivers/media/video/cx23885/cx23885-dvb.c: .demod
= XC3028_FE_OREN538,
drivers/media/video/cx23885/cx23885-dvb.c: .demod
= 5000,
drivers/media/video/cx23885/cx23885-dvb.c: .demod
= XC3028_FE_ZARLINK456,
drivers/media/video/cx23885/cx23885-dvb.c: .demod
= XC3028_FE_ZARLINK456,
drivers/media/video/cx88/cx88-cards.c: ctl-demod =
XC3028_FE_ZARLINK456;
drivers/media/video/cx88/cx88-cards.c: ctl-demod = XC3028_FE_OREN538;
drivers/media/video/cx88/cx88-cards.c: ctl-demod =
XC3028_FE_ZARLINK456;
drivers/media/video/cx88/cx88-cards.c: ctl-demod = XC3028_FE_OREN538;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_ZARLINK456;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_ZARLINK456;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_DEFAULT;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_DEFAULT;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_DEFAULT;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_CHINA;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_CHINA;
drivers/media/video/em28xx/em28xx-cards.c: ctl-demod =
XC3028_FE_OREN538;
drivers/media/video/cx18/cx18-dvb.c:.demod =
XC3028_FE_ZARLINK456,
drivers/media/video/cx18/cx18-dvb.c:.demod =
XC3028_FE_ZARLINK456,
drivers/media/video/cx18/cx18-dvb.c:.demod =
XC3028_FE_ZARLINK456,
drivers/media/video/saa7134/saa7134-cards.c:ctl.demod =
XC3028_FE_ZARLINK456;
drivers/media/video/saa7134/saa7134-cards.c:ctl.demod =
XC3028_FE_OREN538;
drivers/media/dvb/dvb-usb/cxusb.c: .demod =
XC3028_FE_ZARLINK456,
drivers/media/dvb/dvb-usb/dib0700_devices.c:.demod = XC3028_FE_DIBCOM52,
(non-relevant results removed)
In the specific case of this device, it should be using this macro:
#define XC3028_FE_DIBCOM52 5200
As it uses a Dibcom firmware. The logic inside tuner-xc2028 assumes that
those macros are used.
It's also worth noting that he isn't the first person to complain
about tuning offset problems with the xc3028L. Just look at the
rather nasty hack some random user did for the EVGA inDtube (which is
xc3208L/s5h1409).
As some drivers are properly using the macros while others aren't that
explains why when someone fixes xc3028 for a device, it breaks support
for other devices.
We should make sure that all devices will use the proper macros, and then
look into a fix for the logic.
http://linuxtv.org/wiki/index.php/EVGA_inDtube
Bear in mind that it worked when I added the original support.
Somebody caused a regression since then though.
In short, I can appreciate why the user is frustrated. The xc3028L
support worked at one point and then somebody broke the xc3028 driver.
Devin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH v3] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
Em 27-07-2011 11:58, Devin Heitmueller escreveu: On Wed, Jul 27, 2011 at 10:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Btw, what's the video standard that you're using? DTV7? Does your device use a xc3028 or xc3028xl? Whats's your demod and board? It was in the first sentence of his email. He's got an HVR-1400, which uses the xc3028L and dib7000p. It's also worth noting that he isn't the first person to complain about tuning offset problems with the xc3028L. Just look at the rather nasty hack some random user did for the EVGA inDtube (which is xc3208L/s5h1409). http://linuxtv.org/wiki/index.php/EVGA_inDtube Bear in mind that it worked when I added the original support. Somebody caused a regression since then though. In short, I can appreciate why the user is frustrated. The xc3028L support worked at one point and then somebody broke the xc3028 driver. Devin Btw, looking at the firmware for xc3028L [1], with the v4l-utils /utils/xc3028-firmware/firmware-tool: [1] http://steventoth.net/linux/hvr1400/xc3028L-v36.fw firmware file name: /lib/firmware/xc3028L-v36.fw firmware name: xc2028 firmware version:3.6 (774) standards: 81 Firmware 0, type: BASE FW F8MHZ (0x0003), id: (), size: 9144 Firmware 1, type: BASE FW F8MHZ MTS (0x0007), id: (), size: 9030 Firmware 2, type: BASE FW FM (0x0401), id: (), size: 9054 Firmware 3, type: BASE FW FM INPUT1 (0x0c01), id: (), size: 9068 Firmware 4, type: BASE FW (0x0001), id: (), size: 9132 Firmware 5, type: BASE FW MTS (0x0005), id: (), size: 9006 Firmware 6, type: STD FW(0x), id: PAL/BG (0007), size: 161 Firmware 7, type: STD FWMTS (0x0004), id: PAL/BG (0007), size: 169 Firmware 8, type: STD FW(0x), id: PAL/BG (0007), size: 161 Firmware 9, type: STD FWMTS (0x0004), id: PAL/BG (0007), size: 169 Firmware 10, type: STD FW(0x), id: PAL/BG (0007), size: 161 Firmware 11, type: STD FWMTS (0x0004), id: PAL/BG (0007), size: 169 Firmware 12, type: STD FW(0x), id: PAL/BG (0007), size: 161 Firmware 13, type: STD FWMTS (0x0004), id: PAL/BG (0007), size: 169 Firmware 14, type: STD FW(0x), id: PAL/DK (00e0), size: 161 Firmware 15, type: STD FWMTS (0x0004), id: PAL/DK (00e0), size: 169 Firmware 16, type: STD FW(0x), id: PAL/DK (00e0), size: 161 Firmware 17, type: STD FWMTS (0x0004), id: PAL/DK (00e0), size: 169 Firmware 18, type: STD FW(0x), id: SECAM/K1 (0020), size: 161 Firmware 19, type: STD FWMTS (0x0004), id: SECAM/K1 (0020), size: 169 Firmware 20, type: STD FW(0x), id: SECAM/K3 (0400), size: 161 Firmware 21, type: STD FWMTS (0x0004), id: SECAM/K3 (0400), size: 169 Firmware 22, type: STD FWD2633 DTV6 ATSC (0x00010030), id: (), size: 149 Firmware 23, type: STD FWD2620 DTV6 QAM (0x0068), id: (), size: 149 Firmware 24, type: STD FWD2633 DTV6 QAM (0x0070), id: (), size: 149 Firmware 25, type: STD FWD2620 DTV7 (0x0088), id: (), size: 149 Firmware 26, type: STD FWD2633 DTV7 (0x0090), id: (), size: 149 Firmware 27, type: STD FWD2620 DTV78 (0x0108), id: (), size: 149 Firmware 28, type: STD FWD2633 DTV78 (0x0110), id: (), size: 149 Firmware 29, type: STD FWD2620 DTV8 (0x0208), id: (), size: 149 Firmware 30, type: STD FWD2633 DTV8 (0x0210), id: (), size: 149 Firmware 31, type: STD FWFM (0x0400), id: (), size: 135 Firmware 32, type: STD FW(0x), id: PAL/I (0010), size: 161 Firmware 33, type: STD FWMTS (0x0004), id: PAL/I (0010), size: 169 Firmware 34, type: STD FW(0x), id: SECAM/L (0040), size: 161 Firmware 35, type: STD FW(0x), id: SECAM/Lc (0080), size: 161 Firmware 36, type: STD FW(0x), id: NTSC/M Kr (8000), size: 161 Firmware 37, type: STD FWLCD (0x1000), id: NTSC/M Kr (8000), size: 161 Firmware 38, type: STD FWLCD NOGD (0x3000), id: NTSC/M Kr (8000), size: 161 Firmware 39, type: STD FWMTS (0x0004), id: NTSC/M Kr (8000), size: 169 Firmware 40, type: STD FW(0x), id: NTSC PAL/M PAL/N (b700), size: 161 Firmware 41, type: STD FWLCD (0x1000), id: NTSC PAL/M PAL/N (b700), size: 161 Firmware 42, type: STD FWLCD NOGD (0x3000), id: NTSC PAL/M PAL/N
[GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, The following changes since commit f0a21151140da01c71de636f482f2eddec2840cc: Merge tag 'v3.0' into staging/for_v3.1 (2011-07-22 13:33:14 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung fimc-for-mauro Sylwester Nawrocki (28): s5p-fimc: Add support for runtime PM in the mem-to-mem driver s5p-fimc: Add media entity initialization s5p-fimc: Remove registration of video nodes from probe() s5p-fimc: Remove sclk_cam clock handling s5p-fimc: Limit number of available inputs to one s5p-fimc: Remove sensor management code from FIMC capture driver s5p-fimc: Remove v4l2_device from video capture and m2m driver s5p-fimc: Add the media device driver s5p-fimc: Conversion to use struct v4l2_fh s5p-fimc: Conversion to the control framework s5p-fimc: Add media operations in the capture entity driver s5p-fimc: Add PM helper function for streaming control s5p-fimc: Correct color format enumeration s5p-fimc: Convert to use media pipeline operations s5p-fimc: Add subdev for the FIMC processing block s5p-fimc: Add support for camera capture in JPEG format s5p-fimc: Add v4l2_device notification support for single frame capture s5p-fimc: Use consistent names for the buffer list functions s5p-fimc: Add runtime PM support in the camera capture driver s5p-fimc: Correct crop offset alignment on exynos4 s5p-fimc: Remove single-planar capability flags noon010pc30: Do not ignore errors in initial controls setup noon010pc30: Convert to the pad level ops noon010pc30: Clean up the s_power callback noon010pc30: Remove g_chip_ident operation handler s5p-csis: Handle all available power supplies s5p-csis: Rework of the system suspend/resume helpers s5p-csis: Enable v4l subdev device node drivers/media/video/Kconfig |4 +- drivers/media/video/noon010pc30.c | 173 ++-- drivers/media/video/s5p-fimc/Makefile |2 +- drivers/media/video/s5p-fimc/fimc-capture.c | 1424 +++ drivers/media/video/s5p-fimc/fimc-core.c| 1119 +++-- drivers/media/video/s5p-fimc/fimc-core.h| 222 +++-- drivers/media/video/s5p-fimc/fimc-mdevice.c | 859 drivers/media/video/s5p-fimc/fimc-mdevice.h | 118 +++ drivers/media/video/s5p-fimc/fimc-reg.c | 76 +- drivers/media/video/s5p-fimc/mipi-csis.c| 84 +- drivers/media/video/s5p-fimc/regs-fimc.h|8 +- include/media/s5p_fimc.h| 11 + include/media/v4l2-chip-ident.h |3 - 13 files changed, 2921 insertions(+), 1182 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.c create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.h -- Regards, Sylwester Nawrocki Samsung Poland RD Center -- 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] [resend] usbvision: disable scaling for Nogatech MicroCam
Offtopic. Mauro is your pull request ready ? the merge window is open. -- 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] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Laurent, Javier,
On 07/27/2011 11:13 AM, Laurent Pinchart wrote:
From: Javier Martinjavier.mar...@vista-silicon.com
The MT9P031 is a parallel 12-bit 5MP sensor from Aptina (formerly
Micron) controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports skipping,
cropping, automatic binning, and gain, exposure, h/v flip and test
pattern controls.
Signed-off-by: Javier Martinjavier.mar...@vista-silicon.com
Signed-off-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 961
+
include/media/mt9p031.h | 19 +
4 files changed, 988 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
Hi Javier,
I've finally been able to spend some time on your MT9P031 driver, and here is
the result. I would like to push the driver to mainline for v3.2. Could you
please review it ?
I still need to have a look at the PLL code to see if we can compute the PLL
registers values at runtime instead of using a table-based approach.
BTW, do you plan to maintain the driver ?
...
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..18e9a3c
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,961 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Laurent Pinchartlaurent.pinch...@ideasonboard.com
+ * Copyright (C) 2011, Javier Martinjavier.mar...@vista-silicon.com
+ * Copyright (C) 2011, Guennadi Liakhovetskig.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * 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.
+ */
+
...
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect crop; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct v4l2_ctrl_handler ctrls;
+ struct mt9p031_platform_data *pdata;
+ struct mutex power_lock; /* lock to protect power_count */
+ int power_count;
+ u16 xskip;
+ u16 yskip;
+ u32 ext_freq;
+ /* pll dividers */
+ u8 m;
+ u8 n;
+ u8 p1;
+
+ /* Registers cache */
+ u16 output_control;
+ u16 mode2;
+};
...
+/*
-
+ * Driver initialization and probing
+ */
+
+static int mt9p031_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
+{
+ struct mt9p031_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ struct mt9p031 *mt9p031;
+ unsigned int i;
+ int ret;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
+ dev_warn(adapter-dev,
+ I2C-Adapter doesn't support I2C_FUNC_SMBUS_WORD\n);
+ return -EIO;
+ }
+
+ mt9p031 = kzalloc(sizeof(*mt9p031), GFP_KERNEL);
+ if (mt9p031 == NULL)
+ return -ENOMEM;
+
+ mt9p031-pdata = pdata;
+ mt9p031-output_control = MT9P031_OUTPUT_CONTROL_DEF;
+ mt9p031-mode2 = MT9P031_READ_MODE_2_ROW_BLC;
+
+ v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 4);
+
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_EXPOSURE, MT9P031_SHUTTER_WIDTH_MIN,
+ MT9P031_SHUTTER_WIDTH_MAX, 1,
+ MT9P031_SHUTTER_WIDTH_DEF);
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_GAIN, MT9P031_GLOBAL_GAIN_MIN,
+ MT9P031_GLOBAL_GAIN_MAX, 1, MT9P031_GLOBAL_GAIN_DEF);
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_HFLIP, 0, 1, 1, 0);
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_VFLIP, 0, 1, 1, 0);
+
+ for (i = 0; i ARRAY_SIZE(mt9p031_ctrls); ++i)
+ v4l2_ctrl_new_custom(mt9p031-ctrls,mt9p031_ctrls[i], NULL);
+
+ mt9p031-subdev.ctrl_handler =mt9p031-ctrls;
+
+ if (mt9p031-ctrls.error)
+ printk(KERN_INFO %s: control initialization error %d\n,
+__func__, mt9p031-ctrls.error);
+
+ mutex_init(mt9p031-power_lock);
+ v4l2_i2c_subdev_init(mt9p031-subdev, client,mt9p031_subdev_ops);
+ mt9p031-subdev.internal_ops =mt9p031_subdev_internal_ops;
+
+ mt9p031-pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_init(mt9p031-subdev.entity, 1,mt9p031-pad, 0);
+ if (ret 0)
+ goto done;
+
+
[dvbscan] missing LNB type
Hi. I want to share experience in the field of using linuxtv-dvb-utils.
Dvbscan (that is scan.s from source tarball) has following LNB
parameters hardcoded:
static struct lnb_types_st lnbs[] = {
{UNIVERSAL, univ_desc, 9750, 10600, 11700 },
{DBS, dbs_desc, 11250, 0, 0 },
{STANDARD,standard_desc, 1, 0, 0 },
{ENHANCED,enhan_desc, 9750, 0, 0 },
{C-BAND, cband_desc, 5150, 0, 0 }
};
I wonder if these parameters are well-known standards and is it ok to
hide them from user. I think it is not.
We have a situation with our local providers (Moscow, Russia) like
TriColor or NTV+. It seems, they assume different frequency values for
'UIVERSAL' LNBs when broadcast network Information. Correct high_val
value is 10750, so whole lnb_type entry should be
{UNIVERSAL2, univ_desc, 9750, 10750, 11700 }
I am not an expert in other software of this kind and will be happy to
know how others solve this problem. Meanwhile I've wrote another
utility to tune up my qpsk frontend, its name is tuneqpsk. Whole
project is located at github [1] - it is part of our company's board
support package.
Thanks, Sergey
PS. I am not in list, please CC me directly.
[1] - https://github.com/ierton/libmdemux
--
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] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Sakari,
On Wednesday 27 July 2011 12:13:05 Sakari Ailus wrote:
Hi Laurent,
Thanks for the patch. I have a few comments below.
Thanks for the review. Please see my answers to your comments below. Javier,
there's one question for you as well.
On Wed, Jul 27, 2011 at 11:13:01AM +0200, Laurent Pinchart wrote:
[snip]
+static struct mt9p031 *to_mt9p031(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct mt9p031, subdev);
+}
+
+static int mt9p031_read(struct i2c_client *client, u8 reg)
+{
+ s32 data = i2c_smbus_read_word_data(client, reg);
+ return data 0 ? data : swab16(data);
Why swab16, and not e.g. be16_to_cpu?
No reason. I'll fix that.
+}
+
+static int mt9p031_write(struct i2c_client *client, u8 reg, u16 data)
+{
+ return i2c_smbus_write_word_data(client, reg, swab16(data));
Same here.
+}
[snip]
+/*
+ * This static table uses ext_freq and vdd_io values to select suitable
+ * PLL dividers m, n and p1 which have been calculated as specifiec in
p36 + * of Aptina's mt9p031 datasheet. New values should be added here.
+ */
+static const struct mt9p031_pll_divs mt9p031_divs[] = {
+ /* ext_freq target_freq m n p1 */
+ {2100, 4800, 26, 2, 6}
Can the divisors be calculated dynamically?
The external clock frequency, target_freq (pixel clock, I assume!) are
typically highly board dependent.
Probably. That's on my TODO list.
+};
+
+static int mt9p031_pll_get_divs(struct mt9p031 *mt9p031)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(mt9p031_divs); i++) {
+ if (mt9p031_divs[i].ext_freq == mt9p031-pdata-ext_freq
+ mt9p031_divs[i].target_freq == mt9p031-pdata-target_freq) {
+ mt9p031-ext_freq = mt9p031_divs[i].ext_freq;
+ mt9p031-m = mt9p031_divs[i].m;
+ mt9p031-n = mt9p031_divs[i].n;
+ mt9p031-p1 = mt9p031_divs[i].p1;
What about a pointer to the array instead of copying the values?
Sounds good to me.
+ return 0;
+ }
+ }
+
+ dev_err(client-dev, Couldn't find PLL dividers for ext_freq = %d,
+ target_freq = %d\n, mt9p031-pdata-ext_freq,
+ mt9p031-pdata-target_freq);
+ return -EINVAL;
+}
+
+static int mt9p031_pll_enable(struct mt9p031 *mt9p031)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
+ int ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON);
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_1,
+ (mt9p031-m 8) | (mt9p031-n - 1));
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_2, mt9p031-p1 - 1);
+ if (ret 0)
+ return ret;
+
+ mdelay(1);
mdelay() is a busyloop. Either msleep(), if the timing isn't critical, and
if it is, then usleep_range().
Timing isn't critical, but that's a stream-on delay, so I'll use
usleep_range().
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON |
+ MT9P031_PLL_CONTROL_USEPLL);
+ mdelay(1);
Javier, is this second mdelay() needed ?
+ return ret;
+}
+
+static inline int mt9p031_pll_disable(struct mt9p031 *mt9p031)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
+
+ return mt9p031_write(client, MT9P031_PLL_CONTROL,
+MT9P031_PLL_CONTROL_PWROFF);
+}
+
+static int mt9p031_power_on(struct mt9p031 *mt9p031)
+{
+ /* Ensure RESET_BAR is low */
+ if (mt9p031-pdata-reset) {
+ mt9p031-pdata-reset(mt9p031-subdev, 1);
+ msleep(1);
msleep(1) may take considerably longer than 1 ms, depending on the system
clock. You might want to use usleep_range() here.
Good point.
+ }
+
+ /* Emable clock */
+ if (mt9p031-pdata-set_xclk)
+ mt9p031-pdata-set_xclk(mt9p031-subdev,
+mt9p031-pdata-ext_freq);
+
+ /* Now RESET_BAR must be high */
+ if (mt9p031-pdata-reset) {
+ mt9p031-pdata-reset(mt9p031-subdev, 0);
+ msleep(1);
+ }
+
+ return 0;
+}
[snip]
+static int mt9p031_set_params(struct mt9p031 *mt9p031)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
+ struct v4l2_mbus_framefmt *format = mt9p031-format;
+ const struct v4l2_rect *crop = mt9p031-crop;
+ unsigned int hblank;
+ unsigned int vblank;
+ unsigned int xskip;
+ unsigned int yskip;
+ unsigned int xbin;
+ unsigned int ybin;
+ int ret;
+
+ /* Windows position and size.
+*
+* TODO: Make sure the start coordinates
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Sylwester,
Thanks for the review.
On Wednesday 27 July 2011 19:34:36 Sylwester Nawrocki wrote:
On 07/27/2011 11:13 AM, Laurent Pinchart wrote:
[snip]
+static int mt9p031_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
+{
+ struct mt9p031_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ struct mt9p031 *mt9p031;
+ unsigned int i;
+ int ret;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
+ dev_warn(adapter-dev,
+ I2C-Adapter doesn't support I2C_FUNC_SMBUS_WORD\n);
+ return -EIO;
+ }
+
+ mt9p031 = kzalloc(sizeof(*mt9p031), GFP_KERNEL);
+ if (mt9p031 == NULL)
+ return -ENOMEM;
+
+ mt9p031-pdata = pdata;
+ mt9p031-output_control = MT9P031_OUTPUT_CONTROL_DEF;
+ mt9p031-mode2 = MT9P031_READ_MODE_2_ROW_BLC;
+
+ v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 4);
+
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_EXPOSURE, MT9P031_SHUTTER_WIDTH_MIN,
+ MT9P031_SHUTTER_WIDTH_MAX, 1,
+ MT9P031_SHUTTER_WIDTH_DEF);
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_GAIN, MT9P031_GLOBAL_GAIN_MIN,
+ MT9P031_GLOBAL_GAIN_MAX, 1, MT9P031_GLOBAL_GAIN_DEF);
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_HFLIP, 0, 1, 1, 0);
+ v4l2_ctrl_new_std(mt9p031-ctrls,mt9p031_ctrl_ops,
+ V4L2_CID_VFLIP, 0, 1, 1, 0);
+
+ for (i = 0; i ARRAY_SIZE(mt9p031_ctrls); ++i)
+ v4l2_ctrl_new_custom(mt9p031-ctrls,mt9p031_ctrls[i], NULL);
+
+ mt9p031-subdev.ctrl_handler =mt9p031-ctrls;
+
+ if (mt9p031-ctrls.error)
+ printk(KERN_INFO %s: control initialization error %d\n,
+ __func__, mt9p031-ctrls.error);
+
+ mutex_init(mt9p031-power_lock);
+ v4l2_i2c_subdev_init(mt9p031-subdev, client,mt9p031_subdev_ops);
+ mt9p031-subdev.internal_ops =mt9p031_subdev_internal_ops;
+
+ mt9p031-pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_init(mt9p031-subdev.entity, 1,mt9p031-pad, 0);
+ if (ret 0)
+ goto done;
+
+ mt9p031-subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+ mt9p031-crop.width = MT9P031_WINDOW_WIDTH_DEF;
+ mt9p031-crop.height = MT9P031_WINDOW_HEIGHT_DEF;
+ mt9p031-crop.left = MT9P031_COLUMN_START_DEF;
+ mt9p031-crop.top = MT9P031_ROW_START_DEF;
+
+ if (mt9p031-pdata-version == MT9P031_MONOCHROME_VERSION)
+ mt9p031-format.code = V4L2_MBUS_FMT_Y12_1X12;
+ else
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG12_1X12;
+
+ mt9p031-format.width = MT9P031_WINDOW_WIDTH_DEF;
+ mt9p031-format.height = MT9P031_WINDOW_HEIGHT_DEF;
+ mt9p031-format.field = V4L2_FIELD_NONE;
+ mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB;
+
+ ret = mt9p031_pll_get_divs(mt9p031);
+
+done:
+ if (ret 0)
It seems there is a v4l2_ctrl_handler_free() missing here...
Good catch. I'll fix that (and the next one as well), and add a
media_entity_cleanup() here as well.
+ kfree(mt9p031);
+
+ return ret;
+}
+
+static int mt9p031_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *subdev = i2c_get_clientdata(client);
+ struct mt9p031 *mt9p031 = to_mt9p031(subdev);
+
+ v4l2_device_unregister_subdev(subdev);
+ media_entity_cleanup(subdev-entity);
... and here.
+ kfree(mt9p031);
+
+ return 0;
+}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.1] v4l-dvb: add and use poll_requested_events() function
Em 17-07-2011 08:19, Hans Verkuil escreveu:
Hi Mauro,
This patch series adds the poll_requested_events() function and uses it in
the V4L2 core and the ivtv driver.
The poll patch is unchanged from the RFCv3 patch posted a week ago and the
other patches are unchanged from the RFCv1 patch series posted last Wednesday
on the linux-media list.
Tested with vivi and ivtv.
Regards,
Hans
The following changes since commit bec969c908bb22931fd5ab8ecdf99de8702a6a31:
[media] v4l: s5p-tv: add TV Mixer driver for Samsung S5P platform
(2011-07-14 13:09:48 -0300)
are available in the git repository at:
ssh://linuxtv.org/git/hverkuil/media_tree.git poll
Hans Verkuil (6):
poll: add poll_requested_events() function
ivtv: only start streaming in poll() if polling for input.
videobuf2: only start streaming in poll() if so requested by the poll
mask.
videobuf: only start streaming in poll() if so requested by the poll
mask.
videobuf2-core: also test for pending events.
vivi: let vb2_poll handle events.
drivers/media/video/ivtv/ivtv-fileops.c |6 ++-
drivers/media/video/videobuf-core.c |3 +-
drivers/media/video/videobuf2-core.c| 48 +-
drivers/media/video/vivi.c |9 +-
fs/eventpoll.c | 19 +--
fs/select.c | 38 +++-
include/linux/poll.h|7 -
7 files changed, 78 insertions(+), 52 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I don't like the idea of merging the first patch directly on my tree, without
the vfs maintainer ack.
The better would be if Alexander could merge it, or give his ack on it.
Alternatively, if he is not maintaining it anymore, then maybe Andrew
can help us.
Thanks!
Mauro
-
From: Hans Verkuil hans.verk...@cisco.com
Subject: poll: add poll_requested_events() function
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
Unfortunately, the current epoll/poll/select implementation doesn't provide
that information reliably. The poll_table_struct does have it: it has a key
field with the event mask. But once a poll() call matches one or more bits
of that mask any following poll() calls are passed a NULL poll_table_struct
pointer.
The solution is to set the qproc field to NULL in poll_table_struct once
poll() matches the events, not the poll_table_struct pointer itself. That
way drivers can obtain the mask through a new poll_requested_events inline.
The poll_table_struct can still be NULL since some kernel code calls it
internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
that case poll_requested_events() returns ~0 (i.e. all events).
Since eventpoll always leaves the key field at ~0 instead of using the
requested events mask, that source was changed as well to properly fill in
the key field.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Jonathan Corbet cor...@lwn.net
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
fs/eventpoll.c | 19 +++
fs/select.c | 38 +-
include/linux/poll.h |7 ++-
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9cfd16..6a54a69 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -650,9 +650,12 @@ static int ep_read_events_proc(struct eventpoll *ep,
struct list_head *head,
void *priv)
{
struct epitem *epi, *tmp;
+ poll_table pt;
+ init_poll_funcptr(pt, NULL);
list_for_each_entry_safe(epi, tmp, head, rdllink) {
- if (epi-ffd.file-f_op-poll(epi-ffd.file, NULL)
+ pt.key = epi-event.events;
+ if (epi-ffd.file-f_op-poll(epi-ffd.file, pt)
epi-event.events)
return POLLIN | POLLRDNORM;
else {
@@ -946,6 +949,7 @@ static int ep_insert(struct eventpoll *ep, struct
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(epq.pt, ep_ptable_queue_proc);
+ epq.pt.key = event-events;
/*
* Attach the item to the poll hooks and get current event bits.
@@ -1027,20 +1031,23 @@ static int ep_modify(struct eventpoll *ep, struct
epitem *epi, struct epoll_even
{
int pwake = 0;
Re: [PATCH 1/3] IT9137 driver for Kworld UB499-2T T09 (id 1b80:e409) - firmware details
Em 25-07-2011 15:34, Malcolm Priestley escreveu: Firmware information for Kworld UB499-2T T09 based on IT913x series. This device uses file dvb-usb-it9137-01.fw. Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- Documentation/dvb/it9137.txt |9 + 1 files changed, 9 insertions(+), 0 deletions(-) create mode 100644 Documentation/dvb/it9137.txt diff --git a/Documentation/dvb/it9137.txt b/Documentation/dvb/it9137.txt new file mode 100644 index 000..9e6726e --- /dev/null +++ b/Documentation/dvb/it9137.txt @@ -0,0 +1,9 @@ +To extract firmware for Kworld UB499-2T (id 1b80:e409) you need to copy the +following file(s) to this directory. + +IT9135BDA.sys Dated Mon 22 Mar 2010 02:20:08 GMT + +extract using dd +dd if=IT9135BDA.sys ibs=1 skip=69632 count=5731 of=dvb-usb-it9137-01.fw + +copy to default firmware location. Malcolm, You should add a rule like the above at: Documentation/dvb/get_dvb_firmware if you cannot get the distribution rights for such firmware. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [resend] usbvision: disable scaling for Nogatech MicroCam
Em 27-07-2011 14:15, Anca Emanuel escreveu: Offtopic. Mauro is your pull request ready ? the merge window is open. Working on it. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [beagleboard] [RFC v1] mt9v113: VGA camera sensor driver and support for BeagleBoard
On Mon, Jul 25, 2011 at 10:13 AM, Koen Kooi k...@beagleboard.org wrote: Op 25 jul. 2011, om 18:56 heeft Mark Grosen het volgende geschreven: On Wed, Jul 13, 2011 at 11:22 AM, Joel A Fernandes agnel.j...@gmail.com wrote: * Adds support for mt9v113 sensor by borrowing heavily from PSP 2.6.37 kernel patches * Adapted to changes in v4l2 framework and ISP driver Signed-off-by: Joel A Fernandes agnel.j...@gmail.com --- This patch will apply against the 2.6.39 kernel built from the OE-development tree (Which is essentially the v2.6.39 from the main tree with OE patches for BeagleBoard support and a few other features) If you have the Leapord imaging camera board with this particular sensor, I would apprecite it if anyone could try this patch out and provide any feedback/test results. To get the complete tree which works on a BeagleBoard-xM with all the OE patches and this patch, you can clone: https://github.com/joelagnel/linux-omap-2.6/tree/oedev-2.6.39-mt9v113 It will compile and work on a BeagleBoard-xM with the defconfig at: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-2.6.39/beagleboard/defconfig Also you will need to apply my media-ctl patch (or clone the tree) to setup the formats: https://github.com/joelagnel/media-ctl/commit/cdf24d1249ac1ff3cd6f70ad80c3b76ac28ba0d5 Binaries for quick testing on a BeagleBoard-xM: U-boot: http://utdallas.edu/~joel.fernandes/u-boot.bin U-boot: http://utdallas.edu/~joel.fernandes/MLO uEnv.txt: http://utdallas.edu/~joel.fernandes/uEnv.txt media-ctl: http://utdallas.edu/~joel.fernandes/media-ctl kernel: http://utdallas.edu/~joel.fernandes/uImage media-ctl/yavta commands you could use to get it to show a picture can be found at: http://utdallas.edu/~joel.fernandes/stream.sh Joel, I gave this a try this weekend. I ran into a few problems/questions. I wanted to try with pre-built (tested?) binaries so I grabbed yours (used your uImage): 1. media-ctl binary does not work because there is no libmediactl.so on my Angstrom root FS. 2. There was no yavta-nc application. have you tried 'opkg update ; opkg install mediactl yavta-nc' ? Showing my Angstrom ignorance here, but I cannot get these packages via opkg update. I use Narcissus builder - I built a new FS yesterday using 2011.03 - should I have used next. It runs fine, but when I do the opkg update; opkg install yavta-nc it fails. I see media-ctl and yavta-nc in the package browser website, but my guess is they are for newer builds? Mark -- 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: [beagleboard] [RFC v1] mt9v113: VGA camera sensor driver and support for BeagleBoard
Joel, I gave this a try this weekend. I ran into a few problems/questions. I wanted to try with pre-built (tested?) binaries so I grabbed yours (used your uImage): 1. media-ctl binary does not work because there is no libmediactl.so on my Angstrom root FS. 2. There was no yavta-nc application. have you tried 'opkg update ; opkg install mediactl yavta-nc' ? Showing my Angstrom ignorance here, but I cannot get these packages via opkg update. I use Narcissus builder - I built a new FS yesterday using 2011.03 - should I have used next. It runs fine, but when I do the opkg update; opkg install yavta-nc it fails. I see media-ctl and yavta-nc in the package browser website, but my guess is they are for newer builds? What is the failure? If you have some output, could you paste it? As a last resort, you could download the .ipk from Angstrom Package browser, and uncompress it to get yavta-nc Thanks, Joel -- 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: 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:Wed Jul 27 19:00:40 CEST 2011 git hash:f0a21151140da01c71de636f482f2eddec2840cc gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] IT9137 driver for Kworld UB499-2T T09 (id 1b80:e409) - firmware details
Malcolm, You should add a rule like the above at: Documentation/dvb/get_dvb_firmware My patch does exactly that. [PATCH] Firmware extraction for IT9135 based devices if you cannot get the distribution rights for such firmware. Thanks, Mauro MvH Benjamin Larsson -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
Em 25-07-2011 21:17, Antti Palosaari escreveu:
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-usb/dvb-usb-dvb.c | 85
+++---
drivers/media/dvb/dvb-usb/dvb-usb-init.c |4 ++
drivers/media/dvb/dvb-usb/dvb-usb.h | 11 +++-
3 files changed, 78 insertions(+), 22 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
index d8c0bd9..5e34df7 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
@@ -162,8 +162,11 @@ static int dvb_usb_fe_wakeup(struct dvb_frontend *fe)
dvb_usb_device_power_ctrl(adap-dev, 1);
-if (adap-fe_init)
-adap-fe_init(fe);
+if (adap-props.frontend_ctrl)
+adap-props.frontend_ctrl(fe, 1);
+
+if (adap-fe_init[fe-id])
+adap-fe_init[fe-id](fe);
return 0;
}
@@ -172,45 +175,89 @@ static int dvb_usb_fe_sleep(struct dvb_frontend *fe)
{
struct dvb_usb_adapter *adap = fe-dvb-priv;
-if (adap-fe_sleep)
-adap-fe_sleep(fe);
+if (adap-fe_sleep[fe-id])
+adap-fe_sleep[fe-id](fe);
+
+if (adap-props.frontend_ctrl)
+adap-props.frontend_ctrl(fe, 0);
return dvb_usb_device_power_ctrl(adap-dev, 0);
}
int dvb_usb_adapter_frontend_init(struct dvb_usb_adapter *adap)
{
+int ret, i, x;
+
+memset(adap-fe, 0, sizeof(adap-fe));
+
if (adap-props.frontend_attach == NULL) {
-err(strange: '%s' #%d doesn't want to attach a
frontend.,adap-dev-desc-name, adap-id);
+err(strange: '%s' #%d doesn't want to attach a frontend.,
+adap-dev-desc-name, adap-id);
+
return 0;
}
-/* re-assign sleep and wakeup functions */
-if (adap-props.frontend_attach(adap) == 0 adap-fe[0] != NULL) {
-adap-fe_init = adap-fe[0]-ops.init; adap-fe[0]-ops.init =
dvb_usb_fe_wakeup;
-adap-fe_sleep = adap-fe[0]-ops.sleep; adap-fe[0]-ops.sleep =
dvb_usb_fe_sleep;
+/* register all given adapter frontends */
+if (adap-props.num_frontends)
+x = adap-props.num_frontends - 1;
+else
+x = 0;
+
+for (i = 0; i = x; i++) {
+ret = adap-props.frontend_attach(adap);
+if (ret || adap-fe[i] == NULL) {
+/* only print error when there is no FE at all */
+if (i == 0)
+err(no frontend was attached by '%s',
+adap-dev-desc-name);
This doesn't seem right. One thing is to accept adap-fe[1] to be
NULL. Another thing is to accept an error at the attach. IMO, the
logic should be something like:
if (ret 0)
return ret;
if (!i !adap-fe[0]) {
err(no adapter!);
return -ENODEV;
}
+
+return 0;
+}
-if (dvb_register_frontend(adap-dvb_adap, adap-fe[0])) {
-err(Frontend registration failed.);
-dvb_frontend_detach(adap-fe[0]);
-adap-fe[0] = NULL;
-return -ENODEV;
+adap-fe[i]-id = i;
+
+/* re-assign sleep and wakeup functions */
+adap-fe_init[i] = adap-fe[i]-ops.init;
+adap-fe[i]-ops.init = dvb_usb_fe_wakeup;
+adap-fe_sleep[i] = adap-fe[i]-ops.sleep;
+adap-fe[i]-ops.sleep = dvb_usb_fe_sleep;
+
+if (dvb_register_frontend(adap-dvb_adap, adap-fe[i])) {
+err(Frontend %d registration failed., i);
+dvb_frontend_detach(adap-fe[i]);
There is a special case here: for DRX-K, we can't call dvb_frontend_detach().
as just one drxk_attach() returns the two pointers. While this is not fixed,
we need to add some logic here to check if the adapter were attached.
+adap-fe[i] = NULL;
+/* In error case, do not try register more FEs,
+ * still leaving already registered FEs alive. */
I think that the proper thing to do is to detach everything, if one of
the attach fails. There isn't much sense on keeping the device partially
initialized.
+if (i == 0)
+return -ENODEV;
+else
+return 0;
}
/* only attach the tuner if the demod is there */
if (adap-props.tuner_attach != NULL)
adap-props.tuner_attach(adap);
-} else
-err(no frontend was attached by '%s',adap-dev-desc-name);
+}
return 0;
}
int dvb_usb_adapter_frontend_exit(struct dvb_usb_adapter *adap)
{
-if (adap-fe[0] != NULL) {
-dvb_unregister_frontend(adap-fe[0]);
-dvb_frontend_detach(adap-fe[0]);
+int i;
+
+/* unregister all given adapter frontends */
+if (adap-props.num_frontends)
+i = adap-props.num_frontends - 1;
+else
+i = 0;
+
+for (; i = 0; i--) {
+if (adap-fe[i] != NULL) {
+dvb_unregister_frontend(adap-fe[i]);
+
Re: [beagleboard] [RFC v1] mt9v113: VGA camera sensor driver and support for BeagleBoard
On Wed, Jul 27, 2011 at 11:49 AM, Joel A Fernandes agnel.j...@gmail.com wrote: Joel, I gave this a try this weekend. I ran into a few problems/questions. I wanted to try with pre-built (tested?) binaries so I grabbed yours (used your uImage): 1. media-ctl binary does not work because there is no libmediactl.so on my Angstrom root FS. 2. There was no yavta-nc application. have you tried 'opkg update ; opkg install mediactl yavta-nc' ? Showing my Angstrom ignorance here, but I cannot get these packages via opkg update. I use Narcissus builder - I built a new FS yesterday using 2011.03 - should I have used next. It runs fine, but when I do the opkg update; opkg install yavta-nc it fails. I see media-ctl and yavta-nc in the package browser website, but my guess is they are for newer builds? What is the failure? If you have some output, could you paste it? As a last resort, you could download the .ipk from Angstrom Package browser, and uncompress it to get yavta-nc Thanks, Joel The error is what you would expect: package not found I did try downloading the .ipk, but it fails to install because libc6 is too old. If I try to update libc6, it says it is already the latest. This is the point about being on an old release (2011.03 vs next). Mark -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add support for the dvb-t part of CT-3650 v3
On 07/24/2011 12:45 AM, Jose Alberto Reguero wrote:
Read without write work as with write. Attached updated patch.
ttusb2-6.diff
- read = i+1 num (msg[i+1].flags I2C_M_RD);
+ write_read = i+1 num (msg[i+1].flags I2C_M_RD);
+ read = msg[i].flags I2C_M_RD;
ttusb2 I2C-adapter seems to be fine for my eyes now. No more writing any
random bytes in case of single read. Good!
+ .dtv6_if_freq_khz = TDA10048_IF_4000,
+ .dtv7_if_freq_khz = TDA10048_IF_4500,
+ .dtv8_if_freq_khz = TDA10048_IF_5000,
+ .clk_freq_khz = TDA10048_CLK_16000,
+static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
cosmetic issue rename to ttusb2_ct3650_i2c_gate_ctrl
{ TDA10048_CLK_16000, TDA10048_IF_4000, 10, 3, 0 },
+ { TDA10048_CLK_16000, TDA10048_IF_4500, 5, 3, 0 },
+ { TDA10048_CLK_16000, TDA10048_IF_5000, 5, 3, 0 },
+ /* Set the pll registers */
+ tda10048_writereg(state, TDA10048_CONF_PLL1, 0x0f);
+ tda10048_writereg(state, TDA10048_CONF_PLL2, (u8)(state-pll_mfactor));
+ tda10048_writereg(state, TDA10048_CONF_PLL3, tda10048_readreg(state,
TDA10048_CONF_PLL3) | ((u8)(state-pll_nfactor) | 0x40));
This if only issue can have effect to functionality and I want double
check. I see few things.
1) clock (and PLL) settings should be done generally only once at
.init() and probably .sleep() in case of needed for sleep. Something
like start clock in init, stop clock in sleep. It is usually very first
thing to set before other. Now it is in wrong place - .set_frontend().
2) Those clock settings seem somehow weird. As you set different PLL M
divider for 6 MHz bandwidth than others. Have you looked those are
really correct? I suspect there could be some other Xtal than 16MHz and
thus those are wrong. Which Xtals there is inside device used? There is
most likely 3 Xtals, one for each chip. It is metal box nearest to chip.
Ran checkpatch.pl also to find out style issues before send patch.
I have send new version, hopefully final, of MFE. It changes array name
from adap-mfe to adap-fe. You should also update that.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
On 07/27/2011 10:06 PM, Mauro Carvalho Chehab wrote:
+for (i = 0; i= x; i++) {
+ret = adap-props.frontend_attach(adap);
+if (ret || adap-fe[i] == NULL) {
+/* only print error when there is no FE at all */
+if (i == 0)
+err(no frontend was attached by '%s',
+adap-dev-desc-name);
This doesn't seem right. One thing is to accept adap-fe[1] to be
NULL. Another thing is to accept an error at the attach. IMO, the
logic should be something like:
if (ret 0)
return ret;
if (!i !adap-fe[0]) {
err(no adapter!);
return -ENODEV;
}
Heh, I tried to keep it functioning as earlier not to break anything!
Only thing it does now differently is that it keeps silent when 2nd FE
attach fails since we don't know always before fe attach if there is fe
or not.
So since it *does not change old behaviour* it must be OK. Let fix old
problems later. There is millions of DVB USB callbacks failing silently
- like tuner_attach etc.
Surely I want also fix many old issues but it is always too risky.
+if (dvb_register_frontend(adap-dvb_adap, adap-fe[i])) {
+err(Frontend %d registration failed., i);
+dvb_frontend_detach(adap-fe[i]);
There is a special case here: for DRX-K, we can't call dvb_frontend_detach().
as just one drxk_attach() returns the two pointers. While this is not fixed,
we need to add some logic here to check if the adapter were attached.
There is currently no DVB USB driver using DRX-K thus it is not problem.
If someone will add such support can fix DRX-K driver.
Also take into account it is possible to register only 1 FE using DVB
USB and manually register 2nd FE as it have been those days.
+adap-fe[i] = NULL;
+/* In error case, do not try register more FEs,
+ * still leaving already registered FEs alive. */
I think that the proper thing to do is to detach everything, if one of
the attach fails. There isn't much sense on keeping the device partially
initialized.
It is not attach which fails here, it is dvb_register_frontend
registration. And I thought that too since it is rather major problem.
But as it seems to be very easy to do it like that I did. Not big issue
though.
+/* use exclusive FE lock if there is multiple shared FEs */
+if (adap-fe[1])
+adap-dvb_adap.mfe_shared = 1;
Why? multiple FE doesn't mean that they're mutually exclusive.
And again we ran same MFE discussion. But if you look DVB USB you
can see its main idea have been to register multiple adapters in case of
not exclusive frontends. That have been most likely implemented like
that from day-0 of DVB USB.
Another point is that it is not that patch which adds support for MFE.
It is old issue and I am not responsible of it. See patch where this
decision is made in year 2008:
commit 59b1842da1c6f33ad2e8da82d3dfb3445751d964
Author: Darron Broad dar...@kewl.org
Date: Sat Oct 11 11:44:05 2008 -0300
V4L/DVB (9227): MFE: Add multi-frontend mutual exclusion
Why to change again old behaviour?
Could you now read all with care. As I pointed out almost all your
findings are are decisions made *earlier*.
Only thing which is not coming from oldies is that you suggest to
unregister all frontends if one register fails.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
Em 27-07-2011 16:49, Antti Palosaari escreveu:
On 07/27/2011 10:06 PM, Mauro Carvalho Chehab wrote:
+for (i = 0; i= x; i++) {
+ret = adap-props.frontend_attach(adap);
+if (ret || adap-fe[i] == NULL) {
+/* only print error when there is no FE at all */
+if (i == 0)
+err(no frontend was attached by '%s',
+adap-dev-desc-name);
This doesn't seem right. One thing is to accept adap-fe[1] to be
NULL. Another thing is to accept an error at the attach. IMO, the
logic should be something like:
if (ret 0)
return ret;
if (!i !adap-fe[0]) {
err(no adapter!);
return -ENODEV;
}
Heh, I tried to keep it functioning as earlier not to break anything! Only
thing it does now differently is that it keeps
silent when 2nd FE attach fails since we don't know always before fe attach
if there is fe or not.
So since it *does not change old behaviour* it must be OK. Let fix old
problems later. There is millions of DVB USB
callbacks failing silently - like tuner_attach etc.
Surely I want also fix many old issues but it is always too risky.
I'm talking about adding another bad behavior: let MFE to have one of the FE's
failing.
+if (dvb_register_frontend(adap-dvb_adap, adap-fe[i])) {
+err(Frontend %d registration failed., i);
+dvb_frontend_detach(adap-fe[i]);
There is a special case here: for DRX-K, we can't call dvb_frontend_detach().
as just one drxk_attach() returns the two pointers. While this is not fixed,
we need to add some logic here to check if the adapter were attached.
There is currently no DVB USB driver using DRX-K thus it is not problem. If
someone will add such support can fix DRX-K driver.
I agree. I was just rising the question. The glue should be bound together with
the first
dvb-usb DRX-K driver.
Also take into account it is possible to register only 1 FE using DVB USB and
manually register 2nd FE as it have been those days.
+adap-fe[i] = NULL;
+/* In error case, do not try register more FEs,
+ * still leaving already registered FEs alive. */
I think that the proper thing to do is to detach everything, if one of
the attach fails. There isn't much sense on keeping the device partially
initialized.
It is not attach which fails here, it is dvb_register_frontend registration.
Yes, sure. I've miss-named.
And I thought that too since it is rather major problem. But as it seems to
be very easy to do it like that I did. Not big issue though.
Core functions should be more strict than drivers. So, I think it should really
enforce an all-or-nothing behavior here.
+/* use exclusive FE lock if there is multiple shared FEs */
+if (adap-fe[1])
+adap-dvb_adap.mfe_shared = 1;
Why? multiple FE doesn't mean that they're mutually exclusive.
And again we ran same MFE discussion. But if you look DVB USB you can see
its main idea
have been to register multiple adapters in case of not exclusive frontends.
That have been
most likely implemented like that from day-0 of DVB USB.
Another point is that it is not that patch which adds support for MFE. It is
old issue and
I am not responsible of it. See patch where this decision is made in year
2008:
commit 59b1842da1c6f33ad2e8da82d3dfb3445751d964
Author: Darron Broad dar...@kewl.org
Date: Sat Oct 11 11:44:05 2008 -0300
V4L/DVB (9227): MFE: Add multi-frontend mutual exclusion
Why to change again old behaviour?
Could you now read all with care. As I pointed out almost all your findings
are are decisions made *earlier*.
Only thing which is not coming from oldies is that you suggest to unregister
all frontends if one register fails.
You miss-understood me. I'm not saying that we should drop support for
mfe_shared flag.
I'm just saying that dvb-usb core should not assume that a driver with more
than one
FE have them into a mutually exclusive configuration.
If you look at dvb-core, the default for it is mfe_shared = 0. We should keep
the same
default for dvb-usb.
In other words, it should be up to the drivers to change mfe_shared flag to 1,
and not
to the core.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.1] v4l-dvb: add and use poll_requested_events() function
Hi Hans,
Em 17-07-2011 08:19, Hans Verkuil escreveu:
Hi Mauro,
This patch series adds the poll_requested_events() function and uses it in
the V4L2 core and the ivtv driver.
The poll patch is unchanged from the RFCv3 patch posted a week ago and the
other patches are unchanged from the RFCv1 patch series posted last Wednesday
on the linux-media list.
Tested with vivi and ivtv.
I don't like the idea of merging the first patch directly on my tree, without
the vfs maintainer ack, as I don't know enough about the poll usage inside the
kernel.
The better would be if Al could merge it, or give his ack on it.
Alternatively, if he is not maintaining it anymore, then maybe Andrew
can help us.
Thanks!
Mauro
-
From: Hans Verkuil hans.verk...@cisco.com
Subject: poll: add poll_requested_events() function
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
Unfortunately, the current epoll/poll/select implementation doesn't provide
that information reliably. The poll_table_struct does have it: it has a key
field with the event mask. But once a poll() call matches one or more bits
of that mask any following poll() calls are passed a NULL poll_table_struct
pointer.
The solution is to set the qproc field to NULL in poll_table_struct once
poll() matches the events, not the poll_table_struct pointer itself. That
way drivers can obtain the mask through a new poll_requested_events inline.
The poll_table_struct can still be NULL since some kernel code calls it
internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
that case poll_requested_events() returns ~0 (i.e. all events).
Since eventpoll always leaves the key field at ~0 instead of using the
requested events mask, that source was changed as well to properly fill in
the key field.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Jonathan Corbet cor...@lwn.net
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
fs/eventpoll.c | 19 +++
fs/select.c | 38 +-
include/linux/poll.h |7 ++-
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9cfd16..6a54a69 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -650,9 +650,12 @@ static int ep_read_events_proc(struct eventpoll *ep,
struct list_head *head,
void *priv)
{
struct epitem *epi, *tmp;
+ poll_table pt;
+ init_poll_funcptr(pt, NULL);
list_for_each_entry_safe(epi, tmp, head, rdllink) {
- if (epi-ffd.file-f_op-poll(epi-ffd.file, NULL)
+ pt.key = epi-event.events;
+ if (epi-ffd.file-f_op-poll(epi-ffd.file, pt)
epi-event.events)
return POLLIN | POLLRDNORM;
else {
@@ -946,6 +949,7 @@ static int ep_insert(struct eventpoll *ep, struct
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(epq.pt, ep_ptable_queue_proc);
+ epq.pt.key = event-events;
/*
* Attach the item to the poll hooks and get current event bits.
@@ -1027,20 +1031,23 @@ static int ep_modify(struct eventpoll *ep, struct
epitem *epi, struct epoll_even
{
int pwake = 0;
unsigned int revents;
+ poll_table pt;
+
+ init_poll_funcptr(pt, NULL);
/*
* Set the new event interest mask before calling f_op-poll();
* otherwise we might miss an event that happens between the
* f_op-poll() call and the new event set registering.
*/
- epi-event.events = event-events;
+ epi-event.events = pt.key = event-events;
epi-event.data = event-data; /* protected by mtx */
/*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
- revents = epi-ffd.file-f_op-poll(epi-ffd.file, NULL);
+ revents = epi-ffd.file-f_op-poll(epi-ffd.file, pt);
/*
* If the item is hot and it is not registered inside the ready
@@ -1075,6 +1082,9 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
unsigned int revents;
struct epitem *epi;
struct epoll_event __user *uevent;
+ poll_table pt;
+
+ init_poll_funcptr(pt, NULL);
/*
* We can loop without lock because we are passed a task private list.
@@ -1087,7 +1097,8 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
On 07/27/2011 11:06 PM, Mauro Carvalho Chehab wrote:
Em 27-07-2011 16:49, Antti Palosaari escreveu:
On 07/27/2011 10:06 PM, Mauro Carvalho Chehab wrote:
+for (i = 0; i= x; i++) {
+ret = adap-props.frontend_attach(adap);
+if (ret || adap-fe[i] == NULL) {
+/* only print error when there is no FE at all */
+if (i == 0)
+err(no frontend was attached by '%s',
+adap-dev-desc-name);
This doesn't seem right. One thing is to accept adap-fe[1] to be
NULL. Another thing is to accept an error at the attach. IMO, the
logic should be something like:
if (ret 0)
return ret;
if (!i !adap-fe[0]) {
err(no adapter!);
return -ENODEV;
}
Heh, I tried to keep it functioning as earlier not to break anything! Only
thing it does now differently is that it keeps
silent when 2nd FE attach fails since we don't know always before fe attach if
there is fe or not.
So since it *does not change old behaviour* it must be OK. Let fix old problems
later. There is millions of DVB USB
callbacks failing silently - like tuner_attach etc.
Surely I want also fix many old issues but it is always too risky.
I'm talking about adding another bad behavior: let MFE to have one of the FE's
failing.
Let the device driver made decision! I can add check that if ret 0
then fail as fatal, but if there is ret=0 and fe=NULL is not fatal. But
since it was discarded earlier I didnt added such check.
There is many devices have like 2 demod places on board. Then it is
housed as demod#0 + demod#1, #demod0 or #demod1. You will not know that
before trying to attach demod. Thus it *must* be possible to discard
missing demod silently. Surely there is soon someone end user making bug
reports if you print error on that case or even deregister whole device.
+if (dvb_register_frontend(adap-dvb_adap, adap-fe[i])) {
+err(Frontend %d registration failed., i);
+dvb_frontend_detach(adap-fe[i]);
There is a special case here: for DRX-K, we can't call dvb_frontend_detach().
as just one drxk_attach() returns the two pointers. While this is not fixed,
we need to add some logic here to check if the adapter were attached.
There is currently no DVB USB driver using DRX-K thus it is not problem. If
someone will add such support can fix DRX-K driver.
I agree. I was just rising the question. The glue should be bound together with
the first
dvb-usb DRX-K driver.
Also take into account it is possible to register only 1 FE using DVB USB and
manually register 2nd FE as it have been those days.
+adap-fe[i] = NULL;
+/* In error case, do not try register more FEs,
+ * still leaving already registered FEs alive. */
I think that the proper thing to do is to detach everything, if one of
the attach fails. There isn't much sense on keeping the device partially
initialized.
It is not attach which fails here, it is dvb_register_frontend registration.
Yes, sure. I've miss-named.
And I thought that too since it is rather major problem. But as it seems to be
very easy to do it like that I did. Not big issue though.
Core functions should be more strict than drivers. So, I think it should really
enforce an all-or-nothing behavior here.
Lets add it later, like next merge window.
+/* use exclusive FE lock if there is multiple shared FEs */
+if (adap-fe[1])
+adap-dvb_adap.mfe_shared = 1;
Why? multiple FE doesn't mean that they're mutually exclusive.
And again we ran same MFE discussion. But if you look DVB USB you can see
its main idea
have been to register multiple adapters in case of not exclusive frontends.
That have been
most likely implemented like that from day-0 of DVB USB.
Another point is that it is not that patch which adds support for MFE. It is
old issue and
I am not responsible of it. See patch where this decision is made in year 2008:
commit 59b1842da1c6f33ad2e8da82d3dfb3445751d964
Author: Darron Broaddar...@kewl.org
Date: Sat Oct 11 11:44:05 2008 -0300
V4L/DVB (9227): MFE: Add multi-frontend mutual exclusion
Why to change again old behaviour?
Could you now read all with care. As I pointed out almost all your findings are
are decisions made *earlier*.
Only thing which is not coming from oldies is that you suggest to unregister
all frontends if one register fails.
You miss-understood me. I'm not saying that we should drop support for
mfe_shared flag.
I'm just saying that dvb-usb core should not assume that a driver with more
than one
FE have them into a mutually exclusive configuration.
If you look at dvb-core, the default for it is mfe_shared = 0. We should keep
the same
default for dvb-usb.
In other words, it should be up to the drivers to change mfe_shared flag to 1,
and not
to the core.
Peace of cake. Anyhow, we still have 2 adapters for DVB USB for that and
have been long than
Re: Parallel CMOS Image Sensor with UART Control Interface
On Wed, 27 Jul 2011, James wrote: On Wed, Jul 27, 2011 at 3:40 AM, Sakari Ailus sakari.ai...@iki.fi wrote: On Mon, Jul 25, 2011 at 04:43:21PM +0800, James wrote: Dear all, Does anyone came across a v4l2 Linux Device Driver for an Image Sensor that uses Parallel CMOS H/V and can only be control by UART interface instead of the common I2C or SPI interface? A similar sensor is the STMicroelectronics VL5510 Image Sensor although it support all 3 types of control interface. (http://www.st.com/internet/automotive/product/178477.jsp) Most or all the drivers found I found under drivers/media/video uses the I2C or SPI interface instead I'm new to writing driver and need a reference v4l2 driver for this type of image sensor to work with OMAP3530 ISP port on Gumstix's Overo board. I just need a very simple v4l2 driver that can extract the image from the sensor and control over it via the UART control interface. Any help is very much appreciated. Hi James, I think there has been a recent discussion on a similar topic under the subject RE: FW: OMAP 3 ISP. The way to do this would be to implement platform subdevs in V4L2 core, which I think we don't have quite yet. Cc Laurent and Michael. -- Sakari Ailus sakari.ai...@iki.fi Hi Sakari, Thanks for pointing me to the discussion thread. I found it from the archive at http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/32700/focus=32721 I read through the threads and see that I'm indeed in similar situation with Alex. We both have sensor that output CMOS H/V image and only have UART/RS232 for control of the sensor operations via sending/reading packet of bytes. i.e. AGC, contrast, brightness etc.. Since the thread ended on 29-Jun, is there anymore update or information? Probably obvious, but just to have it mentioned in this thread, such UART driver should certainly be implemented as a line discipline. Thanks Guennadi As I've a MT9V032 camera with Gusmtix Overo, I was hoping to rely on the MT9V032 driver as a starting point and adapt it for the VL5510 sensor using only the UART interface. Thanks in adv. -- Regards, James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] drxk: Fix error return code during drxk init
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c index 5694955..5b22c1f 100644 --- a/drivers/media/dvb/frontends/drxk_hard.c +++ b/drivers/media/dvb/frontends/drxk_hard.c @@ -6171,7 +6171,7 @@ error: if (status 0) printk(KERN_ERR drxk: Error %d on %s\n, status, __func__); - return 0; + return status; } static void drxk_c_release(struct dvb_frontend *fe) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] drxk: Fix read debug message
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 5b22c1f..85332e8 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -355,13 +355,7 @@ static int i2c_read(struct i2c_adapter *adap,
{.addr = adr, .flags = I2C_M_RD,
.buf = answ, .len = alen}
};
- dprintk(3, :);
- if (debug 2) {
- int i;
- for (i = 0; i len; i++)
- printk(KERN_CONT %02x, msg[i]);
- printk(KERN_CONT \n);
- }
+
status = i2c_transfer(adap, msgs, 2);
if (status != 2) {
if (debug 2)
@@ -374,9 +368,12 @@ static int i2c_read(struct i2c_adapter *adap,
}
if (debug 2) {
int i;
- printk(KERN_CONT : Read );
+ dprintk(2, : read from );
for (i = 0; i len; i++)
printk(KERN_CONT %02x, msg[i]);
+ printk(KERN_CONT Value = );
+ for (i = 0; i alen; i++)
+ printk(KERN_CONT %02x, answ[i]);
printk(KERN_CONT \n);
}
return 0;
@@ -1075,7 +1072,7 @@ static int GetDeviceCapabilities(struct drxk_state *state)
state-m_hasIRQN = false;
break;
default:
- printk(KERN_ERR drxk: DeviceID not supported = %02x\n,
+ printk(KERN_ERR drxk: DeviceID 0x%02x not supported\n,
((sioTopJtagidLo 12) 0xFF));
status = -EINVAL;
goto error2;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] drxk: Fix the logic that selects between DVB-C annex A and C
Fix the DRX-K logic that selects between DVB-C annex A and C
Fix a typo where DVB-C annex type is set via setEnvParameters, but
the driver, uses, instead, setParamParameters[2].
While here, cleans up the code, fixing a bad identation at the fallback
code for other types of firmware, and put the multiple-line comments
into the Linux CodingStyle.
Acked-by: Oliver Endriss o.endr...@gmx.de
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 85332e8..41b0838 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -5382,18 +5382,16 @@ static int SetQAM(struct drxk_state *state, u16
IntermediateFreqkHz,
s32 tunerFreqOffset)
{
int status;
- u8 parameterLen;
- u16 setEnvParameters[5] = { 0, 0, 0, 0, 0 };
u16 setParamParameters[4] = { 0, 0, 0, 0 };
u16 cmdResult;
dprintk(1, \n);
/*
- STEP 1: reset demodulator
- resets FEC DI and FEC RS
- resets QAM block
- resets SCU variables
- */
+* STEP 1: reset demodulator
+* resets FEC DI and FEC RS
+* resets QAM block
+* resets SCU variables
+*/
status = write16(state, FEC_DI_COMM_EXEC__A, FEC_DI_COMM_EXEC_STOP);
if (status 0)
goto error;
@@ -5405,23 +5403,14 @@ static int SetQAM(struct drxk_state *state, u16
IntermediateFreqkHz,
goto error;
/*
- STEP 2: configure demodulator
- -set env
- -set params; resets IQM,QAM,FEC HW; initializes some SCU
variables
- */
+* STEP 2: configure demodulator
+* -set params; resets IQM,QAM,FEC HW; initializes some
+* SCU variables
+*/
status = QAMSetSymbolrate(state);
if (status 0)
goto error;
- /* Env parameters */
- setEnvParameters[2] = QAM_TOP_ANNEX_A; /* Annex */
- if (state-m_OperationMode == OM_QAM_ITU_C)
- setEnvParameters[2] = QAM_TOP_ANNEX_C; /* Annex */
- setParamParameters[3] |= (QAM_MIRROR_AUTO_ON);
- /* check for LOCKRANGE Extented */
- /* setParamParameters[3] |= QAM_LOCKRANGE_NORMAL; */
- parameterLen = 4;
-
/* Set params */
switch (state-param.u.qam.modulation) {
case QAM_256:
@@ -5448,30 +5437,37 @@ static int SetQAM(struct drxk_state *state, u16
IntermediateFreqkHz,
goto error;
setParamParameters[0] = state-m_Constellation; /* constellation */
setParamParameters[1] = DRXK_QAM_I12_J17; /* interleave mode */
+ if (state-m_OperationMode == OM_QAM_ITU_C)
+ setParamParameters[2] = QAM_TOP_ANNEX_C;
+ else
+ setParamParameters[2] = QAM_TOP_ANNEX_A;
+ setParamParameters[3] |= (QAM_MIRROR_AUTO_ON);
+ /* Env parameters */
+ /* check for LOCKRANGE Extented */
+ /* setParamParameters[3] |= QAM_LOCKRANGE_NORMAL; */
status = scu_command(state, SCU_RAM_COMMAND_STANDARD_QAM |
SCU_RAM_COMMAND_CMD_DEMOD_SET_PARAM, 4, setParamParameters, 1, cmdResult);
if (status 0) {
/* Fall-back to the simpler call */
- setParamParameters[0] = QAM_TOP_ANNEX_A;
if (state-m_OperationMode == OM_QAM_ITU_C)
- setEnvParameters[0] = QAM_TOP_ANNEX_C; /* Annex */
+ setParamParameters[0] = QAM_TOP_ANNEX_C;
else
- setEnvParameters[0] = 0;
-
- status = scu_command(state, SCU_RAM_COMMAND_STANDARD_QAM |
SCU_RAM_COMMAND_CMD_DEMOD_SET_ENV, 1, setEnvParameters, 1, cmdResult);
- if (status 0)
- goto error;
+ setParamParameters[0] = QAM_TOP_ANNEX_A;
+ status = scu_command(state, SCU_RAM_COMMAND_STANDARD_QAM |
SCU_RAM_COMMAND_CMD_DEMOD_SET_ENV, 1, setParamParameters, 1, cmdResult);
+ if (status 0)
+ goto error;
setParamParameters[0] = state-m_Constellation; /*
constellation */
setParamParameters[1] = DRXK_QAM_I12_J17; /* interleave
mode */
-
status = scu_command(state, SCU_RAM_COMMAND_STANDARD_QAM |
SCU_RAM_COMMAND_CMD_DEMOD_SET_PARAM, 2, setParamParameters, 1, cmdResult);
}
if (status 0)
goto error;
- /* STEP 3: enable the system in a mode where the ADC provides valid
signal
- setup constellation independent registers */
+ /*
+* STEP 3: enable the system in a mode where the ADC provides valid
+* signal setup constellation independent registers
+*/
#if 0
status = SetFrequency(channel, tunerFreqOffset));
if (status 0)
--
1.7.1
--
[PATCH 0/3] A few DRX-K fixes
The first patch fixes a bug when DVB-K registration fails, potentially causing an OOPS at the caller driver. The second one is a debug printk message fix. The last one fixes a typo a the driver. All patches are trivial. Mauro Carvalho Chehab (3): [media] drxk: Fix error return code during drxk init [media] drxk: Fix read debug message [media] drxk: Fix the logic that selects between DVB-C annex A and C drivers/media/dvb/frontends/drxk_hard.c | 73 ++- 1 files changed, 33 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Firmware extraction for IT9135 based devices
On Wed, 2011-07-27 at 14:21 +0200, Benjamin Larsson wrote: MvH Benjamin Larsson Thanks Benhamin Tested-by: Malcolm Priestley tvbox...@gmail.com Regards Malcolm -- 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
[GIT PATCHES FOR 3.1] Updates for the gspca-stv06xx driver
Hi Mauro, Long time no code. :) Here are some updates to the stv06xx driver. The following changes since commit b0189cd087aa82bd23277cb5c8960ab030e13e5c: Merge branch 'next/devel2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/linux-arm-soc (2011-07-26 17:42:18 -0700) are available in the git repository at: http://git.linuxtv.org/eandren/v4l-dvb-stv06xx.git media-for_v3.1 Erik Andrén (5): gspca-stv06xx: Simplify register writes by avoiding special data structures gspca-stv06xx: Simplify stv_init struct and vv6410 bridge init. gspca-stv06xx: Fix sensor init indentation. gspca-stv06xx: Remove writes to read-only registers gspca-stv06xx: Triple frame rate by decreasing the scan rate. Regards, Erik -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
On Wed, 2011-07-27 at 16:06 -0300, Mauro Carvalho Chehab wrote:
Em 25-07-2011 21:17, Antti Palosaari escreveu:
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-usb/dvb-usb-dvb.c | 85
+++---
drivers/media/dvb/dvb-usb/dvb-usb-init.c |4 ++
drivers/media/dvb/dvb-usb/dvb-usb.h | 11 +++-
3 files changed, 78 insertions(+), 22 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
index d8c0bd9..5e34df7 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
@@ -162,8 +162,11 @@ static int dvb_usb_fe_wakeup(struct dvb_frontend *fe)
dvb_usb_device_power_ctrl(adap-dev, 1);
-if (adap-fe_init)
-adap-fe_init(fe);
+if (adap-props.frontend_ctrl)
+adap-props.frontend_ctrl(fe, 1);
+
+if (adap-fe_init[fe-id])
+adap-fe_init[fe-id](fe);
return 0;
}
@@ -172,45 +175,89 @@ static int dvb_usb_fe_sleep(struct dvb_frontend *fe)
{
struct dvb_usb_adapter *adap = fe-dvb-priv;
-if (adap-fe_sleep)
-adap-fe_sleep(fe);
+if (adap-fe_sleep[fe-id])
+adap-fe_sleep[fe-id](fe);
+
+if (adap-props.frontend_ctrl)
+adap-props.frontend_ctrl(fe, 0);
return dvb_usb_device_power_ctrl(adap-dev, 0);
}
int dvb_usb_adapter_frontend_init(struct dvb_usb_adapter *adap)
{
+int ret, i, x;
+
+memset(adap-fe, 0, sizeof(adap-fe));
+
if (adap-props.frontend_attach == NULL) {
-err(strange: '%s' #%d doesn't want to attach a
frontend.,adap-dev-desc-name, adap-id);
+err(strange: '%s' #%d doesn't want to attach a frontend.,
+adap-dev-desc-name, adap-id);
+
return 0;
}
-/* re-assign sleep and wakeup functions */
-if (adap-props.frontend_attach(adap) == 0 adap-fe[0] != NULL) {
-adap-fe_init = adap-fe[0]-ops.init; adap-fe[0]-ops.init =
dvb_usb_fe_wakeup;
-adap-fe_sleep = adap-fe[0]-ops.sleep; adap-fe[0]-ops.sleep =
dvb_usb_fe_sleep;
+/* register all given adapter frontends */
+if (adap-props.num_frontends)
+x = adap-props.num_frontends - 1;
+else
+x = 0;
+
+for (i = 0; i = x; i++) {
+ret = adap-props.frontend_attach(adap);
+if (ret || adap-fe[i] == NULL) {
+/* only print error when there is no FE at all */
+if (i == 0)
+err(no frontend was attached by '%s',
+adap-dev-desc-name);
This doesn't seem right. One thing is to accept adap-fe[1] to be
NULL. Another thing is to accept an error at the attach. IMO, the
logic should be something like:
if (ret 0)
return ret;
if (!i !adap-fe[0]) {
err(no adapter!);
return -ENODEV;
}
+
+return 0;
+}
-if (dvb_register_frontend(adap-dvb_adap, adap-fe[0])) {
-err(Frontend registration failed.);
-dvb_frontend_detach(adap-fe[0]);
-adap-fe[0] = NULL;
-return -ENODEV;
+adap-fe[i]-id = i;
+
+/* re-assign sleep and wakeup functions */
+adap-fe_init[i] = adap-fe[i]-ops.init;
+adap-fe[i]-ops.init = dvb_usb_fe_wakeup;
+adap-fe_sleep[i] = adap-fe[i]-ops.sleep;
+adap-fe[i]-ops.sleep = dvb_usb_fe_sleep;
+
+if (dvb_register_frontend(adap-dvb_adap, adap-fe[i])) {
+err(Frontend %d registration failed., i);
+dvb_frontend_detach(adap-fe[i]);
There is a special case here: for DRX-K, we can't call dvb_frontend_detach().
as just one drxk_attach() returns the two pointers. While this is not fixed,
we need to add some logic here to check if the adapter were attached.
+adap-fe[i] = NULL;
+/* In error case, do not try register more FEs,
+ * still leaving already registered FEs alive. */
I think that the proper thing to do is to detach everything, if one of
the attach fails. There isn't much sense on keeping the device partially
initialized.
From memory, I recall the existing code doesn't detach the frontend even
if the device driver forces an error. So, the device driver must detach
the frontend first.
The trouble is that dvb-usb is becoming dated as new drivers tend to
work around it. No one likes to touch it, out of fear of breaking
existing drivers.
I think perhaps some kind of legacy wrapper is needed here, with the
moving of dvb-usb to its own core, so more development work can be done.
Regards
Malcolm
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dvb-usb: multi-frontend support (MFE)
On 07/28/2011 01:07 AM, Malcolm Priestley wrote: On Wed, 2011-07-27 at 16:06 -0300, Mauro Carvalho Chehab wrote: Em 25-07-2011 21:17, Antti Palosaari escreveu: Signed-off-by: Antti Palosaaricr...@iki.fi +adap-fe[i] = NULL; +/* In error case, do not try register more FEs, + * still leaving already registered FEs alive. */ I think that the proper thing to do is to detach everything, if one of the attach fails. There isn't much sense on keeping the device partially initialized. From memory, I recall the existing code doesn't detach the frontend even if the device driver forces an error. So, the device driver must detach the frontend first. Yes, if you return for example error (or fe == NULL) for .tuner_attach() it does not detach or deregister it - just silently discard all. I thought very many times those when implementing this and keep very careful not to change old functionality. The trouble is that dvb-usb is becoming dated as new drivers tend to work around it. No one likes to touch it, out of fear of breaking existing drivers. Yes, so true. I have thought that too. There is a lot of things I want to change but those are very hard without massive work. * We should have priv at the very first. No priv for FW DL example. * Remote keytable should be property of certain device model not adapter * There should be way to set count of adapter (and fe) in runtime (this is why I allowed to fail 2nd FE attach silently) * no probe (read eeprom etc) callback (I think read MAC could be renamed for probe) * no FE power control (GPIOs etc) that MFE patch adds this too * maybe probe1 and probe2 callbacks needed. sequence something like plug device = probe1 = download FW = probe2 = attach demod I think perhaps some kind of legacy wrapper is needed here, with the moving of dvb-usb to its own core, so more development work can be done. Wish like to thank you these comments Malcolm! regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
On Wed, Jul 27, 2011 at 07:51:36PM +0200, Laurent Pinchart wrote: Hi Sakari, Hi Laurent, On Wednesday 27 July 2011 12:13:05 Sakari Ailus wrote: Hi Laurent, Thanks for the patch. I have a few comments below. Thanks for the review. Please see my answers to your comments below. Javier, there's one question for you as well. In my opinion the patch looks very good and clean in general. All my comments were small issues and I agree with the resolutions. I think implementing dynamic pll calculation and digital gain control may be postponed if you wish. Especially the latter would be nice since I think many sensors have that feature (plus colour component gains) but no driver expose any proper interface for it. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Parallel CMOS Image Sensor with UART Control Interface
Hi Guennadi, We both have sensor that output CMOS H/V image and only have UART/RS232 for control of the sensor operations via sending/reading packet of bytes. i.e. AGC, contrast, brightness etc.. Since the thread ended on 29-Jun, is there anymore update or information? Probably obvious, but just to have it mentioned in this thread, such UART driver should certainly be implemented as a line discipline. Thanks Guennadi Do you have any working example that I can adapt as per your suggestion? Thanks in adv. -- Regards, James -- 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: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Sylwester, Em 27-07-2011 13:35, Sylwester Nawrocki escreveu: Hi Mauro, The following changes since commit f0a21151140da01c71de636f482f2eddec2840cc: Merge tag 'v3.0' into staging/for_v3.1 (2011-07-22 13:33:14 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung fimc-for-mauro Sylwester Nawrocki (28): s5p-fimc: Add support for runtime PM in the mem-to-mem driver s5p-fimc: Add media entity initialization s5p-fimc: Remove registration of video nodes from probe() s5p-fimc: Remove sclk_cam clock handling s5p-fimc: Limit number of available inputs to one s5p-fimc: Remove sensor management code from FIMC capture driver s5p-fimc: Remove v4l2_device from video capture and m2m driver s5p-fimc: Add the media device driver s5p-fimc: Conversion to use struct v4l2_fh s5p-fimc: Conversion to the control framework s5p-fimc: Add media operations in the capture entity driver s5p-fimc: Add PM helper function for streaming control s5p-fimc: Correct color format enumeration s5p-fimc: Convert to use media pipeline operations s5p-fimc: Add subdev for the FIMC processing block s5p-fimc: Add support for camera capture in JPEG format s5p-fimc: Add v4l2_device notification support for single frame capture s5p-fimc: Use consistent names for the buffer list functions s5p-fimc: Add runtime PM support in the camera capture driver s5p-fimc: Correct crop offset alignment on exynos4 s5p-fimc: Remove single-planar capability flags noon010pc30: Do not ignore errors in initial controls setup noon010pc30: Convert to the pad level ops noon010pc30: Clean up the s_power callback noon010pc30: Remove g_chip_ident operation handler s5p-csis: Handle all available power supplies s5p-csis: Rework of the system suspend/resume helpers s5p-csis: Enable v4l subdev device node From the last time you've submitted a similar set of patches: Why? The proper way to select an input is via S_INPUT. The driver may also optionally allow changing it via the media device, but it should not be a mandatory requirement, as the media device API is optional. The problem I'm trying to solve here is sharing the sensors and mipi-csi receivers between multiple FIMC H/W instances. Previously the driver supported attaching a sensor to only one selected FIMC at compile time. You could, for instance, specify all sensors as the selected FIMC's platform data and then use S_INPUT to choose between them. The sensor could not be used together with any other FIMC. But this is desired due to different capabilities of the FIMC IP instances. And now, instead of hardcoding a sensor assigment to particular video node, the sensors are bound to the media device. The media device driver takes the list of sensors and attaches them one by one to subsequent FIMC instances when it is initializing. Each sensor has a link to each FIMC but only one of them is active by default. That said an user application can use selected camera by opening corresponding video node. Which camera is at which node can be queried with G_INPUT. I could try to implement the previous S_INPUT behaviour, but IMHO this would lead to considerable and unnecessary driver code complication due to supporting overlapping APIs From this current pull request: From c6fb462c38be60a45d16a29a9e56c886ee0aa08c Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki s.nawro...@samsung.com Date: Fri, 10 Jun 2011 20:36:51 +0200 Subject: s5p-fimc: Conversion to the control framework Cc: Linux Media Mailing List linux-media@vger.kernel.org Make the driver inherit sensor controls when video node only API compatibility mode is enabled. The control framework allows to properly handle sensor controls through controls inheritance when pipeline is re-configured at media device level. ... - .vidioc_queryctrl = fimc_vidioc_queryctrl, - .vidioc_g_ctrl = fimc_vidioc_g_ctrl, - .vidioc_s_ctrl = fimc_cap_s_ctrl, ... I'll need to take some time to review this patchset. So, it will likely miss the bus for 3.1. While the code inside this patch looked ok, your comments scared me ;) In summary: The V4L2 API is not a legacy API that needs a compatibility mode. Removing controls like VIDIOC_S_INPUT, VIDIOC_*CTRL, etc in favor of the media controller API is wrong. This specific patch itself seems ok, but it is easy to loose the big picture on a series of 28 patches with about 4000 lines changed. The media controller API is meant to be used only by specific applications that might add some extra features to the driver. So, it is an optional API. In all cases where both API's can do the same thing, the proper way is to use the V4L2 API only, and not the media controller API. So, my current
Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Guennadi, On Wed, Jul 20, 2011 at 01:43, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: A possibility to preallocate and initialise buffers of different sizes in V4L2 is required for an efficient implementation of asnapshot mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF and defines respective data structures. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- snip This looks nicer, I like how we got rid of destroy and gave up on making holes, it would've given us a lot of headaches. I'm thinking about some issues though and also have some comments/questions further below. Already mentioned by others mixing of REQBUFS and CREATE_BUFS. Personally I'd like to allow mixing, including REQBUFS for non-zero, because I think it would be easy to do. I think it could work in the same way as REQBUFS for !=0 works currently (at least in vb2), if we already have some buffers allocated and they are not in use, we free them and a new set is allocated. So I guess it could just stay this way. REQBUFS(0) would of course free everything. Passing format to CREATE_BUFS will make vb2 a bit format-aware, as it would have to pass it forward to the driver somehow. The obvious way would be just vb2 calling the driver's s_fmt handler, but that won't work, as you can't pass indexes to s_fmt. So we'd have to implement a new driver callback for setting formats per index. I guess there is no way around it, unless we actually take the format struct out of CREATE_BUFS and somehow do it via S_FMT. The single-planar structure is full already though, the only way would be to use v4l2_pix_format_mplane instead with plane count = 1 (or more if needed). Another thing is the case of passing size to CREATE_BUFS. vb2, when allocating buffers, gets their sizes from the driver (via queue_setup), it never suggest any particular size. So that flow would have to be changed as well. I guess vb2 could pass the size to queue_setup in a similar way as it does with buffer count. This would mean though that the ioctl would fail if the driver didn't agree to the given size. Right now I don't see an option to negotiate the size with the driver via this option. The more I think of it though, why do we need the size argument? It's not needed in the existing flows (that use S_FMT) and, more importantly, I don't think the application can know more than the driver can, so why giving that option? The driver should know the size for a format at least as well as the application... Also, is there a real use case of providing just size, will the driver know which format to use given a size? + paraTo allocate device buffers applications initialize all +fields of the structnamev4l2_create_buffers/structname structure. +They set the structfieldtype/structfield field in the +structnamev4l2_format/structname structure, embedded in this +structure, to the respective stream or buffer type. +structfieldcount/structfield must be set to the number of required +buffers. structfieldmemory/structfield specifies the required I/O +method. Applications have two possibilities to specify the size of buffers +to be prepared: they can either set the structfieldsize/structfield +field explicitly to a non-zero value, or fill in the frame format data in the +structfieldformat/structfield field. In the latter case buffer sizes +will be calculated automatically by the driver. The Technically, we shouldn't say applications initialize all fields in the first sentence if they do not have to initialize both size and format fields at the same time. +structfieldreserved/structfield array must be zeroed. When the ioctl +is called with a pointer to this structure the driver will attempt to allocate +up to the requested number of buffers and store the actual number allocated +and the starting index in the structfieldcount/structfield and +the structfieldindex/structfield fields respectively. +structfieldcount/structfield can be smaller than the number requested. +-ENOMEM is returned, if the driver runs out of free memory./para + paraWhen the I/O method is not supported the ioctl +returns an EINVAL;./para + + table pgwide=1 frame=none id=v4l2-create-buffers + titlestruct structnamev4l2_create_buffers/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldindex/structfield/entry + entryThe starting buffer index, returned by the driver./entry + /row + row + entry__u32/entry + entrystructfieldcount/structfield/entry + entryThe number of buffers requested or granted./entry + /row + row + entryv4l2-memory;/entry + entrystructfieldmemory/structfield/entry + entryApplications set this field to +constantV4L2_MEMORY_MMAP/constant or +constantV4L2_MEMORY_USERPTR/constant./entry +
