[PATCH] v4l subdev: add dispatching for VIDIOC_DBG_G_REGISTER and VIDIOC_DBG_S_REGISTER.
Ioctls on the subdevs node currently don't dispatch the register access debug
driver callbacks. Add
the dispatching with the same security checks are for non subdev video nodes
(i.e. only capable(CAP_SYS_ADMIN may call the register access ioctls).
---
drivers/media/video/v4l2-subdev.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index b7967c9..8bf8397 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -25,6 +25,7 @@
#include linux/types.h
#include linux/videodev2.h
+#include media/v4l2-chip-ident.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
@@ -173,6 +174,25 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
case VIDIOC_UNSUBSCRIBE_EVENT:
return v4l2_subdev_call(sd, core, unsubscribe_event, vfh, arg);
+
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+ case VIDIOC_DBG_G_REGISTER:
+ {
+ struct v4l2_dbg_register *p = arg;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ return v4l2_subdev_call(sd, core, g_register, p);
+ }
+ case VIDIOC_DBG_S_REGISTER:
+ {
+ struct v4l2_dbg_register *p = arg;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ return v4l2_subdev_call(sd, core, s_register, p);
+ }
+#endif
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
case VIDIOC_SUBDEV_G_FMT: {
struct v4l2_subdev_format *format = arg;
--
1.7.2.5
--
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 v2] v4l: Add driver for Micron MT9M032 camera sensor
The MT9M032 is a parallel 3MP sensor from Micron controlled through I2C. The driver creates a V4L2 subdevice. It currently supports cropping, gain, exposure and v/h flipping controls in monochrome mode with an external pixel clock. Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile|1 + drivers/media/video/mt9m032.c | 814 +++ include/media/mt9m032.h | 38 ++ include/media/v4l2-chip-ident.h |1 + 5 files changed, 861 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9m032.c create mode 100644 include/media/mt9m032.h Changes in V2 * ported to current mainline * Moved dispatching for subdev ioctls VIDIOC_DBG_G_REGISTER and VIDIOC_DBG_S_REGISTER into v4l2-subdev * Removed VIDIOC_DBG_G_CHIP_IDENT support * moved header to media/ * Fixed missing error handling * lowercase hex constants * moved v4l2_get_subdevdata to register access helpers * use div_u64 instead of do_div * moved all know register values into #define:ed constants * Fixed error reporting, used clamp instead of open coding. * lots of style fixes. * add try_ctrl to make sure user space sees rounded values * Fixed some problem in control framework usage. * Fixed set_format to force width and height setup via crop. Simplyfied code. diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index f574dc0..41c6c12 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -798,6 +798,13 @@ config SOC_CAMERA_MT9M001 This driver supports MT9M001 cameras from Micron, monochrome and colour models. +config VIDEO_MT9M032 + tristate MT9M032 camera sensor support + depends on I2C VIDEO_V4L2 + help + This driver supports MT9M032 cameras from Micron, monochrome + models only. + config SOC_CAMERA_MT9M111 tristate mt9m111, mt9m112 and mt9m131 support depends on SOC_CAMERA I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 2723900..0d86830 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -74,6 +74,7 @@ obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o +obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o obj-$(CONFIG_SOC_CAMERA_MT9T112) += mt9t112.o diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c new file mode 100644 index 000..8a64193 --- /dev/null +++ b/drivers/media/video/mt9m032.c @@ -0,0 +1,814 @@ +/* + * Driver for MT9M032 CMOS Image Sensor from Micron + * + * Copyright (C) 2010-2011 Lund Engineering + * Contact: Gil Lund gwl...@lundeng.com + * Author: Martin Hostettler mar...@neutronstar.dyndns.org + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + */ + +#include linux/delay.h +#include linux/i2c.h +#include linux/init.h +#include linux/kernel.h +#include linux/math64.h +#include linux/module.h +#include linux/slab.h +#include linux/v4l2-mediabus.h + +#include media/media-entity.h +#include media/v4l2-chip-ident.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#include media/mt9m032.h + +#define MT9M032_CHIP_VERSION 0x00 +#define MT9M032_ROW_START 0x01 +#define MT9M032_COLUMN_START 0x02 +#define MT9M032_ROW_SIZE 0x03 +#define MT9M032_COLUMN_SIZE0x04 +#define MT9M032_HBLANK 0x05 +#define MT9M032_VBLANK 0x06 +#define MT9M032_SHUTTER_WIDTH_HIGH 0x08 +#define MT9M032_SHUTTER_WIDTH_LOW 0x09 +#define MT9M032_PIX_CLK_CTRL 0x0a +#define MT9M032_PIX_CLK_CTRL_INV_PIXCLK0x8000 +#define MT9M032_RESTART0x0b +#define MT9M032_RESET 0x0d +#define MT9M032_PLL_CONFIG10x11 +#define MT9M032_PLL_CONFIG1_OUTDIV_MASK0x3f +#define MT9M032_PLL_CONFIG1_MUL_SHIFT 8 +#define MT9M032_READ_MODE1 0x1e +#define MT9M032_READ_MODE2
RE: [PATCH] MAINTAINERS: add entries for s5p-mfc and s5p-tv drivers
Hi, How is it going? Best Regards /jtpark -Original Message- From: Marek Szyprowski [mailto:m.szyprow...@samsung.com] Sent: Wednesday, August 31, 2011 6:56 PM To: jtp.p...@samsung.com; linux-media@vger.kernel.org Cc: kgene@samsung.com; 'Kamil Debski'; younglak1004@samsung.com; kyungmin.p...@samsung.com Subject: RE: [PATCH] MAINTAINERS: add entries for s5p-mfc and s5p-tv drivers Hello, On Wednesday, August 31, 2011 10:36 AM Jeongtae Park wrote: Authors of the code definitely should be maintainers. I think everyone will agree. Ok, I will update the patch. Best Regards /jtpark -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Marek Szyprowski Sent: Wednesday, August 10, 2011 6:32 PM To: linux-media@vger.kernel.org Cc: Marek Szyprowski; Kyungmin Park; Kamil Debski; Tomasz Stanislawski Subject: [PATCH] MAINTAINERS: add entries for s5p-mfc and s5p-tv drivers Both driver has been merged to v3.1-rc1, so add its authors as maintainers. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- MAINTAINERS | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 51d42fb..0618d9a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1084,6 +1084,24 @@ F: arch/arm/plat-s5p/dev-fimc* F: arch/arm/plat-samsung/include/plat/*fimc* F: drivers/media/video/s5p-fimc/ +ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT +M: Kyungmin Park kyungmin.p...@samsung.com +M: Kamil Debski k.deb...@samsung.com M: Jeongtae Parkjtp.p...@samsung.com +L: linux-arm-ker...@lists.infradead.org +L: linux-media@vger.kernel.org +S: Maintained +F: arch/arm/plat-s5p/dev-mfc.c +F: drivers/media/video/s5p-mfc/ + +ARM/SAMSUNG S5P SERIES TV SUBSYSTEM SUPPORT +M: Kyungmin Park kyungmin.p...@samsung.com +M: Tomasz Stanislawski t.stanisl...@samsung.com +L: linux-arm-ker...@lists.infradead.org +L: linux-media@vger.kernel.org +S: Maintained +F: arch/arm/plat-s5p/dev-tv.c +F: drivers/media/video/s5p-tv/ + ARM/SHMOBILE ARM ARCHITECTURE M: Paul Mundt let...@linux-sh.org M: Magnus Damm magnus.d...@gmail.com Best regards -- Marek Szyprowski 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
[PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 183 +++
2 files changed, 184 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..8ae3d25 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+=
board-omap3logic.o \
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..be987d9
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C Bus
2
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include linux/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include media/mt9m032.h
+
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 1350,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+ .invert_pixclock = 1,
+};
+
+static struct i2c_board_info camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9M032_NAME, MT9M032_I2C_ADDR),
+ .platform_data = mt9m032_platform_data,
+ },
+};
+
+static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
+ {
+ .board_info = camera_i2c_devices[0],
+ .i2c_adapter_id = MT9M032_I2C_BUS_NUM,
+ },
+ {},
+};
+
+static struct isp_v4l2_subdevs_group camera_subdevs[] = {
+ {
+ .subdevs = camera_i2c_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 1,
+ .clk_pol = 0,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ {},
+};
+
+static struct
Re: [PATCH/RFC 1/2] v4l2: Add the parallel bus HREF signal polarity flags
Hi Sylwester, On Friday 16 September 2011 19:28:42 Sylwester Nawrocki wrote: HREF is a signal indicating valid data during single line transmission. Add corresponding flags for this signal to the set of mediabus signal polarity flags. So that's a data valid signal that gates the pixel data ? The OMAP3 ISP has a similar signal called WEN, and I've seen other chips using DVAL. Your patch looks good to me, except maybe for the signal name that could be made a bit more explicit (I'm not sure what most chips use though). Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- include/media/v4l2-mediabus.h | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..41d8771 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -26,12 +26,14 @@ /* Note: in BT.656 mode HSYNC and VSYNC are unused */ #define V4L2_MBUS_HSYNC_ACTIVE_HIGH (1 2) #define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3) -#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 4) -#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 5) -#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 6) -#define V4L2_MBUS_PCLK_SAMPLE_FALLING(1 7) -#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 8) -#define V4L2_MBUS_DATA_ACTIVE_LOW(1 9) +#define V4L2_MBUS_HREF_ACTIVE_HIGH (1 4) +#define V4L2_MBUS_HREF_ACTIVE_LOW(1 5) +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 6) +#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 7) +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 8) +#define V4L2_MBUS_PCLK_SAMPLE_FALLING(1 9) +#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 10) +#define V4L2_MBUS_DATA_ACTIVE_LOW(1 11) /* Serial flags */ /* How many lanes the client can use */ -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/2] v4l2: Add the parallel bus HREF signal polarity flags
Hi Laurent, thanks for your comments. On 09/17/2011 12:54 PM, Laurent Pinchart wrote: Hi Sylwester, On Friday 16 September 2011 19:28:42 Sylwester Nawrocki wrote: HREF is a signal indicating valid data during single line transmission. Add corresponding flags for this signal to the set of mediabus signal polarity flags. So that's a data valid signal that gates the pixel data ? The OMAP3 ISP has a Yes, it's horizontal window reference signal, it's well described in this datasheet: http://www.morninghan.com/pdf/OV2640FSL_DS_(1_3).pdf AFAICS there can be also its vertical counterpart - VREF. Many devices seem to use this terminology. However, I realize, not all, as you're pointing out. So perhaps it's time for some naming contest now.. :-) similar signal called WEN, and I've seen other chips using DVAL. Your patch looks good to me, except maybe for the signal name that could be made a bit more explicit (I'm not sure what most chips use though). I'm pretty OK with HREF/VREF. But I'm open to any better suggestions. Maybe V4L2_MBUS_LINE_VALID_ACTIVE_HIGH V4L2_MBUS_LINE_VALID_ACTIVE_LOW V4L2_MBUS_FRAME_VALID_ACTIVE_HIGH V4L2_MBUS_FRAME_VALID_ACTIVE_LOW ? Some of Aptina sensor datasheets describes those signals as LINE_VALID/FRAME_VALID, (www.aptina.com/assets/downloadDocument.do?id=76). Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- include/media/v4l2-mediabus.h | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..41d8771 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -26,12 +26,14 @@ /* Note: in BT.656 mode HSYNC and VSYNC are unused */ I've forgotten to update this: /* Note: in BT.656 mode HSYNC, HREF and VSYNC are unused */ #define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 2) #define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3) -#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 4) -#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 5) -#define V4L2_MBUS_PCLK_SAMPLE_RISING(1 6) -#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 7) -#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 8) -#define V4L2_MBUS_DATA_ACTIVE_LOW (1 9) +#define V4L2_MBUS_HREF_ACTIVE_HIGH (1 4) +#define V4L2_MBUS_HREF_ACTIVE_LOW (1 5) +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 6) +#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 7) +#define V4L2_MBUS_PCLK_SAMPLE_RISING(1 8) +#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 9) +#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 10) +#define V4L2_MBUS_DATA_ACTIVE_LOW (1 11) -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/2] v4l2: Add the parallel bus HREF signal polarity flags
On Sat, 17 Sep 2011, Sylwester Nawrocki wrote: Hi Laurent, thanks for your comments. On 09/17/2011 12:54 PM, Laurent Pinchart wrote: Hi Sylwester, On Friday 16 September 2011 19:28:42 Sylwester Nawrocki wrote: HREF is a signal indicating valid data during single line transmission. Add corresponding flags for this signal to the set of mediabus signal polarity flags. So that's a data valid signal that gates the pixel data ? The OMAP3 ISP has a Yes, it's horizontal window reference signal, it's well described in this datasheet: http://www.morninghan.com/pdf/OV2640FSL_DS_(1_3).pdf AFAICS there can be also its vertical counterpart - VREF. Many devices seem to use this terminology. However, I realize, not all, as you're pointing out. So perhaps it's time for some naming contest now.. :-) Hi No objections in principle, just one question though: can these signals actually be used simultaneously with respective *SYNC signals or only as an alternative? If the latter, maybe we could reuse same names by just making them more generic? Thanks Guennadi similar signal called WEN, and I've seen other chips using DVAL. Your patch looks good to me, except maybe for the signal name that could be made a bit more explicit (I'm not sure what most chips use though). I'm pretty OK with HREF/VREF. But I'm open to any better suggestions. Maybe V4L2_MBUS_LINE_VALID_ACTIVE_HIGH V4L2_MBUS_LINE_VALID_ACTIVE_LOW V4L2_MBUS_FRAME_VALID_ACTIVE_HIGH V4L2_MBUS_FRAME_VALID_ACTIVE_LOW ? Some of Aptina sensor datasheets describes those signals as LINE_VALID/FRAME_VALID, (www.aptina.com/assets/downloadDocument.do?id=76). Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- include/media/v4l2-mediabus.h | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..41d8771 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -26,12 +26,14 @@ /* Note: in BT.656 mode HSYNC and VSYNC are unused */ I've forgotten to update this: /* Note: in BT.656 mode HSYNC, HREF and VSYNC are unused */ #define V4L2_MBUS_HSYNC_ACTIVE_HIGH (1 2) #define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3) -#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 4) -#define V4L2_MBUS_VSYNC_ACTIVE_LOW(1 5) -#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 6) -#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 7) -#define V4L2_MBUS_DATA_ACTIVE_HIGH(1 8) -#define V4L2_MBUS_DATA_ACTIVE_LOW (1 9) +#define V4L2_MBUS_HREF_ACTIVE_HIGH(1 4) +#define V4L2_MBUS_HREF_ACTIVE_LOW (1 5) +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 6) +#define V4L2_MBUS_VSYNC_ACTIVE_LOW(1 7) +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 8) +#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 9) +#define V4L2_MBUS_DATA_ACTIVE_HIGH(1 10) +#define V4L2_MBUS_DATA_ACTIVE_LOW (1 11) -- Thanks, Sylwester --- 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 2/5] uvcvideo: Remove deprecated UVCIOC ioctls
The UVCIOC_CTRL_ADD, UVCIOC_CTRL_MAP_OLD, UVCIOC_CTRL_GET and
UVCIOC_CTRL_SET ioctls are deprecated and were scheduled for removal for
v2.6.42. As v2.6.42 == v3.2, remove them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/feature-removal-schedule.txt | 23 ---
drivers/media/video/uvc/uvc_v4l2.c | 54 +--
drivers/media/video/uvc/uvcvideo.h | 100 +--
3 files changed, 6 insertions(+), 171 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index 4dc4654..ead08f1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -495,29 +495,6 @@ Who: Jean Delvare kh...@linux-fr.org
-What: Support for UVCIOC_CTRL_ADD in the uvcvideo driver
-When: 3.2
-Why: The information passed to the driver by this ioctl is now queried
- dynamically from the device.
-Who: Laurent Pinchart laurent.pinch...@ideasonboard.com
-
-
-
-What: Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver
-When: 3.2
-Why: Used only by applications compiled against older driver versions.
- Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls.
-Who: Laurent Pinchart laurent.pinch...@ideasonboard.com
-
-
-
-What: Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver
-When: 3.2
-Why: Superseded by the UVCIOC_CTRL_QUERY ioctl.
-Who: Laurent Pinchart laurent.pinch...@ideasonboard.com
-
-
-
What: Support for driver specific ioctls in the pwc driver (everything
defined in media/pwc-ioctl.h)
When: 3.3
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index ea71d5f..dadf11f 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -32,7 +32,7 @@
* UVC ioctls
*/
static int uvc_ioctl_ctrl_map(struct uvc_video_chain *chain,
- struct uvc_xu_control_mapping *xmap, int old)
+ struct uvc_xu_control_mapping *xmap)
{
struct uvc_control_mapping *map;
unsigned int size;
@@ -58,13 +58,6 @@ static int uvc_ioctl_ctrl_map(struct uvc_video_chain *chain,
break;
case V4L2_CTRL_TYPE_MENU:
- if (old) {
- uvc_trace(UVC_TRACE_CONTROL, V4L2_CTRL_TYPE_MENU not
- supported for UVCIOC_CTRL_MAP_OLD.\n);
- ret = -EINVAL;
- goto done;
- }
-
size = xmap-menu_count * sizeof(*map-menu_info);
map-menu_info = kmalloc(size, GFP_KERNEL);
if (map-menu_info == NULL) {
@@ -538,20 +531,6 @@ static int uvc_v4l2_release(struct file *file)
return 0;
}
-static void uvc_v4l2_ioctl_warn(void)
-{
- static int warned;
-
- if (warned)
- return;
-
- uvc_printk(KERN_INFO, Deprecated UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
- ioctls will be removed in 2.6.42.\n);
- uvc_printk(KERN_INFO, See http://www.ideasonboard.org/uvc/upgrade/
- for upgrade instructions.\n);
- warned = 1;
-}
-
static long uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, void *arg)
{
struct video_device *vdev = video_devdata(file);
@@ -1032,37 +1011,8 @@ static long uvc_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
uvc_trace(UVC_TRACE_IOCTL, Unsupported ioctl 0x%08x\n, cmd);
return -EINVAL;
- /* Dynamic controls. UVCIOC_CTRL_ADD, UVCIOC_CTRL_MAP_OLD,
-* UVCIOC_CTRL_GET and UVCIOC_CTRL_SET are deprecated and scheduled for
-* removal in 2.6.42.
-*/
- case __UVCIOC_CTRL_ADD:
- uvc_v4l2_ioctl_warn();
- return -EEXIST;
-
- case __UVCIOC_CTRL_MAP_OLD:
- uvc_v4l2_ioctl_warn();
- case __UVCIOC_CTRL_MAP:
case UVCIOC_CTRL_MAP:
- return uvc_ioctl_ctrl_map(chain, arg,
- cmd == __UVCIOC_CTRL_MAP_OLD);
-
- case __UVCIOC_CTRL_GET:
- case __UVCIOC_CTRL_SET:
- {
- struct uvc_xu_control *xctrl = arg;
- struct uvc_xu_control_query xqry = {
- .unit = xctrl-unit,
- .selector = xctrl-selector,
- .query = cmd == __UVCIOC_CTRL_GET
- ? UVC_GET_CUR : UVC_SET_CUR,
- .size = xctrl-size,
- .data = xctrl-data,
- };
-
- uvc_v4l2_ioctl_warn();
- return uvc_xu_ctrl_query(chain, xqry);
- }
+ return uvc_ioctl_ctrl_map(chain, arg);
case UVCIOC_CTRL_QUERY:
[PATCH 3/5] media: Fix a UVC performance problem on systems with non-coherent DMA.
From: Al Cooper alcoop...@gmail.com
The UVC driver uses usb_alloc_coherent() to allocate DMA data buffers.
On systems without coherent DMA this ends up allocating buffers in
uncached memory. The subsequent memcpy's done to coalesce the DMA
chunks into contiguous buffers then run VERY slowly. On a MIPS test
system the memcpy is about 200 times slower. This issue prevents the
system from keeping up with 720p YUYV data at 10fps.
The following patch uses kmalloc to alloc the DMA buffers instead of
usb_alloc_coherent on systems without coherent DMA. With this patch
the system was easily able to keep up with 720p at 10fps.
Signed-off-by: Al Cooper alcoop...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_video.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index ffd1158..b015e8e 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -790,8 +790,12 @@ static void uvc_free_urb_buffers(struct uvc_streaming
*stream)
for (i = 0; i UVC_URBS; ++i) {
if (stream-urb_buffer[i]) {
+#ifndef CONFIG_DMA_NONCOHERENT
usb_free_coherent(stream-dev-udev, stream-urb_size,
stream-urb_buffer[i], stream-urb_dma[i]);
+#else
+ kfree(stream-urb_buffer[i]);
+#endif
stream-urb_buffer[i] = NULL;
}
}
@@ -831,9 +835,14 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
*stream,
for (; npackets 1; npackets /= 2) {
for (i = 0; i UVC_URBS; ++i) {
stream-urb_size = psize * npackets;
+#ifndef CONFIG_DMA_NONCOHERENT
stream-urb_buffer[i] = usb_alloc_coherent(
stream-dev-udev, stream-urb_size,
gfp_flags | __GFP_NOWARN, stream-urb_dma[i]);
+#else
+ stream-urb_buffer[i] =
+ kmalloc(stream-urb_size, gfp_flags | __GFP_NOWARN);
+#endif
if (!stream-urb_buffer[i]) {
uvc_free_urb_buffers(stream);
break;
@@ -908,10 +917,14 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream,
urb-context = stream;
urb-pipe = usb_rcvisocpipe(stream-dev-udev,
ep-desc.bEndpointAddress);
+#ifndef CONFIG_DMA_NONCOHERENT
urb-transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
+ urb-transfer_dma = stream-urb_dma[i];
+#else
+ urb-transfer_flags = URB_ISO_ASAP;
+#endif
urb-interval = ep-desc.bInterval;
urb-transfer_buffer = stream-urb_buffer[i];
- urb-transfer_dma = stream-urb_dma[i];
urb-complete = uvc_video_complete;
urb-number_of_packets = npackets;
urb-transfer_buffer_length = size;
@@ -969,8 +982,10 @@ static int uvc_init_video_bulk(struct uvc_streaming
*stream,
usb_fill_bulk_urb(urb, stream-dev-udev, pipe,
stream-urb_buffer[i], size, uvc_video_complete,
stream);
+#ifndef CONFIG_DMA_NONCOHERENT
urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
urb-transfer_dma = stream-urb_dma[i];
+#endif
stream-urb[i] = urb;
}
--
1.7.3.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
[PATCH 5/5] USB: export video.h to the includes available for userspace
From: Marek Szyprowski m.szyprow...@samsung.com The uvcvideo extension unit API requires constants defined in the video.h header. Add it to the list of includes exported to userspace. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- include/linux/usb/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/usb/Kbuild b/include/linux/usb/Kbuild index ed91fb6..b607f35 100644 --- a/include/linux/usb/Kbuild +++ b/include/linux/usb/Kbuild @@ -7,3 +7,4 @@ header-y += gadgetfs.h header-y += midi.h header-y += g_printer.h header-y += tmc.h +header-y += video.h -- 1.7.3.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
[PATCH 1/5] uvcvideo: Detect The Imaging Source CCD cameras by vendor and product ID
From: Arne Caspari a...@unicap-imaging.org
The Imaging Source CCD cameras use a vendor specific interface class
even though they are actually UVC compliant.
Signed-off-by: Arne Caspari a...@unicap-imaging.org
---
drivers/media/video/uvc/uvc_driver.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index e4100b1..a3c24dd 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -2331,6 +2331,14 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_PROBE_DEF },
+ /* The Imaging Source USB CCD cameras */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x199e,
+ .idProduct= 0x8102,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0 },
/* Bodelin ProScopeHR */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_DEV_HI
--
1.7.3.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
[PATCH 4/5] uvcvideo: Add a mapping for H.264 payloads
From: Stephan Lachowsky stephan.lachow...@maxim-ic.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_driver.c |5 +
drivers/media/video/uvc/uvcvideo.h |4
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_driver.c
b/drivers/media/video/uvc/uvc_driver.c
index a3c24dd..656d4c9 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -114,6 +114,11 @@ static struct uvc_format_desc uvc_fmts[] = {
.guid = UVC_GUID_FORMAT_RGBP,
.fcc= V4L2_PIX_FMT_RGB565,
},
+ {
+ .name = H.264,
+ .guid = UVC_GUID_FORMAT_H264,
+ .fcc= V4L2_PIX_FMT_H264,
+ },
};
/*
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index e3aec87..4c1392e 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -89,6 +89,10 @@
{ 'M', '4', '2', '0', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_H264 \
+ { 'H', '2', '6', '4', 0x00, 0x00, 0x10, 0x00, \
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+
/*
* Driver specific constants.
*/
--
1.7.3.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/RFC 1/2] v4l2: Add the parallel bus HREF signal polarity flags
Hi Guennadi, On 09/17/2011 02:34 PM, Guennadi Liakhovetski wrote: On Sat, 17 Sep 2011, Sylwester Nawrocki wrote: Hi Laurent, thanks for your comments. On 09/17/2011 12:54 PM, Laurent Pinchart wrote: Hi Sylwester, On Friday 16 September 2011 19:28:42 Sylwester Nawrocki wrote: HREF is a signal indicating valid data during single line transmission. Add corresponding flags for this signal to the set of mediabus signal polarity flags. So that's a data valid signal that gates the pixel data ? The OMAP3 ISP has a Yes, it's horizontal window reference signal, it's well described in this datasheet: http://www.morninghan.com/pdf/OV2640FSL_DS_(1_3).pdf AFAICS there can be also its vertical counterpart - VREF. Many devices seem to use this terminology. However, I realize, not all, as you're pointing out. So perhaps it's time for some naming contest now.. :-) Hi No objections in principle, just one question though: can these signals actually be used simultaneously with respective *SYNC signals or only as an alternative? If the latter, maybe we could reuse same names by just making them more generic? That's actually a good question. In my use cases only HREF is used as horizontal synchronization signal, i.e. physical bus interface has this signals: -| PCLK -| VSYNC -| HREF -| DATA[0:7] -| FIELD For interlaced mode FIELD can be connected to the horizontal synchronization signal. For this case there is InvPolHSYNC bit in the host interface registers to indicate the polarity. There are 5 bits actually: InvPolPCLK InvPolVSYNC (vertical sychronization) InvPolHREF (horizontal synchronization) InvPolHSYNC (for interlaced mode only, FIELD port = horizontal sync. signal) InvPolFIELD (interlaced mode, FIELD port = FIELD signal) IMHO keeping different names for synchronization and 'data valid' signals is more clear. Thanks Guennadi similar signal called WEN, and I've seen other chips using DVAL. Your patch looks good to me, except maybe for the signal name that could be made a bit more explicit (I'm not sure what most chips use though). I'm pretty OK with HREF/VREF. But I'm open to any better suggestions. Maybe V4L2_MBUS_LINE_VALID_ACTIVE_HIGH V4L2_MBUS_LINE_VALID_ACTIVE_LOW V4L2_MBUS_FRAME_VALID_ACTIVE_HIGH V4L2_MBUS_FRAME_VALID_ACTIVE_LOW ? Some of Aptina sensor datasheets describes those signals as LINE_VALID/FRAME_VALID, (www.aptina.com/assets/downloadDocument.do?id=76). Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- include/media/v4l2-mediabus.h | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..41d8771 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -26,12 +26,14 @@ /* Note: in BT.656 mode HSYNC and VSYNC are unused */ I've forgotten to update this: /* Note: in BT.656 mode HSYNC, HREF and VSYNC are unused */ #define V4L2_MBUS_HSYNC_ACTIVE_HIGH (1 2) #define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3) -#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 4) -#define V4L2_MBUS_VSYNC_ACTIVE_LOW(1 5) -#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 6) -#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 7) -#define V4L2_MBUS_DATA_ACTIVE_HIGH(1 8) -#define V4L2_MBUS_DATA_ACTIVE_LOW (1 9) +#define V4L2_MBUS_HREF_ACTIVE_HIGH(1 4) +#define V4L2_MBUS_HREF_ACTIVE_LOW (1 5) +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 6) +#define V4L2_MBUS_VSYNC_ACTIVE_LOW(1 7) +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 8) +#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 9) +#define V4L2_MBUS_DATA_ACTIVE_HIGH(1 10) +#define V4L2_MBUS_DATA_ACTIVE_LOW (1 11) -- Regards, Sylwester -- 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 5/5] USB: export video.h to the includes available for userspace
On Saturday 17 September 2011 17:34:02 Laurent Pinchart wrote: From: Marek Szyprowski m.szyprow...@samsung.com I'm not sure how this From: line got there, I'll fix it. The uvcvideo extension unit API requires constants defined in the video.h header. Add it to the list of includes exported to userspace. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- include/linux/usb/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/usb/Kbuild b/include/linux/usb/Kbuild index ed91fb6..b607f35 100644 --- a/include/linux/usb/Kbuild +++ b/include/linux/usb/Kbuild @@ -7,3 +7,4 @@ header-y += gadgetfs.h header-y += midi.h header-y += g_printer.h header-y += tmc.h +header-y += video.h -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Sep 17 19:00:21 CEST 2011 git hash:7577911244c437f4a4abac5e4b67b059c06dbe9d gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.3-amd64 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: WARNINGS 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-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS 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 linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
[PULL] dvb-usb-mfe cleanups
Mauro, Please pull the following cleanups from my dvb-usb branch into your for_v3.2 branch. The following changes since commit 2d04c13a507f5a01daa7422cd52250809573cfdb: Michael Krufky (1): [media] dvb-usb: improve sanity check of adap-active_fe in dvb_usb_ctrl_feed are available in the git repository at: git://git.linuxtv.org/mkrufky/mxl111sf.git dvb-usb Michael Krufky (15): mxl111sf: use adap-num_frontends_initialized to determine which frontend is being attached dib0700: fix WARNING: please, no spaces at the start of a line dib0700: fix WARNING: suspect code indent for conditional statements dib0700: fix ERROR: space required before that '' dib0700: fix ERROR: space required after that ',' dibusb-common: fix ERROR: space required after that ',' dibusb-mb: fix ERROR: space required after that ',' ttusb2: fix ERROR: space required after that ',' dvb-usb-dvb: ERROR: space required after that ',' cxusb: fix ERROR: do not use assignment in if condition dibusb-common: fix ERROR: do not use assignment in if condition dibusb-mb: fix ERROR: do not use assignment in if condition digitv: fix ERROR: do not use assignment in if condition m920x: fix ERROR: do not use assignment in if condition opera1: fix ERROR: do not use assignment in if condition drivers/media/dvb/dvb-usb/cxusb.c | 52 -- drivers/media/dvb/dvb-usb/dib0700_devices.c | 23 +++- drivers/media/dvb/dvb-usb/dibusb-common.c | 19 +++--- drivers/media/dvb/dvb-usb/dibusb-mb.c |9 +++-- drivers/media/dvb/dvb-usb/digitv.c |9 - drivers/media/dvb/dvb-usb/dvb-usb-dvb.c |7 ++-- drivers/media/dvb/dvb-usb/m920x.c | 21 ++- drivers/media/dvb/dvb-usb/mxl111sf.c| 19 ++ drivers/media/dvb/dvb-usb/opera1.c |6 ++-- drivers/media/dvb/dvb-usb/ttusb2.c |2 +- 10 files changed, 103 insertions(+), 64 deletions(-) Cheers, Mike Krufky -- 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: Lockdep warning in ivtv driver in 3.1
On Mon, 2011-08-22 at 14:24 -0400, Josh Boyer wrote:
Hi All,
We've gotten a report[1] that the ivtv driver is throwing a lockdep
warning when calling ivtv_gpio_init. From what I can tell, it seems
like the lock being held twice is the one allocated for ivtv-cxhdl, but
I can't immediately see where it's locked and not unlocked in the
callstack path.
Does anyone have an idea where this could be happening?
Yes, I do. Right here:
http://git.linuxtv.org/media_tree.git/blob/refs/heads/staging/for_v3.2:/drivers/media/video/v4l2-ctrls.c#l1120
But it is almost certainly a false positive because of the way the mutex
is initialized in the body of a helper function used by many drivers:
http://git.linuxtv.org/media_tree.git/blob/refs/heads/staging/for_v3.2:/drivers/media/video/v4l2-ctrls.c#l1099
So there is no way for lockdep to distinguish between a control handler
lock in the bridge driver vs. one of the subdevices under the bridge
driver's control.
The mutex should really be initialized in a macro or inline function.
Say like in this patch:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg26097.html
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/27027
See if it still applies and solves your problem.
Further reading:
Comments 11-13 of this ivtv bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=662384
This post by me:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg33565.html
Honestly I wish all mutexes and spinlocks were initalized with such
descriptive names as my patch sets up for the control handler mutex. It
would make the output of lockdep a lot easier to follow.
Regards,
Andy W.
[ 28.556610] =
[ 28.557007] [ INFO: possible recursive locking detected ]
[ 28.557007] 3.1.0-0.rc0.git19.1.fc17.x86_64 #1
[ 28.557007] -
[ 28.557007] modprobe/684 is trying to acquire lock:
[ 28.557007] (hdl-lock){+.+...}, at: [a02919ba]
find_ref_lock+0x24/0x46 [videodev]
[ 28.557007]
[ 28.557007] but task is already holding lock:
[ 28.557007] (hdl-lock){+.+...}, at: [a029380f]
v4l2_ctrl_add_handler+0x49/0x97 [videodev]
[ 28.557007]
[ 28.557007] other info that might help us debug this:
[ 28.557007] Possible unsafe locking scenario:
[ 28.557007]
[ 28.557007]CPU0
[ 28.557007]
[ 28.557007] lock(hdl-lock);
[ 28.557007] lock(hdl-lock);
[ 28.557007]
[ 28.557007] *** DEADLOCK ***
[ 28.557007]
[ 28.557007] May be due to missing lock nesting notation
[ 28.557007]
[ 28.557007] 3 locks held by modprobe/684:
[ 28.557007] #0: (__lockdep_no_validate__){..}, at:
[81314d0c] __driver_attach+0x3b/0x82
[ 28.557007] #1: (__lockdep_no_validate__){..}, at:
[81314d1a] __driver_attach+0x49/0x82
[ 28.557007] #2: (hdl-lock){+.+...}, at: [a029380f]
v4l2_ctrl_add_handler+0x49/0x97 [videodev]
[ 28.557007]
[ 28.557007] stack backtrace:
[ 28.557007] Pid: 684, comm: modprobe Not tainted
3.1.0-0.rc0.git19.1.fc17.x86_64 #1
[ 28.557007] Call Trace:
[ 28.557007] [8108eb06] __lock_acquire+0x917/0xcf7
[ 28.557007] [81014fbe] ? sched_clock+0x9/0xd
[ 28.557007] [8108dffc] ? mark_lock+0x2d/0x220
[ 28.557007] [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.557007] [8108f3dc] lock_acquire+0xf3/0x13e
[ 28.584886] [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [814f2523] __mutex_lock_common+0x5d/0x39a
[ 28.585146] [a02919ba] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [8108f6db] ? mark_held_locks+0x6d/0x95
[ 28.585146] [814f282f] ? __mutex_lock_common+0x369/0x39a
[ 28.585146] [8108f830] ? trace_hardirqs_on_caller+0x12d/0x164
[ 28.585146] [814f296f] mutex_lock_nested+0x40/0x45
[ 28.585146] [a02919ba] find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [a029367e] handler_new_ref+0x42/0x18a [videodev]
[ 28.585146] [a0293833] v4l2_ctrl_add_handler+0x6d/0x97
[videodev]
[ 28.585146] [a028f71b] v4l2_device_register_subdev+0x16c/0x257
[videodev]
[ 28.585146] [a02ddfe9] ivtv_gpio_init+0x14e/0x159 [ivtv]
[ 28.585146] [a02ebd57] ivtv_probe+0xdc4/0x1662 [ivtv]
[ 28.585146] [8108f6c3] ? mark_held_locks+0x55/0x95
[ 28.585146] [814f41df] ? _raw_spin_unlock_irqrestore+0x4d/0x61
[ 28.585146] [8126a12b] local_pci_probe+0x44/0x75
[ 28.585146] [8126acb1] pci_device_probe+0xd0/0xff
[ 28.585146] [81314bef] driver_probe_device+0x131/0x213
[ 28.585146] [81314d2f] __driver_attach+0x5e/0x82
[ 28.585146] [81314cd1] ? driver_probe_device+0x213/0x213
[
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Sat, 2011-09-17 at 11:34 +0200, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
All of the logging messages could be
prefixed by the printk subsystem if you
add #define pr_fmt before any #include
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c
[]
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
[]
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
[]
+ switch (mux_id) {
[]
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
pr_err(Invalid mux id #%d\n, mux_id);
[]
+static int __init camera_init(void)
[]
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+nCAM_VD_SEL);
pr_err(Failed to get GPIO nCAM_VD_SEL(%d)\n,
nCAM_VD_SEL);
etc.
--
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 4/4] v4l2: add blackfin capture bridge driver
One more clean-up possibility:
On Tue, 13 Sep 2011, Scott Jiang wrote:
this is a v4l2 bridge driver for Blackfin video capture device,
support ppi interface
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
[snip]
diff --git a/drivers/media/video/blackfin/bfin_capture.c
b/drivers/media/video/blackfin/bfin_capture.c
new file mode 100644
index 000..24f89f2
--- /dev/null
+++ b/drivers/media/video/blackfin/bfin_capture.c
@@ -0,0 +1,1099 @@
[snip]
+static int __devinit bcap_probe(struct platform_device *pdev)
+{
+ struct bcap_device *bcap_dev;
+ struct video_device *vfd;
+ struct i2c_adapter *i2c_adap;
+ struct bfin_capture_config *config;
+ struct vb2_queue *q;
+ int ret;
+
+ config = pdev-dev.platform_data;
+ if (!config) {
+ v4l2_err(pdev-dev.driver, Unable to get board config\n);
+ return -ENODEV;
+ }
+
+ bcap_dev = kzalloc(sizeof(*bcap_dev), GFP_KERNEL);
+ if (!bcap_dev) {
+ v4l2_err(pdev-dev.driver, Unable to alloc bcap_dev\n);
+ return -ENOMEM;
+ }
+
+ bcap_dev-cfg = config;
+
+ bcap_dev-ppi = create_ppi_instance(config-ppi_info);
+ if (!bcap_dev-ppi) {
+ v4l2_err(pdev-dev.driver, Unable to create ppi\n);
+ ret = -ENODEV;
+ goto err_free_dev;
+ }
+ bcap_dev-ppi-priv = bcap_dev;
+
+ bcap_dev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev);
+ if (IS_ERR(bcap_dev-alloc_ctx)) {
+ ret = PTR_ERR(bcap_dev-alloc_ctx);
+ goto err_free_ppi;
+ }
+
+ vfd = video_device_alloc();
+ if (!vfd) {
+ ret = -ENOMEM;
+ v4l2_err(pdev-dev.driver, Unable to alloc video device\n);
+ goto err_cleanup_ctx;
+ }
+
+ /* initialize field of video device */
+ vfd-release= video_device_release;
+ vfd-fops = bcap_fops;
+ vfd-ioctl_ops = bcap_ioctl_ops;
+ vfd-tvnorms= 0;
+ vfd-v4l2_dev = bcap_dev-v4l2_dev;
+ set_bit(V4L2_FL_USE_FH_PRIO, vfd-flags);
+ strncpy(vfd-name, CAPTURE_DRV_NAME, sizeof(vfd-name));
+ bcap_dev-video_dev = vfd;
+
+ ret = v4l2_device_register(pdev-dev, bcap_dev-v4l2_dev);
+ if (ret) {
+ v4l2_err(pdev-dev.driver,
+ Unable to register v4l2 device\n);
+ goto err_release_vdev;
+ }
+ v4l2_info(bcap_dev-v4l2_dev, v4l2 device registered\n);
+
+ spin_lock_init(bcap_dev-lock);
+ /* initialize queue */
+ q = bcap_dev-buffer_queue;
+ memset(q, 0, sizeof(*q));
This is superfluous: bcap_dev is allocated with kzalloc().
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v3.2] [media] saa7164: Adding support for HVR2200 card id 0x8953
Hi Mauro, Please pull 92aa36f8f9d19b7c47ad3daca15aa0932254246b from git://git.kernellabs.com/stoth/saa7164-dev.git Another SAA7164 HVR220 card profile. http://git.kernellabs.com/?p=stoth/saa7164-dev.git;a=commit;h=92aa36f8f9d19b7c47ad3daca15aa0932254246b drivers/media/video/saa7164/saa7164-cards.c | 62 +++ drivers/media/video/saa7164/saa7164-dvb.c |1 + drivers/media/video/saa7164/saa7164.h |1 + Thanks, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On 09/17/2011 11:34 AM, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
...
+
+static int __init camera_init(void)
+{
+ int ret = -EINVAL;
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+nCAM_VD_SEL);
+ goto err;
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
direction\n,
+nCAM_VD_SEL);
+ goto err_vdsel;
+ }
How about replacing gpio_request + gpio_direction_output with:
gpio_request_one(nCAM_VD_SEL, GPIOF_OUT_INIT_HIGH, nCAM_VD_SEL);
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 2, T2_GPIO2) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO T2_GPIO2(%d)\n,
+EVM_TWL_GPIO_BASE + 2);
+ goto err_vdsel;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 2, 0) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO T2_GPIO2(%d)
direction\n,
+EVM_TWL_GPIO_BASE + 2);
+ goto err_2;
+ }
gpio_request_one(EVM_TWL_GPIO_BASE + 2, GPIOF_OUT_INIT_LOW, T2_GPIO2);
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 8, nCAM_VD_EN) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_EN(%d)\n,
+EVM_TWL_GPIO_BASE + 8);
+ goto err_2;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 8, 0) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_EN(%d)
direction\n,
+EVM_TWL_GPIO_BASE + 8);
+ goto err_8;
+ }
...and gpio_request_one(EVM_TWL_GPIO_BASE + 8, GPIOF_OUT_INIT_LOW,
nCAM_VD_EN) ?
+
+ omap3evm_set_mux(MUX_CAMERA_SENSOR);
+
+
+ ret = omap3_init_camera(isp_platform_data);
+ if (ret 0)
+ goto err_8;
+ return 0;
+
+err_8:
+ gpio_free(EVM_TWL_GPIO_BASE + 8);
+err_2:
+ gpio_free(EVM_TWL_GPIO_BASE + 2);
+err_vdsel:
+ gpio_free(nCAM_VD_SEL);
+err:
+ return ret;
+}
+
+device_initcall(camera_init);
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Sunday 18 September 2011 00:00:16 Sylwester Nawrocki wrote:
On 09/17/2011 11:34 AM, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
...
+
+static int __init camera_init(void)
+{
+ int ret = -EINVAL;
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+ nCAM_VD_SEL);
+ goto err;
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
direction\n, +nCAM_VD_SEL);
+ goto err_vdsel;
+ }
How about replacing gpio_request + gpio_direction_output with:
gpio_request_one(nCAM_VD_SEL, GPIOF_OUT_INIT_HIGH, nCAM_VD_SEL);
I'd even propose gpio_request_array().
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 2, T2_GPIO2) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO T2_GPIO2(%d)\n,
+ EVM_TWL_GPIO_BASE + 2);
+ goto err_vdsel;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 2, 0) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO T2_GPIO2(%d)
direction\n,
+ EVM_TWL_GPIO_BASE + 2);
+ goto err_2;
+ }
gpio_request_one(EVM_TWL_GPIO_BASE + 2, GPIOF_OUT_INIT_LOW, T2_GPIO2);
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 8, nCAM_VD_EN) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_EN(%d)\n,
+ EVM_TWL_GPIO_BASE + 8);
+ goto err_2;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 8, 0) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_EN(%d)
direction\n, +EVM_TWL_GPIO_BASE + 8);
+ goto err_8;
+ }
...andgpio_request_one(EVM_TWL_GPIO_BASE + 8, GPIOF_OUT_INIT_LOW,
nCAM_VD_EN) ?
+
+ omap3evm_set_mux(MUX_CAMERA_SENSOR);
+
+
+ ret = omap3_init_camera(isp_platform_data);
+ if (ret 0)
+ goto err_8;
+ return 0;
+
+err_8:
+ gpio_free(EVM_TWL_GPIO_BASE + 8);
+err_2:
+ gpio_free(EVM_TWL_GPIO_BASE + 2);
+err_vdsel:
+ gpio_free(nCAM_VD_SEL);
+err:
+ return ret;
+}
+
+device_initcall(camera_init);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap_vout: Add poll() support
On Wednesday 31 August 2011 14:24:52 Laurent Pinchart wrote:
Hi Vaibhav,
Any opinion on this patch ?
Ping ?
On Wednesday 24 August 2011 12:27:49 Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap/omap_vout.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c index a1f3c0f..cfc1705 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1184,6 +1184,15 @@ static void omap_vout_buffer_release(struct
videobuf_queue *q, /*
* File operations
*/
+static unsigned int omap_vout_poll(struct file *file,
+ struct poll_table_struct *wait)
+{
+ struct omap_vout_device *vout = file-private_data;
+ struct videobuf_queue *q = vout-vbq;
+
+ return videobuf_poll_stream(file, q, wait);
+}
+
static void omap_vout_vm_open(struct vm_area_struct *vma)
{
struct omap_vout_device *vout = vma-vm_private_data;
@@ -2175,6 +2184,7 @@ static const struct v4l2_ioctl_ops vout_ioctl_ops =
{
static const struct v4l2_file_operations omap_vout_fops = {
.owner = THIS_MODULE,
+ .poll = omap_vout_poll,
.unlocked_ioctl = video_ioctl2,
.mmap = omap_vout_mmap,
.open = omap_vout_open,
--
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
HVR-1600 and HVR-1250
I'm not sure if this is the right list or not but I thought I would give it a try. I've got a HVR-1600 which works great and I can get MythTV to record an analog and digital at the same time. I decided that I needed a second tuner to record another digital signal. I picked up an HVR-1250 (Linux sees it as a HVR-1255). It's one of the newer cards in the 22xxx model. Once I got it setup I could record two digtal's no problem but my analog on the 1600 lost audio. It also won't tune above ch 13. I'm wondering if there is anything I can do to get these cards to play nicely. Thanks Stephen -- 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: HVR-1600 and HVR-1250
Stephen Atkins stephen.atk...@gmail.com wrote: I'm not sure if this is the right list or not but I thought I would give it a try. I've got a HVR-1600 which works great and I can get MythTV to record an analog and digital at the same time. I decided that I needed a second tuner to record another digital signal. I picked up an HVR-1250 (Linux sees it as a HVR-1255). It's one of the newer cards in the 22xxx model. Once I got it setup I could record two digtal's no problem but my analog on the 1600 lost audio. It also won't tune above ch 13. I'm wondering if there is anything I can do to get these cards to play nicely. Thanks Stephen -- 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 Try blacklisting the cx18 module in /etc/modprobe.d/foo, and then have a script modprobe the cx18 module later after all the IO at boot has settled down. -Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uclinux-dist-devel] [PATCH 3/4] v4l2: add vs6624 sensor driver
On Wed, Sep 14, 2011 at 03:28, Scott Jiang wrote: +#ifdef CONFIG_VIDEO_ADV_DEBUG just use DEBUG ? no, v4l2 use CONFIG_VIDEO_ADV_DEBUG ok, i was thinking this was something we added (since we have ADVxxx parts) + v4l_info(client, chip found @ 0x%02x (%s)\n, + client-addr 1, client-adapter-name); is that 1 correct ? i dont think so ... every driver under media I see use this, so what's wrong? meh, they're all wrong imo then :p. they're shifting the address to accommodate datasheets that incorrectly specify the i2c address with the read/write as bit 0. but it's fine for this driver to do that if it's the standard that the rest of the v4l code has adopted. -mike -- 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
