[PATCH v2] 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).
Sigend-off-by: Martin Hostettler martin at neutronstar.dyndns.org
---
drivers/media/video/v4l2-subdev.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index b7967c9..179e20e 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -173,6 +173,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
RE: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Monday, September 19, 2011 3:29 AM
To: Martin Hostettler
Cc: Tony Lindgren; linux-o...@vger.kernel.org; linux-
me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based
camera board.
Hi Martin,
On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
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
+ *
[Hiremath, Vaibhav] The file below seems copied from (which is coming from all
older releases of TI)
http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm-camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c049e3cb32a5b7d9d401fc31
So I would appreciate if you keep original copyright and authorship of the file
and add your sign-off to the patch.
Thanks,
Vaibhav
+ * 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 = {
Re: [PATCH 1/3] v4l: Extend V4L2_CID_COLORFX control with AQUA effect
Hi Laurent,
I am not representing Sylwester :), But with a similar sensor I use,
Aqua means cool tone which is Cb/Cr manipulations.
Regards,
Subash
On 09/19/2011 04:38 AM, Laurent Pinchart wrote:
Hi Sylwester,
Thanks for the patch.
On Friday 16 September 2011 19:05:28 Sylwester Nawrocki wrote:
Add V4L2_COLORFX_AQUA image effect in the V4L2_CID_COLORFX menu.
What's the aqua effect ?
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml |5 +++--
include/linux/videodev2.h|1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml index 8516401..f3c6457
100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -294,8 +294,9 @@ minimum value disables backlight compensation./entry
constantV4L2_COLORFX_SKETCH/constant (5),
constantV4L2_COLORFX_SKY_BLUE/constant (6),
constantV4L2_COLORFX_GRASS_GREEN/constant (7),
-constantV4L2_COLORFX_SKIN_WHITEN/constant (8) and
-constantV4L2_COLORFX_VIVID/constant (9)./entry
+constantV4L2_COLORFX_SKIN_WHITEN/constant (8),
+constantV4L2_COLORFX_VIVID/constant (9) and
+constantV4L2_COLORFX_AQUA/constant (10)./entry
/row
row
entryconstantV4L2_CID_ROTATE/constant/entry
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..5032226 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1144,6 +1144,7 @@ enum v4l2_colorfx {
V4L2_COLORFX_GRASS_GREEN = 7,
V4L2_COLORFX_SKIN_WHITEN = 8,
V4L2_COLORFX_VIVID = 9,
+ V4L2_COLORFX_AQUA = 10,
};
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
--
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 Sun, Sep 18, 2011 at 11:58:55PM +0200, Laurent Pinchart wrote: Hi Martin, On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: 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 + 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); Please don't use device_initcall(), but call the function directly from the OMAP3 EVM init handler. Otherwise camera_init() will be called if OMAP3 EVM support is compiled in the kernel, regardless of the board the kernel runs on. Ok, will do. In which header should the prototyp of that function go? Or can i just add a prototyp to board-omap3evm.c directly? I couldn't find anything that looked right, this is rather board specific after all. - Martin Hostettler -- 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] v4l subdev: add dispatching for VIDIOC_DBG_G_REGISTER and VIDIOC_DBG_S_REGISTER.
On Mon, Sep 19, 2011 at 12:53:07AM +0200, Laurent Pinchart wrote: Hi Martin, Thanks for the patch. On Saturday 17 September 2011 11:26:36 Martin Hostettler wrote: 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). Can we get your SoB line ? If you resubmit the patch, please fold the commit message at 72 columns to keep git happy. Yes, of course. Seems i forgot it. --- 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 Is this needed ? No, it's an leftover. I'll resend a patch fixed patch. - Martin Hostettler -- 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.
Hi Martin, On Monday 19 September 2011 08:10:19 mar...@neutronstar.dyndns.org wrote: On Sun, Sep 18, 2011 at 11:58:55PM +0200, Laurent Pinchart wrote: On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: 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 + 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); Please don't use device_initcall(), but call the function directly from the OMAP3 EVM init handler. Otherwise camera_init() will be called if OMAP3 EVM support is compiled in the kernel, regardless of the board the kernel runs on. Ok, will do. In which header should the prototyp of that function go? Or can i just add a prototyp to board-omap3evm.c directly? I couldn't find anything that looked right, this is rather board specific after all. You can either create arch/arm/mach-omap2/board-omap3evm.h or add the prototype to board-omap3evm.c. -- 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 v2] v4l subdev: add dispatching for VIDIOC_DBG_G_REGISTER and VIDIOC_DBG_S_REGISTER.
Hi Martin,
On Monday 19 September 2011 08:04:56 Martin Hostettler wrote:
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).
Sigend-off-by: Martin Hostettler martin at neutronstar.dyndns.org
I assume you mean Signed-off-by :-)
git commit -s avoid such mistakes.
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c index b7967c9..179e20e 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -173,6 +173,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;
--
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 0/2] Patches for TVP7002
On Sunday, September 18, 2011 20:05:42 Mauro Carvalho Chehab wrote: Em 03-08-2010 05:18, mats.randga...@tandberg.com escreveu: From: Mats Randgaard mats.randga...@tandberg.com The patch TVP7002: Changed register values depends on http://www.mail- archive.com/linux-media@vger.kernel.org/msg20769.html Hmm... those patches still apply over the latest development tree. I didn't saw any comments about it. Are they still applicable? Yes, they are still applicable. Weird, we all must have lost track of these two patches. Regards, Hans Mats Randgaard (2): TVP7002: Return V4L2_DV_INVALID if any of the errors occur. TVP7002: Changed register values. drivers/media/video/tvp7002.c | 14 -- 1 files changed, 4 insertions(+), 10 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 -- 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 09/19/2011 01:02 AM, Laurent Pinchart wrote: On Saturday 17 September 2011 14:07:30 Sylwester Nawrocki wrote: On 09/17/2011 12:54 PM, Laurent Pinchart wrote: 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 In that specific case I would likely connect to HREF signal to the ISP HSYNC signal and ignore the sensor HSYNC signal completely :-) AFAICS there can be also its vertical counterpart - VREF. OK, your HREF signal is thus completely unrelated to my DVAL signal. DVAL really qualifies pixel. For instance, if the sensor outputs pixels at half the pixel rate, DVAL would switch at every pixel clock cycle during a line. Yeah, sounds it's entirely different. 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). LINE_VALID/FRAME_VALID are HSYNC/VSYNC. I would say these are rather inverted horizontal/vertical blanking signal. 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 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/RFC 1/2] v4l2: Add the parallel bus HREF signal polarity flags
Hi Laurent, On 09/19/2011 01:05 AM, Laurent Pinchart wrote: On Saturday 17 September 2011 18:06:20 Sylwester Nawrocki wrote: On 09/17/2011 02:34 PM, Guennadi Liakhovetski wrote: On Sat, 17 Sep 2011, Sylwester Nawrocki wrote: On 09/17/2011 12:54 PM, Laurent Pinchart wrote: 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.. :-) 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) Shouldn't this be handled through platform data only ? Indeed, this is how it's done now and I didn't intend to change that. I just wanted to replace driver's private signal polarity flag definitions with the standard ones. Do you think I should rather keep these things in driver's public header? It's of course a way of less resistance :) To make things complete I thought about adding the FIELD flags, i.e. From 9bd11f9b14dffe877f9c546e068b4b4027c9472a Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki s.nawro...@samsung.com Date: Sun, 18 Sep 2011 11:28:58 +0200 Subject: [PATCH 1/2] v4l2: Add the parallel bus HREF and FIELD signal polarity flags HREF is a signal gating valid data during single line transmission. FIELD is an Even/Odd field selection signal, as specified in ITU-R BT.601 standard. Add corresponding flags for these signals to the set of media bus signal polarity flags. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- include/media/v4l2-mediabus.h | 20 +--- 1 files changed, 13 insertions(+), 7 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..1952d9f 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -23,15 +23,21 @@ #define V4L2_MBUS_MASTER (1 0) #define V4L2_MBUS_SLAVE(1 1) /* Which signal polarities it supports */ -/* Note: in BT.656 mode HSYNC and VSYNC are unused */ +/* Note: in BT.656 mode HSYNC, HREF, FIELD, 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) +/* HREF is a horizontal window reference signal gating valid pixel data */ +#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) +/* Field selection signal for interlaced scan mode */ +#define V4L2_MBUS_FIELD_ACTIVE_HIGH(1 12) +#define V4L2_MBUS_FIELD_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.4.1 If there is more objection to the above changes then I'll drop the patch and stay with driver's private definitions. Thanks, -- 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
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
consistent or timely with applying drivers/misc/ patches. It deserves
better.
[added him to Cc: list]
I do try to handle patches sent to me for misc/ in time for the
different merge windows as that directory contains drivers that have
moved out of the staging/ directory.
But yes, I'm not the overall drivers/misc/ maintainer, do we really need
one? If so, I can easily start maintaining a development tree for it to
keep it separate for the different driver authors to send me stuff and
start tracking it more for real if Arnd doesn't want to do it.
We need for the patches to be applied in a timely manner.
Sometimes when there is no real maintainer, that does not happen.
I think the other equally import aspect of maintainership that
drivers/misc (and drivers/char) needs is someone who says no to
stuff that doesn't belong there and helps submitters to find a
proper place where appropriate and to come up with a proper user
interface abstraction.
I'm definitely willing to do that part.
Greg, how about we both formally take ownership of driver/{misc,char}
and you track the patches while I do the bulk of the reviews? You
are definitely better than me with the patch tracking workflow.
Arnd
--
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
群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万。
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万广交会买家资源： 赠送的500万买家资源库，每月更新 。
3、超级海外买家Email搜索机： 每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625...@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625...@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625...@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
[PATCH 4/4 v2][FOR 3.1] v4l2: add blackfin capture bridge driver
this is a v4l2 bridge driver for Blackfin video capture device,
support ppi interface
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile|2 +
drivers/media/video/blackfin/Kconfig| 10 +
drivers/media/video/blackfin/Makefile |2 +
drivers/media/video/blackfin/bfin_capture.c | 1114 +++
drivers/media/video/blackfin/ppi.c | 201 +
include/media/blackfin/bfin_capture.h | 33 +
include/media/blackfin/ppi.h| 63 ++
8 files changed, 1427 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/blackfin/Kconfig
create mode 100644 drivers/media/video/blackfin/Makefile
create mode 100644 drivers/media/video/blackfin/bfin_capture.c
create mode 100644 drivers/media/video/blackfin/ppi.c
create mode 100644 include/media/blackfin/bfin_capture.h
create mode 100644 include/media/blackfin/ppi.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 1c03abf..52cd491 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -602,6 +602,8 @@ source drivers/media/video/davinci/Kconfig
source drivers/media/video/omap/Kconfig
+source drivers/media/video/blackfin/Kconfig
+
source drivers/media/video/bt8xx/Kconfig
config VIDEO_PMS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 03b55ed..227a700 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -177,6 +177,8 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC)+= s5p-fimc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
+obj-$(CONFIG_BLACKFIN) += blackfin/
+
obj-$(CONFIG_ARCH_DAVINCI) += davinci/
obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o
diff --git a/drivers/media/video/blackfin/Kconfig
b/drivers/media/video/blackfin/Kconfig
new file mode 100644
index 000..ecd5323
--- /dev/null
+++ b/drivers/media/video/blackfin/Kconfig
@@ -0,0 +1,10 @@
+config VIDEO_BLACKFIN_CAPTURE
+ tristate Blackfin Video Capture Driver
+ depends on VIDEO_V4L2 BLACKFIN I2C
+ select VIDEOBUF2_DMA_CONTIG
+ help
+ V4L2 bridge driver for Blackfin video capture device.
+ Choose PPI or EPPI as its interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bfin_video_capture.
diff --git a/drivers/media/video/blackfin/Makefile
b/drivers/media/video/blackfin/Makefile
new file mode 100644
index 000..aa3a0a2
--- /dev/null
+++ b/drivers/media/video/blackfin/Makefile
@@ -0,0 +1,2 @@
+bfin_video_capture-objs := bfin_capture.o ppi.o
+obj-$(CONFIG_VIDEO_BLACKFIN_CAPTURE) += bfin_video_capture.o
diff --git a/drivers/media/video/blackfin/bfin_capture.c
b/drivers/media/video/blackfin/bfin_capture.c
new file mode 100644
index 000..30ed8bb
--- /dev/null
+++ b/drivers/media/video/blackfin/bfin_capture.c
@@ -0,0 +1,1114 @@
+/*
+ * Analog Devices video capture driver
+ *
+ * Copyright (c) 2011 Analog Devices Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/completion.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/types.h
+
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
+
+#include asm/dma.h
+
+#include media/blackfin/bfin_capture.h
+
+#define CAPTURE_DRV_NAMEbfin_capture
+#define BCAP_MIN_NUM_BUF2
+
+struct bcap_format {
+ u8 *desc;
+ u32 pixelformat;
+ enum v4l2_mbus_pixelcode mbus_code;
+ int bpp; /* bits per pixel */
+};
+
+struct bcap_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+struct bcap_device {
+ /* capture device instance */
+ struct v4l2_device v4l2_dev;
+ /* device node data */
+ struct video_device *video_dev;
+ /* sub device instance */
+ struct v4l2_subdev *sd;
+ /* capture config */
+ struct
[PATCH 1/4 v2][FOR 3.1] v4l2: add vb2_get_unmapped_area in vb2 core
no mmu system needs get_unmapped_area file operations to do mmap
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
drivers/media/video/videobuf2-core.c | 31 +++
include/media/videobuf2-core.h |7 +++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 3015e60..02a0ec6 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1344,6 +1344,37 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct
*vma)
}
EXPORT_SYMBOL_GPL(vb2_mmap);
+#ifndef CONFIG_MMU
+unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
+ unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags)
+{
+ unsigned long off = pgoff PAGE_SHIFT;
+ struct vb2_buffer *vb;
+ unsigned int buffer, plane;
+ int ret;
+
+ if (q-memory != V4L2_MEMORY_MMAP) {
+ dprintk(1, Queue is not currently set up for mmap\n);
+ return -EINVAL;
+ }
+
+ /*
+* Find the plane corresponding to the offset passed by userspace.
+*/
+ ret = __find_plane_by_offset(q, off, buffer, plane);
+ if (ret)
+ return ret;
+
+ vb = q-bufs[buffer];
+
+ return (unsigned long)vb2_plane_vaddr(vb, plane);
+}
+EXPORT_SYMBOL_GPL(vb2_get_unmapped_area);
+#endif
+
static int __vb2_init_fileio(struct vb2_queue *q, int read);
static int __vb2_cleanup_fileio(struct vb2_queue *q);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f87472a..5c7b5b4 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -302,6 +302,13 @@ int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type
type);
int vb2_streamoff(struct vb2_queue *q, enum v4l2_buf_type type);
int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma);
+#ifndef CONFIG_MMU
+unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
+ unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags);
+#endif
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table
*wait);
size_t vb2_read(struct vb2_queue *q, char __user *data, size_t count,
loff_t *ppos, int nonblock);
--
1.7.0.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 3/4 v2][FOR 3.1] v4l2: add vs6624 sensor driver
this is a v4l2 sensor-level driver for the ST VS6624 camera
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
drivers/media/video/Kconfig | 10 +
drivers/media/video/Makefile |1 +
drivers/media/video/vs6624.c | 930 +
drivers/media/video/vs6624_regs.h | 337 ++
include/media/v4l2-chip-ident.h |3 +
5 files changed, 1281 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/vs6624.c
create mode 100644 drivers/media/video/vs6624_regs.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index af8ed6b..1c03abf 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -477,6 +477,16 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_VS6624
+ tristate ST VS6624 sensor support
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the ST VS6624
+ camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called vs6624.
+
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 b0329ae..03b55ed 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
+obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
obj-$(CONFIG_VIDEO_BT856) += bt856.o
obj-$(CONFIG_VIDEO_BT866) += bt866.o
diff --git a/drivers/media/video/vs6624.c b/drivers/media/video/vs6624.c
new file mode 100644
index 000..50c2aa5
--- /dev/null
+++ b/drivers/media/video/vs6624.c
@@ -0,0 +1,930 @@
+/*
+ * vs6624.c ST VS6624 CMOS image sensor driver
+ *
+ * Copyright (c) 2011 Analog Devices Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/delay.h
+#include linux/errno.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#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-mediabus.h
+
+#include vs6624_regs.h
+
+#define VGA_WIDTH 640
+#define VGA_HEIGHT 480
+#define QVGA_WIDTH 320
+#define QVGA_HEIGHT 240
+#define QQVGA_WIDTH 160
+#define QQVGA_HEIGHT120
+#define CIF_WIDTH 352
+#define CIF_HEIGHT 288
+#define QCIF_WIDTH 176
+#define QCIF_HEIGHT 144
+#define QQCIF_WIDTH 88
+#define QQCIF_HEIGHT72
+
+#define MAX_FRAME_RATE 30
+
+struct vs6624 {
+ struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct v4l2_fract frame_rate;
+ struct v4l2_mbus_framefmt fmt;
+ unsigned ce_pin;
+};
+
+static const struct vs6624_format {
+ enum v4l2_mbus_pixelcode mbus_code;
+ enum v4l2_colorspace colorspace;
+} vs6624_formats[] = {
+ {
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ },
+ {
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ },
+ {
+ .mbus_code = V4L2_MBUS_FMT_RGB565_2X8_LE,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+
+static struct v4l2_mbus_framefmt vs6624_default_fmt = {
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
+ .code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .field = V4L2_FIELD_NONE,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+};
+
+static const u16 vs6624_p1[] = {
+ 0x8104, 0x03,
+ 0x8105, 0x01,
+ 0xc900, 0x03,
+ 0xc904, 0x47,
+ 0xc905, 0x10,
+ 0xc906, 0x80,
+ 0xc907, 0x3a,
+ 0x903a, 0x02,
+ 0x903b, 0x47,
+ 0x903c, 0x15,
+ 0xc908, 0x31,
+ 0xc909, 0xdc,
+ 0xc90a, 0x80,
+ 0xc90b, 0x44,
+ 0x9044, 0x02,
+ 0x9045, 0x31,
+ 0x9046, 0xe2,
+ 0xc90c, 0x07,
+ 0xc90d, 0xe0,
+ 0xc90e, 0x80,
+ 0xc90f, 0x47,
+ 0x9047, 0x90,
+
[PATCH 2/4 v2][FOR 3.1] v4l2: add adv7183 decoder driver
this driver is a v4l2 subdevice driver to support
Analog Devices ADV7183 SDTV video decoder
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
drivers/media/video/Kconfig| 10 +
drivers/media/video/Makefile |1 +
drivers/media/video/adv7183.c | 686
drivers/media/video/adv7183_regs.h | 107 ++
include/media/adv7183.h| 47 +++
include/media/v4l2-chip-ident.h|3 +
6 files changed, 854 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/adv7183.c
create mode 100644 drivers/media/video/adv7183_regs.h
create mode 100644 include/media/adv7183.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f574dc0..af8ed6b 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -273,6 +273,16 @@ config VIDEO_ADV7180
To compile this driver as a module, choose M here: the
module will be called adv7180.
+config VIDEO_ADV7183
+ tristate Analog Devices ADV7183 decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ V4l2 subdevice driver for the Analog Devices
+ ADV7183 video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7183.
+
config VIDEO_BT819
tristate BT819A VideoStream decoder
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 2723900..b0329ae 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
+obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/video/adv7183.c b/drivers/media/video/adv7183.c
new file mode 100644
index 000..65d682c
--- /dev/null
+++ b/drivers/media/video/adv7183.c
@@ -0,0 +1,686 @@
+/*
+ * adv7183.c Analog Devices ADV7183 video decoder driver
+ *
+ * Copyright (c) 2011 Analog Devices Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/delay.h
+#include linux/errno.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/videodev2.h
+
+#include media/adv7183.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-device.h
+
+#include adv7183_regs.h
+
+struct adv7183 {
+ struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+
+ v4l2_std_id std; /* Current set standard */
+ u32 input;
+ u32 output;
+ unsigned reset_pin;
+ unsigned oe_pin;
+ struct v4l2_mbus_framefmt fmt;
+};
+
+/* EXAMPLES USING 27 MHz CLOCK
+ * Mode 1 CVBS Input (Composite Video on AIN5)
+ * All standards are supported through autodetect, 8-bit, 4:2:2, ITU-R BT.656
output on P15 to P8.
+ */
+static const unsigned char adv7183_init_regs[] = {
+ ADV7183_IN_CTRL, 0x04, /* CVBS input on AIN5 */
+ ADV7183_DIGI_CLAMP_CTRL_1, 0x00, /* Slow down digital clamps */
+ ADV7183_SHAP_FILT_CTRL, 0x41,/* Set CSFM to SH1 */
+ ADV7183_ADC_CTRL, 0x16, /* Power down ADC 1 and ADC 2 */
+ ADV7183_CTI_DNR_CTRL_4, 0x04,/* Set DNR threshold to 4 for flat
response */
+ /* ADI recommended programming sequence */
+ ADV7183_ADI_CTRL, 0x80,
+ ADV7183_CTI_DNR_CTRL_4, 0x20,
+ 0x52, 0x18,
+ 0x58, 0xED,
+ 0x77, 0xC5,
+ 0x7C, 0x93,
+ 0x7D, 0x00,
+ 0xD0, 0x48,
+ 0xD5, 0xA0,
+ 0xD7, 0xEA,
+ ADV7183_SD_SATURATION_CR, 0x3E,
+ ADV7183_PAL_V_END, 0x3E,
+ ADV7183_PAL_F_TOGGLE, 0x0F,
+ ADV7183_ADI_CTRL, 0x00,
+};
+
+static inline struct adv7183 *to_adv7183(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7183, sd);
+}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct adv7183, hdl)-sd;
+}
+
+static inline int adv7183_read(struct v4l2_subdev *sd, unsigned char reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return
RC6 decoding
The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
mode 6A. In mode 6A the decoder supports either 32-bit data (for
Microsoft's MCE RC) or 24 bit.
I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
i.e. 20 bit data. The transmitted frame format is identical to the 24
bit form so I'm curious as to what remotes transmit 24 bit data or was
this an error and it should be 20?
RC6-6-20 is explained here:
http://www.guiott.com/wrc/RC6-6.html
If 24-bit mode is in use, is there a way to select between 20 and 24 bit
operation?
I made the following simple mod to ir-rc6-decoder.c and my Sky/Sky+ RCs
decode correctly (with a custom keytable):
--- a/drivers/media/rc/ir-rc6-decoder.c 2011-05-19 06:06:34.0 +0200
+++ b/drivers/media/rc/ir-rc6-decoder.c 2011-09-19 13:02:35.0 +0200
@@ -17,14 +17,14 @@
/*
* This decoder currently supports:
* RC6-0-16(standard toggle bit in header)
- * RC6-6A-24 (no toggle bit)
+ * RC6-6A-20 (no toggle bit)
* RC6-6A-32 (MCE version with toggle bit in body)
*/
#define RC6_UNIT 44 /* us */
#define RC6_HEADER_NBITS 4 /* not including toggle bit */
#define RC6_0_NBITS16
-#define RC6_6A_SMALL_NBITS 24
+#define RC6_6A_SMALL_NBITS 20
#define RC6_6A_LARGE_NBITS 32
#define RC6_PREFIX_PULSE (6 * RC6_UNIT)
#define RC6_PREFIX_SPACE (2 * RC6_UNIT)
@@ -231,7 +231,7 @@ again:
scancode = data-body ~RC6_6A_MCE_TOGGLE_MASK;
} else {
toggle = 0;
- scancode = data-body 0xff;
+ scancode = data-body;
}
IR_dprintk(1, RC6(6A) scancode 0x%08x (toggle: %u)\n,
--
Lawrence Rust
--
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/2] misc: remove CONFIG_MISC_DEVICES
On Mon, Sep 19, 2011 at 10:47:50AM +0200, Arnd Bergmann wrote:
On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
consistent or timely with applying drivers/misc/ patches. It deserves
better.
[added him to Cc: list]
I do try to handle patches sent to me for misc/ in time for the
different merge windows as that directory contains drivers that have
moved out of the staging/ directory.
But yes, I'm not the overall drivers/misc/ maintainer, do we really need
one? If so, I can easily start maintaining a development tree for it to
keep it separate for the different driver authors to send me stuff and
start tracking it more for real if Arnd doesn't want to do it.
We need for the patches to be applied in a timely manner.
Sometimes when there is no real maintainer, that does not happen.
I think the other equally import aspect of maintainership that
drivers/misc (and drivers/char) needs is someone who says no to
stuff that doesn't belong there and helps submitters to find a
proper place where appropriate and to come up with a proper user
interface abstraction.
I'm definitely willing to do that part.
Greg, how about we both formally take ownership of driver/{misc,char}
and you track the patches while I do the bulk of the reviews? You
are definitely better than me with the patch tracking workflow.
That sounds good to me, I'll be glad to collect the patches and push
them to Linus for both of those trees (might as well keep them in the
same git tree, no need to separate them, right?) and I'll rely on you
for review and acking them. Much like I do today for the tty and serial
trees.
I'll go set up the trees locally today and when kernel.org opens back
up, make them public and add them to linux-next.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE
On Thursday 15 September 2011, Grant Likely wrote: diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..1836cdf 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool Multifunction device drivers +menuconfig MFD_CORE + tristate Multifunction device drivers depends on HAS_IOMEM - default y Looks like there is a bug here. Kconfig symbols with dependencies (HAS_IOMEM) must not ever be selected by other symbols because Kconfig doesn't implement a way to resolve them. This patch means that every select MFD_CORE just assumes that HAS_IOMEM is also selected. That is probably a fair assumption though. Almost all architectures set HAS_IOMEM unconditionally, and the other ones (probably just s390) would not select MFD_CORE. Note that Samuel already took the other patch in the end, so it doesn't matter. The patch I posted encloses the entire directory in if HAS_IOMEM. Arnd -- 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/2] misc: remove CONFIG_MISC_DEVICES
On Monday 19 September 2011, Greg KH wrote: That sounds good to me, I'll be glad to collect the patches and push them to Linus for both of those trees (might as well keep them in the same git tree, no need to separate them, right?) and I'll rely on you for review and acking them. Much like I do today for the tty and serial trees. I'll go set up the trees locally today and when kernel.org opens back up, make them public and add them to linux-next. Ok, great! Thanks, Arnd -- 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/8] ispvideo: Add support for G/S/ENUM_STD ioctl
-Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, September 16, 2011 6:36 PM To: Ravi, Deepthy Cc: linux-media@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk; linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de; Hiremath, Vaibhav Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl Hi Deepthy, On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote: On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote: On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com In order to support TVP5146 (for that matter any video decoder), it is important to support G/S/ENUM_STD ioctl on /dev/videoX device node. Why so ? Shouldn't it be queried on the subdev output pad directly ? Because standard v4l2 application for analog devices will call these std ioctls on the streaming device node. So it's done on /dev/video to make the existing apllication work. Existing applications can't work with the OMAP3 ISP (and similar complex embedded devices) without userspace support anyway, either in the form of a GStreamer element or a libv4l plugin. I still believe that analog video standard operations should be added to the subdev pad operations and exposed through subdev device nodes, exactly as done with formats. [Hiremath, Vaibhav] Laurent, I completely agree with your point that, existing application will not work without setting links properly. But I believe the assumption here is, media-controller should set the links (along with pad formants) and all existing application should work as is. Isn't it? The way it is being done currently is, set the format at the pad level which is same as analog standard resolution and use existing application for streaming... I am ok, if we add s/g/enum_std api support at sub-dev level but this should also be supported on streaming device node. Thanks, Vaibhav -- 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 v2 2/2] s5p-fimc: Convert to use generic media bus polarity flags
Switch to generic media bus signal polarity flags and allow
configuring the FIELD signal polarity.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park s.nawro...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-reg.c | 14 +-
drivers/media/video/s5p-fimc/regs-fimc.h |1 +
include/media/s5p_fimc.h |7 +--
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c
b/drivers/media/video/s5p-fimc/fimc-reg.c
index 2a1ae51..678d7d3 100644
--- a/drivers/media/video/s5p-fimc/fimc-reg.c
+++ b/drivers/media/video/s5p-fimc/fimc-reg.c
@@ -533,20 +533,24 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc,
u32 cfg = readl(fimc-regs + S5P_CIGCTRL);
cfg = ~(S5P_CIGCTRL_INVPOLPCLK | S5P_CIGCTRL_INVPOLVSYNC |
-S5P_CIGCTRL_INVPOLHREF | S5P_CIGCTRL_INVPOLHSYNC);
+S5P_CIGCTRL_INVPOLHREF | S5P_CIGCTRL_INVPOLHSYNC |
+S5P_CIGCTRL_INVPOLFIELD);
- if (cam-flags FIMC_CLK_INV_PCLK)
+ if (cam-flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg |= S5P_CIGCTRL_INVPOLPCLK;
- if (cam-flags FIMC_CLK_INV_VSYNC)
+ if (cam-flags V4L2_MBUS_VSYNC_ACTIVE_LOW)
cfg |= S5P_CIGCTRL_INVPOLVSYNC;
- if (cam-flags FIMC_CLK_INV_HREF)
+ if (cam-flags V4L2_MBUS_HSYNC_ACTIVE_LOW)
cfg |= S5P_CIGCTRL_INVPOLHREF;
- if (cam-flags FIMC_CLK_INV_HSYNC)
+ if (cam-flags V4L2_MBUS_HSYNC_ACTIVE_LOW)
cfg |= S5P_CIGCTRL_INVPOLHSYNC;
+ if (cam-flags V4L2_MBUS_FIELD_ACTIVE_LOW)
+ cfg |= S5P_CIGCTRL_INVPOLFIELD;
+
writel(cfg, fimc-regs + S5P_CIGCTRL);
return 0;
diff --git a/drivers/media/video/s5p-fimc/regs-fimc.h
b/drivers/media/video/s5p-fimc/regs-fimc.h
index 94d2302..c8e3b94 100644
--- a/drivers/media/video/s5p-fimc/regs-fimc.h
+++ b/drivers/media/video/s5p-fimc/regs-fimc.h
@@ -61,6 +61,7 @@
#define S5P_CIGCTRL_CSC_ITU601_709 (1 5)
#define S5P_CIGCTRL_INVPOLHSYNC(1 4)
#define S5P_CIGCTRL_SELCAM_MIPI(1 3)
+#define S5P_CIGCTRL_INVPOLFIELD(1 1)
#define S5P_CIGCTRL_INTERLACE (1 0)
/* Window offset 2 */
diff --git a/include/media/s5p_fimc.h b/include/media/s5p_fimc.h
index 2b58904..688fb3f 100644
--- a/include/media/s5p_fimc.h
+++ b/include/media/s5p_fimc.h
@@ -19,11 +19,6 @@ enum cam_bus_type {
FIMC_LCD_WB, /* FIFO link from LCD mixer */
};
-#define FIMC_CLK_INV_PCLK (1 0)
-#define FIMC_CLK_INV_VSYNC (1 1)
-#define FIMC_CLK_INV_HREF (1 2)
-#define FIMC_CLK_INV_HSYNC (1 3)
-
struct i2c_board_info;
/**
@@ -37,7 +32,7 @@ struct i2c_board_info;
* @i2c_bus_num: i2c control bus id the sensor is attached to
* @mux_id: FIMC camera interface multiplexer index (separate for MIPI and ITU)
* @clk_id: index of the SoC peripheral clock for sensors
- * @flags: flags defining bus signals polarity inversion (High by default)
+ * @flags: the parallel bus flags defining signals polarity (V4L2_MBUS_*)
*/
struct s5p_fimc_isp_info {
struct i2c_board_info *board_info;
--
1.7.6.3
--
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 0/2] v4l: Add media bus polarity flags for FIELD signal
Hello, The following patch adds support for FIELD signal polarity configuration through the parallel media bus flags. The second one just converts s5p-fimc driver to use generic flags. Changes since v2: - dropped V4L2_MBUS_HREF* definitions, added comment on usage of V4L2_MBUS_[HV]SYNC* flags for [HV]REF signals - added V4L2_MBUS_FIELD* - modified the second patch to use HSYNC flags only Sylwester Nawrocki (2): v4l2: Add the polarity flags for parallel camera bus FIELD signal s5p-fimc: Convert to use generic media bus polarity flags drivers/media/video/s5p-fimc/fimc-reg.c | 14 +- drivers/media/video/s5p-fimc/regs-fimc.h |1 + include/media/s5p_fimc.h |7 +-- include/media/v4l2-mediabus.h| 11 +-- 4 files changed, 20 insertions(+), 13 deletions(-) Thanks, -- 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
[PATCH v2 1/2] v4l2: Add the polarity flags for parallel camera bus FIELD signal
FIELD is an Even/Odd field selection signal, as specified in ITU-R BT.601 standard. Add corresponding flag for configuring the FIELD signal polarity. Also add a comment about usage of V4L2_MBUS_[HV]SYNC* flags for the hardware that uses [HV]REF signals. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- include/media/v4l2-mediabus.h | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..586fc44 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -22,8 +22,12 @@ */ #define V4L2_MBUS_MASTER (1 0) #define V4L2_MBUS_SLAVE(1 1) -/* Which signal polarities it supports */ -/* Note: in BT.656 mode HSYNC and VSYNC are unused */ +/* + * Signal polarity flags + * Note: in BT.656 mode HSYNC, FIELD, and VSYNC are unused + * V4L2_MBUS_[HV]SYNC_* flags should be also used for specifying + * configuration of hardware that uses [HV]REF signals + */ #define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 2) #define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3) #define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 4) @@ -32,6 +36,9 @@ #define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 7) #define V4L2_MBUS_DATA_ACTIVE_HIGH (1 8) #define V4L2_MBUS_DATA_ACTIVE_LOW (1 9) +/* Field selection signal for interlaced scan mode */ +#define V4L2_MBUS_FIELD_ACTIVE_HIGH(1 12) +#define V4L2_MBUS_FIELD_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.6.3 -- 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 v3 1/2] v4l2: Add the polarity flags for parallel camera bus FIELD signal
FIELD is an Even/Odd field selection signal, as specified in ITU-R BT.601 standard. Add corresponding flag for configuring the FIELD signal polarity. Also add a comment about usage of V4L2_MBUS_[HV]SYNC* flags for the hardware that uses [HV]REF signals. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Resending with proper bit assignment. --- include/media/v4l2-mediabus.h | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..f3a61ab 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -22,8 +22,12 @@ */ #define V4L2_MBUS_MASTER (1 0) #define V4L2_MBUS_SLAVE(1 1) -/* Which signal polarities it supports */ -/* Note: in BT.656 mode HSYNC and VSYNC are unused */ +/* + * Signal polarity flags + * Note: in BT.656 mode HSYNC, FIELD, and VSYNC are unused + * V4L2_MBUS_[HV]SYNC_* flags should be also used for specifying + * configuration of hardware that uses [HV]REF signals + */ #define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 2) #define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3) #define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 4) @@ -32,6 +36,9 @@ #define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 7) #define V4L2_MBUS_DATA_ACTIVE_HIGH (1 8) #define V4L2_MBUS_DATA_ACTIVE_LOW (1 9) +/* Field selection signal for interlaced scan mode */ +#define V4L2_MBUS_FIELD_ACTIVE_HIGH(1 10) +#define V4L2_MBUS_FIELD_ACTIVE_LOW (1 11) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.6.3 -- 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.2] noon010pc30 conversion to the pad level ops
Mauro, please pull from my tree for a few noon01pc30 driver updates. This is conversion to the pad level ops and the subdev user-space API and other related modifications. The following changes since commit e27412f5a5966629e3d4213c78a539068ca0ea26: [media] mmp_camera: add MODULE_ALIAS (2011-09-18 08:05:43 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l_noon010pc30 Sylwester Nawrocki (3): noon010pc30: Conversion to the media controller API noon010pc30: Improve s_power operation handling noon010pc30: Remove g_chip_ident operation handler drivers/media/video/Kconfig |2 +- drivers/media/video/noon010pc30.c | 266 +++- include/media/v4l2-chip-ident.h |3 - 3 files changed, 171 insertions(+), 100 deletions(-) Best 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
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:Mon Sep 19 19:00:14 CEST 2011 git hash:e27412f5a5966629e3d4213c78a539068ca0ea26 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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 v2] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi
On Sun, 18 Sep 2011, Laurent Pinchart wrote:
Hi Martin,
On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
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 @@
[snip]
+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;
+ }
+
+ 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;
+ }
+
+ 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;
+ }
+
+ 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);
Please don't use device_initcall(), but call the function directly from the
OMAP3 EVM init handler. Otherwise camera_init() will be called if OMAP3 EVM
support is compiled in the kernel, regardless of the board the kernel runs on.
Another possibility is to put
if (!machine_is_omap3evm())
return 0;
in the beginning of the function. Probably, best to follow what other
omap3 boards do.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, September 19, 2011 3:29 AM To: Martin Hostettler Cc: Tony Lindgren; linux-o...@vger.kernel.org; linux- me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board. Hi Martin, On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: 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 + * [Hiremath, Vaibhav] The file below seems copied from (which is coming from all older releases of TI) http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm-camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c049e3cb32a5b7d9d401fc31 So I would appreciate if you keep original copyright and authorship of the file and add your sign-off to the patch. First of all i don't have any problem Adding your name and the TI copyright. Maybe i should have been more careful when looking at and adeption omap3evm_set_mux as i really took that from the TI code. I honestly don't remember if i took any other code from that file or not. It ends up doing what the hardware needs anyway. For me it doesn't matter with such trival things, but i should have been more careful. Do you consider it resolved if use the following at the start? /* * Copyright (C) 2010 Texas Instruments Inc * Copyright (C) 2010-2011 Lund Engineering * Contact: Gil Lund gwl...@lundeng.com * Authors: *Vaibhav Hiremath hvaib...@ti.com *Martin Hostettler mar...@neutronstar.dyndns.org */ But then again the copy on my harddisk has these too... * Contributors: * Anuj Aggarwal anuj.aggar...@ti.com * Sivaraj R siva...@ti.com Maybe i should add them too. Not sure really... - Martin Hostettler -- 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] v4l: Add driver for Micron MT9M032 camera sensor
Hi Laurent just one question: On Mon, 19 Sep 2011, Laurent Pinchart wrote: 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 @@ [snip] +static int mt9m032_read_reg(struct mt9m032 *sensor, const u8 reg) No need for the const keyword, this isn't a pointer :-) I was actually wondering about these: of course it's not the same as using const for a pointer to tell the compiler, that this function will not change caller's data. But - doesn't using const for any local variable tell the compiler, that that _variable_ will not be modified in this function? Are there no optimisation possibilities, arising from that? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 12:09 PM
To: Valkeinen, Tomi
Cc: Hiremath, Vaibhav; linux-o...@vger.kernel.org; Taneja, Archit; linux-
me...@vger.kernel.org; Molnar, Lajos
Subject: [PATCH v2 1/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha
compatibility setting
[Hiremath, Vaibhav] Few minor comments below -
On OMAP3, in order to enable alpha blending for LCD and TV managers, we
needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are
set,
we switch to an OMAP3 compatibility mode where the zorder values in the
pipeline
[Hiremath, Vaibhav] Spelling mistake???
attribute registers are ignored and a fixed priority is configured.
Rename the manager_info member alpha_enabled to partial_alpha_enabled
for
more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and
OMAP4
alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2
user is
expected to check for the ZORDER cap, if an overlay doesn't have this cap,
the
user is expected to set the parameter partial_alpha_enabled. If the
overlay has
ZORDER cap, the DSS2 user can assume that alpha blending is already
enabled.
Don't support OMAP3 compatibility mode for now. Trying to read/write to
alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does
not
set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.
Change alpha_enabled to partial_alpha_enabled int the omap_vout driver.
Use
overlay cap OMAP_DSS_OVL_CAP_GLOBAL_ALPHA to check if overlay supports
alpha
blending or not. Replace this with checks for VIDEO1 pipeline.
Initial patch was made by: Lajos Molnar mol...@ti.com
[Hiremath, Vaibhav] I think you can put his sign-off as well and remove this
line or move it below ---
Cc: linux-media@vger.kernel.org
Cc: Lajos Molnar mol...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 16 +++-
drivers/video/omap2/dss/dispc.c| 24
drivers/video/omap2/dss/dss.h |4 ++--
drivers/video/omap2/dss/dss_features.c | 22 +++---
drivers/video/omap2/dss/dss_features.h |3 ++-
drivers/video/omap2/dss/manager.c | 28 +++
-
include/video/omapdss.h|3 ++-
7 files changed, 59 insertions(+), 41 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index b3a5ecd..95daf98 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1165,12 +1165,17 @@ static int vidioc_try_fmt_vid_overlay(struct file
*file, void *fh,
{
int ret = 0;
struct omap_vout_device *vout = fh;
+ struct omap_overlay *ovl;
+ struct omapvideo_info *ovid;
struct v4l2_window *win = f-fmt.win;
+ ovid = vout-vid_info;
+ ovl = ovid-overlays[0];
+
[Hiremath, Vaibhav] I think it will be helpful if you put some comment above
this line on why video1, something like,
/*
* Global alpha is not supported on Video1 pipeline/overlay
*/
ret = omap_vout_try_window(vout-fbuf, win);
if (!ret) {
- if (vout-vid == OMAP_VIDEO1)
+ if ((ovl-caps OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
win-global_alpha = 255;
else
win-global_alpha = f-fmt.win.global_alpha;
@@ -1194,8 +1199,7 @@ static int vidioc_s_fmt_vid_overlay(struct file
*file, void *fh,
ret = omap_vout_new_window(vout-crop, vout-win, vout-fbuf,
win);
if (!ret) {
- /* Video1 plane does not support global alpha */
- if (ovl-id == OMAP_DSS_VIDEO1)
+ if ((ovl-caps OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
vout-win.global_alpha = 255;
else
vout-win.global_alpha = f-fmt.win.global_alpha;
@@ -1788,7 +1792,9 @@ static int vidioc_s_fbuf(struct file *file, void *fh,
if (ovl-manager ovl-manager-get_manager_info
ovl-manager-set_manager_info) {
ovl-manager-get_manager_info(ovl-manager, info);
- info.alpha_enabled = enable;
+ /* enable this only if there is no zorder cap */
+ if ((ovl-caps OMAP_DSS_OVL_CAP_ZORDER) == 0)
+ info.partial_alpha_enabled = enable;
if (ovl-manager-set_manager_info(ovl-manager, info))
return -EINVAL;
}
@@ -1820,7 +1826,7 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
}
if (ovl-manager ovl-manager-get_manager_info) {
ovl-manager-get_manager_info(ovl-manager, info);
- if (info.alpha_enabled)
+ if
RE: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
-Original Message- From: mar...@neutronstar.dyndns.org [mailto:mar...@neutronstar.dyndns.org] Sent: Tuesday, September 20, 2011 12:55 AM To: Hiremath, Vaibhav Cc: Laurent Pinchart; Tony Lindgren; linux-o...@vger.kernel.org; linux- me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board. On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, September 19, 2011 3:29 AM To: Martin Hostettler Cc: Tony Lindgren; linux-o...@vger.kernel.org; linux- me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board. Hi Martin, On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: 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 + * [Hiremath, Vaibhav] The file below seems copied from (which is coming from all older releases of TI) http://arago-project.org/git/projects/?p=linux- omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm- camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c04 9e3cb32a5b7d9d401fc31 So I would appreciate if you keep original copyright and authorship of the file and add your sign-off to the patch. First of all i don't have any problem Adding your name and the TI copyright. Maybe i should have been more careful when looking at and adeption omap3evm_set_mux as i really took that from the TI code. The best practice it to always keep copy-right of the file intact... I wouldn't mind if you use and modify any part of the code and also add your authorship. I feel, Copy-right is important part. I honestly don't remember if i took any other code from that file or not. It ends up doing what the hardware needs anyway. For me it doesn't matter with such trival things, but i should have been more careful. Do you consider it resolved if use the following at the start? /* * Copyright (C) 2010 Texas Instruments Inc Change it to 2011. * Copyright (C) 2010-2011 Lund Engineering * Contact: Gil Lund gwl...@lundeng.com Not sure do you really need above line... * Authors: *Vaibhav Hiremath hvaib...@ti.com *Martin Hostettler mar...@neutronstar.dyndns.org */ Looks ok to me. But then again the copy on my harddisk has these too... * Contributors: * Anuj Aggarwal anuj.aggar...@ti.com * Sivaraj R siva...@ti.com Maybe i should add them too. Not sure really... I think we should not pollute source file with all our names, so I would recommend to put copy rights and probably author. Thanks, Vaibhav - Martin Hostettler -- 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: Question about USB interface index restriction in gspca
Am 16.09.2011 08:33, schrieb Jean-Francois Moine: On Thu, 15 Sep 2011 23:46:57 +0200 Frank Schäferfschaefer@googlemail.com wrote: For webcam devices, the interface class is meaningful only when set to USB_CLASS_VIDEO (UVC). Otherwise, I saw many different values. Does that mean that there are devices out in the wild that report for example USB_CLASS_WIRELESS_CONTROLLER for the video interface ??? For video on a particular interface, the subdriver must call the function gspca_dev_probe2() as this is done in spca1528 and xirlink_cit. Hmm, sure, that would work... But wouldn't it be better to improve the interface check and merge the two probing functions ? The subdrivers can decide which interfaces are (not) probed and the gspca core does plausability checks (e.g. bulk/isoc endpoint ? usb class ?). Generally, the first interface is the video device, and the function gspca_dev_probe() works well enough. The function gspca_dev_probe2() is used by only 2 subdrivers and the way to find the correct interface is not easy. For example, the webcam 047d:5003 (subdriver spca1528) has 3 interfaces (class vendor specific). The 1st one has only one altsetting with only one interrupt endpoint, the 2nd one has 8 altsettings, each with only one isochronous endpoint, and the last one has one altsetting with 3 endpoints (bulk in, bulk out and interrupt). At the first glance, it is easy to know the right interface, but writing generic code to handle such webcams seems rather complicated. I didn't want to say that it is easy to know the right interface. It is definitely not. But I think we could do it better than we currently do. Anyway, it seems there is no interest in such a patch. Thanks for you explanations. So, if your webcam is in the 99.99% which use the interface 0, use gspca_dev_probe(), otherwise, YOU know the right interface, so, call gspca_dev_probe2(). Isn't it also possible that we don't know the right interface and it is not interface 0 ? ;-) Regards, Frank -- 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] v4l: Add driver for Micron MT9M032 camera sensor
Hi Guennadi, On Monday 19 September 2011 21:28:09 Guennadi Liakhovetski wrote: Hi Laurent just one question: On Mon, 19 Sep 2011, Laurent Pinchart wrote: 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 @@ [snip] +static int mt9m032_read_reg(struct mt9m032 *sensor, const u8 reg) No need for the const keyword, this isn't a pointer :-) I was actually wondering about these: of course it's not the same as using const for a pointer to tell the compiler, that this function will not change caller's data. But - doesn't using const for any local variable tell the compiler, that that _variable_ will not be modified in this function? Are there no optimisation possibilities, arising from that? I would expect the compiler to be smart enough to notice that the variable is never assigned. In practice, for such a small function, the generated code is identical with and without the const keyword. -- 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 v2] v4l: Add driver for Micron MT9M032 camera sensor
On Tue, 20 Sep 2011, Laurent Pinchart wrote: Hi Guennadi, On Monday 19 September 2011 21:28:09 Guennadi Liakhovetski wrote: Hi Laurent just one question: On Mon, 19 Sep 2011, Laurent Pinchart wrote: 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 @@ [snip] +static int mt9m032_read_reg(struct mt9m032 *sensor, const u8 reg) No need for the const keyword, this isn't a pointer :-) I was actually wondering about these: of course it's not the same as using const for a pointer to tell the compiler, that this function will not change caller's data. But - doesn't using const for any local variable tell the compiler, that that _variable_ will not be modified in this function? Are there no optimisation possibilities, arising from that? I would expect the compiler to be smart enough to notice that the variable is never assigned. Sure, but using const would allow the compiler to catch and complain about uses like foo(reg); unless foo() is also declared as foo(const u8 *). But yes, for small obvious functions it makes no difference. In practice, for such a small function, the generated code is identical with and without the const keyword. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] soc-camera: mt9t112: modify delay time after initialize
Hi Guennadi, all mt9t112 camera needs 100 milliseconds for initializing Special thanks to Phil Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com Reported-by: Phil Edworthy phil.edwor...@renesas.com --- drivers/media/video/mt9t112.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9t112.c b/drivers/media/video/mt9t112.c index 7438f8d..e581d8a 100644 --- a/drivers/media/video/mt9t112.c +++ b/drivers/media/video/mt9t112.c @@ -885,7 +885,7 @@ static int mt9t112_s_stream(struct v4l2_subdev *sd, int enable) /* Invert PCLK (Data sampled on falling edge of pixclk) */ mt9t112_reg_write(ret, client, 0x3C20, param); - mdelay(5); + mdelay(100); priv-flags |= INIT_DONE; } Hi Guennadi, What's the status of this patch? It applies ok for me, and I couldn't find any reference at the ML why it was not applied yet. Hm, yeah... Looks like also this patch: Subject: [PATCH 3/3] soc-camera: mt9t112: The flag which control camera-init is removed mt9t112 should always be initialized when camera start. Because current driver doesn't run this operation, it will be un-stable if user side player run open/close several times. Special thanks to Namiki-san Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com Reported-by: Takashi Namiki takashi.nam...@renesas.com has not been applied nor discussed on the list... For patches that old I would tend to say: if the author / submitter didn't re-submit, then, probably, patches aren't relevant anymore... Although it is quite possible, that I failed to process them back then. Morimoto-san, do you have any information on these patches? Have these problems been solved somehow, so that the patches have become obsolete, or are the problems, that they address, still there? This patch is needed for mt9t112 camera initialize. I thought that it was already applied. Best regards --- Kuninori Morimoto -- 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
