RE: ISP OMAP3 camera support ov7690
Hi Michael,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of michael
> Sent: Sunday, October 04, 2009 7:29 PM
> To: Nishanth Menon
> Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org
> Subject: Re: ISP OMAP3 camera support ov7690
>
> Hi,
>
> cc: linux-media
>
> Nishanth Menon wrote:
> > michael said the following on 10/03/2009 06:13 PM:
> >> I'm writing a driver to support the ov7690 camera and I have some
> >> question about the meaning of:
> >>
> >> - datalane configuration
> > CSI2 Data lanes - each CSI2 lane is a differential pair.
> And, at least 1
> > clock and data lane is used in devices.
>
> Sorry can you explain a little bit more. I have the camera
> connected to the
> cam_hs and cam_vs and the data is 8Bit. I use the the isp init
> structure. The sccb bus works great and I can send
> configuration to it,
> but I don't receive any interrupt from the ics, seems that it
> doen't see
> the transaction:
>
> The ISPCCDC: ###CCDC SYN_MODE=0x31704 seems ok.
>
>
> static struct isp_interface_config ov7690_if_config = {
> .ccdc_par_ser = ISP_CSIA,
> .dataline_shift = 0x0,
> .hsvs_syncdetect= ISPCTRL_SYNC_DETECT_VSFALL,
Can you try with ISPCTRL_SYNC_DETECT_VSRISE ?
> .strobe = 0x0,
> .prestrobe = 0x0,
> .shutter= 0x0,
> .wenlog = ISPCCDC_CFG_WENLOG_AND,
> .wait_hs_vs = 0x4,
> .raw_fmt_in = ISPCCDC_INPUT_FMT_GR_BG,
> .u.csi.crc = 0x0,
> .u.csi.mode = 0x0,
> .u.csi.edge = 0x0,
> .u.csi.signalling = 0x0,
> .u.csi.strobe_clock_inv = 0x0,
> .u.csi.vs_edge = 0x0,
> .u.csi.channel = 0x0,
> .u.csi.vpclk= 0x1,
> .u.csi.data_start = 0x0,
> .u.csi.data_size= 0x0,
> .u.csi.format = V4L2_PIX_FMT_YUYV,
> };
>
> and I don't know the meaning of
>
> lanecfg.clk.pol = OV7690_CSI2_CLOCK_POLARITY;
> lanecfg.clk.pos = OV7690_CSI2_CLOCK_LANE;
> lanecfg.data[0].pol = OV7690_CSI2_DATA0_POLARITY;
> lanecfg.data[0].pos = OV7690_CSI2_DATA0_LANE;
> lanecfg.data[1].pol = OV7690_CSI2_DATA1_POLARITY;
> lanecfg.data[1].pos = OV7690_CSI2_DATA1_LANE;
> lanecfg.data[2].pol = 0;
> lanecfg.data[2].pos = 0;
> lanecfg.data[3].pol = 0;
> lanecfg.data[3].pos = 0;
>
This is the physical connection details:
- The .pol field stands for the differntial pair polarity.
(i.e. the order in which the negative and positive connections
are pugged in to the CSI2 ComplexIO module)
- The .pos field is for telling in which position of the 4
available physically you have your clock, or data lane located.
Regards,
Sergio
> >> - phyconfiguration
> > PHY - Physical timing configurations. btw, if it is camera
> specific you
> > could get a lot of inputs from [1].
>
> Ok I wil ask to them.
>
> >
> > Regards,
> > Nishanth Menon
> >
> > Ref:
> > [1] http://vger.kernel.org/vger-lists.html#linux-media
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> Michael
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-omap" 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
Programming sensor through firmware files bc of NDA
Hi all, I'm currently interested in knowing what is the stand on having a v4l2_subdev driver that uses some kind of binary for programming registers in a image sensor driver. NOTE: I must confess I currently don't know how to do it (Any pointers/samples for doing it on a proper way?) The only reason for doing this is to avoid potential violation of NDA with sensor manufacturer by exposing all register details. Please comment. Regards, Sergio-- 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: dqbuf in blocking mode
Hi Laurent,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org
> [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of
> Laurent Pinchart
> Sent: Thursday, October 01, 2009 8:34 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: Linux Media Mailing List
> Subject: Re: dqbuf in blocking mode
>
> Hi Sergio,
>
> On Thursday 01 October 2009 13:56:19 Aguirre Rodriguez,
> Sergio Alberto wrote:
> > Hi all,
> >
> > I was wondering how acceptable is to requeue a buffer in a
> dqbuf call
> > if the videbuf_dqbuf returns error?
> >
> > See, here's our current omap3 camera dqbuf function code:
> >
> > static int vidioc_dqbuf(struct file *file, void *fh, struct
> v4l2_buffer *b)
> > {
> > struct omap34xxcam_fh *ofh = fh;
> > int rval;
> >
> > videobuf_dqbuf_again:
> > rval = videobuf_dqbuf(&ofh->vbq, b, file->f_flags & O_NONBLOCK);
> >
> > /*
> > * This is a hack. We don't want to show -EIO to the user
> > * space. Requeue the buffer and try again if we're not doing
> > * this in non-blocking mode.
> > */
>
> If I'm not mistaken videobuf_dqbuf() only returns -EIO if the
> buffer state is
> VIDEOBUF_ERROR. This is the direct result of either
>
> - videobuf_queue_cancel() being called, or
> - the device driver marking the buffer as erroneous because
> of a (possibly
> transient) device error
>
> In the first case VIDIOC_DQBUF should in my opinion return
> with an error. In
> the second case things are not that clear. A transient error
> could be hidden
> from the application, or, if returned to the application
> through -EIO,
> shouldn't be treated as a fatal error. Non-transient errors
> should result in
> the application stopping video streaming.
>
> Unfortunately there V4L2 API doesn't offer a way to find out
> if the error is
> transient or fatal:
>
> "EIO VIDIOC_DQBUF failed due to an internal error.
> Can also indicate
> temporary problems like signal loss. Note the driver might
> dequeue an (empty)
> buffer despite returning an error, or even stop capturing."
>
> -EIO can mean many different things that need to be handled
> differently by
> applications. I especially hate the "the driver might dequeue
> an (empty)
> buffer despite returning an error".
>
> Drivers should always or never dequeue a buffer when an error
> occurs, not
> sometimes. The problem is for the application to recognize
> the difference
> between a transient and a fatal error in a backward-compatible way.
I think there are 2 different problems we are talking about here.
Problem #1: Incomplete DQBUF communication from driver to userspace.
(which is what you're talking about)
Problem #2: Should an internal requeue of a failed buffer be allowed?
About #1, I agree with all your points.
But about #2, I'm not sure what's your stand on it... Most probably you're
thinking that it is acceptable to lock the call _just_ if its a transient error,
therefore depending on solving problem #1 first.
What are your toughts on this?
Regards,
Sergio
>
> > if (rval == -EIO) {
> > videobuf_qbuf(&ofh->vbq, b);
> > if (!(file->f_flags & O_NONBLOCK))
> > goto videobuf_dqbuf_again;
> > /*
> > * We don't have a videobuf_buffer now --- maybe next
> > * time...
> > */
> > rval = -EAGAIN;
> > }
> >
> > return rval;
> > }
> >
> > Is anything wrong with doing this? Or perhaphs something
> better to do?
>
> --
> 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
>
> --
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: status of google group created for working on Media controller?
Hi Murali, > -Original Message- > From: linux-media-ow...@vger.kernel.org > [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of > Karicheri, Muralidharan > Sent: Thursday, October 01, 2009 8:46 AM > To: linux-media@vger.kernel.org > Subject: status of google group created for working on Media > controller? > > Hi, > > In the plumbers conference, a Google group was setup to share > ideas/patches during development of media controller > framework. But I have not any email regarding the same. Could > someone tell me what is the current status of this group and > add me to the group based on my below information? Guru should add you to the group. Nothing has been yet discussed there though. Regards, Sergio > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > email: m-kariche...@ti.com > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- 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
dqbuf in blocking mode
Hi all,
I was wondering how acceptable is to requeue a buffer in a dqbuf call
if the videbuf_dqbuf returns error?
See, here's our current omap3 camera dqbuf function code:
static int vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *b)
{
struct omap34xxcam_fh *ofh = fh;
int rval;
videobuf_dqbuf_again:
rval = videobuf_dqbuf(&ofh->vbq, b, file->f_flags & O_NONBLOCK);
/*
* This is a hack. We don't want to show -EIO to the user
* space. Requeue the buffer and try again if we're not doing
* this in non-blocking mode.
*/
if (rval == -EIO) {
videobuf_qbuf(&ofh->vbq, b);
if (!(file->f_flags & O_NONBLOCK))
goto videobuf_dqbuf_again;
/*
* We don't have a videobuf_buffer now --- maybe next
* time...
*/
rval = -EAGAIN;
}
return rval;
}
Is anything wrong with doing this? Or perhaphs something better to do?
Regards,
Sergio--
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: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes
> -Original Message-
> From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
> Sent: Wednesday, September 02, 2009 8:41 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: Linux Media Mailing List; Hans Verkuil; Paulius Zaleckas; Robert
> Jarzmik; Kuninori Morimoto; Laurent Pinchart; Karicheri, Muralidharan
> Subject: RE: [PATCH 1/3] v4l: Add a 10-bit monochrome and missing 8- and
> 10-bit Bayer fourcc codes
>
> On Wed, 2 Sep 2009, Aguirre Rodriguez, Sergio Alberto wrote:
>
> >
> >
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
> > Sent: Wednesday, September 02, 2009 7:34 AM
> > >
> > > The 16-bit monochrome fourcc code has been previously abused for a 10-
> bit
> > > format, add a new 10-bit code instead. Also add missing 8- and 10-bit
> > > Bayer
> > > fourcc codes for completeness.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > >
> > > Indeed, this is not directly related to the image-bus API, but I'd
> like to
> > > have these codes available for completeness and also to stop abusing
> > > 16-bit codes for 10-bit formats.
> > >
> > > include/linux/videodev2.h |7 ++-
> > > 1 files changed, 6 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > index 9d9a615..ffea559 100644
> > > --- a/include/linux/videodev2.h
> > > +++ b/include/linux/videodev2.h
> > > @@ -293,6 +293,7 @@ struct v4l2_pix_format {
> > >
> > > /* Grey formats */
> > > #define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8
> > > Greyscale */
> > > +#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10
> > > Greyscale */
> > > #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16
> > > Greyscale */
> > >
> > > /* Palette formats */
> > > @@ -328,7 +329,11 @@ struct v4l2_pix_format {
> > > #define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8
> > > BGBG.. GRGR.. */
> > > #define V4L2_PIX_FMT_SGBRG8 v4l2_fourcc('G', 'B', 'R', 'G') /* 8
> > > GBGB.. RGRG.. */
> > > #define V4L2_PIX_FMT_SGRBG8 v4l2_fourcc('G', 'R', 'B', 'G') /* 8
> > > GRGR.. BGBG.. */
> > > -#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10bit
> raw
> > > bayer */
> > > +#define V4L2_PIX_FMT_SRGGB8 v4l2_fourcc('R', 'G', 'G', 'B') /* 8
> > > RGRG.. GBGB.. */
> > > +#define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0') /* 10
> > > BGBG.. GRGR.. */
> > > +#define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10
> > > GBGB.. RGRG.. */
> > > +#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10
> > > GRGR.. BGBG.. */
> > > +#define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0') /* 10
> > > RGRG.. GBGB.. */
> >
> > I tried adding these same RAW Bayer 10-bit codes, but I missed
> > documentation changes. (Perhaphs you should do the same)
>
> Indeed, I forgot about it, sorry:-( I can mention in a next revision, that
> you posted an earlier version of this patch, and will add documentation as
> Hans commented on your patch.
Hey, no problem. For me its better if you can do that for me :)
I'll add my Signed-off-by in the next revision of this patch (if you want to,
of course).
Regards,
Sergio
>
> Thanks
> Guennadi
>
> > Actually, you responded on that thread :)
> > http://www.spinics.net/lists/linux-media/msg08882.html
> >
> > I had to postpone that patch, since I'm currently being dragged to some
> > internal high priority issues. But if you can do it, I'm ok with that :)
> >
> > Regards,
> > Sergio
> >
> > > /* 10bit raw bayer DPCM compressed to 8 bits */
> > > #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > /*
> > > --
> > > 1.6.2.4
>
> ---
> 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] v4l: add an image-bus API for configuring v4l2 subdev pixel and frame formats
Guennadi,
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
Sent: Wednesday, September 02, 2009 7:34 AM
> To: Linux Media Mailing List
> Cc: Hans Verkuil; Paulius Zaleckas; Robert Jarzmik; Kuninori Morimoto;
> Laurent Pinchart; Karicheri, Muralidharan
> Subject: [PATCH 2/3] v4l: add an image-bus API for configuring v4l2 subdev
> pixel and frame formats
>
> Video subdevices, like cameras, decoders, connect to video bridges over
> specialised busses. Data is being transferred over these busses in various
> formats, which only loosely correspond to fourcc codes, describing how
> video
> data is stored in RAM. This is not a one-to-one correspondence, therefore
> we
> cannot use fourcc codes to configure subdevice output data formats. This
> patch
> adds codes for several such on-the-bus formats and an API, similar to the
> familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring
> those
> codes. After all users of the old API in struct v4l2_subdev_video_ops are
> converted, the API will be removed.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> drivers/media/video/Makefile|2 +-
> drivers/media/video/v4l2-imagebus.c | 196
> +++
> include/media/v4l2-imagebus.h | 80 ++
> include/media/v4l2-subdev.h | 10 ++-
> 4 files changed, 286 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/video/v4l2-imagebus.c
> create mode 100644 include/media/v4l2-imagebus.h
>
> +const struct v4l2_imgbus_pixelfmt *v4l2_imgbus_get_fmtdesc(
> + enum v4l2_imgbus_pixelcode code)
> +{
> + if ((unsigned int)code > ARRAY_SIZE(imgbus_fmt))
> + return NULL;
> + return imgbus_fmt + code;
Wouldn't it be better to do this instead?:
return imgbus_fmt[code];
> +}
> +EXPORT_SYMBOL(v4l2_imgbus_get_fmtdesc);
> +
> +s32 v4l2_imgbus_bytes_per_line(u32 width,
> +const struct v4l2_imgbus_pixelfmt *imgf)
> +{
> + switch (imgf->packing) {
> + case V4L2_IMGBUS_PACKING_NONE:
> + return width * imgf->bits_per_sample / 8;
> + case V4L2_IMGBUS_PACKING_2X8:
> + case V4L2_IMGBUS_PACKING_EXTEND16:
> + return width * 2;
> + }
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(v4l2_imgbus_bytes_per_line);
> diff --git a/include/media/v4l2-imagebus.h b/include/media/v4l2-imagebus.h
> new file mode 100644
> index 000..d8c0fb8
> --- /dev/null
> +++ b/include/media/v4l2-imagebus.h
> @@ -0,0 +1,80 @@
> +/*
> + * Image Bus API header
> + *
> + * Copyright (C) 2009, Guennadi Liakhovetski
> + *
> + * 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.
> + */
> +
> +#ifndef V4L2_IMGBUS_H
> +#define V4L2_IMGBUS_H
> +
> +enum v4l2_imgbus_packing {
> + V4L2_IMGBUS_PACKING_NONE,
> + V4L2_IMGBUS_PACKING_2X8,
> + V4L2_IMGBUS_PACKING_EXTEND16,
> +};
> +
> +enum v4l2_imgbus_order {
> + V4L2_IMGBUS_ORDER_LE,
> + V4L2_IMGBUS_ORDER_BE,
> +};
> +
> +enum v4l2_imgbus_pixelcode {
> + V4L2_IMGBUS_FMT_YUYV,
> + V4L2_IMGBUS_FMT_YVYU,
> + V4L2_IMGBUS_FMT_UYVY,
> + V4L2_IMGBUS_FMT_VYUY,
> + V4L2_IMGBUS_FMT_VYUY_SMPTE170M_8,
> + V4L2_IMGBUS_FMT_VYUY_SMPTE170M_16,
> + V4L2_IMGBUS_FMT_RGB555,
> + V4L2_IMGBUS_FMT_RGB555X,
> + V4L2_IMGBUS_FMT_RGB565,
> + V4L2_IMGBUS_FMT_RGB565X,
> + V4L2_IMGBUS_FMT_SBGGR8,
> + V4L2_IMGBUS_FMT_SGBRG8,
> + V4L2_IMGBUS_FMT_SGRBG8,
> + V4L2_IMGBUS_FMT_SRGGB8,
> + V4L2_IMGBUS_FMT_SBGGR10,
> + V4L2_IMGBUS_FMT_SGBRG10,
> + V4L2_IMGBUS_FMT_SGRBG10,
> + V4L2_IMGBUS_FMT_SRGGB10,
> + V4L2_IMGBUS_FMT_GREY,
> + V4L2_IMGBUS_FMT_Y16,
> + V4L2_IMGBUS_FMT_Y10,
> + V4L2_IMGBUS_FMT_SBGGR10_2X8,
> +};
> +
> +/**
> + * struct v4l2_imgbus_pixelfmt - Data format on the image bus
> + * @fourcc: Fourcc code...
> + * @colorspace: and colorspace, that will be obtained if the
> data
> is
> + * stored in memory in the following way:
> + * @bits_per_sample: How many bits the bridge has to sample
> + * @packing: Type of sample-packing, that has to be used
> + * @order: Sample order when storing in memory
> + */
> +struct v4l2_imgbus_pixelfmt {
> + u32 fourcc;
I see that you're using __u32 later on.
Perhaphs you may want to keep consistency.
> + enum v4l2_colorspacecolorspace;
> + const char *name;
> + enum v4l2_imgbus_packingpacking;
> + enum v4l2_imgbus_order order;
> + u8 bits_per_sample;
Similarly here.
> +};
> +
> +struct v4l2_imgbus_framefmt {
> + __u32 width;
> + __u32 height;
> + enum v4l2_imgbus_pixelc
RE: [PATCH 1/3] v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
Sent: Wednesday, September 02, 2009 7:34 AM
>
> The 16-bit monochrome fourcc code has been previously abused for a 10-bit
> format, add a new 10-bit code instead. Also add missing 8- and 10-bit
> Bayer
> fourcc codes for completeness.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> Indeed, this is not directly related to the image-bus API, but I'd like to
> have these codes available for completeness and also to stop abusing
> 16-bit codes for 10-bit formats.
>
> include/linux/videodev2.h |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 9d9a615..ffea559 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -293,6 +293,7 @@ struct v4l2_pix_format {
>
> /* Grey formats */
> #define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8
> Greyscale */
> +#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10
> Greyscale */
> #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16
> Greyscale */
>
> /* Palette formats */
> @@ -328,7 +329,11 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8
> BGBG.. GRGR.. */
> #define V4L2_PIX_FMT_SGBRG8 v4l2_fourcc('G', 'B', 'R', 'G') /* 8
> GBGB.. RGRG.. */
> #define V4L2_PIX_FMT_SGRBG8 v4l2_fourcc('G', 'R', 'B', 'G') /* 8
> GRGR.. BGBG.. */
> -#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw
> bayer */
> +#define V4L2_PIX_FMT_SRGGB8 v4l2_fourcc('R', 'G', 'G', 'B') /* 8
> RGRG.. GBGB.. */
> +#define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0') /* 10
> BGBG.. GRGR.. */
> +#define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10
> GBGB.. RGRG.. */
> +#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10
> GRGR.. BGBG.. */
> +#define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0') /* 10
> RGRG.. GBGB.. */
I tried adding these same RAW Bayer 10-bit codes, but I missed documentation
changes. (Perhaphs you should do the same)
Actually, you responded on that thread :)
http://www.spinics.net/lists/linux-media/msg08882.html
I had to postpone that patch, since I'm currently being dragged to some
internal high priority issues. But if you can do it, I'm ok with that :)
Regards,
Sergio
> /* 10bit raw bayer DPCM compressed to 8 bits */
> #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> /*
> --
> 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
--
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] v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera
> -Original Message-
> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: Wednesday, August 26, 2009 1:43 AM
> To: Guennadi Liakhovetski
> Cc: Laurent Pinchart; Aguirre Rodriguez, Sergio Alberto; Linux Media
> Mailing List
> Subject: Re: [PATCH v3] v4l: add new v4l2-subdev sensor operations, use
> g_skip_top_lines in soc-camera
>
> On Wednesday 26 August 2009 08:41:00 Guennadi Liakhovetski wrote:
> > Introduce new v4l2-subdev sensor operations, move .enum_framesizes() and
> > .enum_frameintervals() methods to it, add a new .g_skip_top_lines()
> method
> > and switch soc-camera to use it instead of .y_skip_top soc_camera_device
> > member, which can now be removed.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> >
> > Changes since v2: renamed skip_top_lines into g_skip_top_lines, made
> > explanation comment hopefully clearer.
> >
> > drivers/media/video/mt9m001.c | 30 --
>
> > drivers/media/video/mt9m111.c |1 -
> > drivers/media/video/mt9t031.c |8 ++
> > drivers/media/video/mt9v022.c | 32 --
> --
> > drivers/media/video/pxa_camera.c |9 ++-
> > drivers/media/video/soc_camera_platform.c |1 -
> > include/media/soc_camera.h|1 -
> > include/media/v4l2-subdev.h | 13 +++
> > 8 files changed, 69 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/media/video/mt9m001.c
> b/drivers/media/video/mt9m001.c
> > index 45388d2..17be2d4 100644
> > --- a/drivers/media/video/mt9m001.c
> > +++ b/drivers/media/video/mt9m001.c
> > @@ -82,6 +82,7 @@ struct mt9m001 {
> > int model; /* V4L2_IDENT_MT9M001* codes from v4l2-chip-ident.h */
> > unsigned int gain;
> > unsigned int exposure;
> > + unsigned short y_skip_top; /* Lines to skip at the top */
> > unsigned char autoexposure;
> > };
> >
> > @@ -222,7 +223,7 @@ static int mt9m001_s_crop(struct v4l2_subdev *sd,
> struct v4l2_crop *a)
> > soc_camera_limit_side(&rect.top, &rect.height,
> > MT9M001_ROW_SKIP, MT9M001_MIN_HEIGHT,
> MT9M001_MAX_HEIGHT);
> >
> > - total_h = rect.height + icd->y_skip_top + vblank;
> > + total_h = rect.height + mt9m001->y_skip_top + vblank;
> >
> > /* Blanking and start values - default... */
> > ret = reg_write(client, MT9M001_HORIZONTAL_BLANKING, hblank);
> > @@ -239,7 +240,7 @@ static int mt9m001_s_crop(struct v4l2_subdev *sd,
> struct v4l2_crop *a)
> > ret = reg_write(client, MT9M001_WINDOW_WIDTH, rect.width - 1);
> > if (!ret)
> > ret = reg_write(client, MT9M001_WINDOW_HEIGHT,
> > - rect.height + icd->y_skip_top - 1);
> > + rect.height + mt9m001->y_skip_top - 1);
> > if (!ret && mt9m001->autoexposure) {
> > ret = reg_write(client, MT9M001_SHUTTER_WIDTH, total_h);
> > if (!ret) {
> > @@ -327,13 +328,13 @@ static int mt9m001_s_fmt(struct v4l2_subdev *sd,
> struct v4l2_format *f)
> > static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct v4l2_format
> *f)
> > {
> > struct i2c_client *client = sd->priv;
> > - struct soc_camera_device *icd = client->dev.platform_data;
> > + struct mt9m001 *mt9m001 = to_mt9m001(client);
> > struct v4l2_pix_format *pix = &f->fmt.pix;
> >
> > v4l_bound_align_image(&pix->width, MT9M001_MIN_WIDTH,
> > MT9M001_MAX_WIDTH, 1,
> > - &pix->height, MT9M001_MIN_HEIGHT + icd->y_skip_top,
> > - MT9M001_MAX_HEIGHT + icd->y_skip_top, 0, 0);
> > + &pix->height, MT9M001_MIN_HEIGHT + mt9m001->y_skip_top,
> > + MT9M001_MAX_HEIGHT + mt9m001->y_skip_top, 0, 0);
> >
> > if (pix->pixelformat == V4L2_PIX_FMT_SBGGR8 ||
> > pix->pixelformat == V4L2_PIX_FMT_SBGGR16)
> > @@ -552,7 +553,7 @@ static int mt9m001_s_ctrl(struct v4l2_subdev *sd,
> struct v4l2_control *ctrl)
> > if (ctrl->value) {
> > const u16 vblank = 25;
> > unsigned int total_h = mt9m001->rect.height +
> > - icd->y_skip_top + vblank;
> > + mt9m001->y_skip_top + vblank;
> > if (reg_write(client, MT9M001_SHUTTER_WIDTH,
> > total_h) < 0)
> >
RE: [PATCH v2] v4l: add new v4l2-subdev sensor operations, use skip_top_lines in soc-camera
Guennadi,
Some comments I came across embedded below:
> +
> +/**
> + * struct v4l2_subdev_sensor_ops - v4l2-subdev sensor operations
> + * @enum_framesizes: enumerate supported framesizes
> + * @enum_frameintervals: enumerate supported frame format intervals
> + * @skip_top_lines: number of lines at the top of the image to be
> skipped. This
> + * is needed for some sensors, that corrupt several top
> lines.
> + */
> +struct v4l2_subdev_sensor_ops {
> int (*enum_framesizes)(struct v4l2_subdev *sd, struct
> v4l2_frmsizeenum *fsize);
> int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
> v4l2_frmivalenum *fival);
> + int (*skip_top_lines)(struct v4l2_subdev *sd, u32 *lines);
> };
1. I honestly find a bit misleading the skip_top_lines name, since that IMO
could be misunderstood that the called function will DO skip lines in the
sensor, which is not the intended response...
How about g_skip_top_lines, or get_skip_top_lines, or something that clarifies
it's a "get information" abstraction interface?
2. Why enumeration mechanisms are not longer needed for a video device? (You're
removing them from video_ops)
3. Wouldn't it be better to report a valid region, instead of just the top
lines? I think that should be already covered by the driver reporting the valid
size regions on enumeration, no?
Regards,
Sergio
>
> struct v4l2_subdev_ops {
> @@ -234,6 +245,7 @@ struct v4l2_subdev_ops {
> const struct v4l2_subdev_tuner_ops *tuner;
> const struct v4l2_subdev_audio_ops *audio;
> const struct v4l2_subdev_video_ops *video;
> + const struct v4l2_subdev_sensor_ops *sensor;
> };
>
> #define V4L2_SUBDEV_NAME_SIZE 32
> --
> 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
--
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] v4l2: Add other RAW Bayer 10bit component orders
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
> Sent: Thursday, August 13, 2009 1:51 PM
> To: linux-media@vger.kernel.org
> Subject: [RFC][PATCH] v4l2: Add other RAW Bayer 10bit component orders
>
> From: Sergio Aguirre
>
> This helps clarifying different pattern orders for RAW Bayer 10 bit
> cases.
My intention with this patch is to help sensor drivers letting know the
userspace (or a v4l2_device master) the exact order of components a sensor is
outputting...
Please share your comments/thoughts/kicks :)
Regards,
Sergio
>
> Signed-off-by: Sergio Aguirre
> ---
> include/linux/videodev2.h |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 9e66c50..8aa6255 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -327,6 +327,9 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0')
> /* 10bit raw bayer DPCM compressed to 8 bits */
> #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> +#define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0')
> +#define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0')
> +#define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0')
> #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16
> BGBG.. GRGR.. */
>
> /* compressed formats */
> --
> 1.6.3.2
--
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
[RFC][PATCH] v4l2: Add other RAW Bayer 10bit component orders
From: Sergio Aguirre
This helps clarifying different pattern orders for RAW Bayer 10 bit
cases.
Signed-off-by: Sergio Aguirre
---
include/linux/videodev2.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 9e66c50..8aa6255 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -327,6 +327,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0')
/* 10bit raw bayer DPCM compressed to 8 bits */
#define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+#define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0')
+#define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0')
+#define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0')
#define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16 BGBG..
GRGR.. */
/* compressed formats */
--
1.6.3.2
0001-v4l2-Add-other-RAW-Bayer-10bit-component-orders.patch
Description: 0001-v4l2-Add-other-RAW-Bayer-10bit-component-orders.patch
RE: Linux Plumbers Conference 2009: V4L2 API discussions
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > Sent: Tuesday, August 04, 2009 12:13 PM > To: Hans Verkuil; linux-media@vger.kernel.org > Cc: eduardo.valen...@nokia.com; davinci-linux-open- > sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus Damm; > Dongsoo, Nathaniel Kim > Subject: RE: Linux Plumbers Conference 2009: V4L2 API discussions > > > > > -Original Message- > > From: davinci-linux-open-source-boun...@linux.davincidsp.com > > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On > > Behalf Of Hans Verkuil > > Sent: Tuesday, August 04, 2009 12:42 PM > > To: linux-media@vger.kernel.org > > Cc: eduardo.valen...@nokia.com; davinci-linux-open- > > sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus > > Damm; Dongsoo, Nathaniel Kim > > Subject: Linux Plumbers Conference 2009: V4L2 API discussions > > > > Hi all, > > > > During this years Plumbers Conference I will be organizing a session > > (or > > possibly more than one) on what sort of new V4L2 APIs are needed to > > support the new SoC devices. These new APIs should also solve the > > problem > > of how to find all the related alsa/fb/ir/dvb devices that a typical > > video > > device might create. > > > > A proposal was made about a year ago (note that this is a bit > > outdated > > by now, but the basics are still valid): > > > > http://www.archivum.info/video4linux-list%40redhat.com/2008- > > 07/msg00371.html > > > > In the past year the v4l2 core has evolved enough so that we can > > finally > > start thinking about this for real. > > > > I would like to know who will be attending this conference. I also > > urge > > anyone who is working in this area and who wants to have a say in > > this to > > attend the conference. The goal is to prepare a new RFC with a > > detailed > > proposal on the new APIs that are needed to fully support all the > > new > > SoCs. So the more input we get, the better the end-result will be. > > > [Hiremath, Vaibhav] Hi Hans, > > I will be attending the conference and along with above mentioned RFC I > would want to discuss some of the open issues, forthcoming TI devices, > their complexity and required software interfaces (media processor (as you > mentioned above)) and similar stuff. Hans, Vaibhav, I'll be attending this conference too. I just got approval from my boss ;). I'm starting to take the v4l2_subdev migration task as a high priority now, since most of the stability related issues in some proprietary platform are gone now. :) Actually, I'm also interested on the discussions about the Preview/Resizer Wrappers. Meet you there. Regards, Sergio > > > I will work with you offline before sharing the details here with the > community. > > Thanks, > Vaibhav Hiremath > > > Early-bird registration is still possible up to August 5th (that's > > tomorrow :-) ). > > > > Regards, > > > > Hans > > > > -- > > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > > > > ___ > > Davinci-linux-open-source mailing list > > davinci-linux-open-sou...@linux.davincidsp.com > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > > source > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: Help bringing up a sensor driver for isp omap34xx.c
(Unlooping Sameer and Mohit, as they don't longer maintain the driver) Hi John, > -Original Message- > From: John Sarman [mailto:johnsar...@gmail.com] > Sent: Wednesday, July 15, 2009 4:45 PM > To: sakari.ai...@nokia.com; Venkatraman, Sameer; Mohit Jalori; Aguirre > Rodriguez, Sergio Alberto; Tuukka Toivonen; linux-media > Subject: Help bringing up a sensor driver for isp omap34xx.c > > Hello, >I am having a problem deciphering what is wrong with my sensor > driver. It seems that everything operates on the driver but that I am > getting buffer overflows. I have fully tested the image sensor and it > is set to operate in 640x480 mode. currently it is like 648x 487 for > the dummy pixels and lines. I have enabled all the debugging #defines > in the latest code from the gitorious repository. Can you specify the gitorious repository URL you're using? I also had to edit > a few debug statements because they cause the compile to fail. Those > failures were due to the resizer rewrite and since the #defines were > commented out that code was never compiled. Anyways here is my dmesg > after I open and select the /dev/video0. > > I have been banging my head against a wall for 2 weeks now. > > Thanks, > > ISPCTRL: <1>isp_buf_queue: queue 0 vb 0, mmu 000a4000 > ISPCTRL: <1>isp_buf_queue: queue 1 vb 1, mmu 0013a000 > ISPCTRL: <1>isp_buf_queue: queue 2 vb 2, mmu 001d > ISPCTRL: <1>isp_buf_queue: queue 3 vb 3, mmu 00266000 > ISPCTRL: HS_VS_IRQ <6>ISPCTRL: OVF_IRQ <6>ISPCTRL: > ISPCTRL: HS_VS_IRQ <6>ISPCTRL: OVF_IRQ <6>ISPCTRL: > ISPCTRL: HS_VS_IRQ <6>ISPCTRL: OVF_IRQ <6>ISPCTRL: > ISPCTRL: HS_VS_IRQ <6>ISPCTRL: OVF_IRQ <6>ISPCTRL: Seems that you're getting an overflow in the SBL (Shared Buffer Logic) component, which is the one that manages to save/load the buffers from memory. It could happen because the SBL is writing pretty slow to memory... Is it possible that you share your patches to integrate this sensor driver + boardfile changes you did? That way I can help you more. Regards, Sergio -- 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: v4l2_int_device vs v4l2_subdev?
> > But in user space there is nothing changed having access to > > device and control them. > > As you know, subdev and int-device is all about how to bind > > interface(or host?) and device and make them communicated each other. > > But using subdev device driver with int-device supporting interface > > (or host) device driver? it won't make any communication. > > So if you are running out of time with your project, you'd better use > > old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if > > you have enough time and wanna be challenging, try to convert > > in-device based omap3 camera interface driver to subdev supporting > > one. > > Someone's got to do this. v4l2_subdev is the future and it has many > advantages over the older interfaces. The ability to be able to use the > same i2c driver in anything from USB webcams to PCI capture cards to > omap/davinci embedded platforms is very powerful. Hi, We have already this framework migration planned, but we haven't been able to do it, because we are still solving stability issues on the driver. I beg for your patience, and i hope i can get my hands on this pretty soon. I'll be updating my tree when i have something. Regards, Sergio-- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto > From: Gary Thomas [mailto:g...@mlbassoc.com] > > Aguirre Rodriguez, Sergio Alberto wrote: > > > From: Gary Thomas [mailto:g...@mlbassoc.com] > > >> Aguirre Rodriguez, Sergio Alberto wrote: > > >>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > >>> ow...@vger.kernel.org] On Behalf Of Zach LeRoy > > >>>> I am working on adding support for a micron 2 MP sensor: mt9d111 on > a > > >>>> gumsitx overo. This is a i2c-controlled sensor. Ideally, I would > > like > > >> to > > >>>> use the omap34xxcam driver to interface with this sensor. I am > > >> wondering > > >>>> if there are currently any distributions which already include > > support > > >> for > > >>>> this sensor through the omap34xxcam driver, or if anyone else is > > >>>> interested in this topic. > > >>>> > > >>> Hi Zach, > > >>> > > >>> I'm working along with Sakari Ailus and others in this omap34xxcam > > >> driver you're talking about, and we are in the process to provide a > > newer > > >> patchset to work on the latest l-o tree. > > >>> Sakari is sharing the camera core here: > > >>> > > >>> http://gitorious.org/omap3camera > > >>> > > >>> And I have also this repository which contains a snapshot of > Sakari's > > >> tree + support from some sensors I have available for the 3430SDP and > > LDP > > >> (the name could confuse with the above, but I'll change the > > name/location > > >> soon): > > >>> http://gitorious.org/omap3-linux-camera-driver > > >>> > > >>> Testing the driver with as much sensors as we can is very > interesting > > >> (at least for me), because that help us spot possible bugs that > aren't > > >> seen with our current HW. So, I'll be looking forward if you add this > > >> sensor driver to the supported list :) > > >> I'd like to move forward using this on OMAP/3530 with TVP5150 (S- > video > > in) > > >> > > >> Sadly, the tree above (omap3-linux-camera-driver) won't build for the > > >> Zoom/LDP: > > >> CC arch/arm/mach-omap2/board-ldp-camera.o > > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > > >> camera.c:59: > > >> error: implicit declaration of function 'PAGE_ALIGN' > > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > > >> camera.c:59: > > >> error: initializer element is not constant > > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > > >> camera.c:59: > > >> error: (near initialization for 'ov3640_hwc.capture_mem') > > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > > camera.c: > > >> In function 'ov3640_sensor_set_prv_data': > > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > > >> camera.c:89: > > >> error: 'hwc' undeclared (first use in this function) > > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > > >> camera.c:89: > > >> error: (Each undeclared identifier is reported only once > > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > > >> camera.c:89: > > >> error: for each function it appears in.) > > >> > > >> Looking at the code, it seems that some pieces are missing - merge > > >> problem maybe? > > > > > > Hi Gary, > > > > > > I'm currently on the process to rebase and verify all this code on > > 3430SDP, Zoom1 and soon Zoom2. > > > > > > Here you can find my progress: > > > > > > http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary > > > > > > Check devel branch, which contains all latest Sakari's tree patches > > (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o > PM > > tree, plus the patches, which are still in works, to make the above > > mentioned platforms to work. > > > > > > I'm first trying to make 3430SDP work, do
RE: OMAP34XXCAM: Micron mt9d111 sensor support?
> -Original Message- > From: Gary Thomas [mailto:g...@mlbassoc.com] > Sent: Tuesday, June 23, 2009 8:23 AM > To: Aguirre Rodriguez, Sergio Alberto > Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus > Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? > > Aguirre Rodriguez, Sergio Alberto wrote: > >> -Original Message- > >> From: Gary Thomas [mailto:g...@mlbassoc.com] > >> Sent: Monday, June 22, 2009 1:06 PM > >> To: Aguirre Rodriguez, Sergio Alberto > >> Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus > >> Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? > >> > >> Aguirre Rodriguez, Sergio Alberto wrote: > >>>> -Original Message- > >>>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >>>> ow...@vger.kernel.org] On Behalf Of Zach LeRoy > >>>> Sent: Wednesday, June 17, 2009 5:06 PM > >>>> To: linux-omap; linux-media@vger.kernel.org > >>>> Subject: OMAP34XXCAM: Micron mt9d111 sensor support? > >>>> > >>>> I am working on adding support for a micron 2 MP sensor: mt9d111 on a > >>>> gumsitx overo. This is a i2c-controlled sensor. Ideally, I would > like > >> to > >>>> use the omap34xxcam driver to interface with this sensor. I am > >> wondering > >>>> if there are currently any distributions which already include > support > >> for > >>>> this sensor through the omap34xxcam driver, or if anyone else is > >>>> interested in this topic. > >>>> > >>> Hi Zach, > >>> > >>> I'm working along with Sakari Ailus and others in this omap34xxcam > >> driver you're talking about, and we are in the process to provide a > newer > >> patchset to work on the latest l-o tree. > >>> Sakari is sharing the camera core here: > >>> > >>> http://gitorious.org/omap3camera > >>> > >>> And I have also this repository which contains a snapshot of Sakari's > >> tree + support from some sensors I have available for the 3430SDP and > LDP > >> (the name could confuse with the above, but I'll change the > name/location > >> soon): > >>> http://gitorious.org/omap3-linux-camera-driver > >>> > >>> Testing the driver with as much sensors as we can is very interesting > >> (at least for me), because that help us spot possible bugs that aren't > >> seen with our current HW. So, I'll be looking forward if you add this > >> sensor driver to the supported list :) > >> I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video > in) > >> > >> Sadly, the tree above (omap3-linux-camera-driver) won't build for the > >> Zoom/LDP: > >> CC arch/arm/mach-omap2/board-ldp-camera.o > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > >> camera.c:59: > >> error: implicit declaration of function 'PAGE_ALIGN' > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > >> camera.c:59: > >> error: initializer element is not constant > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > >> camera.c:59: > >> error: (near initialization for 'ov3640_hwc.capture_mem') > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > camera.c: > >> In function 'ov3640_sensor_set_prv_data': > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > >> camera.c:89: > >> error: 'hwc' undeclared (first use in this function) > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > >> camera.c:89: > >> error: (Each undeclared identifier is reported only once > >> /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > >> camera.c:89: > >> error: for each function it appears in.) > >> > >> Looking at the code, it seems that some pieces are missing - merge > >> problem maybe? > > > > Hi Gary, > > > > I'm currently on the process to rebase and verify all this code on > 3430SDP, Zoom1 and soon Zoom2. > > > > Here you can find my progress: > > > > http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary > > > > Check devel branch, which contains all latest Sakari's tree patches > (http://
RE: OMAP34XXCAM: Micron mt9d111 sensor support?
> -Original Message- > From: Gary Thomas [mailto:g...@mlbassoc.com] > Sent: Monday, June 22, 2009 1:06 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: Zach LeRoy; linux-omap; linux-media@vger.kernel.org; Sakari Ailus > Subject: Re: OMAP34XXCAM: Micron mt9d111 sensor support? > > Aguirre Rodriguez, Sergio Alberto wrote: > > > >> -Original Message- > >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >> ow...@vger.kernel.org] On Behalf Of Zach LeRoy > >> Sent: Wednesday, June 17, 2009 5:06 PM > >> To: linux-omap; linux-media@vger.kernel.org > >> Subject: OMAP34XXCAM: Micron mt9d111 sensor support? > >> > >> I am working on adding support for a micron 2 MP sensor: mt9d111 on a > >> gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like > to > >> use the omap34xxcam driver to interface with this sensor. I am > wondering > >> if there are currently any distributions which already include support > for > >> this sensor through the omap34xxcam driver, or if anyone else is > >> interested in this topic. > >> > > > > Hi Zach, > > > > I'm working along with Sakari Ailus and others in this omap34xxcam > driver you're talking about, and we are in the process to provide a newer > patchset to work on the latest l-o tree. > > > > Sakari is sharing the camera core here: > > > > http://gitorious.org/omap3camera > > > > And I have also this repository which contains a snapshot of Sakari's > tree + support from some sensors I have available for the 3430SDP and LDP > (the name could confuse with the above, but I'll change the name/location > soon): > > > > http://gitorious.org/omap3-linux-camera-driver > > > > Testing the driver with as much sensors as we can is very interesting > (at least for me), because that help us spot possible bugs that aren't > seen with our current HW. So, I'll be looking forward if you add this > sensor driver to the supported list :) > > > > I'd like to move forward using this on OMAP/3530 with TVP5150 (S-video in) > > Sadly, the tree above (omap3-linux-camera-driver) won't build for the > Zoom/LDP: > CC arch/arm/mach-omap2/board-ldp-camera.o > /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > camera.c:59: > error: implicit declaration of function 'PAGE_ALIGN' > /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > camera.c:59: > error: initializer element is not constant > /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > camera.c:59: > error: (near initialization for 'ov3640_hwc.capture_mem') > /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp-camera.c: > In function 'ov3640_sensor_set_prv_data': > /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > camera.c:89: > error: 'hwc' undeclared (first use in this function) > /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > camera.c:89: > error: (Each undeclared identifier is reported only once > /local/omap3-linux-camera-driver/arch/arm/mach-omap2/board-ldp- > camera.c:89: > error: for each function it appears in.) > > Looking at the code, it seems that some pieces are missing - merge > problem maybe? Hi Gary, I'm currently on the process to rebase and verify all this code on 3430SDP, Zoom1 and soon Zoom2. Here you can find my progress: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Check devel branch, which contains all latest Sakari's tree patches (http://gitorious.org/omap3camera) rebased on top of latest Kevin's l-o PM tree, plus the patches, which are still in works, to make the above mentioned platforms to work. I'm first trying to make 3430SDP work, don't have a Zoom1/Zoom2 handy right now... My gitorious tree will eventually disappear, as I can work better with this new one. I'll consolidate some patches when this sensor code is ready, and will CC you if interested. Regards, Sergio > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > > -- 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: OMAP3 ISP and camera drivers (update 2)
> -Original Message- > From: Menon, Nishanth > Sent: Monday, June 22, 2009 9:50 AM > To: Aguirre Rodriguez, Sergio Alberto; Dongsoo Kim > Cc: Tuukka.O Toivonen; Sakari Ailus; linux-media@vger.kernel.org; > Hiremath, Vaibhav; Koskipaa Antti (Nokia-D/Helsinki); Cohen David.A > (Nokia-D/Helsinki); Alexey Klimov; g...@mlbassoc.com > Subject: RE: OMAP3 ISP and camera drivers (update 2) > > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto > > Sent: Monday, June 22, 2009 5:22 PM > > > Thank you Sergio. So you mean that I can buy OMAP Zoom target board > > > with MT or OV sensor on it sooner or later? cool! > > > > AFAIK, when you buy the Zoom Target platform, you can only have OV3640 > > sensor. BUT you could hack the board to include another sensor (Maybe > > consulting Logic people could clarify this). > > > > In Zoom1, I'll be able just to test the OV3640 sensor, which is the one > I > > have available here. > > > > On 3430SDP, is where I do have MT9P012 sensor (5MP RAW sensor) connected > > in parallel, and an OV3640 (Smart sensor, but driver is using it as RAW > > sensor currently only) in CSI2 interface. > > > > Curious: Thought we had two sensors: OV3640[1] on zoom1 and a 8MP sensor > on zoom2[2] -> am I wrong in saying that the connectors are compatible > since both are CSI2[3]? You're not wrong. The connectors are compatible, it'll be a matter of the driver part located in board specific code to request the necessary datalanes for the transmission to be done adequately. But both should follow CSI2 standard spec. > > SDP3430[4] supports MT9p012(CPI) and ov3640(CSI2).. as long as someone can > put a sensor with the right connectors and voltage checks, they should be > "plug and play" - at least from a h/w perspective ;) Yes, that's correct. Only proper sensor driver will be required of course... > > Regards, > Nishanth Menon > Ref: > [1] http://www.ovt.com/products/part_detail.php?id=26 > [2] > https://www.omapzoom.org/gf/project/omapzoom/wiki/?pagename=WhatIsZoom2 > [3] > https://www.omapzoom.com/gf/project/omapandroid/mailman/?_forum_action=For > umMessageBrowse&thread_id=1912&action=ListThreads&mailman_id=22 > [4] > http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&n > avigationId=12013&contentId=28741#sdp -- 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: OMAP3 ISP and camera drivers (update 2)
> -Original Message- > From: Dongsoo Kim [mailto:dongsoo@gmail.com] > Sent: Monday, June 22, 2009 9:05 AM > To: Aguirre Rodriguez, Sergio Alberto > Cc: Tuukka.O Toivonen; Sakari Ailus; linux-media@vger.kernel.org; > Hiremath, Vaibhav; Koskipaa Antti (Nokia-D/Helsinki); Cohen David.A > (Nokia-D/Helsinki); Alexey Klimov; g...@mlbassoc.com > Subject: Re: OMAP3 ISP and camera drivers (update 2) > > > 2009. 06. 22, 오후 11:01, Aguirre Rodriguez, Sergio Alberto 작성: > > >> -Original Message- > >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >> ow...@vger.kernel.org] On Behalf Of Tuukka.O Toivonen > >> Sent: Monday, June 22, 2009 8:52 AM > >> To: ext Dongsoo, Nathaniel Kim > >> Cc: Sakari Ailus; linux-media@vger.kernel.org; Aguirre Rodriguez, > >> Sergio > >> Alberto; Hiremath, Vaibhav; Koskipaa Antti (Nokia-D/Helsinki); Cohen > >> David.A (Nokia-D/Helsinki); Alexey Klimov; g...@mlbassoc.com > >> Subject: Re: OMAP3 ISP and camera drivers (update 2) > >> > >> On Saturday 20 June 2009 12:05:13 ext Dongsoo, Nathaniel Kim wrote: > >>> Following patch. > >>> > >> > http://www.gitorious.org/omap3camera/mainline/commit/d92c96406296310a977b0 > >> 0f45b209523929b15b5 > >>> What happens to the capability when the int device is dummy? (does > >>> it > >>> mean that there is no int device?) > >> > >> Yes, when the int device is dummy, there is no such a device. > >> For example, when vdev->vdev_sensor == v4l2_int_device_dummy() > >> it means that the device has no sensor. > >> > >> In that case, obviously, the device is not capable of capturing > >> or streaming. > >> > >>> And one more thing. If I want to test how the "ISP" driver is > >>> working, > >>> is there any target board that I can buy also a sensor device > >>> already > >>> attached on it? > >> > >> I think that TI probably has some boards for sale, you > >> could take a look at their web pages. > > > > Hi Nate, > > > > I'm currently rebasing these patches on top of latest Kevin's PM > > tree, and trying to make 3430SDP (MT9P012 and OV3640), Zoom1 and > > Zoom2 (not there yet, but in the works) sensors to work in there. > > Thank you Sergio. So you mean that I can buy OMAP Zoom target board > with MT or OV sensor on it sooner or later? cool! AFAIK, when you buy the Zoom Target platform, you can only have OV3640 sensor. BUT you could hack the board to include another sensor (Maybe consulting Logic people could clarify this). In Zoom1, I'll be able just to test the OV3640 sensor, which is the one I have available here. On 3430SDP, is where I do have MT9P012 sensor (5MP RAW sensor) connected in parallel, and an OV3640 (Smart sensor, but driver is using it as RAW sensor currently only) in CSI2 interface. > > > > > You can find this tree on: > > > > http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary > > > > Checkout devel branch. > > > > That's my latest progress. > > OK I'll try to look at the devel branch. > Cheers, > > Nate > > > > > Regards, > > Sergio > >> > >> - Tuukka > >> -- > >> 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: OMAP3 ISP and camera drivers (update 2)
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Tuukka.O Toivonen > Sent: Monday, June 22, 2009 8:52 AM > To: ext Dongsoo, Nathaniel Kim > Cc: Sakari Ailus; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio > Alberto; Hiremath, Vaibhav; Koskipaa Antti (Nokia-D/Helsinki); Cohen > David.A (Nokia-D/Helsinki); Alexey Klimov; g...@mlbassoc.com > Subject: Re: OMAP3 ISP and camera drivers (update 2) > > On Saturday 20 June 2009 12:05:13 ext Dongsoo, Nathaniel Kim wrote: > > Following patch. > > > http://www.gitorious.org/omap3camera/mainline/commit/d92c96406296310a977b0 > 0f45b209523929b15b5 > > What happens to the capability when the int device is dummy? (does it > > mean that there is no int device?) > > Yes, when the int device is dummy, there is no such a device. > For example, when vdev->vdev_sensor == v4l2_int_device_dummy() > it means that the device has no sensor. > > In that case, obviously, the device is not capable of capturing > or streaming. > > > And one more thing. If I want to test how the "ISP" driver is working, > > is there any target board that I can buy also a sensor device already > > attached on it? > > I think that TI probably has some boards for sale, you > could take a look at their web pages. Hi Nate, I'm currently rebasing these patches on top of latest Kevin's PM tree, and trying to make 3430SDP (MT9P012 and OV3640), Zoom1 and Zoom2 (not there yet, but in the works) sensors to work in there. You can find this tree on: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Checkout devel branch. That's my latest progress. Regards, Sergio > > - Tuukka > -- > 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: OMAP34XXCAM: Micron mt9d111 sensor support?
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Zach LeRoy > Sent: Wednesday, June 17, 2009 5:06 PM > To: linux-omap; linux-media@vger.kernel.org > Subject: OMAP34XXCAM: Micron mt9d111 sensor support? > > I am working on adding support for a micron 2 MP sensor: mt9d111 on a > gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to > use the omap34xxcam driver to interface with this sensor. I am wondering > if there are currently any distributions which already include support for > this sensor through the omap34xxcam driver, or if anyone else is > interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) Regards, Sergio > > Cheers, > > Zach LeRoy > -- > 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: OMAP patches for linux-media
> From: Mauro Carvalho Chehab [mche...@infradead.org] > Sent: Tuesday, June 16, 2009 8:40 AM > To: Sakari Ailus > Cc: Jadav, Brijesh R; Subrahmanya, Chaithrika; David Cohen; Curran, Dominic; > Eduardo Valentin; Eero Nurkkala; Felipe Balbi; Shah, Hardik; Nagalla, Hari; > Hadli, Manjunath; Mikko Hurskainen; Karicheri, Muralidharan; Menon, Nishanth; > R, Sivaraj; Paulraj, Sandeep; Aguirre Rodriguez, Sergio Alberto; Tomi > Valkeinen; Tuukka Toivonen; Hiremath, Vaibhav; Hans Verkuil; Linux Media > Mailing List > Subject: OMAP patches for linux-media > > Hi Sakari and others, > > I'm seeing lots of patches and discussions for OMAP and DaVinci being handled > at the linux-media Mailing List, as part of the development process of the > open > source drivers. > > However, it is hard to track all those discussions and be sure what patches > are > ready for merging and what patches are just RFC. > > On the development model we use here, we have driver maintainers that are > responsible to discuss about improvements on their drivers. They are generally > the driver authors or the one that first started submitting the patches for > that driver(s). > > One of the roles of the driver maintainers is to collect the patches for the > drivers they maintain, merge on their trees, and periodically ask the patch > merge. > > One fundamental concept on Kernel development is the concept of "Commit > earlier > and commit often", meaning that the better is to send small, incremental, and > periodic patches, than wait until having everything done, then submit a big > patch. Every time I receive a big patch I need to postpone its analysis and > open a big window on my schedule to analyze it. Of course, this means to > postpone it, and generally results on lots of comments going back to > developer, > that, in turn, will need to do lots of changes and return me back with another > big patch for me to analyze again, resulting on a long period of time for > merging it. > > As you, Sakari, was the first one that started merging the OMAP drivers, I was > expecting that you would be the one that will handle the figure of the driver > maintainer for OMAP. I even created you an account at linuxtv for you to > create > your trees there and ask me to merge from it. > > Unfortunately, you haven't sent me any pull requests yet along this year. This > is concerning me a lot, since, at the end, I'll need to review big piles of > patches and/or drivers when you decide to submit the final version. > > So, I decided to send you this email, c/c a random list of people that I > believe are involved on the submit and/or review process of those patches, in > the hope to better understand and to discuss what's happening and how can we > speedup the merge process of those patches. Hi Mauro, We are currently going through an internal debugging process on new found issues while testing the driver on a proprietary HW/SW platform. As there is priority for us to find stability in this platforms, we had to put aside a bit the maintenance of the shared patches. One maybe important news is that I'll be creating a new tree soon to host current OMAP3 and future OMAP4 camera drivers for upstream from TI perspective. My main task will be to maintain this tree in TI, and take care of upstreaming and fixing patches for acceptance by both linux-omap and linux-media lists. Some of the known to-dos are: - v4l2_subdev conversion - Regulator framework usage - ISP registration as a memory to memory device. I hope to resume this task soon, and keep in touch with the community on the latest version of patches. I'll let you know when the next version is ready for merge. Thanks for your concern and time on this. Regards, Sergio > > > > 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: New Driver for DaVinci DM355/DM365/DM6446
> From: Karicheri, Muralidharan > Sent: Monday, June 01, 2009 9:58 PM > To: Aguirre Rodriguez, Sergio Alberto; Paulraj, Sandeep; > linux-media@vger.kernel.org > Cc: linux-ker...@vger.kernel.org; Grosen, Mark > Subject: RE: New Driver for DaVinci DM355/DM365/DM6446 > > Sergio, > > Is it part of the patches Vaibhav & others from TI are submitting to open > source ? Yes, currently I have been sharing this codebase with Vaibhav, which he is taking for the 3530 EVM, which uses the camera ISP to receive images from a video decoder using a parallel BT656 output. > I know that there is an > ongoing effort at TI India to submit the resizer driver to open source for > OMAP3? I guess this is still on hold, as the current internal approach is not acceptable in the V4L2 standards. > As per the email > exchanges I had with Vaibhav (TI India) on this, it is part of the ISP module. That's correct. > We plan to submit the > patches to open source for H3A and was trying to see which is the right way > to do it. The ISP driver core that we are sharing, it already has the H3A driver on it, which is accessed through Private IOCTLs declared inside the driver. > We will > investigate the tree you mentioned below and let you know if we have > additional questions. Vaibhav should be already familiar with this codebase, so maybe it could be easier for you to talk with him about this. > The plan is to align with OMAP3 for the implementation. Although the current code maintenance is on hold because i've been busy with some other custormer requirements, i havent been able to continue working on the pending TODOs so far. But as this strategy on a better collaboration with the community is attempted, i'm trying ot find my way to get back wit hthe maintenance of this driver to meet at least the required changes for acceptance of the driver. It'll be definitively good to align on this, so we can avoid rewriting the same thing over again. Regards, Sergio > > regards, > > Murali Karicheri > email: m-kariche...@ti.com > >-Original Message- >From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto >Sent: Monday, June 01, 2009 2:39 PM >To: Paulraj, Sandeep; linux-media@vger.kernel.org >Cc: linux-ker...@vger.kernel.org; Grosen, Mark >Subject: RE: New Driver for DaVinci DM355/DM365/DM6446 > >> From: linux-media-ow...@vger.kernel.org [linux-media- >ow...@vger.kernel.org] On Behalf Of Paulraj, Sandeep >> Sent: Monday, June 01, 2009 5:56 PM >> To: linux-media@vger.kernel.org >> Cc: linux-ker...@vger.kernel.org; Grosen, Mark >> Subject: New Driver for DaVinci DM355/DM365/DM6446 >> >> Hello, >> >> WE have a module(H3A) on Davinci DM6446,DM355 and DM365. >> >> Customers require a way to collect the data required to perform the Auto >Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as >opposed to software. > This is primarily for performance reasons as there >is not enough software processing MIPS (to do 3A statistics) available in >> an imaging/video system. >> >> Including this block in hardware reduces the load on the processor and >bandwidth to the memory as the data is collected on the fly from the imager. >> >> This modules collects statistics and we currently implement it as a >character driver. > >This also exists in OMAP3 chips, and is part of the ISP module. > >I maintain, along with Sakari Ailus, a V4L2 camera driver, which is >currently just shared through a gitorious repository: > >http://gitorious.org/omap3camera > >The way we offer an interface for the user to be able to request this >statistics is with the usage of private IOCTLs declared inside the same >V4L2 capturing device driver. > >So, that way we have a V4L2 driver which has a private call, instead of >having it separately from the capture driver. > >Regards, >Sergio >> >> Which mailing list would be the most appropriate mailing list to submit >patches for review? >> >> Thanks, >> Sandeep >> -- >> 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 -- 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: New Driver for DaVinci DM355/DM365/DM6446
> From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] > On Behalf Of Paulraj, Sandeep > Sent: Monday, June 01, 2009 5:56 PM > To: linux-media@vger.kernel.org > Cc: linux-ker...@vger.kernel.org; Grosen, Mark > Subject: New Driver for DaVinci DM355/DM365/DM6446 > > Hello, > > WE have a module(H3A) on Davinci DM6446,DM355 and DM365. > > Customers require a way to collect the data required to perform the Auto > Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as > opposed to software. > This is primarily for performance reasons as there is > not enough software processing MIPS (to do 3A statistics) available in > an imaging/video system. > > Including this block in hardware reduces the load on the processor and > bandwidth to the memory as the data is collected on the fly from the imager. > > This modules collects statistics and we currently implement it as a character > driver. This also exists in OMAP3 chips, and is part of the ISP module. I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently just shared through a gitorious repository: http://gitorious.org/omap3camera The way we offer an interface for the user to be able to request this statistics is with the usage of private IOCTLs declared inside the same V4L2 capturing device driver. So, that way we have a V4L2 driver which has a private call, instead of having it separately from the capture driver. Regards, Sergio > > Which mailing list would be the most appropriate mailing list to submit > patches for review? > > Thanks, > Sandeep > -- > 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 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
>From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On
>Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
>Sent: Tuesday, May 19, 2009 7:53 AM
>To: Shah, Hardik
>Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
>Hiremath, Vaibhav
>Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>
>Hello Hardik,
>
>Reviewing your driver, I found something made me curious.
>
>
>On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah wrote:
>> +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
>> + * called. This is used to setup buffers and return size and count of
>> + * buffers allocated. After the call to this buffer, videobuf layer will
>> + * setup buffer queue depending on the size and count of buffers
>> + */
>> +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
>> *count,
>> + unsigned int *size)
>> +{
>> + struct omap_vout_device *vout = q->priv_data;
>> + int startindex = 0, i, j;
>> + u32 phy_addr = 0, virt_addr = 0;
>> +
>> + if (!vout)
>> + return -EINVAL;
>> +
>> + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
>> + return -EINVAL;
>> +
>> + startindex = (vout->vid == OMAP_VIDEO1) ?
>> + video1_numbuffers : video2_numbuffers;
>> + if (V4L2_MEMORY_MMAP == vout->memory && *count < startindex)
>> + *count = startindex;
>> +
>> + if ((rotation_enabled(vout->rotation)) && *count > 4)
>> + *count = 4;
>> +
>
>
>
>This seems to be weird to me. If user requests multiple buffers more
>than 4, user cannot recognize that the number of buffers requested is
>forced to change into 4. I'm not sure whether this could be serious or
>not, but it is obvious that user can have doubt about why if user have
>no information about the OMAP H/W.
>Is it really necessary to be configured to 4?
>
>
>Cheers,
>
>Nate
>
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it is
the userspace app responsability to check the value again, to confirm how many
of the requested buffers are actually available.
Regards,
Sergio--
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
[RFC] Updated 3430SDP and LDP camera drivers
Hi all, I have created a gitorious account for storing latest progress on 3430SDP and LDP camera sensor drivers. (MT9P012 and OV3640 for SDP, and OV3640 for LDP) This patchset can be pulled with the following command: git pull git://git.gitorious.org/omap3-linux-camera-driver/mainline.git omap3camerabase 3430sdp_and_ldp_sensor_drivers It is based on 2.6.30-rc2 Notes: - omap3camerabase branch contains a snapshot of almost all the commits shared through Sakari's gitorious repository (http://www.gitorious.org/projects/omap3camera). The only commits lacking are the ones that had been accepted already on mainline/linux-omap. - 3430sdp_and_ldp_sensor_drivers: Contains the patches I have been sharing during the past months but with some fixes done already based on the comments many of you have provided (Thanks a lot for that) Known TODOs: - v4l2_subdev conversion! - ISP xclk exported to Clock API - Memory 2 memory device conversion - Syncup with latest internal tree fixes - Use regulator framework - Fix OV3640 (at least on SDP doesn't work now somehow) As soon as I update them, will let you know. Any comment on those, is completely welcome. Regards, Sergio -- 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
[RFC] V4L2 CID for Testpattern mode
Hi, During the omap3camera development, we came across with the case of imaging sensors which can produce test patterns instead of capturing images from the CCD. What we did in an attempt to keep an standard interface, is that we created a CID named V4L2_CID_TEST_PATTERN of integer type, so 0 is "no test pattern", and from 1 to any supported quantity, to select between supported pattern modes. So, do you think this is good approach? Or is it something which supports already this kind of setting? I think it is a pretty common feature in capturing devices. Regards, Sergio -- 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] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hi Vaibhav, Please find some comments below > -Original Message- > From: Hiremath, Vaibhav > Sent: Monday, March 30, 2009 8:35 AM > To: linux-media@vger.kernel.org > Cc: Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim; Toivonen > Tuukka.O (Nokia-D/Oulu); linux-o...@vger.kernel.org; Nagalla, Hari; Sakari > Ailus; Hans Verkuil; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, > Hardik; Kumar, Purushotam > Subject: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 > framework > > Hi, > > With reference to the mail-thread started by Sakari on Resizer driver > interface, > > http://marc.info/?l=linux-omap&m=123628392325716&w=2 > > I would like to bring some issues and propose changes to adapt such > devices under V4L2 framework. Sorry for delayed response on this mail- > thread, actually I was on vacation. > > As proposed by Sakari, I do agree with the approach of having V4L2 > interface for memory-to-memory operation of the ISP (like resizer and > previewer), but I would like to bring some important aspects/issues here - > > - Some drawbacks of V4L2-buf layer framework for such kind of > devices > - Need for backward compatibility. > > Drawbacks for V4L2-Buf layer - > - > > 1} In case of resizer driver, the input buffer will always be different > than output buffer. > > In case of Mmapped buffer there is no issue, since driver allocates > maximum of input and output. User doesn't have control on this, although > there is loss of memory from system point of view. > > In case of User Pointer Exchange, User would expect and may allocate > different sizes of buffers for input and output which V4L2-buf layer > doesn't support with single queue. And to address this, I think here we > need to have either of following approaches - > > - Use two separate buffer queues, one for input and another for > output. > - Or hack the driver for v4l2_buffer, internally using different > buffer params for input and output. [Not recommended] > > Please note that sometimes application receives buffers from another > driver or from some codecs engine that's why input and output buffer will > never be of same size. > > 2) V4L2-buf layer doesn't support IOMEM coming from user application. Just > to give low level details about this - > > When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer > coming from another driver (which is iomampped), then QUEUEBUF ioctl will > fail from 'videobuf_iolock' --> videobuf_dma_init_user_locked --> > get_user_pages. > > In 'get_user_pages' it checks for IOMEM flag and returns error, which is > expected behavior from Kernel point of view. We are trying to map buffer > which is already mapped to kernel by another driver. I'm not sure if I understood the problem right... Can you please help me clarify? So, basically the problem is that both drivers needs to associate a single buffer with 2 different DMA transfers at the same time (one from other driver, and other from ISP) Is that correct? > > One thing I am not able to understand, how nobody came across such use- > case which is very common. And to address this issue we need to add > support for IOMEM in V4L2-buf layer. > > NOTE: Currently both of these issues have been addressed as a custom > implementation for our internal use case. > > Backward Compatibility - > --- > > This is an important aspect, since similar hardware modules are available > on Davinci as well as on OMAP and their driver interface is completely > different. > > On Davinci, resizer driver is supported through plane char driver > interface which handles all data/buffer processing and control paths. It > maintains internal queue for priority of resizing tasks and stuff. > > The driver is present under /drivers/char/Davinci. > > Here I feel, V4L2 way is better, since all image processing drivers should > go under "drivers/media/video/". And again we can make use of readily > available V4L2 framework interface for data and control path to manage > buffers. We should enhance V4L2 framework to support such devices. > > > Proposed Required Changes - > -- > > I am putting some high level changes required to be done for supporting > such devices - > > - Enhancement in V4L2-buf layer for above issues > > - Will be directly using sub-device frame-work and have to enhance > it to support such devices. > > - Below are the parameters we need to configure for Resizer from > user application - > >
RE: [PATCH 12/13][Resubmit][drivers/media] changed ioctls to unlocked
> > {
> > + lock_kernel();
> > +
>
> Why moving to unlocked_ioctl if you're acquiring the Big Kernel Lock
> anyways?
Ok, forget it, just saw Alexey mail chain...
Understood.
Regards,
Sergio
--
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 12/13][Resubmit][drivers/media] changed ioctls to unlocked
Hi Stoyan,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of stoyboy...@gmail.com
> Sent: Tuesday, March 24, 2009 3:39 PM
> To: linux-ker...@vger.kernel.org
> Cc: Stoyan Gaydarov; linux-media@vger.kernel.org
> Subject: [PATCH 12/13][Resubmit][drivers/media] changed ioctls to unlocked
>
> From: Stoyan Gaydarov
>
> Signed-off-by: Stoyan Gaydarov
> ---
> drivers/media/dvb/bt8xx/dst_ca.c |7 +--
> drivers/media/video/dabusb.c | 11 ---
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/dvb/bt8xx/dst_ca.c
> b/drivers/media/dvb/bt8xx/dst_ca.c
> index 0258451..d3487c5 100644
> --- a/drivers/media/dvb/bt8xx/dst_ca.c
> +++ b/drivers/media/dvb/bt8xx/dst_ca.c
> @@ -552,8 +552,10 @@ free_mem_and_exit:
> return result;
> }
>
> -static int dst_ca_ioctl(struct inode *inode, struct file *file, unsigned
> int cmd, unsigned long ioctl_arg)
> +static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned
> long ioctl_arg)
> {
> + lock_kernel();
> +
Why moving to unlocked_ioctl if you're acquiring the Big Kernel Lock anyways?
--
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
Some possible missing v4l2_subdev IOCTLs.
Hi Hans, I did a quick analysis of the subdev, and noticed that some video ioctls for the subdevices aren't there... [gs]_crop [gs]_parm enum_frameintervals enum_framesizes enum_fmt_cap I noticed this because we currently use them for a "best sensor output" selection before sending the image to the OMAP3 ISP. Any particular reason why these aren't there? Regards, Sergio -- 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: ISP Configuration for RAW Bayer sensor
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Suresh Rao
> Sent: Thursday, March 19, 2009 7:59 AM
> To: linux-media@vger.kernel.org
> Cc: Tuukka.O Toivonen
> Subject: Re: ISP Configuration for RAW Bayer sensor
>
> Hi Tuukka,
>
> Thanks a lot for the patch, I will try this.
>
> I tried similar thing but on the sensor side and it worked, ie., I
> skip the very first line from readout and get the desired format for
> the ISP.
Hi Suresh,
I am currently working on a patch for solving these type of adjustments.
The main idea is to specify from the sensor to the ISP, which is the output Raw
sequence: RGGB, GRBG, BGGR, GBRG. And then adjust internal ISP reading offset
to interpret the image adequately...
I'll post the patch as soon as I have it ready (I'm currently busy with some
other higher priority tasks for these remaining 2 weeks of the month :I)
Regards,
Sergio
>
> Thanks,
> Suresh
>
> On Thu, Mar 19, 2009 at 1:12 PM, Tuukka.O Toivonen
> wrote:
> > On Wednesday 18 March 2009 18:17:56 ext Suresh Rao wrote:
> >> I am working with MT9V023 RAW sensor. The data format from the sensor
> is
> >>
> >> B G B G B G B G ...
> >> G R G R G R G R ...
> >> B G B G B G B G ...
> >> G R G R G R G R [ Format 1]
> > [...]
> >> I want to use the ISP on the OMAP for doing interpolation and format
> >> conversion to UYVY. I am able to capture the images from the sensor,
> >> however I notice that the color information is missing. I dug the
> >> sources and found that in the RAW capture mode ISP is getting
> >> configured to input format
> >>
> >> G R G R G R G R ...
> >> B G B G B G B G ...
> >> G R G R G R G R ...
> >> B G B G B G B G ... [Format 2]
> >>
> >> Has anyone tried sensors with BGGR ( Format 1) on OMAP?
> >>
> >> Can anyone give me some pointers or information on how to configure
> >> ISP for BGGR (Format 1)
> >
> > If you can live with losing a few pixels (maybe sensor has a few extra)
> > I recommend to configure ISP to crop away the topmost line.
> >
> > Here's couple of old _example_ patches how to configure the cropping.
> > Just gives an idea where to start...
> >
> > - Tuukka
> >
> >
> > diff --git a/drivers/media/video/isp/ispccdc.c
> b/drivers/media/video/isp/ispccdc.c
> > index 2288bc9..87870f1 100644
> > --- a/drivers/media/video/isp/ispccdc.c
> > +++ b/drivers/media/video/isp/ispccdc.c
> > @@ -1189,13 +1189,13 @@ int ispccdc_config_size(u32 input_w, u32 input_h,
> u32 output_w, u32 output_h)
> > ISPCCDC_HORZ_INFO);
> > } else {
> > if (ispccdc_obj.ccdc_inpfmt == CCDC_RAW) {
> > - omap_writel(1 <<
> ISPCCDC_HORZ_INFO_SPH_SHIFT
> > - |
> ((ispccdc_obj.ccdcout_w - 1)
> > + omap_writel(0 <<
> ISPCCDC_HORZ_INFO_SPH_SHIFT
> > + | (ispccdc_obj.ccdcout_w
> > <<
> ISPCCDC_HORZ_INFO_NPH_SHIFT),
> > ISPCCDC_HORZ_INFO);
> > } else {
> > omap_writel(0 <<
> ISPCCDC_HORZ_INFO_SPH_SHIFT
> > - |
> ((ispccdc_obj.ccdcout_w - 1)
> > + | (ispccdc_obj.ccdcout_w
> > <<
> ISPCCDC_HORZ_INFO_NPH_SHIFT),
> > ISPCCDC_HORZ_INFO);
> > }
> > @@ -1227,7 +1227,7 @@ int ispccdc_config_size(u32 input_w, u32 input_h,
> u32 output_w, u32 output_h)
> > ISPCCDC_VP_OUT_VERT_NUM_SHIFT),
> > ISPCCDC_VP_OUT);
> > omap_writel(0 << ISPCCDC_HORZ_INFO_SPH_SHIFT |
> > - ((ispccdc_obj.ccdcout_w - 1) <<
> > + (ispccdc_obj.ccdcout_w <<
> > ISPCCDC_HORZ_INFO_NPH_SHIFT),
> > ISPCCDC_HORZ_INFO);
> > omap_writel(0 << ISPCCDC_VERT_START_SLV0_SHIFT,
> > diff --git a/drivers/media/video/isp/ispccdc.c
> > b/drivers/media/video/isp/ispccdc.c
> > index f5957b2..6afaabf 100644
> > --- a/drivers/media/video/isp/ispccdc.c
> > +++ b/drivers/media/video/isp/ispccdc.c
> > @@ -478,7 +478,7 @@ EXPORT_SYMBOL(ispccdc_enable_lsc);
> > **/
> > void ispccdc_config_crop(u32 left, u32 top, u32 height, u32 width)
> > {
> > - ispccdc_obj.ccdcin_woffset = left + ((left + 1) % 2);
> > + ispccdc_obj.ccdcin_woffset = left + (left % 2);
> > ispccdc_obj.ccdcin_hoffset = top + (top % 2);
> >
> > ispccdc_obj.crop_w = width - (width % 16);
> > @@ -1166,7 +1166,7 @@ int ispccdc_config_size(u32 inpu
RE: [PATCH 5/5] LDP: Add support for built-in camera
> -Original Message-
> From: stanley.miao [mailto:stanley.m...@windriver.com]
> Sent: Tuesday, March 10, 2009 3:04 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus;
> Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley;
> Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth
> Subject: RE: [PATCH 5/5] LDP: Add support for built-in camera
>
> On Mon, 2009-03-09 at 15:24 -0500, Aguirre Rodriguez, Sergio Alberto
> wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: stanley.miao [mailto:stanley.m...@windriver.com]
> >
> >
> >
> > > > +static struct i2c_board_info __initdata ldp_i2c_boardinfo_2[] = {
> > > > +#if defined(CONFIG_VIDEO_OV3640) ||
> defined(CONFIG_VIDEO_OV3640_MODULE)
> > > > + {
> > > > + I2C_BOARD_INFO("ov3640", OV3640_I2C_ADDR),
> > > > + .platform_data = &ldp_ov3640_platform_data,
> > > > + },
> > > > +#endif
> > > > +};
> > > >
> > > This new added i2c_board_info was not registered.
> > > After I added this line,
> > >
> > > omap_register_i2c_bus(2, 400, ldp_i2c_boardinfo_2,
> > > ARRAY_SIZE(ldp_i2c_boardinfo_2));
> > >
> > > the sensor was found. but the test still failed. A lot of error came
> out
> > > when I run my test program.
> > >
> > > <3>CSI2: ComplexIO Error IRQ 80
> > > CSI2: ComplexIO Error IRQ 80
> > > <3>CSI2: ComplexIO Error IRQ c2
> > > CSI2: ComplexIO Error IRQ c2
> > > <3>CSI2: ComplexIO Error IRQ c2
> > > CSI2: ComplexIO Error IRQ c2
> > > <3>CSI2: ComplexIO Error IRQ c6
> > > CSI2: ComplexIO Error IRQ c6
> > > <3>CSI2: ECC correction failed
> > > CSI2: ECC correction failed
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > > <3>CSI2: ComplexIO Error IRQ 6
> > > CSI2: ComplexIO Error IRQ 6
> > >
> >
> > Oops, my mistake. Missed to add that struct there... Fixed now.
> >
> > About the CSI2 errors you're receiving... Which version of LDP are you
> using? Which Silicon revision has (ES2.1 or ES3.0)?
>
> ZOOM1 board(LDP3430-VG1.0.0-1), omap3430 ES2.1.
>
> When I use your old version patch, sometimes the test succeed, sometimes
> failed(no data was generated and no error). This version, always failed.
Stanley,
I'm working on some CSI2 fixes that could help you with this..
I'll keep you updated on this.
Also, about your board version, it is possible that you'll need a HW modfix
because of a redundant resistor in CSI2 datalanes. I'm in talks with some
people at TI to prepare a ready to publish document about this rework.
Zoom1 with ES3 silicon doesn't need this HW fix.
I'll hope to get back to you about this next week.
Regards,
Sergio
>
> Thanks.
> Stanley.
>
> >
> > Regards,
> > Sergio
> > >
> > > Stanley.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hi, > -Original Message- > From: Alexey Klimov [mailto:klimov.li...@gmail.com] > Sent: Saturday, March 07, 2009 9:42 AM > To: DongSoo(Nathaniel) Kim > Cc: Curran, Dominic; Aguirre Rodriguez, Sergio Alberto; linux- > me...@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; Tuukka.O > Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; > Lakhani, Amish; Menon, Nishanth > Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 > > Hello, all > > On Fri, 2009-03-06 at 10:54 +0900, DongSoo(Nathaniel) Kim wrote: > > Hi Alexey, > > > > On Fri, Mar 6, 2009 at 7:05 AM, Alexey Klimov > wrote: > > > Hello, all > > > > > > On Thu, Mar 5, 2009 at 7:42 PM, Curran, Dominic > wrote: > > >> > > >> Hi Kim > > >> > > >>> -Original Message- > > >>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > >>> ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim > > >>> Sent: Wednesday, March 04, 2009 8:58 PM > > >>> To: Aguirre Rodriguez, Sergio Alberto > > >>> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari > Ailus; > > >>> Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; > Hiremath, > > >>> Vaibhav; Lakhani, Amish; Menon, Nishanth > > >>> Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 > > >>> > > >>> Hi Sergio, > > >>> > > >>> > > >>> > > >>> On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto > > >>> wrote: > > >>> > + /* turn on analog power */ > > >>> > + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, > > >>> > + VAUX_2_8_V, > TWL4030_VAUX2_DEDICATED); > > >>> > + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, > > >>> > + VAUX_DEV_GRP_P1, > TWL4030_VAUX2_DEV_GRP); > > >>> > + > > >>> > + /* out of standby */ > > >>> > + gpio_set_value(MT9P012_STANDBY_GPIO, 0); > > >>> > + udelay(1000); > > >>> > > >>> It seems better using msleep rather than udelay for 1000us much. > Just > > >>> to be safe :) > > >>> How about you? > > >>> > > >> > > >> Why is msleep safer than udelay ? > > > > > > I have small guess that he is wondering why you are using big delays > > > with help of udelay(). (It's may be obvious but as we know udelay uses > > > cpu loops to make delay and msleep calls to scheduler) So, msleep is > > > more flexible and "softer" but if you need precise time or you can't > > > sleep in code you need udelay. Sometimes using udelay is reasonably > > > required. > > > > I totally agree with you. > > But besides the "udelay and mdelay accuracy" issue, Sergio's power up > > timing for MT9P012 seems to delay too much. (not for lens > > controller.) > > I also have experience using MT9P012 sensor with other ISP, but in > > case of mine it took 600 to 800 ms for whole power up sequence. > > But if that delay depends on SDP board and Sergio had no options > > without making delay for that much, then it explains everything. > > So I'm saying if there was no other option than making long delay to > > bring up MT9P012 sensor properly, if I were Sergio I should rather use > > mdelay than udelay. > > I agree with you. mdelay is really safer that udelay. Sorry for not participating much in this thread, I have been busy fixing other comments. This delay setting was set before I ever touched this drivers by other omap3 Linux camera ex-team member here in TI. I suspect they were set to the minimum working level in SDP already, but I haven't honestly tried to move them. I guess it's a good time to do so. :) I'll fix some other things first, and put this on my plate to check before reposting next version of drivers. I really appreciate your feedback on this. Regards, Sergio > > >From file include/linux/delay.h: > > * Using udelay() for intervals greater than a few milliseconds can > * risk overflow for high loops_per_jiffy (high bogomips) machines. The > * mdelay() provides a wrapper to prevent this. For delays greater > * than MAX_UDELAY_MS milliseconds, the wrapper is used. Architecture > * specific values can be defined in asm-???/delay.h as an override. > > So, let's Sergio check and decide what he needed! :) > > > Cheers, > > > > Nate > > -- > Best regards, Klimov Alexey > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OV3640: Add driver
> -Original Message-
> From: Trent Piepho [mailto:xy...@speakeasy.org]
> Sent: Wednesday, March 04, 2009 7:42 PM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus;
> Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley;
> Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth
> Subject: Re: [PATCH 3/5] OV3640: Add driver
>
> On Tue, 3 Mar 2009, Aguirre Rodriguez, Sergio Alberto wrote:
> > + {
> > + /* Note: V4L2 defines RGB565 as:
> > +*
> > +* Byte 0Byte 1
> > +* g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4
> g3
> > +*
> > +* We interpret RGB565 as:
> > +*
> > +* Byte 0Byte 1
> > +* g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4
> g3
>
> The V4L2 spec was corrected to define the RGB565 the normal way.
Oh ok.. Didn't knew that..
Removed that note.
Thanks!
Sergio
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OV3640: Add driver
Hi Alexey,
> -Original Message-
> From: Alexey Klimov [mailto:klimov.li...@gmail.com]
> > --- /dev/null
> > +++ b/drivers/media/video/ov3640.c
> > @@ -0,0 +1,2202 @@
> > +/*
> > + * drivers/media/video/ov3640.c
> > + *
> > + * ov3640 sensor driver
> > + *
> > + *
> > + * Copyright (C) 2008 Texas Instruments.
>
> 2009 ?
Fixed.
> > +static int ov3640_read_reg(struct i2c_client *client, u16 data_length,
> u16 reg,
> > + u32
> *val)
> > +{
> > + int err = 0;
> > + struct i2c_msg msg[1];
> > + unsigned char data[4];
> > +
> > + if (!client->adapter)
> > + return -ENODEV;
> > +
> > + msg->addr = client->addr;
> > + msg->flags = I2C_M_WR;
> > + msg->len = 2;
> > + msg->buf = data;
> > +
> > + /* High byte goes out first */
> > + data[0] = (u8) (reg >> 8);
> > + data[1] = (u8) (reg & 0xff);
> > +
> > + err = i2c_transfer(client->adapter, msg, 1);
>
> Please, let me understand.. You call i2c_transfer() and ask it to
> transfer one message(third parameter), right ?
> So, the returned value is negative errno or the number of messages
> executed. Logic says that you should check somethin like this:
> if (err = 1) {
> good;
> } else {
> i2c_transfer failed;
> we should deal with it(printk, try again, etc)
> }
>
> Or even:
> if (unlikely(err != 1)) {
> i2c_transfer failed;
> }
> Good code continue;
>
> Right or wrong ?
The idea of this piece of code is to:
- First do a write transfer with nothing else than the register address to read.
- Then do a I2C read transfer to receive the value from register selected in
previous write with the size of data_length variable.
I do agree that perhaps a cleanup for this piece of code needs to be done...
I'll clean it up, test, and repost the resulting patch for your review. :)
>
> > + if (err >= 0) {
> > + mdelay(3);
> > + msg->flags = I2C_M_RD;
> > + msg->len = data_length;
> > + err = i2c_transfer(client->adapter, msg, 1);
> > + }
> > + if (err >= 0) {
> > + *val = 0;
> > + /* High byte comes first */
> > + if (data_length == 1)
> > + *val = data[0];
> > + else if (data_length == 2)
> > + *val = data[1] + (data[0] << 8);
> > + else
> > + *val = data[3] + (data[2] << 8) +
> > + (data[1] << 16) + (data[0] << 24);
> > + return 0;
> > + }
> > + dev_err(&client->dev, "read from offset 0x%x error %d", reg,
> err);
>
> "\n" should be in dev_err.
Done
>
> > + return err;
> > +}
> > +
> > +/* Write a value to a register in ov3640 sensor device.
> > + * @client: i2c driver client structure.
> > + * @reg: Address of the register to read value from.
> > + * @val: Value to be written to a specific register.
> > + * Returns zero if successful, or non-zero otherwise.
> > + */
> > +static int ov3640_write_reg(struct i2c_client *client, u16 reg, u8 val)
> > +{
> > + int err = 0;
> > + struct i2c_msg msg[1];
> > + unsigned char data[3];
> > + int retries = 0;
> > +
> > + if (!client->adapter)
> > + return -ENODEV;
> > +retry:
> > + msg->addr = client->addr;
> > + msg->flags = I2C_M_WR;
> > + msg->len = 3;
> > + msg->buf = data;
> > +
> > + /* high byte goes out first */
> > + data[0] = (u8) (reg >> 8);
> > + data[1] = (u8) (reg & 0xff);
> > + data[2] = val;
> > +
> > + err = i2c_transfer(client->adapter, msg, 1);
> > + udelay(50);
> > +
> > + if (err >= 0)
>
> Well, probably all checks of returned values after i2c_transfer should
> be reformatted in right way.
I'll redesign this...
>
>
> > + return 0;
> > +
> > + if (retries <= 5) {
> > + dev_dbg(&client->dev, "Retrying I2C... %d", retries);
>
> "\n"
Done.
> > + /* FIXME: QXGA framerate setting forced to 15 FPS */
> > + if (isize == QXGA) {
> > + err = ov3640_write_reg(client, OV3640_PLL_1, 0x32);
> > + err = ov3640_write_reg(client, OV3640_PLL_2, 0x21);
> > + err = ov3640_write_reg(client, OV3640_PLL_3, 0x21);
> > + err = ov3640_write_reg(client, OV3640_CLK, 0x01);
> > + err = ov3640_write_reg(client, 0x304c, 0x81);
>
> I see no checking of returned values. For example, if first function
> failed, rest functions will keep going.
Agreed.. I think I'll definitely redesign this to avoid this kind of trouble.
> > +
> > + /* Common registers */
> > + err = ov3640_write_regs(client, ov3640_common[isize]);
> > +
> > + /* Configure image size and pixel format */
> > +
RE: [PATCH 5/5] LDP: Add support for built-in camera
Hi,
> -Original Message-
> From: stanley.miao [mailto:stanley.m...@windriver.com]
> > +static struct i2c_board_info __initdata ldp_i2c_boardinfo_2[] = {
> > +#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
> > + {
> > + I2C_BOARD_INFO("ov3640", OV3640_I2C_ADDR),
> > + .platform_data = &ldp_ov3640_platform_data,
> > + },
> > +#endif
> > +};
> >
> This new added i2c_board_info was not registered.
> After I added this line,
>
> omap_register_i2c_bus(2, 400, ldp_i2c_boardinfo_2,
> ARRAY_SIZE(ldp_i2c_boardinfo_2));
>
> the sensor was found. but the test still failed. A lot of error came out
> when I run my test program.
>
> <3>CSI2: ComplexIO Error IRQ 80
> CSI2: ComplexIO Error IRQ 80
> <3>CSI2: ComplexIO Error IRQ c2
> CSI2: ComplexIO Error IRQ c2
> <3>CSI2: ComplexIO Error IRQ c2
> CSI2: ComplexIO Error IRQ c2
> <3>CSI2: ComplexIO Error IRQ c6
> CSI2: ComplexIO Error IRQ c6
> <3>CSI2: ECC correction failed
> CSI2: ECC correction failed
> <3>CSI2: ComplexIO Error IRQ 6
> CSI2: ComplexIO Error IRQ 6
> <3>CSI2: ComplexIO Error IRQ 6
> CSI2: ComplexIO Error IRQ 6
> <3>CSI2: ComplexIO Error IRQ 6
> CSI2: ComplexIO Error IRQ 6
> <3>CSI2: ComplexIO Error IRQ 6
> CSI2: ComplexIO Error IRQ 6
>
Oops, my mistake. Missed to add that struct there... Fixed now.
About the CSI2 errors you're receiving... Which version of LDP are you using?
Which Silicon revision has (ES2.1 or ES3.0)?
Regards,
Sergio
>
> Stanley.
--
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: OMAP3 ISP and camera drivers (update)
> -Original Message- > From: Sakari Ailus [mailto:sakari.ai...@maxwell.research.nokia.com] > Sent: Friday, March 06, 2009 9:32 AM > To: linux-media@vger.kernel.org > Cc: Aguirre Rodriguez, Sergio Alberto; DongSoo Kim; Hiremath, Vaibhav; > Toivonen Tuukka Olli Artturi; Koskipää Antti Jussi Petteri; Cohen David > Abraham; Alexey Klimov > Subject: OMAP3 ISP and camera drivers (update) > > Hi, > > I've updated the patchset in Gitorious. > > http://www.gitorious.org/projects/omap3camera> > > Changes include > > - Power management support. ISP suspend/resume should work now. > > - Reindented and cleaned up everything. There are still some warnings > from checkpatch.pl from the CSI2 code. > > - Fix for crash in device registration, posted to list already. (Thanks, > Vaibhav, Alexey!) > > - LSC errors should be handled properly now. Hi Sakari, Doing a pull like you suggested in past release: $ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \ iommu omap3camera base Brings the same code than before... I see that omap3isp branch is updated on gitorious, but trying to pull that branch gives merge errors. Regards, Sergio -- 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/5] MT9P012: Add driver
Hi Felipe,
Sorry for the delay replying this...
Find my responses below.
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
> Sent: Wednesday, March 04, 2009 5:31 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus;
> Toivonen Tuukka.O (Nokia-D/Oulu); Doyu Hiroshi (Nokia-D/Helsinki);
> DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav;
> Lakhani, Amish; Menon, Nishanth
> Subject: Re: [PATCH 1/5] MT9P012: Add driver
>
> Hi,
>
> not looking at v4l2 part since it's not my area...
>
>
> On Tue, Mar 03, 2009 at 09:44:14PM +0100, ext Aguirre Rodriguez, Sergio
> Alberto wrote:
> > +#define SENSOR_DETECTED1
> > +#define SENSOR_NOT_DETECTED0
>
> these two should be unneeded...
Agreed, got rid of them...
>
> > +
> > +/**
> > + * struct mt9p012_reg - mt9p012 register format
> > + * @length: length of the register
> > + * @reg: 16-bit offset to register
> > + * @val: 8/16/32-bit register value
> > + *
> > + * Define a structure for MT9P012 register initialization values
> > + */
> > +struct mt9p012_reg {
> > + u16 length;
> > + u16 reg;
> > + u32 val;
> > +};
> > +
> > +enum image_size {
> > + BIN4XSCALE,
> > + BIN4X,
> > + BIN2X,
> > + THREE_MP,
> > + FIVE_MP
>
> you probably wanna prefix these with MT9P012_ to avoid namespace
> conflicts.
Done.
>
> > +};
> > +
> > +enum pixel_format {
> > + RAWBAYER10
> > +};
> > +
> > +#define NUM_IMAGE_SIZES5
> > +#define NUM_PIXEL_FORMATS 1
> > +#define NUM_FPS2 /* 2 ranges */
> > +#define FPS_LOW_RANGE 0
> > +#define FPS_HIGH_RANGE 1
> > +
> > +/**
> > + * struct capture_size - image capture size information
> > + * @width: image width in pixels
> > + * @height: image height in pixels
> > + */
> > +struct capture_size {
> > + unsigned long width;
> > + unsigned long height;
> > +};
> > +
> > +/**
> > + * struct mt9p012_pll_settings - struct for storage of sensor pll
> values
> > + * @vt_pix_clk_div: vertical pixel clock divider
> > + * @vt_sys_clk_div: veritcal system clock divider
> > + * @pre_pll_div: pre pll divider
> > + * @fine_int_tm: fine resolution interval time
> > + * @frame_lines: number of lines in frame
> > + * @line_len: number of pixels in line
> > + * @min_pll: minimum pll multiplier
> > + * @max_pll: maximum pll multiplier
> > + */
> > +struct mt9p012_pll_settings {
> > + u16 vt_pix_clk_div;
> > + u16 vt_sys_clk_div;
> > + u16 pre_pll_div;
> > +
> > + u16 fine_int_tm;
> > + u16 frame_lines;
> > + u16 line_len;
> > +
> > + u16 min_pll;
> > + u16 max_pll;
> > +};
> > +
> > +/*
> > + * Array of image sizes supported by MT9P012. These must be ordered
> from
> > + * smallest image size to largest.
> > + */
> > +const static struct capture_size mt9p012_sizes[] = {
> > + { 216, 162 }, /* 4X BINNING+SCALING */
> > + { 648, 486 }, /* 4X BINNING */
> > + { 1296, 972 }, /* 2X BINNING */
> > + { 2048, 1536}, /* 3 MP */
> > + { 2592, 1944}, /* 5 MP */
> > +};
> > +
> > +/* PLL settings for MT9P012 */
> > +enum mt9p012_pll_type {
> > + PLL_5MP = 0,
> > + PLL_3MP,
> > + PLL_1296_15FPS,
> > + PLL_1296_30FPS,
> > + PLL_648_15FPS,
> > + PLL_648_30FPS,
> > + PLL_216_15FPS,
> > + PLL_216_30FPS
> > +};
>
> missing tabs, fix identation.
Done.
>
> > +
> > +/* Debug functions */
> > +static int debug;
> > +module_param(debug, bool, 0644);
> > +MODULE_PARM_DESC(debug, "Debug level (0-1)");
>
> if it's a bool it's not debug level, it's debug on/off switch :-p
>
> > +static struct mt9p012_sensor mt9p012;
> > +static struct i2c_driver mt9p012sensor_i2c_driver;
>
> unneeded.
You're right. Done.
>
> > +static unsigned long xclk_current = MT9P012_XCLK_NOM_1;
>
> why ??
Hmm, well. This is the xclk default value we use.
The driver basically uses 2 XCLK values to cover all the supported
framerates/framesizes.
Anyways, I've added a xclk_current field as part of struct mt9p012_sensor
instead. Removed this static var.
>
> > +stati
RE: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
> -Original Message- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: Tuesday, March 03, 2009 5:56 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; > Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley; > Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth > Subject: Re: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera > > On Tuesday 03 March 2009, Aguirre Rodriguez, Sergio Alberto wrote: > > > > > This patch series depends on the following patches: > > > > > > - "Add TWL4030 registers", posted by Tuukka Toivonen on March 2nd. > > > > http://marc.info/?l=linux-omap&m=123597520231668&w=2 > > I'd much rather see these drivers just use the regulator > framework to switch any sensor power rails on/off. Hi, Sounds interesting. Is there any documentation on how to use this? > > As with the V4L2 interface changes, the twl4030 regulator > support will be in mainline for the 2.6.30 kernels. > > - Dave > > -- 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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
> -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Wednesday, March 04, 2009 4:45 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: sakari.ai...@maxwell.research.nokia.com; DongSoo(Nathaniel) Kim; > Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia-D/Oulu); linux- > o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org > Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver > > On Wednesday 04 March 2009 22:46:07 Aguirre Rodriguez, Sergio Alberto > wrote: > > > -Original Message- > > > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > > > Sent: Wednesday, March 04, 2009 3:06 PM > > > To: sakari.ai...@maxwell.research.nokia.com > > > Cc: DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O > > > (Nokia- D/Oulu); Aguirre Rodriguez, Sergio Alberto; > > > linux-o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org > > > Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver > > > > > > On Wednesday 04 March 2009 20:22:04 Sakari Ailus wrote: > > > > Hans Verkuil wrote: > > > > > On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: > > > > >> Thank you for your kind explanation Hans. > > > > >> > > > > >> Problem is omap3 camera subsystem is making device node for every > > > > >> int device attached to it. > > > > > > > > > > That's wrong. Multiple devices should only be created if they can > > > > > all be used at the same time. Otherwise there should be just one > > > > > device that uses S_INPUT et al to select between the inputs. > > > > > > > > There might be situations where multiple device nodes would be > > > > beneficial even if they cannot be used simultaneously in all cases. > > > > > > > > Currently the omap34xxcam camera driver creates one device per > > > > camera. A camera in this case contains an isp (or camera controller), > > > > image sensor, lens and flash. The properties like maximum frame rate > > > > or resolution of a camera are usually (almost) completely defined by > > > > those of the sensor, lens and flash. This affects also cropping > > > > capabilities. > > > > > > > > Several programs can access video devices simultaneously. What > > > > happens if another program switches the input when the first one > > > > doesn't expect it? The original user won't notice the change, > instead > > > > of getting -EBUSY when trying to open the other video device. > > > > > > It is actually quite common to be able to switch inputs using one > > > program (e.g. v4l2-ctl) while another program also has the video node > > > open. This will typically be used for debugging or experimenting. > > > Depending on the hardware, switching inputs while capturing is in > > > progress may or may not be > > > allowed (the driver might just return -EBUSY in that case). > > > > > > In addition the application can also call VIDIOC_S_PRIORITY to protect > > > it against outside interference, provided the driver supports this > > > ioctl. > > > > > > As an aside: many applications don't use VIDIOC_S_PRIORITY since > > > whether a driver implements it is hit-and-miss. As part of the new > v4l2 > > > framework I have a struct v4l2_fh planned that will integrate support > > > of this ioctl in the framework, thus making it generic for all drivers. > > > But this won't be available any time soon. > > > > As what I understand, we have 2 possible situations for multiple opens > > here: > > > > Situation 1 > > - Instance1: Select sensor 1, and Do queue/dequeue of buffers. > > - Instance2: If sensor 1 is currently selected, Begin loop requesting > > internally collected OMAP3ISP statistics (with V4L2 private based > IOCTLs) > > for performing user-side Auto-exposure, Auto White Balance, Auto Focus > > algorithms. And Adjust gains (with S_CTRL) accordingly on sensor as a > > result. > > Question: if you have multiple sensors, and sensor 1 is selected, can you > still get statistics from sensor 2? Or is all this still limited to the > selected sensor? Just want to make sure I understand it all. Everytime a RAW10 Bayer formatted frame is received on the OMAP3ISP, statistics are being generated and when done, stored in buffers allocated internally on the driver (last 5 frames only), marking every stats buffer with the f
RE: [PATCH 5/5] LDP: Add support for built-in camera
From: Curran, Dominic
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
> > Sent: Tuesday, March 03, 2009 2:44 PM
> > To: linux-media@vger.kernel.org; linux-o...@vger.kernel.org
> > Cc: Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel)
> Kim;
> > MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon,
> Nishanth
> > Subject: [PATCH 5/5] LDP: Add support for built-in camera
> >
> > This patch adds support for the LDP builtin camera sensor:
> > - Primary sensor (/dev/video4): OV3640 (CSI2).
> >
> > It introduces also a new file for storing all camera sensors board
> > specific related functions, like other platforms do (N800 for example).
> >
> > Signed-off-by: Sergio Aguirre
> > ---
> > arch/arm/mach-omap2/Makefile|3 +-
> > arch/arm/mach-omap2/board-ldp-camera.c | 203
> > +++
> > arch/arm/mach-omap2/board-ldp.c | 17 +++
> > arch/arm/plat-omap/include/mach/board-ldp.h |1 +
> > 4 files changed, 223 insertions(+), 1 deletions(-)
> > create mode 100644 arch/arm/mach-omap2/board-ldp-camera.c
> >
> > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > index ee6..097bc58 100644
> > --- a/arch/arm/mach-omap2/Makefile
> > +++ b/arch/arm/mach-omap2/Makefile
> > @@ -63,7 +63,8 @@ obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-
> > omap3beagle.o \
> >mmc-twl4030.o \
> >twl4030-generic-scripts.o
> > obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
> > - mmc-twl4030.o
> > + mmc-twl4030.o \
> > + board-ldp-camera.o
> > obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
> >board-apollon-mmc.o \
> >board-apollon-keys.o
> > diff --git a/arch/arm/mach-omap2/board-ldp-camera.c b/arch/arm/mach-
> > omap2/board-ldp-camera.c
> > new file mode 100644
> > index 000..0db085c
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/board-ldp-camera.c
> > @@ -0,0 +1,203 @@
> > +/*
> > + * linux/arch/arm/mach-omap2/board-ldp0-camera.c
>
> Minor typo, should be:
> linux/arch/arm/mach-omap2/board-ldp-camera.c
Oops, fixed.
> > +
> > +static struct omap34xxcam_sensor_config ov3640_hwc = {
> > + .sensor_isp = 0,
> > + .xclk = OMAP34XXCAM_XCLK_B,
> > + .capture_mem = 2592 * 1944 * 2 * 2,
>
> Should this be 2048 * 1536 * 2 * 2 ?
Yep, You're right. Fixed.
I'll repost after I fix Felipe Balbi's comments on MT sensor.
Thanks for your time!
Regards,
Sergio
--
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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
> -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Wednesday, March 04, 2009 3:06 PM > To: sakari.ai...@maxwell.research.nokia.com > Cc: DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia- > D/Oulu); Aguirre Rodriguez, Sergio Alberto; linux-o...@vger.kernel.org; > Nagalla, Hari; linux-media@vger.kernel.org > Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver > > On Wednesday 04 March 2009 20:22:04 Sakari Ailus wrote: > > Hans Verkuil wrote: > > > On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: > > >> Thank you for your kind explanation Hans. > > >> > > >> Problem is omap3 camera subsystem is making device node for every int > > >> device attached to it. > > > > > > That's wrong. Multiple devices should only be created if they can all > > > be used at the same time. Otherwise there should be just one device > > > that uses S_INPUT et al to select between the inputs. > > > > There might be situations where multiple device nodes would be > > beneficial even if they cannot be used simultaneously in all cases. > > > > Currently the omap34xxcam camera driver creates one device per camera. A > > camera in this case contains an isp (or camera controller), image > > sensor, lens and flash. The properties like maximum frame rate or > > resolution of a camera are usually (almost) completely defined by those > > of the sensor, lens and flash. This affects also cropping capabilities. > > > > Several programs can access video devices simultaneously. What happens > > if another program switches the input when the first one doesn't expect > > it? The original user won't notice the change, instead of getting -EBUSY > > when trying to open the other video device. > > It is actually quite common to be able to switch inputs using one program > (e.g. v4l2-ctl) while another program also has the video node open. This > will typically be used for debugging or experimenting. Depending on the > hardware, switching inputs while capturing is in progress may or may not > be > allowed (the driver might just return -EBUSY in that case). > > In addition the application can also call VIDIOC_S_PRIORITY to protect it > against outside interference, provided the driver supports this ioctl. > > As an aside: many applications don't use VIDIOC_S_PRIORITY since whether a > driver implements it is hit-and-miss. As part of the new v4l2 framework I > have a struct v4l2_fh planned that will integrate support of this ioctl in > the framework, thus making it generic for all drivers. But this won't be > available any time soon. As what I understand, we have 2 possible situations for multiple opens here: Situation 1 - Instance1: Select sensor 1, and Do queue/dequeue of buffers. - Instance2: If sensor 1 is currently selected, Begin loop requesting internally collected OMAP3ISP statistics (with V4L2 private based IOCTLs) for performing user-side Auto-exposure, Auto White Balance, Auto Focus algorithms. And Adjust gains (with S_CTRL) accordingly on sensor as a result. Situation 2 - Instance1: Select sensor1 as input. Begin streaming. - Instance2: Select sensor2 as input. Attempt to begin streaming. So, if I understood right, on Situation 2, if you attempt to do a S_INPUT to sensor2 while capturing from sensor1, it should return a -EBUSY, right? I mean, the app should consciously make sure the input (sensor) is the correct one before performing any adjustments. I think our current approach avoids the user to be constantly checking if the input is still the same before updating gains... I'm not clear if this single-node idea is really helping the user to have a simpler usage in Situation 1, which I feel will become pretty common on this driver... > > > In short, it's been just more clear to have one device per camera. There > > may be other reasons but these come to mind this time. > > I very much disagree here. Having multiple devices ONLY makes sense if you > can capture from them in parallel. This situation is really just a > straightforward case of multiple inputs you have to choose from. > > > > BTW, do I understand correctly that e.g. lens drivers also get their > > > own /dev/videoX node? Please tell me I'm mistaken! Since that would be > > > so very wrong. > > > > Yes, you're mistaken this time. :) > > > > The contents of a video devices are defined in platform data. > > > > > I hope that the conversion to v4l2_subdev will take place soon. You > are > > > basically stuck in a technological dead-end :-( > > > > Making thin
RE: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
> From: stanley.miao [mailto:stanley.m...@windriver.com] > > Aguirre Rodriguez, Sergio Alberto wrote: > > > This patch series depends on the following patches: > > > > > > - "Add TWL4030 registers", posted by Tuukka Toivonen on March 2nd. > > > - "OMAP3 ISP and camera drivers" patch series, posted by Sakari Ailus > > on > > >March 3rd. (Please follow his instructions to pull from > gitorious.org > > server) > > > > > > This has been tested with: > > > - SDP3430-VG5.0.1 with OMAP3430-ES3.1 daughter board upgrade. > > > - Camkit V3.0.1 with MT9P012 and OV3640 sensors > > > - LDP with OV3640 sensor > > > > > > Sergio Aguirre (5): > > > MT9P012: Add driver > > > DW9710: Add driver > > > OV3640: Add driver > > > > > Hi, Sergio, > > > > You forgot to send the 3rd patch, "OV3640: Add driver". > > Hmm, weird... I'm sure I have sent the 5 patches to both linux-omap and > linux-media MLs... But, according to http://patchwork.kernel.org/ linux- > omap didn't receive that patch you're telling me... > > Anyways, resending that last patch to linux-omap only. > > Thanks for the interest. Stanley, I don't know why this patch is not making it... I resent it twice now, and it doesn't arrive to the list... Tony, Is this patch "OV3640: Add driver" being held on a mail filter somewhere? Regards, Sergio > > > > > Stanley. > > > > > OMAP3430SDP: Add support for Camera Kit v3 > > > LDP: Add support for built-in camera > > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
> -Original Message- > From: stanley.miao [mailto:stanley.m...@windriver.com] > Sent: Tuesday, March 03, 2009 11:43 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; > Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley; > Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth > Subject: Re: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera > > Aguirre Rodriguez, Sergio Alberto wrote: > > This patch series depends on the following patches: > > > > - "Add TWL4030 registers", posted by Tuukka Toivonen on March 2nd. > > - "OMAP3 ISP and camera drivers" patch series, posted by Sakari Ailus > on > >March 3rd. (Please follow his instructions to pull from gitorious.org > server) > > > > This has been tested with: > > - SDP3430-VG5.0.1 with OMAP3430-ES3.1 daughter board upgrade. > > - Camkit V3.0.1 with MT9P012 and OV3640 sensors > > - LDP with OV3640 sensor > > > > Sergio Aguirre (5): > > MT9P012: Add driver > > DW9710: Add driver > > OV3640: Add driver > > > Hi, Sergio, > > You forgot to send the 3rd patch, "OV3640: Add driver". Hmm, weird... I'm sure I have sent the 5 patches to both linux-omap and linux-media MLs... But, according to http://patchwork.kernel.org/ linux-omap didn't receive that patch you're telling me... Anyways, resending that last patch to linux-omap only. Thanks for the interest. > > Stanley. > > > OMAP3430SDP: Add support for Camera Kit v3 > > LDP: Add support for built-in camera > > > -- 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 0/5] Sensor drivers for OMAP3430SDP and LDP camera
> -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Tuesday, March 03, 2009 4:47 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; > Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley; > Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth > Subject: Re: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera > > On Tuesday 03 March 2009 21:44:12 Aguirre Rodriguez, Sergio Alberto wrote: > > This patch series depends on the following patches: > > > > - "Add TWL4030 registers", posted by Tuukka Toivonen on March 2nd. > > - "OMAP3 ISP and camera drivers" patch series, posted by Sakari Ailus > on > >March 3rd. (Please follow his instructions to pull from gitorious.org > > server) > > Sergio, Sakari, > > I'm feeling quite uncomfortable about this series with regards to the use > of > the v4l2-int API instead of v4l2_subdev. I know that it is on the TODO > list, but every driver that is merged that uses v4l2-int will later mean > extra work. > > I and others have been working very hard to get the existing ioctl-based > i2c > modules converted in time for the 2.6.30 merge window. It looks like I'll > be able to have it done in time (fingers crossed :-) ). So it is rather > sad > to see new modules that do not yet use it. > > Right now the v4l2_device and v4l2_subdev framework is pretty basic and so > the amount of work to do the conversion is still limited, but once I've > finished my initial conversion I'll be adding lots more features, do > cleanups, and generally improve the framework substantially. Any existing > modules that use v4l2_device and v4l2_subdev will be updated by me. But > I'm > not going to do that for modules using v4l2-int, that will be the > responsibility of the module's author when he converts it to v4l2_subdev. > So the longer you wait, the more work that will be. > > I *strongly* recommend that the conversion to the new framework is done > first. I know it might delay inclusion of some drivers, but my expectation > based on all the other conversions I've done until now is that it will > actually simplify the drivers. > > My experiences with it have been uniformly positive and it should be > possible to use it as well with the ISP module or other logical > sub-devices. There are lots of interesting possibilities there that you do > not have with v4l2-int. Hans, I agree that we need to head for migration asap, but we hadn't had a chance to begin on this as some other higher priority issues were (and some still are) showing up. Anyways, can you please point me to the latest version of the v4l2_subdev documentation so we can begin properly working on this? Regards, Sergio -- 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 0/5] Sensor drivers for OMAP3430SDP and LDP camera
Adding links for easier reference to required patches: > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto > Sent: Tuesday, March 03, 2009 2:44 PM > To: linux-media@vger.kernel.org; linux-o...@vger.kernel.org > Cc: Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; > MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, > Nishanth > Subject: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera > > This patch series depends on the following patches: > > - "Add TWL4030 registers", posted by Tuukka Toivonen on March 2nd. http://marc.info/?l=linux-omap&m=123597520231668&w=2 > - "OMAP3 ISP and camera drivers" patch series, posted by Sakari Ailus on >March 3rd. (Please follow his instructions to pull from gitorious.org > server) > http://marc.info/?l=linux-omap&m=123607483202215&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] LDP: Add support for built-in camera
This patch adds support for the LDP builtin camera sensor:
- Primary sensor (/dev/video4): OV3640 (CSI2).
It introduces also a new file for storing all camera sensors board
specific related functions, like other platforms do (N800 for example).
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-ldp-camera.c | 203 +++
arch/arm/mach-omap2/board-ldp.c | 17 +++
arch/arm/plat-omap/include/mach/board-ldp.h |1 +
4 files changed, 223 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-ldp-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ee6..097bc58 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,7 +63,8 @@ obj-$(CONFIG_MACH_OMAP3_BEAGLE) +=
board-omap3beagle.o \
mmc-twl4030.o \
twl4030-generic-scripts.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
- mmc-twl4030.o
+ mmc-twl4030.o \
+ board-ldp-camera.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
board-apollon-mmc.o \
board-apollon-keys.o
diff --git a/arch/arm/mach-omap2/board-ldp-camera.c
b/arch/arm/mach-omap2/board-ldp-camera.c
new file mode 100644
index 000..0db085c
--- /dev/null
+++ b/arch/arm/mach-omap2/board-ldp-camera.c
@@ -0,0 +1,203 @@
+/*
+ * linux/arch/arm/mach-omap2/board-ldp0-camera.c
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Sergio Aguirre
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_TWL4030_CORE
+
+#include
+#include
+#include
+
+#include
+
+#include
+
+#include
+
+static int cam_inited;
+#include
+#include <../drivers/media/video/omap34xxcam.h>
+#include <../drivers/media/video/isp/ispreg.h>
+
+#define LDPCAM_USE_XCLKB 1
+
+#define VAUX_1_8_V 0x05
+#define VAUX_DEV_GRP_P10x20
+#define VAUX_DEV_GRP_NONE 0x00
+
+#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
+#define OV3640_RESET_GPIO 98
+#define OV3640_STANDBY_GPIO7
+#include
+#include <../drivers/media/video/isp/ispcsi2.h>
+static struct omap34xxcam_hw_config *hwc;
+#define OV3640_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_DATA0_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_DATA1_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_CLOCK_LANE 1/* Clock lane position: 1 */
+#define OV3640_CSI2_DATA0_LANE 2/* Data0 lane position: 2 */
+#define OV3640_CSI2_DATA1_LANE 3/* Data1 lane position: 3 */
+#define OV3640_CSI2_PHY_THS_TERM 4
+#define OV3640_CSI2_PHY_THS_SETTLE 14
+#define OV3640_CSI2_PHY_TCLK_TERM 0
+#define OV3640_CSI2_PHY_TCLK_MISS 1
+#define OV3640_CSI2_PHY_TCLK_SETTLE14
+
+static struct omap34xxcam_sensor_config ov3640_hwc = {
+ .sensor_isp = 0,
+ .xclk = OMAP34XXCAM_XCLK_B,
+ .capture_mem = 2592 * 1944 * 2 * 2,
+ .ival_default = { 1, 15 },
+};
+
+static struct isp_interface_config ov3640_if_config = {
+ .ccdc_par_ser = ISP_CSIA,
+ .dataline_shift = 0x0,
+ .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
+ .strobe = 0x0,
+ .prestrobe = 0x0,
+ .shutter = 0x0,
+ .prev_sph = 2,
+ .prev_slv = 1,
+ .wenlog = ISPCCDC_CFG_WENLOG_AND,
+ .wait_hs_vs = 2,
+ .u.csi.crc = 0x0,
+ .u.csi.mode = 0x0,
+ .u.csi.edge = 0x0,
+ .u.csi.signalling = 0x0,
+ .u.csi.strobe_clock_inv = 0x0,
+ .u.csi.vs_edge = 0x0,
+ .u.csi.channel = 0x1,
+ .u.csi.vpclk = 0x1,
+ .u.csi.data_start = 0x0,
+ .u.csi.data_size = 0x0,
+ .u.csi.format = V4L2_PIX_FMT_SGRBG10,
+};
+
+static int ov3640_sensor_set_prv_data(void *priv)
+{
+ hwc = priv;
+ hwc->u.sensor.xclk = ov3640_hwc.xclk;
+ hwc->u.sensor.sensor_isp = ov3640_hwc.sensor_isp;
+ hwc->dev_index = 1;
+ hwc->dev_minor = 4;
+ hwc->dev_type = OMAP34XXCAM_SLAVE_SENSOR;
+ return 0;
+}
+
+static int ov3640_sensor_power_set(enum v4l2_power power)
+{
+ struct isp_csi2_lanes_cfg lanecfg;
+ struct isp_csi2_phy_cfg phyconfig;
+ static enum v4l2_power previous_power = V4L2_POWER_OFF;
+
+ if (!cam_inited) {
+ printk(KERN_ERR "OV3640: Unable to control board GPIOs!\n");
+ return -EFAULT;
+ }
+
+ switch (power) {
+ case V4L2_POWER_ON:
+
[PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
This patch adds support for sensors contained in Camkit v3,
which has:
- Primary sensor (/dev/video0): MT9P012 (Parallel) with
DW9710 lens driver.
- Secondary sensor (/dev/video4): OV3640 (CSI2).
It introduces also a new file for storing all camera sensors board
specific related functions, like other platforms do (N800 for example).
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-3430sdp-camera.c | 490 +++
arch/arm/mach-omap2/board-3430sdp.c | 42 ++-
arch/arm/plat-omap/include/mach/board-3430sdp.h |1 +
4 files changed, 534 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-3430sdp-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 33b5aa8..ee6 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -53,7 +53,8 @@ obj-$(CONFIG_MACH_OMAP2EVM) += board-omap2evm.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
mmc-twl4030.o \
- board-3430sdp-flash.o
+ board-3430sdp-flash.o \
+ board-3430sdp-camera.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
mmc-twl4030.o \
board-omap3evm-flash.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp-camera.c
b/arch/arm/mach-omap2/board-3430sdp-camera.c
new file mode 100644
index 000..661d5ed
--- /dev/null
+++ b/arch/arm/mach-omap2/board-3430sdp-camera.c
@@ -0,0 +1,490 @@
+/*
+ * linux/arch/arm/mach-omap2/board-3430sdp.c
+ *
+ * Copyright (C) 2007 Texas Instruments
+ *
+ * Modified from mach-omap2/board-generic.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * 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.
+ */
+
+#ifdef CONFIG_TWL4030_CORE
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+
+#include
+
+static int cam_inited;
+#include
+#include <../drivers/media/video/omap34xxcam.h>
+#include <../drivers/media/video/isp/ispreg.h>
+#define DEBUG_BASE 0x0800
+
+#define REG_SDP3430_FPGA_GPIO_2 (0x50)
+#define FPGA_SPR_GPIO1_3v3 (0x1 << 14)
+#define FPGA_GPIO6_DIR_CTRL(0x1 << 6)
+
+#define VAUX_2_8_V 0x09
+#define VAUX_1_8_V 0x05
+#define VAUX_DEV_GRP_P10x20
+#define VAUX_DEV_GRP_NONE 0x00
+
+#define CAMKITV3_USE_XCLKA 0
+#define CAMKITV3_USE_XCLKB 1
+
+#define CAMKITV3_RESET_GPIO98
+/* Sensor specific GPIO signals */
+#define MT9P012_STANDBY_GPIO 58
+#define OV3640_STANDBY_GPIO55
+static void __iomem *fpga_map_addr;
+
+#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
+#include
+static enum v4l2_power mt9p012_previous_power = V4L2_POWER_OFF;
+#endif
+
+#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
+#include
+#include <../drivers/media/video/isp/ispcsi2.h>
+static struct omap34xxcam_hw_config *hwc;
+#define OV3640_CSI2_CLOCK_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_DATA0_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_DATA1_POLARITY 0 /* +/- pin order */
+#define OV3640_CSI2_CLOCK_LANE 1/* Clock lane position: 1 */
+#define OV3640_CSI2_DATA0_LANE 2/* Data0 lane position: 2 */
+#define OV3640_CSI2_DATA1_LANE 3/* Data1 lane position: 3 */
+#define OV3640_CSI2_PHY_THS_TERM 4
+#define OV3640_CSI2_PHY_THS_SETTLE 14
+#define OV3640_CSI2_PHY_TCLK_TERM 0
+#define OV3640_CSI2_PHY_TCLK_MISS 1
+#define OV3640_CSI2_PHY_TCLK_SETTLE14
+#endif
+
+#ifdef CONFIG_VIDEO_DW9710
+#include
+#endif
+
+static void __iomem *fpga_map_addr;
+
+static void enable_fpga_vio_1v8(u8 enable)
+{
+ u16 reg_val;
+
+ fpga_map_addr = ioremap(DEBUG_BASE, 4096);
+ reg_val = readw(fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+
+ /* Ensure that the SPR_GPIO1_3v3 is 0 - powered off.. 1 is on */
+ if (reg_val & FPGA_SPR_GPIO1_3v3) {
+ reg_val |= FPGA_SPR_GPIO1_3v3;
+ reg_val |= FPGA_GPIO6_DIR_CTRL; /* output mode */
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ /* give a few milli sec to settle down
+* Let the sensor also settle down.. if required..
+*/
+ if (enable)
+ mdelay(10);
+ }
+
+ if (enable) {
+ reg_val |= FPGA_SPR_GPIO1_3v3 | FPGA_GPIO6_DIR_CTRL;
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ }
+ /*
[PATCH 2/5] DW9710: Add driver
This driver has been currently being tested with
OMAP3430SDP platform, working on top of MT9P012
sensor.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/dw9710.c | 548 +
drivers/media/video/dw9710_priv.h | 57
include/media/dw9710.h| 35 +++
5 files changed, 649 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/dw9710.c
create mode 100644 drivers/media/video/dw9710_priv.h
create mode 100644 include/media/dw9710.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 05e9fa1..225d9cf 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -313,6 +313,14 @@ config VIDEO_MT9P012
MT9P012 camera. It is currently working with the TI OMAP3
camera controller.
+config VIDEO_DW9710
+ tristate "Lens driver for DW9710"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 lens driver for the Dongwoon
+ DW9710 coil. It is currently working with the TI OMAP3
+ camera controller and micron MT9P012 sensor.
+
config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L1 && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c445099..52a34d9 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_VIDEO_OMAP3) += omap34xxcam.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_MT9P012) += mt9p012.o
+obj-$(CONFIG_VIDEO_DW9710) += dw9710.o
obj-$(CONFIG_USB_DABUSB)+= dabusb.o
obj-$(CONFIG_USB_OV511) += ov511.o
diff --git a/drivers/media/video/dw9710.c b/drivers/media/video/dw9710.c
new file mode 100644
index 000..362cb0d
--- /dev/null
+++ b/drivers/media/video/dw9710.c
@@ -0,0 +1,548 @@
+/*
+ * drivers/media/video/dw9710.c
+ *
+ * DW9710 Coil Motor (LENS) driver
+ *
+ * Copyright (C) 2008 Texas Instruments.
+ *
+ * Contributors:
+ * Troy Laramy
+ * Mohit Jalori
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include "dw9710_priv.h"
+
+static struct dw9710_device dw9710 = {
+ .state = DW9710_LENS_NOT_DETECTED,
+ .current_lens_posn = DW9710_DEF_LENS_POSN,
+};
+
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+ int current_value;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_FOCUS_ABSOLUTE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Focus, Absolute",
+ .minimum = 0,
+ .maximum = DW9710_MAX_FOCUS_POS,
+ .step = DW9710_LENS_POSN_STEP,
+ .default_value = DW9710_DEF_LENS_POSN,
+ },
+ .current_value = DW9710_DEF_LENS_POSN,
+ }
+};
+
+/**
+ * find_vctrl - Finds the requested ID in the video control structure array
+ * @id: ID of control to search the video control array for
+ *
+ * Returns the index of the requested ID from the control structure array
+ */
+static int find_vctrl(int id)
+{
+ int i;
+
+ if (id < V4L2_CID_BASE)
+ return -EDOM;
+
+ for (i = (ARRAY_SIZE(video_control) - 1); i >= 0; i--) {
+ if (video_control[i].qc.id == id)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * dw9710_reg_read - Reads a value from a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Pointer to u16 for returning value of register to read.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_read(struct i2c_client *client, u16 *value)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[2];
+
+ if (!client->adapter)
+ return -ENODEV;
+
+ msg->addr = client->addr;
+ msg->flags = I2C_M_RD;
+ msg->len = 2;
+ msg->buf = data;
+
+ data[0] = 0;
+ data[1] = 0;
+
+ err = i2c_transfer(client->adapter, msg, 1);
+
+ if (err >= 0) {
+ err = ((data[0] & 0xFF) << 8) | (data[1]);
+ *value = err;
+ return 0;
+ }
+ return err;
+}
+
+/**
+ * dw9710_reg_write - Writes a value to a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Value of register to write.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_write(struct i2c_client *client, u16 value)
+{
+ int err;
+ struct i2c_msg msg[1];
[RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
This patch series depends on the following patches: - "Add TWL4030 registers", posted by Tuukka Toivonen on March 2nd. - "OMAP3 ISP and camera drivers" patch series, posted by Sakari Ailus on March 3rd. (Please follow his instructions to pull from gitorious.org server) This has been tested with: - SDP3430-VG5.0.1 with OMAP3430-ES3.1 daughter board upgrade. - Camkit V3.0.1 with MT9P012 and OV3640 sensors - LDP with OV3640 sensor Sergio Aguirre (5): MT9P012: Add driver DW9710: Add driver OV3640: Add driver OMAP3430SDP: Add support for Camera Kit v3 LDP: Add support for built-in camera arch/arm/mach-omap2/Makefile|6 +- arch/arm/mach-omap2/board-3430sdp-camera.c | 490 + arch/arm/mach-omap2/board-3430sdp.c | 42 +- arch/arm/mach-omap2/board-ldp-camera.c | 203 +++ arch/arm/mach-omap2/board-ldp.c | 17 + arch/arm/plat-omap/include/mach/board-3430sdp.h |1 + arch/arm/plat-omap/include/mach/board-ldp.h |1 + drivers/media/video/Kconfig | 31 + drivers/media/video/Makefile|3 + drivers/media/video/dw9710.c| 548 ++ drivers/media/video/dw9710_priv.h | 57 + drivers/media/video/mt9p012.c | 1890 +++ drivers/media/video/mt9p012_regs.h | 74 + drivers/media/video/ov3640.c| 2202 +++ drivers/media/video/ov3640_regs.h | 600 ++ include/media/dw9710.h | 35 + include/media/mt9p012.h | 37 + include/media/ov3640.h | 31 + 18 files changed, 6265 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-omap2/board-3430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-ldp-camera.c create mode 100644 drivers/media/video/dw9710.c create mode 100644 drivers/media/video/dw9710_priv.h create mode 100644 drivers/media/video/mt9p012.c create mode 100644 drivers/media/video/mt9p012_regs.h create mode 100644 drivers/media/video/ov3640.c create mode 100644 drivers/media/video/ov3640_regs.h create mode 100644 include/media/dw9710.h create mode 100644 include/media/mt9p012.h create mode 100644 include/media/ov3640.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH 09/14] OMAP: CAM: Add ISP Core
Hi Nate,
> -Original Message-
> From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com]
> Sent: Monday, March 02, 2009 2:10 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-o...@vger.kernel.org; video4linux-l...@redhat.com; Nagalla,
> Hari; Sakari Ailus; Tuukka.O Toivonen; linux-media@vger.kernel.org
> Subject: Re: [REVIEW PATCH 09/14] OMAP: CAM: Add ISP Core
>
> Hello,
>
> reviewing ISP driver, I found that we've got no querymenu support in
> ISP and also omap3 camera interface driver.
Sakari is about to repost our latest progress on this driver, and exactly one
of the changes we did is added this support for querymenu on both camera and
ISP drivers.
>
> +/**
> + * struct vcontrol - Video control structure.
> + * @qc: V4L2 Query control structure.
> + * @current_value: Current value of the control.
> + */
> +static struct vcontrol {
> + struct v4l2_queryctrl qc;
> + int current_value;
> +} video_control[] = {
>
>
>
> + {
> + {
> + .id = V4L2_CID_PRIVATE_ISP_COLOR_FX,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "Color Effects",
> + .minimum = PREV_DEFAULT_COLOR,
> + .maximum = PREV_BW_COLOR,
> + .step = 1,
> + .default_value = PREV_DEFAULT_COLOR,
> + },
> + .current_value = PREV_DEFAULT_COLOR,
> + }
> +};
>
> I think we should make it menu type for this color FX control.
> If that kind of control has no menu information, user has no way to
> figure out what kind of FX supported by device.
> BTW if we make querymenu support in omap3 camera subsystem, we should
> make querymenu support for v4l2 int device also.
> I think I've seen before a patch which intent to use querymenu in v4l2
> int device, but no patch for omap3 ISP and camera interface.
> Can I make a patch and post on linux-omap, linux-media list? of course
> if you don't mind.
> Or...am I digging wrong way? I mean.. querymenu for omap3 camera subsystem.
> Please let me know :)
Please hold a bit, as we expect to repost the driver again this week.
This control is now substituted by V4L2_CID_COLORFX, with seems to be already
accepted for merging into v4l:
http://osdir.com/ml/linux-media/2009-02/msg00593.html
Anyways, thanks for your intended help on this. Expect new patches very soon.
>
> Cheers,
>
> Nate
>
> --
>
> DongSoo(Nathaniel), Kim
> Engineer
> Mobile S/W Platform Lab.
> Telecommunication R&D Centre
> Samsung Electronics CO., LTD.
> e-mail : dongsoo@gmail.com
> dongsoo45@samsung.com
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Missing first 4 frames
> -Original Message- > From: video4linux-list-boun...@redhat.com [mailto:video4linux-list- > boun...@redhat.com] On Behalf Of halli manjunatha > Sent: Wednesday, February 04, 2009 6:37 AM > To: video4linux-l...@redhat.com > Subject: Missing first 4 frames > > Hi , >I am working on omap3 custom board and using the TI's camera > patches > on 2.6.28 kernel and the problem is that first 4 frames are coming 1/4 of > HVGA but i am capturing HVGA images. after 4 frames everything is normal. Hi, (Looping linux-omap ML, and replacing v4l with linux-media ML) I have some questions for you: - The camera sensor you are using, is it: - Interfaced to OMAP through: Parallel, CCP2, or CSI2? - Raw (without internal ISP: Image Signal Processing) or smart (With ISP) - Which pixel format are you requesting? - Which patchset did you use? The ones submitted on: - 12 Jan 2009 or - 12 Dec 2008 - The frames you're getting are stored with a wrong filesize? Or you're getting an incomplete frame? - Can you describe me the steps you take for capturing (if its possible, your V4L2 test app source) Regards, Sergio > > I don't wether it is the right list to say this problem, please guid > me where to look, following is my register dump > > > ###CM_FCLKEN_CAM=0x3 > ###CM_ICLKEN_CAM=0x1 > ###CM_CLKSEL_CAM=0x4 > ###CM_AUTOIDLE_CAM=0x1 > ###CM_CLKEN_PLL[18:16] should be 0x7, = 0x90371037 > ###CM_CLKSEL2_PLL[18:8] should be 0x2D, [6:0] should be 1 = 0x1b00c > ###CTRL_PADCONF_CAM_HS=0x1080108 > ###CTRL_PADCONF_CAM_XCLKA=0x1080108 > ###CTRL_PADCONF_CAM_D1=0x1000100 > ###CTRL_PADCONF_CAM_D3=0x1080100 > ###CTRL_PADCONF_CAM_D5=0x1080108 > ###CTRL_PADCONF_CAM_D7=0x1080108 > ###CTRL_PADCONF_CAM_D9=0x1080108 > ###CTRL_PADCONF_CAM_D11=0x108 > ###ISP_CTRL=0x3bf188 > ###ISP_TCTRL_CTRL=0x9 > ###ISP_SYSCONFIG=0x2000 > ###ISP_SYSSTATUS=0x1 > ###ISP_IRQ0ENABLE=0x9300 > ###ISP_IRQ0STATUS=0x0 > ###CCDC PCR=0x1 > ISP_CTRL =0x3bf188 > ###ISP_CTRL in ccdc =0x3bf188 > ###ISP_IRQ0ENABLE in ccdc =0x9300 > ###ISP_IRQ0STATUS in ccdc =0x0 > ###CCDC SYN_MODE=0x31700 > ###CCDC HORZ_INFO=0x13f > ###CCDC VERT_START=0x0 > ###CCDC VERT_LINES=0x1df > ###CCDC CULLING=0x00ff > ###CCDC HSIZE_OFF=0x280 > ###CCDC SDOFST=0x0 > ###CCDC SDR_ADDR=0x400 > ###CCDC CLAMP=0x10 > ###CCDC COLPTN=0x0 > ###CCDC CFG=0x8000 > ###CCDC VP_OUT=0x0 > ###CCDC_SDR_ADDR= 0x400 > ###CCDC FMTCFG=0x4000 > ###CCDC FMT_HORZ=0x0 > ###CCDC FMT_VERT=0x0 > ###CCDC LSC_CONFIG=0x6600 > ###CCDC LSC_INIT=0x0 > ###CCDC LSC_TABLE BASE=0x0 > ###CCDC LSC TABLE OFFSET=0x0 > > Thanks in advance > -- > Regards > > Hall > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] V4L2: Add COLORFX user control
>From 07396d67b39bf7bcc81440d3e72d253ad6c54f11 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre
Date: Tue, 20 Jan 2009 15:34:43 -0600
Subject: [PATCH v2] V4L2: Add COLORFX user control
This is a common feature on many cameras. the options are:
Default colors,
B & W,
Sepia
Signed-off-by: Sergio Aguirre
---
include/linux/videodev2.h |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4669d7e..89ed395 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -876,8 +876,15 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_BACKLIGHT_COMPENSATION(V4L2_CID_BASE+28)
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
+#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+enum v4l2_colorfx {
+ V4L2_COLORFX_NONE = 0,
+ V4L2_COLORFX_BW = 1,
+ V4L2_COLORFX_SEPIA = 2,
+};
+
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.5.6.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: Color FX User control proposal
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@skynet.be]
> Sent: Monday, January 19, 2009 9:32 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com; Nagalla,
> Hari; Curran, Dominic; Kulkarni, Pallavi; Sakari Ailus; Tuukka.O Toivonen;
> mikko.hurskai...@nokia.com
> Subject: Re: Color FX User control proposal
>
> Hi,
>
> On Tuesday 13 January 2009, Aguirre Rodriguez, Sergio Alberto wrote:
> > Hi,
> >
> > Recently in TI and Nokia, we are working towards having for acceptance
> an
> > OMAP3 camera driver, which uses an on-chip Image Signal Processor that
> has
> > one feature of color effects. We were using a V4L2 private CID for that,
> > but have been suggested that this could be common enough to propose to
> the
> > V4L2 spec aswell for other devices to use.
> >
> > Below patch adds the control to include/linux/videodev2.h file, should
> this
> > be enough? (This patch is taking as a codebase the latest linux-omap
> > kernel, which I believe is v2.6.28 still)
> >
> > Thanks and Regards,
> > Sergio
> >
> > From 022b87f3e7f3c3be141ab271a110948ea9567a69 Mon Sep 17 00:00:00 2001
> > From: Sergio Aguirre
> > Date: Tue, 13 Jan 2009 16:25:31 -0600
> > Subject: [PATCH] V4L2: Add COLORFX user control
> >
> > This is a common feature on many cameras. the options are:
> > Default colors,
> > B & W,
> > Sepia
> >
> > Signed-off-by: Sergio Aguirre
> > ---
> > include/linux/videodev2.h |9 -
> > 1 files changed, 8 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 4669d7e..b02a10d 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -876,8 +876,15 @@ enum v4l2_power_line_frequency {
> > #define V4L2_CID_BACKLIGHT_COMPENSATION(V4L2_CID_BASE+28)
> > #define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
> > #define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
> > +#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
> > +enum v4l2_colorfx {
> > + V4L2_COLORFX_DEFAULT= 0,
>
> If this option disables color effects, shouldn't it be called
> V4L2_COLORFX_NONE instead ?
You're right. Makes more sense, I'll update the patch.
Regards,
Sergio
>
> > + V4L2_COLORFX_BW = 1,
> > + V4L2_COLORFX_SEPIA = 2,
> > +};
> > +
> > /* last CID + 1 */
> > -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31)
> > +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
> >
> > /* MPEG-class control IDs defined by V4L2 */
> > #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG |
> 0x900)
>
> Best 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: Color FX User control proposal
> -Original Message- > From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] > Sent: Wednesday, January 14, 2009 4:06 AM > To: Hans Verkuil > Cc: video4linux-l...@redhat.com; Aguirre Rodriguez, Sergio Alberto; linux- > me...@vger.kernel.org; Curran, Dominic; Sakari Ailus; > mikko.hurskai...@nokia.com; Tuukka.O Toivonen; Nagalla, Hari; Michael > Schimek > Subject: Re: Color FX User control proposal > > On Wed, 14 Jan 2009 08:16:14 +0100 > Hans Verkuil wrote: > > > On Tuesday 13 January 2009 23:36:53 Aguirre Rodriguez, Sergio Alberto > > wrote: > > > Hi, > > > > > > Recently in TI and Nokia, we are working towards having for > > > acceptance an OMAP3 camera driver, which uses an on-chip Image Signal > > > Processor that has one feature of color effects. We were using a V4L2 > > > private CID for that, but have been suggested that this could be > > > common enough to propose to the V4L2 spec aswell for other devices to > > > use. > > > > > > Below patch adds the control to include/linux/videodev2.h file, > > > should this be enough? (This patch is taking as a codebase the latest > > > linux-omap kernel, which I believe is v2.6.28 still) > > Seems good for me. > > > > > > > Thanks and Regards, > > > Sergio > > > > Signed-off-by: Hans Verkuil > > > > Mauro, > > > > Can you merge this patch? Looks good to me. > > For us to apply, We need also a patch updating V4L2 API docbook. Done. Hans has the patch for the new spec (0.25) on hold until the merge of this control is done... Thanks! > > 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: [REVIEW PATCH 04/14] OMAP: CAM: Add ISP user header and register defs
> -Original Message-
> From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
> Sent: Tuesday, January 13, 2009 2:42 PM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; video4linux-
> l...@redhat.com; Sakari Ailus; Tuukka.O Toivonen; Nagalla, Hari
> Subject: Re: [REVIEW PATCH 04/14] OMAP: CAM: Add ISP user header and
> register defs
>
> On Mon, 12 Jan 2009 20:03:15 -0600
> "Aguirre Rodriguez, Sergio Alberto" wrote:
>
> > +/* ISP Private IOCTLs */
> > +#define VIDIOC_PRIVATE_ISP_CCDC_CFG\
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 1, struct
> ispccdc_update_config)
> > +#define VIDIOC_PRIVATE_ISP_PRV_CFG \
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 2, struct ispprv_update_config)
> > +#define VIDIOC_PRIVATE_ISP_AEWB_CFG \
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 4, struct isph3a_aewb_config)
> > +#define VIDIOC_PRIVATE_ISP_AEWB_REQ \
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 5, struct isph3a_aewb_data)
> > +#define VIDIOC_PRIVATE_ISP_HIST_CFG \
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 6, struct isp_hist_config)
> > +#define VIDIOC_PRIVATE_ISP_HIST_REQ \
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 7, struct isp_hist_data)
> > +#define VIDIOC_PRIVATE_ISP_AF_CFG \
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 8, struct af_configuration)
> > +#define VIDIOC_PRIVATE_ISP_AF_REQ \
> > + _IOWR('V', BASE_VIDIOC_PRIVATE + 9, struct isp_af_data)
>
> Are those new ioctl meant to be used by the userspace API? If so, we need
> to
> understand each one, since maybe some of them make some sense to be in the
> public API. Also, a proper documentation should be provided for all of
> those
> ioctls.
Yes, this Private IOCTLs that we added to the driver are currently being used
by some of our customers by their userspace applications that contain algos for
performing Auto Focus, AutoExposure, Auto White Balance, and some other gain
table programming into the driver. A description of each one is shown below:
OMAP3 ISP driver Private IOCTLs explanation
- VIDIOC_PRIVATE_ISP_CCDC_CFG: Configures the OMAP3 ISP CCDC module settings
contained in struct ispccdc_update_config (defined in
arch/arm/plat-omap/include/mach/isp_user.h).
/**
* ispccdc_update_config - Structure for CCDC configuration.
* @update: Specifies which CCDC registers should be updated.
* @flag: Specifies which CCDC functions should be enabled.
* @alawip: Enable/Disable A-Law compression.
* @bclamp: Black clamp control register.
* @blcomp: Black level compensation value for RGrGbB Pixels. 2's complement.
* @fpc: Number of faulty pixels corrected in the frame, address of FPC table.
* @cull: Cull control register.
* @colptn: Color pattern of the sensor.
* @lsc: Pointer to LSC gain table.
*/
struct ispccdc_update_config {
__u16 update;
__u16 flag;
enum alaw_ipwidth alawip;
struct ispccdc_bclamp *bclamp;
struct ispccdc_blcomp *blcomp;
struct ispccdc_fpc *fpc;
struct ispccdc_lsc_config *lsc_cfg;
struct ispccdc_culling *cull;
__u32 colptn;
__u8 *lsc;
};
- VIDIOC_PRIVATE_ISP_PRV_CFG: Configures the OMAP3 ISP Preview module settings
contained in struct ispprv_update_config (defined in
arch/arm/plat-omap/include/mach/isp_user.h).
/**
* struct ispprv_update_config - Structure for Preview Configuration (user).
* @update: Specifies which ISP Preview registers should be updated.
* @flag: Specifies which ISP Preview functions should be enabled.
* @yen: Pointer to luma enhancement table.
* @shading_shift: 3bit value of shift used in shading compensation.
* @prev_hmed: Pointer to structure containing the odd and even distance.
* between the pixels in the image along with the filter threshold.
* @prev_cfa: Pointer to structure containing the CFA interpolation table, CFA.
*format in the image, vertical and horizontal gradient threshold.
* @csup: Pointer to Structure for Chrominance Suppression coefficients.
* @prev_wbal: Pointer to structure for White Balance.
* @prev_blkadj: Pointer to structure for Black Adjustment.
* @rgb2rgb: Pointer to structure for RGB to RGB Blending.
* @prev_csc: Pointer to structure for Color Space Conversion from RGB-YCbYCr.
* @yclimit: Pointer to structure for Y, C Value Limit.
* @prev_dcor: Pointer to structure for defect correction.
* @prev_nf: Pointer to structure for Noise Filter
* @red_gamma: Pointer to red gamma correction table.
* @green_gamma: Pointer to green gamma correction table.
* @blue_gamma: Pointer to blue gamma correction table.
*/
struct ispprv_update_config {
__u16 update;
RE: Color FX User control proposal
> For us to apply, We need also a patch updating V4L2 API docbook.
>
> Cheers,
> Mauro
Hi,
Should below patch to v4l2spec-0.24 be fine?
Regards,
Sergio
v4l2spec: Add colorFX control documentation
This patch adds description for proposed new V4L2_CID_COLORFX user
control.
Signed-off-by: Sergio Aguirre
---
Makefile |1 +
controls.sgml | 11 ++-
videodev2.h |8 +++-
3 files changed, 18 insertions(+), 2 deletions(-)
Index: v4l2spec-0.24/Makefile
===
--- v4l2spec-0.24.orig/Makefile 2009-01-14 13:30:23.0 -0600
+++ v4l2spec-0.24/Makefile 2009-01-14 13:32:14.0 -0600
@@ -338,6 +338,7 @@
v4l2_mpeg_videotype \
v4l2_mpeg_videotype \
v4l2_power_line_frequency \
+ v4l2_colorfx \
v4l2_prio_state \
; do echo "-e \"s/ *$$i/ $$i/g\""; done)
Index: v4l2spec-0.24/controls.sgml
===
--- v4l2spec-0.24.orig/controls.sgml2009-01-14 13:17:18.0 -0600
+++ v4l2spec-0.24/controls.sgml 2009-01-14 13:32:53.0 -0600
@@ -261,11 +261,20 @@
Adjusts the backlight compensation in a camera. The
minimum value disables backlight compensation.
+
+V4L2_CID_COLORFX
+integer
+Sets the color effect to be applied to the captured
+or displayed image. Possible values are:
+V4L2_COLORFX_DEFAULT (0),
+V4L2_COLORFX_BW (1) and
+V4L2_COLORFX_SEPIA (2).
+
V4L2_CID_LASTP1
End of the predefined control IDs (currently
-V4L2_CID_BACKLIGHT_COMPENSATION + 1).
+V4L2_CID_COLORFX + 1).
V4L2_CID_PRIVATE_BASE
Index: v4l2spec-0.24/videodev2.h
===
--- v4l2spec-0.24.orig/videodev2.h 2009-01-14 13:30:57.0 -0600
+++ v4l2spec-0.24/videodev2.h 2009-01-14 13:31:53.0 -0600
@@ -879,7 +879,13 @@
#define V4L2_CID_WHITE_BALANCE_TEMPERATURE (V4L2_CID_BASE+26)
#define V4L2_CID_SHARPNESS (V4L2_CID_BASE+27)
#define V4L2_CID_BACKLIGHT_COMPENSATION(V4L2_CID_BASE+28)
-#define V4L2_CID_LASTP1(V4L2_CID_BASE+29) /*
last CID + 1 */
+#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+enum v4l2_colorfx {
+ V4L2_COLORFX_DEFAULT= 0,
+ V4L2_COLORFX_BW = 1,
+ V4L2_COLORFX_SEPIA = 2,
+};
+#define V4L2_CID_LASTP1(V4L2_CID_BASE+32) /*
last CID + 1 */
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
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: Building v4l2spec docbook problems
> -Original Message- > From: video4linux-list-boun...@redhat.com [mailto:video4linux-list- > boun...@redhat.com] On Behalf Of Hans Verkuil > Sent: Sunday, December 07, 2008 6:48 AM > To: v4l > Subject: Building v4l2spec docbook problems > > Hi all, > > I'm trying to build the v4l2spec: > http://v4l2spec.bytesex.org/v4l2spec-0.24.tar.bz2 > > But I'm getting the following errors: > > ... > Using catalogs: /etc/sgml/catalog > Using stylesheet: /home/hans/work/src/v4l2spec-0.24/custom.dsl#html > Working on: /home/hans/work/src/v4l2spec-0.24/v4l2.sgml > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:357:5:W: cannot > generate system identifier for general entity "sub-common" > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:357:5:E: general > entity "sub-common" not defined and no default entity > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:357:15:E: reference to > entity "sub-common" for which no system identifier could be generated > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:357:4: entity was > defined here > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:358:11:E: end tag > for "CHAPTER" which is not finished > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:361:5:W: cannot > generate system identifier for general entity "sub-pixfmt" > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:361:5:E: general > entity "sub-pixfmt" not defined and no default entity > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:361:15:E: reference to > entity "sub-pixfmt" for which no system identifier could be generated > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:361:4: entity was > defined here > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:362:11:E: end tag > for "CHAPTER" which is not finished > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:365:5:W: cannot > generate system identifier for general entity "sub-io" > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:365:5:E: general > entity "sub-io" not defined and no default entity > jade:/home/hans/work/src/v4l2spec-0.24/v4l2.sgml:365:11:E: reference to > entity "sub-io" for which no system identifier could be generated > > And this continues for a long list of 'sub-something' entities. > > Me no speak sgml, so I hope someone more familiar with this can help me. Hi Hans, I'm having the same problems than you. Any update on this? I don't speak sgml either :(. Regards, Sergio > > Thanks, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG > > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list
RE: Patch series in Tarball submitted (RE: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2)
> -Original Message- > From: Hiremath, Vaibhav > Sent: Wednesday, January 14, 2009 8:51 AM > [Hiremath, Vaibhav] I tried to build camera driver as module and got > following error - > > ERROR: "ispmmu_get_mapeable_space" [drivers/media/video/omap34xxcam.ko] > undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > You have missed to export this symbol, please correct in next version of > patches. > Oops, good catch. Thanks, I'll correct that. No problem. Regards, Sergio -- 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
Color FX User control proposal
Hi,
Recently in TI and Nokia, we are working towards having for acceptance an OMAP3
camera driver, which uses an on-chip Image Signal Processor that has one
feature of color effects. We were using a V4L2 private CID for that, but have
been suggested that this could be common enough to propose to the V4L2 spec
aswell for other devices to use.
Below patch adds the control to include/linux/videodev2.h file, should this be
enough? (This patch is taking as a codebase the latest linux-omap kernel, which
I believe is v2.6.28 still)
Thanks and Regards,
Sergio
>From 022b87f3e7f3c3be141ab271a110948ea9567a69 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre
Date: Tue, 13 Jan 2009 16:25:31 -0600
Subject: [PATCH] V4L2: Add COLORFX user control
This is a common feature on many cameras. the options are:
Default colors,
B & W,
Sepia
Signed-off-by: Sergio Aguirre
---
include/linux/videodev2.h |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4669d7e..b02a10d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -876,8 +876,15 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_BACKLIGHT_COMPENSATION(V4L2_CID_BASE+28)
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
+#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+enum v4l2_colorfx {
+ V4L2_COLORFX_DEFAULT= 0,
+ V4L2_COLORFX_BW = 1,
+ V4L2_COLORFX_SEPIA = 2,
+};
+
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+31)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch series in Tarball submitted (RE: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2)
Hi all, Just in case you're having troubles getting the patches, heres a tarball with all of them: https://omapzoom.org/gf/download/docmanfileversion/51/959/l-o_cam_patches_2009_01_12.tar.bz2 I appreciate your time, Sergio > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto > Sent: Monday, January 12, 2009 8:03 PM > To: linux-o...@vger.kernel.org > Cc: linux-media@vger.kernel.org; video4linux-l...@redhat.com; Sakari > Ailus; Tuukka.O Toivonen; Nagalla, Hari > Subject: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver > v2 > > Hi, > > I'm sending the following patchset for review to the relevant lists > (linux-omap, v4l, linux-media). > > Includes: > - Omap3 camera core + ISP drivers. > - MT9P012 sensor driver (adapted to 3430SDP) > - DW9710 lens driver (adapted to work with MT9P012 for SDP) > - Necessary v4l2-int-device changes to make above drivers work > - Redefine OMAP3 ISP platform device. > - Review comments fixed from: (Thanks a lot for their time and help) >- Hans Verkuil >- Tony Lindgreen >- Felipe Balbi >- Vaibhav Hiremath >- David Brownell > > Some notes: > - Uses v4l2-int-device solution. > - Tested with 3430SDP ES3.0 VG5.0.1 with Camkit v3.0.1 > - Applies cleanly on top of commit > 0ec95b96fd77036a13398c66901e11cd301190d0 by Jouni Hogander (OMAP3: PM: > Emu_pwrdm is switched off by hardware even when sdti is in use) > - ISP wrappers dropped from the patchset, as a rework is going on > currently. > > > I appreciate in advance your time. > > Regards, > Sergio > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2
Hi Stanley, I'm currently have that patch on hold, along with the ISP wrapper because I'm reworking them, and also I wanted first to be sure the OMAP3 camera core gets pushed (that's why I included only one sensor driver, to be able to test at least the camera core), and that way I feel it'll be more easier that the OV3640 sensor gets accepted after that. Thanks for the interest. Regards, Sergio > -Original Message- > From: stanley.miao [mailto:stanley.m...@windriver.com] > Sent: Monday, January 12, 2009 8:31 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: linux-o...@vger.kernel.org; video4linux-l...@redhat.com; Nagalla, > Hari; Sakari Ailus; Tuukka.O Toivonen; linux-media@vger.kernel.org > Subject: Re: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor > driver v2 > > Hi,Sergio, > > I saw you had a ov3640 patch in omapzoom tree. Why don't you submit it > together ? > > Stanley. > > On Mon, 2009-01-12 at 20:03 -0600, Aguirre Rodriguez, Sergio Alberto > wrote: > > Hi, > > > > I'm sending the following patchset for review to the relevant lists > (linux-omap, v4l, linux-media). > > > > Includes: > > - Omap3 camera core + ISP drivers. > > - MT9P012 sensor driver (adapted to 3430SDP) > > - DW9710 lens driver (adapted to work with MT9P012 for SDP) > > - Necessary v4l2-int-device changes to make above drivers work > > - Redefine OMAP3 ISP platform device. > > - Review comments fixed from: (Thanks a lot for their time and help) > >- Hans Verkuil > >- Tony Lindgreen > >- Felipe Balbi > >- Vaibhav Hiremath > >- David Brownell > > > > Some notes: > > - Uses v4l2-int-device solution. > > - Tested with 3430SDP ES3.0 VG5.0.1 with Camkit v3.0.1 > > - Applies cleanly on top of commit > 0ec95b96fd77036a13398c66901e11cd301190d0 by Jouni Hogander (OMAP3: PM: > Emu_pwrdm is switched off by hardware even when sdti is in use) > > - ISP wrappers dropped from the patchset, as a rework is going on > currently. > > > > > > I appreciate in advance your time. > > > > Regards, > > Sergio > > > > -- > > video4linux-list mailing list > > Unsubscribe mailto:video4linux-list- > requ...@redhat.com?subject=unsubscribe > > https://www.redhat.com/mailman/listinfo/video4linux-list -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 13/14] OMAP: CAM: Add DW9710 Lens Driver
This adds the DW9710 Lens driver
Signed-off-by: Sergio Aguirre
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/dw9710.c | 548 +
drivers/media/video/dw9710_priv.h | 57
include/media/dw9710.h| 35 +++
5 files changed, 649 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/dw9710.c
create mode 100644 drivers/media/video/dw9710_priv.h
create mode 100644 include/media/dw9710.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 1616c32..10075c3 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -313,6 +313,14 @@ config VIDEO_MT9P012
MT9P012 camera. It is currently working with the TI OMAP3
camera controller.
+config VIDEO_DW9710
+ tristate "Lens driver for DW9710"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 lens driver for the Dongwoon
+ DW9710 coil. It is currently working with the TI OMAP3
+ camera controller and micron MT9P012 sensor.
+
config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L1 && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f73b65c..41c71d5 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_MT9P012)+= mt9p012.o
+obj-$(CONFIG_VIDEO_DW9710) += dw9710.o
obj-$(CONFIG_VIDEO_OMAP3) += omap34xxcam.o isp/
diff --git a/drivers/media/video/dw9710.c b/drivers/media/video/dw9710.c
new file mode 100644
index 000..362cb0d
--- /dev/null
+++ b/drivers/media/video/dw9710.c
@@ -0,0 +1,548 @@
+/*
+ * drivers/media/video/dw9710.c
+ *
+ * DW9710 Coil Motor (LENS) driver
+ *
+ * Copyright (C) 2008 Texas Instruments.
+ *
+ * Contributors:
+ * Troy Laramy
+ * Mohit Jalori
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include "dw9710_priv.h"
+
+static struct dw9710_device dw9710 = {
+ .state = DW9710_LENS_NOT_DETECTED,
+ .current_lens_posn = DW9710_DEF_LENS_POSN,
+};
+
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+ int current_value;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_FOCUS_ABSOLUTE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Focus, Absolute",
+ .minimum = 0,
+ .maximum = DW9710_MAX_FOCUS_POS,
+ .step = DW9710_LENS_POSN_STEP,
+ .default_value = DW9710_DEF_LENS_POSN,
+ },
+ .current_value = DW9710_DEF_LENS_POSN,
+ }
+};
+
+/**
+ * find_vctrl - Finds the requested ID in the video control structure array
+ * @id: ID of control to search the video control array for
+ *
+ * Returns the index of the requested ID from the control structure array
+ */
+static int find_vctrl(int id)
+{
+ int i;
+
+ if (id < V4L2_CID_BASE)
+ return -EDOM;
+
+ for (i = (ARRAY_SIZE(video_control) - 1); i >= 0; i--) {
+ if (video_control[i].qc.id == id)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * dw9710_reg_read - Reads a value from a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Pointer to u16 for returning value of register to read.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_read(struct i2c_client *client, u16 *value)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[2];
+
+ if (!client->adapter)
+ return -ENODEV;
+
+ msg->addr = client->addr;
+ msg->flags = I2C_M_RD;
+ msg->len = 2;
+ msg->buf = data;
+
+ data[0] = 0;
+ data[1] = 0;
+
+ err = i2c_transfer(client->adapter, msg, 1);
+
+ if (err >= 0) {
+ err = ((data[0] & 0xFF) << 8) | (data[1]);
+ *value = err;
+ return 0;
+ }
+ return err;
+}
+
+/**
+ * dw9710_reg_write - Writes a value to a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Value of register to write.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_write(struct i2c_client *client, u16 value)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[2];
+ int retry = 0;
+
+ if (!client->adapter)
+ return -ENODEV;
+
[REVIEW PATCH 14/14] OMAP34XX: CAM: Add Sensors Support
This adds support in OMAP34xx SDP board file for
MT9P012 Sensor and DW9710 Lens driver.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-3430sdp.c | 319 ++-
1 files changed, 318 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ade186b..8fa1d4d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,31 @@
#include
#include
+#ifdef CONFIG_VIDEO_OMAP3
+#include
+#include <../drivers/media/video/omap34xxcam.h>
+#include <../drivers/media/video/isp/ispreg.h>
+#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
+/* Sensor specific GPIO signals */
+#define MT9P012_RESET_GPIO 98
+#define MT9P012_STANDBY_GPIO 58
+
+#define MT9P012_USE_XCLKA 0
+#define MT9P012_USE_XCLKB 1
+
+#define VAUX_2_8_V 0x09
+#define VAUX_DEV_GRP_P10x20
+#define VAUX_DEV_GRP_NONE 0x00
+
+#include
+static enum v4l2_power mt9p012_previous_power = V4L2_POWER_OFF;
+#endif
+#endif
+
+#ifdef CONFIG_VIDEO_DW9710
+#include
+#endif
+
#include
#include
#include
@@ -238,6 +264,281 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
},
};
+#ifdef CONFIG_VIDEO_OMAP3
+#define DEBUG_BASE 0x0800
+#define REG_SDP3430_FPGA_GPIO_2 (0x50)
+#define FPGA_SPR_GPIO1_3v3 (0x1 << 14)
+#define FPGA_GPIO6_DIR_CTRL(0x1 << 6)
+
+static void __iomem *fpga_map_addr;
+
+static void enable_fpga_vio_1v8(u8 enable)
+{
+ u16 reg_val;
+
+ fpga_map_addr = ioremap(DEBUG_BASE, 4096);
+ reg_val = readw(fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+
+ /* Ensure that the SPR_GPIO1_3v3 is 0 - powered off.. 1 is on */
+ if (reg_val & FPGA_SPR_GPIO1_3v3) {
+ reg_val |= FPGA_SPR_GPIO1_3v3;
+ reg_val |= FPGA_GPIO6_DIR_CTRL; /* output mode */
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ /* give a few milli sec to settle down
+* Let the sensor also settle down.. if required..
+*/
+ if (enable)
+ mdelay(10);
+ }
+
+ if (enable) {
+ reg_val |= FPGA_SPR_GPIO1_3v3 | FPGA_GPIO6_DIR_CTRL;
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ }
+ /* Vrise time for the voltage - should be less than 1 ms */
+ mdelay(1);
+}
+#endif
+
+#ifdef CONFIG_VIDEO_DW9710
+static int dw9710_lens_power_set(enum v4l2_power power)
+{
+
+ /* The power change depends on MT9P012 powerup, so if we request a
+* power state different from sensor, we should return error
+*/
+ if ((mt9p012_previous_power != V4L2_POWER_OFF) &&
+ (power != mt9p012_previous_power))
+ return -EIO;
+
+ switch (power) {
+ case V4L2_POWER_OFF:
+ /* Power Down Sequence */
+#ifdef CONFIG_TWL4030_CORE
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ VAUX_DEV_GRP_NONE, TWL4030_VAUX2_DEV_GRP);
+#else
+#error "no power companion board defined!"
+#endif
+ enable_fpga_vio_1v8(0);
+ gpio_free(MT9P012_RESET_GPIO);
+ iounmap(fpga_map_addr);
+ gpio_free(MT9P012_STANDBY_GPIO);
+ break;
+ case V4L2_POWER_ON:
+ /* Request and configure gpio pins */
+ if (gpio_request(MT9P012_STANDBY_GPIO,
+ "mt9p012_standby_gpio")) {
+ printk(KERN_WARNING "Could not request GPIO %d"
+ " for MT9P012\n",
+ MT9P012_STANDBY_GPIO);
+ return -EIO;
+ }
+
+ /* Request and configure gpio pins */
+ if (gpio_request(MT9P012_RESET_GPIO, "mt9p012_reset_gpio"))
+ return -EIO;
+
+ /* set to output mode */
+ gpio_direction_output(MT9P012_STANDBY_GPIO, true);
+ /* set to output mode */
+ gpio_direction_output(MT9P012_RESET_GPIO, true);
+
+ /* STANDBY_GPIO is active HIGH for set LOW to release */
+ gpio_set_value(MT9P012_STANDBY_GPIO, 1);
+
+ /* nRESET is active LOW. set HIGH to release reset */
+ gpio_set_value(MT9P012_RESET_GPIO, 1);
+
+ /* turn on digital power */
+ enable_fpga_vio_1v8(1);
+#ifdef CONFIG_TWL4030_CORE
+ /* turn on analog power */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ VAUX_2_8_V, TWL4030_VAUX2_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODU
[REVIEW PATCH 10/14] OMAP: CAM: Add ISP gain tables
This adds the OMAP ISP gain tables. Includes: * Blue Gamma gain table * CFA gain table * Green Gamma gain table * Luma Enhancement gain table * Noise filter gain table * Red Gamma gain table Signed-off-by: Sergio Aguirre --- drivers/media/video/isp/bluegamma_table.h| 1040 ++ drivers/media/video/isp/cfa_coef_table.h | 592 +++ drivers/media/video/isp/greengamma_table.h | 1040 ++ drivers/media/video/isp/luma_enhance_table.h | 144 drivers/media/video/isp/noise_filter_table.h | 79 ++ drivers/media/video/isp/redgamma_table.h | 1040 ++ 6 files changed, 3935 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/isp/bluegamma_table.h create mode 100644 drivers/media/video/isp/cfa_coef_table.h create mode 100644 drivers/media/video/isp/greengamma_table.h create mode 100644 drivers/media/video/isp/luma_enhance_table.h create mode 100644 drivers/media/video/isp/noise_filter_table.h create mode 100644 drivers/media/video/isp/redgamma_table.h diff --git a/drivers/media/video/isp/bluegamma_table.h b/drivers/media/video/isp/bluegamma_table.h new file mode 100644 index 000..9ec8376 --- /dev/null +++ b/drivers/media/video/isp/bluegamma_table.h @@ -0,0 +1,1040 @@ +/* + * drivers/media/video/isp/bluegamma_table.h + * + * Gamma Table values for BLUE for TI's OMAP3 Camera ISP + * + * Copyright (C) 2008 Texas Instruments, Inc. + * + * 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. + */ + +0, +0, +1, +2, +3, +3, +4, +5, +6, +8, +10, +12, +14, +16, +18, +20, +22, +23, +25, +26, +28, +29, +31, +32, +34, +35, +36, +37, +39, +40, +41, +42, +43, +44, +45, +46, +47, +48, +49, +50, +51, +52, +52, +53, +54, +55, +56, +57, +58, +59, +60, +61, +62, +63, +63, +64, +65, +66, +66, +67, +68, +69, +69, +70, +71, +72, +72, +73, +74, +75, +75, +76, +77, +78, +78, +79, +80, +81, +81, +82, +83, +84, +84, +85, +86, +87, +88, +88, +89, +90, +91, +91, +92, +93, +94, +94, +95, +96, +97, +97, +98, +98, +99, +99, +100, +100, +101, +101, +102, +103, +104, +104, +105, +106, +107, +108, +108, +109, +110, +111, +111, +112, +113, +114, +114, +115, +116, +117, +117, +118, +119, +119, +120, +120, +121, +121, +122, +122, +123, +123, +124, +124, +125, +125, +126, +126, +127, +127, +128, +128, +129, +129, +130, +130, +131, +131, +132, +132, +133, +133, +134, +134, +135, +135, +136, +136, +137, +137, +138, +138, +139, +139, +140, +140, +141, +141, +142, +142, +143, +143, +144, +144, +145, +145, +146, +146, +147, +147, +148, +148, +149, +149, +150, +150, +151, +151, +152, +152, +153, +153, +153, +153, +154, +154, +154, +154, +155, +155, +156, +156, +157, +157, +158, +158, +158, +159, +159, +159, +160, +160, +160, +161, +161, +162, +162, +163, +163, +164, +164, +164, +164, +165, +165, +165, +165, +166, +166, +167, +167, +168, +168, +169, +169, +170, +170, +170, +170, +171, +171, +171, +171, +172, +172, +173, +173, +174, +174, +175, +175, +176, +176, +176, +176, +177, +177, +177, +177, +178, +178, +178, +178, +179, +179, +179, +179, +180, +180, +180, +180, +181, +181, +181, +181, +182, +182, +182, +182, +183, +183, +183, +183, +184, +184, +184, +184, +185, +185, +185, +185, +186, +186, +186, +186, +187, +187, +187, +187, +188, +188, +188, +188, +189, +189, +189, +189, +190, +190, +190, +190, +191, +191, +191, +191, +192, +192, +192, +192, +193, +193, +193, +193, +194, +194, +194, +194, +195, +195, +195, +195, +196, +196, +196, +196, +197, +197, +197, +197, +198, +198, +198, +198, +199, +199, +199, +199, +200, +200, +200, +200, +201, +201, +201, +201, +202, +202, +202, +203, +203, +203, +203, +204, +204, +204, +204, +205, +205, +205, +205, +206, +206, +206, +206, +207, +207, +207, +207, +208, +208, +208, +208, +209, +209, +209, +209, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +211, +211, +211, +211, +211, +211, +211, +211, +211, +211, +211, +212, +212, +212, +212, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +214, +214, +214, +214, +215, +215, +215, +215, +215, +215, +215, +215, +215, +215, +215, +216, +216, +216, +216, +217, +217, +217, +217, +218, +218, +218, +218, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +220, +220, +220, +220, +221, +221, +221, +221, +221, +221, +221, +221, +221, +221, +221, +222, +222, +222, +222, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +224, +224, +224, +224, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +226, +226, +226, +226, +227, +227, +227, +227, +227, +227, +227, +227, +227,
[REVIEW PATCH 03/14] OMAP34XX: CAM: Resources fixes
This patch reassigns resources of a omap3isp platform device,
which is more adequate than the older one. This is needed for
using __raw_[readl,writel] calls after ioremapping the specified
platform resources in ISP driver.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/devices.c | 76 ++--
arch/arm/plat-omap/include/mach/omap34xx.h | 53 +++-
2 files changed, 123 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d7e848e..4617c8b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -56,10 +56,68 @@ static inline void omap_init_camera(void)
#elif defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
-static struct resource cam_resources[] = {
+static struct resource omap34xxcam_resources[] = {
+};
+
+static struct resource omap3isp_resources[] = {
+ {
+ .start = OMAP3_ISP_BASE,
+ .end= OMAP3_ISP_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CBUFF_BASE,
+ .end= OMAP3_ISP_CBUFF_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CCP2_BASE,
+ .end= OMAP3_ISP_CCP2_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CCDC_BASE,
+ .end= OMAP3_ISP_CCDC_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_HIST_BASE,
+ .end= OMAP3_ISP_HIST_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_H3A_BASE,
+ .end= OMAP3_ISP_H3A_END,
+ .flags = IORESOURCE_MEM,
+ },
{
- .start = OMAP34XX_CAMERA_BASE,
- .end= OMAP34XX_CAMERA_BASE + 0x1B70,
+ .start = OMAP3_ISP_PREV_BASE,
+ .end= OMAP3_ISP_PREV_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_RESZ_BASE,
+ .end= OMAP3_ISP_RESZ_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_SBL_BASE,
+ .end= OMAP3_ISP_SBL_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_MMU_BASE,
+ .end= OMAP3_ISP_MMU_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CSI2A_BASE,
+ .end= OMAP3_ISP_CSI2A_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CSI2PHY_BASE,
+ .end= OMAP3_ISP_CSI2PHY_END,
.flags = IORESOURCE_MEM,
},
{
@@ -71,13 +129,21 @@ static struct resource cam_resources[] = {
static struct platform_device omap_cam_device = {
.name = "omap34xxcam",
.id = -1,
- .num_resources = ARRAY_SIZE(cam_resources),
- .resource = cam_resources,
+ .num_resources = ARRAY_SIZE(omap34xxcam_resources),
+ .resource = omap34xxcam_resources,
+};
+
+static struct platform_device omap_isp_device = {
+ .name = "omap3isp",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap3isp_resources),
+ .resource = omap3isp_resources,
};
static inline void omap_init_camera(void)
{
platform_device_register(&omap_cam_device);
+ platform_device_register(&omap_isp_device);
}
#else
static inline void omap_init_camera(void)
diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h
b/arch/arm/plat-omap/include/mach/omap34xx.h
index 27a1e45..d19c423 100644
--- a/arch/arm/plat-omap/include/mach/omap34xx.h
+++ b/arch/arm/plat-omap/include/mach/omap34xx.h
@@ -56,7 +56,32 @@
#define OMAP34XX_SR1_BASE 0x480C9000
#define OMAP34XX_SR2_BASE 0x480CB000
-#define OMAP34XX_CAMERA_BASE (L4_34XX_BASE + 0xBC000)
+#define OMAP3430_ISP_BASE (L4_34XX_BASE + 0xBC000)
+#define OMAP3430_ISP_CBUFF_BASE(OMAP3430_ISP_BASE + 0x0100)
+#define OMAP3430_ISP_CCP2_BASE (OMAP3430_ISP_BASE + 0x0400)
+#define OMAP3430_ISP_CCDC_BASE (OMAP3430_ISP_BASE + 0x0600)
+#define OMAP3430_ISP_HIST_BASE (OMAP3430_ISP_BASE + 0x0A00)
+#define OMAP3430_ISP_H3A_BASE (OMAP3430_ISP_BASE + 0x0C00)
+#define OMAP3430_ISP_PREV_BASE (OMAP3430_ISP_BASE + 0x0E00)
+#define OMAP3430_ISP_RESZ_BASE (OMAP3430_ISP_BASE + 0x100
[REVIEW PATCH 02/14] v4l2-int-device: add support for VIDIOC_QUERYMENU
Signed-off-by: Tuukka Toivonen
Signed-off-by: Sergio Aguirre
---
include/media/v4l2-int-device.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 85a1834..052ffe0 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -178,6 +178,7 @@ enum v4l2_int_ioctl_num {
vidioc_int_s_fmt_cap_num,
vidioc_int_try_fmt_cap_num,
vidioc_int_queryctrl_num,
+ vidioc_int_querymenu_num,
vidioc_int_g_ctrl_num,
vidioc_int_s_ctrl_num,
vidioc_int_cropcap_num,
@@ -279,6 +280,7 @@ V4L2_INT_WRAPPER_1(g_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(s_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(try_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(queryctrl, struct v4l2_queryctrl, *);
+V4L2_INT_WRAPPER_1(querymenu, struct v4l2_querymenu, *);
V4L2_INT_WRAPPER_1(g_ctrl, struct v4l2_control, *);
V4L2_INT_WRAPPER_1(s_ctrl, struct v4l2_control, *);
V4L2_INT_WRAPPER_1(cropcap, struct v4l2_cropcap, *);
--
1.5.6.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
[REVIEW PATCH 01/14] V4L: Int if: Dummy slave
This patch implements a dummy slave that has no functionality. Helps
managing slaves in the OMAP 3 camera driver; no need to check for NULL
pointers.
Signed-off-by: Sakari Ailus
Signed-off-by: Sergio Aguirre
---
drivers/media/video/v4l2-int-device.c | 19 +++
include/media/v4l2-int-device.h |2 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-int-device.c
b/drivers/media/video/v4l2-int-device.c
index a935bae..cba1c9c 100644
--- a/drivers/media/video/v4l2-int-device.c
+++ b/drivers/media/video/v4l2-int-device.c
@@ -32,6 +32,25 @@
static DEFINE_MUTEX(mutex);
static LIST_HEAD(int_list);
+static struct v4l2_int_slave dummy_slave = {
+ /* Dummy pointer to avoid underflow in find_ioctl. */
+ .ioctls = (void *)0x8000,
+ .num_ioctls = 0,
+};
+
+static struct v4l2_int_device dummy = {
+ .type = v4l2_int_type_slave,
+ .u = {
+ .slave = &dummy_slave,
+ },
+};
+
+struct v4l2_int_device *v4l2_int_device_dummy()
+{
+ return &dummy;
+}
+EXPORT_SYMBOL_GPL(v4l2_int_device_dummy);
+
void v4l2_int_device_try_attach_all(void)
{
struct v4l2_int_device *m, *s;
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 9c2df41..85a1834 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -84,6 +84,8 @@ struct v4l2_int_device {
void *priv;
};
+struct v4l2_int_device *v4l2_int_device_dummy(void);
+
void v4l2_int_device_try_attach_all(void);
int v4l2_int_device_register(struct v4l2_int_device *d);
--
1.5.6.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
[REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2
Hi, I'm sending the following patchset for review to the relevant lists (linux-omap, v4l, linux-media). Includes: - Omap3 camera core + ISP drivers. - MT9P012 sensor driver (adapted to 3430SDP) - DW9710 lens driver (adapted to work with MT9P012 for SDP) - Necessary v4l2-int-device changes to make above drivers work - Redefine OMAP3 ISP platform device. - Review comments fixed from: (Thanks a lot for their time and help) - Hans Verkuil - Tony Lindgreen - Felipe Balbi - Vaibhav Hiremath - David Brownell Some notes: - Uses v4l2-int-device solution. - Tested with 3430SDP ES3.0 VG5.0.1 with Camkit v3.0.1 - Applies cleanly on top of commit 0ec95b96fd77036a13398c66901e11cd301190d0 by Jouni Hogander (OMAP3: PM: Emu_pwrdm is switched off by hardware even when sdti is in use) - ISP wrappers dropped from the patchset, as a rework is going on currently. I appreciate in advance your time. Regards, Sergio -- 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
