Re: Using OV5642 sensor driver for CM8206-A500SA-E
Hi Anatolij, if I remember correctly I had the same issue inverted. For me the initialization sequence of the freescale driver didn't work. Generally it was quite difficult to deduce anything from the docs to split the initialization into sensible parts. Too many parts were undocumented or didn't work as expected. Maybe there are different hardware revisions out there that need a different register setup. Unfortunately I can only give you some general notes here as I no longer possess an OV5642. Good luck, Bastian 2012/11/6 Anatolij Gustschin ag...@denx.de Hi, I'm trying to use mainline ov5642 driver for ov5642 based camera module CM8206-A500SA-E from TRULY. The driver loads and initializes the sensor, but the initialization seems to be incomplete, the sensor doesn't generate pixel clock and sync signals. For a quick test I've replaced the default initialisation sequences from ov5642_default_regs_init[] and ov5642_default_regs_finalise[] with an init sequence in ov5642_setting_30fps_720P_1280_720[] taken from Freescale ov5642 driver [1] and commented out ov5642_set_resolution() in ov5642_s_power(). With these changes to the mainline driver the sensor starts clocking out pixels and I receive 1280x720 image. Is anyone using the mainline ov5642 driver for mentioned TRULY camera module? Just wanted to ask before digging further to find out what changes to the mainline driver are really needed to make it working with TRULY camera module. Thanks, Anatolij [1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/plain/drivers/media/video/mxc/capture/ov5642.c?h=imx_3.0.15 -- 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] media: Add camera controls for the ov5642 driver
Hello Sakari!
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
Hi Bastian,
On Mon, Sep 05, 2011 at 09:32:55AM +, Bastian Hecht wrote:
2011/9/1 Sakari Ailus sakari.ai...@iki.fi:
On Thu, Sep 01, 2011 at 11:14:08AM +0200, Sylwester Nawrocki wrote:
Hi Sakari,
On 09/01/2011 10:47 AM, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote:
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
[clip]
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled
V4L2_CID_PRIVATE_BASE deprecated and read
Documentation/feature-removal-schedule.txt. I couldn't find anything.
Hmm. Did you happen to check when that has been written? :)
Please use this one instead:
URL:http://hverkuil.home.xs4all.nl/spec/media.html
Drivers can also implement their own custom controls using
V4L2_CID_PRIVATE_BASE and higher values.
Which specific location describes V4L2_CID_PRIVATE_BASE differently
there?
That was a general comment, not related to the private base. There's no
use for a three-year-old spec as a reference!
The control framework does not support private controls, for example.
The
controls should be put to their own class in videodev2.h nowadays,
that's my
understanding. Cc Hans.
Is this really the case that we close the door for private controls in
the mainline kernel ? Or am I misunderstanding something ?
How about v4l2_ctrl_new_custom() ?
What if there are controls applicable to single driver only ?
Do we really want to have plenty of such in videodev2.h ?
We have some of those already in videodev2.h. I'm not certain if I'm happy
with this myself, considering e.g. that we could get a few truckloads of
only camera lens hardware specific controls in the near future.
So in my case (as these are controls that might be used by others too)
I should add something like
#define V4L2_CID_BLUE_SATURATION (V4L2_CID_CAMERA_CLASS_BASE+19)
#define V4L2_CID_RED_SATURATION (V4L2_CID_CAMERA_CLASS_BASE+20)
What do these two controls do? Do they control gain or something else?
Hmm. Maybe I named them a bit unsharp. It is the U Saturation and V
Saturation. To me it looks like turning up the saturation in HSV
space, but only for either the blue or the red channel. This would
correspond to V4L2_CID_{RED,BLUE}_BALANCE when I read the docs. They
say it is {Red,Blue} chroma balance.
I have other controls for that I used V4L2_CID_{RED,BLUE}_BALANCE.
These are gains. So in fact I should swap them in my code and the
remaining question is, how to name the red and blue gain controls.
#define V4L2_CID_GRAY_SCALE_IMAGE (V4L2_CID_CAMERA_CLASS_BASE+21)
V4L2_CID_COLOR_KILLER looks like something which would fit for the purpose.
Oh great! So I just take this.
#define V4L2_CID_SOLARIZE_EFFECT (V4L2_CID_CAMERA_CLASS_BASE+22)
Sounds interesting for a sensor. I wonder if this would fall under a menu
control, V4L2_CID_COLORFX.
When I read the the possible enums for V4L2_CID_COLORFX, it indeed
sounds very much like my solarize effect should be added there too. I
found V4L2_COLORFX_BW there, too. Isn't that a duplicate of the color
killer control then?
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
Thanks for your help,
Bastian
--
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] media: Add camera controls for the ov5642 driver
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
On Tue, Sep 06, 2011 at 07:56:40AM +, Bastian Hecht wrote:
Hello Sakari!
Hi Bastian,
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
Hi Bastian,
On Mon, Sep 05, 2011 at 09:32:55AM +, Bastian Hecht wrote:
2011/9/1 Sakari Ailus sakari.ai...@iki.fi:
On Thu, Sep 01, 2011 at 11:14:08AM +0200, Sylwester Nawrocki wrote:
Hi Sakari,
On 09/01/2011 10:47 AM, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi Liakhovetski
wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote:
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
[clip]
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled
V4L2_CID_PRIVATE_BASE deprecated and read
Documentation/feature-removal-schedule.txt. I couldn't find
anything.
Hmm. Did you happen to check when that has been written? :)
Please use this one instead:
URL:http://hverkuil.home.xs4all.nl/spec/media.html
Drivers can also implement their own custom controls using
V4L2_CID_PRIVATE_BASE and higher values.
Which specific location describes V4L2_CID_PRIVATE_BASE differently
there?
That was a general comment, not related to the private base. There's
no
use for a three-year-old spec as a reference!
The control framework does not support private controls, for
example. The
controls should be put to their own class in videodev2.h nowadays,
that's my
understanding. Cc Hans.
Is this really the case that we close the door for private controls in
the mainline kernel ? Or am I misunderstanding something ?
How about v4l2_ctrl_new_custom() ?
What if there are controls applicable to single driver only ?
Do we really want to have plenty of such in videodev2.h ?
We have some of those already in videodev2.h. I'm not certain if I'm
happy
with this myself, considering e.g. that we could get a few truckloads of
only camera lens hardware specific controls in the near future.
So in my case (as these are controls that might be used by others too)
I should add something like
#define V4L2_CID_BLUE_SATURATION
(V4L2_CID_CAMERA_CLASS_BASE+19)
#define V4L2_CID_RED_SATURATION
(V4L2_CID_CAMERA_CLASS_BASE+20)
What do these two controls do? Do they control gain or something else?
Hmm. Maybe I named them a bit unsharp. It is the U Saturation and V
Saturation. To me it looks like turning up the saturation in HSV
space, but only for either the blue or the red channel. This would
correspond to V4L2_CID_{RED,BLUE}_BALANCE when I read the docs. They
say it is {Red,Blue} chroma balance.
I have other controls for that I used V4L2_CID_{RED,BLUE}_BALANCE.
These are gains. So in fact I should swap them in my code and the
remaining question is, how to name the red and blue gain controls.
I think Laurent had a similar issue in his Aptina sensor driver. In my
opinion we need a class for low level controls such as the gain ones. Do I
understand correctly they control the red and blue pixel gain in the sensor
pixel matrix? Do you also have gain controls for the two greens?
Yes, I assume that this is done there. Either in the analog circuit by
decreasing the preload or digitally then. Don't know exactly. There
are registers for the green pixels as well. As I used the
V4L2_CID_{RED,BLUE}_BALANCE controls and there was no
V4L2_CID_GREEN_BALANCE, I just skipped green as one can
increase/decrease the global gain and get an arbitrary mix as well.
So for these gain settings we should add these?
V4L2_CID_RED_GAIN
V4L2_CID_BLUE_GAIN
V4L2_CID_GREEN_GAIN
#define V4L2_CID_GRAY_SCALE_IMAGE
(V4L2_CID_CAMERA_CLASS_BASE+21)
V4L2_CID_COLOR_KILLER looks like something which would fit for the purpose.
Oh great! So I just take this.
#define V4L2_CID_SOLARIZE_EFFECT
(V4L2_CID_CAMERA_CLASS_BASE+22)
Sounds interesting for a sensor. I wonder if this would fall under a menu
control, V4L2_CID_COLORFX.
When I read the the possible enums for V4L2_CID_COLORFX, it indeed
sounds very much like my solarize effect should be added there too. I
found V4L2_COLORFX_BW there, too. Isn't that a duplicate of the color
killer control then?
In my opinion V4L2_CID_COLORFX should never be implemented in drivers for
which the hardware doesn't implement these effects in a non-parametrisable
way. This control was originally added for the OMAP 3 ISP driver but the
driver never implemented it.
Your triple negation (never, doesn't, non-) is quite tricky xD
If I get it right, you say that one should not use V4L2_CID_COLORFX
for hardware with parametrisable effects.
My BW and Solarize effects are non-parametrisable and they can be
turned on together (which makes
[PATCH 1/2 v4] media: Add support for arbitrary resolution for the ov5642 camera driver
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..3d7038c 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
* published by the Free Software Foundation.
*/
+#include linux/bitops.h
#include linux/delay.h
#include linux/i2c.h
+#include linux/kernel.h
#include linux/slab.h
#include linux/videodev2.h
@@ -34,7 +36,7 @@
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH 0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW 0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW 0x3809
@@ -44,19 +46,44 @@
#define REG_OUT_TOTAL_WIDTH_LOW0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_OUTPUT_FORMAT 0x4300
+#define REG_ISP_CTRL_010x5001
+#define REG_AVG_WINDOW_END_X_HIGH 0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could make
+ * the chip work the intended way. As it works with predefined register lists,
+ * some undocumented registers are presumably changed there to achieve their
+ * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
*/
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT 720
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT 720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT 20
+
+/*
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
+ */
+#define BLANKING_MIN_HEIGHT1000
struct regval_list {
u16 reg_num;
@@ -581,6 +608,11 @@ struct ov5642_datafmt {
struct ov5642 {
struct v4l2_subdev subdev;
const struct ov5642_datafmt *fmt;
+ struct v4l2_rectcrop_rect;
+
+ /* blanking information */
+ int total_width;
+ int total_height;
};
static const struct ov5642_datafmt ov5642_colour_fmts[] = {
@@ -641,6 +673,21 @@ static int reg_write(struct i2c_client *client, u16 reg,
u8 val)
return 0;
}
+
+/*
+ * convenience function to write 16 bit register values that are split up
+ * into two consecutive high and low parts
+ */
+static int reg_write16(struct i2c_client *client, u16 reg, u16 val16)
+{
+ int ret;
+
+ ret = reg_write(client, reg, val16 8);
+ if (ret)
+ return ret;
+ return reg_write(client, reg + 1, val16 0x00ff);
+}
+
#ifdef CONFIG_VIDEO_ADV_DEBUG
static int ov5642_get_register(struct v4l2_subdev *sd, struct
v4l2_dbg_register *reg)
{
@@ -684,58 +731,55 @@ static int ov5642_write_array(struct i2c_client *client,
return 0;
}
-static int ov5642_set_resolution(struct i2c_client *client)
+static int ov5642_set_resolution(struct v4l2_subdev *sd)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ int width = priv-crop_rect.width;
+ int height = priv-crop_rect.height;
+ int total_width = priv-total_width;
+ int total_height = priv-total_height;
+ int start_x = (OV5642_SENSOR_SIZE_X - width) / 2;
+ int start_y = (OV5642_SENSOR_SIZE_Y - height) / 2;
int ret;
- u8 start_x_high = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 8;
- u8 start_x_low = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 0xff;
- u8 start_y_high = ((OV5642_SENSOR_SIZE_Y - OV5642_HEIGHT) / 2) 8;
- u8 start_y_low = ((OV5642_SENSOR_SIZE_Y - OV5642_HEIGHT) / 2) 0xff;
-
- u8 width_high =
Re: [PATCH 1/2 v4] media: Add support for arbitrary resolution for the ov5642 camera driver
I forgot the sign-off and just discovered checkpatch errors. I'll
repost the fixed version. Sorry for spam.
2011/9/6 Bastian Hecht hec...@googlemail.com:
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..3d7038c 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
* published by the Free Software Foundation.
*/
+#include linux/bitops.h
#include linux/delay.h
#include linux/i2c.h
+#include linux/kernel.h
#include linux/slab.h
#include linux/videodev2.h
@@ -34,7 +36,7 @@
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH 0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW 0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW 0x3809
@@ -44,19 +46,44 @@
#define REG_OUT_TOTAL_WIDTH_LOW 0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_OUTPUT_FORMAT 0x4300
+#define REG_ISP_CTRL_01 0x5001
+#define REG_AVG_WINDOW_END_X_HIGH 0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could make
+ * the chip work the intended way. As it works with predefined register
lists,
+ * some undocumented registers are presumably changed there to achieve their
+ * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
*/
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT 720
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT 720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT 2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT 20
+
+/*
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
+ */
+#define BLANKING_MIN_HEIGHT 1000
struct regval_list {
u16 reg_num;
@@ -581,6 +608,11 @@ struct ov5642_datafmt {
struct ov5642 {
struct v4l2_subdev subdev;
const struct ov5642_datafmt *fmt;
+ struct v4l2_rect crop_rect;
+
+ /* blanking information */
+ int total_width;
+ int total_height;
};
static const struct ov5642_datafmt ov5642_colour_fmts[] = {
@@ -641,6 +673,21 @@ static int reg_write(struct i2c_client *client, u16 reg,
u8 val)
return 0;
}
+
+/*
+ * convenience function to write 16 bit register values that are split up
+ * into two consecutive high and low parts
+ */
+static int reg_write16(struct i2c_client *client, u16 reg, u16 val16)
+{
+ int ret;
+
+ ret = reg_write(client, reg, val16 8);
+ if (ret)
+ return ret;
+ return reg_write(client, reg + 1, val16 0x00ff);
+}
+
#ifdef CONFIG_VIDEO_ADV_DEBUG
static int ov5642_get_register(struct v4l2_subdev *sd, struct
v4l2_dbg_register *reg)
{
@@ -684,58 +731,55 @@ static int ov5642_write_array(struct i2c_client *client,
return 0;
}
-static int ov5642_set_resolution(struct i2c_client *client)
+static int ov5642_set_resolution(struct v4l2_subdev *sd)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ int width = priv-crop_rect.width;
+ int height = priv-crop_rect.height;
+ int total_width = priv-total_width;
+ int total_height = priv-total_height;
+ int start_x = (OV5642_SENSOR_SIZE_X - width) / 2;
+ int start_y = (OV5642_SENSOR_SIZE_Y - height) / 2;
int ret;
- u8 start_x_high = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 8
[PATCH 1/2 v5] media: Add support for arbitrary resolution
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..e52fdb1 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
* published by the Free Software Foundation.
*/
+#include linux/bitops.h
#include linux/delay.h
#include linux/i2c.h
+#include linux/kernel.h
#include linux/slab.h
#include linux/videodev2.h
@@ -34,7 +36,7 @@
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH 0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW 0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW 0x3809
@@ -44,19 +46,44 @@
#define REG_OUT_TOTAL_WIDTH_LOW0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_OUTPUT_FORMAT 0x4300
+#define REG_ISP_CTRL_010x5001
+#define REG_AVG_WINDOW_END_X_HIGH 0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could make
+ * the chip work the intended way. As it works with predefined register lists,
+ * some undocumented registers are presumably changed there to achieve their
+ * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
*/
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT 720
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT 720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT 20
+
+/*
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
+ */
+#define BLANKING_MIN_HEIGHT1000
struct regval_list {
u16 reg_num;
@@ -581,6 +608,11 @@ struct ov5642_datafmt {
struct ov5642 {
struct v4l2_subdev subdev;
const struct ov5642_datafmt *fmt;
+ struct v4l2_rectcrop_rect;
+
+ /* blanking information */
+ int total_width;
+ int total_height;
};
static const struct ov5642_datafmt ov5642_colour_fmts[] = {
@@ -641,6 +673,21 @@ static int reg_write(struct i2c_client *client, u16 reg,
u8 val)
return 0;
}
+
+/*
+ * convenience function to write 16 bit register values that are split up
+ * into two consecutive high and low parts
+ */
+static int reg_write16(struct i2c_client *client, u16 reg, u16 val16)
+{
+ int ret;
+
+ ret = reg_write(client, reg, val16 8);
+ if (ret)
+ return ret;
+ return reg_write(client, reg + 1, val16 0x00ff);
+}
+
#ifdef CONFIG_VIDEO_ADV_DEBUG
static int ov5642_get_register(struct v4l2_subdev *sd, struct
v4l2_dbg_register *reg)
{
@@ -684,58 +731,55 @@ static int ov5642_write_array(struct i2c_client *client,
return 0;
}
-static int ov5642_set_resolution(struct i2c_client *client)
+static int ov5642_set_resolution(struct v4l2_subdev *sd)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ int width = priv-crop_rect.width;
+ int height = priv-crop_rect.height;
+ int total_width = priv-total_width;
+ int total_height = priv-total_height;
+ int start_x = (OV5642_SENSOR_SIZE_X - width) / 2;
+ int start_y = (OV5642_SENSOR_SIZE_Y - height) / 2;
int ret;
- u8 start_x_high = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 8;
- u8 start_x_low = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 0xff;
- u8 start_y_high = ((OV5642_SENSOR_SIZE_Y - OV5642_HEIGHT) / 2) 8;
- u8 start_y_low = ((OV5642_SENSOR_SIZE_Y - OV5642_HEIGHT) / 2
Re: [PATCH] media: Add camera controls for the ov5642 driver
Hello Sakari,
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
On Tue, Sep 06, 2011 at 09:01:15AM +, Bastian Hecht wrote:
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
On Tue, Sep 06, 2011 at 07:56:40AM +, Bastian Hecht wrote:
Hello Sakari!
Hi Bastian,
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
Hi Bastian,
On Mon, Sep 05, 2011 at 09:32:55AM +, Bastian Hecht wrote:
2011/9/1 Sakari Ailus sakari.ai...@iki.fi:
On Thu, Sep 01, 2011 at 11:14:08AM +0200, Sylwester Nawrocki wrote:
Hi Sakari,
On 09/01/2011 10:47 AM, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi Liakhovetski
wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote:
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
[clip]
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled
V4L2_CID_PRIVATE_BASE deprecated and read
Documentation/feature-removal-schedule.txt. I couldn't find
anything.
Hmm. Did you happen to check when that has been written? :)
Please use this one instead:
URL:http://hverkuil.home.xs4all.nl/spec/media.html
Drivers can also implement their own custom controls using
V4L2_CID_PRIVATE_BASE and higher values.
Which specific location describes V4L2_CID_PRIVATE_BASE
differently there?
That was a general comment, not related to the private base.
There's no
use for a three-year-old spec as a reference!
The control framework does not support private controls, for
example. The
controls should be put to their own class in videodev2.h
nowadays, that's my
understanding. Cc Hans.
Is this really the case that we close the door for private controls
in
the mainline kernel ? Or am I misunderstanding something ?
How about v4l2_ctrl_new_custom() ?
What if there are controls applicable to single driver only ?
Do we really want to have plenty of such in videodev2.h ?
We have some of those already in videodev2.h. I'm not certain if I'm
happy
with this myself, considering e.g. that we could get a few
truckloads of
only camera lens hardware specific controls in the near future.
So in my case (as these are controls that might be used by others too)
I should add something like
#define V4L2_CID_BLUE_SATURATION
(V4L2_CID_CAMERA_CLASS_BASE+19)
#define V4L2_CID_RED_SATURATION
(V4L2_CID_CAMERA_CLASS_BASE+20)
What do these two controls do? Do they control gain or something else?
Hmm. Maybe I named them a bit unsharp. It is the U Saturation and V
Saturation. To me it looks like turning up the saturation in HSV
space, but only for either the blue or the red channel. This would
correspond to V4L2_CID_{RED,BLUE}_BALANCE when I read the docs. They
say it is {Red,Blue} chroma balance.
I have other controls for that I used V4L2_CID_{RED,BLUE}_BALANCE.
These are gains. So in fact I should swap them in my code and the
remaining question is, how to name the red and blue gain controls.
I think Laurent had a similar issue in his Aptina sensor driver. In my
opinion we need a class for low level controls such as the gain ones. Do I
understand correctly they control the red and blue pixel gain in the sensor
pixel matrix? Do you also have gain controls for the two greens?
Yes, I assume that this is done there. Either in the analog circuit by
decreasing the preload or digitally then. Don't know exactly. There
are registers for the green pixels as well. As I used the
V4L2_CID_{RED,BLUE}_BALANCE controls and there was no
V4L2_CID_GREEN_BALANCE, I just skipped green as one can
increase/decrease the global gain and get an arbitrary mix as well.
So for these gain settings we should add these?
V4L2_CID_RED_GAIN
V4L2_CID_BLUE_GAIN
V4L2_CID_GREEN_GAIN
Do you have two or just one green gains? In all sensors I've seen there are
two.
No, here is only one.
I think I could send an RFC on this to the list and cc you and Laurent.
Ok fine, thanks! But hmmm - what do I do with my driver in the
meantime actually? Stall the upstream process or remove my controls
temporarily - or is there a better way?
#define V4L2_CID_GRAY_SCALE_IMAGE
(V4L2_CID_CAMERA_CLASS_BASE+21)
V4L2_CID_COLOR_KILLER looks like something which would fit for the
purpose.
Oh great! So I just take this.
#define V4L2_CID_SOLARIZE_EFFECT
(V4L2_CID_CAMERA_CLASS_BASE+22)
Sounds interesting for a sensor. I wonder if this would fall under a
menu
control, V4L2_CID_COLORFX.
When I read the the possible enums for V4L2_CID_COLORFX, it indeed
sounds very much like my solarize effect should be added there too. I
found
Re: [PATCH] media: Add camera controls for the ov5642 driver
Hello Sakari,
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
On Tue, Sep 06, 2011 at 09:35:24AM +, Bastian Hecht wrote:
Hello Sakari,
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
On Tue, Sep 06, 2011 at 09:01:15AM +, Bastian Hecht wrote:
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
On Tue, Sep 06, 2011 at 07:56:40AM +, Bastian Hecht wrote:
Hello Sakari!
Hi Bastian,
2011/9/6 Sakari Ailus sakari.ai...@iki.fi:
Hi Bastian,
On Mon, Sep 05, 2011 at 09:32:55AM +, Bastian Hecht wrote:
2011/9/1 Sakari Ailus sakari.ai...@iki.fi:
On Thu, Sep 01, 2011 at 11:14:08AM +0200, Sylwester Nawrocki
wrote:
Hi Sakari,
On 09/01/2011 10:47 AM, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi
Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht
wrote:
2011/8/28 Laurent Pinchart
laurent.pinch...@ideasonboard.com:
[clip]
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
I checked at http://v4l2spec.bytesex.org/spec/x542.htm,
googled
V4L2_CID_PRIVATE_BASE deprecated and read
Documentation/feature-removal-schedule.txt. I couldn't find
anything.
Hmm. Did you happen to check when that has been written? :)
Please use this one instead:
URL:http://hverkuil.home.xs4all.nl/spec/media.html
Drivers can also implement their own custom controls using
V4L2_CID_PRIVATE_BASE and higher values.
Which specific location describes V4L2_CID_PRIVATE_BASE
differently there?
That was a general comment, not related to the private base.
There's no
use for a three-year-old spec as a reference!
The control framework does not support private controls, for
example. The
controls should be put to their own class in videodev2.h
nowadays, that's my
understanding. Cc Hans.
Is this really the case that we close the door for private
controls in
the mainline kernel ? Or am I misunderstanding something ?
How about v4l2_ctrl_new_custom() ?
What if there are controls applicable to single driver only ?
Do we really want to have plenty of such in videodev2.h ?
We have some of those already in videodev2.h. I'm not certain if
I'm happy
with this myself, considering e.g. that we could get a few
truckloads of
only camera lens hardware specific controls in the near future.
So in my case (as these are controls that might be used by others
too)
I should add something like
#define V4L2_CID_BLUE_SATURATION
(V4L2_CID_CAMERA_CLASS_BASE+19)
#define V4L2_CID_RED_SATURATION
(V4L2_CID_CAMERA_CLASS_BASE+20)
What do these two controls do? Do they control gain or something
else?
Hmm. Maybe I named them a bit unsharp. It is the U Saturation and V
Saturation. To me it looks like turning up the saturation in HSV
space, but only for either the blue or the red channel. This would
correspond to V4L2_CID_{RED,BLUE}_BALANCE when I read the docs. They
say it is {Red,Blue} chroma balance.
I have other controls for that I used V4L2_CID_{RED,BLUE}_BALANCE.
These are gains. So in fact I should swap them in my code and the
remaining question is, how to name the red and blue gain controls.
I think Laurent had a similar issue in his Aptina sensor driver. In my
opinion we need a class for low level controls such as the gain ones.
Do I
understand correctly they control the red and blue pixel gain in the
sensor
pixel matrix? Do you also have gain controls for the two greens?
Yes, I assume that this is done there. Either in the analog circuit by
decreasing the preload or digitally then. Don't know exactly. There
are registers for the green pixels as well. As I used the
V4L2_CID_{RED,BLUE}_BALANCE controls and there was no
V4L2_CID_GREEN_BALANCE, I just skipped green as one can
increase/decrease the global gain and get an arbitrary mix as well.
So for these gain settings we should add these?
V4L2_CID_RED_GAIN
V4L2_CID_BLUE_GAIN
V4L2_CID_GREEN_GAIN
Do you have two or just one green gains? In all sensors I've seen there are
two.
No, here is only one.
It is a raw bayer sensor, isn't it?
I think I could send an RFC on this to the list and cc you and Laurent.
Ok fine, thanks! But hmmm - what do I do with my driver in the
meantime actually? Stall the upstream process or remove my controls
temporarily - or is there a better way?
It is also possible to expose these controls just for this sensor, but I
would wait a little bit if that's okay for you. Your sensor driver isn't the
only one depending on these new controls --- Laurent also has one.
I don't think this should take
[PATCH/RFC] media: Add camera controls for the ov5642 driver
The driver now supports automatic/manual gain, automatic/manual white
balance, automatic/manual exposure control, vertical flip, brightness
control, contrast control and saturation control. Additionally the
following effects are available now: rotating the hue in the colorspace,
gray scale image and solarize effect.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
INCOMPLETE: There are some missing defines in videodev2.h that are
discussed currently. If something like V4L2_CID_{RED,BLUE}_GAIN is added
to them, my current V4L2_CID_{RED,BLUE}_BALANCE will become
V4L2_CID_{RED,BLUE}_GAIN and OV5642_CONTROL_{RED,BLUE}_SATURATION will
become V4L2_CID_{RED,BLUE}_BALANCE. The remaining code is complete.
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 41b3f51..56459f2 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -30,6 +30,18 @@
#define REG_CHIP_ID_HIGH 0x300a
#define REG_CHIP_ID_LOW0x300b
+#define REG_RED_GAIN_HIGH 0x3400
+#define REG_RED_GAIN_LOW 0x3401
+#define REG_BLUE_GAIN_HIGH 0x3404
+#define REG_BLUE_GAIN_LOW 0x3405
+#define REG_AWB_MANUAL 0x3406
+#define REG_EXP_HIGH 0x3500
+#define REG_EXP_MIDDLE 0x3501
+#define REG_EXP_LOW0x3502
+#define REG_EXP_GAIN_CTRL 0x3503
+#define REG_GAIN 0x350b
+#define REG_EXTEND_FRAME_TIME_HIGH 0x350c
+#define REG_EXTEND_FRAME_TIME_LOW 0x350d
#define REG_WINDOW_START_X_HIGH0x3800
#define REG_WINDOW_START_X_LOW 0x3801
#define REG_WINDOW_START_Y_HIGH0x3802
@@ -46,13 +58,54 @@
#define REG_OUT_TOTAL_WIDTH_LOW0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_FLIP_SUBSAMPLE 0x3818
#define REG_OUTPUT_FORMAT 0x4300
#define REG_ISP_CTRL_010x5001
+#define REG_DIGITAL_EFFECTS0x5580
+#define REG_HUE_COS0x5581
+#define REG_HUE_SIN0x5582
+#define REG_BLUE_SATURATION0x5583
+#define REG_RED_SATURATION 0x5584
+#define REG_CONTRAST 0x5588
+#define REG_BRIGHTNESS 0x5589
+#define REG_D_E_AUXILLARY 0x558a
#define REG_AVG_WINDOW_END_X_HIGH 0x5682
#define REG_AVG_WINDOW_END_X_LOW 0x5683
#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+/* default register initialisation */
+#define REG_EXP_GAIN_INIT 0x00
+#define REG_FLIP_SUBSAMPLE_INIT0xc1
+#define REG_DIGITAL_EFFECTS_INIT 0x06
+#define REG_D_E_AUXILLARY_INIT 0x01
+
+/* default values in native space */
+#define DEFAULT_RBBALANCE 0x400
+#define DEFAULT_CONTRAST 0x20
+#define DEFAULT_SATURATION 0x40
+
+#define MAX_EXP_NATIVE 0x01
+#define MAX_GAIN_NATIVE0x1f
+#define MAX_RBBALANCE_NATIVE 0x0fff
+#define MAX_EXP0x
+#define MAX_GAIN 0xff
+#define MAX_RBBALANCE 0xff
+#define MAX_HUE_TRIG_NATIVE0x80
+
+#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE + 0)
+#define OV5642_CONTROL_RED_SATURATION (V4L2_CID_PRIVATE_BASE + 1)
+
+#define EXP_V4L2_TO_NATIVE(x) ((x) 4)
+#define EXP_NATIVE_TO_V4L2(x) ((x) 4)
+#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN)
+#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE)
+#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE /
MAX_RBBALANCE)
+#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE /
MAX_RBBALANCE_NATIVE)
+
+/* flaw in the datasheet. we need some extra lines */
+#define MANUAL_LONG_EXP_SAFETY_DISTANCE20
+
/* active pixel array size */
#define OV5642_SENSOR_SIZE_X 2592
#define OV5642_SENSOR_SIZE_Y 1944
@@ -85,6 +138,9 @@
*/
#define BLANKING_MIN_HEIGHT1000
+static int ov5642_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl);
+static int ov5642_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl);
+
struct regval_list {
u16 reg_num;
u8 value;
@@ -132,10 +188,8 @@ static struct regval_list ov5642_default_regs_init[] = {
{ 0x471d, 0x5 },
{ 0x4708, 0x6 },
{ 0x370c, 0xa0 },
- { 0x5687, 0x94 },
{ 0x501f, 0x0 },
{ 0x5000, 0x4f },
- { 0x5001, 0xcf },
{ 0x4300, 0x30 },
{ 0x4300, 0x30 },
{ 0x460b, 0x35 },
@@ -148,11 +202,8 @@ static struct regval_list ov5642_default_regs_init[] = {
{ 0x4402, 0x90 },
{ 0x460c, 0x22 },
{ 0x3815, 0x44 },
- { 0x3503, 0x7 },
{ 0x3501, 0x73 },
{ 0x3502, 0x80 },
- { 0x350b, 0x0 },
- { 0x3818
Re: [PATCH 1/2 v2] media: Add support for arbitrary resolution for the ov5642 camera driver
Hello Laurent,
2011/8/31 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
Guennadi pointed out that should can sound a bit harsh, so please read my
reviews as if
#define you should I think you should
I think that you think I should do the right thing. I removed
out_sizes and repost v3 in a moment :)
was prepended to all of them :-)
On Wednesday 31 August 2011 19:06:25 Laurent Pinchart wrote:
On Wednesday 31 August 2011 17:05:52 Bastian Hecht wrote:
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..87b432e 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
[snip]
@@ -684,107 +737,101 @@ static int ov5642_write_array(struct i2c_client
[snip]
-static int ov5642_s_fmt(struct v4l2_subdev *sd,
- struct v4l2_mbus_framefmt *mf)
+static int ov5642_s_fmt(struct v4l2_subdev *sd, struct
v4l2_mbus_framefmt *mf) {
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov5642 *priv = to_ov5642(client);
-
- dev_dbg(sd-v4l2_dev-dev, %s(%u)\n, __func__, mf-code);
+ int ret;
/* MIPI CSI could have changed the format, double-check */
if (!ov5642_find_datafmt(mf-code))
return -EINVAL;
ov5642_try_fmt(sd, mf);
-
priv-fmt = ov5642_find_datafmt(mf-code);
- ov5642_write_array(client, ov5642_default_regs_init);
- ov5642_set_resolution(client);
- ov5642_write_array(client, ov5642_default_regs_finalise);
+ ret = ov5642_write_array(client, ov5642_default_regs_init);
+ if (!ret)
+ ret = ov5642_set_resolution(sd);
+ if (!ret)
+ ret = ov5642_write_array(client, ov5642_default_regs_finalise);
You shouldn't write anything to the sensor here. As only .s_crop can
currently change the format, .s_fmt should just return the current format
without performing any change or writing anything to the device.
We talked about it in the ov5642 controls thread. I need to initialize
the sensor at some point and it doesn't work to divide the calls
between different locations.
- return 0;
+ return ret;
}
[snip]
@@ -827,15 +874,42 @@ static int ov5642_g_chip_ident(struct v4l2_subdev
[snip]
static int ov5642_g_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
struct v4l2_rect *rect = a-c;
- a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- rect-top = 0;
- rect-left = 0;
- rect-width = OV5642_WIDTH;
- rect-height = OV5642_HEIGHT;
+ a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
Shouldn't you return an error instead when a-type is not
V4L2_BUF_TYPE_VIDEO_CAPTURE ?
No idea, but if you say so, I'll change it.
+ *rect = priv-crop_rect;
return 0;
}
--
Regards,
Laurent Pinchart
best,
Bastian
--
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 1/2 v3] media: Add support for arbitrary resolution for the ov5642 camera driver
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..54c822c 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
* published by the Free Software Foundation.
*/
+#include linux/bitops.h
#include linux/delay.h
#include linux/i2c.h
+#include linux/kernel.h
#include linux/slab.h
#include linux/videodev2.h
@@ -34,7 +36,7 @@
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH 0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW 0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW 0x3809
@@ -44,19 +46,44 @@
#define REG_OUT_TOTAL_WIDTH_LOW0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_OUTPUT_FORMAT 0x4300
+#define REG_ISP_CTRL_010x5001
+#define REG_AVG_WINDOW_END_X_HIGH 0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could make
+ * the chip work the intended way. As it works with predefined register lists,
+ * some undocumented registers are presumably changed there to achieve their
+ * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
*/
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT 720
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT 720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT 20
+
+/*
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
+ */
+#define BLANKING_MIN_HEIGHT1000
struct regval_list {
u16 reg_num;
@@ -581,6 +608,11 @@ struct ov5642_datafmt {
struct ov5642 {
struct v4l2_subdev subdev;
const struct ov5642_datafmt *fmt;
+ struct v4l2_rectcrop_rect;
+
+ /* blanking information */
+ int total_width;
+ int total_height;
};
static const struct ov5642_datafmt ov5642_colour_fmts[] = {
@@ -641,6 +673,21 @@ static int reg_write(struct i2c_client *client, u16 reg,
u8 val)
return 0;
}
+
+/*
+ * convenience function to write 16 bit register values that are split up
+ * into two consecutive high and low parts
+ */
+static int reg_write16(struct i2c_client *client, u16 reg, u16 val16)
+{
+ int ret;
+
+ ret = reg_write(client, reg, val16 8);
+ if (ret)
+ return ret;
+ return reg_write(client, reg + 1, val16 0x00ff);
+}
+
#ifdef CONFIG_VIDEO_ADV_DEBUG
static int ov5642_get_register(struct v4l2_subdev *sd, struct
v4l2_dbg_register *reg)
{
@@ -684,107 +731,101 @@ static int ov5642_write_array(struct i2c_client *client,
return 0;
}
-static int ov5642_set_resolution(struct i2c_client *client)
+static int ov5642_set_resolution(struct v4l2_subdev *sd)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ int width = priv-crop_rect.width;
+ int height = priv-crop_rect.height;
+ int total_width = priv-total_width;
+ int total_height = priv-total_height;
+ int start_x = (OV5642_SENSOR_SIZE_X - width) / 2;
+ int start_y = (OV5642_SENSOR_SIZE_Y - height) / 2;
int ret;
- u8 start_x_high = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 8;
- u8 start_x_low = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 0xff;
- u8 start_y_high = ((OV5642_SENSOR_SIZE_Y - OV5642_HEIGHT) / 2) 8;
- u8 start_y_low = ((OV5642_SENSOR_SIZE_Y - OV5642_HEIGHT) / 2) 0xff;
-
- u8 width_high =
Re: [PATCH] media: Add camera controls for the ov5642 driver
2011/9/1 Sakari Ailus sakari.ai...@iki.fi: On Thu, Sep 01, 2011 at 11:14:08AM +0200, Sylwester Nawrocki wrote: Hi Sakari, On 09/01/2011 10:47 AM, Sakari Ailus wrote: On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi Liakhovetski wrote: On Thu, 1 Sep 2011, Sakari Ailus wrote: On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote: 2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com: [clip] If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated. I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled V4L2_CID_PRIVATE_BASE deprecated and read Documentation/feature-removal-schedule.txt. I couldn't find anything. Hmm. Did you happen to check when that has been written? :) Please use this one instead: URL:http://hverkuil.home.xs4all.nl/spec/media.html Drivers can also implement their own custom controls using V4L2_CID_PRIVATE_BASE and higher values. Which specific location describes V4L2_CID_PRIVATE_BASE differently there? That was a general comment, not related to the private base. There's no use for a three-year-old spec as a reference! The control framework does not support private controls, for example. The controls should be put to their own class in videodev2.h nowadays, that's my understanding. Cc Hans. Is this really the case that we close the door for private controls in the mainline kernel ? Or am I misunderstanding something ? How about v4l2_ctrl_new_custom() ? What if there are controls applicable to single driver only ? Do we really want to have plenty of such in videodev2.h ? We have some of those already in videodev2.h. I'm not certain if I'm happy with this myself, considering e.g. that we could get a few truckloads of only camera lens hardware specific controls in the near future. So in my case (as these are controls that might be used by others too) I should add something like #define V4L2_CID_BLUE_SATURATION(V4L2_CID_CAMERA_CLASS_BASE+19) #define V4L2_CID_RED_SATURATION (V4L2_CID_CAMERA_CLASS_BASE+20) #define V4L2_CID_GRAY_SCALE_IMAGE (V4L2_CID_CAMERA_CLASS_BASE+21) #define V4L2_CID_SOLARIZE_EFFECT(V4L2_CID_CAMERA_CLASS_BASE+22) to videodev2.h? -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] media: Add support for arbitrary resolution for the ov5642 camera driver
2011/9/5 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Monday 05 September 2011 11:10:48 Bastian Hecht wrote:
2011/8/31 Laurent Pinchart:
Hi Bastian,
Guennadi pointed out that should can sound a bit harsh, so please read
my reviews as if
#define you should I think you should
I think that you think I should do the right thing. I removed out_sizes and
repost v3 in a moment :)
Thanks :-)
was prepended to all of them :-)
On Wednesday 31 August 2011 19:06:25 Laurent Pinchart wrote:
On Wednesday 31 August 2011 17:05:52 Bastian Hecht wrote:
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard
1280x720 only.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c
b/drivers/media/video/ov5642.c index 6410bda..87b432e 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
[snip]
@@ -684,107 +737,101 @@ static int ov5642_write_array(struct
i2c_client
[snip]
-static int ov5642_s_fmt(struct v4l2_subdev *sd,
- struct v4l2_mbus_framefmt *mf)
+static int ov5642_s_fmt(struct v4l2_subdev *sd, struct
v4l2_mbus_framefmt *mf) {
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov5642 *priv = to_ov5642(client);
-
- dev_dbg(sd-v4l2_dev-dev, %s(%u)\n, __func__, mf-code);
+ int ret;
/* MIPI CSI could have changed the format, double-check */
if (!ov5642_find_datafmt(mf-code))
return -EINVAL;
ov5642_try_fmt(sd, mf);
-
priv-fmt = ov5642_find_datafmt(mf-code);
- ov5642_write_array(client, ov5642_default_regs_init);
- ov5642_set_resolution(client);
- ov5642_write_array(client, ov5642_default_regs_finalise);
+ ret = ov5642_write_array(client, ov5642_default_regs_init);
+ if (!ret)
+ ret = ov5642_set_resolution(sd);
+ if (!ret)
+ ret = ov5642_write_array(client,
ov5642_default_regs_finalise);
You shouldn't write anything to the sensor here. As only .s_crop can
currently change the format, .s_fmt should just return the current
format without performing any change or writing anything to the device.
We talked about it in the ov5642 controls thread. I need to initialize
the sensor at some point and it doesn't work to divide the calls
between different locations.
Sure, but calling s_fmt isn't mandatory for hosts/bridges. What about moving
sensor initialization to s_stream() ?
- return 0;
+ return ret;
}
[snip]
@@ -827,15 +874,42 @@ static int ov5642_g_chip_ident(struct
v4l2_subdev
[snip]
static int ov5642_g_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
struct v4l2_rect *rect = a-c;
- a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- rect-top = 0;
- rect-left = 0;
- rect-width = OV5642_WIDTH;
- rect-height = OV5642_HEIGHT;
+ a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
Shouldn't you return an error instead when a-type is not
V4L2_BUF_TYPE_VIDEO_CAPTURE ?
No idea, but if you say so, I'll change it.
VIDIOC_G_FMT documentation states that
When the requested buffer type is not supported drivers return an EINVAL
error code.
I thought VIDIOC_G_CROP documentation did as well, but it doesn't. However I
believe the above should apply to VIDIOC_G_CROP as well. There is no explicit
documentation about error codes for subdev operations, but I think it makes
sense to follow what the V4L2 ioctls do.
And these ioctl calls go straight through to my driver? Or is there
some intermediate work by the subdev architecture? I'm asking because
I don't check the buffer type in g_fmt as well. If so, I have to
change that too.
best,
Bastian
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] media: Add support for arbitrary resolution for the ov5642 camera driver
Hello Laurent,
2011/9/5 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Monday 05 September 2011 11:41:28 Bastian Hecht wrote:
2011/9/5 Laurent Pinchart:
On Monday 05 September 2011 11:10:48 Bastian Hecht wrote:
2011/8/31 Laurent Pinchart:
static int ov5642_g_crop(struct v4l2_subdev *sd, struct v4l2_crop
*a) {
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
struct v4l2_rect *rect = a-c;
- a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- rect-top = 0;
- rect-left = 0;
- rect-width = OV5642_WIDTH;
- rect-height = OV5642_HEIGHT;
+ a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
Shouldn't you return an error instead when a-type is not
V4L2_BUF_TYPE_VIDEO_CAPTURE ?
No idea, but if you say so, I'll change it.
VIDIOC_G_FMT documentation states that
When the requested buffer type is not supported drivers return an EINVAL
error code.
I thought VIDIOC_G_CROP documentation did as well, but it doesn't.
However I believe the above should apply to VIDIOC_G_CROP as well. There
is no explicit documentation about error codes for subdev operations,
but I think it makes sense to follow what the V4L2 ioctls do.
And these ioctl calls go straight through to my driver? Or is there
some intermediate work by the subdev architecture? I'm asking because
I don't check the buffer type in g_fmt as well. If so, I have to
change that too.
The ioctls go to the host/bridge driver, which then decides when and how to
call g/s_fmt and g/s_crop. I would add the same check to g_fmt.
Next time I will work in the media section of the kernel, I must study
the docs a bit better I guess :/
To the g_fmt() thing... is there the buffer type given at all? The
argument of type struct v4l2_mbus_framefmt doesn't contain it.
best,
Bastian
--
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: [PATCH] media: Add camera controls for the ov5642 driver
2011/8/31 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Wed, 31 Aug 2011, Bastian Hecht wrote:
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
Thanks for the patch.
On Wednesday 17 August 2011 18:02:07 Bastian Hecht wrote:
The driver now supports automatic/manual gain, automatic/manual white
balance, automatic/manual exposure control, vertical flip, brightness
control, contrast control and saturation control. Additionally the
following effects are available now: rotating the hue in the colorspace,
gray scale image and solarize effect.
Any chance to port soc-camera to the control framework ? :-)
I redirect that to Guennadi :-)
Hans is prepaing an update of his port, then we'll integrate it... This
all will take time, so, it's better to do this driver now the old
soc-camera way, and port it later.
[snip]
+static int ov5642_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control
*ctrl) +{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ int ret = 0;
+ u8 val8;
+ u16 val16;
+ u32 val32;
+ int trig;
+ struct v4l2_control aux_ctrl;
+
+ switch (ctrl-id) {
+ case V4L2_CID_AUTOGAIN:
+ if (!ctrl-value) {
+ aux_ctrl.id = V4L2_CID_GAIN;
+ ret = ov5642_g_ctrl(sd, aux_ctrl);
+ if (ret)
+ break;
+ priv-gain = aux_ctrl.value;
+ }
+
+ ret = reg_read(client, REG_EXP_GAIN_CTRL, val8);
+ if (ret)
+ break;
+ val8 = ctrl-value ? val8 ~BIT(1) : val8 | BIT(1);
+ ret = reg_write(client, REG_EXP_GAIN_CTRL, val8);
+ if (!ret)
+ priv-agc = ctrl-value;
What about caching the content of this register (and of other registers
below)
instead of reading it back ? If you can't do that, a reg_clr_set() function
would make the code simpler.
Ok I will do the caching.
Wasn't the reason for reading those registers from the hardware, that the
sensor changes them in auto* modes (autogain in this case)?
There are different cases. E.g. this register sets the autogain and
autoexposure on/off not the gain value itself. So indeed one should
cache it (sometimes I registered side-effects on the ov5642 - setting
1 register changed others. I hope I won't run into trouble with
these).
best,
Bastian
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] media: Add support for arbitrary resolution for the ov5642 camera driver
2011/9/5 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Guennadi,
On Monday 05 September 2011 11:51:57 Guennadi Liakhovetski wrote:
On Mon, 5 Sep 2011, Laurent Pinchart wrote:
On Monday 05 September 2011 11:10:48 Bastian Hecht wrote:
2011/8/31 Laurent Pinchart:
On Wednesday 31 August 2011 19:06:25 Laurent Pinchart wrote:
On Wednesday 31 August 2011 17:05:52 Bastian Hecht wrote:
This patch adds the ability to get arbitrary resolutions with a
width up to 2592 and a height up to 720 pixels instead of the
standard 1280x720 only.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c
b/drivers/media/video/ov5642.c index 6410bda..87b432e 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
[snip]
@@ -684,107 +737,101 @@ static int ov5642_write_array(struct
i2c_client
[snip]
-static int ov5642_s_fmt(struct v4l2_subdev *sd,
- struct v4l2_mbus_framefmt *mf)
+static int ov5642_s_fmt(struct v4l2_subdev *sd, struct
v4l2_mbus_framefmt *mf) {
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov5642 *priv = to_ov5642(client);
-
- dev_dbg(sd-v4l2_dev-dev, %s(%u)\n, __func__, mf-code);
+ int ret;
/* MIPI CSI could have changed the format, double-check */
if (!ov5642_find_datafmt(mf-code))
return -EINVAL;
ov5642_try_fmt(sd, mf);
-
priv-fmt = ov5642_find_datafmt(mf-code);
- ov5642_write_array(client, ov5642_default_regs_init);
- ov5642_set_resolution(client);
- ov5642_write_array(client, ov5642_default_regs_finalise);
+ ret = ov5642_write_array(client, ov5642_default_regs_init);
+ if (!ret)
+ ret = ov5642_set_resolution(sd);
+ if (!ret)
+ ret = ov5642_write_array(client,
ov5642_default_regs_finalise);
You shouldn't write anything to the sensor here. As only .s_crop can
currently change the format, .s_fmt should just return the current
format without performing any change or writing anything to the
device.
We talked about it in the ov5642 controls thread. I need to initialize
the sensor at some point and it doesn't work to divide the calls
between different locations.
Sure, but calling s_fmt isn't mandatory for hosts/bridges. What about
moving sensor initialization to s_stream() ?
Throughout the development of this driver, I was opposing the delayed
configuration approach. I.e., the approach, in which all the ioctl()s,
like S_FMT, S_CROP, etc. only store user values internally, and the actual
hardware configuration is only performed at STREAMON time. There are
several reasons to this: the spec says the driver may program the
hardware, allocate resources and generally prepare for data exchange
(yes, may != must), most drivers seem to do the same, the possibility
to check and return any hardware errors, returned by this operation, I
probably have forgotten something. But if we ignore all these reasons as
insufficiently important, then yes, doing the actualy hardware
configuration in .s_stream() brings a couple of advantages with it,
especially for drivers / devices like this one.
So, if there are no strong objections, maybe indeed move this back to
.s_stream() would be the better solution here.
I have no strong opinion here. Your points are certainly valid. I'm fine with
performing direct hardware setup in .s_crop(), but doing it in .s_fmt() looks
weird to me as .s_fmt() doesn't perform any operation now that the driver
moved to using .s_crop(). Without delayed initialization I believe the device
should be initialized when powered up, and have its crop rectangle altered in
.s_crop().
Ok, it is moved to s_power and s_crop now. This approach sounds clean indeed.
best,
Bastian
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
Hello Laurent,
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
Thanks for the patch.
[snip]
+#define REG_RED_GAIN_HIGH 0x3400
+#define REG_RED_GAIN_LOW 0x3401
+#define REG_BLUE_GAIN_HIGH 0x3404
+#define REG_BLUE_GAIN_LOW 0x3405
+#define REG_AWB_MANUAL 0x3406
+#define REG_EXP_HIGH 0x3500
+#define REG_EXP_MIDDLE 0x3501
+#define REG_EXP_LOW 0x3502
+#define REG_EXP_GAIN_CTRL 0x3503
+#define REG_GAIN 0x350b
This belongs to the second patch.
Yes, I've changed it.
+#define REG_EXTEND_FRAME_TIME_HIGH 0x350c
+#define REG_EXTEND_FRAME_TIME_LOW 0x350d
#define REG_WINDOW_START_X_HIGH 0x3800
#define REG_WINDOW_START_X_LOW 0x3801
#define REG_WINDOW_START_Y_HIGH 0x3802
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH 0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW 0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW 0x3809
@@ -44,19 +58,56 @@
#define REG_OUT_TOTAL_WIDTH_LOW 0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_FLIP_SUBSAMPLE 0x3818
+#define REG_OUTPUT_FORMAT 0x4300
+#define REG_ISP_CTRL_01 0x5001
+#define REG_DIGITAL_EFFECTS 0x5580
+#define REG_HUE_COS 0x5581
+#define REG_HUE_SIN 0x5582
+#define REG_BLUE_SATURATION 0x5583
+#define REG_RED_SATURATION 0x5584
+#define REG_CONTRAST 0x5588
+#define REG_BRIGHTNESS 0x5589
+#define REG_D_E_AUXILLARY 0x558a
+#define REG_AVG_WINDOW_END_X_HIGH 0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
So does this.
Changed as well.
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
+
+/* current maximum working size */
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT 720
+
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT 20
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
*/
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT 720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT 2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+#define BLANKING_MIN_HEIGHT 1000
+
+/*
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could
make + * the chip work the intended way. As it works with predefined
register lists, + * some undocumented registers are presumably changed
there to achieve their + * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
+ */
Can you please move this comment above the OV5642_MAX_WIDTH and
OV5642_MAX_HEIGHT definitions ?
Ok, done.
struct regval_list {
u16 reg_num;
@@ -105,10 +156,8 @@ static struct regval_list ov5642_default_regs_init[] =
{ { 0x471d, 0x5 },
{ 0x4708, 0x6 },
{ 0x370c, 0xa0 },
- { 0x5687, 0x94 },
Unless I'm mistaken, this register value is removed and isn't replaced by
anything in this patch or the next one. Is that intentional ?
This was a cropping offset. It is done now dynamically.
{ 0x501f, 0x0 },
{ 0x5000, 0x4f },
- { 0x5001, 0xcf },
This one is replaced by 0xff. I'm not sure how that's related to this patch.
Could you please check all modifications to the ov5642_default_regs_init[] and
ov5642_default_regs_finalise[] arrays ? Some probably need to move to the next
patch, and others don't seem to be related to any of the two patches.
There are 2 reasons why the registers are changed: 1st) values are
calculated dynamically now. 2nd) the register list contains
duplicates. It changes some registers multiple times with different
values
[PATCH 1/2 v2] media: Add support for arbitrary resolution for the ov5642 camera driver
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..87b432e 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
* published by the Free Software Foundation.
*/
+#include linux/bitops.h
#include linux/delay.h
#include linux/i2c.h
+#include linux/kernel.h
#include linux/slab.h
#include linux/videodev2.h
@@ -34,7 +36,7 @@
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH 0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW 0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW 0x3809
@@ -44,19 +46,44 @@
#define REG_OUT_TOTAL_WIDTH_LOW0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_OUTPUT_FORMAT 0x4300
+#define REG_ISP_CTRL_010x5001
+#define REG_AVG_WINDOW_END_X_HIGH 0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could make
+ * the chip work the intended way. As it works with predefined register lists,
+ * some undocumented registers are presumably changed there to achieve their
+ * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
*/
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT 720
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT 720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT 20
+
+/*
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
+ */
+#define BLANKING_MIN_HEIGHT1000
struct regval_list {
u16 reg_num;
@@ -578,9 +605,20 @@ struct ov5642_datafmt {
enum v4l2_colorspacecolorspace;
};
+/* the output resolution and blanking information */
+struct ov5642_out_size {
+ int width;
+ int height;
+ int total_width;
+ int total_height;
+};
+
struct ov5642 {
struct v4l2_subdev subdev;
+
const struct ov5642_datafmt *fmt;
+ struct v4l2_rectcrop_rect;
+ struct ov5642_out_size out_size;
};
static const struct ov5642_datafmt ov5642_colour_fmts[] = {
@@ -641,6 +679,21 @@ static int reg_write(struct i2c_client *client, u16 reg,
u8 val)
return 0;
}
+
+/*
+ * convenience function to write 16 bit register values that are split up
+ * into two consecutive high and low parts
+ */
+static int reg_write16(struct i2c_client *client, u16 reg, u16 val16)
+{
+ int ret;
+
+ ret = reg_write(client, reg, val16 8);
+ if (ret)
+ return ret;
+ return reg_write(client, reg + 1, val16 0x00ff);
+}
+
#ifdef CONFIG_VIDEO_ADV_DEBUG
static int ov5642_get_register(struct v4l2_subdev *sd, struct
v4l2_dbg_register *reg)
{
@@ -684,107 +737,101 @@ static int ov5642_write_array(struct i2c_client *client,
return 0;
}
-static int ov5642_set_resolution(struct i2c_client *client)
+static int ov5642_set_resolution(struct v4l2_subdev *sd)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ int width = priv-out_size.width;
+ int height = priv-out_size.height;
+ int total_width = priv-out_size.total_width;
+ int total_height = priv-out_size.total_height;
+ int start_x = (OV5642_SENSOR_SIZE_X - width) / 2;
+ int start_y = (OV5642_SENSOR_SIZE_Y - height) / 2;
int ret;
- u8 start_x_high = ((OV5642_SENSOR_SIZE_X - OV5642_WIDTH) / 2) 8;
- u8
Re: [PATCH] media: Add camera controls for the ov5642 driver
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
Thanks for the patch.
On Wednesday 17 August 2011 18:02:07 Bastian Hecht wrote:
The driver now supports automatic/manual gain, automatic/manual white
balance, automatic/manual exposure control, vertical flip, brightness
control, contrast control and saturation control. Additionally the
following effects are available now: rotating the hue in the colorspace,
gray scale image and solarize effect.
Any chance to port soc-camera to the control framework ? :-)
I redirect that to Guennadi :-)
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 1b40d90..069a720 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -74,6 +74,34 @@
#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+/* default values in native space */
+#define DEFAULT_RBBALANCE 0x400
+#define DEFAULT_CONTRAST 0x20
+#define DEFAULT_SATURATION 0x40
+
+#define MAX_EXP_NATIVE 0x01
+#define MAX_GAIN_NATIVE 0x1f
+#define MAX_RBBALANCE_NATIVE 0x0fff
+#define MAX_EXP 0x
+#define MAX_GAIN 0xff
+#define MAX_RBBALANCE 0xff
+#define MAX_HUE_TRIG_NATIVE 0x80
+
+#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE + 0)
+#define OV5642_CONTROL_RED_SATURATION (V4L2_CID_PRIVATE_BASE + 1)
+#define OV5642_CONTROL_GRAY_SCALE (V4L2_CID_PRIVATE_BASE + 2)
+#define OV5642_CONTROL_SOLARIZE (V4L2_CID_PRIVATE_BASE + 3)
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled
V4L2_CID_PRIVATE_BASE deprecated and read
Documentation/feature-removal-schedule.txt. I couldn't find anything.
If it is deprecated, do you have an idea how to offer device specific
features to the user?
+
+#define EXP_V4L2_TO_NATIVE(x) ((x) 4)
+#define EXP_NATIVE_TO_V4L2(x) ((x) 4)
+#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN)
+#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE)
+#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE /
MAX_RBBALANCE) +#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE /
MAX_RBBALANCE_NATIVE) +
+/* flaw in the datasheet. we need some extra lines */
+#define MANUAL_LONG_EXP_SAFETY_DISTANCE 20
+
/* active pixel array size */
#define OV5642_SENSOR_SIZE_X 2592
#define OV5642_SENSOR_SIZE_Y 1944
[snip]
@@ -804,6 +1013,100 @@ static int ov5642_set_resolution(struct v4l2_subdev
*sd) return ret;
}
+static int ov5642_restore_state(struct v4l2_subdev *sd)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ struct v4l2_control set_ctrl;
+ int tmp_red_balance = priv-red_balance;
+ int tmp_blue_balance = priv-blue_balance;
+ int tmp_gain = priv-gain;
+ int tmp_exp = priv-exposure;
+ int ret;
+
+ set_ctrl.id = V4L2_CID_AUTOGAIN;
+ set_ctrl.value = priv-agc;
+ ret = ov5642_s_ctrl(sd, set_ctrl);
What about writing to registers directly ?
I thought about that too, but code duplication would be very large
(e.g. take the hue control). I considered the speedup of avoiding
function calls less than the error-proness of this duplication. It is
just cleaner imho.
+
+ if (!priv-agc) {
+ set_ctrl.id = V4L2_CID_GAIN;
+ set_ctrl.value = tmp_gain;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_AUTO_WHITE_BALANCE;
+ set_ctrl.value = priv-awb;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ if (!priv-awb) {
+ set_ctrl.id = V4L2_CID_RED_BALANCE;
+ set_ctrl.value = tmp_red_balance;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = V4L2_CID_BLUE_BALANCE;
+ set_ctrl.value = tmp_blue_balance;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_EXPOSURE_AUTO;
+ set_ctrl.value = priv-aec;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ if (priv-aec == V4L2_EXPOSURE_MANUAL) {
+ set_ctrl.id = V4L2_CID_EXPOSURE;
+ set_ctrl.value = tmp_exp;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_VFLIP;
+ set_ctrl.value = priv-vflip;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = OV5642_CONTROL_GRAY_SCALE;
+ set_ctrl.value = priv-grayscale;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd
Re: [PATCH] media: Add camera controls for the ov5642 driver
2011/8/31 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Wednesday 31 August 2011 17:27:49 Bastian Hecht wrote:
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Wednesday 17 August 2011 18:02:07 Bastian Hecht wrote:
The driver now supports automatic/manual gain, automatic/manual white
balance, automatic/manual exposure control, vertical flip, brightness
control, contrast control and saturation control. Additionally the
following effects are available now: rotating the hue in the colorspace,
gray scale image and solarize effect.
Any chance to port soc-camera to the control framework ? :-)
I redirect that to Guennadi :-)
Guennadi, do you have any update on this ? Hans posted patches early this
year, do you know if there has been any work on them since then ?
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 1b40d90..069a720 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -74,6 +74,34 @@
#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+/* default values in native space */
+#define DEFAULT_RBBALANCE 0x400
+#define DEFAULT_CONTRAST 0x20
+#define DEFAULT_SATURATION 0x40
+
+#define MAX_EXP_NATIVE 0x01
+#define MAX_GAIN_NATIVE 0x1f
+#define MAX_RBBALANCE_NATIVE 0x0fff
+#define MAX_EXP 0x
+#define MAX_GAIN 0xff
+#define MAX_RBBALANCE 0xff
+#define MAX_HUE_TRIG_NATIVE 0x80
+
+#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE +
0) +#define OV5642_CONTROL_RED_SATURATION (V4L2_CID_PRIVATE_BASE
+ 1) +#define OV5642_CONTROL_GRAY_SCALE (V4L2_CID_PRIVATE_BASE + 2)
+#define OV5642_CONTROL_SOLARIZE (V4L2_CID_PRIVATE_BASE +
3)
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled
V4L2_CID_PRIVATE_BASE deprecated and read
Documentation/feature-removal-schedule.txt. I couldn't find anything.
If it is deprecated, do you have an idea how to offer device specific
features to the user?
The basic idea is that controls should be standardized, or at least documented
and added to the V4L2 spec. Controls should belong to a class, so you should
select the proper base class and add a big offset (I've used 0x1000) in the
meantime if you want to export private controls.
Is this code accessable? Then I can just copy the scheme.
+
+#define EXP_V4L2_TO_NATIVE(x) ((x) 4)
+#define EXP_NATIVE_TO_V4L2(x) ((x) 4)
+#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN)
+#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE)
+#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE /
MAX_RBBALANCE) +#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE
/ MAX_RBBALANCE_NATIVE) +
+/* flaw in the datasheet. we need some extra lines */
+#define MANUAL_LONG_EXP_SAFETY_DISTANCE 20
+
/* active pixel array size */
#define OV5642_SENSOR_SIZE_X 2592
#define OV5642_SENSOR_SIZE_Y 1944
[snip]
@@ -804,6 +1013,100 @@ static int ov5642_set_resolution(struct
v4l2_subdev *sd) return ret;
}
+static int ov5642_restore_state(struct v4l2_subdev *sd)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ struct v4l2_control set_ctrl;
+ int tmp_red_balance = priv-red_balance;
+ int tmp_blue_balance = priv-blue_balance;
+ int tmp_gain = priv-gain;
+ int tmp_exp = priv-exposure;
+ int ret;
+
+ set_ctrl.id = V4L2_CID_AUTOGAIN;
+ set_ctrl.value = priv-agc;
+ ret = ov5642_s_ctrl(sd, set_ctrl);
What about writing to registers directly ?
I thought about that too, but code duplication would be very large
(e.g. take the hue control). I considered the speedup of avoiding
function calls less than the error-proness of this duplication. It is
just cleaner imho.
OK. This will be replaced when soc-camera will use the control framework
anyway.
+
+ if (!priv-agc) {
+ set_ctrl.id = V4L2_CID_GAIN;
+ set_ctrl.value = tmp_gain;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_AUTO_WHITE_BALANCE;
+ set_ctrl.value = priv-awb;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ if (!priv-awb) {
+ set_ctrl.id = V4L2_CID_RED_BALANCE;
+ set_ctrl.value = tmp_red_balance;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id = V4L2_CID_BLUE_BALANCE;
+ set_ctrl.value
Re: [PATCH] media: Add camera controls for the ov5642 driver
2011/8/31 Bastian Hecht hec...@googlemail.com:
2011/8/31 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Wednesday 31 August 2011 17:27:49 Bastian Hecht wrote:
2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Wednesday 17 August 2011 18:02:07 Bastian Hecht wrote:
The driver now supports automatic/manual gain, automatic/manual white
balance, automatic/manual exposure control, vertical flip, brightness
control, contrast control and saturation control. Additionally the
following effects are available now: rotating the hue in the colorspace,
gray scale image and solarize effect.
Any chance to port soc-camera to the control framework ? :-)
I redirect that to Guennadi :-)
Guennadi, do you have any update on this ? Hans posted patches early this
year, do you know if there has been any work on them since then ?
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 1b40d90..069a720 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -74,6 +74,34 @@
#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+/* default values in native space */
+#define DEFAULT_RBBALANCE 0x400
+#define DEFAULT_CONTRAST 0x20
+#define DEFAULT_SATURATION 0x40
+
+#define MAX_EXP_NATIVE 0x01
+#define MAX_GAIN_NATIVE 0x1f
+#define MAX_RBBALANCE_NATIVE 0x0fff
+#define MAX_EXP 0x
+#define MAX_GAIN 0xff
+#define MAX_RBBALANCE 0xff
+#define MAX_HUE_TRIG_NATIVE 0x80
+
+#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE +
0) +#define OV5642_CONTROL_RED_SATURATION (V4L2_CID_PRIVATE_BASE
+ 1) +#define OV5642_CONTROL_GRAY_SCALE (V4L2_CID_PRIVATE_BASE + 2)
+#define OV5642_CONTROL_SOLARIZE (V4L2_CID_PRIVATE_BASE +
3)
If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated.
I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled
V4L2_CID_PRIVATE_BASE deprecated and read
Documentation/feature-removal-schedule.txt. I couldn't find anything.
If it is deprecated, do you have an idea how to offer device specific
features to the user?
The basic idea is that controls should be standardized, or at least
documented
and added to the V4L2 spec. Controls should belong to a class, so you should
select the proper base class and add a big offset (I've used 0x1000) in the
meantime if you want to export private controls.
Is this code accessable? Then I can just copy the scheme.
+
+#define EXP_V4L2_TO_NATIVE(x) ((x) 4)
+#define EXP_NATIVE_TO_V4L2(x) ((x) 4)
+#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN)
+#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE)
+#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE /
MAX_RBBALANCE) +#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE
/ MAX_RBBALANCE_NATIVE) +
+/* flaw in the datasheet. we need some extra lines */
+#define MANUAL_LONG_EXP_SAFETY_DISTANCE 20
+
/* active pixel array size */
#define OV5642_SENSOR_SIZE_X 2592
#define OV5642_SENSOR_SIZE_Y 1944
[snip]
@@ -804,6 +1013,100 @@ static int ov5642_set_resolution(struct
v4l2_subdev *sd) return ret;
}
+static int ov5642_restore_state(struct v4l2_subdev *sd)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov5642 *priv = to_ov5642(client);
+ struct v4l2_control set_ctrl;
+ int tmp_red_balance = priv-red_balance;
+ int tmp_blue_balance = priv-blue_balance;
+ int tmp_gain = priv-gain;
+ int tmp_exp = priv-exposure;
+ int ret;
+
+ set_ctrl.id = V4L2_CID_AUTOGAIN;
+ set_ctrl.value = priv-agc;
+ ret = ov5642_s_ctrl(sd, set_ctrl);
What about writing to registers directly ?
I thought about that too, but code duplication would be very large
(e.g. take the hue control). I considered the speedup of avoiding
function calls less than the error-proness of this duplication. It is
just cleaner imho.
OK. This will be replaced when soc-camera will use the control framework
anyway.
+
+ if (!priv-agc) {
+ set_ctrl.id = V4L2_CID_GAIN;
+ set_ctrl.value = tmp_gain;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+ }
+
+ set_ctrl.id = V4L2_CID_AUTO_WHITE_BALANCE;
+ set_ctrl.value = priv-awb;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ if (!priv-awb) {
+ set_ctrl.id = V4L2_CID_RED_BALANCE;
+ set_ctrl.value = tmp_red_balance;
+ if (!ret)
+ ret = ov5642_s_ctrl(sd, set_ctrl);
+
+ set_ctrl.id
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
Hello Laurent and others, 2011/8/30 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Guennadi, On Tuesday 30 August 2011 15:13:25 Guennadi Liakhovetski wrote: On Tue, 30 Aug 2011, Laurent Pinchart wrote: On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote: On Mon, 29 Aug 2011, Laurent Pinchart wrote: On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote: On Mon, 29 Aug 2011, Laurent Pinchart wrote: On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote: On Sun, 28 Aug 2011, Laurent Pinchart wrote: [snip] @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd, ov5642_try_fmt(sd, mf); + priv-out_size.width = mf-width; + priv-out_size.height = mf-height; It looks like to me (but I may be wrong) that you achieve different resolutions using cropping, not scaling. If that's correct you should implement s_crop support and refuse changing the resolution through s_fmt. As the patch explains (I think) on several occasions, currently only the 1:1 scale is supported, and it was our deliberate choice to implement this using the scaling API If you implement cropping, you should use the crop API, not the scaling API :-) It's changing both - input and output sizes. Sure, but it's still cropping. Why? Isn't it a matter of the PoV? No it isn't. Cropping is cropping, regardless of how you look at it. It changes the output window, i.e., implements S_FMT. And S_FMT is by far more important / widely used than S_CROP. Refusing to change the output window and always just returning the == crop size wouldn't be polite, IMHO. If your sensor has no scaler the output size is equal to the crop rectangle. There's no way around that, and there's no reason to have the driver behave otherwise. Don't think many users would guess to use S_CROP. Users who want to crop use S_CROP. Standard applications a la mplayer don't use S_CROP at all. That's because they don't want to crop. mplayer expects the driver to perform scaling when it calls S_FMT, and users won't be happy if you crop instead. So, here's my opinion, based on the V4L2 spec. I'm going to base on this and pull this patch into my tree and let Mauro decide, unless he expresses his negative opinion before that. I've also made other comments. I expect at least a v2 that addresses them. Being the author I should drop a note too, I guess. Currently I'm working on all the comments and preparing a new set of patches. I will of course either implement the suggestion or reply to it in 1 or 2 days. As far as the cropping/scaling discussion is going on - I wait until you agreed on something (what is probably not happening though ;) before adressing it directly in the code. I don't have a real own opinion here as I am too unexperienced. If the arguments are balanced I would prefer leaving the code as it is :-) but I'm open to change it if necessary. best regards, Bastian -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
2011/8/30 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Tue, 30 Aug 2011, Hans Verkuil wrote:
On Tuesday, August 30, 2011 16:24:55 Guennadi Liakhovetski wrote:
Hi Hans
On Tue, 30 Aug 2011, Hans Verkuil wrote:
[snip]
The problem with S_FMT changing the crop rectangle (and I assume we are
not
talking about small pixel tweaks to make the hardware happy) is that the
crop operation actually removes part of the frame. That's not something
you
would expect S_FMT to do, ever. Such an operation has to be explicitly
requested by the user.
It's also why properly written applications (e.g. capture-example.c) has
code like this to reset the crop rectangle before starting streaming:
if (0 == xioctl(fd, VIDIOC_CROPCAP, cropcap)) {
crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
crop.c = cropcap.defrect; /* reset to default */
if (-1 == xioctl(fd, VIDIOC_S_CROP, crop)) {
switch (errno) {
case EINVAL:
/* Cropping not supported. */
break;
default:
/* Errors ignored. */
break;
}
}
}
(Hmm, capture-example.c should also test for ENOTTY since we changed the
error code).
I agree, that preserving input rectangle == output rectangle in reply to
S_FMT is not nice, and should be avoided, wherever possible. Still, I
prefer this to sticking with just one fixed output geometry, especially
since (1) the spec doesn't prohibit this behaviour,
Hmm, I think it should be prohibited. Few drivers actually implement crop,
and fewer applications use it. So I'm not surprised the spec doesn't go into
much detail.
(2) there are already
precedents in the mainline.
Which precedents? My guess is that any driver that does this was either not
(or poorly) reviewed, or everyone just missed it.
My first two sensor drivers mt9m001 and mt9v022 do this, but, I suspect, I
didn't invent it at that time, I think, I copied it from somewhere, cannot
say for sure though anymore.
Maybe, a bit of hardware background would help: the sensor is actually
supposed to be able to both crop and scale, and we did try to implement
scales other than 1:1, but the chip just refused to produce anything
meaningful.
I still don't see any reason why S_FMT would suddenly crop on such a sensor.
It's completely unexpected and the user does not get what he expects.
Good, let's make it simple for all (except Bastian) then: Bastian, sorry
for having misguided you, please, switch to .s_crop().
Sure, no problem. So s_fmt() shall be not available at all then,
right? Instead the cropping rectangle can be changed and the output
rectangle is adjusted accordingly.
best regards,
Bastian
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
This patch adds the ability to get arbitrary resolutions with a width
up to 2592 and a height up to 720 pixels instead of the standard 1280x720
only.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 6410bda..1b40d90 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -14,8 +14,10 @@
* published by the Free Software Foundation.
*/
+#include linux/bitops.h
#include linux/delay.h
#include linux/i2c.h
+#include linux/kernel.h
#include linux/slab.h
#include linux/videodev2.h
@@ -28,13 +30,25 @@
#define REG_CHIP_ID_HIGH 0x300a
#define REG_CHIP_ID_LOW0x300b
+#define REG_RED_GAIN_HIGH 0x3400
+#define REG_RED_GAIN_LOW 0x3401
+#define REG_BLUE_GAIN_HIGH 0x3404
+#define REG_BLUE_GAIN_LOW 0x3405
+#define REG_AWB_MANUAL 0x3406
+#define REG_EXP_HIGH 0x3500
+#define REG_EXP_MIDDLE 0x3501
+#define REG_EXP_LOW0x3502
+#define REG_EXP_GAIN_CTRL 0x3503
+#define REG_GAIN 0x350b
+#define REG_EXTEND_FRAME_TIME_HIGH 0x350c
+#define REG_EXTEND_FRAME_TIME_LOW 0x350d
#define REG_WINDOW_START_X_HIGH0x3800
#define REG_WINDOW_START_X_LOW 0x3801
#define REG_WINDOW_START_Y_HIGH0x3802
#define REG_WINDOW_START_Y_LOW 0x3803
#define REG_WINDOW_WIDTH_HIGH 0x3804
#define REG_WINDOW_WIDTH_LOW 0x3805
-#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
#define REG_WINDOW_HEIGHT_LOW 0x3807
#define REG_OUT_WIDTH_HIGH 0x3808
#define REG_OUT_WIDTH_LOW 0x3809
@@ -44,19 +58,56 @@
#define REG_OUT_TOTAL_WIDTH_LOW0x380d
#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+#define REG_FLIP_SUBSAMPLE 0x3818
+#define REG_OUTPUT_FORMAT 0x4300
+#define REG_ISP_CTRL_010x5001
+#define REG_DIGITAL_EFFECTS0x5580
+#define REG_HUE_COS0x5581
+#define REG_HUE_SIN0x5582
+#define REG_BLUE_SATURATION0x5583
+#define REG_RED_SATURATION 0x5584
+#define REG_CONTRAST 0x5588
+#define REG_BRIGHTNESS 0x5589
+#define REG_D_E_AUXILLARY 0x558a
+#define REG_AVG_WINDOW_END_X_HIGH 0x5682
+#define REG_AVG_WINDOW_END_X_LOW 0x5683
+#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
+#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+
+/* active pixel array size */
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
+
+/* current maximum working size */
+#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X
+#define OV5642_MAX_HEIGHT 720
+
+/* default sizes */
+#define OV5642_DEFAULT_WIDTH 1280
+#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT
+
+/* minimum extra blanking */
+#define BLANKING_EXTRA_WIDTH 500
+#define BLANKING_EXTRA_HEIGHT 20
/*
- * define standard resolution.
- * Works currently only for up to 720 lines
- * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ * the sensor's autoexposure is buggy when setting total_height low.
+ * It tries to expose longer than 1 frame period without taking care of it
+ * and this leads to weird output. So we set 1000 lines as minimum.
*/
-#define OV5642_WIDTH 1280
-#define OV5642_HEIGHT 720
-#define OV5642_TOTAL_WIDTH 3200
-#define OV5642_TOTAL_HEIGHT2000
-#define OV5642_SENSOR_SIZE_X 2592
-#define OV5642_SENSOR_SIZE_Y 1944
+#define BLANKING_MIN_HEIGHT1000
+
+/*
+ * About OV5642 resolution, cropping and binning:
+ * This sensor supports it all, at least in the feature description.
+ * Unfortunately, no combination of appropriate registers settings could make
+ * the chip work the intended way. As it works with predefined register lists,
+ * some undocumented registers are presumably changed there to achieve their
+ * goals.
+ * This driver currently only works for resolutions up to 720 lines with a
+ * 1:1 scale. Hopefully these restrictions will be removed in the future.
+ */
struct regval_list {
u16 reg_num;
@@ -105,10 +156,8 @@ static struct regval_list ov5642_default_regs_init[] = {
{ 0x471d, 0x5 },
{ 0x4708, 0x6 },
{ 0x370c, 0xa0 },
- { 0x5687, 0x94 },
{ 0x501f, 0x0 },
{ 0x5000, 0x4f },
- { 0x5001, 0xcf },
{ 0x4300, 0x30 },
{ 0x4300, 0x30 },
{ 0x460b, 0x35 },
@@ -121,11 +170,8 @@ static struct regval_list ov5642_default_regs_init[] = {
{ 0x4402, 0x90 },
{ 0x460c, 0x22 },
{ 0x3815, 0x44 },
- { 0x3503, 0x7 },
{ 0x3501, 0x73 },
{ 0x3502, 0x80 },
- { 0x350b, 0x0 },
- { 0x3818, 0xc8
[PATCH] media: Add camera controls for the ov5642 driver
The driver now supports automatic/manual gain, automatic/manual white
balance, automatic/manual exposure control, vertical flip, brightness
control, contrast control and saturation control. Additionally the
following effects are available now: rotating the hue in the colorspace,
gray scale image and solarize effect.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 1b40d90..069a720 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -74,6 +74,34 @@
#define REG_AVG_WINDOW_END_Y_HIGH 0x5686
#define REG_AVG_WINDOW_END_Y_LOW 0x5687
+/* default values in native space */
+#define DEFAULT_RBBALANCE 0x400
+#define DEFAULT_CONTRAST 0x20
+#define DEFAULT_SATURATION 0x40
+
+#define MAX_EXP_NATIVE 0x01
+#define MAX_GAIN_NATIVE0x1f
+#define MAX_RBBALANCE_NATIVE 0x0fff
+#define MAX_EXP0x
+#define MAX_GAIN 0xff
+#define MAX_RBBALANCE 0xff
+#define MAX_HUE_TRIG_NATIVE0x80
+
+#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE + 0)
+#define OV5642_CONTROL_RED_SATURATION (V4L2_CID_PRIVATE_BASE + 1)
+#define OV5642_CONTROL_GRAY_SCALE (V4L2_CID_PRIVATE_BASE + 2)
+#define OV5642_CONTROL_SOLARIZE(V4L2_CID_PRIVATE_BASE + 3)
+
+#define EXP_V4L2_TO_NATIVE(x) ((x) 4)
+#define EXP_NATIVE_TO_V4L2(x) ((x) 4)
+#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN)
+#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE)
+#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE /
MAX_RBBALANCE)
+#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE /
MAX_RBBALANCE_NATIVE)
+
+/* flaw in the datasheet. we need some extra lines */
+#define MANUAL_LONG_EXP_SAFETY_DISTANCE20
+
/* active pixel array size */
#define OV5642_SENSOR_SIZE_X 2592
#define OV5642_SENSOR_SIZE_Y 1944
@@ -109,6 +137,9 @@
* 1:1 scale. Hopefully these restrictions will be removed in the future.
*/
+static int ov5642_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl);
+static int ov5642_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl);
+
struct regval_list {
u16 reg_num;
u8 value;
@@ -608,6 +639,145 @@ static struct regval_list ov5642_default_regs_finalise[]
= {
{ 0x, 0xff },
};
+static const struct v4l2_queryctrl ov5642_controls[] = {
+ {
+ .id = V4L2_CID_AUTOGAIN,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Automatic Gain Control,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 1,
+ },
+ {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Gain,
+ .minimum= 0,
+ .maximum= MAX_GAIN,
+ .step = 1,
+ .default_value = 0,
+ },
+ {
+ .id = V4L2_CID_AUTO_WHITE_BALANCE,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Automatic White Balance,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 1,
+ },
+ {
+ .id = V4L2_CID_BLUE_BALANCE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Blue Balance,
+ .minimum= 0,
+ .maximum= MAX_RBBALANCE,
+ .step = 1,
+ .default_value = DEFAULT_RBBALANCE,
+ },
+ {
+ .id = V4L2_CID_RED_BALANCE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Red Balance,
+ .minimum= 0,
+ .maximum= MAX_RBBALANCE,
+ .step = 1,
+ .default_value = DEFAULT_RBBALANCE,
+ },
+ {
+ .id = V4L2_CID_EXPOSURE_AUTO,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Automatic Exposure Control,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = V4L2_EXPOSURE_AUTO,
+ },
+ {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Exposure,
+ .minimum= 0,
+ .maximum= MAX_EXP,
+ .step = 1,
+ .default_value = 0,
+ },
+ /* vflip works out
Re: [PATCH] media: Added extensive feature set to the OV5642 camera driver
2011/8/16 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Tuesday 16 August 2011 14:58:58 Bastian Hecht wrote: The driver now supports arbitray resolutions (width up to 2592, height up to 720), automatic/manual gain, automatic/manual white balance, automatic/manual exposure control, vertical flip, brightness control, contrast control and saturation control. Additionally the following effects are available now: rotating the hue in the colorspace, gray scale image and solarize effect. That's a big patch, thus quite hard to review. What about splitting it in one patch per feature (or group of features, at least separating format configuration and controls) ? :-) Hello Laurent, I have reposted the my code split into 2 patches. The first with changes related to the image sizes and the other with all the controls. I hope that this separation makes it easy enough to review it. If not, tell me and I can split it up further. Thanks for reviewing, Bastian Hecht -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: Added extensive feature set to the OV5642 camera driver
The driver now supports arbitray resolutions (width up to 2592, height up to 720), automatic/manual gain, automatic/manual white balance, automatic/manual exposure control, vertical flip, brightness control, contrast control and saturation control. Additionally the following effects are available now: rotating the hue in the colorspace, gray scale image and solarize effect. Signed-of-by: Bastian Hecht hec...@gmail.com --- diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c index 6410bda..069a720 100644 --- a/drivers/media/video/ov5642.c +++ b/drivers/media/video/ov5642.c @@ -14,8 +14,10 @@ * published by the Free Software Foundation. */ +#include linux/bitops.h #include linux/delay.h #include linux/i2c.h +#include linux/kernel.h #include linux/slab.h #include linux/videodev2.h @@ -28,13 +30,25 @@ #define REG_CHIP_ID_HIGH 0x300a #define REG_CHIP_ID_LOW0x300b +#define REG_RED_GAIN_HIGH 0x3400 +#define REG_RED_GAIN_LOW 0x3401 +#define REG_BLUE_GAIN_HIGH 0x3404 +#define REG_BLUE_GAIN_LOW 0x3405 +#define REG_AWB_MANUAL 0x3406 +#define REG_EXP_HIGH 0x3500 +#define REG_EXP_MIDDLE 0x3501 +#define REG_EXP_LOW0x3502 +#define REG_EXP_GAIN_CTRL 0x3503 +#define REG_GAIN 0x350b +#define REG_EXTEND_FRAME_TIME_HIGH 0x350c +#define REG_EXTEND_FRAME_TIME_LOW 0x350d #define REG_WINDOW_START_X_HIGH0x3800 #define REG_WINDOW_START_X_LOW 0x3801 #define REG_WINDOW_START_Y_HIGH0x3802 #define REG_WINDOW_START_Y_LOW 0x3803 #define REG_WINDOW_WIDTH_HIGH 0x3804 #define REG_WINDOW_WIDTH_LOW 0x3805 -#define REG_WINDOW_HEIGHT_HIGH 0x3806 +#define REG_WINDOW_HEIGHT_HIGH 0x3806 #define REG_WINDOW_HEIGHT_LOW 0x3807 #define REG_OUT_WIDTH_HIGH 0x3808 #define REG_OUT_WIDTH_LOW 0x3809 @@ -44,19 +58,87 @@ #define REG_OUT_TOTAL_WIDTH_LOW0x380d #define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e #define REG_OUT_TOTAL_HEIGHT_LOW 0x380f +#define REG_FLIP_SUBSAMPLE 0x3818 +#define REG_OUTPUT_FORMAT 0x4300 +#define REG_ISP_CTRL_010x5001 +#define REG_DIGITAL_EFFECTS0x5580 +#define REG_HUE_COS0x5581 +#define REG_HUE_SIN0x5582 +#define REG_BLUE_SATURATION0x5583 +#define REG_RED_SATURATION 0x5584 +#define REG_CONTRAST 0x5588 +#define REG_BRIGHTNESS 0x5589 +#define REG_D_E_AUXILLARY 0x558a +#define REG_AVG_WINDOW_END_X_HIGH 0x5682 +#define REG_AVG_WINDOW_END_X_LOW 0x5683 +#define REG_AVG_WINDOW_END_Y_HIGH 0x5686 +#define REG_AVG_WINDOW_END_Y_LOW 0x5687 + +/* default values in native space */ +#define DEFAULT_RBBALANCE 0x400 +#define DEFAULT_CONTRAST 0x20 +#define DEFAULT_SATURATION 0x40 + +#define MAX_EXP_NATIVE 0x01 +#define MAX_GAIN_NATIVE0x1f +#define MAX_RBBALANCE_NATIVE 0x0fff +#define MAX_EXP0x +#define MAX_GAIN 0xff +#define MAX_RBBALANCE 0xff +#define MAX_HUE_TRIG_NATIVE0x80 + +#define OV5642_CONTROL_BLUE_SATURATION (V4L2_CID_PRIVATE_BASE + 0) +#define OV5642_CONTROL_RED_SATURATION (V4L2_CID_PRIVATE_BASE + 1) +#define OV5642_CONTROL_GRAY_SCALE (V4L2_CID_PRIVATE_BASE + 2) +#define OV5642_CONTROL_SOLARIZE(V4L2_CID_PRIVATE_BASE + 3) + +#define EXP_V4L2_TO_NATIVE(x) ((x) 4) +#define EXP_NATIVE_TO_V4L2(x) ((x) 4) +#define GAIN_V4L2_TO_NATIVE(x) ((x) * MAX_GAIN_NATIVE / MAX_GAIN) +#define GAIN_NATIVE_TO_V4L2(x) ((x) * MAX_GAIN / MAX_GAIN_NATIVE) +#define RBBALANCE_V4L2_TO_NATIVE(x) ((x) * MAX_RBBALANCE_NATIVE / MAX_RBBALANCE) +#define RBBALANCE_NATIVE_TO_V4L2(x) ((x) * MAX_RBBALANCE / MAX_RBBALANCE_NATIVE) + +/* flaw in the datasheet. we need some extra lines */ +#define MANUAL_LONG_EXP_SAFETY_DISTANCE20 + +/* active pixel array size */ +#define OV5642_SENSOR_SIZE_X 2592 +#define OV5642_SENSOR_SIZE_Y 1944 + +/* current maximum working size */ +#define OV5642_MAX_WIDTH OV5642_SENSOR_SIZE_X +#define OV5642_MAX_HEIGHT 720 + +/* default sizes */ +#define OV5642_DEFAULT_WIDTH 1280 +#define OV5642_DEFAULT_HEIGHT OV5642_MAX_HEIGHT + +/* minimum extra blanking */ +#define BLANKING_EXTRA_WIDTH 500 +#define BLANKING_EXTRA_HEIGHT 20 /* - * define standard resolution. - * Works currently only for up to 720 lines - * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720 + * the sensor's autoexposure is buggy when setting total_height low. + * It tries to expose longer than 1 frame period without taking care of it + * and this leads to weird
Re: [PATCH] V4L: sh_mobile_ceu_camera: fix Oops when USERPTR mapping fails
On Mon, 4 Jul 2011, Guennadi Liakhovetski wrote: If vb2_dma_contig_get_userptr() fails on a videobuffer, driver's .buf_init() method will not be called and the list will not be initialised. Trying to remove an uninitialised element from a list leads to a NULL-dereference. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Tested on mackerel. Tested-by: Bastian Hecht hec...@gmail.com Thanks, Bastian --- drivers/media/video/sh_mobile_ceu_camera.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c index 3ae5c9c..a851a3e 100644 --- a/drivers/media/video/sh_mobile_ceu_camera.c +++ b/drivers/media/video/sh_mobile_ceu_camera.c @@ -421,8 +421,12 @@ static void sh_mobile_ceu_videobuf_release(struct vb2_buffer *vb) pcdev-active = NULL; } - /* Doesn't hurt also if the list is empty */ - list_del_init(buf-queue); + /* + * Doesn't hurt also if the list is empty, but it hurts, if queuing the + * buffer failed, and .buf_init() hasn't been called + */ + if (buf-queue.next) + list_del_init(buf-queue); spin_unlock_irq(pcdev-lock); } -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: initial driver for ov5642 CMOS sensor
2011/6/27 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
Thanks for the patch.
On Friday 24 June 2011 12:57:36 Bastian Hecht wrote:
This is an initial driver release for the Omnivision 5642 CMOS sensor.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
new file mode 100644
index 000..3cdae97
--- /dev/null
+++ b/drivers/media/video/ov5642.c
@@ -0,0 +1,1011 @@
+/*
+ * Driver for OV5642 CMOS Image Sensor from Omnivision
+ *
+ * Copyright (C) 2011, Bastian Hecht hec...@gmail.com
+ *
+ * Based on Sony IMX074 Camera Driver
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on Omnivision OV7670 Camera Driver
+ * Copyright (C) 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+
+/* OV5642 registers */
+#define REG_CHIP_ID_HIGH 0x300a
+#define REG_CHIP_ID_LOW 0x300b
+
+#define REG_WINDOW_START_X_HIGH 0x3800
+#define REG_WINDOW_START_X_LOW 0x3801
+#define REG_WINDOW_START_Y_HIGH 0x3802
+#define REG_WINDOW_START_Y_LOW 0x3803
+#define REG_WINDOW_WIDTH_HIGH 0x3804
+#define REG_WINDOW_WIDTH_LOW 0x3805
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_LOW 0x3807
+#define REG_OUT_WIDTH_HIGH 0x3808
+#define REG_OUT_WIDTH_LOW 0x3809
+#define REG_OUT_HEIGHT_HIGH 0x380a
+#define REG_OUT_HEIGHT_LOW 0x380b
+#define REG_OUT_TOTAL_WIDTH_HIGH 0x380c
+#define REG_OUT_TOTAL_WIDTH_LOW 0x380d
+#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
+#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+
+/*
+ * define standard resolution.
+ * Works currently only for up to 720 lines
+ * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ */
+
+#define OV5642_WIDTH 1280
+#define OV5642_HEIGHT 720
+#define OV5642_TOTAL_WIDTH 3200
+#define OV5642_TOTAL_HEIGHT 2000
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
+
+struct regval_list {
+ u16 reg_num;
+ u8 value;
+};
+
+static struct regval_list ov5642_default_regs_init[] = {
+ { 0x3103, 0x93 },
+ { 0x3008, 0x82 },
+ { 0x3017, 0x7f },
+ { 0x3018, 0xfc },
+ { 0x3810, 0xc2 },
+ { 0x3615, 0xf0 },
+ { 0x3000, 0x0 },
+ { 0x3001, 0x0 },
+ { 0x3002, 0x0 },
+ { 0x3003, 0x0 },
+ { 0x3004, 0xff },
+ { 0x3030, 0x2b },
+ { 0x3011, 0x8 },
+ { 0x3010, 0x10 },
+ { 0x3604, 0x60 },
+ { 0x3622, 0x60 },
+ { 0x3621, 0x9 },
+ { 0x3709, 0x0 },
+ { 0x4000, 0x21 },
+ { 0x401d, 0x22 },
+ { 0x3600, 0x54 },
+ { 0x3605, 0x4 },
+ { 0x3606, 0x3f },
+ { 0x3c01, 0x80 },
+ { 0x300d, 0x22 },
+ { 0x3623, 0x22 },
+ { 0x5000, 0x4f },
+ { 0x5020, 0x4 },
+ { 0x5181, 0x79 },
+ { 0x5182, 0x0 },
+ { 0x5185, 0x22 },
+ { 0x5197, 0x1 },
+ { 0x5500, 0xa },
+ { 0x5504, 0x0 },
+ { 0x5505, 0x7f },
+ { 0x5080, 0x8 },
+ { 0x300e, 0x18 },
+ { 0x4610, 0x0 },
+ { 0x471d, 0x5 },
+ { 0x4708, 0x6 },
+ { 0x370c, 0xa0 },
+ { 0x5687, 0x94 },
+ { 0x501f, 0x0 },
+ { 0x5000, 0x4f },
+ { 0x5001, 0xcf },
+ { 0x4300, 0x30 },
+ { 0x4300, 0x30 },
+ { 0x460b, 0x35 },
+ { 0x471d, 0x0 },
+ { 0x3002, 0xc },
+ { 0x3002, 0x0 },
+ { 0x4713, 0x3 },
+ { 0x471c, 0x50 },
+ { 0x4721, 0x2 },
+ { 0x4402, 0x90 },
+ { 0x460c, 0x22 },
+ { 0x3815, 0x44 },
+ { 0x3503, 0x7 },
+ { 0x3501, 0x73 },
+ { 0x3502, 0x80 },
+ { 0x350b, 0x0 },
+ { 0x3818, 0xc8 },
+ { 0x3824, 0x11 },
+ { 0x3a00, 0x78 },
+ { 0x3a1a, 0x4 },
+ { 0x3a13, 0x30 },
+ { 0x3a18, 0x0 },
+ { 0x3a19, 0x7c },
+ { 0x3a08, 0x12 },
+ { 0x3a09, 0xc0 },
+ { 0x3a0a, 0xf },
+ { 0x3a0b, 0xa0 },
+ { 0x350c, 0x7 },
+ { 0x350d, 0xd0 },
+ { 0x3a0d, 0x8 },
+ { 0x3a0e, 0x6 },
+ { 0x3500, 0x0 },
+ { 0x3501, 0x0 },
+ { 0x3502, 0x0 },
+ { 0x350a, 0x0 },
+ { 0x350b, 0x0 },
+ { 0x3503, 0x0 },
+ { 0x3a0f, 0x3c },
+ { 0x3a10, 0x32 },
+ { 0x3a1b, 0x3c },
+ { 0x3a1e, 0x32 },
+ { 0x3a11, 0x80 },
+ { 0x3a1f, 0x20 },
+ { 0x3030, 0x2b },
+ { 0x3a02, 0x0 },
+ { 0x3a03, 0x7d },
+ { 0x3a04, 0x0
[PATCH] media: initial driver for ov5642 CMOS sensor
This is an initial driver release for the Omnivision 5642 CMOS sensor.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
new file mode 100644
index 000..3cdae97
--- /dev/null
+++ b/drivers/media/video/ov5642.c
@@ -0,0 +1,1011 @@
+/*
+ * Driver for OV5642 CMOS Image Sensor from Omnivision
+ *
+ * Copyright (C) 2011, Bastian Hecht hec...@gmail.com
+ *
+ * Based on Sony IMX074 Camera Driver
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on Omnivision OV7670 Camera Driver
+ * Copyright (C) 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+
+/* OV5642 registers */
+#define REG_CHIP_ID_HIGH 0x300a
+#define REG_CHIP_ID_LOW0x300b
+
+#define REG_WINDOW_START_X_HIGH0x3800
+#define REG_WINDOW_START_X_LOW 0x3801
+#define REG_WINDOW_START_Y_HIGH0x3802
+#define REG_WINDOW_START_Y_LOW 0x3803
+#define REG_WINDOW_WIDTH_HIGH 0x3804
+#define REG_WINDOW_WIDTH_LOW 0x3805
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_LOW 0x3807
+#define REG_OUT_WIDTH_HIGH 0x3808
+#define REG_OUT_WIDTH_LOW 0x3809
+#define REG_OUT_HEIGHT_HIGH0x380a
+#define REG_OUT_HEIGHT_LOW 0x380b
+#define REG_OUT_TOTAL_WIDTH_HIGH 0x380c
+#define REG_OUT_TOTAL_WIDTH_LOW0x380d
+#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
+#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+
+/*
+ * define standard resolution.
+ * Works currently only for up to 720 lines
+ * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ */
+
+#define OV5642_WIDTH 1280
+#define OV5642_HEIGHT 720
+#define OV5642_TOTAL_WIDTH 3200
+#define OV5642_TOTAL_HEIGHT2000
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
+
+struct regval_list {
+ u16 reg_num;
+ u8 value;
+};
+
+static struct regval_list ov5642_default_regs_init[] = {
+ { 0x3103, 0x93 },
+ { 0x3008, 0x82 },
+ { 0x3017, 0x7f },
+ { 0x3018, 0xfc },
+ { 0x3810, 0xc2 },
+ { 0x3615, 0xf0 },
+ { 0x3000, 0x0 },
+ { 0x3001, 0x0 },
+ { 0x3002, 0x0 },
+ { 0x3003, 0x0 },
+ { 0x3004, 0xff },
+ { 0x3030, 0x2b },
+ { 0x3011, 0x8 },
+ { 0x3010, 0x10 },
+ { 0x3604, 0x60 },
+ { 0x3622, 0x60 },
+ { 0x3621, 0x9 },
+ { 0x3709, 0x0 },
+ { 0x4000, 0x21 },
+ { 0x401d, 0x22 },
+ { 0x3600, 0x54 },
+ { 0x3605, 0x4 },
+ { 0x3606, 0x3f },
+ { 0x3c01, 0x80 },
+ { 0x300d, 0x22 },
+ { 0x3623, 0x22 },
+ { 0x5000, 0x4f },
+ { 0x5020, 0x4 },
+ { 0x5181, 0x79 },
+ { 0x5182, 0x0 },
+ { 0x5185, 0x22 },
+ { 0x5197, 0x1 },
+ { 0x5500, 0xa },
+ { 0x5504, 0x0 },
+ { 0x5505, 0x7f },
+ { 0x5080, 0x8 },
+ { 0x300e, 0x18 },
+ { 0x4610, 0x0 },
+ { 0x471d, 0x5 },
+ { 0x4708, 0x6 },
+ { 0x370c, 0xa0 },
+ { 0x5687, 0x94 },
+ { 0x501f, 0x0 },
+ { 0x5000, 0x4f },
+ { 0x5001, 0xcf },
+ { 0x4300, 0x30 },
+ { 0x4300, 0x30 },
+ { 0x460b, 0x35 },
+ { 0x471d, 0x0 },
+ { 0x3002, 0xc },
+ { 0x3002, 0x0 },
+ { 0x4713, 0x3 },
+ { 0x471c, 0x50 },
+ { 0x4721, 0x2 },
+ { 0x4402, 0x90 },
+ { 0x460c, 0x22 },
+ { 0x3815, 0x44 },
+ { 0x3503, 0x7 },
+ { 0x3501, 0x73 },
+ { 0x3502, 0x80 },
+ { 0x350b, 0x0 },
+ { 0x3818, 0xc8 },
+ { 0x3824, 0x11 },
+ { 0x3a00, 0x78 },
+ { 0x3a1a, 0x4 },
+ { 0x3a13, 0x30 },
+ { 0x3a18, 0x0 },
+ { 0x3a19, 0x7c },
+ { 0x3a08, 0x12 },
+ { 0x3a09, 0xc0 },
+ { 0x3a0a, 0xf },
+ { 0x3a0b, 0xa0 },
+ { 0x350c, 0x7 },
+ { 0x350d, 0xd0 },
+ { 0x3a0d, 0x8 },
+ { 0x3a0e, 0x6 },
+ { 0x3500, 0x0 },
+ { 0x3501, 0x0 },
+ { 0x3502, 0x0 },
+ { 0x350a, 0x0 },
+ { 0x350b, 0x0 },
+ { 0x3503, 0x0 },
+ { 0x3a0f, 0x3c },
+ { 0x3a10, 0x32 },
+ { 0x3a1b, 0x3c },
+ { 0x3a1e, 0x32 },
+ { 0x3a11, 0x80 },
+ { 0x3a1f, 0x20 },
+ { 0x3030, 0x2b },
+ { 0x3a02, 0x0 },
+ { 0x3a03, 0x7d },
+ { 0x3a04, 0x0 },
+ { 0x3a14, 0x0 },
+ { 0x3a15, 0x7d },
+ { 0x3a16, 0x0 },
+ { 0x3a00, 0x78 },
+ { 0x3a08, 0x9
Re: Capabilities of the Omap3 ISP driver
2011/5/30 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Monday 30 May 2011 23:39:13 Bastian Hecht wrote: 2011/5/30 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Sunday 29 May 2011 15:27:23 Bastian Hecht wrote: Hello Laurent, I'm on to a project that needs two synced separate small cameras for stereovision. I was thinking about realizing this on an DM3730 with 2 aptina csi2 cameras that are used in snapshot mode. As far as I know, the DM3730 doesn't have CSI2 interfaces. If I don't mix up datasheets, it is stated very clearly that 2 csi2 interfaces are supported. I took the datasheet at http://www.ti.com/litv/pdf/sprugn4k declared as AM/DM37x Multimedia Device Technical Reference Manual (Silicon Revision 1.x) (Rev. K) (PDF 26851 KB). The camera ISP implements three receivers which are named CSI2A, CSI1/CCP2B, and CSI2C. The CSI2A and CSI2C are MIPI D-PHY CSI2 compatible. on page 1070. Chapter 6 starts with the following disclaimer: NOTE: This chapter gives information about all modules and features in the high-tier device. To check availability of modules and features, see Section 1.5, AM/DM37x Family, and the device-specific data manual. In unavailable modules and features, the memory area is reserved, read is undefined, and write can lead to unpredictable behavior. And if you look at table 1-3 on page 195, the CSI2 receivers are not supported. OK, that potentially saved me tons of work! I saw that the omap4 has 2 csi2 interfaces (and I checked this note :). Unfortunately the panda board only leads out 1 csi2 channel. The questions that arise are: - is the ISP driver capable of running 2 concurrent cameras? Yes it can, but only one of them can use the CCDC, preview engine and resizer. The other will be captured directly to memory as raw data. You could capture both raw streams to memory, and then feed them alternatively through the rest of the pipeline. Whether this can work will depend on the image size and frame rate. Ok I will check if it is sufficient to do any conversions on the cpu. - is it possible to simulate a kind of video stream that is externally triggered (I would use a gpio line that simply triggers 10 times a sec) or would there arise problems with the csi2 protocoll (timeouts or similar)? I don't think there will be CSI2 issues (although I'm not an expert there) if you trigger the sensors externally. Nice, when the ISP side is probably no problem - do you have any experience with snapshot mode and know if cameras are capable of doing it at framerates about 10fps? It is just because snapshot mode sounds like taking 1 frame every now and then... can't they call it trigger mode? :) I haven't personally tried it, but 10fps doesn't sound impossible to reach with external triggers. Nice. -- Regards, Laurent Pinchart Thanks, Bastian Hecht -- 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
Capabilities of the Omap3 ISP driver
Hello Laurent, I'm on to a project that needs two synced separate small cameras for stereovision. It's for harvesting tomatoes in fact :) I was thinking about realizing this on an DM3730 with 2 aptina csi2 cameras that are used in snapshot mode. The questions that arise are: - is the ISP driver capable of running 2 concurrent cameras? - is it possible to simulate a kind of video stream that is externally triggered (I would use a gpio line that simply triggers 10 times a sec) or would there arise problems with the csi2 protocoll (timeouts or similar)? Best regards, Bastian Hecht -- 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: Current status report of mt9p031.
Hello Javier, 2011/5/4 javier Martin javier.mar...@vista-silicon.com: Hi, for those interested on mt9p031 working on the Beagleboard xM. I attach 2 patches here that must be applied to kernel-2.6.39-rc commit e8dad69408a9812d6bb42d03e74d2c314534a4fa These patches include a fix for the USB ethernet. What currently works: - Test suggested by Guennadi (http://download.open-technology.de/BeagleBoard_xM-MT9P031/). Known problems: 1. You might be required to create device node for the sensor manually: mknod /dev/v4l-subdev8 c 81 15 chown root:video /dev/v4l-subdev8 2. Images captured seem to be too dull and dark. Values of pixels seem always to low, it seems to me like MSB of each pixel were stuck at 0. I hope someone can help here. I once had a similar problem and found out that I had configured the shifter in the device-setup wrong. So 2 bits were shifted out and I had a dark image. best regards, Bastian Hecht Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: OMAP3 ISP deadlocks on my new arm
2011/4/27 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 27 April 2011 12:55:24 Bastian Hecht wrote: 2011/4/27 Bastian Hecht hec...@googlemail.com: 2011/4/26 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote: 2011/4/21 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote: Laurent Pinchart wrote: ... That's the ideal situation: sensors should not produce any data (or rather any transition on the VS/HS signals) when they're supposed to be stopped. Unfortunately that's not always easy, as some dumb sensors (or sensor-like hardware) can't be stopped. The ISP driver should be able to cope with that in a way that doesn't kill the system completely. I've noticed the same issue with a Caspa camera module and an OMAP3503-based Gumstix. I'll try to come up with a good fix. Hi Laurent, others, Do you think the cause for this is that the system is jammed in handling HS_VS interrupts triggered for every HS? That was my initial guess, yes. A quick fix for this could be just choosing either VS configuration when configuring the CCDC. Alternatively, HS_VS interrupts could be just disabled until omap3isp_configure_interface(). But as the sensor is sending images all the time, proper VS configuration would be needed, or the counting of lines in the CCDC (VD* interrupts) is affected as well. The VD0 interrupt, which is used to trigger an interrupt near the end of the frame, may be triggered one line too early on the first frame, or too late. But this is up to a configuration. I don't think it's a real issue to trigger it one line too early. Anything else? Hello Laurent, I've tried delaying the HS_VS interrupt enable to the CCDC configuration function, after configuring the bridge (and thus the HS/VS interrupt source selection). To my surprise it didn't fix the problem, I still get tons of HS_VS interrupts (10 in about 2.6 seconds) that kill the system. I'll need to hook a scope to the HS and VS signals. have you worked on this problem? Today in my setup I took a longer cable and ran again into the hs/vs interrupt storm (it still works with a short cable). I can tackle this issue too, but to avoid double work I wanted to ask if you worked out something in the meantime. In my case the issue was caused by a combination of two hardware design mistakes. The first one was to use a TXB0801 chip to translate the 3.3V sensor levels to the 1.8V OMAP levels. The TXB0801 4kΩ output impedance, combined with the OMAP3 100µA pull-ups on the HS and VS signals, produces a ~400mV voltage for low logic levels. Then, the XCLKA signal is next to the VS signal on the cable connecting the camera module to the OMAP board. When XCLKA is turned on, cross-talk produces a 400mV peak-to-peak noise on the VS signal. The combination of those two effects create a noisy VS signal that crosses the OMAP3 input level detection gap at high frequency, leading to an interrupt storm. The workaround is to disable the pull-ups on the HS and VS signals, the solution is to redesign the hardware to replace the level translators and reorganize signals on the camera module cable. Hi Laurent, Is your situation any similar ? The long data line (~35cm now at 24MHz) certainly can have an impact but I haven't measured any crosstalk so far. But I'm on another trail now. I found out that on my board the interrupt line is shared with 24: 0 INTC omap-iommu.0 Is the following scenario possible? 1. The omap-iommu isr is registered 2. The isp gets set up (it enables interrupts and disables them again at the end of the probe function) 3. Later I activate the xclk from within my driver 3a. isp_set_xclk() gets the lock omap3isp_get(isp) and so enable_interrupts() is called 3b. The new xclk on my chip makes my hardware create a hs/vs int (either crosstalk, another hardware bug like yours, or simply my chip sends a spurious interrupt for any reason) 3c. isp_set_xclk() puts the lock omap3isp_put(isp) and so disable_interrupts() is called Can there exist a race condition between the omap3isp raising the interrupt pin before 3c or after 3c? Argh... I oversaw that the omap3isp isr handler stays registered all time long so the theory is wrong. No luck :-) The first investigation step is to check which interrupt source causes the interrupts storm. The following test patch should help. diff --git a/drivers/media/video/omap3isp/isp.c b/drivers/media/video/omap3isp/isp.c index de2dec5..c4e6455 100644 --- a/drivers/media/video/omap3isp/isp.c +++ b/drivers/media/video/omap3isp/isp.c @@ -400,6 +400,38 @@ static inline void isp_isr_dbg(struct isp_device *isp, u32 irqstatus
Re: OMAP3 ISP deadlocks on my new arm
2011/4/26 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote: 2011/4/21 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote: Laurent Pinchart wrote: ... That's the ideal situation: sensors should not produce any data (or rather any transition on the VS/HS signals) when they're supposed to be stopped. Unfortunately that's not always easy, as some dumb sensors (or sensor-like hardware) can't be stopped. The ISP driver should be able to cope with that in a way that doesn't kill the system completely. I've noticed the same issue with a Caspa camera module and an OMAP3503-based Gumstix. I'll try to come up with a good fix. Hi Laurent, others, Do you think the cause for this is that the system is jammed in handling HS_VS interrupts triggered for every HS? That was my initial guess, yes. A quick fix for this could be just choosing either VS configuration when configuring the CCDC. Alternatively, HS_VS interrupts could be just disabled until omap3isp_configure_interface(). But as the sensor is sending images all the time, proper VS configuration would be needed, or the counting of lines in the CCDC (VD* interrupts) is affected as well. The VD0 interrupt, which is used to trigger an interrupt near the end of the frame, may be triggered one line too early on the first frame, or too late. But this is up to a configuration. I don't think it's a real issue to trigger it one line too early. Anything else? Hello Laurent, I've tried delaying the HS_VS interrupt enable to the CCDC configuration function, after configuring the bridge (and thus the HS/VS interrupt source selection). To my surprise it didn't fix the problem, I still get tons of HS_VS interrupts (10 in about 2.6 seconds) that kill the system. I'll need to hook a scope to the HS and VS signals. have you worked on this problem? Today in my setup I took a longer cable and ran again into the hs/vs interrupt storm (it still works with a short cable). I can tackle this issue too, but to avoid double work I wanted to ask if you worked out something in the meantime. In my case the issue was caused by a combination of two hardware design mistakes. The first one was to use a TXB0801 chip to translate the 3.3V sensor levels to the 1.8V OMAP levels. The TXB0801 4kΩ output impedance, combined with the OMAP3 100µA pull-ups on the HS and VS signals, produces a ~400mV voltage for low logic levels. Then, the XCLKA signal is next to the VS signal on the cable connecting the camera module to the OMAP board. When XCLKA is turned on, cross-talk produces a 400mV peak-to-peak noise on the VS signal. The combination of those two effects create a noisy VS signal that crosses the OMAP3 input level detection gap at high frequency, leading to an interrupt storm. The workaround is to disable the pull-ups on the HS and VS signals, the solution is to redesign the hardware to replace the level translators and reorganize signals on the camera module cable. Hi Laurent, Is your situation any similar ? The long data line (~35cm now at 24MHz) certainly can have an impact but I haven't measured any crosstalk so far. But I'm on another trail now. I found out that on my board the interrupt line is shared with 24: 0INTC omap-iommu.0 Is the following scenario possible? 1. The omap-iommu isr is registered 2. The isp gets set up (it enables interrupts and disables them again at the end of the probe function) 3. Later I activate the xclk from within my driver 3a. isp_set_xclk() gets the lock omap3isp_get(isp) and so enable_interrupts() is called 3b. The new xclk on my chip makes my hardware create a hs/vs int (either crosstalk, another hardware bug like yours, or simply my chip sends a spurious interrupt for any reason) 3c. isp_set_xclk() puts the lock omap3isp_put(isp) and so disable_interrupts() is called Can there exist a race condition between the omap3isp raising the interrupt pin before 3c or after 3c? If after 3c the omap-iommu isr loops forever as the omap3isp int flag is never cleared. I keep debbuging and trying to find further clues. Best regards, Bastian -- 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: OMAP3 ISP deadlocks on my new arm
2011/4/27 Bastian Hecht hec...@googlemail.com: 2011/4/26 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote: 2011/4/21 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote: Laurent Pinchart wrote: ... That's the ideal situation: sensors should not produce any data (or rather any transition on the VS/HS signals) when they're supposed to be stopped. Unfortunately that's not always easy, as some dumb sensors (or sensor-like hardware) can't be stopped. The ISP driver should be able to cope with that in a way that doesn't kill the system completely. I've noticed the same issue with a Caspa camera module and an OMAP3503-based Gumstix. I'll try to come up with a good fix. Hi Laurent, others, Do you think the cause for this is that the system is jammed in handling HS_VS interrupts triggered for every HS? That was my initial guess, yes. A quick fix for this could be just choosing either VS configuration when configuring the CCDC. Alternatively, HS_VS interrupts could be just disabled until omap3isp_configure_interface(). But as the sensor is sending images all the time, proper VS configuration would be needed, or the counting of lines in the CCDC (VD* interrupts) is affected as well. The VD0 interrupt, which is used to trigger an interrupt near the end of the frame, may be triggered one line too early on the first frame, or too late. But this is up to a configuration. I don't think it's a real issue to trigger it one line too early. Anything else? Hello Laurent, I've tried delaying the HS_VS interrupt enable to the CCDC configuration function, after configuring the bridge (and thus the HS/VS interrupt source selection). To my surprise it didn't fix the problem, I still get tons of HS_VS interrupts (10 in about 2.6 seconds) that kill the system. I'll need to hook a scope to the HS and VS signals. have you worked on this problem? Today in my setup I took a longer cable and ran again into the hs/vs interrupt storm (it still works with a short cable). I can tackle this issue too, but to avoid double work I wanted to ask if you worked out something in the meantime. In my case the issue was caused by a combination of two hardware design mistakes. The first one was to use a TXB0801 chip to translate the 3.3V sensor levels to the 1.8V OMAP levels. The TXB0801 4kΩ output impedance, combined with the OMAP3 100µA pull-ups on the HS and VS signals, produces a ~400mV voltage for low logic levels. Then, the XCLKA signal is next to the VS signal on the cable connecting the camera module to the OMAP board. When XCLKA is turned on, cross-talk produces a 400mV peak-to-peak noise on the VS signal. The combination of those two effects create a noisy VS signal that crosses the OMAP3 input level detection gap at high frequency, leading to an interrupt storm. The workaround is to disable the pull-ups on the HS and VS signals, the solution is to redesign the hardware to replace the level translators and reorganize signals on the camera module cable. Hi Laurent, Is your situation any similar ? The long data line (~35cm now at 24MHz) certainly can have an impact but I haven't measured any crosstalk so far. But I'm on another trail now. I found out that on my board the interrupt line is shared with 24: 0 INTC omap-iommu.0 Is the following scenario possible? 1. The omap-iommu isr is registered 2. The isp gets set up (it enables interrupts and disables them again at the end of the probe function) 3. Later I activate the xclk from within my driver 3a. isp_set_xclk() gets the lock omap3isp_get(isp) and so enable_interrupts() is called 3b. The new xclk on my chip makes my hardware create a hs/vs int (either crosstalk, another hardware bug like yours, or simply my chip sends a spurious interrupt for any reason) 3c. isp_set_xclk() puts the lock omap3isp_put(isp) and so disable_interrupts() is called Can there exist a race condition between the omap3isp raising the interrupt pin before 3c or after 3c? Argh... I oversaw that the omap3isp isr handler stays registered all time long so the theory is wrong. If after 3c the omap-iommu isr loops forever as the omap3isp int flag is never cleared. I keep debbuging and trying to find further clues. Best regards, Bastian -- 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: OMAP3 ISP deadlocks on my new arm
2011/4/21 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Sakari, On Tuesday 19 April 2011 09:31:05 Sakari Ailus wrote: Laurent Pinchart wrote: ... That's the ideal situation: sensors should not produce any data (or rather any transition on the VS/HS signals) when they're supposed to be stopped. Unfortunately that's not always easy, as some dumb sensors (or sensor-like hardware) can't be stopped. The ISP driver should be able to cope with that in a way that doesn't kill the system completely. I've noticed the same issue with a Caspa camera module and an OMAP3503-based Gumstix. I'll try to come up with a good fix. Hi Laurent, others, Do you think the cause for this is that the system is jammed in handling HS_VS interrupts triggered for every HS? That was my initial guess, yes. A quick fix for this could be just choosing either VS configuration when configuring the CCDC. Alternatively, HS_VS interrupts could be just disabled until omap3isp_configure_interface(). But as the sensor is sending images all the time, proper VS configuration would be needed, or the counting of lines in the CCDC (VD* interrupts) is affected as well. The VD0 interrupt, which is used to trigger an interrupt near the end of the frame, may be triggered one line too early on the first frame, or too late. But this is up to a configuration. I don't think it's a real issue to trigger it one line too early. Anything else? Hello Laurent, I've tried delaying the HS_VS interrupt enable to the CCDC configuration function, after configuring the bridge (and thus the HS/VS interrupt source selection). To my surprise it didn't fix the problem, I still get tons of HS_VS interrupts (10 in about 2.6 seconds) that kill the system. I'll need to hook a scope to the HS and VS signals. have you worked on this problem? Today in my setup I took a longer cable and ran again into the hs/vs interrupt storm (it still works with a short cable). I can tackle this issue too, but to avoid double work I wanted to ask if you worked out something in the meantime. Best regards, Bastian Hecht -- 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: OMAP3 ISP deadlocks on my new arm
2011/4/16 David Cohen daco...@gmail.com:
Hi Bastian,
On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht hec...@googlemail.com wrote:
Yeah!
S... when I initialized the the camera (loading a 108 bytes
register listing) I just let run the camera and sent images. So I
first realized a counter overflow if (count++ 10) after a few
seconds. But this seemed to be handled correctly (ignore and delete
HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
hang.
I modified my register listing so that the chip gets booted silently.
In
static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
.s_stream = framix_s_stream, ===
};
I correctly check the stream status now and enable/disable the camera
signals.
I am unsure whether the isp should be able to handle an ongoing data
stream independently of ISP_PIPELINE_STREAM_STOPPED.
streamoff should finish synchronously with last ongoing data. So, it
should have no ongoing data afterwards. Was that your question?
I formulated my reply a bit strange. I meant that that the ongoing
datastream from my camera module (even when the isp-stack is in
stream_stopped state) produces my problem. The question was if it
should be allowed for the camera to send data all time long or only
when it is told to do so by s_stream.
best regards,
Bastian Hecht
Br,
David Cohen
If you decide it should, I will gladly help you find out more, just
ask. It worked on an OMAP3530 before, but I do not know if it is the
hardware or isp software that changed. Unfortunately I can't get an
3530 anymore (I trashed mine...).
You helped me so much! Big thanks.
Bastian Hecht
2011/4/14 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
2011/4/13 Sakari Ailus sakari.ai...@maxwell.research.nokia.com:
Bastian Hecht wrote:
Hello people,
Hi Bastian,
I'm cc'ing Laurent.
I switched to the new DM3730 from IGEP and while it's supposed to be
(almost) the same as the 3530 Version the isp deadlocks
deterministically after I start capturing the second time with yavta.
Does the capture work the first time w/o issues?
Yes, I can always run yavta once capturing 4 frames (3 skipped, last
saved). It usually deadlocks when running yavta the second time but I had
1 successful 2nd try (out of 20 maybe).
All extra locking debug output is enabled in the kernel .config.
I'm not fully certain on what this exactly is that you have below, but
it looks like your system is staying in interrupt context all the time.
My guess is that the ISP is producing interrupts that the driver is not
handling properly, causing the interrupt handler to be called again
immediately.
Nice! OK, I'd like to fully understand the panic output, maybe you can
help there:
After
[ 376.016906] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44)
from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90
the IRQs get enabled again. Immediately our offending irq wants to get
served but noone is clearing it.
At some time, the timer interrupt triggers the watchdog for a kernel panic.
So the last exception block is the process context that is currently
active. But why are there 2 irq routines displayed? Is the middle one the
hardware handling that causes a software irq to be triggered (upper
block)?
So my next step could be to find the unhandled irq number?
If the problem is caused by an interrupt storm, the following patch will
make
your system responsive again after a couple of seconds (but will kill the
ISP
driver :-)). If it doesn't, the problem is likely caused by something else.
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index de2dec5..6497300 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
IRQ0STATUS_CCDC_VD0_IRQ |
IRQ0STATUS_CCDC_VD1_IRQ |
IRQ0STATUS_HS_VS_IRQ;
+ static unsigned int count = 0;
struct isp_device *isp = _isp;
u32 irqstatus;
int ret;
@@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
+ if (count++ 10) {
+ isp_disable_interrupts(isp);
+ return IRQ_HANDLED;
+ }
+
isp_isr_sbl(isp);
if (irqstatus IRQ0STATUS_CSIA_IRQ) {
Do you have the same sensor working on OMAP 3530?
I never had this problem on an OMAP 3530, although I better test it
again with the current setup. I try to get my hands on an 3530 today.
I am unsure if this is an ISP thing or a problem in the
interrupthandling
Re: OMAP3 ISP deadlocks on my new arm
Hello Sakari, 2011/4/13 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Bastian Hecht wrote: Hello people, Hi Bastian, I'm cc'ing Laurent. I switched to the new DM3730 from IGEP and while it's supposed to be (almost) the same as the 3530 Version the isp deadlocks deterministically after I start capturing the second time with yavta. Does the capture work the first time w/o issues? Yes, I can always run yavta once capturing 4 frames (3 skipped, last saved). It usually deadlocks when running yavta the second time but I had 1 successful 2nd try (out of 20 maybe). All extra locking debug output is enabled in the kernel .config. I'm not fully certain on what this exactly is that you have below, but it looks like your system is staying in interrupt context all the time. My guess is that the ISP is producing interrupts that the driver is not handling properly, causing the interrupt handler to be called again immediately. Nice! OK, I'd like to fully understand the panic output, maybe you can help there: After [ 376.016906] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44) from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90 the IRQs get enabled again. Immediately our offending irq wants to get served but noone is clearing it. At some time, the timer interrupt triggers the watchdog for a kernel panic. So the last exception block is the process context that is currently active. But why are there 2 irq routines displayed? Is the middle one the hardware handling that causes a software irq to be triggered (upper block)? So my next step could be to find the unhandled irq number? Do you have the same sensor working on OMAP 3530? I never had this problem on an OMAP 3530, although I better test it again with the current setup. I try to get my hands on an 3530 today. I am unsure if this is an ISP thing or a problem in the interrupthandling software. This has probably something to do with the ISP driver. :-) The first block is the watchdog that detects the deadlock. The last block is in the isp-code but how can it hang when trying to UNlock a spinlock? I am unsure about the 2nd block. The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I give it a shot here first. I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. Why so old kernel? I tried a newer version, but there I couldn't get it booting with my igep. The kernel unpacked and tried to boot but it froze. I decided to use a version that is officially is supported by the igep team. Thanks so much for this valuable guess! Bastian Hecht I think you'd be best off using this one: URL:http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/omap3isp-next-omap3isp Any ideas? Thanks for any help, Bastian Hecht [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks [ 190.071563] [c0031078] (unwind_backtrace+0x0/0xe4) from [c02baf24] (panic+0x50/0xd0) [ 190.079711] [c02baf24] (panic+0x50/0xd0) from [c00729e4] (softlockup_tick+0x134/0x158) [ 190.088043] [c00729e4] (softlockup_tick+0x134/0x158) from [c005612c] (update_process_times+0x28/0x48) [ 190.097656] [c005612c] (update_process_times+0x28/0x48) from [c00697bc] (tick_sched_timer+0x88/0xbc) [ 190.107177] [c00697bc] (tick_sched_timer+0x88/0xbc) from [c0061ff0] (__run_hrtimer+0x44/0x84) [ 190.116119] [c0061ff0] (__run_hrtimer+0x44/0x84) from [c0062144] (hrtimer_interrupt+0x114/0x2c8) [ 190.125305] [c0062144] (hrtimer_interrupt+0x114/0x2c8) from [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) [ 190.135437] [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) from [c00730e4] (handle_IRQ_event+0x24/0xe0) [ 190.145324] [c00730e4] (handle_IRQ_event+0x24/0xe0) from [c0074b80] (handle_level_irq+0x90/0xfc) [ 190.154510] [c0074b80] (handle_level_irq+0x90/0xfc) from [c002c06c] (asm_do_IRQ+0x6c/0x8c) [ 190.163177] [c002c06c] (asm_do_IRQ+0x6c/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) [ 190.176300] 3c80: 0020 c03c20d0 [ 190.184509] 3ca0: c0417240 da412000 0002 ded72e84 000a dec54640 [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 c0051ad8 2113 [ 190.200958] [c002c9f4] (__irq_svc+0x34/0x80) from [c0051ad8] (__do_softirq+0x3c/0xf8) [ 190.209167] [c0051ad8] (__do_softirq+0x3c/0xf8) from [c0051bd4] (irq_exit+0x40/0x8c) [ 190.217315] [c0051bd4] (irq_exit+0x40/0x8c) from [c002c070] (asm_do_IRQ+0x70/0x8c) [ 190.225280] [c002c070] (asm_do_IRQ+0x70/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 ded72e80 4013 ded72e84 [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 da413d68 bf01d4cc
Re: OMAP3 ISP deadlocks on my new arm
Yeah!
S... when I initialized the the camera (loading a 108 bytes
register listing) I just let run the camera and sent images. So I
first realized a counter overflow if (count++ 10) after a few
seconds. But this seemed to be handled correctly (ignore and delete
HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
hang.
I modified my register listing so that the chip gets booted silently.
In
static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
.s_stream = framix_s_stream, ===
};
I correctly check the stream status now and enable/disable the camera signals.
I am unsure whether the isp should be able to handle an ongoing data
stream independently of ISP_PIPELINE_STREAM_STOPPED.
If you decide it should, I will gladly help you find out more, just
ask. It worked on an OMAP3530 before, but I do not know if it is the
hardware or isp software that changed. Unfortunately I can't get an
3530 anymore (I trashed mine...).
You helped me so much! Big thanks.
Bastian Hecht
2011/4/14 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
2011/4/13 Sakari Ailus sakari.ai...@maxwell.research.nokia.com:
Bastian Hecht wrote:
Hello people,
Hi Bastian,
I'm cc'ing Laurent.
I switched to the new DM3730 from IGEP and while it's supposed to be
(almost) the same as the 3530 Version the isp deadlocks
deterministically after I start capturing the second time with yavta.
Does the capture work the first time w/o issues?
Yes, I can always run yavta once capturing 4 frames (3 skipped, last
saved). It usually deadlocks when running yavta the second time but I had
1 successful 2nd try (out of 20 maybe).
All extra locking debug output is enabled in the kernel .config.
I'm not fully certain on what this exactly is that you have below, but
it looks like your system is staying in interrupt context all the time.
My guess is that the ISP is producing interrupts that the driver is not
handling properly, causing the interrupt handler to be called again
immediately.
Nice! OK, I'd like to fully understand the panic output, maybe you can
help there:
After
[ 376.016906] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44)
from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90
the IRQs get enabled again. Immediately our offending irq wants to get
served but noone is clearing it.
At some time, the timer interrupt triggers the watchdog for a kernel panic.
So the last exception block is the process context that is currently
active. But why are there 2 irq routines displayed? Is the middle one the
hardware handling that causes a software irq to be triggered (upper
block)?
So my next step could be to find the unhandled irq number?
If the problem is caused by an interrupt storm, the following patch will make
your system responsive again after a couple of seconds (but will kill the ISP
driver :-)). If it doesn't, the problem is likely caused by something else.
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index de2dec5..6497300 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
IRQ0STATUS_CCDC_VD0_IRQ |
IRQ0STATUS_CCDC_VD1_IRQ |
IRQ0STATUS_HS_VS_IRQ;
+ static unsigned int count = 0;
struct isp_device *isp = _isp;
u32 irqstatus;
int ret;
@@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
+ if (count++ 10) {
+ isp_disable_interrupts(isp);
+ return IRQ_HANDLED;
+ }
+
isp_isr_sbl(isp);
if (irqstatus IRQ0STATUS_CSIA_IRQ) {
Do you have the same sensor working on OMAP 3530?
I never had this problem on an OMAP 3530, although I better test it
again with the current setup. I try to get my hands on an 3530 today.
I am unsure if this is an ISP thing or a problem in the
interrupthandling software.
This has probably something to do with the ISP driver. :-)
The first block is the watchdog that detects the deadlock. The last
block is in the isp-code but how can it hang when trying to UNlock a
spinlock? I am unsure about the 2nd block.
The assembler code of __irq_svc is located in
arch/arm/kernel/entry-armv.S Maybe I should try on
linux-...@lists.arm.linux.org.uk but I thought I give it a shot here
first.
I use the omap3isp-2.6.35.3-omap3isp branch from Laurent.
Why so old kernel?
I tried a newer version, but there I couldn't get it booting with my
igep. The kernel unpacked and tried to boot
OMAP3 ISP deadlocks on my new arm
Hello people, I switched to the new DM3730 from IGEP and while it's supposed to be (almost) the same as the 3530 Version the isp deadlocks deterministically after I start capturing the second time with yavta. All extra locking debug output is enabled in the kernel .config. I am unsure if this is an ISP thing or a problem in the interrupthandling software. The first block is the watchdog that detects the deadlock. The last block is in the isp-code but how can it hang when trying to UNlock a spinlock? I am unsure about the 2nd block. The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I give it a shot here first. I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. Any ideas? Thanks for any help, Bastian Hecht [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks [ 190.071563] [c0031078] (unwind_backtrace+0x0/0xe4) from [c02baf24] (panic+0x50/0xd0) [ 190.079711] [c02baf24] (panic+0x50/0xd0) from [c00729e4] (softlockup_tick+0x134/0x158) [ 190.088043] [c00729e4] (softlockup_tick+0x134/0x158) from [c005612c] (update_process_times+0x28/0x48) [ 190.097656] [c005612c] (update_process_times+0x28/0x48) from [c00697bc] (tick_sched_timer+0x88/0xbc) [ 190.107177] [c00697bc] (tick_sched_timer+0x88/0xbc) from [c0061ff0] (__run_hrtimer+0x44/0x84) [ 190.116119] [c0061ff0] (__run_hrtimer+0x44/0x84) from [c0062144] (hrtimer_interrupt+0x114/0x2c8) [ 190.125305] [c0062144] (hrtimer_interrupt+0x114/0x2c8) from [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) [ 190.135437] [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) from [c00730e4] (handle_IRQ_event+0x24/0xe0) [ 190.145324] [c00730e4] (handle_IRQ_event+0x24/0xe0) from [c0074b80] (handle_level_irq+0x90/0xfc) [ 190.154510] [c0074b80] (handle_level_irq+0x90/0xfc) from [c002c06c] (asm_do_IRQ+0x6c/0x8c) [ 190.163177] [c002c06c] (asm_do_IRQ+0x6c/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) [ 190.176300] 3c80: 0020 c03c20d0 [ 190.184509] 3ca0: c0417240 da412000 0002 ded72e84 000a dec54640 [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 c0051ad8 2113 [ 190.200958] [c002c9f4] (__irq_svc+0x34/0x80) from [c0051ad8] (__do_softirq+0x3c/0xf8) [ 190.209167] [c0051ad8] (__do_softirq+0x3c/0xf8) from [c0051bd4] (irq_exit+0x40/0x8c) [ 190.217315] [c0051bd4] (irq_exit+0x40/0x8c) from [c002c070] (asm_do_IRQ+0x70/0x8c) [ 190.225280] [c002c070] (asm_do_IRQ+0x70/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 ded72e80 4013 ded72e84 [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 da413d68 bf01d4cc bf01d4ec [ 190.254821] 3d60: 6013 [ 190.258361] [c002c9f4] (__irq_svc+0x34/0x80) from [bf01d4ec] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) [ 190.269165] [bf01d4ec] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) from [bf01f1d4] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) [ 190.281951] [bf01f1d4] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) from [c01fa76c] (__video_do_ioctl+0x1488/0x3bd0) [ 190.292877] [c01fa76c] (__video_do_ioctl+0x1488/0x3bd0) from [c01f8ee8] (__video_usercopy+0x2d0/0x414) [ 190.302581] [c01f8ee8] (__video_usercopy+0x2d0/0x414) from [c01f8370] (v4l2_unlocked_ioctl+0x38/0x3c) [ 190.312194] [c01f8370] (v4l2_unlocked_ioctl+0x38/0x3c) from [c00a6d6c] (vfs_ioctl+0x2c/0x6c) [ 190.321044] [c00a6d6c] (vfs_ioctl+0x2c/0x6c) from [c00a7448] (do_vfs_ioctl+0x4cc/0x514) [ 190.329437] [c00a7448] (do_vfs_ioctl+0x4cc/0x514) from [c00a74c4] (sys_ioctl+0x34/0x54) [ 190.337829] [c00a74c4] (sys_ioctl+0x34/0x54) from [c002ce40] (ret_fast_syscall+0x0/0x30) -- 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 deadlocks on my new arm
[ 376.258453] dca0: 000a deab8800 c0461080 c0773214 dea1dcc8 c0071ba0 c0054614 [ 376.22] dcc0: 6113 [ 376.270172] [c002da78] (__irq_svc+0x38/0xa0) from [c0054614] (__do_softirq+0x4c/0x128) [ 376.278503] [c0054614] (__do_softirq+0x4c/0x128) from [c0054740] (irq_exit+0x50/0x9c) [ 376.286712] [c0054740] (irq_exit+0x50/0x9c) from [c002d070] (asm_do_IRQ+0x70/0x8c) [ 376.294677] [c002d070] (asm_do_IRQ+0x70/0x8c) from [c002da78] (__irq_svc+0x38/0xa0) [ 376.302703] Exception stack(0xdea1dd08 to 0xdea1dd50) [ 376.307800] dd00: 0001 dea3e840 0110 0001dbb4 4013 dff0caa8 [ 376.316009] dd20: dff0cac4 dff0cac8 dff0caa8 deab8800 4013 c089e5fc dea1dd50 [ 376.324218] dd40: c0071ba0 c02e3dc4 2013 [ 376.329315] [c002da78] (__irq_svc+0x38/0xa0) from [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44) [ 376.338897] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44) from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90 [omap3_isp]) [ 376.351257] [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90 [omap3_isp]) from [bf02128c] (isp_video_streamon+0x15c/0x214 [omap3_isp]) [ 376.364044] [bf02128c] (isp_video_streamon+0x15c/0x214 [omap3_isp]) from [c0216b38] (__video_do_ioctl+0x1488/0x3bd0) [ 376.375000] [c0216b38] (__video_do_ioctl+0x1488/0x3bd0) from [c02152b4] (__video_usercopy+0x2d0/0x414) [ 376.384704] [c02152b4] (__video_usercopy+0x2d0/0x414) from [c0214708] (v4l2_unlocked_ioctl+0x38/0x3c) [ 376.394317] [c0214708] (v4l2_unlocked_ioctl+0x38/0x3c) from [c00b5f1c] (vfs_ioctl+0x2c/0x6c) [ 376.403137] [c00b5f1c] (vfs_ioctl+0x2c/0x6c) from [c00b6610] (do_vfs_ioctl+0x4e4/0x52c) [ 376.411529] [c00b6610] (do_vfs_ioctl+0x4e4/0x52c) from [c00b668c] (sys_ioctl+0x34/0x54) [ 376.419952] [c00b668c] (sys_ioctl+0x34/0x54) from [c002df40] (ret_fast_syscall+0x0/0x3c) [ 376.428436] ---[ end trace 1b75b31a2719ed1e ]--- 2011/4/13 Bastian Hecht hec...@googlemail.com: Hello people, I switched to the new DM3730 from IGEP and while it's supposed to be (almost) the same as the 3530 Version the isp deadlocks deterministically after I start capturing the second time with yavta. All extra locking debug output is enabled in the kernel .config. I am unsure if this is an ISP thing or a problem in the interrupthandling software. The first block is the watchdog that detects the deadlock. The last block is in the isp-code but how can it hang when trying to UNlock a spinlock? I am unsure about the 2nd block. The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I give it a shot here first. I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. Any ideas? Thanks for any help, Bastian Hecht [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks [ 190.071563] [c0031078] (unwind_backtrace+0x0/0xe4) from [c02baf24] (panic+0x50/0xd0) [ 190.079711] [c02baf24] (panic+0x50/0xd0) from [c00729e4] (softlockup_tick+0x134/0x158) [ 190.088043] [c00729e4] (softlockup_tick+0x134/0x158) from [c005612c] (update_process_times+0x28/0x48) [ 190.097656] [c005612c] (update_process_times+0x28/0x48) from [c00697bc] (tick_sched_timer+0x88/0xbc) [ 190.107177] [c00697bc] (tick_sched_timer+0x88/0xbc) from [c0061ff0] (__run_hrtimer+0x44/0x84) [ 190.116119] [c0061ff0] (__run_hrtimer+0x44/0x84) from [c0062144] (hrtimer_interrupt+0x114/0x2c8) [ 190.125305] [c0062144] (hrtimer_interrupt+0x114/0x2c8) from [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) [ 190.135437] [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) from [c00730e4] (handle_IRQ_event+0x24/0xe0) [ 190.145324] [c00730e4] (handle_IRQ_event+0x24/0xe0) from [c0074b80] (handle_level_irq+0x90/0xfc) [ 190.154510] [c0074b80] (handle_level_irq+0x90/0xfc) from [c002c06c] (asm_do_IRQ+0x6c/0x8c) [ 190.163177] [c002c06c] (asm_do_IRQ+0x6c/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) [ 190.176300] 3c80: 0020 c03c20d0 [ 190.184509] 3ca0: c0417240 da412000 0002 ded72e84 000a dec54640 [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 c0051ad8 2113 [ 190.200958] [c002c9f4] (__irq_svc+0x34/0x80) from [c0051ad8] (__do_softirq+0x3c/0xf8) [ 190.209167] [c0051ad8] (__do_softirq+0x3c/0xf8) from [c0051bd4] (irq_exit+0x40/0x8c) [ 190.217315] [c0051bd4] (irq_exit+0x40/0x8c) from [c002c070] (asm_do_IRQ+0x70/0x8c) [ 190.225280] [c002c070] (asm_do_IRQ+0x70/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 ded72e80 4013 ded72e84 [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 da413d68 bf01d4cc bf01d4ec [ 190.254821] 3d60: 6013 [ 190.258361] [c002c9f4
Re: OMAP3 ISP outputs 5555 5555 5555 5555 ...
2011/3/30 Bastian Hecht hec...@googlemail.com: 2011/3/30 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 30 March 2011 11:41:44 Bastian Hecht wrote: 2011/3/29 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Friday 25 March 2011 13:34:10 Bastian Hecht wrote: 2011/3/24 Bastian Hecht hec...@googlemail.com: 2011/3/24 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Thursday 24 March 2011 10:59:01 Bastian Hecht wrote: 2011/3/22 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 22 March 2011 17:11:04 Bastian Hecht wrote: Hello omap isp devs, maybe you can help me, I am a bit desperate with my current cam problem: I use a ov5642 chip and get only 0x55 in my data output when I use a camclk 1 MHz. With 1 MHz data rate from the camera chip to the omap all works (well the colorspace is strange - it's greenish, but that is not my main concern). I looked up the data on the oscilloscope and all flanks seem to be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data pins are flickering fine. Looks like a picture. I found that the isp stats module uses 0x55 as a magic number but I don't see why it should confuse my readout. I use 2592x1944 raw bayer output via the ccdc. Next to the logical right config I tried all possible configurations of vs/hs active high and low on camera and isp. The isp gets the vs flanks right as the images come out in time (sometimes it misses 1 frame). Anyone of you had this behaviour before? How do you capture images ? yavta will fill buffers with 0x55 before queueing them, so this might indicate that no data is written to the buffer at all. Yes I use yavta. So what does that all mean? It means that the ISP doesn't write data to the buffer. I have no idea why. This simple and clear statement directly led me to the problem :) There was no cam_wen (write enable) pin on both my camera boards. The ISP on the other hand is configured by default to expect it. So I only captured images when my data lanes luckily pulled up the omap wen pin by induction. In ccdc_config_sync_if() I added: /* HACK */ printk(KERN_ALERT Disable wen\n); syn_mode = ~ISPCCDC_SYN_MODE_WEN; So is this something to add to the platform data? I can prepare my very first kernel patch :) The WEN bit controls whether the CCDC module writes to memory or not. It's not supposed to interact with the external cam_wen signal. If you clear the WEN bit, the CCDC is supposed not to write data to memory at all. What you might need to check is the EXWEN bit in the same register. It controls whether the CCDC uses the cam_wen signal or not. The EXWEN bit should already be set to zero by the driver though. Does clearing the WEN bit fix your issue ? Hi Laurent, As I remember (I currently haven't the datasheet available) the wen signal is an input from the camera That's correct. and the SYN_MODE_WEN makes check this signal. According to the TRM, SYN_MODE_EXWEN control whether the cam_wen signal is used or not, and SYN_MODE_WEN controls whether the CCDC captures data to memory or not. Disabling the SYN_MODE_WEN solved my problem and I can reliably read images with 24 MHz datarate on the parallel bus. Artefacts are gone that I had before with 1 MHz, too. If you capture data at the CCDC output, clearing SYN_MODE_WEN is supposed to disable capture completely. Could you double-check your modifications ? Hi Laurent, I fetched the documentation and see what you mean.Doesn't make much sense. I'll double-check soon. Hi, when I wanted to try out the WEN bit I updated to the newest kernel head. It indeed works now whether I disable or enable the SYN_MODE_WEN. So the error must have been eliminated by other patches in the meantime. best regards, Bastian regards, Bastian -- 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: OMAP3 ISP outputs 5555 5555 5555 5555 ...
2011/3/29 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Friday 25 March 2011 13:34:10 Bastian Hecht wrote: 2011/3/24 Bastian Hecht hec...@googlemail.com: 2011/3/24 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Thursday 24 March 2011 10:59:01 Bastian Hecht wrote: 2011/3/22 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 22 March 2011 17:11:04 Bastian Hecht wrote: Hello omap isp devs, maybe you can help me, I am a bit desperate with my current cam problem: I use a ov5642 chip and get only 0x55 in my data output when I use a camclk 1 MHz. With 1 MHz data rate from the camera chip to the omap all works (well the colorspace is strange - it's greenish, but that is not my main concern). I looked up the data on the oscilloscope and all flanks seem to be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data pins are flickering fine. Looks like a picture. I found that the isp stats module uses 0x55 as a magic number but I don't see why it should confuse my readout. I use 2592x1944 raw bayer output via the ccdc. Next to the logical right config I tried all possible configurations of vs/hs active high and low on camera and isp. The isp gets the vs flanks right as the images come out in time (sometimes it misses 1 frame). Anyone of you had this behaviour before? How do you capture images ? yavta will fill buffers with 0x55 before queueing them, so this might indicate that no data is written to the buffer at all. Yes I use yavta. So what does that all mean? It means that the ISP doesn't write data to the buffer. I have no idea why. This simple and clear statement directly led me to the problem :) There was no cam_wen (write enable) pin on both my camera boards. The ISP on the other hand is configured by default to expect it. So I only captured images when my data lanes luckily pulled up the omap wen pin by induction. In ccdc_config_sync_if() I added: /* HACK */ printk(KERN_ALERT Disable wen\n); syn_mode = ~ISPCCDC_SYN_MODE_WEN; So is this something to add to the platform data? I can prepare my very first kernel patch :) The WEN bit controls whether the CCDC module writes to memory or not. It's not supposed to interact with the external cam_wen signal. If you clear the WEN bit, the CCDC is supposed not to write data to memory at all. What you might need to check is the EXWEN bit in the same register. It controls whether the CCDC uses the cam_wen signal or not. The EXWEN bit should already be set to zero by the driver though. Does clearing the WEN bit fix your issue ? Hi Laurent, As I remember (I currently haven't the datasheet available) the wen signal is an input from the camera and the SYN_MODE_WEN makes check this signal. Disabling the SYN_MODE_WEN solved my problem and I can reliably read images with 24 MHz datarate on the parallel bus. Artefacts are gone that I had before with 1 MHz, too. Is this too small for an own patch or could I send one? best regards, Bastian -- 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: OMAP3 ISP outputs 5555 5555 5555 5555 ...
2011/3/30 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 30 March 2011 11:41:44 Bastian Hecht wrote: 2011/3/29 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Friday 25 March 2011 13:34:10 Bastian Hecht wrote: 2011/3/24 Bastian Hecht hec...@googlemail.com: 2011/3/24 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Thursday 24 March 2011 10:59:01 Bastian Hecht wrote: 2011/3/22 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 22 March 2011 17:11:04 Bastian Hecht wrote: Hello omap isp devs, maybe you can help me, I am a bit desperate with my current cam problem: I use a ov5642 chip and get only 0x55 in my data output when I use a camclk 1 MHz. With 1 MHz data rate from the camera chip to the omap all works (well the colorspace is strange - it's greenish, but that is not my main concern). I looked up the data on the oscilloscope and all flanks seem to be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data pins are flickering fine. Looks like a picture. I found that the isp stats module uses 0x55 as a magic number but I don't see why it should confuse my readout. I use 2592x1944 raw bayer output via the ccdc. Next to the logical right config I tried all possible configurations of vs/hs active high and low on camera and isp. The isp gets the vs flanks right as the images come out in time (sometimes it misses 1 frame). Anyone of you had this behaviour before? How do you capture images ? yavta will fill buffers with 0x55 before queueing them, so this might indicate that no data is written to the buffer at all. Yes I use yavta. So what does that all mean? It means that the ISP doesn't write data to the buffer. I have no idea why. This simple and clear statement directly led me to the problem :) There was no cam_wen (write enable) pin on both my camera boards. The ISP on the other hand is configured by default to expect it. So I only captured images when my data lanes luckily pulled up the omap wen pin by induction. In ccdc_config_sync_if() I added: /* HACK */ printk(KERN_ALERT Disable wen\n); syn_mode = ~ISPCCDC_SYN_MODE_WEN; So is this something to add to the platform data? I can prepare my very first kernel patch :) The WEN bit controls whether the CCDC module writes to memory or not. It's not supposed to interact with the external cam_wen signal. If you clear the WEN bit, the CCDC is supposed not to write data to memory at all. What you might need to check is the EXWEN bit in the same register. It controls whether the CCDC uses the cam_wen signal or not. The EXWEN bit should already be set to zero by the driver though. Does clearing the WEN bit fix your issue ? Hi Laurent, As I remember (I currently haven't the datasheet available) the wen signal is an input from the camera That's correct. and the SYN_MODE_WEN makes check this signal. According to the TRM, SYN_MODE_EXWEN control whether the cam_wen signal is used or not, and SYN_MODE_WEN controls whether the CCDC captures data to memory or not. Disabling the SYN_MODE_WEN solved my problem and I can reliably read images with 24 MHz datarate on the parallel bus. Artefacts are gone that I had before with 1 MHz, too. If you capture data at the CCDC output, clearing SYN_MODE_WEN is supposed to disable capture completely. Could you double-check your modifications ? Hi Laurent, I fetched the documentation and see what you mean.Doesn't make much sense. I'll double-check soon. regards, Bastian -- 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: OMAP3 ISP outputs 5555 5555 5555 5555 ...
2011/3/24 Bastian Hecht hec...@googlemail.com: 2011/3/24 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Thursday 24 March 2011 10:59:01 Bastian Hecht wrote: 2011/3/22 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Tuesday 22 March 2011 17:11:04 Bastian Hecht wrote: Hello omap isp devs, maybe you can help me, I am a bit desperate with my current cam problem: I use a ov5642 chip and get only 0x55 in my data output when I use a camclk 1 MHz. With 1 MHz data rate from the camera chip to the omap all works (well the colorspace is strange - it's greenish, but that is not my main concern). I looked up the data on the oscilloscope and all flanks seem to be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data pins are flickering fine. Looks like a picture. I found that the isp stats module uses 0x55 as a magic number but I don't see why it should confuse my readout. I use 2592x1944 raw bayer output via the ccdc. Next to the logical right config I tried all possible configurations of vs/hs active high and low on camera and isp. The isp gets the vs flanks right as the images come out in time (sometimes it misses 1 frame). Anyone of you had this behaviour before? How do you capture images ? yavta will fill buffers with 0x55 before queueing them, so this might indicate that no data is written to the buffer at all. Yes I use yavta. So what does that all mean? It means that the ISP doesn't write data to the buffer. I have no idea why. This simple and clear statement directly led me to the problem :) There was no cam_wen (write enable) pin on both my camera boards. The ISP on the other hand is configured by default to expect it. So I only captured images when my data lanes luckily pulled up the omap wen pin by induction. In ccdc_config_sync_if() I added: /* HACK */ printk(KERN_ALERT Disable wen\n); syn_mode = ~ISPCCDC_SYN_MODE_WEN; So is this something to add to the platform data? I can prepare my very first kernel patch :) cheers, Bastian OK, I keep trying to find the reason. Thank you for answering. - Bastian As far as I understand things: The isp gets a new frame start. Then it counts up the lines as I receive a vd0 interrupt (I added a printk at the isr). In between the isp doesn't write/dma-transfer any data. I double- checked the pclk-line but I see nice flanks. yavta Output with 4MHz: Device /dev/video2 opened: OMAP3 ISP CCDC output (media). Video format set: width: 2592 height: 1944 buffer size: 10077696 Video format: BA10 (30314142) 2592x1944 2 buffers requested. length: 10077696 offset: 0 Buffer 0 mapped at address 0x4016e000. length: 10077696 offset: 10080256 Buffer 1 mapped at address 0x40b0b000. [ 528.454376] pad_op 4, framix addr: dea0a800 [ 528.462341] s_stream is it! enable: 1 [ 530.026184] last line of image received 0 (0) [-] 0 10077696 bytes 530.213853 1300960526.930187 -0.001 fps [ 531.558898] last line of image received 1 (1) [-] 1 10077696 bytes 531.746555 1300960528.462828 0.652 fps [ 533.091613] last line of image received [ 533.098571] s_stream is it! enable: 0 Captured 2 frames in 3.075627 seconds (0.650274 fps, 6553262.798122 B/s). -- 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: OMAP3 ISP outputs 5555 5555 5555 5555 ...
2011/3/22 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Tuesday 22 March 2011 17:11:04 Bastian Hecht wrote: Hello omap isp devs, maybe you can help me, I am a bit desperate with my current cam problem: I use a ov5642 chip and get only 0x55 in my data output when I use a camclk 1 MHz. With 1 MHz data rate from the camera chip to the omap all works (well the colorspace is strange - it's greenish, but that is not my main concern). I looked up the data on the oscilloscope and all flanks seem to be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data pins are flickering fine. Looks like a picture. I found that the isp stats module uses 0x55 as a magic number but I don't see why it should confuse my readout. I use 2592x1944 raw bayer output via the ccdc. Next to the logical right config I tried all possible configurations of vs/hs active high and low on camera and isp. The isp gets the vs flanks right as the images come out in time (sometimes it misses 1 frame). Anyone of you had this behaviour before? How do you capture images ? yavta will fill buffers with 0x55 before queueing them, so this might indicate that no data is written to the buffer at all. Yes I use yavta. So what does that all mean? As far as I understand things: The isp gets a new frame start. Then it counts up the lines as I receive a vd0 interrupt (I added a printk at the isr). In between the isp doesn't write/dma-transfer any data. I double-checked the pclk-line but I see nice flanks. yavta Output with 4MHz: Device /dev/video2 opened: OMAP3 ISP CCDC output (media). Video format set: width: 2592 height: 1944 buffer size: 10077696 Video format: BA10 (30314142) 2592x1944 2 buffers requested. length: 10077696 offset: 0 Buffer 0 mapped at address 0x4016e000. length: 10077696 offset: 10080256 Buffer 1 mapped at address 0x40b0b000. [ 528.454376] pad_op 4, framix addr: dea0a800 [ 528.462341] s_stream is it! enable: 1 [ 530.026184] last line of image received 0 (0) [-] 0 10077696 bytes 530.213853 1300960526.930187 -0.001 fps [ 531.558898] last line of image received 1 (1) [-] 1 10077696 bytes 531.746555 1300960528.462828 0.652 fps [ 533.091613] last line of image received [ 533.098571] s_stream is it! enable: 0 Captured 2 frames in 3.075627 seconds (0.650274 fps, 6553262.798122 B/s). cheers, Bastian Hecht -- 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
OMAP3 ISP outputs 5555 5555 5555 5555 ...
Hello omap isp devs, maybe you can help me, I am a bit desperate with my current cam problem: I use a ov5642 chip and get only 0x55 in my data output when I use a camclk 1 MHz. With 1 MHz data rate from the camera chip to the omap all works (well the colorspace is strange - it's greenish, but that is not my main concern). I looked up the data on the oscilloscope and all flanks seem to be fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data pins are flickering fine. Looks like a picture. I found that the isp stats module uses 0x55 as a magic number but I don't see why it should confuse my readout. I use 2592x1944 raw bayer output via the ccdc. Next to the logical right config I tried all possible configurations of vs/hs active high and low on camera and isp. The isp gets the vs flanks right as the images come out in time (sometimes it misses 1 frame). Anyone of you had this behaviour before? Thanks so much for reading this, Bastian Hecht -- 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
Where to find 8-bit sbggr patch for omap3-isp
Hello dear omap-isp developers, I'm working with a OV5642 sensor with an 8-bit parallel bus. I'm referring to this patch: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/29876/match=sgrbg8 Michael, you say that the patch applies to media-0005-omap3isp from Laurent. I cannot see it in the repo: http://git.linuxtv.org/pinchartl/media.git?a=blob;f=drivers/media/video/omap3-isp/ispccdc.c;h=5ff9d14ce71099cc672e71e2bd1d7ca619bbcc98;hb=media-0005-omap3isp Hasn't the patch been merged into your tree yet, Laurent? Or am I looking at the wrong spot? Thanks for help, Bastian Hecht -- 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: can't register subdev for new sensor driver mt9t001
Hi Loic, in my last post, make sure you return a v4l2_mbus_framefmt structure that contain yuv 720x480. Else the framework thinks your driver cannot supply this format. I do not know the exact enums myself, try to grep it in the linux kernel includes. In my test driver I added a printk(KERN_ALERT blabla); to all subdev calls to see when the framework calls which functions. good luck, Bastian 2011/3/2 Loïc Akue akue.l...@gmail.com: Hi Bastien, Me again =) Thank you for your previous reply. I added some code, so my saa7113 drivers could be compatible with the new media framework. But I still can get some video data, from my sub-device. I saw in a mailing list that you had a similar issue, could you please help me on this? root@cm-t35:~# ./media-ctl -r -l 'saa7115 3-0024:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] My first problem appears when I try to configure my pads before trying to capture root@cm-t35:~# ./media-ctl -f 'saa7115 3-0024:0[UYVY 720x480], OMAP3 ISP CCDC:2[UYVY 720x480]' Setting up format UYVY 720x480 on pad saa7115 3-0024/0 Format set: UYVY 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0 Format set: SGRBG10 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/2 Format set: SGRBG10 720x479 Setting up format SGRBG10 720x479 on pad OMAP3 ISP AEWB/0 Unable to set format: Invalid argument (-22) Setting up format SGRBG10 720x479 on pad OMAP3 ISP AF/0 Unable to set format: Invalid argument (-22) Setting up format SGRBG10 720x479 on pad OMAP3 ISP histogram/0 Unable to set format: Invalid argument (-22) Then, when I run this yavta command : root@cm-t35:~# ./yavta -f UYVY -s 720x480 -n 4 --capture=4 --skip 3 -F $(./media -ctl -e OMAP3 ISP CCDC output) Device /dev/video2 opened: OMAP3 ISP CCDC output (media). Video format set: width: 720 height: 480 buffer size: 691200 Video format: UYVY (59565955) 720x480 4 buffers requested. length: 691200 offset: 0 Buffer 0 mapped at address 0x40306000. length: 691200 offset: 692224 Buffer 1 mapped at address 0x40417000. length: 691200 offset: 1384448 Buffer 2 mapped at address 0x404d1000. length: 691200 offset: 2076672 Buffer 3 mapped at address 0x405ed000. Unable to start streaming: 22. And the system hangs. Do you have any idea where to look? Regards Loïc -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3-isp: can't register subdev for new sensor driver mt9t001
Hi,
when you try to set a format in the pipeline, the sensor gets asked if
he can support this solution.
static int xxx_get_format(struct v4l2_subdev *subdev,
struct v4l2_subdev_fh *fh,
struct v4l2_subdev_format *fmt)
{
struct v4l2_mbus_framefmt format;
format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
format.width = MT9P031_MAX_WIDTH;
format.height = MT9P031_MAX_HEIGHT;
format.field = V4L2_FIELD_NONE;
format.colorspace = V4L2_COLORSPACE_SRGB;
fmt-format = format;
}
This is a simplified version of what you might need. Look the
mechanisms up in other code samples.
The function must be registered in
static struct v4l2_subdev_pad_ops framix_subdev_pad_ops = {
.enum_mbus_code = mt9t001_enum_mbus_code,
.enum_frame_size = mt9t001_enum_frame_size,
.get_fmt = xxx_get_format,
.set_fmt = mt9t001_set_format,
.get_crop = mt9t001_get_crop,
.set_crop = mt9t001_set_crop,
};
cheers,
Bastian
2011/2/28 Loïc Akue akue.l...@gmail.com:
Hi,
Thank you for your reply,
I finally solved my problem. My saa7113 driver code wasn't fully adapted to
work with the new media framework.
I tried to use the media-ctl and yavta programs for testing. Here are my
logs :
./media-ctl -r -l 'saa7115 3-0024:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
CCDC:1-OMAP3 ISP CCDC output:0[1]'
Resetting all links to inactive
Setting up link 16:0 - 5:0 [1]
Setting up link 5:1 - 6:0 [1]
root@cm-t35:~# ./media-ctl -f 'saa7115 3-0024:0[UYVY 720x480], OMAP3 ISP
CCDC:2[UYVY 720x480]'
Setting up format UYVY 720x480 on pad saa7115 3-0024/0
Unable to set format: Invalid argument (-22)
Could it be due to a lack of information provided by my saa7113 driver, or
is it due to a bad understanding of the media-ctl app.
Regards
--
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
media-ctl and omap-isp kernel compatibility issue
Hello omap video stack hackers, some months ago I worked with the mt9p031 sensor from aptina. Unfortunately had to switch to another video chip and I try to achieve the same stage as with my old device. That means the new chip (OV5642) already is up, configured and sends data over the parallel bus. I pulled the new media-ctl tool from git://git.ideasonboard.org/media-ctl.git and compiled it giving the headers from my kernel pull from git://gitorious.org/maemo-multimedia/omap3isp-rx51.git (devel) Some enums are undefined: media.c:47: error: ‘MEDIA_LINK_FLAG_ACTIVE’ undeclared media.c:289: error: ‘MEDIA_ENTITY_TYPE_NODE’ undeclared media.c:290: error: ‘MEDIA_ENTITY_TYPE_SUBDEV’ undeclared So what repos should I go for these days? Is git://gitorious.org/maemo-multimedia/omap3isp-rx51.git ok or should I switch to some other repo? Or is media-ctl just outdated? Thanks for help, Bastian Hecht -- 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 media framework user space usage
Hello,
I succesfully got out images reliably. I just the nokia-tree and mixed
up your mt9t031 and Laurent's mt9t001 code. It's just a barebone that
gets images in default size. It's not cleaned up yet, but I post what
I have.
Greetings,
Bastian
2010/12/6 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Thu, 4 Nov 2010, Laurent Pinchart wrote:
Hi Bastian,
Hi Bastian, all
Have you or anyone ben successful getting mt9p031 to work with the omap3
ISP driver? If so - can I have the code? Or even if it never worked -
could you post the latest version of your driver and platform bindings?
Thanks
Guennadi
On Tuesday 02 November 2010 11:31:28 Bastian Hecht wrote:
I am the first guy needing a 12 bit-bus?
Yes you are :-) You will need to implement 12 bit support in the ISP
driver, or start by hacking the sensor driver to report a 10 bit format
(2 bits will be lost but you should still be able to capture an image).
Isn't that an officially supported procedure to drop the least
significant bits?
You gave me the isp configuration
.bus = { .parallel = {
.data_lane_shift = 1,
...
that instructs the isp to use 10 of the 12 bits.
If you don't need the full 12 bits, sure, that should work.
Second thing is, the yavta app now gets stuck while dequeuing a buffer.
strace ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F
/dev/video2 ...
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_STREAMON, 0xbec11154) = 0
ioctl(3, VIDIOC_DQBUF
strace gets stuck in mid of this line.
Somehow the ISP_ENABLE_IRQ register was reset at some point that is
unclear to me. When I put it on again manually yavta succeeds to read
the frames.
That's weird. Let me know if you can reproduce the problem.
Unfortunately the image consists of black pixels only. We found out that
the
2.8V voltage regulator got broken in the course of development - the 1.8V
logic still worked but the ADC did not...
But the heck - I was never that close :)
--
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
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
/*
* arch/arm/mach-omap2/board-bastix.c
*
* Copyright (C) 2010 Bastian Hecht hec...@gmail.com
*
* based on
*
* Copyright (C) 2008 Nokia Corporation
*
* Contact: Sakari Ailus sakari.ai...@nokia.com
* Tuukka Toivonen tuukka.o.toivo...@nokia.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA
*
*/
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/delay.h
#include linux/mm.h
#include linux/platform_device.h
#include linux/videodev2.h
#include asm/gpio.h
#include plat/control.h
#include ../../../drivers/media/video/isp/isp.h
#include ../../../drivers/media/video/isp/ispreg.h
#include media/mt9t001.h
#include devices.h
#define GPIO_DIR_OUTPUT 0
// IGEP CAM BUS NUM
#define BASTIX_CAM_I2C_BUS_NUM 2
static int __init cam_init(void)
{
return 0;
}
static int bastix_configure_interface(struct v4l2_subdev *subdev,
int width, int height)
{
struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
//isp_set_pixel_clock(isp, 0);
return 0;
}
static struct mt9t001_platform_data bastix_mt9p031_platform_data = {
.clk_pol = 0,
};
static struct i2c_board_info bastix_camera_i2c_devices[] = {
{
I2C_BOARD_INFO(MT9P031_NAME, MT9P031_I2C_ADDR),
.platform_data = bastix_mt9p031_platform_data,
},
};
static struct v4l2_subdev_i2c_board_info bastix_camera_mt9p031[] = {
{
.board_info = bastix_camera_i2c_devices[0],
.i2c_adapter_id = BASTIX_CAM_I2C_BUS_NUM,
},
{ NULL, 0, },
};
static struct isp_v4l2_subdevs_group bastix_camera_subdevs[] = {
{
.subdevs = bastix_camera_mt9p031,
.interface = ISP_INTERFACE_PARALLEL,
.bus = { .parallel = {
.data_lane_shift= 1,
.clk_pol= 0,
.bridge
Re: New media framework user space usage
Hello,
2010/12/7 Guennadi Liakhovetski g.liakhovet...@gmx.de:
Hi Bastian
On Tue, 7 Dec 2010, Bastian Hecht wrote:
Hello,
I succesfully got out images reliably. I just the nokia-tree and mixed
up your mt9t031 and Laurent's mt9t001 code. It's just a barebone that
gets images in default size. It's not cleaned up yet, but I post what
I have.
Thanks! Will have a look and give them a try. If you like, I can try to
help you cleaning up the patches and mainlining them - at least to
Laurent's tree;)
That would be superb, as we do not continue our mt9p031 development
because we try an Omnivion chip. On the other hand, I received so much
support here, that I want the driver code to be in open hands and not
the bin.
Sung Hee develops on the mt9p031, too. We should try to mainline the
mt9p031 code.
cheers,
Bastian
Thanks
Guennadi
Greetings,
Bastian
2010/12/6 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Thu, 4 Nov 2010, Laurent Pinchart wrote:
Hi Bastian,
Hi Bastian, all
Have you or anyone ben successful getting mt9p031 to work with the omap3
ISP driver? If so - can I have the code? Or even if it never worked -
could you post the latest version of your driver and platform bindings?
Thanks
Guennadi
On Tuesday 02 November 2010 11:31:28 Bastian Hecht wrote:
I am the first guy needing a 12 bit-bus?
Yes you are :-) You will need to implement 12 bit support in the ISP
driver, or start by hacking the sensor driver to report a 10 bit
format
(2 bits will be lost but you should still be able to capture an
image).
Isn't that an officially supported procedure to drop the least
significant bits?
You gave me the isp configuration
.bus = { .parallel = {
.data_lane_shift = 1,
...
that instructs the isp to use 10 of the 12 bits.
If you don't need the full 12 bits, sure, that should work.
Second thing is, the yavta app now gets stuck while dequeuing a
buffer.
strace ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F
/dev/video2 ...
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_STREAMON, 0xbec11154) = 0
ioctl(3, VIDIOC_DQBUF
strace gets stuck in mid of this line.
Somehow the ISP_ENABLE_IRQ register was reset at some point that is
unclear to me. When I put it on again manually yavta succeeds to read
the frames.
That's weird. Let me know if you can reproduce the problem.
Unfortunately the image consists of black pixels only. We found out
that the
2.8V voltage regulator got broken in the course of development - the
1.8V
logic still worked but the ADC did not...
But the heck - I was never that close :)
--
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
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
---
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: omap3-isp: can't register subdev for new sensor driver mt9t001
Hello Stefan,
I can send you my code tomorrow. Meanwhile a short hint, that may help
you: The mt9p031 needs a not only the i2c clock to work but also the
cam_clk signals.
Right now this is hacked into the isp-driver in my setup but I want to
do it like the nokia code (pass a clock-setup function defined in the
board-code to the sensor driver, so that the driver can setup the
clock itself before i2c-checking is done).
best greetings,
Bastian
2010/12/1 Stefan Steuerwald salsas...@googlemail.com:
Hi,
may I please have your help with the following:
I have adapted the MT9T001 driver from Laurent's tree at
http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media-mt9t001
to the current state of the media-framework in this kernel tree (devel
branch):
http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51
to run this on a gumstix overo (OMAP3) board.
(Duplicating Bastian's recent work, I know, but he's on hoilday...).
The mt9t001 driver module loads and probes ok, however, the creation
of a v4l2 subdev
for the sensor fails (i2c says -EBUSY, see below). It seems to choke
on the fact that the
sensor's I2C address of 0x5D is already in use after loading the
mt9t001 module,
which I think is fine:
r...@overo:~# modprobe iommu2
omap-iommu omap-iommu.0: isp registered
r...@overo:~# modprobe omap3-isp
Linux media interface: v0.10
Linux video capture interface: v2.00
omap3isp omap3isp: Revision 2.0 found
omap-iommu omap-iommu.0: isp: version 1.1
isp_register_subdev_group: i2c_adapter_id 3, type mt9t001, i2c_addr 93
mt9t001 3-005d: mt9t001_probe()
mt9t001 3-005d: mt9t001_video_probe()
mt9t001 3-005d: MT9T001 detected
v4l2_i2c_new_subdev_board: info-addr=0x5d, probe_addrs=(null)
i2c i2c-3: Failed to register i2c client mt9t001 at 0x5d (-16)
isp_register_subdev_group: Unable to register subdev mt9t001
This creates these subdevs:
r...@overo:~# cat /sys/class/video4linux/v4l-subdev*/name
OMAP3 ISP CCP2
OMAP3 ISP CSI2a
OMAP3 ISP CCDC
OMAP3 ISP preview
OMAP3 ISP resizer
OMAP3 ISP AEWB
OMAP3 ISP AF
OMAP3 ISP histogram
which has the sensor missing, I believe.
I am using platform_device_register() in my
arch/arm/mach-omap2/board-overo.c file
to register my iof_isp_platform_data as follows:
static struct i2c_board_info overo_i2c_boardinfo_3[] = {
{
I2C_BOARD_INFO(mt9t001, 0x5d),
},
};
static struct v4l2_subdev_i2c_board_info iof_camera_mt9t001[] = {
{
.board_info = overo_i2c_boardinfo_3[0],
.i2c_adapter_id = 3,
},
{ NULL, 0, },
};
static struct isp_v4l2_subdevs_group iof_camera_subdevs[] = {
{
.subdevs = iof_camera_mt9t001,
.interface = ISP_INTERFACE_PARALLEL,
.bus = { .parallel = {
.data_lane_shift = 0,
.clk_pol = 1,
.bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
} },
},
{ NULL, 0, },
};
static struct isp_platform_data iof_isp_platform_data = {
.subdevs = iof_camera_subdevs,
};
I have followed the recent conversation between Bastian, Laurent and
others on the
similar subject of a mt9p031 driver used with omap3-isp.
Any pointers on what to check are greatly appreciated.
Thank you,
Stefan.
--
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: OMAP3530 ISP irqs disabled
2010/11/7 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Hi all! Michael Jones wrote: Hi Bastian (Laurent, and Sakari), I want to clarify this: I try to read images with yafta. I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros. I repeat the process some times and keep checking the data. After - let's say the 6th time - the images contain exactly the data I expect. WHEN they are read they are good. I just don't want to read 20 black images before 1 image is transferred right. -Bastian I'm on to your problem, having reproduced it myself. I suspect that you're actually only getting one frame: your very first buffer. You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame. If you clear the good frame in your application once, you won't get any more non-zero frames afterwards. Or if you request more buffers, you'll have fewer non-zero frames. That's the behavior I observe. (FYI: your lines are quite long, well over 80 characters.) Have you checked the ISP writes data to the buffers? It's good to try with a known pattern that you can't get from a sensor. The CCDC is getting disabled by the VD1 interrupt: ispccdc_vd1_isr()-__ispccdc_handle_stopping()-__ispccdc_enable(ccdc, 0) To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem. In fact, I was still getting VD1 interrupts even though I had disabled them. Has anybody else observed that VD1 cannot be disabled? I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled. Yes, the CCDC VD0 and VD1 counters keep counting even if the module is disabled. That is a known problem. The VD0 interrupts are ignored as long as there are no buffers queued. How many buffers do you have btw.? Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it: --- a/drivers/media/video/isp/ispccdc.c +++ b/drivers/media/video/isp/ispccdc.c @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc) spin_lock_irqsave(ccdc-lsc.req_lock, flags); /* We are about to stop CCDC and/without LSC */ - if ((ccdc-output CCDC_OUTPUT_MEMORY) || + if ((ccdc-output CCDC_OUTPUT_MEMORY) (ccdc-state == ISP_PIPELINE_STREAM_SINGLESHOT)) ccdc-stopping = CCDC_STOP_REQUEST; Does this fix the problem? ISP_PIPELINE_STREAM_SINGLESHOT is there for memory sources and I do not think this is a correct fix. It fixes the problem for me. I read 2 frames now, the first is half full, but the second gets synchronized nicely then and I got my first picture out of it. It works reliable now. Is your VSYNC on falling or rising edge? This is defined for CCP2 and this is what the driver was originally written for. If it's different (rising??), you should apply the attached wildly opportunistic patch, which I do not expect to fix this problem, however. I got rising HSYNC and rising VSINC sampled at falling pixelclock. - Bastian But I might be just pointing you to wrong direction, better wait for Laurent's answer. :-) Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: OMAP3530 ISP irqs disabled
Hello all, I got it now!!! After adding debugfs support and observing my isp like a lynx I found out that magically the ISP_CTRL register changes from [ 316.903900] omap3isp omap3isp: ###ISP CTRL=0x0020 to 0x0020c040 after an successful image read :-) This is the shift configuration that should never be touched and the syn_detect register that changes from trigger interrupts on HS falling edge to VS rising edge. I saw that the these registers get written in the ccdc_configure - isp_configure_bridge - write_regs. Let's see if I can find out the concrete bug location. cheers, Bastian 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote: 2010/11/3 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Bastian Hecht wrote: 2010/11/3 Bastian Hecht hec...@googlemail.com: Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. It _might_ be better to have this in isp_get(). While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. That should definitely not be necessary. The interrupts are enabled in isp_get(). As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. Are you getting any other interrupts? Basically every ISP block which is on the pipe will produce interrupts. Which ISP block is writing the images to memory for you? I read out the CCDC with this pipeline: ./media-ctl -r -l 'mt9p031 2-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-005d:0[SGRBG10 2592x1944], OMAP3 ISP CCDC:1[SGRBG10 2592x1944]' ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 I get these interrupts while reading 4 frames: [ 3962.689483] s_stream is it! enable: 1 [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user wants to disable module. [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ [ 3967.242614] s_stream is it! enable: 0 Maybe a stupid question, but have you set exposure and gain to a reasonable value? :-) First reaction was - that must be it! But hmmm... the flanks on the data lines of the camera are mostly high. When I press my finger on the sensor they are mostly low. The other values seem to be good too: xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within the limits of the datasheets - camera and omap isp). cam_vs raises for about 1 sec goes shortly down and comes up again. cam_hs seems to fit too. Every 20th try I get data from an image sample the other times only zeros. The CCDC is configured with a DC subtract value of 64 by default, so it subtract 64 from every pixel. If your pixel values are lower than or equal to 64 you will get a black image
Re: OMAP3530 ISP irqs disabled
2010/11/5 Bastian Hecht hec...@googlemail.com: Hello all, I got it now!!! After adding debugfs support and observing my isp like a lynx I found out that magically the ISP_CTRL register changes from [ 316.903900] omap3isp omap3isp: ###ISP CTRL=0x0020 to 0x0020c040 after an successful image read :-) Sorry false alarm... the bridge gets configured correctly for my 12- to 10-bit shift and the isp listens for VS for frame starts. It just was 0x0020 after reset and had to be set correctly. This is the shift configuration that should never be touched and the syn_detect register that changes from trigger interrupts on HS falling edge to VS rising edge. I saw that the these registers get written in the ccdc_configure - isp_configure_bridge - write_regs. Let's see if I can find out the concrete bug location. cheers, Bastian 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote: 2010/11/3 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Bastian Hecht wrote: 2010/11/3 Bastian Hecht hec...@googlemail.com: Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. It _might_ be better to have this in isp_get(). While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. That should definitely not be necessary. The interrupts are enabled in isp_get(). As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. Are you getting any other interrupts? Basically every ISP block which is on the pipe will produce interrupts. Which ISP block is writing the images to memory for you? I read out the CCDC with this pipeline: ./media-ctl -r -l 'mt9p031 2-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-005d:0[SGRBG10 2592x1944], OMAP3 ISP CCDC:1[SGRBG10 2592x1944]' ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 I get these interrupts while reading 4 frames: [ 3962.689483] s_stream is it! enable: 1 [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user wants to disable module. [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ [ 3967.242614] s_stream is it! enable: 0 Maybe a stupid question, but have you set exposure and gain to a reasonable value? :-) First reaction was - that must be it! But hmmm... the flanks on the data lines of the camera are mostly high. When I press my finger on the sensor they are mostly low. The other values seem to be good too: xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within the limits of the datasheets - camera and omap isp). cam_vs raises for about 1 sec goes shortly down and comes up again. cam_hs seems to fit too. Every 20th
Re: OMAP3530 ISP irqs disabled
2010/11/5 Michael Jones michael.jo...@matrix-vision.de: Hi Bastian (Laurent, and Sakari), I want to clarify this: I try to read images with yafta. I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros. I repeat the process some times and keep checking the data. After - let's say the 6th time - the images contain exactly the data I expect. WHEN they are read they are good. I just don't want to read 20 black images before 1 image is transferred right. -Bastian I'm on to your problem, having reproduced it myself. I suspect that you're actually only getting one frame: your very first buffer. You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame. If you clear the good frame in your application once, you won't get any more non-zero frames afterwards. Or if you request more buffers, you'll have fewer non-zero frames. That's the behavior I observe. I can confirm the very first buffer theorem. I indeed get 1 valid frame after each reboot. First I didn'notice it because I used Laurent's yafta --skip 3 ... command line. I read 4 frames and only saved the last. Btw, heaven sent you... I keep working on this problem 1 week now and am pretty desperate. I started reading about the linux memory management system to understand all the buffer dma streaming. (well that is probably not the worst thing to sacrifice time...) Tell me if I can do something for you to help. cheers, Bastian The CCDC is getting disabled by the VD1 interrupt: ispccdc_vd1_isr()-__ispccdc_handle_stopping()-__ispccdc_enable(ccdc, 0) To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem. In fact, I was still getting VD1 interrupts even though I had disabled them. Has anybody else observed that VD1 cannot be disabled? I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled. Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it: --- a/drivers/media/video/isp/ispccdc.c +++ b/drivers/media/video/isp/ispccdc.c @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc) spin_lock_irqsave(ccdc-lsc.req_lock, flags); /* We are about to stop CCDC and/without LSC */ - if ((ccdc-output CCDC_OUTPUT_MEMORY) || + if ((ccdc-output CCDC_OUTPUT_MEMORY) (ccdc-state == ISP_PIPELINE_STREAM_SINGLESHOT)) ccdc-stopping = CCDC_STOP_REQUEST; -- Michael Jones MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: OMAP3530 ISP irqs disabled
2010/11/4 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote: 2010/11/3 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Bastian Hecht wrote: 2010/11/3 Bastian Hecht hec...@googlemail.com: Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. It _might_ be better to have this in isp_get(). While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. That should definitely not be necessary. The interrupts are enabled in isp_get(). As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. Are you getting any other interrupts? Basically every ISP block which is on the pipe will produce interrupts. Which ISP block is writing the images to memory for you? I read out the CCDC with this pipeline: ./media-ctl -r -l 'mt9p031 2-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-005d:0[SGRBG10 2592x1944], OMAP3 ISP CCDC:1[SGRBG10 2592x1944]' ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 I get these interrupts while reading 4 frames: [ 3962.689483] s_stream is it! enable: 1 [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user wants to disable module. [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ [ 3967.242614] s_stream is it! enable: 0 Maybe a stupid question, but have you set exposure and gain to a reasonable value? :-) First reaction was - that must be it! But hmmm... the flanks on the data lines of the camera are mostly high. When I press my finger on the sensor they are mostly low. The other values seem to be good too: xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within the limits of the datasheets - camera and omap isp). cam_vs raises for about 1 sec goes shortly down and comes up again. cam_hs seems to fit too. Every 20th try I get data from an image sample the other times only zeros. The CCDC is configured with a DC subtract value of 64 by default, so it subtract 64 from every pixel. If your pixel values are lower than or equal to 64 you will get a black image. As a quick hack you can replace ccdc-clamp.dcsubval = 64; with ccdc-clamp.dcsubval = 0; in isp_ccdc_init(). The correct solution is to use the VIDIOC_PRIVATE_ISP_CCDC_CFG ioctl to configure the DC subtraction value to 0. This is not the problem. The 64 reduction is a nice hint as I was wondering why I get 0x3BF when the sensor is full in light and I was lucky and a frame was read. I wondered why it is not 0x3FF - all 10 bits high. When I slightly press my finger on it I get about 0x045-0x1bf. So the sensor values seem to be ok. The values fill the whole 10MB image. Can you give me an other media-ctl setup, so that I can read jpegs from the preview unit, please? I want to follow 3 leads now
OMAP3530 ISP irqs disabled
Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. However... please help me get rid of these zeros! I keep reading through the ISP and the mt9p031 docs to find some settings that could have influence on the data sampling. The sensor is working fine now, so the solution should be somewhere within the isp. Thank you all, Bastian -- 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: OMAP3530 ISP irqs disabled
2010/11/3 Bastian Hecht hec...@googlemail.com: Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. However... please help me get rid of these zeros! I keep reading through the ISP and the mt9p031 docs to find some settings that could have influence on the data sampling. The sensor is working fine now, so the solution should be somewhere within the isp. Thank you all, Bastian -- 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: OMAP3530 ISP irqs disabled
2010/11/3 Michael Jones michael.jo...@matrix-vision.de: Bastian Hecht wrote: I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. HS_VS_IRQ is _either_ VS _or_ HS interrupts, but not both. The SYNC_DETECT bits in ISP_CTRL determines which. For writing into memory, the ISP only needs to react per frame, not per line, so it is set up to trigger on VS. OK, I see, thank you. Is there a point in the ccdc code where I can directly look up what is read from the camera pins cam_d*? All the signals seem to be fine from the camera, I want to check if this is true and the problem is in the dma part. - Bastian -- Michael Jones MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: OMAP3530 ISP irqs disabled
2010/11/3 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Hi Bastian, Bastian Hecht wrote: 2010/11/3 Bastian Hecht hec...@googlemail.com: Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. It _might_ be better to have this in isp_get(). While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. That should definitely not be necessary. The interrupts are enabled in isp_get(). As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. Are you getting any other interrupts? Basically every ISP block which is on the pipe will produce interrupts. Which ISP block is writing the images to memory for you? I read out the CCDC with this pipeline: ./media-ctl -r -l 'mt9p031 2-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-005d:0[SGRBG10 2592x1944], OMAP3 ISP CCDC:1[SGRBG10 2592x1944]' ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 I get these interrupts while reading 4 frames: [ 3962.689483] s_stream is it! enable: 1 [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user wants to disable module. [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ [ 3967.242614] s_stream is it! enable: 0 Maybe a stupid question, but have you set exposure and gain to a reasonable value? :-) First reaction was - that must be it! But hmmm... the flanks on the data lines of the camera are mostly high. When I press my finger on the sensor they are mostly low. The other values seem to be good too: xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within the limits of the datasheets - camera and omap isp). cam_vs raises for about 1 sec goes shortly down and comes up again. cam_hs seems to fit too. Every 20th try I get data from an image sample the other times only zeros. - Bastian Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: New media framework user space usage
Hello Laurent,
I am the first guy needing a 12 bit-bus?
Yes you are :-) You will need to implement 12 bit support in the ISP driver,
or start by hacking the sensor driver to report a 10 bit format (2 bits will
be lost but you should still be able to capture an image).
Isn't that an officially supported procedure to drop the least
significant bits?
You gave me the isp configuration
.bus = { .parallel = {
.data_lane_shift= 1,
...
that instructs the isp to use 10 of the 12 bits.
Second thing is, the yavta app now gets stuck while dequeuing a buffer.
strace ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F
/dev/video2 ...
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0
ioctl(3, VIDIOC_STREAMON, 0xbec11154) = 0
ioctl(3, VIDIOC_DQBUF
strace gets stuck in mid of this line.
Somehow the ISP_ENABLE_IRQ register was reset at some point that is
unclear to me. When I put it on again manually yavta succeeds to read
the frames. Unfortunately the image consists of black pixels only. We
found out that the 2.8V voltage regulator got broken in the course of
development - the 1.8V logic still worked but the ADC did not...
But the heck - I was never that close :)
bye,
Bastian
--
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 media framework user space usage
To clarify this: The number of pixels in an image sensor is typically simply the number of independent photosites - so the 5-MP MT9P031 sensor will give you a raw image with 5 million 12-bit values in it. (not 5x3 million, or 5x4 million, just 5 million) Each photosite is covered by a single color filter, so each 12-bit raw value represents a single color channel, and it is the only color channel measured at that pixel. Which color channel is recorded for each pixel depends on the arrangement of the color filters. The most common arrangement is the Bayer pattern, which you wrote: 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 So the top-left pixel in the sensor is covered by a green filter, the one to the right of it is covered by a red filter, the one below it is a blue filter. The pattern tiles across the whole sensor in this fashion. (Note that which color is the top-leftmost does vary between sensors, but the basic repeating tile is the same - two greens for each red and blue, diagonally arranged) To convert this 5-million-pixel raw image into a 5-million-pixel RGB image, you have to demosaic the image - come up with the missing two color values for each pixel. It suffices to say that there are lots of ways to do this, of varying levels of complexity and quality. The OMAP3 ISP preview pipe runs such a method in hardware, to give you a 3-channel YUV 4:2:2 output from a raw sensor image, with 5 million Y values, 2.5 million U, and 2.5 million V values. There is a 3x3 color conversion matrix inside the preview pipeline that converts from the sensor's RGB space to a standard RGB space (at least if you set up the matrix right), and then a second matrix to go from that RGB space to YUV. The number of bits per channel also gets reduced from 10 to 8 using a gamma lookup table. So if you ask the ISP for raw data, you get 5 million 16-bit values (of which only the lower 10 or 12 bits are valid) total. If you ask it for YUV data, you'll get 10 million 8-bit values. Hope that clarifies, and doesn't further confuse things. OK, sure! Somehow I got stuck with the idea that you can get 1 pixel only from each quadruple, but as you said you can check the neighbourhood from each raw pixel with a kernel-matrix. Another step to a clearer understanding of the materia, thank you. So, I followed the stuck ioctl in the code until I saw that the ISP simply waits for an image to complete. As the signals seem to come out right of the chip, I will double check my mux settings and investigate the ISP_IRQ0STATUS register to see if interrupts are generated at all. The reference manual states on page 1503 that this register is located at 0x480B C010 in physical memory. Instead of polluting the kernel code I tried to use inw() to read the register from userspace: unsigned int a; a = inw(0xC010480B); // and I tried a = inw(0x480BC010); Both tries gave me segfaults. Any idea why that does not work? Well now I put the debug message in the kernel code. bye, Bastian Eino-Ville Talvala Stanford University -- 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 media framework user space usage
Hello Eino-Ville,
Most of the ISP can't handle more than 10-bit input - unless you're
streaming raw sensor data straight to memory, you'll have to use the bridge
lane shifter to decimate the input.
In the new framework, I don't know how that's done, unfortunately.
Thank you for pointing me to it. Now I read about it in the technical
reference manual too
(http://focus.ti.com/lit/ug/spruf98k/spruf98k.pdf).
At page 1392 it mentions the possibility to reduce the precision from
12- to 10-bit. It turns out Laurent already sent me the right
configuration in a side note of a former post of me. On page 1574 I
found another related register: CCDC_FMTCFG. Here you can select which
10 of the 12 bits you want to keep.
I looked up the code-flow for the isp-framework and post it here for reference:
static struct isp_v4l2_subdevs_group bastix_camera_subdevs[] = {
{
.subdevs = bastix_camera_mt9p031,
.interface = ISP_INTERFACE_PARALLEL,
.bus = { .parallel = {
.data_lane_shift= 1,
.clk_pol= 1,
.bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
} },
},
{ NULL, 0, },
};
static struct isp_platform_data bastix_isp_platform_data = {
.subdevs = bastix_camera_subdevs,
};
...
omap3isp_device.dev.platform_data = bastix_isp_platform_data;
---
The config is handled in isp.c here:
void isp_configure_bridge(struct isp_device *isp, enum ccdc_input_entity input,
const struct isp_parallel_platform_data *pdata)
{
...
switch (input) {
case CCDC_INPUT_PARALLEL:
ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
ispctrl_val |= pdata-data_lane_shift
ISPCTRL_SHIFT_SHIFT;
ispctrl_val |= pdata-clk_pol ISPCTRL_PAR_CLK_POL_SHIFT;
ispctrl_val |= pdata-bridge ISPCTRL_PAR_BRIDGE_SHIFT;
break;
...
}
Also, technically, the mt9p031 output colorspace is not sRGB, although I'm
not sure how close it is. It's its own sensor-specific space, determined by
the color filters on it, and you'll want to calibrate for it at some point.
The output format of the sensor is
R Gr
Gb B
The same colorspace is given as example in spruf98k on page 1409.
There I am still confused about the sematic of 1 pixel. Is it the
quadruple of the bayer values or each component? Or does it depend on
the context? Does the the sensor send 5MP data to the isp or 5MPx4
bayer values? Does the 12-bit width belong to each bayer value? In the
sensor you read from right to left, I don't know if the ISP doc means
reading left to right. And so on and so on...
Good luck,
As you can see I need and appreciate it :)
About the freezing ioctl. I discovered that I have a clocking issue. I
will solve it monday and see if it works better and had an impact on
the isp-driver.
Eino-Ville Talvala
Stanford University
cheers,
Bastian
--
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 media framework user space usage
Hello Laurant, With the media-ctl and yavta test applications, just run ./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP CCDC:1[SGRBG10 1024x768]' ./yavta -f SGRBG10 -s 1024x768 -n 4 --capture=4 --skip 3 -F $(./media-ctl -e OMAP3 ISP CCDC output) Replace all occurences of 1024x768 by your sensor native resolution, and mt9t001 3-005d by the sensur subdev name. I did as you said and everything works fine until I use yavta: Video format set: width: 2952 height: 1944 buffer size: 11508480 Video format: BA10 (30314142) 2952x1944 4 buffers requested. length: 11508480 offset: 0 Buffer 0 mapped at address 0x4016d000. length: 11508480 offset: 11509760 Buffer 1 mapped at address 0x40c67000. length: 11508480 offset: 23019520 Buffer 2 mapped at address 0x41761000. length: 11508480 offset: 34529280 Buffer 3 mapped at address 0x4225b000. Unable to start streaming: 22 This is in ret = ioctl(dev-fd, enable ? VIDIOC_STREAMON : VIDIOC_STREAMOFF, type); errno 22 is: Invalid argument Any ideas where to look next? Thanks, Bastian -- 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: New media framework user space usage
Hi, I did as you said and everything works fine until I use yavta: Video format set: width: 2952 height: 1944 buffer size: 11508480 Video format: BA10 (30314142) 2952x1944 ooops, I had a typo... 2952 becomes 2592 4 buffers requested. length: 11508480 offset: 0 Buffer 0 mapped at address 0x4016d000. length: 11508480 offset: 11509760 Buffer 1 mapped at address 0x40c67000. length: 11508480 offset: 23019520 Buffer 2 mapped at address 0x41761000. length: 11508480 offset: 34529280 Buffer 3 mapped at address 0x4225b000. Unable to start streaming: 22 This is in ret = ioctl(dev-fd, enable ? VIDIOC_STREAMON : VIDIOC_STREAMOFF, type); errno 22 is: Invalid argument Now it becomes Unable to start streaming: 32 : Broken pipe I will check if the video format of the sensor chip is SGRBG10 in default. cheers, Bastian Any ideas where to look next? Thanks, Bastian -- 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: New media framework user space usage
Hello, Now it becomes Unable to start streaming: 32 : Broken pipe I saw that my stub mt9p031_get_format gets called. Thanks a lot. So I reached the point where I can fill my driver with life. I will check if the video format of the sensor chip is SGRBG10 in default. I guess this is GRBG. What does the S stand for? Datasheet says: Pixels are output in a Bayer pattern format consisting of four “colors”—GreenR, GreenB, Red, and Blue (Gr, Gb, R, B)—representing three filter colors. When no mirror modes are enabled, the first row output alternates between Gr and R pixels, and the second row output alternates between B and Gb pixels. The Gr and Gb pixels have the same color filter, but they are treated as separate colors by the data path and analog signal chain. ciao, Bastian cheers, Bastian Any ideas where to look next? Thanks, Bastian -- 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: New media framework user space usage
Hello Laurant, sorry I am flooding a bit here, but now I reached a point where I am really stuck. In the get_fmt_pad I set the following format *format = mt9p031-format; that is defined as mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10; mt9p031-format.width = MT9P031_MAX_WIDTH; mt9p031-format.height = MT9P031_MAX_HEIGHT; mt9p031-format.field = V4L2_FIELD_NONE; mt9p031-format.colorspace = V4L2_COLORSPACE_SRGB; I found the different formats in /include/linux/v4l2-mediabus.h. I have 12 data bit channels, but there is no enum for that (like V4L2_MBUS_FMT_SGRBG10_1X12). I am the first guy needing a 12 bit-bus? Second thing is, the yavta app now gets stuck while dequeuing a buffer. strace ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 ... ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_QBUF, 0xbec111cc) = 0 ioctl(3, VIDIOC_STREAMON, 0xbec11154) = 0 ioctl(3, VIDIOC_DQBUF strace gets stuck in mid of this line. cheers, Bastian -- 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
New media framework user space usage
Hello Laurent,
my mt9p031 camera project for the omap3530 isp has come to the point
where the ISP registered video[0-6], media0 and v4l-subdev[0-7].
As far as I can see from the names...
cat /sys/class/video4linux/video*/names
OMAP3 ISP CCP2 input
OMAP3 ISP CSI2a output
OMAP3 ISP CCDC output
OMAP3 ISP preview input
OMAP3 ISP preview output
OMAP3 ISP resizer input
OMAP3 ISP resizer output
cat /sys/class/video4linux/v4l-subdev*/names
OMAP3 ISP CCP2
OMAP3 ISP CSI2a
OMAP3 ISP CCDC
OMAP3 ISP preview
OMAP3 ISP resizer
OMAP3 ISP AEWB
OMAP3 ISP AF
OMAP3 ISP histogram
... I want to read /dev/video2 (CCDC).
When I try out a little test program from the V4L2 doc, this line fails:
ioctl (fd, VIDIOC_G_STD, std_id)
So far I adopted your mt9t001 driver, merged it with Guennadis
mt9p031. It contains lot of stubs that I want to fill out when I
succeed to make them called inside the kernel.
I looked at your presentation for the media controller and wonder if I
have to set up a pipeline by myself before I can read /dev/video2
(http://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-v4l2_summit-media.pdf).
I failed at the point where I wanted to try out the little snippet on
page 17 as I don't have definitions of the MEDIA_IOC_ENUM_ENTITIES.
Are there somewhere userspace headers available?
int fd;
fd = open(“/dev/media0”, O_RDWR);
while (1) {
struct media_user_entity entity;
struct media_user_links links;
ret = ioctl(fd, MEDIA_IOC_ENUM_ENTITIES, entity);
if (ret 0)
break;
while (1) {
ret = ioctl(fd, MEDIA_IOC_ENUM_LINKS, links);
if (ret 0)
break;
}
Thanks for help,
Bastian
APPENDIX A: dmesg
[ 103.356018] Linux media interface: v0.10
[ 103.356048] device class 'media': registering
[ 103.442230] Linux video capture interface: v2.00
[ 103.442260] device class 'video4linux': registering
[ 103.814239] bus: 'i2c': add driver mt9p031
[ 103.894622] bus: 'platform': add driver omap3isp
[ 103.933959] address of isp_platform_data in boardconfig: bf065074
[ 103.940155] Registering platform device 'omap3isp'. Parent at platform
[ 103.940185] device: 'omap3isp': device_add
[ 103.940246] bus: 'platform': add device omap3isp
[ 103.940490] bus: 'platform': driver_probe_device: matched device
omap3isp with driver omap3isp
[ 103.940490] bus: 'platform': really_probe: probing driver omap3isp
with device omap3isp
[ 103.940551] address of isp_platform_data bf065074
[ 103.954467] omap3isp omap3isp: Revision 2.0 found
[ 103.962738] omap-iommu omap-iommu.0: isp: version 1.1
[ 103.969879] omap3isp omap3isp: hist: DMA channel = 0
[ 103.970001] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 576 Hz
[ 103.972229] omap3isp omap3isp: -ISP Register dump--
[ 103.972259] omap3isp omap3isp: ###ISP SYSCONFIG=0x0001
[ 103.972259] omap3isp omap3isp: ###ISP SYSSTATUS=0x0001
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0ENABLE=0x
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0STATUS=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_GRESET_LENGTH=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_PSTRB_REPLAY=0x
[ 103.972351] omap3isp omap3isp: ###ISP CTRL=0x00200200
[ 103.972351] omap3isp omap3isp: ###ISP TCTRL_CTRL=0x001e
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_FRAME=0x
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_PSTRB_DELAY=0x
[ 103.972412] omap3isp omap3isp: ###ISP TCTRL_STRB_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_SHUT_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_PSTRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_STRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_SHUT_LENGTH=0x
[ 103.972503] omap3isp omap3isp: ###SBL PCR=0x
[ 103.972503] omap3isp omap3isp: ###SBL SDR_REQ_EXP=0x
[ 103.972534] omap3isp omap3isp:
[ 103.974700] device: 'media0': device_add
[ 103.975128] device: 'v4l-subdev0': device_add
[ 103.975524] device: 'video0': device_add
[ 103.975799] device: 'v4l-subdev1': device_add
[ 103.976104] device: 'video1': device_add
[ 103.976409] device: 'v4l-subdev2': device_add
[ 103.976684] device: 'video2': device_add
[ 103.976959] device: 'v4l-subdev3': device_add
[ 103.977294] device: 'video3': device_add
[ 103.977600] device: 'video4': device_add
[ 103.977905] device: 'v4l-subdev4': device_add
[ 103.978210] device: 'video5': device_add
[ 103.978485] device: 'video6': device_add
[ 103.978759] device: 'v4l-subdev5': device_add
[ 103.979156] device: 'v4l-subdev6': device_add
[ 103.979461] device: 'v4l-subdev7': device_add
[ 104.752685] device: '2-005d': device_add
[ 104.752777] bus: 'i2c': add device 2-005d
[ 104.753051] bus: 'i2c': driver_probe_device: matched device 2-005d
with driver mt9p031
[ 104.753082] bus: 'i2c': really_probe: probing driver mt9p031 with
device 2-005d
[ 104.769897] mt9p031 2-005d: Detected a MT9P031
Re: New media framework user space usage
Hi,
after reading the topic controls, subdevs, and media framework
(http://www.spinics.net/lists/linux-media/msg24474.html) I guess I
double-posted something here :S
But what I still don't understand is, how configuring the camera
works. You say that the subdevs (my camera sensor) are configured
directly. 2 things make me wonder. How gets the ISP informed about the
change and why don't I see my camera in the subdevs name list I
posted. All subdevs are from the ISP.
My camera already receives a clock, the i2c connection works and my
oscilloscope shows that the sensor is throwing out data on the
parallel bus pins. But unfortunately I am a completely v4l2 newbie. I
read through the v4l2-docs now but the first example already didn't
work because of the new framework. Can you point me to a way to read
/dev/video2?
Thank you very much,
Bastian
2010/10/28 Bastian Hecht hec...@googlemail.com:
Hello Laurent,
my mt9p031 camera project for the omap3530 isp has come to the point
where the ISP registered video[0-6], media0 and v4l-subdev[0-7].
As far as I can see from the names...
cat /sys/class/video4linux/video*/names
OMAP3 ISP CCP2 input
OMAP3 ISP CSI2a output
OMAP3 ISP CCDC output
OMAP3 ISP preview input
OMAP3 ISP preview output
OMAP3 ISP resizer input
OMAP3 ISP resizer output
cat /sys/class/video4linux/v4l-subdev*/names
OMAP3 ISP CCP2
OMAP3 ISP CSI2a
OMAP3 ISP CCDC
OMAP3 ISP preview
OMAP3 ISP resizer
OMAP3 ISP AEWB
OMAP3 ISP AF
OMAP3 ISP histogram
... I want to read /dev/video2 (CCDC).
When I try out a little test program from the V4L2 doc, this line fails:
ioctl (fd, VIDIOC_G_STD, std_id)
So far I adopted your mt9t001 driver, merged it with Guennadis
mt9p031. It contains lot of stubs that I want to fill out when I
succeed to make them called inside the kernel.
I looked at your presentation for the media controller and wonder if I
have to set up a pipeline by myself before I can read /dev/video2
(http://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-v4l2_summit-media.pdf).
I failed at the point where I wanted to try out the little snippet on
page 17 as I don't have definitions of the MEDIA_IOC_ENUM_ENTITIES.
Are there somewhere userspace headers available?
int fd;
fd = open(“/dev/media0”, O_RDWR);
while (1) {
struct media_user_entity entity;
struct media_user_links links;
ret = ioctl(fd, MEDIA_IOC_ENUM_ENTITIES, entity);
if (ret 0)
break;
while (1) {
ret = ioctl(fd, MEDIA_IOC_ENUM_LINKS, links);
if (ret 0)
break;
}
Thanks for help,
Bastian
APPENDIX A: dmesg
[ 103.356018] Linux media interface: v0.10
[ 103.356048] device class 'media': registering
[ 103.442230] Linux video capture interface: v2.00
[ 103.442260] device class 'video4linux': registering
[ 103.814239] bus: 'i2c': add driver mt9p031
[ 103.894622] bus: 'platform': add driver omap3isp
[ 103.933959] address of isp_platform_data in boardconfig: bf065074
[ 103.940155] Registering platform device 'omap3isp'. Parent at platform
[ 103.940185] device: 'omap3isp': device_add
[ 103.940246] bus: 'platform': add device omap3isp
[ 103.940490] bus: 'platform': driver_probe_device: matched device
omap3isp with driver omap3isp
[ 103.940490] bus: 'platform': really_probe: probing driver omap3isp
with device omap3isp
[ 103.940551] address of isp_platform_data bf065074
[ 103.954467] omap3isp omap3isp: Revision 2.0 found
[ 103.962738] omap-iommu omap-iommu.0: isp: version 1.1
[ 103.969879] omap3isp omap3isp: hist: DMA channel = 0
[ 103.970001] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 576 Hz
[ 103.972229] omap3isp omap3isp: -ISP Register dump--
[ 103.972259] omap3isp omap3isp: ###ISP SYSCONFIG=0x0001
[ 103.972259] omap3isp omap3isp: ###ISP SYSSTATUS=0x0001
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0ENABLE=0x
[ 103.972290] omap3isp omap3isp: ###ISP IRQ0STATUS=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_GRESET_LENGTH=0x
[ 103.972320] omap3isp omap3isp: ###ISP TCTRL_PSTRB_REPLAY=0x
[ 103.972351] omap3isp omap3isp: ###ISP CTRL=0x00200200
[ 103.972351] omap3isp omap3isp: ###ISP TCTRL_CTRL=0x001e
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_FRAME=0x
[ 103.972381] omap3isp omap3isp: ###ISP TCTRL_PSTRB_DELAY=0x
[ 103.972412] omap3isp omap3isp: ###ISP TCTRL_STRB_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_SHUT_DELAY=0x
[ 103.972442] omap3isp omap3isp: ###ISP TCTRL_PSTRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_STRB_LENGTH=0x
[ 103.972473] omap3isp omap3isp: ###ISP TCTRL_SHUT_LENGTH=0x
[ 103.972503] omap3isp omap3isp: ###SBL PCR=0x
[ 103.972503] omap3isp omap3isp: ###SBL SDR_REQ_EXP=0x
[ 103.972534] omap3isp omap3isp:
[ 103.974700] device: 'media0': device_add
[ 103.975128] device
Re: soc_camera device
Hello Hal, I am working on the same problem and thanks to Laurent and others I made lots of progress here. I want to point you to http://www.mail-archive.com/linux-media@vger.kernel.org/msg23076.html and http://www.mail-archive.com/linux-media@vger.kernel.org/msg23315.html Have fun, Bastian 2010/10/20 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Hal, On Tuesday 19 October 2010 23:58:48 Hal Moroff wrote: I'm pretty new to Linux video drivers (I do have experience with drivers in general) and am trying to get my head around the driver models. Sorry if this is too basic a question for this forum. I have an OMAP 3530 running Arago Linux (2.6.32 at the moment), You should really upgrade to a more recent OMAP3 ISP driver. The driver has been (nearly) completely rewritten and has a new userspace API (still V4L2 compatible of course). If you build your userspace applications for the OMAP3 ISP driver shipped with the 2.6.32 kernel you will be stuck with the old buggy driver. You can find the latest driver in http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media-0004- omap3isp and I'm trying to capture images from an Aptina sensor for which there does not seem to be a driver. There seem to be soc_camera, soc_camera-int, v4l2, omap34xxcam drivers at the very least. I'm pretty confused over these and how they do or don't work with V4L2 and/or each other. And you're missing isp-mod.ko :-) It seems that some of the driver models are deprecated (but still in use), and that soc_camera is current. Or is it? In recent driver versions isp-mod.ko and omap34xxcam.ko have been merged into omap3-isp.ko. The driver doesn't use the SoC camera framework, so you can forget about soc_camera for now. 2 things in particular at the moment are giving me a hard time: 1. I can't seem to load soc_camera.ko ... I keep getting the error: soc_camera: exports duplicate symbol soc_camera_host_unregister (owned by kernel) I can't seem to resolve this, nor can I find the issue described in any online forum (and so I suspect it's my problem). That's probably caused by soc_camera being built in your kernel image, and then built again as a module. That shouldn't matter as you don't need soc_camera anyway. 2. There are drivers for the Aptina MT9V022 and the MT9M001 (among others). Both of these are sensors, and not SOC, and yet both of these rely on the soc_camera module. I'm willing to create the driver for my Aptina sensor, and the easiest way is generally to look at a known driver as a template, however I can't figure out which to look at. To be compatible with the OMAP3 ISP driver, sensor drivers need to implement the V4L2 subdev pad-level API. Look at the MT9T001 driver in http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media- mt9t001 for sample code. Please read the http://www.spinics.net/lists/linux-media/msg23744.html mail thread for more information. -- 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: OMAP 3530 ISP driver segfaults
2010/10/15 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Friday 15 October 2010 13:59:24 Bastian Hecht wrote: Hello ISP driver developers, after the lastest pull of branch 'devel' of git://gitorious.org/maemo-multimedia/omap3isp-rx51 I get a segfault when I register my ISP_device. The segfault happens in isp.c in line isp-iommu = iommu_get(isp); I noticed that with the new kernel the module iommu is loaded automatically after booting while it wasn't in before my pull (my old pull is about 3 days old). Tell me what kind of further info you need. Btw, I run an Igepv2. Can you make sure that both the omap-iommu and iommu2 modules are loaded before omap3-isp.ko ? Hello Laurent, that did the trick! Don't get dependencies checked at load time? I mean undefined functions lead to load errors. I just want to learn to be prepared next time. So was it some data structure that gets properly initilized by iommu2 so that insmod cannot see the error? Thanks for enlightenment, Bastian -- 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
OMAP 3530 ISP driver segfaults
Hello ISP driver developers,
after the lastest pull of branch 'devel' of
git://gitorious.org/maemo-multimedia/omap3isp-rx51 I get a segfault
when I register my ISP_device.
The segfault happens in isp.c in line
isp-iommu = iommu_get(isp);
I noticed that with the new kernel the module iommu is loaded
automatically after booting while it wasn't in before my pull (my old
pull is about 3 days old).
Tell me what kind of further info you need. Btw, I run an Igepv2.
Thank you,
Bastian
Here is the dmesg output since init:
[ 62.589965] Freeing init memory: 128K
[ 71.526092] omap-iommu omap-iommu.0: isp registered
[ 106.695953] net eth0: SMSC911x/921x identified at 0xe0808000, IRQ: 336
[ 148.803588] Linux media interface: v0.10
[ 149.751892] Linux video capture interface: v2.00
[ 155.912719] address of isp_platform_data in boardconfig: bf058074
[ 155.919219] address of isp_platform_data bf058074
[ 155.932434] omap3isp omap3isp: Revision 2.0 found
[ 155.940673] Unable to handle kernel NULL pointer dereference at
virtual address 0004
[ 155.948852] pgd = dedb8000
[ 155.951599] [0004] *pgd=9fffa031, *pte=, *ppte=
[ 155.957977] Internal error: Oops: 17 [#1]
[ 155.962036] last sysfs file: /sys/module/iommu/initstate
[ 155.967407] Modules linked in: board_bastix(+) omap3_isp
v4l2_common videodev media iovmm iommu
[ 155.976257] CPU: 0Not tainted (2.6.35+ #4)
[ 155.980834] PC is at iommu_get+0x70/0x108 [iommu]
[ 155.985595] LR is at clk_enable+0x38/0x4c
[ 155.989654] pc : [bf000bf8]lr : [c0037920]psr: 2013
[ 155.989654] sp : deeefe68 ip : fp :
[ 156.001220] r10: decf8014 r9 : c03d3760 r8 :
[ 156.006500] r7 : 07ff r6 : dfe6be18 r5 : c03d3758 r4 : dfe6be00
[ 156.013092] r3 : r2 : r1 : c03d8b64 r0 : dfe6be00
[ 156.019683] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 156.026855] Control: 10c5387d Table: 9edb8019 DAC: 0015
[ 156.032653] Process insmod (pid: 1877, stack limit = 0xd2f0)
[ 156.038726] Stack: (0xdeeefe68 to 0xdeef)
[ 156.043121] fe60: decf8000 c03d3758 000f
bf0333dc 0001
[ 156.051391] fe80: dee13ba8 c03d3768
c03d3760 c03d3760
[ 156.059631] fea0: bf045314 c0028fc4
c019bd50 c019bd3c c019af30
[ 156.067901] fec0: c019bdec c03d3760 c019b064
c019a548 dfc04b08 dfcf2774
[ 156.076141] fee0: c03d3794 c03d3760 c03f7770 c019b118 0001
c03d3760 c03d3768 c019a3b8
[ 156.084411] ff00: c03d3760 c0198ff0 deeeff40 c03d3768 c03d3768
c015e050
[ 156.092651] ff20: c03d3758 c03d3758 0010 01c0 00014154
c0028fc4 d000 00013008
[ 156.100921] ff40: c019c15c bf05b000
00014154 c0028330
[ 156.109161] ff60: bf0580c4 00013008 00014154 c0028fc4
bf0580c4 00013008
[ 156.117431] ff80: 00014154 c006c948 00013018 00014154 00013008
4000e93c 0002 0003
[ 156.125701] ffa0: 0080 c0028e40 4000e93c 0002 00013018
00014154 00013008 0001
[ 156.133941] ffc0: 4000e93c 0002 0003 0080 be989a2b
00013008
[ 156.142211] ffe0: 00013018 be9897ac 90d8 400fa194 2010
00013018 c00c 330c
[ 156.150543] [bf000bf8] (iommu_get+0x70/0x108 [iommu]) from
[bf0333dc] (isp_probe+0x2e8/0xbe4 [omap3_isp])
[ 156.160583] [bf0333dc] (isp_probe+0x2e8/0xbe4 [omap3_isp]) from
[c019bd50] (platform_drv_probe+0x14/0x18)
[ 156.170623] [c019bd50] (platform_drv_probe+0x14/0x18) from
[c019af30] (driver_probe_device+0xa8/0x158)
[ 156.180358] [c019af30] (driver_probe_device+0xa8/0x158) from
[c019a548] (bus_for_each_drv+0x48/0x80)
[ 156.189941] [c019a548] (bus_for_each_drv+0x48/0x80) from
[c019b118] (device_attach+0x50/0x68)
[ 156.198913] [c019b118] (device_attach+0x50/0x68) from
[c019a3b8] (bus_probe_device+0x24/0x40)
[ 156.207855] [c019a3b8] (bus_probe_device+0x24/0x40) from
[c0198ff0] (device_add+0x308/0x46c)
[ 156.216735] [c0198ff0] (device_add+0x308/0x46c) from [c019c15c]
(platform_device_add+0x104/0x160)
[ 156.226043] [c019c15c] (platform_device_add+0x104/0x160) from
[c0028330] (do_one_initcall+0x58/0x1b4)
[ 156.235717] [c0028330] (do_one_initcall+0x58/0x1b4) from
[c006c948] (sys_init_module+0x90/0x1a4)
[ 156.244964] [c006c948] (sys_init_module+0x90/0x1a4) from
[c0028e40] (ret_fast_syscall+0x0/0x30)
My board specific code:
// IGEP CAM BUS NUM
#define BASTIX_CAM_I2C_BUS_NUM 2
static int __init cam_init(void)
{
return 0;
}
static struct mt9t001_platform_data bastix_mt9p031_platform_data = {
.clk_pol= 0,
};
static struct i2c_board_info bastix_camera_i2c_devices[] = {
{
I2C_BOARD_INFO(MT9P031_NAME, MT9P031_I2C_ADDR),
.platform_data = bastix_mt9p031_platform_data,
},
};
static struct v4l2_subdev_i2c_board_info bastix_camera_mt9p031[] = {
{
Re: OMAP 3530 camera ISP forks and new media framework
Hi Laurent,
2010/10/12 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Tuesday 12 October 2010 14:10:00 Bastian Hecht wrote:
2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Monday 11 October 2010 16:58:35 Bastian Hecht wrote:
2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
So... let's see if i got some things right, please let me now if you
disagree:
- I do want to use the omap34xxcam.c driver as it is for the newest
framework and I get most support for it
That's a bad start. With the latest driver, omap34xxcam.c doesn't
exist anymore :-)
Nice :S
I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
your framework is too much for me to start with). So in this driver I
tell the framework that I can do i2c probing, some subdev_core_ops and
some subdev_video_ops. I define these functions that mostly do some
basic i2c communication to the sensor chip. I guess I can handle that
as there are so many examples out there.
The best solution would be to add mt9p031 support to the mt9t001 driver.
If that's too difficult to start with, you can copy mt9t001 to mt9p031
and modify the driver as needed and merge the two drivers when you will
be satisfied with the result.
OK, now I built the nokia kernel for the omap3-isp and made your
mt9t001.c work for it.
In mt9t001.c you call i2c_add_driver(mt9t001_driver);
As far I as I figured out the driver core system looks for matches
between registered devices in arch/arm/omap/devices.c and appropriate
drivers.
The driver core looks for matches between registered drivers and registered
devices. Devices are registered in lots of places, arch/arm/omap/devices.c is
only one of them. Board-specific devices are registered (or at least declared)
in a board file located (for this architecture) in arch/arm/mach-omap2/.
Is the next step to include a static struct platform_device into
devices.c? Or is there a special i2c_device struct that I have to use?
The OMAP3 ISP driver requires platform data that contain, among other
information, the list of I2C subdevices. Have a look at arch/arm/mach-
omap2/board-rx51-camera.c.
OK, I am closing in :)
I registered the OMAP_ISP device in my board-module. The driver kicks in
[ 205.686248] omap3isp omap3isp: Revision 2.0 found
and I can see the device in /sys/devices/platform/omap3isp.
I loaded your slightly modified mt9t001 module under the name mt9p031
and I can find it under
/sys/bus/i2c/drivers/mt9p031
/sys/module/laurentcam/drivers/i2c:mt9p031
But this subdevice-driver doesn't get active (I added alot printk in
the sensor module code, but no probing, nothing happens except the
registration). I have not connected anything to the camera isp
physically, but I think it should find out when probing?
I also see no /dev/videox device from the isp. Can you guide me to
next step? Your help makes it so much easier and I really appreciate
it :)
Thanks,
Bastian
Here my board code:
static struct mt9t001_platform_data bastix_mt9p031_platform_data = {
.clk_pol= 0,
};
static struct i2c_board_info bastix_camera_i2c_devices[] = {
{
I2C_BOARD_INFO(MT9P031_NAME, MT9P031_I2C_ADDR), /*
name is mt9p031 and i2caddr is fantasy number */
.platform_data = bastix_mt9p031_platform_data,
},
};
static struct v4l2_subdev_i2c_board_info bastix_camera_mt9p031[] = {
{
.board_info = bastix_camera_i2c_devices[0],
.i2c_adapter_id = BASTIX_CAM_I2C_BUS_NUM, /* busnum is 2 */
.module_name = mt9p031,
},
{ NULL, 0, NULL, },
};
static struct isp_v4l2_subdevs_group bastix_camera_subdevs[] = {
{
.subdevs = bastix_camera_mt9p031,
.interface = ISP_INTERFACE_CCP2B_PHY1,
.bus = { .ccp2 = {
.strobe_clk_pol = 0,
.crc= 1,
.ccp2_mode = 1,
.phy_layer = 1,
.vpclk_div = 1,
} },
},
{ NULL, 0, },
};
static struct isp_platform_data bastix_isp_platform_data = {
.subdevs = bastix_camera_subdevs,
};
module_init() {
...
omap3isp_device.dev.platform_data = bastix_isp_platform_data;
return platform_device_register(omap3isp_device);
}
--
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: OMAP 3530 camera ISP forks and new media framework
Hello Laurent, 2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Monday 11 October 2010 16:58:35 Bastian Hecht wrote: 2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: So... let's see if i got some things right, please let me now if you disagree: - I do want to use the omap34xxcam.c driver as it is for the newest framework and I get most support for it That's a bad start. With the latest driver, omap34xxcam.c doesn't exist anymore :-) Nice :S I think I take the mt9t001 approach (Sorry Guennadi, I think modifying your framework is too much for me to start with). So in this driver I tell the framework that I can do i2c probing, some subdev_core_ops and some subdev_video_ops. I define these functions that mostly do some basic i2c communication to the sensor chip. I guess I can handle that as there are so many examples out there. The best solution would be to add mt9p031 support to the mt9t001 driver. If that's too difficult to start with, you can copy mt9t001 to mt9p031 and modify the driver as needed and merge the two drivers when you will be satisfied with the result. OK, now I built the nokia kernel for the omap3-isp and made your mt9t001.c work for it. In mt9t001.c you call i2c_add_driver(mt9t001_driver); As far I as I figured out the driver core system looks for matches between registered devices in arch/arm/omap/devices.c and appropriate drivers. Is the next step to include a static struct platform_device into devices.c? Or is there a special i2c_device struct that I have to use? Thanks so much, Bastian But where do I stack that on top? On the camera bridge host, but if it isn't omap34xxcam, which driver can I use? How are they connected? http://gitorious.org/maemo-multimedia/omap3isp-rx51 The omap34xxcam.ko and isp-mod.ko modules have been merged into a single omap3-isp.ko module. All the driver code is now in drivers/media/video/isp. -- 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: OMAP 3530 camera ISP forks and new media framework
2010/10/12 Bastian Hecht hec...@googlemail.com: Hello Laurent, 2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Monday 11 October 2010 16:58:35 Bastian Hecht wrote: 2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: So... let's see if i got some things right, please let me now if you disagree: - I do want to use the omap34xxcam.c driver as it is for the newest framework and I get most support for it That's a bad start. With the latest driver, omap34xxcam.c doesn't exist anymore :-) Nice :S I think I take the mt9t001 approach (Sorry Guennadi, I think modifying your framework is too much for me to start with). So in this driver I tell the framework that I can do i2c probing, some subdev_core_ops and some subdev_video_ops. I define these functions that mostly do some basic i2c communication to the sensor chip. I guess I can handle that as there are so many examples out there. The best solution would be to add mt9p031 support to the mt9t001 driver. If that's too difficult to start with, you can copy mt9t001 to mt9p031 and modify the driver as needed and merge the two drivers when you will be satisfied with the result. OK, now I built the nokia kernel for the omap3-isp and made your mt9t001.c work for it. In mt9t001.c you call i2c_add_driver(mt9t001_driver); As far I as I figured out the driver core system looks for matches between registered devices in arch/arm/omap/devices.c and appropriate drivers. Is the next step to include a static struct platform_device into devices.c? Or is there a special i2c_device struct that I have to use? Thanks so much, Bastian I now use the board-rx51-camera.c as scaffold and try to integrate my camera chip device information. But where do I stack that on top? On the camera bridge host, but if it isn't omap34xxcam, which driver can I use? How are they connected? http://gitorious.org/maemo-multimedia/omap3isp-rx51 The omap34xxcam.ko and isp-mod.ko modules have been merged into a single omap3-isp.ko module. All the driver code is now in drivers/media/video/isp. -- 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: OMAP 3530 camera ISP forks and new media framework
So... let's see if i got some things right, please let me now if you disagree: - I do want to use the omap34xxcam.c driver as it is for the newest framework and I get most support for it - The camera sensor driver must implement the v4l2-subdev and the new pad-level api. As the register list of mt9t031 and mt9p031 sensors are identical, I could copy the subdev-part. But the existing mt9t031 driver stacks on top of soc_camera. soc_camera creates a v4l2 device. omap34xxcam also creates a v4l2 dev. Obviously they are competing architectures. Guennadi wrote: There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if mt9t031 and mt9p031 are indeed similar enough, I think, the right way is to join efforts to port soc-camera over to the new pad-level API and re-use the driver. This confuses me a bit now. Guennadi, is your idea to update the soc_camera interface for pad-level support and port omap34xxcam to a soc_camera_omap34xxcam? I don't think I am capable of writing a new host bridge driver, so I would prefer touching only the sensor driver part. Or do you think it is better to remove the soc_camera dependency and fit the camera sensor driver to omap34xxcam directly? - If I do the later, I take Laurent's approach and look at his MT9T001 sensor driver for Sakari's omap34xxcam host driver and adapt it for my needs. I can look for more subdev pad-level examples in Vaibhav's repository. So long, thanks for all your help, Bastian -- 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 3530 camera ISP forks and new media framework
2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: So... let's see if i got some things right, please let me now if you disagree: - I do want to use the omap34xxcam.c driver as it is for the newest framework and I get most support for it That's a bad start. With the latest driver, omap34xxcam.c doesn't exist anymore :-) Nice :S I think I take the mt9t001 approach (Sorry Guennadi, I think modifying your framework is too much for me to start with). So in this driver I tell the framework that I can do i2c probing, some subdev_core_ops and some subdev_video_ops. I define these functions that mostly do some basic i2c communication to the sensor chip. I guess I can handle that as there are so many examples out there. But where do I stack that on top? On the camera bridge host, but if it isn't omap34xxcam, which driver can I use? How are they connected? Thanks, Bastian -- 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 3530 camera ISP forks and new media framework
2010/10/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Mon, 11 Oct 2010, Bastian Hecht wrote: 2010/10/11 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: So... let's see if i got some things right, please let me now if you disagree: - I do want to use the omap34xxcam.c driver as it is for the newest framework and I get most support for it That's a bad start. With the latest driver, omap34xxcam.c doesn't exist anymore :-) Nice :S I think I take the mt9t001 approach (Sorry Guennadi, I think modifying your framework is too much for me to start with). AFAIR, you said, that register sets of mt9t031 and mt9p031 are identical, so, I think, I will be against mainlining a new driver for the same hardware for the pad-level ops, duplicating an soc-camera driver. Apart from creating a one-off redundancy, this looks like an extremely negative precedent to me. That said, please, double check your estimate as identical. If there are differences, say, even in only 10% of registers, it might still be justified to make a new driver. mt9m001 and mt9t031 are also very similar, still, it appeared to me at that time, that a new driver would be cleaner, than a single driver full of forks or other indirections. Thanks Guennadi The point is, I will jump around my office for a full day when I get out a single picture of my camera PCB. After that I will gladly work towards uncluttering the driver duplication. I will see if it fits better the mt9t001 or mt9t031 and integrate it in there. Cheers, Bastian So in this driver I tell the framework that I can do i2c probing, some subdev_core_ops and some subdev_video_ops. I define these functions that mostly do some basic i2c communication to the sensor chip. I guess I can handle that as there are so many examples out there. But where do I stack that on top? On the camera bridge host, but if it isn't omap34xxcam, which driver can I use? How are they connected? Thanks, Bastian --- 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: OMAP 3530 camera ISP forks and new media framework
Bastian Hecht wrote: I want to write a sensor driver for the mt9p031 (not mt9t031) camera chip and start getting confused about the different kernel forks and There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if mt9t031 and mt9p031 are indeed similar enough, I think, the right way is to join efforts to port soc-camera over to the new pad-level API and re-use the driver. Thanks Guennadi That would be wonderful. As this is my first contact with v4l2 in the kernel I keep reading through the docs and the sources to get a firmer grasp of all the stuff here. Thanks, Bastian http://www.symplektikon.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
OMAP 3530 camera ISP forks and new media framework
Hello media team, I want to write a sensor driver for the mt9p031 (not mt9t031) camera chip and start getting confused about the different kernel forks and architectural changes that happen in V4L2. A similar problem was discussed in this mailing list at http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html. Currently I don't know which branch to follow. Either http://gitorious.org/omap3camera from Sakari Ailus or the branch media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from Laurent Pinchart. Both have an folder drivers/media/video/isp and are written for the new media controller architecture if I am right. I see in http://gitorious.org/omap3camera/camera-firmware that there is already an empty placeholder for the mt9t031. The README of the camera-firmware repository states: makemodes.pl is a perl script which converts sensor register lists from FIXME into C code. dcc-pulautin is a Makefile (mostly) that converts sensor register lists as C code into binaries understandable to sensor drivers. The end result is a binary with sensor driver name, sensor version and bin suffix, for example et8ek8-0002.bin. So I think the goal is to provide a script framework for camera systems. You just script some register tables and it creates a binary that can be read by a sensor driver made for that framework. If the a camera bridge driver for your chip exists, you are done. Am I right? Are drivers/media/video/et8ek8.c and drivers/staging/dream/camera/mt9p012_* such drivers? So do you think it is the right way to go to use your ISP driver, adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and write a register list and create a camera firmware for that sensor driver with makemodes? I am still quite confused... if I get something wrong, please give me some hints. Thanks a lot! Bastian Hecht -- 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
