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 > > #include > > > > +#include > > 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.
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 > > --- > > 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 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 Nawrocki
Signed-off-by: Kyungmin Park
---
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.
V4L2_COLORFX_SKETCH (5),
V4L2_COLORFX_SKY_BLUE (6),
V4L2_COLORFX_GRASS_GREEN (7),
-V4L2_COLORFX_SKIN_WHITEN (8) and
-V4L2_COLORFX_VIVID (9).
+V4L2_COLORFX_SKIN_WHITEN (8),
+V4L2_COLORFX_VIVID (9) and
+V4L2_COLORFX_AQUA (10).
V4L2_CID_ROTATE
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.
> -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
> > ---
> > 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
> > + * Author: Martin Hostettler
> > + *
[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
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#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;
[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 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 RESEND 0/4] davinci vpbe: enable DM365 v4l2 display driver
Sakari, Hans, Can I request you to have a look at these patches too? Thanks and Regards, -Manju On Mon, Sep 19, 2011 at 11:05:25, Hadli, Manjunath wrote: > The patchset adds incremental changes necessary to enable dm365 > v4l2 display driver, which includes vpbe display driver changes, osd specific > changes and venc changes. The changes are incremental in nature,addind a few > HD modes, and taking care of register level changes. > > The patch set does not include THS7303 amplifier driver which is planned to > be sent seperately. > > > Manjunath Hadli (4): > davinci vpbe: remove unused macro. > davinci vpbe: add dm365 VPBE display driver changes > davinci vpbe: add dm365 and dm355 specific OSD changes > davinci vpbe: add VENC block changes to enable dm365 and dm355 > > drivers/media/video/davinci/vpbe.c | 55 +++- > drivers/media/video/davinci/vpbe_display.c |1 - > drivers/media/video/davinci/vpbe_osd.c | 474 > +--- > drivers/media/video/davinci/vpbe_venc.c| 205 +++-- > include/media/davinci/vpbe.h | 16 + > include/media/davinci/vpbe_venc.h |4 + > 6 files changed, 686 insertions(+), 69 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
[PATCH RESEND 2/4] davinci vpbe: add dm365 VPBE display driver changes
This patch implements the core additions to the display driver,
mainly controlling the VENC and other encoders for dm365.
This patch also includes addition of amplifier subdevice to the
vpbe driver and interfacing with venc subdevice.
Signed-off-by: Manjunath Hadli
---
drivers/media/video/davinci/vpbe.c | 55 ++--
include/media/davinci/vpbe.h | 16 ++
2 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
index d773d30..21a8645 100644
--- a/drivers/media/video/davinci/vpbe.c
+++ b/drivers/media/video/davinci/vpbe.c
@@ -141,11 +141,12 @@ static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
return 0;
}
-static int vpbe_get_mode_info(struct vpbe_device *vpbe_dev, char *mode)
+static int vpbe_get_mode_info(struct vpbe_device *vpbe_dev, char *mode,
+ int output_index)
{
struct vpbe_config *cfg = vpbe_dev->cfg;
struct vpbe_enc_mode_info var;
- int curr_output = vpbe_dev->current_out_index;
+ int curr_output = output_index;
int i;
if (NULL == mode)
@@ -245,6 +246,8 @@ static int vpbe_set_output(struct vpbe_device *vpbe_dev,
int index)
struct encoder_config_info *curr_enc_info =
vpbe_current_encoder_info(vpbe_dev);
struct vpbe_config *cfg = vpbe_dev->cfg;
+ struct venc_platform_data *venc_device = vpbe_dev->venc_device;
+ enum v4l2_mbus_pixelcode if_params;
int enc_out_index;
int sd_index;
int ret = 0;
@@ -274,6 +277,8 @@ static int vpbe_set_output(struct vpbe_device *vpbe_dev,
int index)
goto out;
}
+ if_params = cfg->outputs[index].if_params;
+ venc_device->setup_if_config(if_params);
if (ret)
goto out;
}
@@ -293,7 +298,7 @@ static int vpbe_set_output(struct vpbe_device *vpbe_dev,
int index)
* encoder.
*/
ret = vpbe_get_mode_info(vpbe_dev,
-cfg->outputs[index].default_mode);
+cfg->outputs[index].default_mode, index);
if (!ret) {
struct osd_state *osd_device = vpbe_dev->osd_device;
@@ -367,6 +372,11 @@ static int vpbe_s_dv_preset(struct vpbe_device *vpbe_dev,
ret = v4l2_subdev_call(vpbe_dev->encoders[sd_index], video,
s_dv_preset, dv_preset);
+ if (!ret && (vpbe_dev->amp != NULL)) {
+ /* Call amplifier subdevice */
+ ret = v4l2_subdev_call(vpbe_dev->amp, video,
+ s_dv_preset, dv_preset);
+ }
/* set the lcd controller output for the given mode */
if (!ret) {
struct osd_state *osd_device = vpbe_dev->osd_device;
@@ -566,6 +576,8 @@ static int platform_device_get(struct device *dev, void
*data)
if (strcmp("vpbe-osd", pdev->name) == 0)
vpbe_dev->osd_device = platform_get_drvdata(pdev);
+ if (strcmp("vpbe-venc", pdev->name) == 0)
+ vpbe_dev->venc_device = dev_get_platdata(&pdev->dev);
return 0;
}
@@ -584,6 +596,7 @@ static int platform_device_get(struct device *dev, void
*data)
static int vpbe_initialize(struct device *dev, struct vpbe_device *vpbe_dev)
{
struct encoder_config_info *enc_info;
+ struct amp_config_info *amp_info;
struct v4l2_subdev **enc_subdev;
struct osd_state *osd_device;
struct i2c_adapter *i2c_adap;
@@ -704,6 +717,39 @@ static int vpbe_initialize(struct device *dev, struct
vpbe_device *vpbe_dev)
v4l2_warn(&vpbe_dev->v4l2_dev, "non-i2c encoders"
" currently not supported");
}
+ /* Add amplifier subdevice for dm365 */
+ if ((strcmp(vpbe_dev->cfg->module_name, "dm365-vpbe-display") == 0) &&
+ vpbe_dev->cfg->amp != NULL) {
+ vpbe_dev->amp = kmalloc(sizeof(struct v4l2_subdev *),
+ GFP_KERNEL);
+ if (vpbe_dev->amp == NULL) {
+ v4l2_err(&vpbe_dev->v4l2_dev,
+ "unable to allocate memory for sub device");
+ ret = -ENOMEM;
+ goto vpbe_fail_v4l2_device;
+ }
+ amp_info = vpbe_dev->cfg->amp;
+ if (amp_info->is_i2c) {
+ vpbe_dev->amp = v4l2_i2c_new_subdev_board(
+ &vpbe_dev->v4l2_dev, i2c_adap,
+ &_info->board_info, NULL);
+ if (!vpbe_dev->amp) {
+ v4l2_err(&vpbe_dev->v4l2_dev,
+"amplifier %s failed to register",
+amp_info->module_name);
+
[PATCH RESEND 3/4] davinci vpbe: add dm365 and dm355 specific OSD changes
Add OSD block changes to enable dm365 and dm355 for vpbe driver.
Changes are based on version number of OSD, which have incremental
changes over 644x OSD hardware interms of few registers.
VPBE_VERSION_2 = dm365 specific
VPBE_VERSION_3 = dm355 specific
Signed-off-by: Manjunath Hadli
---
drivers/media/video/davinci/vpbe_osd.c | 474 +---
1 files changed, 433 insertions(+), 41 deletions(-)
diff --git a/drivers/media/video/davinci/vpbe_osd.c
b/drivers/media/video/davinci/vpbe_osd.c
index 5352884..cf472d3 100644
--- a/drivers/media/video/davinci/vpbe_osd.c
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -248,11 +248,31 @@ static void _osd_set_rec601_attenuation(struct osd_state
*sd,
osd_modify(sd, OSD_OSDWIN0MD_ATN0E,
enable ? OSD_OSDWIN0MD_ATN0E : 0,
OSD_OSDWIN0MD);
+ if (sd->vpbe_type == VPBE_VERSION_1) {
+ osd_modify(sd, OSD_OSDWIN0MD_ATN0E,
+ enable ? OSD_OSDWIN0MD_ATN0E : 0,
+ OSD_OSDWIN0MD);
+ } else if ((sd->vpbe_type == VPBE_VERSION_3) ||
+ (sd->vpbe_type == VPBE_VERSION_2)) {
+ osd_modify(sd, OSD_EXTMODE_ATNOSD0EN,
+ enable ? OSD_EXTMODE_ATNOSD0EN : 0,
+ OSD_EXTMODE);
+ }
break;
case OSDWIN_OSD1:
osd_modify(sd, OSD_OSDWIN1MD_ATN1E,
enable ? OSD_OSDWIN1MD_ATN1E : 0,
OSD_OSDWIN1MD);
+ if (sd->vpbe_type == VPBE_VERSION_1) {
+ osd_modify(sd, OSD_OSDWIN1MD_ATN1E,
+ enable ? OSD_OSDWIN1MD_ATN1E : 0,
+ OSD_OSDWIN1MD);
+ } else if ((sd->vpbe_type == VPBE_VERSION_3) ||
+ (sd->vpbe_type == VPBE_VERSION_2)) {
+ osd_modify(sd, OSD_EXTMODE_ATNOSD1EN,
+ enable ? OSD_EXTMODE_ATNOSD1EN : 0,
+ OSD_EXTMODE);
+ }
break;
}
}
@@ -273,15 +293,72 @@ static void _osd_set_blending_factor(struct osd_state *sd,
}
}
+static void _osd_enable_rgb888_pixblend(struct osd_state *sd,
+ enum osd_win_layer osdwin)
+{
+
+ osd_modify(sd, OSD_MISCCTL_BLDSEL, 0, OSD_MISCCTL);
+ switch (osdwin) {
+ case OSDWIN_OSD0:
+ osd_modify(sd, OSD_EXTMODE_OSD0BLDCHR,
+ OSD_EXTMODE_OSD0BLDCHR, OSD_EXTMODE);
+ break;
+ case OSDWIN_OSD1:
+ osd_modify(sd, OSD_EXTMODE_OSD1BLDCHR,
+ OSD_EXTMODE_OSD1BLDCHR, OSD_EXTMODE);
+ break;
+ }
+}
+
static void _osd_enable_color_key(struct osd_state *sd,
enum osd_win_layer osdwin,
unsigned colorkey,
enum osd_pix_format pixfmt)
{
switch (pixfmt) {
+ case PIXFMT_1BPP:
+ case PIXFMT_2BPP:
+ case PIXFMT_4BPP:
+ case PIXFMT_8BPP:
+ if (sd->vpbe_type == VPBE_VERSION_3) {
+ switch (osdwin) {
+ case OSDWIN_OSD0:
+ osd_modify(sd, OSD_TRANSPBMPIDX_BMP0,
+ colorkey <<
+ OSD_TRANSPBMPIDX_BMP0_SHIFT,
+ OSD_TRANSPBMPIDX);
+ break;
+ case OSDWIN_OSD1:
+ osd_modify(sd, OSD_TRANSPBMPIDX_BMP1,
+ colorkey <<
+ OSD_TRANSPBMPIDX_BMP1_SHIFT,
+ OSD_TRANSPBMPIDX);
+ break;
+ }
+ }
+ break;
case PIXFMT_RGB565:
- osd_write(sd, colorkey & OSD_TRANSPVAL_RGBTRANS,
- OSD_TRANSPVAL);
+ if (sd->vpbe_type == VPBE_VERSION_1) {
+ osd_write(sd, colorkey & OSD_TRANSPVAL_RGBTRANS,
+ OSD_TRANSPVAL);
+ } else if (sd->vpbe_type == VPBE_VERSION_3) {
+ osd_write(sd, colorkey & OSD_TRANSPVALL_RGBL,
+ OSD_TRANSPVALL);
+ }
+ break;
+ case PIXFMT_YCbCrI:
+ case PIXFMT_YCrCbI:
+ if (sd->vpbe_type == VPBE_VERSION_3)
+ osd_modify(sd, OSD_TRANSPVALU_Y, colorkey,
+ OSD_TRANSPVALU);
+ break;
+ case PIXFMT_RGB888:
+ if (sd->vpbe_type == VPBE_VERSION_3) {
+
[PATCH RESEND 4/4] davinci vpbe: add VENC block changes to enable dm365 and dm355
This patch implements necessary changes for enabling dm365 and
dm355 hardware for vpbe. The patch contains additional HD mode
support for dm365 (720p60, 1080i30) and appropriate register
modifications based on version numbers.
VPBE_VERSION_2 = dm365 specific
VPBE_VERSION_3 = dm355 specific
Signed-off-by: Manjunath Hadli
---
drivers/media/video/davinci/vpbe_venc.c | 205 +++
include/media/davinci/vpbe_venc.h |4 +
2 files changed, 185 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
index 03a3e5c..53c2994 100644
--- a/drivers/media/video/davinci/vpbe_venc.c
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -99,6 +99,8 @@ static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32
val)
return val;
}
+#define VDAC_COMPONENT 0x543
+#define VDAC_S_VIDEO 0x210
/* This function sets the dac of the VPBE for various outputs
*/
static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
@@ -109,11 +111,12 @@ static int venc_set_dac(struct v4l2_subdev *sd, u32
out_index)
venc_write(sd, VENC_DACSEL, 0);
break;
case 1:
- v4l2_dbg(debug, 1, sd, "Setting output to S-Video\n");
- venc_write(sd, VENC_DACSEL, 0x210);
+ v4l2_dbg(debug, 1, sd, "Setting output to Component\n");
+ venc_write(sd, VENC_DACSEL, VDAC_COMPONENT);
break;
- case 2:
- venc_write(sd, VENC_DACSEL, 0x543);
+ case 2:
+ v4l2_dbg(debug, 1, sd, "Setting output to S-video\n");
+ venc_write(sd, VENC_DACSEL, VDAC_S_VIDEO);
break;
default:
return -EINVAL;
@@ -124,6 +127,8 @@ static int venc_set_dac(struct v4l2_subdev *sd, u32
out_index)
static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
{
+ struct venc_state *venc = to_state(sd);
+ struct venc_platform_data *pdata = venc->pdata;
v4l2_dbg(debug, 2, sd, "venc_enabledigitaloutput\n");
if (benable) {
@@ -155,7 +160,8 @@ static void venc_enabledigitaloutput(struct v4l2_subdev
*sd, int benable)
/* Disable LCD output control (accepting default polarity) */
venc_write(sd, VENC_LCDOUT, 0);
- venc_write(sd, VENC_CMPNT, 0x100);
+ if (pdata->venc_type != VPBE_VERSION_3)
+ venc_write(sd, VENC_CMPNT, 0x100);
venc_write(sd, VENC_HSPLS, 0);
venc_write(sd, VENC_HINT, 0);
venc_write(sd, VENC_HSTART, 0);
@@ -178,11 +184,14 @@ static void venc_enabledigitaloutput(struct v4l2_subdev
*sd, int benable)
}
}
+#define VDAC_CONFIG_SD_V3 0x0E21A6B6
+#define VDAC_CONFIG_SD_V2 0x081141CF
/*
* setting NTSC mode
*/
static int venc_set_ntsc(struct v4l2_subdev *sd)
{
+ u32 val;
struct venc_state *venc = to_state(sd);
struct venc_platform_data *pdata = venc->pdata;
@@ -195,12 +204,22 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
venc_enabledigitaloutput(sd, 0);
- /* to set VENC CLK DIV to 1 - final clock is 54 MHz */
- venc_modify(sd, VENC_VIDCTL, 0, 1 << 1);
- /* Set REC656 Mode */
- venc_write(sd, VENC_YCCCTL, 0x1);
- venc_modify(sd, VENC_VDPRO, 0, VENC_VDPRO_DAFRQ);
- venc_modify(sd, VENC_VDPRO, 0, VENC_VDPRO_DAUPS);
+ if (pdata->venc_type == VPBE_VERSION_3) {
+ venc_write(sd, VENC_CLKCTL, 0x01);
+ venc_write(sd, VENC_VIDCTL, 0);
+ val = vdaccfg_write(sd, VDAC_CONFIG_SD_V3);
+ } else if (pdata->venc_type == VPBE_VERSION_2) {
+ venc_write(sd, VENC_CLKCTL, 0x01);
+ venc_write(sd, VENC_VIDCTL, 0);
+ vdaccfg_write(sd, VDAC_CONFIG_SD_V2);
+ } else {
+ /* to set VENC CLK DIV to 1 - final clock is 54 MHz */
+ venc_modify(sd, VENC_VIDCTL, 0, 1 << 1);
+ /* Set REC656 Mode */
+ venc_write(sd, VENC_YCCCTL, 0x1);
+ venc_modify(sd, VENC_VDPRO, 0, VENC_VDPRO_DAFRQ);
+ venc_modify(sd, VENC_VDPRO, 0, VENC_VDPRO_DAUPS);
+ }
venc_write(sd, VENC_VMOD, 0);
venc_modify(sd, VENC_VMOD, (1 << VENC_VMOD_VIE_SHIFT),
@@ -220,6 +239,7 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
static int venc_set_pal(struct v4l2_subdev *sd)
{
struct venc_state *venc = to_state(sd);
+ struct venc_platform_data *pdata = venc->pdata;
v4l2_dbg(debug, 2, sd, "venc_set_pal\n");
@@ -230,10 +250,20 @@ static int venc_set_pal(struct v4l2_subdev *sd)
venc_enabledigitaloutput(sd, 0);
- /* to set VENC CLK DIV to 1 - final clock is 54 MHz */
- venc_modify(sd, VENC_VIDCTL, 0, 1 << 1);
- /* Set REC656 Mode */
- venc_write(sd, VENC_YCCCTL, 0x1);
+ if (pdata->venc_type == VPBE_VERSION_
[PATCH RESEND 1/4] davinci vpbe: remove unused macro.
remove VPBE_DISPLAY_SD_BUF_SIZE as it is no longer used. Signed-off-by: Manjunath Hadli --- drivers/media/video/davinci/vpbe_display.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/davinci/vpbe_display.c b/drivers/media/video/davinci/vpbe_display.c index ae7add1..09a659e 100644 --- a/drivers/media/video/davinci/vpbe_display.c +++ b/drivers/media/video/davinci/vpbe_display.c @@ -43,7 +43,6 @@ static int debug; -#define VPBE_DISPLAY_SD_BUF_SIZE (720*576*2) #define VPBE_DEFAULT_NUM_BUFS 3 module_param(debug, int, 0644); -- 1.6.2.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 RESEND 0/4] davinci vpbe: enable DM365 v4l2 display driver
The patchset adds incremental changes necessary to enable dm365 v4l2 display driver, which includes vpbe display driver changes, osd specific changes and venc changes. The changes are incremental in nature,addind a few HD modes, and taking care of register level changes. The patch set does not include THS7303 amplifier driver which is planned to be sent seperately. Manjunath Hadli (4): davinci vpbe: remove unused macro. davinci vpbe: add dm365 VPBE display driver changes davinci vpbe: add dm365 and dm355 specific OSD changes davinci vpbe: add VENC block changes to enable dm365 and dm355 drivers/media/video/davinci/vpbe.c | 55 +++- drivers/media/video/davinci/vpbe_display.c |1 - drivers/media/video/davinci/vpbe_osd.c | 474 +--- drivers/media/video/davinci/vpbe_venc.c| 205 +++-- include/media/davinci/vpbe.h | 16 + include/media/davinci/vpbe_venc.h |4 + 6 files changed, 686 insertions(+), 69 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Mauro, Thank you for your note. The first RFC for this (VPFE MC) driver was sent only in August this year. The other driver being discussed before was VPBE (which did go through some grind but not 2 years) which you accepted. This series of patches is definitely not two years old (unless I am mistaken somewhere). Currently Sakari is taking active interest in reviewing the patches, but I would like to take the cue from your note to request others also to actively review these patches and help me get them accepted. Thanks and Regards, -Manju On Sun, Sep 18, 2011 at 20:05:46, Mauro Carvalho Chehab wrote: > Em 29-08-2011 12:07, Manjunath Hadli escreveu: > > changes from last patch set: > > 1. Made changes based on Sakari's feedback mainly: > > a. returned early to allow unindenting > > b. reformatting to shift the code to left where possible > > c. changed hex numbers to lower case > > d. corrected the defines according to module names. > > e. magic numbers removed. > > f. changed non-integer returning functions to void > > g. removed unwanted paranthses. > > h. fixed error codes. > > i. fixed some RESET_BIt code to what it was intended for. > > 2. reorganized the header files to move the kernel-only headers along > > with the c files and interface headers in the include folder. > > Manju, > > Please be sure to send me a pull request when you think this driver is ready > for merge. The first submission I'm noticing for this driver was back on > 2009, and still today, nobody sent me a git pull request for it. Two years > seems too much time to solve the pending issues and sending a pull request > for me to merge it! > > > > Manjunath Hadli (6): > > davinci: vpfe: add dm3xx IPIPEIF hardware support module > > davinci: vpfe: add support for CCDC hardware for dm365 > > davinci: vpfe: add ccdc driver with media controller interface > > davinci: vpfe: add v4l2 video driver support > > davinci: vpfe: v4l2 capture driver with media interface > > davinci: vpfe: build infrastructure for dm365 > > > > Nagabhushana Netagunte (2): > > davinci: vpfe: add IPIPE hardware layer support > > davinci: vpfe: add IPIPE support for media controller driver > > > > drivers/media/video/davinci/Kconfig | 46 +- > > drivers/media/video/davinci/Makefile | 17 +- > > drivers/media/video/davinci/ccdc_hw_device.h | 10 +- > > drivers/media/video/davinci/ccdc_types.h | 43 + > > drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ > > drivers/media/video/davinci/dm365_ccdc.h | 88 + > > drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ > > drivers/media/video/davinci/dm365_def_para.c | 486 +++ > > drivers/media/video/davinci/dm365_def_para.h | 39 + > > drivers/media/video/davinci/dm365_ipipe.c | 3966 > > + > > drivers/media/video/davinci/dm365_ipipe.h | 300 ++ > > drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ > > drivers/media/video/davinci/dm365_ipipe_hw.h | 539 > > drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ > > drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ > > drivers/media/video/davinci/imp_common.h | 85 + > > drivers/media/video/davinci/imp_hw_if.h | 178 ++ > > drivers/media/video/davinci/vpfe_capture.c| 793 + > > drivers/media/video/davinci/vpfe_capture.h| 104 + > > drivers/media/video/davinci/vpfe_ccdc.c | 813 + > > drivers/media/video/davinci/vpfe_ccdc.h | 85 + > > drivers/media/video/davinci/vpfe_video.c | 1712 +++ > > drivers/media/video/davinci/vpfe_video.h | 142 + > > include/linux/davinci_vpfe.h | 1223 > > include/linux/dm365_ccdc.h| 664 + > > include/linux/dm3xx_ipipeif.h | 64 + > > include/media/davinci/vpfe.h | 91 + > > 27 files changed, 14829 insertions(+), 11 deletions(-) create mode > > 100644 drivers/media/video/davinci/ccdc_types.h > > create mode 100644 drivers/media/video/davinci/dm365_ccdc.c > > create mode 100644 drivers/media/video/davinci/dm365_ccdc.h > > create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h > > create mode 100644 drivers/media/video/davinci/dm365_def_para.c > > create mode 100644 drivers/media/video/davinci/dm365_def_para.h > > create mode 100644 drivers/media/video/davinci/dm365_ipipe.c > > create mode 100644 drivers/media/video/davinci/dm365_ipipe.h > > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c > > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h > > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c > > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h > > create mode 100644 drivers/media/video/davinci/imp_common.h > > create mode 100644 drivers/media/video/davinci/imp_hw_if.h > > create
Re: [RFC][PATCH 2/2] v4l2: Add lv8093 lens driver
Hi Mauro/Laurent,
On Sun, Sep 18, 2011 at 7:53 AM, Laurent Pinchart
wrote:
> Hi,
>
> On Sunday 18 September 2011 14:25:50 Mauro Carvalho Chehab wrote:
>> Em 13-07-2010 20:40, Sergio Aguirre escreveu:
>> > This adds LV8093 Piezo Actuator Lens driver.
>> >
>> > This is currently found in tandem with IMX046 sensor.
>>
>> Due to patchwork.kernel.org long outage, I'm working on setting a new
>> patchwork instance somewhere else. So, I'm importing the old patches and
>> double-check if something were missed.
>>
>> In this proccess, I noticed that, for two times, a driver for lv8093 were
>> proposed, one as part of the OMAPZOOM series of patches, back in Feb/2009,
>> and a second submission, on this series.
>>
>> However, it seems that this were never applied, even not having any single
>> comment on the last time you've submitted it, as a RFC.
>>
>> It seems that the omap3 maintainer lost those patches, or am I missing
>> something?
>
> If you're talking about the OMAP3 ISP maintainer, indeed, I've never even
> noticed the patches :-)
This patches are so old, that I've forgotten completely about them :P
I'll actually need to dust off my old Zoom3 HW I have around to retest this. :)
And BTW, Dominic doesn't work at TI since last year, so I'm unlooping
his e-mail address.
>
> Review inlined.
Ok. Thanks.
>
>> > Signed-off-by: Sergio Aguirre
>> > ---
>> >
>> > drivers/media/video/Kconfig | 8 +
>> > drivers/media/video/Makefile | 1 +
>> > drivers/media/video/lv8093.c | 614
>> > drivers/media/video/lv8093_regs.h | 76 +
>> > include/media/lv8093.h | 40 +++
>> > include/media/v4l2-chip-ident.h | 3 +
>> > 6 files changed, 742 insertions(+), 0 deletions(-)
>> > create mode 100644 drivers/media/video/lv8093.c
>> > create mode 100644 drivers/media/video/lv8093_regs.h
>> > create mode 100644 include/media/lv8093.h
>> >
>> > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
>> > index 10cd7b3..b62adce 100644
>> > --- a/drivers/media/video/Kconfig
>> > +++ b/drivers/media/video/Kconfig
>> > @@ -344,6 +344,14 @@ config VIDEO_IMX046
>> >
>> > IMX046 camera. It is currently working with the TI OMAP3
>> > camera controller.
>> >
>> > +config VIDEO_LV8093
>> > + tristate "Piezo Actuator Lens driver for LV8093"
>> > + depends on I2C && VIDEO_V4L2
>> > + ---help---
>> > + This is a Video4Linux2 lens driver for the Sanyo LV8093.
>> > + It is currently working with the TI OMAP3 camera controller
>> > + and Sony IMX046 sensor.
>> > +
>
> You will need to implement the media controller API to work with the TI OMAP3
> ISP.
Yeah. I think I've implemented this driver when Media Controller
wasn't still upstreamed,
and under review still.
>
>> > config VIDEO_SAA7110
>> >
>> > tristate "Philips SAA7110 video decoder"
>> > depends on VIDEO_V4L2 && I2C
>> >
>> > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
>> > index 00341cb..50f528c 100644
>> > --- a/drivers/media/video/Makefile
>> > +++ b/drivers/media/video/Makefile
>> > @@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
>> >
>> > obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
>> > obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
>> > obj-$(CONFIG_VIDEO_IMX046) += imx046.o
>> >
>> > +obj-$(CONFIG_VIDEO_LV8093) += lv8093.o
>> >
>> > obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
>> > obj-$(CONFIG_VIDEO_SAA711X) += saa7115.o
>> > obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
>> >
>> > diff --git a/drivers/media/video/lv8093.c b/drivers/media/video/lv8093.c
>> > new file mode 100644
>> > index 000..b0b0fcf
>> > --- /dev/null
>> > +++ b/drivers/media/video/lv8093.c
>> > @@ -0,0 +1,614 @@
>> > +/*
>> > + * drivers/media/video/lv8093.c
>> > + *
>> > + * LV8093 Piezo Motor (LENS) driver
>> > + *
>> > + * Copyright (C) 2008-2009 Texas Instruments.
>> > + * Copyright (C) 2009 Hewlett-Packard.
>> > + *
>> > + * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
>> > + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
>> > + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
>> > + */
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#include "lv8093_regs.h"
>> > +
>> > +static struct vcontrol {
>> > + struct v4l2_queryctrl qc;
>> > +} video_control[] = {
>> > + {
>> > + {
>> > + .id = V4L2_CID_FOCUS_RELATIVE,
>> > + .type = V4L2_CTRL_TYPE_INTEGER,
>> > + .name = "Lens Relative Position",
>> > + .minimum = 0,
>> > + .maximum = 0,
>> > + .step = LV8093_MAX_RELAT
Re: Asking advice for Camera/ISP driver framework design
Hi Cliff, On Thursday 15 September 2011 19:10:52 Sakari Ailus wrote: > Cliff Cai wrote: > > On Thu, Sep 15, 2011 at 6:20 PM, Laurent Pinchart wrote: > >> On Wednesday 14 September 2011 08:13:32 Cliff Cai wrote: > >>> Dear guys, > >>> > >>> I'm currently working on a camera/ISP Linux driver project.Of course,I > >>> want it to be a V4L2 driver,but I got a problem about how to design > >>> the driver framework. > >>> let me introduce the background of this ISP(Image signal processor) a > >>> little bit. > >>> 1.The ISP has two output paths,first one called main path which is > >>> used to transfer image data for taking picture and recording,the other > >>> one called preview path which is used to transfer image data for > >>> previewing. > >>> 2.the two paths have the same image data input from sensor,but their > >>> outputs are different,the output of main path is high quality and > >>> larger image,while the output of preview path is smaller image. > >>> 3.the two output paths have independent DMA engines used to move image > >>> data to system memory. > >>> > >>> The problem is currently, the V4L2 framework seems only support one > >>> buffer queue,and in my case,obviously,two buffer queues are required. > >>> Any idea/advice for implementing such kind of V4L2 driver? or any > >>> other better solutions? > >> > >> Your driver should create two video nodes, one for each stream. They > >> will each have their own buffers queue. > >> > >> The driver should also implement the media controller API to let > >> applications discover that the video nodes are related and how they > >> interact with the ISP. > > > > As "Documentation/media-framework" says, one of the goals of media > > device model is "Discovering a device internal topology,and > > configuring it at runtime".I'm just a bit confused about how > > applications can discover the related video notes? Could you explain > > it a little more? > > The major and minor numbers of video nodes are provided to the user > space in struct media_entity_desc (defined in include/linux/media.h) > using MEDIA_IOC_ENUM_ENTITIES IOCTL. The major and minor numbers define > which device node corresponds to the video device; this isn't trivial > for an application to do so there's a library which makes it easier: > > http://git.ideasonboard.org/?p=media-ctl.git;a=summary> > > See src/media.h for the interface. An example how to use this is > available in src/main.c. > > Entities the type of which is MEDIA_ENT_T_DEVNODE_V4L are V4L2 device > nodes. http://www.ideasonboard.org/media/omap3isp.ps shows a device topology example generated automatically from the output of the media-ctl tool. -- 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 1/3] v4l: Extend V4L2_CID_COLORFX control with AQUA effect
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 Nawrocki
> Signed-off-by: Kyungmin Park
> ---
> 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.
> V4L2_COLORFX_SKETCH (5),
> V4L2_COLORFX_SKY_BLUE (6),
> V4L2_COLORFX_GRASS_GREEN (7),
> -V4L2_COLORFX_SKIN_WHITEN (8) and
> -V4L2_COLORFX_VIVID (9).
> +V4L2_COLORFX_SKIN_WHITEN (8),
> +V4L2_COLORFX_VIVID (9) and
> +V4L2_COLORFX_AQUA (10).
>
>
> V4L2_CID_ROTATE
> 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)
--
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 2/3] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
Hi Sylwester,
Thanks for the patch.
On Friday 16 September 2011 19:05:29 Sylwester Nawrocki wrote:
> V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct
> a driver what is the power line frequency so an appropriate filter
> can be used by the device to cancel flicker by compensating the light
> intensity ripple. Currently in the menu we have entries for
> 50 and 60 Hz and for entirely disabling the anti-flicker filter.
> However some devices are capable of automatically detecting the
> frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
Acked-by: Laurent Pinchart
> ---
> Documentation/DocBook/media/v4l/controls.xml |5 +++--
> drivers/media/video/v4l2-ctrls.c |1 +
> include/linux/videodev2.h|1 +
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml index f3c6457..aff7989
> 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -232,8 +232,9 @@ control is deprecated. New drivers and applications
> should use the Enables a power line frequency filter to avoid
> flicker. Possible values for enum
> v4l2_power_line_frequency are:
> V4L2_CID_POWER_LINE_FREQUENCY_DISABLED (0),
> -V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1) and
> -V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2).
> +V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1),
> +V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2) and
> +V4L2_CID_POWER_LINE_FREQUENCY_AUTO (3).
>
>
> V4L2_CID_HUE_AUTO
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c index 06b6014..20abe5d 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -210,6 +210,7 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> "Disabled",
> "50 Hz",
> "60 Hz",
> + "Auto",
> NULL
> };
> static const char * const camera_exposure_auto[] = {
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 5032226..ec858e7 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1125,6 +1125,7 @@ enum v4l2_power_line_frequency {
> V4L2_CID_POWER_LINE_FREQUENCY_DISABLED = 0,
> V4L2_CID_POWER_LINE_FREQUENCY_50HZ = 1,
> V4L2_CID_POWER_LINE_FREQUENCY_60HZ = 2,
> + V4L2_CID_POWER_LINE_FREQUENCY_AUTO = 3,
> };
> #define V4L2_CID_HUE_AUTO(V4L2_CID_BASE+25)
> #define V4L2_CID_WHITE_BALANCE_TEMPERATURE (V4L2_CID_BASE+26)
--
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 Sylwester, 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 ? > IMHO keeping different names for synchronization and 'data valid' signals > is more clear. > > >>> 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 Nawrocki > Signed-off-by: Kyungmin Park > --- > > 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, 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 Sylwester, 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. > 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. > >> Signed-off-by: Sylwester Nawrocki > >> Signed-off-by: Kyungmin Park > >> --- > >> > >> 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, 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.
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.
> ---
> 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
> #include
>
> +#include
Is this needed ?
> #include
> #include
> #include
> @@ -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;
--
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
Hi Martin, Thanks for the patch. On Saturday 17 September 2011 11:29:31 Martin Hostettler wrote: > The MT9M032 is a parallel 3MP sensor from Micron controlled through I2C. According to the Aptina datasheet, it's an 1.6MP sensor :-) > 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 > --- > 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 > + * Author: Martin Hostettler > + * > + * 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 > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include You can remove this header. > +#include > +#include > +#include > + > +#include > + > +#define MT9M032_CHIP_VERSION 0x00 > +#define MT9M032_ROW_START0x01 > +#define MT9M032_COLUMN_START 0x02 > +#define MT9M032_ROW_SIZE 0x03 > +#define MT9M032_COLUMN_SIZE 0x04 > +#define MT9M032_HBLANK 0x05 > +#define MT9M032_VBLANK 0x06 > +#define MT9M032_SHUTTER_WIDTH_HIGH 0x08 > +#define MT9M032_SHUTTER_WIDTH_LOW0x09 > +#define MT9M032_PIX_CLK_CTRL 0x0a > +#define MT9M032_PIX_CLK_CTRL_INV_PIXCLK 0x8000 > +#define MT9M032_RESTART 0x0b > +#define MT9M032_RESET0x0d > +#define MT9M032_PLL_CONFIG1 0x11 > +#define MT9M032_PLL_CONFIG1_OUTDIV_MASK 0x3f > +#define MT9M032_PLL_
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
> ---
> 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
> + * Author: Martin Hostettler
> + *
> + * 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
> +#include
> +#include
> +
> +#include
> +#include
> +#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_SEL 157
> +
> +#define MT9M032_I2C_BUS_NUM 2
> +
> +
> +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 = ISPCT
Re: Proposal for a low-level Linux display framework
Hi Rob, (CC'ing linux-media, as I believe this is very on-topic) On Sunday 18 September 2011 18:14:26 Rob Clark wrote: > On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote: > > On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote: > >> On 09/15/2011 05:52 PM, Alex Deucher wrote: > >> > Please don't claim that the DRM developers do not want to cooperate. > >> > I realize that people have strong opinions about existing APIs, put > >> > there has been just as much, if not more obstinacy from the v4l and fb > >> > people. > >> > >> Well, I think it's too late to really fix this thing. We now have 3 APIs > >> in the kernel that have to be kept. Probably the best we can do now is > >> figure out how we can reduce code duplication and do extensions to > >> those APIs in a way that they are compatible with each other or > >> completely independent and can be used across the APIs. > > > > Sorry for jumping late into the discussion. Let me try to shed some new > > light on this. > > > > I've been thinking about the DRM/KMS/FB/V4L APIs overlap for quite some > > time now. All of them have their share of issues, historical nonsense > > and unique features. I don't think we can pick one of those APIs today > > and decide to drop the others, but we certainly need to make DRM, KMS, > > FB and V4L interoperable at various levels. The alternative is to keep > > ignoring each other and let the market decice. > > I think we need to differentiate between V4L camera, and display.. > > MC and subdev stuff clearly seem to be the way to go for complex > camera / imaging subsystems. But that is a very different problem > domain from GPU+display. We need to stop blurring the two topics. I would agree with you if we were only talking about GPU, but display is broader than that. Many hardware available today have complex display pipelines with "deep tunneling" between other IP blocks (such as the camera subsystem) and the display. Configuration of such pipelines isn't specific to DRM/KMS. > > Thinking that the market could pick something like OpenMAX > > scares me, so I'd rather find a good compromise and move forward. > > > > Disclaimer: My DRM/KMS knowledge isn't as good as my FB and V4L > > knowledge, so please feel free to correct my mistakes. > > > > All our video-related APIs started as solutions to different problems. > > They all share an important feature: they assume that the devices they > > control is more or less monolithic. For that reason they expose a single > > device to userspace, and mix device configuration and data transfer on > > the same device node. > > > > This shortcoming became painful in V4L a couple of years ago. When I > > started working on the OMAP3 ISP (camera) driver I realized that trying > > to configure a complex hardware pipeline without exposing its internals > > to userspace applications wouldn't be possible. DRM, KMS and FB ran into > > the exact same problem, just more recently, as showed by various RFCs > > ([1], [2]). > > But I do think that overlays need to be part of the DRM/KMS interface, > simply because flipping still needs to be synchronized w/ the GPU. I > have some experience using V4L for display, and this is one (of > several) broken aspects of that. I agree that DRM/KMS must be used to address needs specific to display hardware, but I don't think *all* display needs are specific to the display. > > To fix this issue, the V4L community developed a new API called the Media > > Controller [3]. In a nutshell, the MC aims at > > > > - exposing the device topology to userspace as an oriented graph of > > entities connected with links through pads > > > > - controlling the device topology from userspace by enabling/disabling > > links > > > > - giving userspace access to per-entity controls > > > > - configuring formats at individual points in the pipeline from > > userspace. > > > > The MC API solves the first two problems. The last two require help from > > V4L (which has been extended with new MC-aware ioctls), as MC is > > media-agnostic and can't thus configure video formats. > > > > To support this, the V4L subsystem exposes an in-kernel API based around > > the concept of sub-devices. A single high-level hardware device is > > handled by multiple sub-devices, possibly controlled by different > > drivers. For instance, in the OMAP3-based N900 digital camera, the OMAP3 > > ISP is made of 8 sub-devices (all controlled by the OMAP3 ISP driver), > > and the two sensors, flash controller and lens controller all have their > > own sub-device, each of them controlled by its own driver. > > > > All this infrastructure exposes the devices a the graph showed in [4] to > > applications, and the V4L sub-device API can be used to set formats at > > individual pads. This allows controlling scaling, cropping, composing and > > other video-related operations on the pipeline. > > > > With the introduction of the media controller architecture, I
Re: [PATCH v3 0/3] fbdev: Add FOURCC-based format configuration API
Hi Florian, On Sunday 18 September 2011 21:49:09 Florian Tobias Schandinat wrote: > Hi all, > > as there was no reaction to this patch series I am scheduling it for 3.3 > merge window (3.2 seems too close to me as this is an API change). That's fine with me. > As the second patch has nothing to do with fbdev it should go mainline via > V4L2. Any problems/comments? The NV24/42 patch will need to reach mainline before the sh_mobile_lcdc YUV API patch, or compilation will break. Mauro, what's your preference ? Should the patch go through the media tree ? If so, how should we synchronize it with the fbdev tree ? Should I push it to 3.2 ? -- 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] video: s3c-fb: Add window positioning support
Hi Florian,
On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
> On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
> >>> OMAP seem to be doing window/plane positioning in their driver code.
> >>> Is it possible to have this window positioning support at a common
> >>> place?
> >>
> >> Good point. Congratulations for figuring out that I like to standardize
> >> things. But I think your suggestion is far from being enough to be
> >> useful for userspace (which is our goal so that applications can be
> >> reused along drivers and don't need to know about individual drivers).
> >
> > Beside standardizing things, do you also like to take them one level
> > higher to solve challenging issues ? I know the answer must be yes :-)
> >
> > The problem at hand here is something we have solved in V4L2
> > (theoretically only for part of it) with the media controller API, the
> > V4L2 subdevs and their pad-level format API.
> >
> > In a nutshell, the media controller lets drivers model hardware as a
> > graph of buliding blocks connected through their pads and expose that
> > description to userspace applications. In V4L2 most of those blocks are
> > V4L2 subdevs, which are abstract building blocks that implement sets of
> > standard operations. Those operations are exposed to userspace through
> > the V4L2 subdevs pad-level format API, allowing application to configure
> > sizes and selection rectangles at all pads in the graph. Selection
> > rectangles can be used to configure cropping and composing, which is
> > exactly what the window positioning API needs to do.
> >
> > Instead of creating a new fbdev-specific API to do the same, shouldn't we
> > try to join forces ?
>
> Okay, thanks for the pointer. After having a look at your API I understand
> that it would solve the problem to discover how many windows (in this
> case) are there and how they can be accessed. It looks fine for this
> purpose, powerful enough and not too complex. So if I get it correct we
> still need at least a way to configure the position of the
> windows/overlays/sink pads similar to what Ajay proposed.
Yes, the media controller API can only expose the topology to userspace, it
can't be used to configure FB-specific parameters on the pipeline.
> Additionally a way to get and/or set the z-position of the overlays if
> multiple overlays overlap and set/get how the overlays work (overdraw,
> constant alpha, source/destination color keying). Normally I'd consider
> these link properties but I think implementing them as properties of the
> source framebuffer or sink pad would work as well.
> Is this correct or did I miss something?
That's correct.
What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I
don't think it makes sense to implement three different solutions to the same
problem in our three video-related APIs. What's your opinion about that ?
I've tried to raise the issue on the dri-devel mailing list ("Proposal for a
low-level Linux display framework"), but there's still a long way to go before
convincing everybody. Feel free to help me :-)
--
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
em28xx: new board id [eb1a:2870]
Hi everyone, I've made some tests with my Pinnacle PCTV Stick[1] Model: Pinnacle PCTV Stick Vendor/Product id: [eb1a:2870]. lsusb : Bus 001 Device 009: ID eb1a:2870 eMPIA Technology, Inc. Pinnacle PCTV Stick Dmesg with kernel 3.0 : http://pastebin.com/VDpczS7V Tests made with Kaffeine : - Analog [Worked] - DVB[Worked] I have tested this driver[2] with this patch[3] (em28xx-new-2.6.35-patch) and it works on 2.6.XX Is it possible to port it to 3.0 ? Thank you, best regards. [1] http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_unidentified_DVB-T_USB_device [2] http://bitbucket.org/mdonoughe/em28xx-new [3] http://archlinux.pastebin.com/nfwA8sU9 -- 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 12:08:20AM +0200, Laurent Pinchart wrote:
> 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().
>
Nice interface. Apart from a bit less detailed error reporting it nicely
simplifies the code. I'll make a new patch using that soon.
- 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.
On Sat, Sep 17, 2011 at 01:24:29PM -0700, Joe Perches wrote:
> 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
Ah, i didn't really knew about that feature yet. I really have to keep
that in mind when grepping for error messages in the future.
But i don't think it would help much, as i now reducted the total number
of pr_err calls to 2 in this patch.
Thanks for the idea anyway.
- Martin Hostettler
>
> > 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 v3 0/3] fbdev: Add FOURCC-based format configuration API
Hi all, as there was no reaction to this patch series I am scheduling it for 3.3 merge window (3.2 seems too close to me as this is an API change). As the second patch has nothing to do with fbdev it should go mainline via V4L2. Any problems/comments? Best regards, Florian Tobias Schandinat On 08/31/2011 11:18 AM, Laurent Pinchart wrote: > Hi everybody, > > Here's the third version of the fbdev FOURCC-based format configuration API. > > Compared to the previous version, I've added an FB_TYPE_FOURCC in addition to > FB_VISUAL_FOURCC, fixed the documentation (thanks to Geert for reviewing it > and explaining how fbdev bitplanes work) and fixed bugs in the sh_mobile_lcdc > YUV support. > > The sb_mobile_lcdc patch applies on top of the latest patches that I've sent > to the list. You can find a consolidated version that includes this patch set > at http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/fbdev-yuv. > > I've updated the fbdev-test tool to add FOURCC support. The code is available > in the fbdev-test yuv branch at > http://git.ideasonboard.org/?p=fbdev-test.git;a=shortlog;h=refs/heads/yuv. > > Laurent Pinchart (3): > fbdev: Add FOURCC-based format configuration API > v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats > fbdev: sh_mobile_lcdc: Support FOURCC-based format API > > Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 129 > Documentation/DocBook/media/v4l/pixfmt.xml |1 + > Documentation/fb/api.txt| 317 > arch/arm/mach-shmobile/board-ag5evm.c |2 +- > arch/arm/mach-shmobile/board-ap4evb.c |4 +- > arch/arm/mach-shmobile/board-mackerel.c |4 +- > arch/sh/boards/mach-ap325rxa/setup.c|2 +- > arch/sh/boards/mach-ecovec24/setup.c|2 +- > arch/sh/boards/mach-kfr2r09/setup.c |2 +- > arch/sh/boards/mach-migor/setup.c |4 +- > arch/sh/boards/mach-se/7724/setup.c |2 +- > drivers/video/sh_mobile_lcdcfb.c| 362 > +++ > include/linux/fb.h | 28 ++- > include/linux/videodev2.h |2 + > include/video/sh_mobile_lcdc.h |4 +- > 15 files changed, 726 insertions(+), 139 deletions(-) > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml > create mode 100644 Documentation/fb/api.txt > -- 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] video: s3c-fb: Add window positioning support
Hi Laurent, On 09/07/2011 03:31 PM, Laurent Pinchart wrote: > Hi Florian, > > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote: >> Hi all, >> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote: >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP >>> seem to be doing window/plane positioning in their driver code. >>> Is it possible to have this window positioning support at a common place? >> >> Good point. Congratulations for figuring out that I like to standardize >> things. But I think your suggestion is far from being enough to be useful >> for userspace (which is our goal so that applications can be reused along >> drivers and don't need to know about individual drivers). > > Beside standardizing things, do you also like to take them one level higher > to > solve challenging issues ? I know the answer must be yes :-) > > The problem at hand here is something we have solved in V4L2 (theoretically > only for part of it) with the media controller API, the V4L2 subdevs and > their > pad-level format API. > > In a nutshell, the media controller lets drivers model hardware as a graph of > buliding blocks connected through their pads and expose that description to > userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which > are abstract building blocks that implement sets of standard operations. > Those > operations are exposed to userspace through the V4L2 subdevs pad-level format > API, allowing application to configure sizes and selection rectangles at all > pads in the graph. Selection rectangles can be used to configure cropping and > composing, which is exactly what the window positioning API needs to do. > > Instead of creating a new fbdev-specific API to do the same, shouldn't we try > to join forces ? Okay, thanks for the pointer. After having a look at your API I understand that it would solve the problem to discover how many windows (in this case) are there and how they can be accessed. It looks fine for this purpose, powerful enough and not too complex. So if I get it correct we still need at least a way to configure the position of the windows/overlays/sink pads similar to what Ajay proposed. Additionally a way to get and/or set the z-position of the overlays if multiple overlays overlap and set/get how the overlays work (overdraw, constant alpha, source/destination color keying). Normally I'd consider these link properties but I think implementing them as properties of the source framebuffer or sink pad would work as well. Is this correct or did I miss something? Best regards, Florian Tobias Schandinat -- 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 09/18/2011 08:28 AM, Greg KH wrote: > On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote: >> On 09/05/2011 07:19 AM, Arnd Bergmann wrote: >>> I think it would simply be more consistent to have it enabled all >>> the time. Well, even better would be to move the bulk of the misc >>> drivers to a proper location sorted by their subsystems. A lot of them >>> should never have been merged in their current state IMHO. >> >> >> If it's clear where they belong, then sure, they should be somewhere >> other than drivers/misc/, but I don't see that it's clear for several >> of them. >> >> >>> I think I should finally do what has been talked about a few times and >>> formally become the maintainer of drivers/char and drivers/misc ;-) >>> >>> The problem is that I'm not actually a good maintainer, but maybe it's >>> better to just have someone instead of falling back to Andrew or >>> some random subsystem maintainer to send any patches for drivers/misc. >> >> 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. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Patches for TVP7002
Em 03-08-2010 05:18, mats.randga...@tandberg.com escreveu: > From: Mats Randgaard > > 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? > > 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
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:Sun Sep 18 19:00:15 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/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] soc-camera: mt9t112: modify delay time after initialize
On Sun, 18 Sep 2011, Mauro Carvalho Chehab wrote: > Em 02-02-2010 02:54, Kuninori Morimoto escreveu: > > mt9t112 camera needs 100 milliseconds for initializing > > Special thanks to Phil > > > > Signed-off-by: Kuninori Morimoto > > Reported-by: Phil Edworthy > > --- > > 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 > Reported-by: Takashi Namiki 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? 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
Em 02-02-2010 02:54, Kuninori Morimoto escreveu: > mt9t112 camera needs 100 milliseconds for initializing > Special thanks to Phil > > Signed-off-by: Kuninori Morimoto > Reported-by: Phil Edworthy > --- > 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. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: can't find bt driver
Em 18-09-2011 12:50, James escreveu: > On 09/18/11 07:30, Mauro Carvalho Chehab wrote: >> Em 17-09-2011 20:05, James escreveu: >>> Where is the bt848 driver in kernel-3.0.4? >> It should be at the usual places: >> >> $ find drivers/media/ -name bt8x* >> drivers/media/video/bt8xx >> drivers/media/dvb/bt8xx >> >> $ find sound/ -name bt8* >> sound/pci/bt87x.c > I found it under dvd but there is no check box, just three stars. > │ │--- DVB/ATSC adapters│ │ > │ │ *** Supported BT878 Adapters *** > > > I can't find it under video. > All I have is: > │ │--- Video capture adapters │ │ > │ │[ ] Enable advanced debug functionality│ │ > │ │[ ] Enable old-style fixed minor ranges for video devices │ │ > │ │[*] Autoselect pertinent encoders/decoders and other helper chi│ │ > │ │ < > CPiA2 Video For Linux │ │ > │ │ < > Philips SAA7134 support│ │ > │ │ < > Siemens-Nixdorf 'Multimedia eXtension Board' │ │ > │ │ < > Hexium HV-PCI6 and Orion frame grabber │ │ > │ │ < > Hexium Gemini frame grabber│ │ > │ │ < > Marvell 88ALP01 (Cafe) CMOS Camera Controller support │ │ > │ │ < > SR030PC30 VGA camera sensor support│ │ > │ │ < > NOON010PC30 CIF camera sensor support │ │ > │ │ < > SoC camera support │ │ > │ │[*] V4L USB devices ---> > -- > 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 Probably, You've disabled Remote Controller support or some other needed dependency. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: can't find bt driver
On 09/18/11 07:30, Mauro Carvalho Chehab wrote: Em 17-09-2011 20:05, James escreveu: Where is the bt848 driver in kernel-3.0.4? It should be at the usual places: $ find drivers/media/ -name bt8x* drivers/media/video/bt8xx drivers/media/dvb/bt8xx $ find sound/ -name bt8* sound/pci/bt87x.c I found it under dvd but there is no check box, just three stars. │ │--- DVB/ATSC adapters│ │ │ │ *** Supported BT878 Adapters *** I can't find it under video. All I have is: │ │--- Video capture adapters │ │ │ │[ ] Enable advanced debug functionality│ │ │ │[ ] Enable old-style fixed minor ranges for video devices │ │ │ │[*] Autoselect pertinent encoders/decoders and other helper chi│ │ │ │ < > CPiA2 Video For Linux │ │ │ │ < > Philips SAA7134 support│ │ │ │ < > Siemens-Nixdorf 'Multimedia eXtension Board' │ │ │ │ < > Hexium HV-PCI6 and Orion frame grabber │ │ │ │ < > Hexium Gemini frame grabber│ │ │ │ < > Marvell 88ALP01 (Cafe) CMOS Camera Controller support │ │ │ │ < > SR030PC30 VGA camera sensor support│ │ │ │ < > NOON010PC30 CIF camera sensor support │ │ │ │ < > SoC camera support │ │ │ │[*] V4L USB devices ---> -- 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][saa7134] do not change mute state for capturing audio
Hi Mauro, I've finally found the time (and an energy)
to go look into the automute breakage.
With the attached automute fix I no longer have
any problems with pulseaudio.
I also attached the patch that introduces an "std"
option to limit the scan list, resulting in a faster scan.
It is completely unrelated to the automute one, it is
here just in case.
What do you think?
>From ccdfa126e98b5484f4a08de591ac8d89f775251c Mon Sep 17 00:00:00 2001
From: Stas Sergeev
Date: Sun, 18 Sep 2011 19:06:21 +0400
Subject: [PATCH 1/2] saa7134: fix automute
---
drivers/media/video/saa7134/saa7134-tvaudio.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c b/drivers/media/video/saa7134/saa7134-tvaudio.c
index 57e646b..62a6287 100644
--- a/drivers/media/video/saa7134/saa7134-tvaudio.c
+++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
@@ -332,7 +332,7 @@ static int tvaudio_checkcarrier(struct saa7134_dev *dev, struct mainscan *scan)
{
__s32 left,right,value;
- if (audio_debug > 1) {
+ if (audio_debug > 1 && (dev->tvnorm->id & scan->std)) {
int i;
dprintk("debug %d:",scan->carr);
for (i = -150; i <= 150; i += 30) {
@@ -546,6 +546,7 @@ static int tvaudio_thread(void *data)
dev->tvnorm->name, carrier/1000, carrier%1000,
max1, max2);
dev->last_carrier = carrier;
+ dev->automute = !(dev->thread.scan1 > 1);
} else if (0 != dev->last_carrier) {
/* no carrier -- try last detected one as fallback */
@@ -553,6 +554,7 @@ static int tvaudio_thread(void *data)
dprintk("audio carrier scan failed, "
"using %d.%03d MHz [last detected]\n",
carrier/1000, carrier%1000);
+ dev->automute = 1;
} else {
/* no carrier + no fallback -- use default */
@@ -560,9 +562,9 @@ static int tvaudio_thread(void *data)
dprintk("audio carrier scan failed, "
"using %d.%03d MHz [default]\n",
carrier/1000, carrier%1000);
+ dev->automute = 1;
}
tvaudio_setcarrier(dev,carrier,carrier);
- dev->automute = 0;
saa_andorb(SAA7134_STEREO_DAC_OUTPUT_SELECT, 0x30, 0x00);
saa7134_tvaudio_setmute(dev);
/* find the exact tv audio norm */
@@ -1020,6 +1022,7 @@ int saa7134_tvaudio_init2(struct saa7134_dev *dev)
}
dev->thread.thread = NULL;
+ dev->thread.scan1 = dev->thread.scan2 = 0;
if (my_thread) {
saa7134_tvaudio_init(dev);
/* start tvaudio thread */
--
1.7.6
>From 70709f12f7161c98cb7ebae104b520dc30c6bd53 Mon Sep 17 00:00:00 2001
From: Stas Sergeev
Date: Sun, 18 Sep 2011 19:13:05 +0400
Subject: [PATCH 2/2] saa7134: introduce "std" module parameter to force video
std
---
drivers/media/video/saa7134/saa7134-video.c | 39 --
drivers/media/video/saa7134/saa7134.h |1 +
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c
index 776ba2d..04ac7de 100644
--- a/drivers/media/video/saa7134/saa7134-video.c
+++ b/drivers/media/video/saa7134/saa7134-video.c
@@ -40,12 +40,15 @@ static unsigned int noninterlaced; /* 0 */
static unsigned int gbufsize = 720*576*4;
static unsigned int gbufsize_max = 720*576*4;
static char secam[] = "--";
+static char std[16] = "--";
module_param(video_debug, int, 0644);
MODULE_PARM_DESC(video_debug,"enable debug messages [video]");
module_param(gbuffers, int, 0444);
MODULE_PARM_DESC(gbuffers,"number of capture buffers, range 2-32");
module_param(noninterlaced, int, 0644);
MODULE_PARM_DESC(noninterlaced,"capture non interlaced video");
+module_param_string(std, std, sizeof(std), 0644);
+MODULE_PARM_DESC(secam, "force TV standard, either PAL, SECAM or NTSC");
module_param_string(secam, secam, sizeof(secam), 0644);
MODULE_PARM_DESC(secam, "force SECAM variant, either DK,L or Lc");
@@ -1847,14 +1850,20 @@ int saa7134_s_std_internal(struct saa7134_dev *dev, struct saa7134_fh *fh, v4l2_
return -EBUSY;
}
- for (i = 0; i < TVNORMS; i++)
+ for (i = 0; i < TVNORMS; i++) {
+ if (!tvnorms[i].enabled)
+ continue;
if (*id == tvnorms[i].id)
break;
+ }
if (i == TVNORMS)
- for (i = 0; i < TVNORMS; i++)
+ for (i = 0; i < TVNORMS; i++) {
+ if (!tvnorms[i].enabled)
+continue;
if (*id & tvnorms[i].id)
break;
+ }
if (i == TVNORMS)
return -EINVAL;
@@ -1871,6 +1880,8 @@ int saa7134_s_std_internal(struct saa7134_dev *dev, struct saa7134_fh *fh, v4l2_
fixup = V4L2_STD_SECAM;
}
for (i = 0; i < TVNORMS; i++) {
+ if (!tvnorms[i].enabled)
+continue;
if (fixup == tvnorms[i].id)
break;
}
@@ -2579,8 +2590,30 @@ int saa7134_videoport_init(struct saa7134_dev *dev)
int saa7134_video_init2(struct saa7134_dev *dev)
{
+ int i, idx = -1;
+ for (i = 0; i < TVNORMS; i++) {
+ int enable = (std[0] == '-' || strncasecmp(std,
+tvnorms[i].name, strlen(std)) == 0);
+
+ if (secam[0] != '-') {
+ char buf[16] = "SECAM";
+ if (strncasecmp(buf, tvnorms[i].name,
+ strlen(buf)) =
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Sun, Sep 18, 2011 at 08:11:45AM -0700, Randy Dunlap wrote: > On 09/05/2011 07:19 AM, Arnd Bergmann wrote: > > I think it would simply be more consistent to have it enabled all > > the time. Well, even better would be to move the bulk of the misc > > drivers to a proper location sorted by their subsystems. A lot of them > > should never have been merged in their current state IMHO. > > > If it's clear where they belong, then sure, they should be somewhere > other than drivers/misc/, but I don't see that it's clear for several > of them. > > > > I think I should finally do what has been talked about a few times and > > formally become the maintainer of drivers/char and drivers/misc ;-) > > > > The problem is that I'm not actually a good maintainer, but maybe it's > > better to just have someone instead of falling back to Andrew or > > some random subsystem maintainer to send any patches for drivers/misc. > > 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. 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
[ANNOUNCE] patchwork.linuxtv.org
Dear Sirs, As several of you noticed, we were having several troubles with patchwork.kernel.org, resulting on patches that got lost and several other troubles. Still, it is the main tool I use here to collect random patches that people send through the mailing list and that the driver maintainer is lazy^Wbusy enough to not care to pick and send me via a git pull request. At the end of August, Kernel.org infrastructure were put down for maintainance, and there's no ETA for it to return. All new patches sent to the linux-media ML will now be sent also to patchwork.linuxtv.org, where they'll be stored if patchwork euristics detect the email as a patch. So, I decided to run a new patchwork instance at linuxtv.org. Unfortunately, with kernel.org servers down, I could not recover the patches that were there. Due to that, I've sent to patchwork filter the emails from my linux-media archives (that has a few holes, but it is better than nothing). About 7500+ patches were added there, since 2009. As most of the patches were already applied, I've scripted some logic to detect if a patch were (partially) applied, or if the patch were rejected. I'm now reviewing manually the patches that still applies and pinging people about them, if the patch is too old and I didn't notice it being applied. This gives us a second chance of reviewing the patches that older versions of Patchwork (or kernel.org instance) didn't catch. The patchwork instance at linuxtv is capable of automatically sending notifications to people if a patch changes its state. I'll likely enable this feature on a near future, after finishing the review of the old stuff. I'll also likely try to use the delegate function of patchwork. I'll keep you updated about new features as we'll be able to activate them. For those that are submitting patches, I'd like to remember that patchwork has some rules to accept a patch. It basically will get your patch if: - the patch sent inlined; - the patch weren't mangled by the emailer (some emailers love to break long lines into smaller ones, damaging the patches); - are encoded with ASCII and doesn't contain any character upper than 0x80 (no accented characters). Patchwork might also get patches uuencoded, with different charsets (in particular, if your name has accents, I recommend you to use UTF-8) and/or with the patch attached, but I recommend you to double check at patchwork.linuxtv.org to see if the patch were caught. Also, although patchwork does accept attached patches, you should not send patches on this way, as people can't easily review it (as several developers use plain text emailers that can't reply to the inlined patch text). If you discover any problems there, or notice a patch that were badly tagged (and aren't marked there as "New"), please drop me an email. Ah, you should notice that, by default, patchwork will only show patches tagged as New or Under review (e. g., patches with "Action required"). So, if you want to search for a patch that might be wrongly tagged, you'll need to click into patchwork "Filters:" field and change it to show all patch status, or click on the URL bellow: http://patchwork.linuxtv.org/project/linux-media/list/?state=* I hope you enjoy patchwork.linuxtv.org! Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On 09/05/2011 07:19 AM, Arnd Bergmann wrote: > I think it would simply be more consistent to have it enabled all > the time. Well, even better would be to move the bulk of the misc > drivers to a proper location sorted by their subsystems. A lot of them > should never have been merged in their current state IMHO. If it's clear where they belong, then sure, they should be somewhere other than drivers/misc/, but I don't see that it's clear for several of them. > I think I should finally do what has been talked about a few times and > formally become the maintainer of drivers/char and drivers/misc ;-) > > The problem is that I'm not actually a good maintainer, but maybe it's > better to just have someone instead of falling back to Andrew or > some random subsystem maintainer to send any patches for drivers/misc. 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] So yes, I think that drivers/misc/ (and probably drivers/char/) deserves a maintainer, but you are not making a good case for you being that person. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Em 29-08-2011 12:07, Manjunath Hadli escreveu: > changes from last patch set: > 1. Made changes based on Sakari's feedback mainly: > a. returned early to allow unindenting > b. reformatting to shift the code to left where possible > c. changed hex numbers to lower case > d. corrected the defines according to module names. > e. magic numbers removed. > f. changed non-integer returning functions to void > g. removed unwanted paranthses. > h. fixed error codes. > i. fixed some RESET_BIt code to what it was intended for. > 2. reorganized the header files to move the kernel-only headers > along with the c files and interface headers in the include folder. Manju, Please be sure to send me a pull request when you think this driver is ready for merge. The first submission I'm noticing for this driver was back on 2009, and still today, nobody sent me a git pull request for it. Two years seems too much time to solve the pending issues and sending a pull request for me to merge it! > > Manjunath Hadli (6): > davinci: vpfe: add dm3xx IPIPEIF hardware support module > davinci: vpfe: add support for CCDC hardware for dm365 > davinci: vpfe: add ccdc driver with media controller interface > davinci: vpfe: add v4l2 video driver support > davinci: vpfe: v4l2 capture driver with media interface > davinci: vpfe: build infrastructure for dm365 > > Nagabhushana Netagunte (2): > davinci: vpfe: add IPIPE hardware layer support > davinci: vpfe: add IPIPE support for media controller driver > > drivers/media/video/davinci/Kconfig | 46 +- > drivers/media/video/davinci/Makefile | 17 +- > drivers/media/video/davinci/ccdc_hw_device.h | 10 +- > drivers/media/video/davinci/ccdc_types.h | 43 + > drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ > drivers/media/video/davinci/dm365_ccdc.h | 88 + > drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ > drivers/media/video/davinci/dm365_def_para.c | 486 +++ > drivers/media/video/davinci/dm365_def_para.h | 39 + > drivers/media/video/davinci/dm365_ipipe.c | 3966 > + > drivers/media/video/davinci/dm365_ipipe.h | 300 ++ > drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ > drivers/media/video/davinci/dm365_ipipe_hw.h | 539 > drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ > drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ > drivers/media/video/davinci/imp_common.h | 85 + > drivers/media/video/davinci/imp_hw_if.h | 178 ++ > drivers/media/video/davinci/vpfe_capture.c| 793 + > drivers/media/video/davinci/vpfe_capture.h| 104 + > drivers/media/video/davinci/vpfe_ccdc.c | 813 + > drivers/media/video/davinci/vpfe_ccdc.h | 85 + > drivers/media/video/davinci/vpfe_video.c | 1712 +++ > drivers/media/video/davinci/vpfe_video.h | 142 + > include/linux/davinci_vpfe.h | 1223 > include/linux/dm365_ccdc.h| 664 + > include/linux/dm3xx_ipipeif.h | 64 + > include/media/davinci/vpfe.h | 91 + > 27 files changed, 14829 insertions(+), 11 deletions(-) > create mode 100644 drivers/media/video/davinci/ccdc_types.h > create mode 100644 drivers/media/video/davinci/dm365_ccdc.c > create mode 100644 drivers/media/video/davinci/dm365_ccdc.h > create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h > create mode 100644 drivers/media/video/davinci/dm365_def_para.c > create mode 100644 drivers/media/video/davinci/dm365_def_para.h > create mode 100644 drivers/media/video/davinci/dm365_ipipe.c > create mode 100644 drivers/media/video/davinci/dm365_ipipe.h > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h > create mode 100644 drivers/media/video/davinci/imp_common.h > create mode 100644 drivers/media/video/davinci/imp_hw_if.h > create mode 100644 drivers/media/video/davinci/vpfe_capture.c > create mode 100644 drivers/media/video/davinci/vpfe_capture.h > create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c > create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h > create mode 100644 drivers/media/video/davinci/vpfe_video.c > create mode 100644 drivers/media/video/davinci/vpfe_video.h > create mode 100644 include/linux/davinci_vpfe.h > create mode 100644 include/linux/dm365_ccdc.h > create mode 100644 include/linux/dm3xx_ipipeif.h > create mode 100644 include/media/davinci/vpfe.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 -- To u
Re: [RFC][PATCH 2/2] v4l2: Add lv8093 lens driver
Hi,
On Sunday 18 September 2011 14:25:50 Mauro Carvalho Chehab wrote:
> Em 13-07-2010 20:40, Sergio Aguirre escreveu:
> > This adds LV8093 Piezo Actuator Lens driver.
> >
> > This is currently found in tandem with IMX046 sensor.
>
> Due to patchwork.kernel.org long outage, I'm working on setting a new
> patchwork instance somewhere else. So, I'm importing the old patches and
> double-check if something were missed.
>
> In this proccess, I noticed that, for two times, a driver for lv8093 were
> proposed, one as part of the OMAPZOOM series of patches, back in Feb/2009,
> and a second submission, on this series.
>
> However, it seems that this were never applied, even not having any single
> comment on the last time you've submitted it, as a RFC.
>
> It seems that the omap3 maintainer lost those patches, or am I missing
> something?
If you're talking about the OMAP3 ISP maintainer, indeed, I've never even
noticed the patches :-)
Review inlined.
> > Signed-off-by: Sergio Aguirre
> > ---
> >
> > drivers/media/video/Kconfig |8 +
> > drivers/media/video/Makefile |1 +
> > drivers/media/video/lv8093.c | 614
> > drivers/media/video/lv8093_regs.h | 76 +
> > include/media/lv8093.h| 40 +++
> > include/media/v4l2-chip-ident.h |3 +
> > 6 files changed, 742 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/media/video/lv8093.c
> > create mode 100644 drivers/media/video/lv8093_regs.h
> > create mode 100644 include/media/lv8093.h
> >
> > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> > index 10cd7b3..b62adce 100644
> > --- a/drivers/media/video/Kconfig
> > +++ b/drivers/media/video/Kconfig
> > @@ -344,6 +344,14 @@ config VIDEO_IMX046
> >
> > IMX046 camera. It is currently working with the TI OMAP3
> > camera controller.
> >
> > +config VIDEO_LV8093
> > + tristate "Piezo Actuator Lens driver for LV8093"
> > + depends on I2C && VIDEO_V4L2
> > + ---help---
> > + This is a Video4Linux2 lens driver for the Sanyo LV8093.
> > + It is currently working with the TI OMAP3 camera controller
> > + and Sony IMX046 sensor.
> > +
You will need to implement the media controller API to work with the TI OMAP3
ISP.
> > config VIDEO_SAA7110
> >
> > tristate "Philips SAA7110 video decoder"
> > depends on VIDEO_V4L2 && I2C
> >
> > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> > index 00341cb..50f528c 100644
> > --- a/drivers/media/video/Makefile
> > +++ b/drivers/media/video/Makefile
> > @@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
> >
> > obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
> > obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
> > obj-$(CONFIG_VIDEO_IMX046) += imx046.o
> >
> > +obj-$(CONFIG_VIDEO_LV8093) += lv8093.o
> >
> > obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
> > obj-$(CONFIG_VIDEO_SAA711X) += saa7115.o
> > obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
> >
> > diff --git a/drivers/media/video/lv8093.c b/drivers/media/video/lv8093.c
> > new file mode 100644
> > index 000..b0b0fcf
> > --- /dev/null
> > +++ b/drivers/media/video/lv8093.c
> > @@ -0,0 +1,614 @@
> > +/*
> > + * drivers/media/video/lv8093.c
> > + *
> > + * LV8093 Piezo Motor (LENS) driver
> > + *
> > + * Copyright (C) 2008-2009 Texas Instruments.
> > + * Copyright (C) 2009 Hewlett-Packard.
> > + *
> > + * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
> > + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
> > + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "lv8093_regs.h"
> > +
> > +static struct vcontrol {
> > + struct v4l2_queryctrl qc;
> > +} video_control[] = {
> > + {
> > + {
> > + .id = V4L2_CID_FOCUS_RELATIVE,
> > + .type = V4L2_CTRL_TYPE_INTEGER,
> > + .name = "Lens Relative Position",
> > + .minimum = 0,
> > + .maximum = 0,
> > + .step = LV8093_MAX_RELATIVE_STEP,
> > + .default_value = 0,
> > + }
> > + ,}
> > +};
> > +
> > +static struct i2c_driver lv8093_i2c_driver;
> > +
> > +static struct lv8093_lens_settings {
> > + u8 reg;
> > + u8 val;
> > +} lens_settings[] = {
> > + { /* Set control register */
> > + .reg = CAMAF_LV8093_CTL_REG,
> > + .val = CAMAF_LV8093_GATE0 |
> > + CAMAF_LV8093_ENIN |
> > + CAMAF_LV8093_CKSEL_ONE |
> > + CAMAF_LV8093_RET2 |
> > + C
Re: [PATCH] FM1216ME_MK3 AUX byte for FM mode
Hi Dmitri,
Em 23-04-2009 02:40, Dmitri Belimov escreveu:
> Hi All
>
> Write AUX byte to FM1216ME_MK3 when FM mode, better sensitivity. It can be
> usefull for other tuners.
Hmm... Found this patch. It were never applied, but it may make some sense
to apply it.
Could you please double-check if this patch is still valid, and, if so, re-send
it
to me?
Thanks!
Mauro
>
> diff -r 00a84f86671d linux/drivers/media/common/tuners/tuner-simple.c
> --- a/linux/drivers/media/common/tuners/tuner-simple.cMon Apr 20
> 22:07:44 2009 +
> +++ b/linux/drivers/media/common/tuners/tuner-simple.cThu Apr 23
> 10:26:54 2009 +1000
> @@ -751,6 +751,17 @@
> if (4 != rc)
> tuner_warn("i2c i/o error: rc == %d (should be 4)\n", rc);
>
> + /* Write AUX byte */
> + switch (priv->type) {
> + case TUNER_PHILIPS_FM1216ME_MK3:
> + buffer[2] = 0x98;
> + buffer[3] = 0x20; /* set TOP AGC */
> + rc = tuner_i2c_xfer_send(&priv->i2c_props, buffer, 4);
> + if (4 != rc)
> + tuner_warn("i2c i/o error: rc == %d (should be 4)\n",
> rc);
> + break;
> + }
> +
> return 0;
> }
>
> Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
>
>
> With my best regards, Dmitry.
--
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: [RFC][PATCH 2/2] v4l2: Add lv8093 lens driver
Hi Sergio/Dominic,
Em 13-07-2010 20:40, Sergio Aguirre escreveu:
> This adds LV8093 Piezo Actuator Lens driver.
>
> This is currently found in tandem with IMX046 sensor.
Due to patchwork.kernel.org long outage, I'm working on setting a new patchwork
instance somewhere else. So, I'm importing the old patches and double-check
if something were missed.
In this proccess, I noticed that, for two times, a driver for lv8093 were
proposed,
one as part of the OMAPZOOM series of patches, back in Feb/2009, and a second
submission, on this series.
However, it seems that this were never applied, even not having any single
comment on the last time you've submitted it, as a RFC.
It seems that the omap3 maintainer lost those patches, or am I missing
something?
Thanks,
Mauro
>
> Signed-off-by: Sergio Aguirre
> ---
> drivers/media/video/Kconfig |8 +
> drivers/media/video/Makefile |1 +
> drivers/media/video/lv8093.c | 614
> +
> drivers/media/video/lv8093_regs.h | 76 +
> include/media/lv8093.h| 40 +++
> include/media/v4l2-chip-ident.h |3 +
> 6 files changed, 742 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/lv8093.c
> create mode 100644 drivers/media/video/lv8093_regs.h
> create mode 100644 include/media/lv8093.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 10cd7b3..b62adce 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -344,6 +344,14 @@ config VIDEO_IMX046
> IMX046 camera. It is currently working with the TI OMAP3
> camera controller.
>
> +config VIDEO_LV8093
> + tristate "Piezo Actuator Lens driver for LV8093"
> + depends on I2C && VIDEO_V4L2
> + ---help---
> + This is a Video4Linux2 lens driver for the Sanyo LV8093.
> + It is currently working with the TI OMAP3 camera controller
> + and Sony IMX046 sensor.
> +
> config VIDEO_SAA7110
> tristate "Philips SAA7110 video decoder"
> depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 00341cb..50f528c 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
> obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
> obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
> obj-$(CONFIG_VIDEO_IMX046) += imx046.o
> +obj-$(CONFIG_VIDEO_LV8093) += lv8093.o
> obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
> obj-$(CONFIG_VIDEO_SAA711X) += saa7115.o
> obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
> diff --git a/drivers/media/video/lv8093.c b/drivers/media/video/lv8093.c
> new file mode 100644
> index 000..b0b0fcf
> --- /dev/null
> +++ b/drivers/media/video/lv8093.c
> @@ -0,0 +1,614 @@
> +/*
> + * drivers/media/video/lv8093.c
> + *
> + * LV8093 Piezo Motor (LENS) driver
> + *
> + * Copyright (C) 2008-2009 Texas Instruments.
> + * Copyright (C) 2009 Hewlett-Packard.
> + *
> + * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
> + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
> + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "lv8093_regs.h"
> +
> +static struct vcontrol {
> + struct v4l2_queryctrl qc;
> +} video_control[] = {
> + {
> + {
> + .id = V4L2_CID_FOCUS_RELATIVE,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "Lens Relative Position",
> + .minimum = 0,
> + .maximum = 0,
> + .step = LV8093_MAX_RELATIVE_STEP,
> + .default_value = 0,
> + }
> + ,}
> +};
> +
> +static struct i2c_driver lv8093_i2c_driver;
> +
> +static struct lv8093_lens_settings {
> + u8 reg;
> + u8 val;
> +} lens_settings[] = {
> + { /* Set control register */
> + .reg = CAMAF_LV8093_CTL_REG,
> + .val = CAMAF_LV8093_GATE0 |
> + CAMAF_LV8093_ENIN |
> + CAMAF_LV8093_CKSEL_ONE |
> + CAMAF_LV8093_RET2 |
> + CAMAF_LV8093_INIT_OFF,
> + },
> + { /* Specify number of clocks per period */
> + .reg = CAMAF_LV8093_RST_REG,
> + .val = (LV8093_CLK_PER_PERIOD - 1),
> + },
> + { /* Set the GATE_A pulse set value */
> + .reg = CAMAF_LV8093_GTAS_REG,
> + .val = (LV8093_TIME_GATEA + 1),
> + },
> + { /* Set the GATE_B pulse reset value */
> + .reg = CAMAF_LV8093_GTBR_REG,
>
Re: [PATCH] TT CT-3650 CI support
On Jueves, 1 de Septiembre de 2011 01:47:32 Jose Alberto Reguero escribió:
> From:
>
> http://www.spinics.net/lists/linux-media/msg20440.html
>
> This patch add support for the CI of the TT CT-3650.
>
> Jose Alberto
>
> Signed-off-by: Jose Alberto Reguero
Second version with changes suggested by Mauro in:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20811
Jose Alberto
Signed-off-by: Jose Alberto Reguero
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c 2011-08-28 05:45:24.0 +0200
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c 2011-09-18 02:06:00.211411451 +0200
@@ -33,16 +33,40 @@
#include "tda10048.h"
#include "tda827x.h"
#include "lnbp21.h"
+/* CA */
+#include "dvb_ca_en50221.h"
/* debug */
static int dvb_usb_ttusb2_debug;
#define deb_info(args...) dprintk(dvb_usb_ttusb2_debug,0x01,args)
module_param_named(debug,dvb_usb_ttusb2_debug, int, 0644);
MODULE_PARM_DESC(debug, "set debugging level (1=info (or-able))." DVB_USB_DEBUG_STATUS);
+static int dvb_usb_ttusb2_debug_ci;
+module_param_named(debug_ci,dvb_usb_ttusb2_debug_ci, int, 0644);
+MODULE_PARM_DESC(debug_ci, "set debugging ci." DVB_USB_DEBUG_STATUS);
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+#define ci_dbg(format, arg...)\
+do { \
+ if (dvb_usb_ttusb2_debug_ci)\
+ printk(KERN_DEBUG DVB_USB_LOG_PREFIX \
+ ": %s " format "\n" , __func__, ## arg); \
+} while (0)
+
+enum {
+ TT3650_CMD_CI_TEST = 0x40,
+ TT3650_CMD_CI_RD_CTRL,
+ TT3650_CMD_CI_WR_CTRL,
+ TT3650_CMD_CI_RD_ATTR,
+ TT3650_CMD_CI_WR_ATTR,
+ TT3650_CMD_CI_RESET,
+ TT3650_CMD_CI_SET_VIDEO_PORT
+};
+
struct ttusb2_state {
+ struct dvb_ca_en50221 ca;
+ struct mutex ca_mutex;
u8 id;
u16 last_rc_key;
};
@@ -79,6 +103,255 @@
return 0;
}
+/* ci */
+static int tt3650_ci_msg(struct dvb_usb_device *d, u8 cmd, u8 *data, unsigned int write_len, unsigned int read_len)
+{
+ int ret;
+ u8 rx[60];/* (64 -4) */
+ ret = ttusb2_msg(d, cmd, data, write_len, rx, read_len);
+ if (!ret)
+ memcpy(data, rx, read_len);
+ return ret;
+}
+
+static int tt3650_ci_msg_locked(struct dvb_ca_en50221 *ca, u8 cmd, u8 *data, unsigned int write_len, unsigned int read_len)
+{
+ struct dvb_usb_device *d = ca->data;
+ struct ttusb2_state *state = d->priv;
+ int ret;
+
+ mutex_lock(&state->ca_mutex);
+ ret = tt3650_ci_msg(d, cmd, data, write_len, read_len);
+ mutex_unlock(&state->ca_mutex);
+
+ return ret;
+}
+
+static int tt3650_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address)
+{
+ u8 buf[3];
+ int ret = 0;
+
+ if (slot)
+ return -EINVAL;
+
+ buf[0] = (address >> 8) & 0x0F;
+ buf[1] = address;
+
+
+ ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_RD_ATTR, buf, 2, 3);
+
+ ci_dbg("%04x -> %d 0x%02x", address, ret, buf[2]);
+
+ if (ret < 0)
+ return ret;
+
+ return buf[2];
+}
+
+static int tt3650_ci_write_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address, u8 value)
+{
+ u8 buf[3];
+
+ ci_dbg("%d 0x%04x 0x%02x", slot, address, value);
+
+ if (slot)
+ return -EINVAL;
+
+ buf[0] = (address >> 8) & 0x0F;
+ buf[1] = address;
+ buf[2] = value;
+
+ return tt3650_ci_msg_locked(ca, TT3650_CMD_CI_WR_ATTR, buf, 3, 3);
+}
+
+static int tt3650_ci_read_cam_control(struct dvb_ca_en50221 *ca, int slot, u8 address)
+{
+ u8 buf[2];
+ int ret;
+
+ if (slot)
+ return -EINVAL;
+
+ buf[0] = address & 3;
+
+ ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_RD_CTRL, buf, 1, 2);
+
+ ci_dbg("0x%02x -> %d 0x%02x", address, ret, buf[1]);
+
+ if (ret < 0)
+ return ret;
+
+ return buf[1];
+}
+
+static int tt3650_ci_write_cam_control(struct dvb_ca_en50221 *ca, int slot, u8 address, u8 value)
+{
+ u8 buf[2];
+
+ ci_dbg("%d 0x%02x 0x%02x", slot, address, value);
+
+ if (slot)
+ return -EINVAL;
+
+ buf[0] = address;
+ buf[1] = value;
+
+ return tt3650_ci_msg_locked(ca, TT3650_CMD_CI_WR_CTRL, buf, 2, 2);
+}
+
+static int tt3650_ci_set_video_port(struct dvb_ca_en50221 *ca, int slot, int enable)
+{
+ u8 buf[1];
+ int ret;
+
+ ci_dbg("%d %d", slot, enable);
+
+ if (slot)
+ return -EINVAL;
+
+ buf[0] = enable;
+
+ ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_SET_VIDEO_PORT, buf, 1, 1);
+ if (ret < 0)
+ return ret;
+
+ if (enable != buf[0]) {
+ err("CI not %sabled.", enable ? "en" : "dis");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int tt3650_ci_slot_shutdown(struct dvb_ca_en50221 *ca, int slot)
+{
+ return tt3650_ci_set_video_port(ca, slot, 0);
+}
+
+static int tt3650_ci_slot_ts_enable(struct dvb_ca_en50221 *ca, int slot)
+{
+ return tt3650_ci_set_video_port(ca, slot, 1);
+}
+
+static int tt3650_ci_slot_reset(struct dvb_ca_en50221 *ca, int slot)
+{
+ struct dvb_usb_device *d = ca->data;
+ struct ttusb2_state *state = d->priv;
+ u8 buf[1];
+ int ret;
+
+ ci_dbg("%d", slot);
+
+ if (slot)
+ return -EINVAL;
+
+ buf[0] = 0;
+
+ mutex_lock(&state->ca_mutex);
+
+ ret = tt365
Re: [git:v4l-dvb/for_v3.2] [media] cx18: Fix videobuf capture
Mauro Carvalho Chehab wrote:
>This is an automatic generated email to let you know that the following
>patch were queued at the
>http://git.linuxtv.org/media_tree.git tree:
>
>Subject: [media] cx18: Fix videobuf capture
>Author: Simon Farnsworth
>Date:Mon Sep 5 12:23:12 2011 -0300
>
>When we moved to 3.0, we found that the cx18 driver was oopsing on
>close with:
>
>NULL pointer deref at:
>
>[ 2290.461009] Call Trace:
>[ 2290.461009] [] ? pm_qos_add_request+0xc/0x6e
>[ 2290.461009] [] __mutex_lock_common+0x87/0x125
>[ 2290.461009] [] ? cx18_queue_flush+0x31/0x87 [cx18]
>[ 2290.461009] [] ? __might_sleep+0x29/0xe4
>[ 2290.461009] [] __mutex_lock_slowpath+0x25/0x27
>[ 2290.461009] [] ? mutex_lock+0x2e/0x3b
>[ 2290.461009] [] mutex_lock+0x2e/0x3b
>[ 2290.461009] [] videobuf_queue_lock+0x13/0x15
>[videobuf_core]
>[ 2290.461009] [] __videobuf_free+0xfc/0x112 [videobuf_core]
>[ 2290.461009] [] cx18_v4l2_close+0x158/0x172 [cx18]
>[ 2290.461009] [] ? cpumask_next+0x1a/0x1d
>[ 2290.461009] [] v4l2_release+0x35/0x52 [videodev]
>[ 2290.461009] [] fput+0x100/0x1a5
>[ 2290.461009] [] filp_close+0x5c/0x64
>[ 2290.461009] [] sys_close+0x5f/0x93
>[ 2290.461009] [] sysenter_do_call+0x12/0x28
>
>Some digging showed that a merge at some previous point partially
>added broken mmap() support, causing this trace. Remove the broken
>code completely.
>
>On top of that, the calculation in place for "buffer full" depended on
>UYUV instead of HM12, while our GStreamer code was picking HM12 in
>some circumstances.
>
>Finally, the V4L2_CAP_STREAMING capability was never exposed. Patch it
>into the YUV encoder node only.
>
>Signed-off-by: Simon Farnsworth
>Signed-off-by: Mauro Carvalho Chehab
>
> drivers/media/video/cx18/cx18-driver.h |5 +
> drivers/media/video/cx18/cx18-fileops.c |2 --
> drivers/media/video/cx18/cx18-ioctl.c | 18 +++---
> drivers/media/video/cx18/cx18-mailbox.c |2 +-
> drivers/media/video/cx18/cx18-streams.c | 13 +
> 5 files changed, 26 insertions(+), 14 deletions(-)
>
>---
>
>http://git.linuxtv.org/media_tree.git?a=commitdiff;h=09fc9802c31a9358a4e34642aa5f569111752879
>
>diff --git a/drivers/media/video/cx18/cx18-driver.h
>b/drivers/media/video/cx18/cx18-driver.h
>index 1834207..b9a94fc 100644
>--- a/drivers/media/video/cx18/cx18-driver.h
>+++ b/drivers/media/video/cx18/cx18-driver.h
>@@ -409,6 +409,7 @@ struct cx18_stream {
>
> /* Videobuf for YUV video */
> u32 pixelformat;
>+ u32 vb_bytes_per_frame;
> struct list_head vb_capture;/* video capture queue */
> spinlock_t vb_lock;
> struct timer_list vb_timeout;
>@@ -430,10 +431,6 @@ struct cx18_open_id {
> u32 open_id;
> int type;
> struct cx18 *cx;
>-
>- struct videobuf_queue vbuf_q;
>- spinlock_t s_lock; /* Protect vbuf_q */
>- enum v4l2_buf_type vb_type;
> };
>
> static inline struct cx18_open_id *fh2id(struct v4l2_fh *fh)
>diff --git a/drivers/media/video/cx18/cx18-fileops.c
>b/drivers/media/video/cx18/cx18-fileops.c
>index 07411f3..14cb961 100644
>--- a/drivers/media/video/cx18/cx18-fileops.c
>+++ b/drivers/media/video/cx18/cx18-fileops.c
>@@ -784,8 +784,6 @@ int cx18_v4l2_close(struct file *filp)
> cx18_release_stream(s);
> } else {
> cx18_stop_capture(id, 0);
>- if (id->type == CX18_ENC_STREAM_TYPE_YUV)
>- videobuf_mmap_free(&id->vbuf_q);
> }
> kfree(id);
> mutex_unlock(&cx->serialize_lock);
>diff --git a/drivers/media/video/cx18/cx18-ioctl.c
>b/drivers/media/video/cx18/cx18-ioctl.c
>index afe0a29..66b1c15 100644
>--- a/drivers/media/video/cx18/cx18-ioctl.c
>+++ b/drivers/media/video/cx18/cx18-ioctl.c
>@@ -160,12 +160,7 @@ static int cx18_g_fmt_vid_cap(struct file *file,
>void *fh,
> pixfmt->priv = 0;
> if (id->type == CX18_ENC_STREAM_TYPE_YUV) {
> pixfmt->pixelformat = s->pixelformat;
>- /* HM12 YUV size is (Y=(h*720) + UV=(h*(720/2)))
>- UYUV YUV size is (Y=(h*720) + UV=(h*(720))) */
>- if (s->pixelformat == V4L2_PIX_FMT_HM12)
>- pixfmt->sizeimage = pixfmt->height * 720 * 3 / 2;
>- else
>- pixfmt->sizeimage = pixfmt->height * 720 * 2;
>+ pixfmt->sizeimage = s->vb_bytes_per_frame;
> pixfmt->bytesperline = 720;
> } else {
> pixfmt->pixelformat = V4L2_PIX_FMT_MPEG;
>@@ -296,6 +291,12 @@ static int cx18_s_fmt_vid_cap(struct file *file,
>void *fh,
> return -EBUSY;
>
> s->pixelformat = fmt->fmt.pix.pixelformat;
>+ /* HM12 YUV size is (Y=(h*720) + UV=(h*(720/2)))
>+ UYUV YUV size is (Y=(h*720) + UV=(h*(720))) */
>+ if (s->pixelformat == V4L2_PIX_FMT_HM12)
>+ s->vb_bytes_per_frame = h * 720 * 3 / 2;
>+ else
>+ s->vb_bytes_per_frame = h * 720 * 2;
>
> mbus_fmt.width = cx->cxhdl.width = w;
>
Re: can't find bt driver
Em 17-09-2011 20:05, James escreveu: > Where is the bt848 driver in kernel-3.0.4? It should be at the usual places: $ find drivers/media/ -name bt8x* drivers/media/video/bt8xx drivers/media/dvb/bt8xx $ find sound/ -name bt8* sound/pci/bt87x.c > -- > 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] mmp_camera: add MODULE_ALIAS
Em 14-09-2011 19:47, Jonathan Corbet escreveu: > On Wed, 7 Sep 2011 10:36:46 +0100 (BST) > Daniel Drake wrote: > >> This enables module autoloading. >> >> Signed-off-by: Daniel Drake > > No objections here, consider it acked. > > Mauro: as far as I'm concerned, Daniel can be considered a co-maintainer > of the OLPC camera drivers. I'm not planning to forget about them, and > I'll certainly still look at patches, but please don't ever hold up > something from him if (as has, on very rare occasion, been known to > happen) I get a little slow. Ok, I'll do that. Thanks! Mauro > > Thanks, > > jon > -- > 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
