Re: [PULL] soc-camera and mediabus
Guennadi Liakhovetski wrote:
> Hi Mauro
>
> On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:
>
>> Guennadi Liakhovetski wrote:
>>> So, is the doc patch, that I've sent to the list ok? Ok, the hunk for the
>>> automatically (in hg) generated file will get dropped, and otherwise does
>>> it look correct?
>> It looks correctly on my eyes. The only thing I noticed is that you've added
>> emacs headers at the end of the new patches:
>>
>> +
>> +
>>
>> Please remove those tags when submitting the final version.
>
> I tried to just through away the media-specs/media-entities.tmpl hunk, as
> that file should be auto-generated, but the new version doesn't include
> the new formats either. What am I doing wrong? The patch attached below.
As you're adding new files, you need to tell Makefile to take a look on them
also. So, just add the new files to V4L_SGMLS list at Makefile should do
the job.
Cheers,
Mauro.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
> # HG changeset patch
> # User Guennadi Liakhovetski
> # Date 1261648434 -3600
> # Node ID 52e14d4799279a860fe158e8bf4f1993d6c6
> # Parent 4506e2d541265bfa0c0fd5187c6a39d39a456559
> document new pixel formats
>
> Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
> 8-bit Bayer formats.
>
> Signed-off-by: Guennadi Liakhovetski
>
> diff -r 4506e2d54126 -r 52e14d479927
> linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml Thu Dec 24
> 10:53:54 2009 +0100
> @@ -0,0 +1,90 @@
> +
> +
> + V4L2_PIX_FMT_SRGGB10 ('RG10'),
> + V4L2_PIX_FMT_SGRBG10 ('BA10'),
> + V4L2_PIX_FMT_SGBRG10 ('GB10'),
> + V4L2_PIX_FMT_SBGGR10 ('BG10'),
> +
> + &manvol;
> +
> +
> + id="V4L2-PIX-FMT-SRGGB10">V4L2_PIX_FMT_SRGGB10
> + id="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10
> + id="V4L2-PIX-FMT-SGBRG10">V4L2_PIX_FMT_SGBRG10
> + id="V4L2-PIX-FMT-SBGGR10">V4L2_PIX_FMT_SBGGR10
> + 10-bit Bayer formats expanded to 16 bits
> +
> +
> + Description
> +
> + The following four pixel formats are raw sRGB / Bayer formats with
> +10 bits per colour. Each colour component is stored in a 16-bit word, with 6
> +unused high bits filled with zeros. Each n-pixel row contains n/2 green
> samples
> +and n/2 blue or red samples, with alternating red and blue rows. Bytes are
> +stored in memory in little endian order. They are conventionally described
> +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
> +formats
> +
> +
> + V4L2_PIX_FMT_SBGGR10 4 × 4
> +pixel image
> +
> +
> + Byte Order.
> + Each cell is one byte, high 6 bits in high bytes are 0.
> +
> +
> +
> +
> +
> + start + 0:
> + B00low
> + B00high
> + G01low
> + G01high
> + B02low
> + B02high
> + G03low
> + G03high
> +
> +
> + start + 8:
> + G10low
> + G10high
> + R11low
> + R11high
> + G12low
> + G12high
> + R13low
> + R13high
> +
> +
> + start + 16:
> + B20low
> + B20high
> + G21low
> + G21high
> + B22low
> + B22high
> + G23low
> + G23high
> +
> +
> + start + 24:
> + G30low
> + G30high
> + R31low
> + R31high
> + G32low
> + G32high
> + R33low
> + R33high
> +
> +
> +
> +
> +
> +
> +
> +
> +
> diff -r 4506e2d54126 -r 52e14d479927
> linux/Documentation/DocBook/v4l/pixfmt-srggb8.xml
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb8.xml Thu Dec 24
> 10:53:54 2009 +0100
> @@ -0,0 +1,67 @@
> +
> +
> + V4L2_PIX_FMT_SRGGB8 ('RGGB')
> + &manvol;
> +
> +
> + V4L2_PIX_FMT_SRGGB8
> + Bayer RGB format
> +
> +
> + Description
> +
> + This is commonly the native format of digital cameras,
> +reflecting the arrangement of sensors on the CCD device. Only one red,
> +green or blue value is given for each pixel. Missing components must
> +be interpolated from neighbouring pixels. From left to right the first
> +row consists of a red and green value, the second row of a green and
> +blue value. This scheme repeats to the right and down for every two
> +columns and rows.
> +
> +
> + V4L2_PIX_
Re: [PULL] soc-camera and mediabus
Hi Mauro
On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:
> Guennadi Liakhovetski wrote:
> >
> > So, is the doc patch, that I've sent to the list ok? Ok, the hunk for the
> > automatically (in hg) generated file will get dropped, and otherwise does
> > it look correct?
>
> It looks correctly on my eyes. The only thing I noticed is that you've added
> emacs headers at the end of the new patches:
>
> +
> +
>
> Please remove those tags when submitting the final version.
I tried to just through away the media-specs/media-entities.tmpl hunk, as
that file should be auto-generated, but the new version doesn't include
the new formats either. What am I doing wrong? The patch attached below.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
# HG changeset patch
# User Guennadi Liakhovetski
# Date 1261648434 -3600
# Node ID 52e14d4799279a860fe158e8bf4f1993d6c6
# Parent 4506e2d541265bfa0c0fd5187c6a39d39a456559
document new pixel formats
Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
8-bit Bayer formats.
Signed-off-by: Guennadi Liakhovetski
diff -r 4506e2d54126 -r 52e14d479927
linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xmlThu Dec 24
10:53:54 2009 +0100
@@ -0,0 +1,90 @@
+
+
+ V4L2_PIX_FMT_SRGGB10 ('RG10'),
+V4L2_PIX_FMT_SGRBG10 ('BA10'),
+V4L2_PIX_FMT_SGBRG10 ('GB10'),
+V4L2_PIX_FMT_SBGGR10 ('BG10'),
+
+ &manvol;
+
+
+ V4L2_PIX_FMT_SRGGB10
+ V4L2_PIX_FMT_SGRBG10
+ V4L2_PIX_FMT_SGBRG10
+ V4L2_PIX_FMT_SBGGR10
+ 10-bit Bayer formats expanded to 16 bits
+
+
+ Description
+
+ The following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats
+
+
+ V4L2_PIX_FMT_SBGGR10 4 × 4
+pixel image
+
+
+ Byte Order.
+ Each cell is one byte, high 6 bits in high bytes are 0.
+
+
+
+
+
+ start + 0:
+ B00low
+ B00high
+ G01low
+ G01high
+ B02low
+ B02high
+ G03low
+ G03high
+
+
+ start + 8:
+ G10low
+ G10high
+ R11low
+ R11high
+ G12low
+ G12high
+ R13low
+ R13high
+
+
+ start + 16:
+ B20low
+ B20high
+ G21low
+ G21high
+ B22low
+ B22high
+ G23low
+ G23high
+
+
+ start + 24:
+ G30low
+ G30high
+ R31low
+ R31high
+ G32low
+ G32high
+ R33low
+ R33high
+
+
+
+
+
+
+
+
+
diff -r 4506e2d54126 -r 52e14d479927
linux/Documentation/DocBook/v4l/pixfmt-srggb8.xml
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb8.xml Thu Dec 24 10:53:54
2009 +0100
@@ -0,0 +1,67 @@
+
+
+ V4L2_PIX_FMT_SRGGB8 ('RGGB')
+ &manvol;
+
+
+ V4L2_PIX_FMT_SRGGB8
+ Bayer RGB format
+
+
+ Description
+
+ This is commonly the native format of digital cameras,
+reflecting the arrangement of sensors on the CCD device. Only one red,
+green or blue value is given for each pixel. Missing components must
+be interpolated from neighbouring pixels. From left to right the first
+row consists of a red and green value, the second row of a green and
+blue value. This scheme repeats to the right and down for every two
+columns and rows.
+
+
+ V4L2_PIX_FMT_SRGGB8 4 × 4
+pixel image
+
+
+ Byte Order.
+ Each cell is one byte.
+
+
+
+
+
+ start + 0:
+ R00
+ G01
+ R02
+ G03
+
+
+ start + 4:
+ G10
+ B11
+
Re: [PULL] soc-camera and mediabus
Hans Verkuil wrote: > On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote: >> On Mon, 14 Dec 2009, Jonathan Cameron wrote: >> > Having bridge-specific code in a sub-device driver will be a disaster in the > long run. Well, we've seen what happens when you do it that way. True. > As far as I know the only soc-dependency left now is for bus configuration. > Proposals were made some time ago and we should pick that up again and remove > that last dependency. We should really go on that direction. V4L i2c drivers shouldn't depend on platform_data. I've experienced some very bad time fixing conflicts and waiting for arch merges in order to try to avoid conflicts related to platform_data changes that should be reflected into V4L drivers. Even after migrating to -git, this problem won't solve, since the header files that holds platform_data are highly volatile: on all kernel versions, they had several changes, and the platform_data patch made while changing the V4L code needs to be changed during the next merge window. Due to that, I don't doubt that some earlier merges had broke git bisect capabilities on those drivers that rely on the highly volatile platform_data header files applied on arch tree and a separate patch applied on v4l tree. It seems that we'll need to have some code that will be responsible to handle arch/platform_data glue, to be merged in the same subsystem that holds the *.h files, taking care on the required differences for drivers that need platform_data to work, and a separate code to handle the V4L functionalities. In other words, drivers like soc_camera and omap core should be broken internally into two separate files (or modules), one with V4L bits and the other with arch/platform_data glue, where the second one should be be maintained together with the corresponding arch code. 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: [PULL] soc-camera and mediabus
On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote:
> On Mon, 14 Dec 2009, Jonathan Cameron wrote:
>
> > Hi All,
> >
> > >> 3) it would be interesting to patch the other sensor drivers to be
> > >> compatible
> > >>with soc_camera (mt9v011/ov7670);
> > >
> > > Well, this could be done, yes, but does it make sense to do this blindly
> > > without any hardware to test? I would rather add such conversions on a
> > > one-by-one basis as need arises.
> > >
> > I'm working on the ov7670. I've added the media bus stuff to what I've
> > previously posted but I haven't tested as yet. For reference, a quick and
> > dirty
> > cut of the patch is below. Some thought is needed on how to deal with the
> > sections
> > that currently need to be different for the soc-camera and non soc camera
> > uses.
> > (mainly the registration code in probe).
>
> Look at my patch for mt9t031. First you do not have to fail if
> client->dev.platform_data == NULL. You have to look at the bridge driver,
> that's currently working with ov7670. If it is not setting platform_data,
> you can use it to detect whether you're in soc-camera environment or not.
> Otherwise, if the bridge driver were also using that pointer, we would
> have to come up with a ov7670-specific struct to be linked from that
> pointer. I was actually thinking about a way to pass soc-camera data to
> client drivers in a way, that would not imped non soc-camera use. So, how
> about:
>
>
> I soc-camera environment
>
> 1. platform defines a
>
> static struct ov7670_platform_data ov7670 = {
> .link = &ov7670_link,
> };
>
> 2. and a
>
> static struct soc_camera_link ov7670_link = {
> .client_data = &ov7670,
> };
>
> 3. soc-camera core gets &ov7670_link in its probe, same as this is done
> now, then it does
>
> icl->icd = icd;
> icl->board_info->platform_data = icl->client_data;
>
> subdev = v4l2_i2c_new_subdev_board(&ici->v4l2_dev, adap,
> icl->module_name, icl->board_info, NULL);
>
> 4. ov7670 probe is called with client platform data pointing to its own
> data:
>
> static int ov7670_probe(struct i2c_client *client,
> const struct i2c_device_id *did)
> {
> struct ov7670_platform_data *pdata = client->dev.platform_data;
> struct soc_camera_link *icl = pdata->link;
> struct soc_camera_device *icd;
>
> if (icl)
> icd = icl->icd;
>
>
> II Non soc-camera environment
>
> 1. the bridge driver fills in sensor data and does
>
> struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));
>
> ov7670_pdata->... = ...;
> board_info->platform_data = ov7670_pdata;
>
> subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
> module_name, board_info, NULL);
>
> 2. ov7670_probe() gets called and finds its data as above, but without an
> soc-camera link this time.
>
>
> The advantage of the above is, that each client driver is free to define
> its own platform data struct, and for soc-camera it only has to provide
> one pointer in it. The ugly side is the cross-referencing between I.1. and
> I.2. above.
>
> Alternatively we could agree, that all client drivers get in their i2c
> client platform data a standard struct with only pointers in it to client
> data and to various bridging models:
>
> struct v4l2_client {
> void *client;
> struct soc_camera_link *icl;
> struct int_device_link *int;
> ...
> };
>
> or a bit more hidden
>
> struct v4l2_client {
> void *client;
> void *bridge_data;
> enum V4L2_BRIDGE_TYPE bridge_type;
> };
Before this goes too far let me just say that I will NAK any attempt in this
direction. Subdevice drivers must eventually be completely independent from
bridge driver. The same driver should work out of the box for soc-camera,
gspca, omap3, davinci, saa7134 and whatever other bridge driver is out there.
Having bridge-specific code in a sub-device driver will be a disaster in the
long run. Well, we've seen what happens when you do it that way.
As far as I know the only soc-dependency left now is for bus configuration.
Proposals were made some time ago and we should pick that up again and remove
that last dependency.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [PULL] soc-camera and mediabus
On Mon, 14 Dec 2009, Jonathan Cameron wrote:
> Hi All,
>
> >> 3) it would be interesting to patch the other sensor drivers to be
> >> compatible
> >>with soc_camera (mt9v011/ov7670);
> >
> > Well, this could be done, yes, but does it make sense to do this blindly
> > without any hardware to test? I would rather add such conversions on a
> > one-by-one basis as need arises.
> >
> I'm working on the ov7670. I've added the media bus stuff to what I've
> previously posted but I haven't tested as yet. For reference, a quick and
> dirty
> cut of the patch is below. Some thought is needed on how to deal with the
> sections
> that currently need to be different for the soc-camera and non soc camera
> uses.
> (mainly the registration code in probe).
Look at my patch for mt9t031. First you do not have to fail if
client->dev.platform_data == NULL. You have to look at the bridge driver,
that's currently working with ov7670. If it is not setting platform_data,
you can use it to detect whether you're in soc-camera environment or not.
Otherwise, if the bridge driver were also using that pointer, we would
have to come up with a ov7670-specific struct to be linked from that
pointer. I was actually thinking about a way to pass soc-camera data to
client drivers in a way, that would not imped non soc-camera use. So, how
about:
I soc-camera environment
1. platform defines a
static struct ov7670_platform_data ov7670 = {
.link = &ov7670_link,
};
2. and a
static struct soc_camera_link ov7670_link = {
.client_data = &ov7670,
};
3. soc-camera core gets &ov7670_link in its probe, same as this is done
now, then it does
icl->icd = icd;
icl->board_info->platform_data = icl->client_data;
subdev = v4l2_i2c_new_subdev_board(&ici->v4l2_dev, adap,
icl->module_name, icl->board_info, NULL);
4. ov7670 probe is called with client platform data pointing to its own
data:
static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct ov7670_platform_data *pdata = client->dev.platform_data;
struct soc_camera_link *icl = pdata->link;
struct soc_camera_device *icd;
if (icl)
icd = icl->icd;
II Non soc-camera environment
1. the bridge driver fills in sensor data and does
struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));
ov7670_pdata->... = ...;
board_info->platform_data = ov7670_pdata;
subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
module_name, board_info, NULL);
2. ov7670_probe() gets called and finds its data as above, but without an
soc-camera link this time.
The advantage of the above is, that each client driver is free to define
its own platform data struct, and for soc-camera it only has to provide
one pointer in it. The ugly side is the cross-referencing between I.1. and
I.2. above.
Alternatively we could agree, that all client drivers get in their i2c
client platform data a standard struct with only pointers in it to client
data and to various bridging models:
struct v4l2_client {
void *client;
struct soc_camera_link *icl;
struct int_device_link *int;
...
};
or a bit more hidden
struct v4l2_client {
void *client;
void *bridge_data;
enum V4L2_BRIDGE_TYPE bridge_type;
};
> On another note, does anyone have an objection to making the set_bus_param
> function optional? At the moment we are adding null functions for those
> devices that can't actually change anything which seems a little pointless.
Yes, it can.
>
> Jonathan
>
>
> diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
> index 0e2184e..e57c3b5 100644
> --- a/drivers/media/video/ov7670.c
> +++ b/drivers/media/video/ov7670.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
>
> MODULE_AUTHOR("Jonathan Corbet ");
> @@ -545,7 +546,7 @@ static struct ov7670_format_struct {
> .bpp= 1
> },
> };
> -#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
> +
>
>
> /*
> @@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int
> hstart, int hstop,
> return ret;
> }
>
> +static enum v4l2_mbus_pixelcode ov7670_codes[] = {
> + V4L2_MBUS_FMT_YUYV8_2X8,
> + V4L2_MBUS_FMT_RGB565_2X8_LE,
> +};
>
> -static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
> +static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum
> v4l2_mbus_pixelcode *code)
> {
> - struct ov7670_format_struct *ofmt;
> -
> - if (fmt->index >= N_OV7670_FMTS)
> + if (index >= ARRAY_SIZE(ov7670_codes))
> return -EINVAL;
>
> - ofmt = ov7670_formats + fmt->index;
> - fmt->flags = 0;
> - strcpy(fmt->description, ofmt->desc);
> - fmt->pixelformat = ofmt->pixelfor
Re: [PULL] soc-camera and mediabus
Jonathan Cameron wrote: > Hi All, > >>> 3) it would be interesting to patch the other sensor drivers to be >>> compatible >>>with soc_camera (mt9v011/ov7670); >> Well, this could be done, yes, but does it make sense to do this blindly >> without any hardware to test? I would rather add such conversions on a >> one-by-one basis as need arises. >> > I'm working on the ov7670. I've added the media bus stuff to what I've > previously posted but I haven't tested as yet. For reference, a quick and > dirty > cut of the patch is below. Some thought is needed on how to deal with the > sections > that currently need to be different for the soc-camera and non soc camera > uses. > (mainly the registration code in probe). True. Couldn't this be a library that handles the code difference between soc-camera platform-data bits and normal subdev? Even better: couldn't this code be handled by soc_camera core and just use subdev interface for both cases? After finishing the patch, please ping me. I have here an OLPC with ov7670 where I can test if the new code doesn't break the cafe_ccic driver. You'll probably need to touch on it, as it will need to use the new mediabus API to talk with ov7670. > On another note, does anyone have an objection to making the set_bus_param > function optional? At the moment we are adding null functions for those > devices that can't actually change anything which seems a little pointless. Agreed. 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: [PULL] soc-camera and mediabus
Guennadi Liakhovetski wrote: > On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote: > >> Guennadi Liakhovetski wrote: >>> Hi Mauro, >>> >>> At last soc-camera and mediabus lot for 2.6.33. Note, that one of this >>> patches adds new fourcc codes. A patch for their documentation will be >>> submitted immediately. >>> >>> Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb >>> >>> for the following 30 changesets: >>> >>> 01/30: tw9910: The driver can also handle revision 1 of the chip >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734 >>> >>> 02/30: soc-camera: remove no longer needed struct members >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c >>> >>> 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in >>> soc-camera >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19 >>> >>> 04/30: soc-camera: fix multi-line comment coding style >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109 >>> >>> 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a >>> client fails >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb >>> >>> 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc >>> codes >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59 >>> >>> 07/30: soc-camera: add a private field to struct soc_camera_link >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132 >>> >>> 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c >>> >>> 09/30: soc-camera: switch drivers and platforms to use .priv in struct >>> soc_camera_link >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633 >>> >>> 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3 >>> >>> 11/30: tw9910: Add revision control >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3 >>> >>> 12/30: tw9910: simplify chip ID calculation >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84 >>> >>> 13/30: tw9910: Tri-state pins when idle >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0 >>> >>> 14/30: tw9910: Add power control >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f >>> >>> 15/30: tw9910: tw9910_set_hsync clean up >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121 >>> >>> 16/30: tw9910: Add revision control to tw9910_set_hsync >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679 >>> >>> 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame >>> formats >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a >>> >>> 18/30: soc-camera: convert to the new mediabus API >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b >>> >>> 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0 >>> >>> 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add >>> platform data >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c >>> >>> 21/30: mt9t031: make the use of the soc-camera client API optional >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8 >>> >>> 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1 >>> >>> 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490 >>> >>> 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b >>> >>> 25/30: tw9910: modify V/H outpit pin setting to use VALID >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942 >>> >>> 26/30: tw9910: modify output format >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1 >>> >>> 27/30: tw9910: remove cropping >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a >>> >>> 28/30: tw9910: Add sync polarity support >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0 >>> >>> 29/30: soc-camera: Add mt9t112 camera driver >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937 >>> >>> 30/30: sh_mobile_ceu_camera: Remove frame size page alignment >>> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f >>> >>> >>> a/linux/arch/sh/boards/board-ap325rxa.c| 606 -- >>> b/linux
Re: [PULL] soc-camera and mediabus
Hi All,
>> 3) it would be interesting to patch the other sensor drivers to be compatible
>>with soc_camera (mt9v011/ov7670);
>
> Well, this could be done, yes, but does it make sense to do this blindly
> without any hardware to test? I would rather add such conversions on a
> one-by-one basis as need arises.
>
I'm working on the ov7670. I've added the media bus stuff to what I've
previously posted but I haven't tested as yet. For reference, a quick and dirty
cut of the patch is below. Some thought is needed on how to deal with the
sections
that currently need to be different for the soc-camera and non soc camera uses.
(mainly the registration code in probe).
On another note, does anyone have an objection to making the set_bus_param
function optional? At the moment we are adding null functions for those
devices that can't actually change anything which seems a little pointless.
Jonathan
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..e57c3b5 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Jonathan Corbet ");
@@ -545,7 +546,7 @@ static struct ov7670_format_struct {
.bpp= 1
},
};
-#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
+
/*
@@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int
hstart, int hstop,
return ret;
}
+static enum v4l2_mbus_pixelcode ov7670_codes[] = {
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_RGB565_2X8_LE,
+};
-static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
+static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum
v4l2_mbus_pixelcode *code)
{
- struct ov7670_format_struct *ofmt;
-
- if (fmt->index >= N_OV7670_FMTS)
+ if (index >= ARRAY_SIZE(ov7670_codes))
return -EINVAL;
- ofmt = ov7670_formats + fmt->index;
- fmt->flags = 0;
- strcpy(fmt->description, ofmt->desc);
- fmt->pixelformat = ofmt->pixelformat;
+ *code = ov7670_codes[index];
return 0;
}
static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
- struct v4l2_format *fmt,
- struct ov7670_format_struct **ret_fmt,
- struct ov7670_win_size **ret_wsize)
+ struct v4l2_mbus_framefmt *mf,
+ struct ov7670_format_struct **ret_fmt,
+ struct ov7670_win_size **ret_wsize)
{
int index;
struct ov7670_win_size *wsize;
- struct v4l2_pix_format *pix = &fmt->fmt.pix;
- for (index = 0; index < N_OV7670_FMTS; index++)
- if (ov7670_formats[index].pixelformat == pix->pixelformat)
- break;
- if (index >= N_OV7670_FMTS) {
- /* default to first format */
- index = 0;
- pix->pixelformat = ov7670_formats[0].pixelformat;
- }
- if (ret_fmt != NULL)
- *ret_fmt = ov7670_formats + index;
- /*
-* Fields: the OV devices claim to be progressive.
-*/
- pix->field = V4L2_FIELD_NONE;
+ mf->field = V4L2_FIELD_NONE;
/*
* Round requested image size down to the nearest
* we support, but not below the smallest.
*/
for (wsize = ov7670_win_sizes; wsize < ov7670_win_sizes + N_WIN_SIZES;
wsize++)
- if (pix->width >= wsize->width && pix->height >= wsize->height)
+ if ( mf->width >= wsize->width && mf->height >= wsize->height)
break;
if (wsize >= ov7670_win_sizes + N_WIN_SIZES)
wsize--; /* Take the smallest one */
@@ -722,22 +708,34 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
/*
* Note the size we'll actually handle.
*/
- pix->width = wsize->width;
- pix->height = wsize->height;
- pix->bytesperline = pix->width*ov7670_formats[index].bpp;
- pix->sizeimage = pix->height*pix->bytesperline;
+ mf->width = wsize->width;
+ mf->height = wsize->height;
+ switch (mf->code) {
+ case V4L2_MBUS_FMT_RGB565_2X8_LE:
+ mf->colorspace = V4L2_COLORSPACE_SRGB;
+ if (ret_fmt != NULL)
+ *ret_fmt = ov7670_formats + 2;
+ break;
+ default:
+ mf->code = V4L2_MBUS_FMT_YUYV8_2X8;
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ mf->colorspace = V4L2_COLORSPACE_JPEG;
+ if (ret_fmt != NULL)
+ *ret_fmt = ov7670_formats;
+ break;
+ }
return 0;
}
-static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *fmt)
+static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt
*mf)
{
- return ov7670_try_fmt_internal(sd, fmt, N
Re: [PULL] soc-camera and mediabus
On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote: > Guennadi Liakhovetski wrote: > > Hi Mauro, > > > > At last soc-camera and mediabus lot for 2.6.33. Note, that one of this > > patches adds new fourcc codes. A patch for their documentation will be > > submitted immediately. > > > > Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb > > > > for the following 30 changesets: > > > > 01/30: tw9910: The driver can also handle revision 1 of the chip > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734 > > > > 02/30: soc-camera: remove no longer needed struct members > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c > > > > 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in > > soc-camera > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19 > > > > 04/30: soc-camera: fix multi-line comment coding style > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109 > > > > 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a > > client fails > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb > > > > 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc > > codes > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59 > > > > 07/30: soc-camera: add a private field to struct soc_camera_link > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132 > > > > 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c > > > > 09/30: soc-camera: switch drivers and platforms to use .priv in struct > > soc_camera_link > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633 > > > > 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3 > > > > 11/30: tw9910: Add revision control > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3 > > > > 12/30: tw9910: simplify chip ID calculation > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84 > > > > 13/30: tw9910: Tri-state pins when idle > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0 > > > > 14/30: tw9910: Add power control > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f > > > > 15/30: tw9910: tw9910_set_hsync clean up > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121 > > > > 16/30: tw9910: Add revision control to tw9910_set_hsync > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679 > > > > 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame > > formats > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a > > > > 18/30: soc-camera: convert to the new mediabus API > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b > > > > 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0 > > > > 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add > > platform data > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c > > > > 21/30: mt9t031: make the use of the soc-camera client API optional > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8 > > > > 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1 > > > > 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490 > > > > 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b > > > > 25/30: tw9910: modify V/H outpit pin setting to use VALID > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942 > > > > 26/30: tw9910: modify output format > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1 > > > > 27/30: tw9910: remove cropping > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a > > > > 28/30: tw9910: Add sync polarity support > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0 > > > > 29/30: soc-camera: Add mt9t112 camera driver > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937 > > > > 30/30: sh_mobile_ceu_camera: Remove frame size page alignment > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f > > > > > > a/linux/arch/sh/boards/board-ap325rxa.c| 606 -- > > b/linu
Re: [PULL] soc-camera and mediabus
Guennadi Liakhovetski wrote: > Hi Mauro, > > At last soc-camera and mediabus lot for 2.6.33. Note, that one of this > patches adds new fourcc codes. A patch for their documentation will be > submitted immediately. > > Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb > > for the following 30 changesets: > > 01/30: tw9910: The driver can also handle revision 1 of the chip > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734 > > 02/30: soc-camera: remove no longer needed struct members > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c > > 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in > soc-camera > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19 > > 04/30: soc-camera: fix multi-line comment coding style > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109 > > 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client > fails > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb > > 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc > codes > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59 > > 07/30: soc-camera: add a private field to struct soc_camera_link > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132 > > 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c > > 09/30: soc-camera: switch drivers and platforms to use .priv in struct > soc_camera_link > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633 > > 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3 > > 11/30: tw9910: Add revision control > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3 > > 12/30: tw9910: simplify chip ID calculation > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84 > > 13/30: tw9910: Tri-state pins when idle > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0 > > 14/30: tw9910: Add power control > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f > > 15/30: tw9910: tw9910_set_hsync clean up > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121 > > 16/30: tw9910: Add revision control to tw9910_set_hsync > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679 > > 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame > formats > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a > > 18/30: soc-camera: convert to the new mediabus API > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b > > 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0 > > 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add > platform data > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c > > 21/30: mt9t031: make the use of the soc-camera client API optional > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8 > > 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1 > > 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490 > > 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b > > 25/30: tw9910: modify V/H outpit pin setting to use VALID > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942 > > 26/30: tw9910: modify output format > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1 > > 27/30: tw9910: remove cropping > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a > > 28/30: tw9910: Add sync polarity support > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0 > > 29/30: soc-camera: Add mt9t112 camera driver > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937 > > 30/30: sh_mobile_ceu_camera: Remove frame size page alignment > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f > > > a/linux/arch/sh/boards/board-ap325rxa.c| 606 -- > b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt | 157 + > b/linux/arch/sh/boards/mach-ap325rxa/setup.c | 657 +++ > b/linux/arch/sh/boards/mach-kfr2r09/setup.c| 622 ++ > b/linux/drivers/media/video/mt9t112.c
