soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev
PATCH 1/1 soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev
From: Jonathan Cameron <[email protected]>
OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron
---
This is my first cut at a merge of the various ov7670 drivers to work with Guennadi Liakhovetski's work on moving soc-camera over to v4l2-subdev framework.
Thanks to Darius Augulis for many of the register settings, though a few sets marked as untested in his driver don't seem to work.
I'm not entirely happy with the mapping of various parameters onto the standard v4l controls and would greatly appreciate any suggestions about these.
There are still a lot of magic numbers in here but I've tried to identify the purposes of as many as possible.
At the moment I've deliberately kept it separate in naming etc from the in tree ov7670 driver as I don't want to go breaking that driver. Is there anyone out there who has the hardware and would consider doing the relevant board support code and testing?
All comments welcome.
drivers/media/video/Kconfig | 6 + drivers/media/video/Makefile | 1 + drivers/media/video/ov7670_soc.c | 1475 ++++++++++++++++++++++++++++++++++++++ include/media/ov7670_soc.h | 21 + 4 files changed, 1503 insertions(+), 0 deletions(-)
drivers/media/video/Kconfig +6 -0
@@ -746,6 +746,12 @@ config SOC_CAMERA_OV772X help This is a ov772x camera driver +config SOC_CAMERA_OV7670_SOC + tristate "ov7670 soc camera support" + depends on SOC_CAMERA && I2C + help + This is an ov7670 soc camera driver + config MX1_VIDEO bool
drivers/media/video/Makefile +1 -0
@@ -141,6 +141,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X) += ov772x.o +obj-$(CONFIG_SOC_CAMERA_OV7670_SOC) += ov7670_soc.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o obj-$(CONFIG_SOC_CAMERA_TW9910) += tw9910.o # soc-camera host drivers have to be linked after camera drivers
drivers/media/video/ov7670_soc.c new file +1475 -0
1,475 lines not on this page · raw message
include/media/ov7670_soc.h new file +21 -0
@@ -0,0 +1,21 @@ +/* ov7670_soc Camera +* +* Copyright (C) 2009 Jonathan Cameron <[email protected]> +* +* 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 __OV7670_SOC_H__ +#define __OV7670_SOC_H__ + +#include <media/soc_camera.h> + +struct ov7670_soc_camera_info { +int gpio_pwr; +int gpio_reset; +struct soc_camera_link link; +}; + +#endif
Quoted 4 lines · Jonathan Cameron
From: Jonathan Cameron <[email protected]>
OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron
Could you please, describe in more detail how you merged them?
However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there, convert it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one, and finally make it work with soc-camera. This way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Quoted 8 lines · Guennadi Liakhovetski
Quoted 4 lines · Jonathan Cameron
From: Jonathan Cameron <[email protected]>
OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron
Could you please, describe in more detail how you merged them?
Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything.
Note that a lot of what was in those drivers (usually labeled as untested) simply doesn't work and is based on 'magic' register sets provided by omnivision.
Quoted 3 lines
However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there,
That is more or less what I've done (it's based on Jonathan Corbet's driver). Darius' driver and mine have never been in mainline. Darius' was a complete rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the platform I'm using (principally because Omnivision are ignoring both myself and the board supplier).
Quoted 4 lines
convert
it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one,
That's the problem. The only mainlined driver is specifically for an OLPC machine. The driver is tied to specific i2c device and doesn't use anything anywhere near soc-camera or v4l2-subdev.
While it would be nice to get a single driver working
for this hardware as well as more conventional soc-camera devices, it isn't going to happen without a lot of input from someone with an olpc. The chip is interfaced through a Marvell 88alp101 'cafe' chip which does a whole host of random things alongside being video processor and taking a quick look at that would be written in a completely different fashion if it were done now (mfd with subdevices etc, v4l2-sudev)
So basically in the ideal world it would happen exactly as you've suggested, but I doubt it'll happen any time soon and in the meantime there is no in kernel support for those of us using the chip on other platforms.
*looks hopefully in the direction of Jonathan Corbet and other olpc owners*
Quoted 4 lines
and finally make it work with soc-camera. This
way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound?
Would be fine if the original driver (or anything terribly close to it) were useable on a platform I actually have without more or less being rewritten.
I can back track the driver to be as close to that as possible and still functional, but I'm not entirely sure it will make the code any easier to review and you'll loose a lot the functionality lifted from Darius' as my original drivers.
The original posting I made was as close as you can reasonably get to Jonathan's original driver.
http://patchwork.kernel.org/patch/12192/
At the time it wasn't really reviewed (beyond a few comments) as you were just commencing the soc-camera conversion and it made sense to wait for after that.
I'm not really sure how we should proceed with this. I'm particularly loath to touch the olpc driver unless we have a reasonable number of people willing to test.
Jonathan
Quoted 18 lines · Jonathan Cameron
Quoted 7 lines · Guennadi Liakhovetski
Quoted 4 lines · Jonathan Cameron
From: Jonathan Cameron <[email protected]>
OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron
Could you please, describe in more detail how you merged them?
Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything.
Note that a lot of what was in those drivers (usually labeled as untested) simply doesn't work and is based on 'magic' register sets provided by omnivision.
Quoted 3 lines
However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there,
Quoted 6 lines
That is more or less what I've done (it's based on Jonathan Corbet's driver). Darius' driver and mine have never been in mainline. Darius' was a complete rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the platform I'm using (principally because Omnivision are ignoring both myself and the board supplier).
It's very difficult to write 'normal' driver for it.
Omnivision does not provide useful documentation,
only long constant arrays with few strange comments.
Beside documentation is poor, there are lot of errors in register description.
Many things are mistery, not documented and seems Omnivision does not have such documentation.
I thing this sensor isn't perfect for embedded projects. It's 'designed' for webcams, where reliability and quality are not needed. With ov7720 similar situation...
Quoted 50 lines
Quoted 5 lines
convert
it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one,That's the problem. The only mainlined driver is specifically for an OLPC machine. The driver is tied to specific i2c device and doesn't use anything anywhere near soc-camera or v4l2-subdev.
While it would be nice to get a single driver working
for this hardware as well as more conventional soc-camera devices, it isn't going to happen without a lot of input from someone with an olpc. The chip is interfaced through a Marvell 88alp101 'cafe' chip which does a whole host of random things alongside being video processor and taking a quick look at that would be written in a completely different fashion if it were done now (mfd with subdevices etc, v4l2-sudev)So basically in the ideal world it would happen exactly as you've suggested, but I doubt it'll happen any time soon and in the meantime there is no in kernel support for those of us using the chip on other platforms.
*looks hopefully in the direction of Jonathan Corbet and other olpc owners*
Quoted 4 lines
and finally make it work with soc-camera. This
way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound?Would be fine if the original driver (or anything terribly close to it) were useable on a platform I actually have without more or less being rewritten.
I can back track the driver to be as close to that as possible and still functional, but I'm not entirely sure it will make the code any easier to review and you'll loose a lot the functionality lifted from Darius' as my original drivers.
The original posting I made was as close as you can reasonably get to Jonathan's original driver.
http://patchwork.kernel.org/patch/12192/
At the time it wasn't really reviewed (beyond a few comments) as you were just commencing the soc-camera conversion and it made sense to wait for after that.
I'm not really sure how we should proceed with this. I'm particularly loath to touch the olpc driver unless we have a reasonable number of people willing to test.
Jonathan
Quoted 31 lines · Darius Augulis
Quoted 19 lines · Jonathan Cameron
Quoted 7 lines · Guennadi Liakhovetski
Quoted 4 lines · Jonathan Cameron
From: Jonathan Cameron <[email protected]>
OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron
Could you please, describe in more detail how you merged them?
Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything.
Note that a lot of what was in those drivers (usually labeled as untested)
simply doesn't work and is based on 'magic' register sets provided by omnivision.Quoted 3 lines
However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there,
Quoted 10 lines
That is more or less what I've done (it's based on Jonathan Corbet's driver).
Darius' driver and mine have never been in mainline. Darius' was a complete
rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the
platform I'm using (principally because Omnivision are ignoring both myself
and the board supplier).
Quoted 10 lines
It's very difficult to write 'normal' driver for it. Omnivision does not provide useful documentation,
only long constant arrays with few strange comments.
Beside documentation is poor, there are lot of errors in register description.
Many things are mistery, not documented and seems Omnivision does not have such documentation.
I thing this sensor isn't perfect for embedded projects. It's 'designed' for webcams, where reliability and quality are not needed. With ov7720 similar situation...
Agreed. Though random discussions with others suggest lots of these chips turn up in things like pedestrian avoidance systems in cars and similar. (not generally running linux and tend to have fairly fixed settings I guess).
Jonathan
Quoted 27 lines · On Tuesday 16 June 2009 16:45:04 Jonathan Cameron wrote:
Quoted 7 lines · Guennadi Liakhovetski
Quoted 4 lines · Jonathan Cameron
From: Jonathan Cameron <[email protected]>
OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron
Could you please, describe in more detail how you merged them?
Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything.
Note that a lot of what was in those drivers (usually labeled as untested) simply doesn't work and is based on 'magic' register sets provided by omnivision.
Quoted 3 lines
However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there,
That is more or less what I've done (it's based on Jonathan Corbet's driver). Darius' driver and mine have never been in mainline. Darius' was a complete rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the platform I'm using (principally because Omnivision are ignoring both myself and the board supplier).
Quoted 8 lines
Quoted 4 lines
convert
it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one,That's the problem. The only mainlined driver is specifically for an OLPC machine. The driver is tied to specific i2c device and doesn't use anything anywhere near soc-camera or v4l2-subdev.
Yes, it does. ov7670.c was converted to v4l2-subdev in 2.6.30.
Quoted 8 lines
While it would be nice to get a single driver working
for this hardware as well as more conventional soc-camera devices, it isn't going to happen without a lot of input from someone with an olpc. The chip is interfaced through a Marvell 88alp101 'cafe' chip which does a whole host of random things alongside being video processor and taking a quick look at that would be written in a completely different fashion if it were done now (mfd with subdevices etc, v4l2-sudev)
Quoted 7 lines
So basically in the ideal world it would happen exactly as you've suggested, but I doubt it'll happen any time soon and in the meantime there is no in kernel support for those of us using the chip on other platforms.
*looks hopefully in the direction of Jonathan Corbet and other olpc owners*
I have an olpc, but I still haven't had the time to setup a proper test environment on it. However, I managed to clear my backlog of reviews in the past few days so hopefully I can find some time this weekend to set it up.
Quoted 19 lines
Quoted 4 lines
and finally make it work with soc-camera. This
way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound?Would be fine if the original driver (or anything terribly close to it) were useable on a platform I actually have without more or less being rewritten.
I can back track the driver to be as close to that as possible and still functional, but I'm not entirely sure it will make the code any easier to review and you'll loose a lot the functionality lifted from Darius' as my original drivers.
The original posting I made was as close as you can reasonably get to Jonathan's original driver.
Quoted 7 lines
At the time it wasn't really reviewed (beyond a few comments) as you were just commencing the soc-camera conversion and it made sense to wait for after that.
I'm not really sure how we should proceed with this. I'm particularly loath to touch the olpc driver unless we have a reasonable number of people willing to test.
The current ov7670.c driver in the 2.6.30 tree (and the v4l-dvb repository) is already v4l2_subdev based and should be reusable in other platforms, including soc-camera once that has also been converted to use v4l2_subdev.
Regards,
Hans
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Quoted 29 lines · Hans Verkuil
Quoted 28 lines · On Tuesday 16 June 2009 16:45:04 Jonathan Cameron wrote:
Quoted 6 lines · Guennadi Liakhovetski
Quoted 4 lines · Jonathan Cameron
From: Jonathan Cameron <[email protected]>
OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron
Could you please, describe in more detail how you merged them?
Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything.
Note that a lot of what was in those drivers (usually labeled as untested) simply doesn't work and is based on 'magic' register sets provided by omnivision.
Quoted 3 lines
However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there,
That is more or less what I've done (it's based on Jonathan Corbet's driver). Darius' driver and mine have never been in mainline. Darius' was a complete rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the platform I'm using (principally because Omnivision are ignoring both myself and the board supplier).
Quoted 4 lines
convert
it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one,
Quoted 5 lines
Quoted 3 lines
That's the problem. The only mainlined driver is specifically for an OLPC machine. The driver is tied to specific i2c device and doesn't use anything anywhere near soc-camera or v4l2-subdev.
Yes, it does.
ov7670.cwas converted to v4l2-subdev in 2.6.30.
Ah! thanks for the heads up on that.
Some how I missed that entirely.
Quoted 14 lines
Quoted 14 lines
While it would be nice to get a single driver working
for this hardware as well as more conventional soc-camera devices, it isn't going to happen without a lot of input from someone with an olpc. The chip is interfaced through a Marvell 88alp101 'cafe' chip which does a whole host of random things alongside being video processor and taking a quick look at that would be written in a completely different fashion if it were done now (mfd with subdevices etc, v4l2-sudev)So basically in the ideal world it would happen exactly as you've suggested, but I doubt it'll happen any time soon and in the meantime there is no in kernel support for those of us using the chip on other platforms.
Quoted 6 lines
Quoted 2 lines
*looks hopefully in the direction of Jonathan Corbet and other olpc owners*
I have an olpc, but I still haven't had the time to setup a proper test environment on it. However, I managed to clear my backlog of reviews in the past few days so hopefully I can find some time this weekend to set it up.
Cool.
Quoted 23 lines
Quoted 23 lines
Quoted 5 lines
and finally make it work with soc-camera. This
way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound?Would be fine if the original driver (or anything terribly close to it) were useable on a platform I actually have without more or less being rewritten.
I can back track the driver to be as close to that as possible and still functional, but I'm not entirely sure it will make the code any easier to review and you'll loose a lot the functionality lifted from Darius' as my original drivers.
The original posting I made was as close as you can reasonably get to Jonathan's original driver.
http://patchwork.kernel.org/patch/12192/
At the time it wasn't really reviewed (beyond a few comments) as you were just commencing the soc-camera conversion and it made sense to wait for after that.
Quoted 7 lines
Quoted 3 lines
I'm not really sure how we should proceed with this. I'm particularly loath to touch the olpc driver unless we have a reasonable number of people willing to test.
The current
ov7670.cdriver in the 2.6.30 tree (and the v4l-dvb repository) is alreadyv4l2_subdevbased and should be reusable in other platforms, including soc-camera once that has also been converted to usev4l2_subdev.
Excellent, I'll look at moving the functionality patches based on this driver and Darius' on to that then. Sorry for repeating some of your work, I somehow completely forgot your original email saying this was on it's way!
Jonathan