2017-06-22 15:06:47

by Hugues Fruchet

[permalink] [raw]
Subject: [PATCH v1 0/6] Add support of OV9655 camera

This patchset enables OV9655 camera support.

OV9655 support has been tested using STM32F4DIS-CAM extension board
plugged on connector P1 of STM32F746G-DISCO board.
Due to lack of OV9650/52 hardware support, the modified related code
could not have been checked for non-regression.

First patches upgrade current support of OV9650/52 to prepare then
introduction of OV9655 variant patch.
Because of OV9655 register set slightly different from OV9650/9652,
not all of the driver features are supported (controls). Supported
resolutions are limited to VGA, QVGA, QQVGA.
Supported format is limited to RGB565.
Controls are limited to color bar test pattern for test purpose.

OV9655 initial support is based on a driver written by H. Nikolaus Schaller [1].
OV9655 registers sequences come from STM32CubeF7 embedded software [2].

[1] http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
[2] https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c

===========
= history =
===========
version 1:
- Initial submission.

H. Nikolaus Schaller (1):
DT bindings: add bindings for ov965x camera module

Hugues Fruchet (5):
[media] ov9650: add device tree support
[media] ov9650: select the nearest higher resolution
[media] ov9650: use write_array() for resolution sequences
[media] ov9650: add multiple variant support
[media] ov9650: add support of OV9655 variant

.../devicetree/bindings/media/i2c/ov965x.txt | 37 +
drivers/media/i2c/Kconfig | 6 +-
drivers/media/i2c/ov9650.c | 792 +++++++++++++++++----
3 files changed, 704 insertions(+), 131 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt

--
1.9.1


2017-06-22 15:06:49

by Hugues Fruchet

[permalink] [raw]
Subject: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

From: "H. Nikolaus Schaller" <[email protected]>

This adds documentation of device tree bindings
for the OV965X family camera sensor module.

Signed-off-by: H. Nikolaus Schaller <[email protected]>
Signed-off-by: Hugues Fruchet <[email protected]>
---
.../devicetree/bindings/media/i2c/ov965x.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
new file mode 100644
index 0000000..0e0de1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
@@ -0,0 +1,37 @@
+* Omnivision OV9650/9652/9655 CMOS sensor
+
+The Omnivision OV965x sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties:
+- compatible: should be one of
+ "ovti,ov9650"
+ "ovti,ov9652"
+ "ovti,ov9655"
+- clocks: reference to the mclk input clock.
+
+Optional Properties:
+- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
+- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+&i2c2 {
+ ov9655: camera@30 {
+ compatible = "ovti,ov9655";
+ reg = <0x30>;
+ pwdn-gpios = <&gpioh 13 GPIO_ACTIVE_HIGH>;
+ clocks = <&clk_ext_camera>;
+
+ port {
+ ov9655: endpoint {
+ remote-endpoint = <&dcmi_0>;
+ };
+ };
+ };
+};
--
1.9.1

2017-06-22 15:06:48

by Hugues Fruchet

[permalink] [raw]
Subject: [PATCH v1 4/6] [media] ov9650: use write_array() for resolution sequences

Align resolution sequences on initialization sequence using
i2c_rv structure NULL terminated .This add flexibility
on resolution sequence size.
Document resolution related registers by using corresponding
define instead of hexa address/value.

Signed-off-by: Hugues Fruchet <[email protected]>
---
drivers/media/i2c/ov9650.c | 98 ++++++++++++++++++++++++++++++----------------
1 file changed, 64 insertions(+), 34 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 4311da6..8b283c9 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -227,11 +227,16 @@ struct ov965x_ctrls {
u8 update;
};

+struct i2c_rv {
+ u8 addr;
+ u8 value;
+};
+
struct ov965x_framesize {
u16 width;
u16 height;
u16 max_exp_lines;
- const u8 *regs;
+ const struct i2c_rv *regs;
};

struct ov965x_interval {
@@ -280,9 +285,11 @@ struct ov965x {
u8 apply_frame_fmt;
};

-struct i2c_rv {
- u8 addr;
- u8 value;
+struct ov965x_pixfmt {
+ u32 code;
+ u32 colorspace;
+ /* REG_TSLB value, only bits [3:2] may be set. */
+ u8 tslb_reg;
};

static const struct i2c_rv ov965x_init_regs[] = {
@@ -342,30 +349,59 @@ struct i2c_rv {
{ REG_NULL, 0 }
};

-#define NUM_FMT_REGS 14
-/*
- * COM7, COM3, COM4, HSTART, HSTOP, HREF, VSTART, VSTOP, VREF,
- * EXHCH, EXHCL, ADC, OCOM, OFON
- */
-static const u8 frame_size_reg_addr[NUM_FMT_REGS] = {
- 0x12, 0x0c, 0x0d, 0x17, 0x18, 0x32, 0x19, 0x1a, 0x03,
- 0x2a, 0x2b, 0x37, 0x38, 0x39,
-};
-
-static const u8 ov965x_sxga_regs[NUM_FMT_REGS] = {
- 0x00, 0x00, 0x00, 0x1e, 0xbe, 0xbf, 0x01, 0x81, 0x12,
- 0x10, 0x34, 0x81, 0x93, 0x51,
+static const struct i2c_rv ov965x_sxga_regs[] = {
+ { REG_COM7, 0x00 },
+ { REG_COM3, 0x00 },
+ { REG_COM4, 0x00 },
+ { REG_HSTART, 0x1e },
+ { REG_HSTOP, 0xbe },
+ { 0x32, 0xbf },
+ { REG_VSTART, 0x01 },
+ { REG_VSTOP, 0x81 },
+ { REG_VREF, 0x12 },
+ { REG_EXHCH, 0x10 },
+ { REG_EXHCL, 0x34 },
+ { REG_ADC, 0x81 },
+ { REG_ACOM, 0x93 },
+ { REG_OFON, 0x51 },
+ { REG_NULL, 0 },
};

-static const u8 ov965x_vga_regs[NUM_FMT_REGS] = {
- 0x40, 0x04, 0x80, 0x26, 0xc6, 0xed, 0x01, 0x3d, 0x00,
- 0x10, 0x40, 0x91, 0x12, 0x43,
+static const struct i2c_rv ov965x_vga_regs[] = {
+ { REG_COM7, 0x40 },
+ { REG_COM3, 0x04 },
+ { REG_COM4, 0x80 },
+ { REG_HSTART, 0x26 },
+ { REG_HSTOP, 0xc6 },
+ { 0x32, 0xed },
+ { REG_VSTART, 0x01 },
+ { REG_VSTOP, 0x3d },
+ { REG_VREF, 0x00 },
+ { REG_EXHCH, 0x10 },
+ { REG_EXHCL, 0x40 },
+ { REG_ADC, 0x91 },
+ { REG_ACOM, 0x12 },
+ { REG_OFON, 0x43 },
+ { REG_NULL, 0 },
};

/* Determined empirically. */
-static const u8 ov965x_qvga_regs[NUM_FMT_REGS] = {
- 0x10, 0x04, 0x80, 0x25, 0xc5, 0xbf, 0x00, 0x80, 0x12,
- 0x10, 0x40, 0x91, 0x12, 0x43,
+static const struct i2c_rv ov965x_qvga_regs[] = {
+ { REG_COM7, 0x10 },
+ { REG_COM3, 0x04 },
+ { REG_COM4, 0x80 },
+ { REG_HSTART, 0x25 },
+ { REG_HSTOP, 0xc5 },
+ { 0x32, 0xbf },
+ { REG_VSTART, 0x00 },
+ { REG_VSTOP, 0x80 },
+ { REG_VREF, 0x12 },
+ { REG_EXHCH, 0x10 },
+ { REG_EXHCL, 0x40 },
+ { REG_ADC, 0x91 },
+ { REG_ACOM, 0x12 },
+ { REG_OFON, 0x43 },
+ { REG_NULL, 0 },
};

static const struct ov965x_framesize ov965x_framesizes[] = {
@@ -387,13 +423,6 @@ struct i2c_rv {
},
};

-struct ov965x_pixfmt {
- u32 code;
- u32 colorspace;
- /* REG_TSLB value, only bits [3:2] may be set. */
- u8 tslb_reg;
-};
-
static const struct ov965x_pixfmt ov965x_formats[] = {
{ MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG, 0x00},
{ MEDIA_BUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG, 0x04},
@@ -1268,11 +1297,12 @@ static int ov965x_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config

static int ov965x_set_frame_size(struct ov965x *ov965x)
{
- int i, ret = 0;
+ int ret = 0;
+
+ v4l2_dbg(1, debug, ov965x->client, "%s\n", __func__);

- for (i = 0; ret == 0 && i < NUM_FMT_REGS; i++)
- ret = ov965x_write(ov965x->client, frame_size_reg_addr[i],
- ov965x->frame_size->regs[i]);
+ ret = ov965x_write_array(ov965x->client,
+ ov965x->frame_size->regs);
return ret;
}

--
1.9.1

2017-06-22 15:06:45

by Hugues Fruchet

[permalink] [raw]
Subject: [PATCH v1 3/6] [media] ov9650: select the nearest higher resolution

Refine the resolution selection algorithm by selecting
only the nearest higher resolution (instead of lower and higher).

Signed-off-by: Hugues Fruchet <[email protected]>
---
drivers/media/i2c/ov9650.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 8340a45..4311da6 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1196,9 +1196,11 @@ static void __ov965x_try_frame_size(struct v4l2_mbus_framefmt *mf,
unsigned int min_err = UINT_MAX;

while (i--) {
- int err = abs(fsize->width - mf->width)
- + abs(fsize->height - mf->height);
- if (err < min_err) {
+ int w_err = (fsize->width - mf->width);
+ int h_err = (fsize->height - mf->height);
+ int err = w_err + h_err;
+
+ if ((w_err >= 0) && (h_err >= 0) && (err < min_err)) {
min_err = err;
match = fsize;
}
--
1.9.1

2017-06-22 15:07:54

by Hugues Fruchet

[permalink] [raw]
Subject: [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant

Add a first support of OV9655 variant.
Because of register set slightly different from OV9650/9652,
not all of the driver features are supported (controls).
Supported resolutions are limited to VGA, QVGA, QQVGA.
Supported format is limited to RGB565.
Controls are limited to color bar test pattern for test purpose.

Signed-off-by: H. Nikolaus Schaller <[email protected]>
Signed-off-by: Hugues Fruchet <[email protected]>
---
drivers/media/i2c/Kconfig | 4 +-
drivers/media/i2c/ov9650.c | 486 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 457 insertions(+), 33 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index efea14d..a8f638c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -594,11 +594,11 @@ config VIDEO_OV7670
controller.

config VIDEO_OV9650
- tristate "OmniVision OV9650/OV9652 sensor support"
+ tristate "OmniVision OV9650/OV9652/OV9655 sensor support"
depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
---help---
This is a V4L2 sensor-level driver for the Omnivision
- OV9650 and OV9652 camera sensors.
+ OV9650 and OV9652 and OV9655 camera sensors.

config VIDEO_VS6624
tristate "ST VS6624 sensor support"
diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index a9d268d..c0819af 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1,5 +1,5 @@
/*
- * Omnivision OV9650/OV9652 CMOS Image Sensor driver
+ * Omnivision OV9650/OV9652/OV9655 CMOS Image Sensor driver
*
* Copyright (C) 2013, Sylwester Nawrocki <[email protected]>
*
@@ -7,6 +7,15 @@
* by Vladimir Fonov.
* Copyright (c) 2010, Vladimir Fonov
*
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Author: Hugues Fruchet <[email protected]> for STMicroelectronics.
+ *
+ * OV9655 initial support based on a driver written by H. Nikolaus Schaller:
+ * http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
+ * OV9655 registers sequence from STM32CubeF7 embedded software, see:
+ * https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
@@ -58,14 +67,21 @@
#define REG_PID 0x0a /* Product ID MSB */
#define REG_VER 0x0b /* Product ID LSB */
#define REG_COM3 0x0c
-#define COM3_SWAP 0x40
+#define COM3_COLORBAR 0x80
+#define COM3_RGB565 0x00
+#define COM3_SWAP 0x40 /* Doesn't work in RGB */
+#define COM3_RESETB 0x08
#define COM3_VARIOPIXEL1 0x04
+#define OV9655_SINGLEFRAME 0x01
#define REG_COM4 0x0d /* Vario Pixels */
#define COM4_VARIOPIXEL2 0x80
+#define OV9655_TRISTATE /* seems to have a different function */
#define REG_COM5 0x0e /* System clock options */
#define COM5_SLAVE_MODE 0x10
-#define COM5_SYSTEMCLOCK48MHZ 0x80
+#define COM5_SYSTEMCLOCK48MHZ 0x80 /* not on OV9655 */
+#define OV9655_EXPOSURESTEP 0x01
#define REG_COM6 0x0f /* HREF & ADBLC options */
+#define COM6_BLC_OPTICAL 0x40 /* Optical black */
#define REG_AECH 0x10 /* Exposure value, AEC[9:2] */
#define REG_CLKRC 0x11 /* Clock control */
#define CLK_EXT 0x40 /* Use external clock directly */
@@ -74,13 +90,18 @@
#define COM7_RESET 0x80
#define COM7_FMT_MASK 0x38
#define COM7_FMT_VGA 0x40
-#define COM7_FMT_CIF 0x20
+#define COM7_FMT_CIF 0x20
#define COM7_FMT_QVGA 0x10
#define COM7_FMT_QCIF 0x08
-#define COM7_RGB 0x04
-#define COM7_YUV 0x00
-#define COM7_BAYER 0x01
-#define COM7_PBAYER 0x05
+#define COM7_RGB 0x04
+#define COM7_YUV 0x00
+#define COM7_BAYER 0x01
+#define COM7_PBAYER 0x05
+#define OV9655_COM7_VGA 0x60
+#define OV9655_COM7_RAWRGB 0x00 /* different format encoding */
+#define OV9655_COM7_RAWRGBINT 0x01
+#define OV9655_COM7_YUV 0x02
+#define OV9655_COM7_RGB 0x03
#define REG_COM8 0x13 /* AGC/AEC options */
#define COM8_FASTAEC 0x80 /* Enable fast AGC/AEC */
#define COM8_AECSTEP 0x40 /* Unlimited AEC step size */
@@ -89,14 +110,23 @@
#define COM8_AWB 0x02 /* White balance enable */
#define COM8_AEC 0x01 /* Auto exposure enable */
#define REG_COM9 0x14 /* Gain ceiling */
-#define COM9_GAIN_CEIL_MASK 0x70 /* */
+#define COM9_GAIN_CEIL_MASK 0x70
+#define COM9_GAIN_CEIL_16X 0x30
+#define OV9655_COM9_EXPTIMING 0x08
+#define OV9655_COM9_VSYNCDROP 0x04
+#define OV9655_COM9_AECDROP 0x02
#define REG_COM10 0x15 /* PCLK, HREF, HSYNC signals polarity */
+#define OV9655_SLAVE_PIN 0x80 /* SLHS/SLVS instead of RESETB/PWDN */
#define COM10_HSYNC 0x40 /* HSYNC instead of HREF */
#define COM10_PCLK_HB 0x20 /* Suppress PCLK on horiz blank */
-#define COM10_HREF_REV 0x08 /* Reverse HREF */
+#define OV9655_COM10_PCLK_REV 0x10 /* PCLK reverse */
+#define COM10_HREF_REV 0x08 /* Reverse HREF */
#define COM10_VS_LEAD 0x04 /* VSYNC on clock leading edge */
+#define OV9655_COM10_RESET_OPTION 0x04 /* Reset signal end point */
#define COM10_VS_NEG 0x02 /* VSYNC negative */
#define COM10_HS_NEG 0x01 /* HSYNC negative */
+#define OV9655_REG16 0x16 /* dummy frame and blanking */
+#define OV9655_REG16_DUMMY_8 0x20 /* dummy frame when gain > 8 */
#define REG_HSTART 0x17 /* Horiz start high bits */
#define REG_HSTOP 0x18 /* Horiz stop high bits */
#define REG_VSTART 0x19 /* Vert start high bits */
@@ -117,6 +147,7 @@
#define REG_BBIAS 0x27 /* B channel output bias */
#define REG_GBBIAS 0x28 /* Gb channel output bias */
#define REG_GRCOM 0x29 /* Analog BLC & regulator */
+#define OV9655_PREGAIN 0x29
#define REG_EXHCH 0x2a /* Dummy pixel insert MSB */
#define REG_EXHCL 0x2b /* Dummy pixel insert LSB */
#define REG_RBIAS 0x2c /* R channel output bias */
@@ -127,12 +158,30 @@
#define REG_HSYEN 0x31 /* HSYNC falling edge delay LSB*/
#define REG_HREF 0x32 /* HREF pieces */
#define REG_CHLF 0x33 /* reserved */
+#define OV9655_CLKF 0x33 /* Array current control */
+#define OV9655_AREF1 0x34 /* Array reference control */
+#define OV9655_AREF2 0x35 /* Array reference control */
+#define OV9655_AREF3 0x36 /* Array reference control */
#define REG_ADC 0x37 /* reserved */
+#define OV9655_ADC 0x37 /* ADC Control 1 (Range adjustment) */
#define REG_ACOM 0x38 /* reserved */
-#define REG_OFON 0x39 /* Power down register */
+#define OV9655_ADC2 0x38 /* ADC Control 2 (Range adjustment) */
+#define REG_OFON 0x39 /* Power down register (ov9650 only) */
#define OFON_PWRDN 0x08 /* Power down bit */
+#define OV9655_AREF4 0x39 /* Array reference control */
#define REG_TSLB 0x3a /* YUVU format */
+#define OV9655_PCLKDELAY2NS 0x40
+#define OV9655_PCLKDELAY4NS 0x80
+#define OV9655_PCLKDELAY6NS 0xc0
+#define OV9655_OUTREVERSE 0x20
+#define OV9655_FIXEDUV 0x10
#define TSLB_YUYV_MASK 0x0c /* UYVY or VYUY - see com13 */
+#define TSLB_YUYV 0x00
+#define TSLB_YVYU 0x04
+#define TSLB_VYUY 0x08
+#define TSLB_UYVY 0x0c
+#define OV9655_BANDINGAUTO 0x02
+
#define REG_COM11 0x3b /* Night mode, banding filter enable */
#define COM11_NIGHT 0x80 /* Night mode enable */
#define COM11_NMFR 0x60 /* Two bit NM frame rate */
@@ -142,25 +191,38 @@
#define COM12_HREF 0x80 /* HREF always */
#define REG_COM13 0x3d /* Gamma selection, Color matrix en. */
#define COM13_GAMMA 0x80 /* Gamma enable */
-#define COM13_UVSAT 0x40 /* UV saturation auto adjustment */
+#define COM13_UVSAT 0x40 /* UV saturation auto adjustment */
+#define COM13_Y_DELAY 0x08 /* Delay Y channel */
#define COM13_UVSWAP 0x01 /* V before U - w/TSLB */
#define REG_COM14 0x3e /* Edge enhancement options */
#define COM14_EDGE_EN 0x02
#define COM14_EEF_X2 0x01
+#define OV9655_REG_COM14 0x3e /* pixel correction/zoom ON/OFF sel. */
+#define OV9655_COM14_BLACK_PIX 0x08 /* Black pixel correction */
+#define OV9655_COM14_WHITE_PIX 0x04 /* White pixel correction */
+#define OV9655_COM14_ZOOM 0x02 /* Zoom function ON */
#define REG_EDGE 0x3f /* Edge enhancement factor */
#define EDGE_FACTOR_MASK 0x0f
#define REG_COM15 0x40 /* Output range, RGB 555/565 */
#define COM15_R10F0 0x00 /* Data range 10 to F0 */
-#define COM15_R01FE 0x80 /* 01 to FE */
+#define COM15_R01FE 0x80 /* 01 to FE */
#define COM15_R00FF 0xc0 /* 00 to FF */
#define COM15_RGB565 0x10 /* RGB565 output */
#define COM15_RGB555 0x30 /* RGB555 output */
#define COM15_SWAPRB 0x04 /* Swap R&B */
#define REG_COM16 0x41 /* Color matrix coeff options */
#define REG_COM17 0x42 /* Single frame out, banding filter */
+#define OV9655_REG_COM17 0x42 /* Denoise, edge, auto gain, ... */
+#define OV9655_COM17_EDGE_AUTO 0x40 /* Edge auto */
+#define OV9655_COM17_DENOISE_AUTO 0x80 /* Denoise auto */
+#define OV9655_REG_RSVD(__n) (0x43 + (__n) - 1) /* reserved but used... */
/* n = 1...9, 0x4f..0x57 */
-#define REG_MTX(__n) (0x4f + (__n) - 1)
+#define REG_MTX(__n) (0x4f + (__n) - 1)
#define REG_MTXS 0x58
+#define REG_AWBOP(__n) (0x59 + (__n) - 1) /* AWB control options */
+#define REG_BLMT 0x5F /* AWB Blue Component Gain Limit */
+#define REG_RLMT 0x60 /* AWB Red Component Gain Limit */
+#define REG_GLMT 0x61 /* AWB Green Component Gain Limit */
/* Lens Correction Option 1...5, __n = 0...5 */
#define REG_LCC(__n) (0x62 + (__n) - 1)
#define LCC5_LCC_ENABLE 0x01 /* LCC5, enable lens correction */
@@ -170,10 +232,26 @@
#define REG_HV 0x69 /* Manual banding filter MSB */
#define REG_MBD 0x6a /* Manual banding filter value */
#define REG_DBLV 0x6b /* reserved */
+#define OV9655_REG_DBLV 0x6b /* PLL, DVDD regu bypass, bandgap */
+#define OV9655_DBLV_BANDGAP 0x0a /* default value */
+#define OV9655_DBLV_LDO_BYPASS 0x10
+#define OV9655_DBLV_PLL_BYPASS 0x00
+#define OV9655_DBLV_PLL_4X 0x40
+#define OV9655_DBLV_PLL_6X 0x80
+#define OV9655_DBLV_PLL_8X 0xc0
#define REG_GSP 0x6c /* Gamma curve */
#define GSP_LEN 15
+#define OV9655_REG_DNSTH 0x70 /* De-noise Function Threshold Adj. */
+#define OV9655_REG_POIDX 0x72 /* Pixel output index */
+#define OV9655_REG_PCKDV 0x73 /* Pixel Clock Output Selection */
+#define OV9655_REG_XINDX 0x74 /* Horizontal Scaling Down Coeff. */
+#define OV9655_REG_YINDX 0x75 /* Vertical Scaling Down Coeff. */
+#define OV9655_REG_SLOP 0x7A /* Gamma Curve Highest Segment Slope */
+#define OV9655_REG_GAM(__n) (0x7B + (__n) - 1) /* Gamma curve */
#define REG_GST 0x7c /* Gamma curve */
#define GST_LEN 15
+#define OV9655_REG_COM18 0x8b /* Zoom mode in VGA */
+#define OV9655_REG_COM19 0x8c /* UV adjustment */
#define REG_COM21 0x8b
#define REG_COM22 0x8c /* Edge enhancement, denoising */
#define COM22_WHTPCOR 0x02 /* White pixel correction enable */
@@ -181,6 +259,8 @@
#define COM22_DENOISE 0x10 /* White pixel correction option */
#define REG_COM23 0x8d /* Color bar test, color gain */
#define COM23_TEST_MODE 0x10
+#define OV9655_REG_COM20 0x8d
+#define OV9655_COM20_TEST_MODE 0x10
#define REG_DBLC1 0x8f /* Digital BLC */
#define REG_DBLC_B 0x90 /* Digital BLC B channel offset */
#define REG_DBLC_R 0x91 /* Digital BLC R channel offset */
@@ -193,6 +273,17 @@
#define REG_AECHM 0xa1 /* Exposure value - bits AEC[15:10] */
#define REG_BD50ST 0xa2 /* Banding filter value for 50Hz */
#define REG_BD60ST 0xa3 /* Banding filter value for 60Hz */
+#define OV9655_REG_COM21 0xa4 /* Digital gain */
+#define OV9655_REG_AWB_GREEN 0xa6 /* AWB green */
+#define OV9655_REG_REF_A8 0xa8 /* Analog Reference Control */
+#define OV9655_REG_REF_A9 0xa9 /* Analog Reference Control */
+#define OV9655_REG_BLC(__n) (0xac + (__n) - 1) /* Black Level Control */
+#define OV9655_REG_CTRLB4 0xb4 /* UV adjustment */
+#define OV9655_REG_ADBOFF 0xbc /* ADC B channel offset setting */
+#define OV9655_REG_ADROFF 0xbd /* ADC R channel offset setting */
+#define OV9655_REG_ADGBOFF 0xbe /* ADC Gb channel offset setting */
+#define OV9655_REG_ADGEOFF 0xbf /* ADC Gr channel offset setting */
+#define OV9655_REG_COM24 0xc7 /* Pixel clock frequency selection */
#define REG_NULL 0xff /* Array end token */

#define DEF_CLKRC 0x80
@@ -200,6 +291,7 @@
#define OV965X_ID(_msb, _lsb) ((_msb) << 8 | (_lsb))
#define OV9650_ID 0x9650
#define OV9652_ID 0x9652
+#define OV9655V5_ID 0x9657

struct ov965x_ctrls {
struct v4l2_ctrl_handler handler;
@@ -458,6 +550,292 @@ struct ov965x_pixfmt {
{{ 1, 25 }, { QVGA_WIDTH, QVGA_HEIGHT }, 1 }, /* 25 fps */
};

+/* OV9655 */
+static const struct i2c_rv ov9655_init_regs[] = {
+ { REG_GAIN, 0x00 },
+ { REG_BLUE, 0x80 },
+ { REG_RED, 0x80 },
+ { REG_VREF, 0x02 },
+ { REG_COM1, 0x03 },
+ { REG_COM2, 0x01 },/* Output drive x2 */
+ { REG_COM3, COM3_RGB565 },/* Output drive x2, RGB565 */
+ { REG_COM5, 0x60 | OV9655_EXPOSURESTEP },/* 0x60 ? */
+ { REG_COM6, COM6_BLC_OPTICAL },
+ { REG_CLKRC, 0x01 },/* F(internal clk) = F(input clk) / 2 */
+ { REG_COM7, OV9655_COM7_VGA | OV9655_COM7_YUV },
+ { REG_COM8, COM8_FASTAEC | COM8_AECSTEP |
+ COM8_AGC | COM8_AWB | COM8_AEC },
+ { REG_COM9, COM9_GAIN_CEIL_16X | OV9655_COM9_EXPTIMING |
+ OV9655_COM9_AECDROP },
+ { OV9655_REG16, OV9655_REG16_DUMMY_8 | 0x4 },
+ { REG_HSTART, 0x18 },
+ { REG_HSTOP, 0x04 },
+ { REG_VSTART, 0x01 },
+ { REG_VSTOP, 0x81 },
+ { REG_MVFP, 0x00 },/* No mirror/flip */
+ { REG_AEW, 0x3c },
+ { REG_AEB, 0x36 },
+ { REG_VPT, 0x72 },
+ { REG_BBIAS, 0x08 },
+ { REG_GBBIAS, 0x08 },
+ { OV9655_PREGAIN, 0x15 },
+ { REG_EXHCH, 0x00 },
+ { REG_EXHCL, 0x00 },
+ { REG_RBIAS, 0x08 },
+ { REG_HREF, 0x12 },/* QVGA */
+ { REG_CHLF, 0x00 },
+ { OV9655_AREF1, 0x3f },
+ { OV9655_AREF2, 0x00 },
+ { OV9655_AREF3, 0x3a },
+ { OV9655_ADC2, 0x72 },
+ { OV9655_AREF4, 0x57 },
+ { REG_TSLB, OV9655_PCLKDELAY6NS | TSLB_UYVY },
+ { REG_COM11, 0x04 },/* 0x04 ? */
+ { REG_COM13, COM13_GAMMA | 0x10 |
+ COM13_Y_DELAY | COM13_UVSWAP },/* 0x10 ? */
+ {OV9655_REG_COM14, OV9655_COM14_ZOOM }, /* QVGA */
+ { REG_EDGE, 0xc1 },
+ { REG_COM15, COM15_R00FF },/* Full range output */
+ { REG_COM16, 0x41 },/* 0x41 ? */
+ { OV9655_REG_COM17, OV9655_COM17_EDGE_AUTO |
+ OV9655_COM17_DENOISE_AUTO },
+ { OV9655_REG_RSVD(1), 0x0a },
+ { OV9655_REG_RSVD(2), 0xf0 },
+ { OV9655_REG_RSVD(3), 0x46 },
+ { OV9655_REG_RSVD(4), 0x62 },
+ { OV9655_REG_RSVD(5), 0x2a },
+ { OV9655_REG_RSVD(6), 0x3c },
+ { OV9655_REG_RSVD(7), 0xfc },
+ { OV9655_REG_RSVD(8), 0xfc },
+ { OV9655_REG_RSVD(9), 0x7f },
+ { OV9655_REG_RSVD(10), 0x7f },
+ { OV9655_REG_RSVD(11), 0x7f },
+ { REG_MTX(1), 0x98 },
+ { REG_MTX(2), 0x98 },
+ { REG_MTX(3), 0x00 },
+ { REG_MTX(4), 0x28 },
+ { REG_MTX(5), 0x70 },
+ { REG_MTX(6), 0x98 },
+ { REG_MTXS, 0x1a },
+ { REG_AWBOP(1), 0x85 },
+ { REG_AWBOP(2), 0xa9 },
+ { REG_AWBOP(3), 0x64 },
+ { REG_AWBOP(4), 0x84 },
+ { REG_AWBOP(5), 0x53 },
+ { REG_AWBOP(6), 0x0e },
+ { REG_BLMT, 0xf0 },
+ { REG_RLMT, 0xf0 },
+ { REG_GLMT, 0xf0 },
+ { REG_LCC(1), 0x00 },
+ { REG_LCC(2), 0x00 },
+ { REG_LCC(3), 0x02 },
+ { REG_LCC(4), 0x20 },
+ { REG_LCC(5), 0x00 },
+ { 0x69, 0x0a },/* Reserved... */
+ { OV9655_REG_DBLV, OV9655_DBLV_PLL_4X | OV9655_DBLV_LDO_BYPASS |
+ OV9655_DBLV_BANDGAP },
+ { 0x6c, 0x04 },/* Reserved... */
+ { 0x6d, 0x55 },/* Reserved... */
+ { 0x6e, 0x00 },/* Reserved... */
+ { 0x6f, 0x9d },/* Reserved... */
+ { OV9655_REG_DNSTH, 0x21 },
+ { 0x71, 0x78 },/* Reserved... */
+ { OV9655_REG_POIDX, 0x11 },/* QVGA */
+ { OV9655_REG_PCKDV, 0x01 },/* QVGA */
+ { OV9655_REG_XINDX, 0x10 },
+ { OV9655_REG_YINDX, 0x10 },
+ { 0x76, 0x01 },/* Reserved... */
+ { 0x77, 0x02 },/* Reserved... */
+ { 0x7A, 0x12 },/* Reserved... */
+ { OV9655_REG_GAM(1), 0x08 },
+ { OV9655_REG_GAM(2), 0x16 },
+ { OV9655_REG_GAM(3), 0x30 },
+ { OV9655_REG_GAM(4), 0x5e },
+ { OV9655_REG_GAM(5), 0x72 },
+ { OV9655_REG_GAM(6), 0x82 },
+ { OV9655_REG_GAM(7), 0x8e },
+ { OV9655_REG_GAM(8), 0x9a },
+ { OV9655_REG_GAM(9), 0xa4 },
+ { OV9655_REG_GAM(10), 0xac },
+ { OV9655_REG_GAM(11), 0xb8 },
+ { OV9655_REG_GAM(12), 0xc3 },
+ { OV9655_REG_GAM(13), 0xd6 },
+ { OV9655_REG_GAM(14), 0xe6 },
+ { OV9655_REG_GAM(15), 0xf2 },
+ { 0x8a, 0x24 },/* Reserved... */
+ { OV9655_REG_COM19, 0x80 },
+ { 0x90, 0x7d },/* Reserved... */
+ { 0x91, 0x7b },/* Reserved... */
+ { REG_LCCFB, 0x02 },
+ { REG_LCCFR, 0x02 },
+ { REG_DBLC_GB, 0x7a },
+ { REG_DBLC_GR, 0x79 },
+ { REG_AECHM, 0x40 },
+ { OV9655_REG_COM21, 0x50 },
+ { 0xa5, 0x68 },/* Reserved... */
+ { OV9655_REG_AWB_GREEN, 0x4a },
+ { OV9655_REG_REF_A8, 0xc1 },
+ { OV9655_REG_REF_A9, 0xef },
+ { 0xaa, 0x92 },/* Reserved... */
+ { 0xab, 0x04 },/* Reserved... */
+ { OV9655_REG_BLC(1), 0x80 },
+ { OV9655_REG_BLC(2), 0x80 },
+ { OV9655_REG_BLC(3), 0x80 },
+ { OV9655_REG_BLC(4), 0x80 },
+ { OV9655_REG_BLC(7), 0xf2 },
+ { OV9655_REG_BLC(8), 0x20 },
+ { OV9655_REG_CTRLB4, 0x20 },
+ { 0xb5, 0x00 },/* Reserved... */
+ { 0xb6, 0xaf },/* Reserved... */
+ { 0xb6, 0xaf },/* Reserved... */
+ { 0xbb, 0xae },/* Reserved... */
+ { OV9655_REG_ADBOFF, 0x7f },
+ { OV9655_REG_ADROFF, 0x7f },
+ { OV9655_REG_ADGBOFF, 0x7f },
+ { OV9655_REG_ADGEOFF, 0x7f },
+ { OV9655_REG_ADGEOFF, 0x7f },
+ { 0xc0, 0xaa },/* Reserved... */
+ { 0xc1, 0xc0 },/* Reserved... */
+ { 0xc2, 0x01 },/* Reserved... */
+ { 0xc3, 0x4e },/* Reserved... */
+ { 0xc6, 0x05 },/* Reserved... */
+ { OV9655_REG_COM24, 0x81 },/* QVGA */
+ { 0xc9, 0xe0 },/* Reserved... */
+ { 0xca, 0xe8 },/* Reserved... */
+ { 0xcb, 0xf0 },/* Reserved... */
+ { 0xcc, 0xd8 },/* Reserved... */
+ { 0xcd, 0x93 },/* Reserved... */
+ { REG_COM7, OV9655_COM7_VGA | OV9655_COM7_RGB },
+ { REG_COM15, COM15_RGB565 },
+ { REG_NULL, 0}
+};
+
+static const struct i2c_rv ov9655_qvga_regs[] = {
+ { REG_HREF, 0x12 },
+ { OV9655_REG_COM14, OV9655_COM14_ZOOM },
+ { OV9655_REG_POIDX, 0x11 },
+ { OV9655_REG_PCKDV, 0x01 },
+ { OV9655_REG_COM24, 0x81 },
+ { REG_NULL, 0}
+};
+
+static const struct i2c_rv ov9655_qqvga_regs[] = {
+ { REG_HREF, 0xa4 },
+ { REG_COM14, OV9655_COM14_BLACK_PIX | OV9655_COM14_WHITE_PIX |
+ OV9655_COM14_ZOOM },
+ { OV9655_REG_POIDX, 0x22 },
+ { OV9655_REG_PCKDV, 0x02 },
+ { OV9655_REG_COM24, 0x82 },
+ { REG_NULL, 0}
+};
+
+static const struct i2c_rv ov9655_vga_regs[] = {
+ { REG_GAIN, 0x11 },
+ { REG_VREF, 0x12 },
+ { REG_B_AVE, 0x2e },
+ { REG_GB_AVE, 0x2e },
+ { REG_GR_AVE, 0x2e },
+ { REG_R_AVE, 0x2e },
+ { REG_COM6, 0x48 },
+ { REG_AECH, 0x7b },
+ { REG_CLKRC, 0x03 },
+ { REG_COM8, COM8_FASTAEC | COM8_AECSTEP | COM8_BFILT |
+ COM8_AGC | COM8_AWB | COM8_AEC },
+ { REG_HSTART, 0x16 },
+ { REG_HSTOP, 0x02 },
+ { REG_VSTART, 0x01 },
+ { REG_VSTOP, 0x3d },
+ { REG_MVFP, 0x04 },
+ { REG_YAVE, 0x2e },
+ { REG_HREF, 0xff },
+ { OV9655_AREF1, 0x3d },
+ { OV9655_AREF3, 0xfa },
+ { REG_TSLB, 0xcc },
+ { REG_COM11, 0xcc },
+ { REG_COM14, 0x0c },
+ { REG_EDGE, 0x82 },
+ { REG_COM15, COM15_R00FF | COM15_RGB565 },/* full range */
+ { REG_COM16, 0x40 },
+ { OV9655_REG_RSVD(1), 0x14 },
+ { OV9655_REG_RSVD(2), 0xf0 },
+ { OV9655_REG_RSVD(3), 0x46 },
+ { OV9655_REG_RSVD(4), 0x62 },
+ { OV9655_REG_RSVD(5), 0x2a },
+ { OV9655_REG_RSVD(6), 0x3c },
+ { OV9655_REG_RSVD(8), 0xe9 },
+ { OV9655_REG_RSVD(9), 0xdd },
+ { OV9655_REG_RSVD(10), 0xdd },
+ { OV9655_REG_RSVD(11), 0xdd },
+ { OV9655_REG_RSVD(12), 0xdd },
+ { REG_LCC(1), 0x00 },
+ { REG_LCC(2), 0x00 },
+ { REG_LCC(3), 0x02 },
+ { REG_LCC(4), 0x20 },
+ { REG_LCC(5), 0x01 },
+ { REG_GSP, 0x0c },
+ { 0x6f, 0x9e },/* Reserved... */
+ { OV9655_REG_DNSTH, 0x06 },
+ { OV9655_REG_POIDX, 0x00 },
+ { OV9655_REG_PCKDV, 0x00 },
+ { OV9655_REG_XINDX, 0x3a },
+ { OV9655_REG_YINDX, 0x35 },
+ { OV9655_REG_SLOP, 0x20 },
+ { OV9655_REG_GAM(1), 0x1c },
+ { OV9655_REG_GAM(2), 0x28 },
+ { OV9655_REG_GAM(3), 0x3c },
+ { OV9655_REG_GAM(4), 0x5a },
+ { OV9655_REG_GAM(5), 0x68 },
+ { OV9655_REG_GAM(6), 0x76 },
+ { OV9655_REG_GAM(7), 0x80 },
+ { OV9655_REG_GAM(8), 0x88 },
+ { OV9655_REG_GAM(9), 0x8f },
+ { OV9655_REG_GAM(10), 0x96 },
+ { OV9655_REG_GAM(11), 0xa3 },
+ { OV9655_REG_GAM(12), 0xaf },
+ { OV9655_REG_GAM(13), 0xc4 },
+ { OV9655_REG_GAM(14), 0xd7 },
+ { OV9655_REG_GAM(15), 0xe8 },
+ { 0x8a, 0x23 },/* Reserved... */
+ { OV9655_REG_COM19, 0x8d },
+ { 0x90, 0x92 },/* Reserved... */
+ { 0x91, 0x92 },/* Reserved... */
+ { REG_DBLC_GB, 0x90 },
+ { REG_DBLC_GR, 0x90 },
+ { OV9655_REG_AWB_GREEN, 0x40 },
+ { OV9655_REG_ADBOFF, 0x02 },
+ { OV9655_REG_ADROFF, 0x01 },
+ { OV9655_REG_ADGBOFF, 0x02 },
+ { OV9655_REG_ADGEOFF, 0x01 },
+ { 0xc1, 0xc8 },/* Reserved... */
+ { 0xc6, 0x85 },/* Reserved... */
+ { OV9655_REG_COM24, 0x80 },
+ { REG_NULL, 0}
+};
+
+static const struct ov965x_framesize ov9655_framesizes[] = {
+ {
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
+ .regs = ov9655_vga_regs,
+ .max_exp_lines = 498,
+ }, {
+ .width = QVGA_WIDTH,
+ .height = QVGA_HEIGHT,
+ .regs = ov9655_qvga_regs,
+ .max_exp_lines = 248,
+ },
+ {
+ .width = QQVGA_WIDTH,
+ .height = QQVGA_HEIGHT,
+ .regs = ov9655_qqvga_regs,
+ .max_exp_lines = 124,
+ },
+};
+
+static const struct ov965x_pixfmt ov9655_formats[] = {
+ { MEDIA_BUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB, 0x08},
+};
+
static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
{
return &container_of(ctrl->handler, struct ov965x, ctrls.handler)->sd;
@@ -894,12 +1272,16 @@ static int ov965x_set_test_pattern(struct ov965x *ov965x, int value)
{
int ret;
u8 reg;
+ u8 addr = (ov965x->id == OV9655V5_ID) ?
+ REG_COM3 : REG_COM23;
+ u8 mask = (ov965x->id == OV9655V5_ID) ?
+ COM3_COLORBAR : COM23_TEST_MODE;

- ret = ov965x_read(ov965x->client, REG_COM23, &reg);
+ ret = ov965x_read(ov965x->client, addr, &reg);
if (ret < 0)
return ret;
- reg = value ? reg | COM23_TEST_MODE : reg & ~COM23_TEST_MODE;
- return ov965x_write(ov965x->client, REG_COM23, reg);
+ reg = value ? reg | mask : reg & ~mask;
+ return ov965x_write(ov965x->client, addr, reg);
}

static int __g_volatile_ctrl(struct ov965x *ov965x, struct v4l2_ctrl *ctrl)
@@ -1102,6 +1484,30 @@ static int ov965x_initialize_controls(struct ov965x *ov965x)
return 0;
}

+static int ov9655_initialize_controls(struct ov965x *ov965x)
+{
+ const struct v4l2_ctrl_ops *ops = &ov965x_ctrl_ops;
+ struct ov965x_ctrls *ctrls = &ov965x->ctrls;
+ struct v4l2_ctrl_handler *hdl = &ctrls->handler;
+ int ret;
+
+ ret = v4l2_ctrl_handler_init(hdl, 16);
+ if (ret < 0)
+ return ret;
+
+ v4l2_ctrl_new_std_menu_items(hdl, ops, V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(test_pattern_menu) - 1, 0, 0,
+ test_pattern_menu);
+ if (hdl->error) {
+ ret = hdl->error;
+ v4l2_ctrl_handler_free(hdl);
+ return ret;
+ }
+
+ ov965x->sd.ctrl_handler = hdl;
+ return 0;
+}
+
/*
* V4L2 subdev video and pad level operations
*/
@@ -1518,9 +1924,15 @@ static int ov965x_detect_sensor(struct v4l2_subdev *sd)

if (!ret) {
ov965x->id = OV965X_ID(pid, ver);
- if (ov965x->id == OV9650_ID || ov965x->id == OV9652_ID) {
+ switch (ov965x->id) {
+ case OV9650_ID:
+ case OV9652_ID:
v4l2_info(sd, "Found OV%04X sensor\n", ov965x->id);
- } else {
+ break;
+ case OV9655V5_ID:
+ v4l2_info(sd, "Found OV%04X sensor\n", ov965x->id - 2);
+ break;
+ default:
v4l2_err(sd, "Sensor detection failed (%04X, %d)\n",
ov965x->id, ret);
ret = -ENODEV;
@@ -1598,18 +2010,28 @@ static int ov965x_probe(struct i2c_client *client,
if (ret < 0)
goto err_me;

- ov965x->init_regs = ov965x_init_regs;
- ov965x->initialize_controls = ov965x_initialize_controls;
- ov965x->framesizes = ov965x_framesizes;
- ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
- ov965x->formats = ov965x_formats;
- ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
- ov965x->intervals = ov965x_intervals;
- ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
- ov965x->fiv = &ov965x_intervals[0];
- ov965x->set_frame_interval = __ov965x_set_frame_interval;
- ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
- ov965x->set_params = __ov965x_set_params;
+ if (ov965x->id != OV9655V5_ID) {
+ ov965x->init_regs = ov965x_init_regs;
+ ov965x->initialize_controls = ov965x_initialize_controls;
+ ov965x->framesizes = ov965x_framesizes;
+ ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
+ ov965x->formats = ov965x_formats;
+ ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
+ ov965x->intervals = ov965x_intervals;
+ ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
+ ov965x->fiv = &ov965x_intervals[0];
+ ov965x->set_frame_interval = __ov965x_set_frame_interval;
+ ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
+ ov965x->set_params = __ov965x_set_params;
+ } else {
+ ov965x->init_regs = ov9655_init_regs;
+ ov965x->initialize_controls = ov9655_initialize_controls;
+ ov965x->framesizes = ov9655_framesizes;
+ ov965x->nb_of_framesizes = ARRAY_SIZE(ov9655_framesizes);
+ ov965x->formats = ov9655_formats;
+ ov965x->nb_of_formats = ARRAY_SIZE(ov9655_formats);
+ ov965x->set_params = ov965x_set_frame_size;
+ };

ov965x->frame_size = &ov965x->framesizes[0];
ov965x_get_default_format(ov965x, &ov965x->format);
@@ -1652,6 +2074,7 @@ static int ov965x_remove(struct i2c_client *client)
static const struct i2c_device_id ov965x_id[] = {
{ "OV9650", 0x9650 },
{ "OV9652", 0x9652 },
+ { "OV9655", 0x9655 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, ov965x_id);
@@ -1659,6 +2082,7 @@ static int ov965x_remove(struct i2c_client *client)
static const struct of_device_id ov965x_of_match[] = {
{ .compatible = "ovti,ov9650", .data = (void *)0x9650 },
{ .compatible = "ovti,ov9652", .data = (void *)0x9652 },
+ { .compatible = "ovti,ov9655", .data = (void *)0x9655 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, ov965x_of_match);
--
1.9.1

2017-06-22 15:08:16

by Hugues Fruchet

[permalink] [raw]
Subject: [PATCH v1 2/6] [media] ov9650: add device tree support

Allows use of device tree configuration data.
If no device tree data is there, configuration is taken from platform data.
In order to keep GPIOs configuration compatible between both way of doing,
GPIOs are switched to descriptor-based interface.

Signed-off-by: H. Nikolaus Schaller <[email protected]>
Signed-off-by: Hugues Fruchet <[email protected]>
---
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/ov9650.c | 81 ++++++++++++++++++++++++++++++++++------------
2 files changed, 61 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c380e24..efea14d 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -595,7 +595,7 @@ config VIDEO_OV7670

config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
- depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
---help---
This is a V4L2 sensor-level driver for the Omnivision
OV9650 and OV9652 camera sensors.
diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 2de2fbb..8340a45 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -11,12 +11,14 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/kernel.h>
#include <linux/media.h>
#include <linux/module.h>
+#include <linux/of_gpio.h>
#include <linux/ratelimit.h>
#include <linux/slab.h>
#include <linux/string.h>
@@ -249,9 +251,10 @@ struct ov965x {
struct v4l2_subdev sd;
struct media_pad pad;
enum v4l2_mbus_type bus_type;
- int gpios[NUM_GPIOS];
+ struct gpio_desc *gpios[NUM_GPIOS];
/* External master clock frequency */
unsigned long mclk_frequency;
+ struct clk *clk;

/* Protects the struct fields below */
struct mutex lock;
@@ -511,10 +514,10 @@ static int ov965x_set_color_matrix(struct ov965x *ov965x)
return 0;
}

-static void ov965x_gpio_set(int gpio, int val)
+static void ov965x_gpio_set(struct gpio_desc *gpio, int val)
{
- if (gpio_is_valid(gpio))
- gpio_set_value(gpio, val);
+ if (gpio)
+ gpiod_set_value_cansleep(gpio, val);
}

static void __ov965x_set_power(struct ov965x *ov965x, int on)
@@ -1406,24 +1409,28 @@ static int ov965x_configure_gpios(struct ov965x *ov965x,
const struct ov9650_platform_data *pdata)
{
int ret, i;
+ int gpios[NUM_GPIOS];

- ov965x->gpios[GPIO_PWDN] = pdata->gpio_pwdn;
- ov965x->gpios[GPIO_RST] = pdata->gpio_reset;
+ gpios[GPIO_PWDN] = pdata->gpio_pwdn;
+ gpios[GPIO_RST] = pdata->gpio_reset;

- for (i = 0; i < ARRAY_SIZE(ov965x->gpios); i++) {
- int gpio = ov965x->gpios[i];
+ for (i = 0; i < ARRAY_SIZE(gpios); i++) {
+ int gpio = gpios[i];

if (!gpio_is_valid(gpio))
continue;
ret = devm_gpio_request_one(&ov965x->client->dev, gpio,
- GPIOF_OUT_INIT_HIGH, "OV965X");
- if (ret < 0)
+ GPIOF_OUT_INIT_HIGH, DRIVER_NAME);
+ if (ret < 0) {
+ dev_err(&ov965x->client->dev,
+ "Failed to request gpio%d (%d)\n", gpio, ret);
return ret;
+ }
v4l2_dbg(1, debug, &ov965x->sd, "set gpio %d to 1\n", gpio);

gpio_set_value(gpio, 1);
gpio_export(gpio, 0);
- ov965x->gpios[i] = gpio;
+ ov965x->gpios[i] = gpio_to_desc(gpio);
}

return 0;
@@ -1469,14 +1476,10 @@ static int ov965x_probe(struct i2c_client *client,
struct v4l2_subdev *sd;
struct ov965x *ov965x;
int ret;
+ struct device_node *np = client->dev.of_node;

- if (pdata == NULL) {
- dev_err(&client->dev, "platform data not specified\n");
- return -EINVAL;
- }
-
- if (pdata->mclk_frequency == 0) {
- dev_err(&client->dev, "MCLK frequency not specified\n");
+ if (!pdata && !np) {
+ dev_err(&client->dev, "Platform data or device tree data must be provided\n");
return -EINVAL;
}

@@ -1486,7 +1489,36 @@ static int ov965x_probe(struct i2c_client *client,

mutex_init(&ov965x->lock);
ov965x->client = client;
- ov965x->mclk_frequency = pdata->mclk_frequency;
+ mutex_init(&ov965x->lock);
+
+ if (np) {
+ /* Device tree */
+ ov965x->gpios[GPIO_RST] =
+ devm_gpiod_get_optional(&client->dev, "resetb",
+ GPIOD_OUT_LOW);
+ ov965x->gpios[GPIO_PWDN] =
+ devm_gpiod_get_optional(&client->dev, "pwdn",
+ GPIOD_OUT_HIGH);
+
+ ov965x->clk = devm_clk_get(&client->dev, NULL);
+ if (IS_ERR(ov965x->clk)) {
+ dev_err(&client->dev, "Could not get clock\n");
+ return PTR_ERR(ov965x->clk);
+ }
+ ov965x->mclk_frequency = clk_get_rate(ov965x->clk);
+ } else {
+ /* Platform data */
+ ret = ov965x_configure_gpios(ov965x, pdata);
+ if (ret < 0)
+ return ret;
+
+ if (pdata->mclk_frequency == 0) {
+ dev_err(&client->dev, "MCLK frequency is mandatory\n");
+ return -EINVAL;
+ }
+ ov965x->mclk_frequency = pdata->mclk_frequency;
+ }
+

sd = &ov965x->sd;
v4l2_i2c_subdev_init(sd, client, &ov965x_subdev_ops);
@@ -1545,15 +1577,22 @@ static int ov965x_remove(struct i2c_client *client)
}

static const struct i2c_device_id ov965x_id[] = {
- { "OV9650", 0 },
- { "OV9652", 0 },
+ { "OV9650", 0x9650 },
+ { "OV9652", 0x9652 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, ov965x_id);

+static const struct of_device_id ov965x_of_match[] = {
+ { .compatible = "ovti,ov9650", .data = (void *)0x9650 },
+ { .compatible = "ovti,ov9652", .data = (void *)0x9652 },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ov965x_of_match);
static struct i2c_driver ov965x_i2c_driver = {
.driver = {
.name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(ov965x_of_match),
},
.probe = ov965x_probe,
.remove = ov965x_remove,
--
1.9.1

2017-06-22 15:08:14

by Hugues Fruchet

[permalink] [raw]
Subject: [PATCH v1 5/6] [media] ov9650: add multiple variant support

Ops support and registers set can now be different
from a variant to another.

Signed-off-by: Hugues Fruchet <[email protected]>
---
drivers/media/i2c/ov9650.c | 141 +++++++++++++++++++++++++++++----------------
1 file changed, 91 insertions(+), 50 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 8b283c9..a9d268d 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -38,7 +38,7 @@
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level (0-2)");

-#define DRIVER_NAME "OV9650"
+#define DRIVER_NAME "ov965x"

/*
* OV9650/OV9652 register definitions
@@ -257,6 +257,21 @@ struct ov965x {
struct media_pad pad;
enum v4l2_mbus_type bus_type;
struct gpio_desc *gpios[NUM_GPIOS];
+
+ /* Variant specific regs and ops */
+ const struct i2c_rv *init_regs;
+ const struct ov965x_framesize *framesizes;
+ unsigned int nb_of_framesizes;
+ const struct ov965x_pixfmt *formats;
+ unsigned int nb_of_formats;
+ const struct ov965x_interval *intervals;
+ unsigned int nb_of_intervals;
+ int (*initialize_controls)(struct ov965x *ov965x);
+ int (*set_frame_interval)(struct ov965x *ov965x,
+ struct v4l2_subdev_frame_interval *fi);
+ void (*update_exposure_ctrl)(struct ov965x *ov965x);
+ int (*set_params)(struct ov965x *ov965x);
+
/* External master clock frequency */
unsigned long mclk_frequency;
struct clk *clk;
@@ -576,7 +591,7 @@ static int ov965x_s_power(struct v4l2_subdev *sd, int on)
__ov965x_set_power(ov965x, on);
if (on) {
ret = ov965x_write_array(client,
- ov965x_init_regs);
+ ov965x->init_regs);
ov965x->apply_frame_fmt = 1;
ov965x->ctrls.update = 1;
}
@@ -1090,12 +1105,13 @@ static int ov965x_initialize_controls(struct ov965x *ov965x)
/*
* V4L2 subdev video and pad level operations
*/
-static void ov965x_get_default_format(struct v4l2_mbus_framefmt *mf)
+static void ov965x_get_default_format(struct ov965x *ov965x,
+ struct v4l2_mbus_framefmt *mf)
{
- mf->width = ov965x_framesizes[0].width;
- mf->height = ov965x_framesizes[0].height;
- mf->colorspace = ov965x_formats[0].colorspace;
- mf->code = ov965x_formats[0].code;
+ mf->width = ov965x->framesizes[0].width;
+ mf->height = ov965x->framesizes[0].height;
+ mf->colorspace = ov965x->formats[0].colorspace;
+ mf->code = ov965x->formats[0].code;
mf->field = V4L2_FIELD_NONE;
}

@@ -1103,10 +1119,12 @@ static int ov965x_enum_mbus_code(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code)
{
- if (code->index >= ARRAY_SIZE(ov965x_formats))
+ struct ov965x *ov965x = to_ov965x(sd);
+
+ if (code->index >= ov965x->nb_of_formats)
return -EINVAL;

- code->code = ov965x_formats[code->index].code;
+ code->code = ov965x->formats[code->index].code;
return 0;
}

@@ -1114,22 +1132,22 @@ static int ov965x_enum_frame_sizes(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_frame_size_enum *fse)
{
- int i = ARRAY_SIZE(ov965x_formats);
+ struct ov965x *ov965x = to_ov965x(sd);
+ int i = ov965x->nb_of_formats;

- if (fse->index >= ARRAY_SIZE(ov965x_framesizes))
+ if (fse->index >= ov965x->nb_of_framesizes)
return -EINVAL;

while (--i)
- if (fse->code == ov965x_formats[i].code)
+ if (fse->code == ov965x->formats[i].code)
break;

- fse->code = ov965x_formats[i].code;
+ fse->code = ov965x->formats[i].code;

- fse->min_width = ov965x_framesizes[fse->index].width;
+ fse->min_width = ov965x->framesizes[fse->index].width;
fse->max_width = fse->min_width;
- fse->max_height = ov965x_framesizes[fse->index].height;
+ fse->max_height = ov965x->framesizes[fse->index].height;
fse->min_height = fse->max_height;
-
return 0;
}

@@ -1138,6 +1156,9 @@ static int ov965x_g_frame_interval(struct v4l2_subdev *sd,
{
struct ov965x *ov965x = to_ov965x(sd);

+ if (!ov965x->fiv)
+ return 0;
+
mutex_lock(&ov965x->lock);
fi->interval = ov965x->fiv->interval;
mutex_unlock(&ov965x->lock);
@@ -1146,13 +1167,15 @@ static int ov965x_g_frame_interval(struct v4l2_subdev *sd,
}

static int __ov965x_set_frame_interval(struct ov965x *ov965x,
- struct v4l2_subdev_frame_interval *fi)
+ struct v4l2_subdev_frame_interval *fi)
{
struct v4l2_mbus_framefmt *mbus_fmt = &ov965x->format;
- const struct ov965x_interval *fiv = &ov965x_intervals[0];
+ const struct ov965x_interval *fiv = ov965x->intervals;
u64 req_int, err, min_err = ~0ULL;
unsigned int i;

+ if (!fiv)
+ return 0;

if (fi->interval.denominator == 0)
return -EINVAL;
@@ -1160,8 +1183,8 @@ static int __ov965x_set_frame_interval(struct ov965x *ov965x,
req_int = (u64)(fi->interval.numerator * 10000) /
fi->interval.denominator;

- for (i = 0; i < ARRAY_SIZE(ov965x_intervals); i++) {
- const struct ov965x_interval *iv = &ov965x_intervals[i];
+ for (i = 0; i < ov965x->nb_of_intervals; i++) {
+ const struct ov965x_interval *iv = ov965x->intervals;

if (mbus_fmt->width != iv->size.width ||
mbus_fmt->height != iv->size.height)
@@ -1185,13 +1208,15 @@ static int ov965x_s_frame_interval(struct v4l2_subdev *sd,
struct v4l2_subdev_frame_interval *fi)
{
struct ov965x *ov965x = to_ov965x(sd);
- int ret;
+ int ret = 0;

v4l2_dbg(1, debug, sd, "Setting %d/%d frame interval\n",
fi->interval.numerator, fi->interval.denominator);

mutex_lock(&ov965x->lock);
- ret = __ov965x_set_frame_interval(ov965x, fi);
+ if (ov965x->set_frame_interval)
+ ret = ov965x->set_frame_interval(ov965x, fi);
+
ov965x->apply_frame_fmt = 1;
mutex_unlock(&ov965x->lock);
return ret;
@@ -1216,12 +1241,13 @@ static int ov965x_get_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
return 0;
}

-static void __ov965x_try_frame_size(struct v4l2_mbus_framefmt *mf,
+static void __ov965x_try_frame_size(struct ov965x *ov965x,
+ struct v4l2_mbus_framefmt *mf,
const struct ov965x_framesize **size)
{
- const struct ov965x_framesize *fsize = &ov965x_framesizes[0],
+ const struct ov965x_framesize *fsize = &ov965x->framesizes[0],
*match = NULL;
- int i = ARRAY_SIZE(ov965x_framesizes);
+ int i = ov965x->nb_of_framesizes;
unsigned int min_err = UINT_MAX;

while (i--) {
@@ -1236,7 +1262,7 @@ static void __ov965x_try_frame_size(struct v4l2_mbus_framefmt *mf,
fsize++;
}
if (!match)
- match = &ov965x_framesizes[0];
+ match = &ov965x->framesizes[0];
mf->width = match->width;
mf->height = match->height;
if (size)
@@ -1246,20 +1272,20 @@ static void __ov965x_try_frame_size(struct v4l2_mbus_framefmt *mf,
static int ov965x_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *fmt)
{
- unsigned int index = ARRAY_SIZE(ov965x_formats);
- struct v4l2_mbus_framefmt *mf = &fmt->format;
struct ov965x *ov965x = to_ov965x(sd);
+ unsigned int index = ov965x->nb_of_formats;
+ struct v4l2_mbus_framefmt *mf = &fmt->format;
const struct ov965x_framesize *size = NULL;
int ret = 0;

- __ov965x_try_frame_size(mf, &size);
+ __ov965x_try_frame_size(ov965x, mf, &size);

while (--index)
- if (ov965x_formats[index].code == mf->code)
+ if (ov965x->formats[index].code == mf->code)
break;

mf->colorspace = V4L2_COLORSPACE_JPEG;
- mf->code = ov965x_formats[index].code;
+ mf->code = ov965x->formats[index].code;
mf->field = V4L2_FIELD_NONE;

mutex_lock(&ov965x->lock);
@@ -1275,7 +1301,7 @@ static int ov965x_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
} else {
ov965x->frame_size = size;
ov965x->format = fmt->format;
- ov965x->tslb_reg = ov965x_formats[index].tslb_reg;
+ ov965x->tslb_reg = ov965x->formats[index].tslb_reg;
ov965x->apply_frame_fmt = 1;
}
}
@@ -1285,12 +1311,14 @@ static int ov965x_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
.interval = { 0, 1 }
};
/* Reset to minimum possible frame interval */
- __ov965x_set_frame_interval(ov965x, &fiv);
+ if (ov965x->set_frame_interval)
+ ret = ov965x->set_frame_interval(ov965x, &fiv);
}
mutex_unlock(&ov965x->lock);

if (!ret)
- ov965x_update_exposure_ctrl(ov965x);
+ if (ov965x->update_exposure_ctrl)
+ ov965x->update_exposure_ctrl(ov965x);

return ret;
}
@@ -1365,7 +1393,8 @@ static int ov965x_s_stream(struct v4l2_subdev *sd, int on)
mutex_lock(&ov965x->lock);
if (ov965x->streaming == !on) {
if (on)
- ret = __ov965x_set_params(ov965x);
+ if (ov965x->set_params)
+ ret = ov965x->set_params(ov965x);

if (!ret && ctrls->update) {
/*
@@ -1398,8 +1427,9 @@ static int ov965x_s_stream(struct v4l2_subdev *sd, int on)
static int ov965x_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
{
struct v4l2_mbus_framefmt *mf = v4l2_subdev_get_try_format(sd, fh->pad, 0);
+ struct ov965x *ov965x = to_ov965x(sd);

- ov965x_get_default_format(mf);
+ ov965x_get_default_format(ov965x, mf);
return 0;
}

@@ -1518,8 +1548,6 @@ static int ov965x_probe(struct i2c_client *client,
ov965x = devm_kzalloc(&client->dev, sizeof(*ov965x), GFP_KERNEL);
if (!ov965x)
return -ENOMEM;
-
- mutex_init(&ov965x->lock);
ov965x->client = client;
mutex_init(&ov965x->lock);

@@ -1560,38 +1588,51 @@ static int ov965x_probe(struct i2c_client *client,
sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE |
V4L2_SUBDEV_FL_HAS_EVENTS;

- ret = ov965x_configure_gpios(ov965x, pdata);
- if (ret < 0)
- return ret;
-
ov965x->pad.flags = MEDIA_PAD_FL_SOURCE;
sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
ret = media_entity_pads_init(&sd->entity, 1, &ov965x->pad);
if (ret < 0)
return ret;

- ret = ov965x_initialize_controls(ov965x);
+ ret = ov965x_detect_sensor(sd);
if (ret < 0)
goto err_me;

- ov965x_get_default_format(&ov965x->format);
- ov965x->frame_size = &ov965x_framesizes[0];
+ ov965x->init_regs = ov965x_init_regs;
+ ov965x->initialize_controls = ov965x_initialize_controls;
+ ov965x->framesizes = ov965x_framesizes;
+ ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
+ ov965x->formats = ov965x_formats;
+ ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
+ ov965x->intervals = ov965x_intervals;
+ ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
ov965x->fiv = &ov965x_intervals[0];
+ ov965x->set_frame_interval = __ov965x_set_frame_interval;
+ ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
+ ov965x->set_params = __ov965x_set_params;

- ret = ov965x_detect_sensor(sd);
- if (ret < 0)
- goto err_ctrls;
+ ov965x->frame_size = &ov965x->framesizes[0];
+ ov965x_get_default_format(ov965x, &ov965x->format);
+
+ if (ov965x->initialize_controls)
+ ret = ov965x->initialize_controls(ov965x);
+ if (ret < 0)
+ goto err_ctrls;

/* Update exposure time min/max to match frame format */
- ov965x_update_exposure_ctrl(ov965x);
+ if (ov965x->update_exposure_ctrl)
+ ov965x->update_exposure_ctrl(ov965x);

ret = v4l2_async_register_subdev(sd);
if (ret < 0)
goto err_ctrls;

+ dev_info(&client->dev, "%s driver probed\n", sd->name);
return 0;
+
err_ctrls:
- v4l2_ctrl_handler_free(sd->ctrl_handler);
+ if (sd->ctrl_handler)
+ v4l2_ctrl_handler_free(sd->ctrl_handler);
err_me:
media_entity_cleanup(&sd->entity);
return ret;
--
1.9.1

2017-06-22 15:42:02

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera


> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>
> This patchset enables OV9655 camera support.
>
> OV9655 support has been tested using STM32F4DIS-CAM extension board
> plugged on connector P1 of STM32F746G-DISCO board.
> Due to lack of OV9650/52 hardware support, the modified related code
> could not have been checked for non-regression.
>
> First patches upgrade current support of OV9650/52 to prepare then
> introduction of OV9655 variant patch.
> Because of OV9655 register set slightly different from OV9650/9652,
> not all of the driver features are supported (controls). Supported
> resolutions are limited to VGA, QVGA, QQVGA.
> Supported format is limited to RGB565.
> Controls are limited to color bar test pattern for test purpose.
>
> OV9655 initial support is based on a driver written by H. Nikolaus Schaller [1].

Great!

I will test as soon as possible.

> OV9655 registers sequences come from STM32CubeF7 embedded software [2].

There is also a preliminary data sheet, e.g. here:

http://electricstuff.co.uk/OV9655-datasheet-annotated.pdf

>
> [1] http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
> [2] https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
>
> ===========
> = history =
> ===========
> version 1:
> - Initial submission.
>
> H. Nikolaus Schaller (1):
> DT bindings: add bindings for ov965x camera module
>
> Hugues Fruchet (5):
> [media] ov9650: add device tree support
> [media] ov9650: select the nearest higher resolution
> [media] ov9650: use write_array() for resolution sequences
> [media] ov9650: add multiple variant support
> [media] ov9650: add support of OV9655 variant
>
> .../devicetree/bindings/media/i2c/ov965x.txt | 37 +
> drivers/media/i2c/Kconfig | 6 +-
> drivers/media/i2c/ov9650.c | 792 +++++++++++++++++----
> 3 files changed, 704 insertions(+), 131 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>
> --
> 1.9.1
>

BR and thanks,
Nikolaus Schaller


2017-06-23 10:25:55

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Hugues,

> Am 22.06.2017 um 17:41 schrieb H. Nikolaus Schaller <[email protected]>:
>
>
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>>
>> This patchset enables OV9655 camera support.
>>
>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>> plugged on connector P1 of STM32F746G-DISCO board.
>> Due to lack of OV9650/52 hardware support, the modified related code
>> could not have been checked for non-regression.
>>
>> First patches upgrade current support of OV9650/52 to prepare then
>> introduction of OV9655 variant patch.
>> Because of OV9655 register set slightly different from OV9650/9652,
>> not all of the driver features are supported (controls). Supported
>> resolutions are limited to VGA, QVGA, QQVGA.
>> Supported format is limited to RGB565.
>> Controls are limited to color bar test pattern for test purpose.
>>
>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller [1].
>
> Great!

Thanks again for picking up or work and trying to get it upstream.

>
> I will test as soon as possible.

I have tried and had to fix some issues first:
* gpio properties have a different name than in our approach (but that is something maintainers have to decide and is easy to follow this or that way)
* there is no clock-frequency property which makes the driver request a clock frequency (something our camera interface expects this way)
* there is no vana-supply regulator and we need that to power on/off the camera on demand (reset and pwdn isn't enough in our hardware)
* for some unknown reason the driver does not load automatically from DT compatibility string and needs to be explicitly modprobed
* unfortunately we still get no image :(

The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which
we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and
sync are correct. But we do not know since mplayer only shows a green screen.

Therefore we had not submitted anything upstream ourselves, because our driver setup
isn't finished and completely working.

I have written some more specific comments linked to proposals for patches as answer to your [PATCH v1 1/6]

BR and thanks,
Nikolaus

2017-06-23 10:26:22

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Hi Hugues,

> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>
> From: "H. Nikolaus Schaller" <[email protected]>
>
> This adds documentation of device tree bindings
> for the OV965X family camera sensor module.
>
> Signed-off-by: H. Nikolaus Schaller <[email protected]>
> Signed-off-by: Hugues Fruchet <[email protected]>
> ---
> .../devicetree/bindings/media/i2c/ov965x.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> new file mode 100644
> index 0000000..0e0de1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> @@ -0,0 +1,37 @@
> +* Omnivision OV9650/9652/9655 CMOS sensor
> +
> +The Omnivision OV965x sensor support multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> +output format.
> +
> +Required Properties:
> +- compatible: should be one of
> + "ovti,ov9650"
> + "ovti,ov9652"
> + "ovti,ov9655"
> +- clocks: reference to the mclk input clock.

I wonder why you have removed the clock-frequency property?

In some situations the camera driver must be able to tell the clock source
which frequency it wants to see.

For example we connect the camera to an OMAP3-ISP (image signal processor) and
there it is assumed that camera modules know the frequency and set the clock, e.g.:

http://elixir.free-electrons.com/linux/v4.4/source/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt#L52
http://elixir.free-electrons.com/linux/v3.14/source/Documentation/devicetree/bindings/media/i2c/mt9p031.txt

If your clock is constant and defined elsewhere we should make this
property optional instead of required. But it should not be missing.

Here is a hack to get it into your code:

http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=b7ab46c775b9e40087e427ae0777e9f7c283694a;hp=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hb=ca85196f6fd9a77e5a0f796aeaf7aa2cde60ce91;hpb=8a71f21b75543a6d99102be1ae4677b28c478ac9

> +
> +Optional Properties:
> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.

Here I wonder why you did split that up into two gpios. Each "*-gpios" can have
multiple entries and if one is not used, a 0 can be specified to make it being ignored.

But it is up to DT maintainers what they prefer: separate single gpios or a single gpio array.


What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
So the driver does not power up the camera module when needed and therefore probing fails.

- vana-supply: a regulator to power up the camera module.

Driver code is not complex to add:

http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hp=c0819afdcefcb19da351741d51dad00aaf909254;hb=8a71f21b75543a6d99102be1ae4677b28c478ac9;hpb=6db55fc472eea2ec6db03833df027aecf6649f88

> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> +&i2c2 {
> + ov9655: camera@30 {
> + compatible = "ovti,ov9655";
> + reg = <0x30>;
> + pwdn-gpios = <&gpioh 13 GPIO_ACTIVE_HIGH>;
> + clocks = <&clk_ext_camera>;
> +
> + port {
> + ov9655: endpoint {
> + remote-endpoint = <&dcmi_0>;
> + };
> + };
> + };
> +};
> --
> 1.9.1
>

BR and thanks,
Nikolaus


2017-06-23 10:46:15

by Andreas Färber

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Hi,

Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> new file mode 100644
>> index 0000000..0e0de1f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> @@ -0,0 +1,37 @@
>> +* Omnivision OV9650/9652/9655 CMOS sensor
>> +
>> +The Omnivision OV965x sensor support multiple resolutions output, such as
>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>> +output format.
>> +
>> +Required Properties:
>> +- compatible: should be one of
>> + "ovti,ov9650"
>> + "ovti,ov9652"
>> + "ovti,ov9655"
>> +- clocks: reference to the mclk input clock.
>
> I wonder why you have removed the clock-frequency property?
>
> In some situations the camera driver must be able to tell the clock source
> which frequency it wants to see.

That's what assigned-clock-rates property is for:

https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-bindings.txt

AFAIU clock-frequency on devices is deprecated and equivalent to having
a clocks property pointing to a fixed-clock, which is different from a
clock with varying rate.

Regards,
Andreas

--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

2017-06-23 11:00:10

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module


> Am 23.06.2017 um 12:46 schrieb Andreas Färber <[email protected]>:
>
> Hi,
>
> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>> new file mode 100644
>>> index 0000000..0e0de1f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>> @@ -0,0 +1,37 @@
>>> +* Omnivision OV9650/9652/9655 CMOS sensor
>>> +
>>> +The Omnivision OV965x sensor support multiple resolutions output, such as
>>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>>> +output format.
>>> +
>>> +Required Properties:
>>> +- compatible: should be one of
>>> + "ovti,ov9650"
>>> + "ovti,ov9652"
>>> + "ovti,ov9655"
>>> +- clocks: reference to the mclk input clock.
>>
>> I wonder why you have removed the clock-frequency property?
>>
>> In some situations the camera driver must be able to tell the clock source
>> which frequency it wants to see.
>
> That's what assigned-clock-rates property is for:
>
> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-bindings.txt
>
> AFAIU clock-frequency on devices is deprecated and equivalent to having
> a clocks property pointing to a fixed-clock, which is different from a
> clock with varying rate.

I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock rate
so we can only have the driver define what it wants to see.

And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is that they do it in the driver.

Maybe ISP developers can comment?

BR,
Nikolaus

2017-06-23 11:58:08

by Laurent Pinchart

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Hi Nikolaus,

On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote:
> Am 23.06.2017 um 12:46 schrieb Andreas F?rber <[email protected]>:
> > Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
> >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> >>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode
> >>> 100644
> >>> index 0000000..0e0de1f
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> >>> @@ -0,0 +1,37 @@
> >>> +* Omnivision OV9650/9652/9655 CMOS sensor
> >>> +
> >>> +The Omnivision OV965x sensor support multiple resolutions output, such
> >>> as
> >>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> >>> +output format.
> >>> +
> >>> +Required Properties:
> >>> +- compatible: should be one of
> >>> + "ovti,ov9650"
> >>> + "ovti,ov9652"
> >>> + "ovti,ov9655"
> >>> +- clocks: reference to the mclk input clock.
> >>
> >> I wonder why you have removed the clock-frequency property?
> >>
> >> In some situations the camera driver must be able to tell the clock
> >> source which frequency it wants to see.
> >
> > That's what assigned-clock-rates property is for:
> >
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b
> > indings.txt
> >
> > AFAIU clock-frequency on devices is deprecated and equivalent to having
> > a clocks property pointing to a fixed-clock, which is different from a
> > clock with varying rate.
>
> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock
> rate so we can only have the driver define what it wants to see.
>
> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is
> that they do it in the driver.
>
> Maybe ISP developers can comment?

The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is
controlled by the clock consumer. As such, it's up to the consumer to decide
whether to compute and request the clock rate dynamically at runtime, or use
the assigned-clock-rates property in DT.

Some ISPs include a clock generator, others don't. It should make no
difference whether the clock is provided by the ISP, by a dedicated clock
source in the SoC or by a discrete on-board adjustable clock source.

--
Regards,

Laurent Pinchart


2017-06-23 14:54:29

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Hi Laurent,

> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart <[email protected]>:
>
> Hi Nikolaus,
>
> On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote:
>> Am 23.06.2017 um 12:46 schrieb Andreas F?rber <[email protected]>:
>>> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode
>>>>> 100644
>>>>> index 0000000..0e0de1f
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>> @@ -0,0 +1,37 @@
>>>>> +* Omnivision OV9650/9652/9655 CMOS sensor
>>>>> +
>>>>> +The Omnivision OV965x sensor support multiple resolutions output, such
>>>>> as
>>>>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>>>>> +output format.
>>>>> +
>>>>> +Required Properties:
>>>>> +- compatible: should be one of
>>>>> + "ovti,ov9650"
>>>>> + "ovti,ov9652"
>>>>> + "ovti,ov9655"
>>>>> +- clocks: reference to the mclk input clock.
>>>>
>>>> I wonder why you have removed the clock-frequency property?
>>>>
>>>> In some situations the camera driver must be able to tell the clock
>>>> source which frequency it wants to see.
>>>
>>> That's what assigned-clock-rates property is for:
>>>
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b
>>> indings.txt
>>>
>>> AFAIU clock-frequency on devices is deprecated and equivalent to having
>>> a clocks property pointing to a fixed-clock, which is different from a
>>> clock with varying rate.
>>
>> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock
>> rate so we can only have the driver define what it wants to see.
>>
>> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is
>> that they do it in the driver.
>>
>> Maybe ISP developers can comment?
>
> The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is
> controlled by the clock consumer. As such, it's up to the consumer to decide
> whether to compute and request the clock rate dynamically at runtime, or use
> the assigned-clock-rates property in DT.
>
> Some ISPs include a clock generator, others don't. It should make no
> difference whether the clock is provided by the ISP, by a dedicated clock
> source in the SoC or by a discrete on-board adjustable clock source.

Thanks for explaining the background.

Do you have an hint or example how to use the assigned-clock-rates property in
a DT for a camera module connected to the omap3isp?

Or does it just mean that it defines the property name?

BR,
Nikolaus


2017-06-23 14:57:25

by Andreas Färber

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Am 23.06.2017 um 16:53 schrieb H. Nikolaus Schaller:
> Hi Laurent,
>
>> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart <[email protected]>:
>>
>> Hi Nikolaus,
>>
>> On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote:
>>> Am 23.06.2017 um 12:46 schrieb Andreas Färber <[email protected]>:
>>>> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode
>>>>>> 100644
>>>>>> index 0000000..0e0de1f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +* Omnivision OV9650/9652/9655 CMOS sensor
>>>>>> +
>>>>>> +The Omnivision OV965x sensor support multiple resolutions output, such
>>>>>> as
>>>>>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>>>>>> +output format.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +- compatible: should be one of
>>>>>> + "ovti,ov9650"
>>>>>> + "ovti,ov9652"
>>>>>> + "ovti,ov9655"
>>>>>> +- clocks: reference to the mclk input clock.
>>>>>
>>>>> I wonder why you have removed the clock-frequency property?
>>>>>
>>>>> In some situations the camera driver must be able to tell the clock
>>>>> source which frequency it wants to see.
>>>>
>>>> That's what assigned-clock-rates property is for:
>>>>
>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b
>>>> indings.txt
>>>>
>>>> AFAIU clock-frequency on devices is deprecated and equivalent to having
>>>> a clocks property pointing to a fixed-clock, which is different from a
>>>> clock with varying rate.
>>>
>>> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock
>>> rate so we can only have the driver define what it wants to see.
>>>
>>> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is
>>> that they do it in the driver.
>>>
>>> Maybe ISP developers can comment?
>>
>> The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is
>> controlled by the clock consumer. As such, it's up to the consumer to decide
>> whether to compute and request the clock rate dynamically at runtime, or use
>> the assigned-clock-rates property in DT.
>>
>> Some ISPs include a clock generator, others don't. It should make no
>> difference whether the clock is provided by the ISP, by a dedicated clock
>> source in the SoC or by a discrete on-board adjustable clock source.
>
> Thanks for explaining the background.
>
> Do you have an hint or example how to use the assigned-clock-rates property in
> a DT for a camera module connected to the omap3isp?
>
> Or does it just mean that it defines the property name?

Please read the documentation link I sent - it's in the very bottom and
should have an example.

Regards,
Andreas

--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

2017-06-23 15:23:03

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Hi,

> Am 23.06.2017 um 16:57 schrieb Andreas Färber <[email protected]>:
>
> Am 23.06.2017 um 16:53 schrieb H. Nikolaus Schaller:
>> Hi Laurent,
>>
>>> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart <[email protected]>:
>>>
>>> Hi Nikolaus,
>>>
>>> On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote:
>>>> Am 23.06.2017 um 12:46 schrieb Andreas Färber <[email protected]>:
>>>>> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode
>>>>>>> 100644
>>>>>>> index 0000000..0e0de1f
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>>> @@ -0,0 +1,37 @@
>>>>>>> +* Omnivision OV9650/9652/9655 CMOS sensor
>>>>>>> +
>>>>>>> +The Omnivision OV965x sensor support multiple resolutions output, such
>>>>>>> as
>>>>>>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>>>>>>> +output format.
>>>>>>> +
>>>>>>> +Required Properties:
>>>>>>> +- compatible: should be one of
>>>>>>> + "ovti,ov9650"
>>>>>>> + "ovti,ov9652"
>>>>>>> + "ovti,ov9655"
>>>>>>> +- clocks: reference to the mclk input clock.
>>>>>>
>>>>>> I wonder why you have removed the clock-frequency property?
>>>>>>
>>>>>> In some situations the camera driver must be able to tell the clock
>>>>>> source which frequency it wants to see.
>>>>>
>>>>> That's what assigned-clock-rates property is for:
>>>>>
>>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b
>>>>> indings.txt
>>>>>
>>>>> AFAIU clock-frequency on devices is deprecated and equivalent to having
>>>>> a clocks property pointing to a fixed-clock, which is different from a
>>>>> clock with varying rate.
>>>>
>>>> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock
>>>> rate so we can only have the driver define what it wants to see.
>>>>
>>>> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is
>>>> that they do it in the driver.
>>>>
>>>> Maybe ISP developers can comment?
>>>
>>> The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is
>>> controlled by the clock consumer. As such, it's up to the consumer to decide
>>> whether to compute and request the clock rate dynamically at runtime, or use
>>> the assigned-clock-rates property in DT.
>>>
>>> Some ISPs include a clock generator, others don't. It should make no
>>> difference whether the clock is provided by the ISP, by a dedicated clock
>>> source in the SoC or by a discrete on-board adjustable clock source.
>>
>> Thanks for explaining the background.
>>
>> Do you have an hint or example how to use the assigned-clock-rates property in
>> a DT for a camera module connected to the omap3isp?
>>
>> Or does it just mean that it defines the property name?
>
> Please read the documentation link I sent - it's in the very bottom and
> should have an example.

I have seen it but it does not give me a good clue how to translate that into
correct omap3isp node setup in a specific DT. Rather it raises more questions.
Maybe because I don't understand completely what it is talking about.

The fundamental question is if this "assigned-clock-rates" is already
handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?

Or should we define that for the omap3isp node?

Then of course we need no new code and just use the right property names.
And N900, N9 camera DTs should be updated.

BR and thanks,
Nikolaus


2017-06-23 18:06:31

by Suman Anna

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Hi Nikolaus,

On 06/23/2017 10:22 AM, H. Nikolaus Schaller wrote:
> Hi,
>
>> Am 23.06.2017 um 16:57 schrieb Andreas Färber <[email protected]>:
>>
>> Am 23.06.2017 um 16:53 schrieb H. Nikolaus Schaller:
>>> Hi Laurent,
>>>
>>>> Am 23.06.2017 um 13:58 schrieb Laurent Pinchart <[email protected]>:
>>>>
>>>> Hi Nikolaus,
>>>>
>>>> On Friday 23 Jun 2017 12:59:24 H. Nikolaus Schaller wrote:
>>>>> Am 23.06.2017 um 12:46 schrieb Andreas Färber <[email protected]>:
>>>>>> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller:
>>>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>>>> b/Documentation/devicetree/bindings/media/i2c/ov965x.txt new file mode
>>>>>>>> 100644
>>>>>>>> index 0000000..0e0de1f
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>>>>>>> @@ -0,0 +1,37 @@
>>>>>>>> +* Omnivision OV9650/9652/9655 CMOS sensor
>>>>>>>> +
>>>>>>>> +The Omnivision OV965x sensor support multiple resolutions output, such
>>>>>>>> as
>>>>>>>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>>>>>>>> +output format.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +- compatible: should be one of
>>>>>>>> + "ovti,ov9650"
>>>>>>>> + "ovti,ov9652"
>>>>>>>> + "ovti,ov9655"
>>>>>>>> +- clocks: reference to the mclk input clock.
>>>>>>>
>>>>>>> I wonder why you have removed the clock-frequency property?
>>>>>>>
>>>>>>> In some situations the camera driver must be able to tell the clock
>>>>>>> source which frequency it wants to see.
>>>>>>
>>>>>> That's what assigned-clock-rates property is for:
>>>>>>
>>>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/clock/clock-b
>>>>>> indings.txt
>>>>>>
>>>>>> AFAIU clock-frequency on devices is deprecated and equivalent to having
>>>>>> a clocks property pointing to a fixed-clock, which is different from a
>>>>>> clock with varying rate.
>>>>>
>>>>> I am not sure if that helps here. The OMAP3-ISP does not have a fixed clock
>>>>> rate so we can only have the driver define what it wants to see.
>>>>>
>>>>> And common practise for OMAP3-ISP based camera modules (e.g. N900, N9) is
>>>>> that they do it in the driver.
>>>>>
>>>>> Maybe ISP developers can comment?
>>>>
>>>> The OMAP3 ISP is a variable-frequency clock provider. The clock frequency is
>>>> controlled by the clock consumer. As such, it's up to the consumer to decide
>>>> whether to compute and request the clock rate dynamically at runtime, or use
>>>> the assigned-clock-rates property in DT.
>>>>
>>>> Some ISPs include a clock generator, others don't. It should make no
>>>> difference whether the clock is provided by the ISP, by a dedicated clock
>>>> source in the SoC or by a discrete on-board adjustable clock source.
>>>
>>> Thanks for explaining the background.
>>>
>>> Do you have an hint or example how to use the assigned-clock-rates property in
>>> a DT for a camera module connected to the omap3isp?
>>>
>>> Or does it just mean that it defines the property name?
>>
>> Please read the documentation link I sent - it's in the very bottom and
>> should have an example.
>
> I have seen it but it does not give me a good clue how to translate that into
> correct omap3isp node setup in a specific DT. Rather it raises more questions.
> Maybe because I don't understand completely what it is talking about.
>
> The fundamental question is if this "assigned-clock-rates" is already
> handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?
>
> Or should we define that for the omap3isp node?
>
> Then of course we need no new code and just use the right property names.
> And N900, N9 camera DTs should be updated.

Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This
function gets invoked usually during clock registration, and also gets
called in platform_drv_probe(), so the parents and clocks do get
configured before your driver gets probed. So, this provides a default
configuration if these properties are supplied (in either clock nodes or
actual device nodes), and if your driver needs to change the rates at
runtime, then you would have to do that in the driver itself.

regards
Suman

2017-06-23 19:00:16

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

Hi Suman,

> Am 23.06.2017 um 20:05 schrieb Suman Anna <[email protected]>:
>
>>>>
>>>> Or does it just mean that it defines the property name?
>>>
>>> Please read the documentation link I sent - it's in the very bottom and
>>> should have an example.
>>
>> I have seen it but it does not give me a good clue how to translate that into
>> correct omap3isp node setup in a specific DT. Rather it raises more questions.
>> Maybe because I don't understand completely what it is talking about.
>>
>> The fundamental question is if this "assigned-clock-rates" is already
>> handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?
>>
>> Or should we define that for the omap3isp node?
>>
>> Then of course we need no new code and just use the right property names.
>> And N900, N9 camera DTs should be updated.
>
> Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This
> function gets invoked usually during clock registration, and also gets
> called in platform_drv_probe(), so the parents and clocks do get
> configured before your driver gets probed. So, this provides a default
> configuration if these properties are supplied (in either clock nodes or
> actual device nodes), and if your driver needs to change the rates at
> runtime, then you would have to do that in the driver itself.

Ok, now I understand. Thanks!

Quite hidden, but nice feature. I would never have thought that it exists.
Especially as there are no examples around omap3isp cameras...

And an fgrep assigned-clock-rates shows not many use cases outside CPU/SoC
include files.

But interestingly arch/arm/boot/dts/at91sam9g25ek.dts uses it for an ovti,ov2640 camera...

So it seems that we just have to write:

ov9655@30 {
compatible = "ovti,ov9655";
reg = <0x30>;
clocks = <&isp 0>; /* cam_clka */
assigned-clocks = <&isp 0>;
assigned-clock-rates = <24000000>;
};

instead of introducing a new clock-frequency property and code to handle it.

Or do I misinterpret what "parents" and "clocks" are in this context?

BR and thanks,
Nikolaus


2017-06-23 22:27:32

by Suman Anna

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/23/2017 01:59 PM, H. Nikolaus Schaller wrote:
> Hi Suman,
>
>> Am 23.06.2017 um 20:05 schrieb Suman Anna <[email protected]>:
>>
>>>>>
>>>>> Or does it just mean that it defines the property name?
>>>>
>>>> Please read the documentation link I sent - it's in the very bottom and
>>>> should have an example.
>>>
>>> I have seen it but it does not give me a good clue how to translate that into
>>> correct omap3isp node setup in a specific DT. Rather it raises more questions.
>>> Maybe because I don't understand completely what it is talking about.
>>>
>>> The fundamental question is if this "assigned-clock-rates" is already
>>> handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?
>>>
>>> Or should we define that for the omap3isp node?
>>>
>>> Then of course we need no new code and just use the right property names.
>>> And N900, N9 camera DTs should be updated.
>>
>> Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This
>> function gets invoked usually during clock registration, and also gets
>> called in platform_drv_probe(), so the parents and clocks do get
>> configured before your driver gets probed. So, this provides a default
>> configuration if these properties are supplied (in either clock nodes or
>> actual device nodes), and if your driver needs to change the rates at
>> runtime, then you would have to do that in the driver itself.
>
> Ok, now I understand. Thanks!
>
> Quite hidden, but nice feature. I would never have thought that it exists.
> Especially as there are no examples around omap3isp cameras...
>
> And an fgrep assigned-clock-rates shows not many use cases outside CPU/SoC
> include files.
>
> But interestingly arch/arm/boot/dts/at91sam9g25ek.dts uses it for an ovti,ov2640 camera...
>
> So it seems that we just have to write:
>
> ov9655@30 {
> compatible = "ovti,ov9655";
> reg = <0x30>;
> clocks = <&isp 0>; /* cam_clka */
> assigned-clocks = <&isp 0>;
> assigned-clock-rates = <24000000>;
> };

Yeah, that looks alright and should work.

regards
Suman

>
> instead of introducing a new clock-frequency property and code to handle it.
>
> Or do I misinterpret what "parents" and "clocks" are in this context?

2017-06-25 09:19:01

by Pavel Machek

[permalink] [raw]
Subject: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi!

> * unfortunately we still get no image :(
>
> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which
> we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and
> sync are correct. But we do not know since mplayer only shows a green screen.

What mplayer command line do you use? How did you set up the pipeline
with media-ctl?

On kernel.org, I have tree called camera-fw5-6 , where camera works
for me on n900. On gitlab, there's modifed fcam-dev, which can be used
for testing.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (741.00 B)
signature.asc (181.00 B)
Digital signature
Download all attachments

2017-06-25 12:36:55

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH v1 5/6] [media] ov9650: add multiple variant support

Hi Hugues,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc6 next-20170623]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url: https://github.com/0day-ci/linux/commits/Hugues-Fruchet/Add-support-of-OV9655-camera/20170625-201153
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x079-06251032 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386

All warnings (new ones prefixed by >>):

drivers/media//i2c/ov9650.c: In function 'ov965x_probe':
>> drivers/media//i2c/ov9650.c:1617:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (ov965x->initialize_controls)
^~
drivers/media//i2c/ov9650.c:1619:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
if (ret < 0)
^~
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_is_valid
Cyclomatic Complexity 1 include/linux/i2c.h:i2c_get_clientdata
Cyclomatic Complexity 1 include/media/media-entity.h:media_entity_cleanup
Cyclomatic Complexity 1 include/media/v4l2-subdev.h:v4l2_get_subdevdata
Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ctrl_to_sd
Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:to_ov965x
Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_get_default_format
Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_enum_mbus_code
Cyclomatic Complexity 4 drivers/media//i2c/ov9650.c:ov965x_enum_frame_sizes
Cyclomatic Complexity 6 drivers/media//i2c/ov9650.c:__ov965x_try_frame_size
Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_i2c_driver_init
Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_remove
Cyclomatic Complexity 8 drivers/media//i2c/ov9650.c:__ov965x_set_frame_interval
Cyclomatic Complexity 5 drivers/media//i2c/ov9650.c:ov965x_read
Cyclomatic Complexity 11 drivers/media//i2c/ov9650.c:__g_volatile_ctrl
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_write
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_write_array
Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_set_frame_size
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_default_gamma_curve
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_color_matrix
Cyclomatic Complexity 5 drivers/media//i2c/ov9650.c:ov965x_set_white_balance
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_brightness
Cyclomatic Complexity 12 drivers/media//i2c/ov9650.c:ov965x_set_gain
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_flip
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_saturation
Cyclomatic Complexity 6 drivers/media//i2c/ov9650.c:ov965x_set_sharpness
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_set_test_pattern
Cyclomatic Complexity 7 drivers/media//i2c/ov9650.c:ov965x_set_banding_filter
Cyclomatic Complexity 10 drivers/media//i2c/ov9650.c:__ov965x_set_params
Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
Cyclomatic Complexity 1 include/media/v4l2-ctrls.h:v4l2_ctrl_lock
Cyclomatic Complexity 1 include/media/v4l2-ctrls.h:v4l2_ctrl_unlock
Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_g_volatile_ctrl
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_s_frame_interval
Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_g_frame_interval
Cyclomatic Complexity 1 include/media/v4l2-ctrls.h:v4l2_ctrl_modify_range
Cyclomatic Complexity 7 drivers/media//i2c/ov9650.c:ov965x_update_exposure_ctrl
Cyclomatic Complexity 3 drivers/media//i2c/ov9650.c:ov965x_initialize_controls
Cyclomatic Complexity 10 drivers/media//i2c/ov9650.c:ov965x_set_exposure
Cyclomatic Complexity 12 drivers/media//i2c/ov9650.c:ov965x_s_ctrl
Cyclomatic Complexity 1 include/media/v4l2-subdev.h:v4l2_subdev_get_try_format
Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_open
Cyclomatic Complexity 11 drivers/media//i2c/ov9650.c:ov965x_set_fmt
Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_get_fmt
Cyclomatic Complexity 13 drivers/media//i2c/ov9650.c:ov965x_s_stream
Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:ov965x_gpio_set
Cyclomatic Complexity 2 drivers/media//i2c/ov9650.c:__ov965x_set_power
Cyclomatic Complexity 7 drivers/media//i2c/ov9650.c:ov965x_s_power
Cyclomatic Complexity 4 drivers/media//i2c/ov9650.c:ov965x_detect_sensor
Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
Cyclomatic Complexity 1 include/asm-generic/gpio.h:__gpio_set_value
Cyclomatic Complexity 1 include/linux/gpio.h:gpio_set_value
Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_export
Cyclomatic Complexity 5 drivers/media//i2c/ov9650.c:ov965x_configure_gpios
Cyclomatic Complexity 14 drivers/media//i2c/ov9650.c:ov965x_probe
Cyclomatic Complexity 1 drivers/media//i2c/ov9650.c:ov965x_i2c_driver_exit

vim +/if +1617 drivers/media//i2c/ov9650.c

1601 ov965x->init_regs = ov965x_init_regs;
1602 ov965x->initialize_controls = ov965x_initialize_controls;
1603 ov965x->framesizes = ov965x_framesizes;
1604 ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
1605 ov965x->formats = ov965x_formats;
1606 ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
1607 ov965x->intervals = ov965x_intervals;
1608 ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
1609 ov965x->fiv = &ov965x_intervals[0];
1610 ov965x->set_frame_interval = __ov965x_set_frame_interval;
1611 ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
1612 ov965x->set_params = __ov965x_set_params;
1613
1614 ov965x->frame_size = &ov965x->framesizes[0];
1615 ov965x_get_default_format(ov965x, &ov965x->format);
1616
> 1617 if (ov965x->initialize_controls)
1618 ret = ov965x->initialize_controls(ov965x);
1619 if (ret < 0)
1620 goto err_ctrls;
1621
1622 /* Update exposure time min/max to match frame format */
1623 if (ov965x->update_exposure_ctrl)
1624 ov965x->update_exposure_ctrl(ov965x);
1625

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation


Attachments:
(No filename) (6.47 kB)
.config.gz (24.35 kB)
Download all attachments

2017-06-25 16:07:46

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant

Hi Hugues,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.12-rc6 next-20170623]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url: https://github.com/0day-ci/linux/commits/Hugues-Fruchet/Add-support-of-OV9655-camera/20170625-201153
base: git://linuxtv.org/media_tree.git master


coccinelle warnings: (new ones prefixed by >>)

>> drivers/media/i2c/ov9650.c:2034:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation

2017-06-25 16:07:44

by kernel test robot

[permalink] [raw]
Subject: [PATCH] ov9650: fix semicolon.cocci warnings

drivers/media/i2c/ov9650.c:2034:2-3: Unneeded semicolon


Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 5ffa34fa8f2e ("ov9650: add support of OV9655 variant")
CC: Hugues Fruchet <[email protected]>
Signed-off-by: Fengguang Wu <[email protected]>
---

ov9650.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -2031,7 +2031,7 @@ static int ov965x_probe(struct i2c_clien
ov965x->formats = ov9655_formats;
ov965x->nb_of_formats = ARRAY_SIZE(ov9655_formats);
ov965x->set_params = ov965x_set_frame_size;
- };
+ }

ov965x->frame_size = &ov965x->framesizes[0];
ov965x_get_default_format(ov965x, &ov965x->format);

2017-06-26 06:01:45

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module


> Am 24.06.2017 um 00:24 schrieb Suman Anna <[email protected]>:
>
> On 06/23/2017 01:59 PM, H. Nikolaus Schaller wrote:
>> Hi Suman,
>>
>>> Am 23.06.2017 um 20:05 schrieb Suman Anna <[email protected]>:
>>>
>>>>>>
>>>>>> Or does it just mean that it defines the property name?
>>>>>
>>>>> Please read the documentation link I sent - it's in the very bottom and
>>>>> should have an example.
>>>>
>>>> I have seen it but it does not give me a good clue how to translate that into
>>>> correct omap3isp node setup in a specific DT. Rather it raises more questions.
>>>> Maybe because I don't understand completely what it is talking about.
>>>>
>>>> The fundamental question is if this "assigned-clock-rates" is already
>>>> handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?
>>>>
>>>> Or should we define that for the omap3isp node?
>>>>
>>>> Then of course we need no new code and just use the right property names.
>>>> And N900, N9 camera DTs should be updated.
>>>
>>> Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This
>>> function gets invoked usually during clock registration, and also gets
>>> called in platform_drv_probe(), so the parents and clocks do get
>>> configured before your driver gets probed. So, this provides a default
>>> configuration if these properties are supplied (in either clock nodes or
>>> actual device nodes), and if your driver needs to change the rates at
>>> runtime, then you would have to do that in the driver itself.
>>
>> Ok, now I understand. Thanks!
>>
>> Quite hidden, but nice feature. I would never have thought that it exists.
>> Especially as there are no examples around omap3isp cameras...
>>
>> And an fgrep assigned-clock-rates shows not many use cases outside CPU/SoC
>> include files.
>>
>> But interestingly arch/arm/boot/dts/at91sam9g25ek.dts uses it for an ovti,ov2640 camera...
>>
>> So it seems that we just have to write:
>>
>> ov9655@30 {
>> compatible = "ovti,ov9655";
>> reg = <0x30>;
>> clocks = <&isp 0>; /* cam_clka */
>> assigned-clocks = <&isp 0>;
>> assigned-clock-rates = <24000000>;
>> };
>
> Yeah, that looks alright and should work.

I have tested and it works that way.

Thanks,
Nikolaus

2017-06-26 06:03:24

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Hugues,

> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller <[email protected]>:
>
> Hi Hugues,
>
>> Am 22.06.2017 um 17:41 schrieb H. Nikolaus Schaller <[email protected]>:
>>
>>
>>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>>>
>>> This patchset enables OV9655 camera support.
>>>
>>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>>> plugged on connector P1 of STM32F746G-DISCO board.
>>> Due to lack of OV9650/52 hardware support, the modified related code
>>> could not have been checked for non-regression.
>>>
>>> First patches upgrade current support of OV9650/52 to prepare then
>>> introduction of OV9655 variant patch.
>>> Because of OV9655 register set slightly different from OV9650/9652,
>>> not all of the driver features are supported (controls). Supported
>>> resolutions are limited to VGA, QVGA, QQVGA.
>>> Supported format is limited to RGB565.
>>> Controls are limited to color bar test pattern for test purpose.
>>>
>>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller [1].
>>
>> Great!
>
> Thanks again for picking up or work and trying to get it upstream.
>
>>
>> I will test as soon as possible.

Here are some more test results and fixes:

>
> I have tried and had to fix some issues first:
> * gpio properties have a different name than in our approach (but that is something maintainers have to decide and is easy to follow this or that way)
> * there is no clock-frequency property which makes the driver request a clock frequency (something our camera interface expects this way)

This can indeed be replaced by assigned-clock-rates and no additional
driver code. So there is no need to implement anything new here.

> * there is no vana-supply regulator and we need that to power on/off the camera on demand (reset and pwdn isn't enough in our hardware)

this is something we still need to have added by patch

<http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=ed5d0a53a9c72036d6e017094b68111b5eb7f00d;hp=c0819afdcefcb19da351741d51dad00aaf909254;hb=da8ae2b038a448c8f822b3a4f20ed378db6d2934;hpb=6db55fc472eea2ec6db03833df027aecf6649f88>

> * for some unknown reason the driver does not load automatically from DT compatibility string and needs to be explicitly modprobed

This turned out to be because the i2c device ids are upper case while compatible-strings
are lower-case. See comment for patch 6/6.

BR and looking forward to v2,
Nikolaus

2017-06-26 06:03:51

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant


> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>
> Add a first support of OV9655 variant.
> Because of register set slightly different from OV9650/9652,
> not all of the driver features are supported (controls).
> Supported resolutions are limited to VGA, QVGA, QQVGA.
> Supported format is limited to RGB565.
> Controls are limited to color bar test pattern for test purpose.
>
> Signed-off-by: H. Nikolaus Schaller <[email protected]>
> Signed-off-by: Hugues Fruchet <[email protected]>
> ---
> drivers/media/i2c/Kconfig | 4 +-
> drivers/media/i2c/ov9650.c | 486 ++++++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 457 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index efea14d..a8f638c 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -594,11 +594,11 @@ config VIDEO_OV7670
> controller.
>
> config VIDEO_OV9650
> - tristate "OmniVision OV9650/OV9652 sensor support"
> + tristate "OmniVision OV9650/OV9652/OV9655 sensor support"
> depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> ---help---
> This is a V4L2 sensor-level driver for the Omnivision
> - OV9650 and OV9652 camera sensors.
> + OV9650 and OV9652 and OV9655 camera sensors.
>
> config VIDEO_VS6624
> tristate "ST VS6624 sensor support"
> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> index a9d268d..c0819af 100644
> --- a/drivers/media/i2c/ov9650.c
> +++ b/drivers/media/i2c/ov9650.c
> @@ -1,5 +1,5 @@
> /*
> - * Omnivision OV9650/OV9652 CMOS Image Sensor driver
> + * Omnivision OV9650/OV9652/OV9655 CMOS Image Sensor driver
> *
> * Copyright (C) 2013, Sylwester Nawrocki <[email protected]>
> *
> @@ -7,6 +7,15 @@
> * by Vladimir Fonov.
> * Copyright (c) 2010, Vladimir Fonov
> *
> + *
> + * Copyright (C) STMicroelectronics SA 2017
> + * Author: Hugues Fruchet <[email protected]> for STMicroelectronics.
> + *
> + * OV9655 initial support based on a driver written by H. Nikolaus Schaller:
> + * http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
> + * OV9655 registers sequence from STM32CubeF7 embedded software, see:
> + * https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
> + *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> @@ -58,14 +67,21 @@
> #define REG_PID 0x0a /* Product ID MSB */
> #define REG_VER 0x0b /* Product ID LSB */
> #define REG_COM3 0x0c
> -#define COM3_SWAP 0x40
> +#define COM3_COLORBAR 0x80
> +#define COM3_RGB565 0x00
> +#define COM3_SWAP 0x40 /* Doesn't work in RGB */
> +#define COM3_RESETB 0x08
> #define COM3_VARIOPIXEL1 0x04
> +#define OV9655_SINGLEFRAME 0x01
> #define REG_COM4 0x0d /* Vario Pixels */
> #define COM4_VARIOPIXEL2 0x80
> +#define OV9655_TRISTATE /* seems to have a different function */
> #define REG_COM5 0x0e /* System clock options */
> #define COM5_SLAVE_MODE 0x10
> -#define COM5_SYSTEMCLOCK48MHZ 0x80
> +#define COM5_SYSTEMCLOCK48MHZ 0x80 /* not on OV9655 */
> +#define OV9655_EXPOSURESTEP 0x01
> #define REG_COM6 0x0f /* HREF & ADBLC options */
> +#define COM6_BLC_OPTICAL 0x40 /* Optical black */
> #define REG_AECH 0x10 /* Exposure value, AEC[9:2] */
> #define REG_CLKRC 0x11 /* Clock control */
> #define CLK_EXT 0x40 /* Use external clock directly */
> @@ -74,13 +90,18 @@
> #define COM7_RESET 0x80
> #define COM7_FMT_MASK 0x38
> #define COM7_FMT_VGA 0x40
> -#define COM7_FMT_CIF 0x20
> +#define COM7_FMT_CIF 0x20
> #define COM7_FMT_QVGA 0x10
> #define COM7_FMT_QCIF 0x08
> -#define COM7_RGB 0x04
> -#define COM7_YUV 0x00
> -#define COM7_BAYER 0x01
> -#define COM7_PBAYER 0x05
> +#define COM7_RGB 0x04
> +#define COM7_YUV 0x00
> +#define COM7_BAYER 0x01
> +#define COM7_PBAYER 0x05
> +#define OV9655_COM7_VGA 0x60
> +#define OV9655_COM7_RAWRGB 0x00 /* different format encoding */
> +#define OV9655_COM7_RAWRGBINT 0x01
> +#define OV9655_COM7_YUV 0x02
> +#define OV9655_COM7_RGB 0x03
> #define REG_COM8 0x13 /* AGC/AEC options */
> #define COM8_FASTAEC 0x80 /* Enable fast AGC/AEC */
> #define COM8_AECSTEP 0x40 /* Unlimited AEC step size */
> @@ -89,14 +110,23 @@
> #define COM8_AWB 0x02 /* White balance enable */
> #define COM8_AEC 0x01 /* Auto exposure enable */
> #define REG_COM9 0x14 /* Gain ceiling */
> -#define COM9_GAIN_CEIL_MASK 0x70 /* */
> +#define COM9_GAIN_CEIL_MASK 0x70
> +#define COM9_GAIN_CEIL_16X 0x30
> +#define OV9655_COM9_EXPTIMING 0x08
> +#define OV9655_COM9_VSYNCDROP 0x04
> +#define OV9655_COM9_AECDROP 0x02
> #define REG_COM10 0x15 /* PCLK, HREF, HSYNC signals polarity */
> +#define OV9655_SLAVE_PIN 0x80 /* SLHS/SLVS instead of RESETB/PWDN */
> #define COM10_HSYNC 0x40 /* HSYNC instead of HREF */
> #define COM10_PCLK_HB 0x20 /* Suppress PCLK on horiz blank */
> -#define COM10_HREF_REV 0x08 /* Reverse HREF */
> +#define OV9655_COM10_PCLK_REV 0x10 /* PCLK reverse */
> +#define COM10_HREF_REV 0x08 /* Reverse HREF */
> #define COM10_VS_LEAD 0x04 /* VSYNC on clock leading edge */
> +#define OV9655_COM10_RESET_OPTION 0x04 /* Reset signal end point */
> #define COM10_VS_NEG 0x02 /* VSYNC negative */
> #define COM10_HS_NEG 0x01 /* HSYNC negative */
> +#define OV9655_REG16 0x16 /* dummy frame and blanking */
> +#define OV9655_REG16_DUMMY_8 0x20 /* dummy frame when gain > 8 */
> #define REG_HSTART 0x17 /* Horiz start high bits */
> #define REG_HSTOP 0x18 /* Horiz stop high bits */
> #define REG_VSTART 0x19 /* Vert start high bits */
> @@ -117,6 +147,7 @@
> #define REG_BBIAS 0x27 /* B channel output bias */
> #define REG_GBBIAS 0x28 /* Gb channel output bias */
> #define REG_GRCOM 0x29 /* Analog BLC & regulator */
> +#define OV9655_PREGAIN 0x29
> #define REG_EXHCH 0x2a /* Dummy pixel insert MSB */
> #define REG_EXHCL 0x2b /* Dummy pixel insert LSB */
> #define REG_RBIAS 0x2c /* R channel output bias */
> @@ -127,12 +158,30 @@
> #define REG_HSYEN 0x31 /* HSYNC falling edge delay LSB*/
> #define REG_HREF 0x32 /* HREF pieces */
> #define REG_CHLF 0x33 /* reserved */
> +#define OV9655_CLKF 0x33 /* Array current control */
> +#define OV9655_AREF1 0x34 /* Array reference control */
> +#define OV9655_AREF2 0x35 /* Array reference control */
> +#define OV9655_AREF3 0x36 /* Array reference control */
> #define REG_ADC 0x37 /* reserved */
> +#define OV9655_ADC 0x37 /* ADC Control 1 (Range adjustment) */
> #define REG_ACOM 0x38 /* reserved */
> -#define REG_OFON 0x39 /* Power down register */
> +#define OV9655_ADC2 0x38 /* ADC Control 2 (Range adjustment) */
> +#define REG_OFON 0x39 /* Power down register (ov9650 only) */
> #define OFON_PWRDN 0x08 /* Power down bit */
> +#define OV9655_AREF4 0x39 /* Array reference control */
> #define REG_TSLB 0x3a /* YUVU format */
> +#define OV9655_PCLKDELAY2NS 0x40
> +#define OV9655_PCLKDELAY4NS 0x80
> +#define OV9655_PCLKDELAY6NS 0xc0
> +#define OV9655_OUTREVERSE 0x20
> +#define OV9655_FIXEDUV 0x10
> #define TSLB_YUYV_MASK 0x0c /* UYVY or VYUY - see com13 */
> +#define TSLB_YUYV 0x00
> +#define TSLB_YVYU 0x04
> +#define TSLB_VYUY 0x08
> +#define TSLB_UYVY 0x0c
> +#define OV9655_BANDINGAUTO 0x02
> +
> #define REG_COM11 0x3b /* Night mode, banding filter enable */
> #define COM11_NIGHT 0x80 /* Night mode enable */
> #define COM11_NMFR 0x60 /* Two bit NM frame rate */
> @@ -142,25 +191,38 @@
> #define COM12_HREF 0x80 /* HREF always */
> #define REG_COM13 0x3d /* Gamma selection, Color matrix en. */
> #define COM13_GAMMA 0x80 /* Gamma enable */
> -#define COM13_UVSAT 0x40 /* UV saturation auto adjustment */
> +#define COM13_UVSAT 0x40 /* UV saturation auto adjustment */
> +#define COM13_Y_DELAY 0x08 /* Delay Y channel */
> #define COM13_UVSWAP 0x01 /* V before U - w/TSLB */
> #define REG_COM14 0x3e /* Edge enhancement options */
> #define COM14_EDGE_EN 0x02
> #define COM14_EEF_X2 0x01
> +#define OV9655_REG_COM14 0x3e /* pixel correction/zoom ON/OFF sel. */
> +#define OV9655_COM14_BLACK_PIX 0x08 /* Black pixel correction */
> +#define OV9655_COM14_WHITE_PIX 0x04 /* White pixel correction */
> +#define OV9655_COM14_ZOOM 0x02 /* Zoom function ON */
> #define REG_EDGE 0x3f /* Edge enhancement factor */
> #define EDGE_FACTOR_MASK 0x0f
> #define REG_COM15 0x40 /* Output range, RGB 555/565 */
> #define COM15_R10F0 0x00 /* Data range 10 to F0 */
> -#define COM15_R01FE 0x80 /* 01 to FE */
> +#define COM15_R01FE 0x80 /* 01 to FE */
> #define COM15_R00FF 0xc0 /* 00 to FF */
> #define COM15_RGB565 0x10 /* RGB565 output */
> #define COM15_RGB555 0x30 /* RGB555 output */
> #define COM15_SWAPRB 0x04 /* Swap R&B */
> #define REG_COM16 0x41 /* Color matrix coeff options */
> #define REG_COM17 0x42 /* Single frame out, banding filter */
> +#define OV9655_REG_COM17 0x42 /* Denoise, edge, auto gain, ... */
> +#define OV9655_COM17_EDGE_AUTO 0x40 /* Edge auto */
> +#define OV9655_COM17_DENOISE_AUTO 0x80 /* Denoise auto */
> +#define OV9655_REG_RSVD(__n) (0x43 + (__n) - 1) /* reserved but used... */
> /* n = 1...9, 0x4f..0x57 */
> -#define REG_MTX(__n) (0x4f + (__n) - 1)
> +#define REG_MTX(__n) (0x4f + (__n) - 1)
> #define REG_MTXS 0x58
> +#define REG_AWBOP(__n) (0x59 + (__n) - 1) /* AWB control options */
> +#define REG_BLMT 0x5F /* AWB Blue Component Gain Limit */
> +#define REG_RLMT 0x60 /* AWB Red Component Gain Limit */
> +#define REG_GLMT 0x61 /* AWB Green Component Gain Limit */
> /* Lens Correction Option 1...5, __n = 0...5 */
> #define REG_LCC(__n) (0x62 + (__n) - 1)
> #define LCC5_LCC_ENABLE 0x01 /* LCC5, enable lens correction */
> @@ -170,10 +232,26 @@
> #define REG_HV 0x69 /* Manual banding filter MSB */
> #define REG_MBD 0x6a /* Manual banding filter value */
> #define REG_DBLV 0x6b /* reserved */
> +#define OV9655_REG_DBLV 0x6b /* PLL, DVDD regu bypass, bandgap */
> +#define OV9655_DBLV_BANDGAP 0x0a /* default value */
> +#define OV9655_DBLV_LDO_BYPASS 0x10
> +#define OV9655_DBLV_PLL_BYPASS 0x00
> +#define OV9655_DBLV_PLL_4X 0x40
> +#define OV9655_DBLV_PLL_6X 0x80
> +#define OV9655_DBLV_PLL_8X 0xc0
> #define REG_GSP 0x6c /* Gamma curve */
> #define GSP_LEN 15
> +#define OV9655_REG_DNSTH 0x70 /* De-noise Function Threshold Adj. */
> +#define OV9655_REG_POIDX 0x72 /* Pixel output index */
> +#define OV9655_REG_PCKDV 0x73 /* Pixel Clock Output Selection */
> +#define OV9655_REG_XINDX 0x74 /* Horizontal Scaling Down Coeff. */
> +#define OV9655_REG_YINDX 0x75 /* Vertical Scaling Down Coeff. */
> +#define OV9655_REG_SLOP 0x7A /* Gamma Curve Highest Segment Slope */
> +#define OV9655_REG_GAM(__n) (0x7B + (__n) - 1) /* Gamma curve */
> #define REG_GST 0x7c /* Gamma curve */
> #define GST_LEN 15
> +#define OV9655_REG_COM18 0x8b /* Zoom mode in VGA */
> +#define OV9655_REG_COM19 0x8c /* UV adjustment */
> #define REG_COM21 0x8b
> #define REG_COM22 0x8c /* Edge enhancement, denoising */
> #define COM22_WHTPCOR 0x02 /* White pixel correction enable */
> @@ -181,6 +259,8 @@
> #define COM22_DENOISE 0x10 /* White pixel correction option */
> #define REG_COM23 0x8d /* Color bar test, color gain */
> #define COM23_TEST_MODE 0x10
> +#define OV9655_REG_COM20 0x8d
> +#define OV9655_COM20_TEST_MODE 0x10
> #define REG_DBLC1 0x8f /* Digital BLC */
> #define REG_DBLC_B 0x90 /* Digital BLC B channel offset */
> #define REG_DBLC_R 0x91 /* Digital BLC R channel offset */
> @@ -193,6 +273,17 @@
> #define REG_AECHM 0xa1 /* Exposure value - bits AEC[15:10] */
> #define REG_BD50ST 0xa2 /* Banding filter value for 50Hz */
> #define REG_BD60ST 0xa3 /* Banding filter value for 60Hz */
> +#define OV9655_REG_COM21 0xa4 /* Digital gain */
> +#define OV9655_REG_AWB_GREEN 0xa6 /* AWB green */
> +#define OV9655_REG_REF_A8 0xa8 /* Analog Reference Control */
> +#define OV9655_REG_REF_A9 0xa9 /* Analog Reference Control */
> +#define OV9655_REG_BLC(__n) (0xac + (__n) - 1) /* Black Level Control */
> +#define OV9655_REG_CTRLB4 0xb4 /* UV adjustment */
> +#define OV9655_REG_ADBOFF 0xbc /* ADC B channel offset setting */
> +#define OV9655_REG_ADROFF 0xbd /* ADC R channel offset setting */
> +#define OV9655_REG_ADGBOFF 0xbe /* ADC Gb channel offset setting */
> +#define OV9655_REG_ADGEOFF 0xbf /* ADC Gr channel offset setting */
> +#define OV9655_REG_COM24 0xc7 /* Pixel clock frequency selection */
> #define REG_NULL 0xff /* Array end token */
>
> #define DEF_CLKRC 0x80
> @@ -200,6 +291,7 @@
> #define OV965X_ID(_msb, _lsb) ((_msb) << 8 | (_lsb))
> #define OV9650_ID 0x9650
> #define OV9652_ID 0x9652
> +#define OV9655V5_ID 0x9657
>
> struct ov965x_ctrls {
> struct v4l2_ctrl_handler handler;
> @@ -458,6 +550,292 @@ struct ov965x_pixfmt {
> {{ 1, 25 }, { QVGA_WIDTH, QVGA_HEIGHT }, 1 }, /* 25 fps */
> };
>
> +/* OV9655 */
> +static const struct i2c_rv ov9655_init_regs[] = {
> + { REG_GAIN, 0x00 },
> + { REG_BLUE, 0x80 },
> + { REG_RED, 0x80 },
> + { REG_VREF, 0x02 },
> + { REG_COM1, 0x03 },
> + { REG_COM2, 0x01 },/* Output drive x2 */
> + { REG_COM3, COM3_RGB565 },/* Output drive x2, RGB565 */
> + { REG_COM5, 0x60 | OV9655_EXPOSURESTEP },/* 0x60 ? */
> + { REG_COM6, COM6_BLC_OPTICAL },
> + { REG_CLKRC, 0x01 },/* F(internal clk) = F(input clk) / 2 */
> + { REG_COM7, OV9655_COM7_VGA | OV9655_COM7_YUV },
> + { REG_COM8, COM8_FASTAEC | COM8_AECSTEP |
> + COM8_AGC | COM8_AWB | COM8_AEC },
> + { REG_COM9, COM9_GAIN_CEIL_16X | OV9655_COM9_EXPTIMING |
> + OV9655_COM9_AECDROP },
> + { OV9655_REG16, OV9655_REG16_DUMMY_8 | 0x4 },
> + { REG_HSTART, 0x18 },
> + { REG_HSTOP, 0x04 },
> + { REG_VSTART, 0x01 },
> + { REG_VSTOP, 0x81 },
> + { REG_MVFP, 0x00 },/* No mirror/flip */
> + { REG_AEW, 0x3c },
> + { REG_AEB, 0x36 },
> + { REG_VPT, 0x72 },
> + { REG_BBIAS, 0x08 },
> + { REG_GBBIAS, 0x08 },
> + { OV9655_PREGAIN, 0x15 },
> + { REG_EXHCH, 0x00 },
> + { REG_EXHCL, 0x00 },
> + { REG_RBIAS, 0x08 },
> + { REG_HREF, 0x12 },/* QVGA */
> + { REG_CHLF, 0x00 },
> + { OV9655_AREF1, 0x3f },
> + { OV9655_AREF2, 0x00 },
> + { OV9655_AREF3, 0x3a },
> + { OV9655_ADC2, 0x72 },
> + { OV9655_AREF4, 0x57 },
> + { REG_TSLB, OV9655_PCLKDELAY6NS | TSLB_UYVY },
> + { REG_COM11, 0x04 },/* 0x04 ? */
> + { REG_COM13, COM13_GAMMA | 0x10 |
> + COM13_Y_DELAY | COM13_UVSWAP },/* 0x10 ? */
> + {OV9655_REG_COM14, OV9655_COM14_ZOOM }, /* QVGA */
> + { REG_EDGE, 0xc1 },
> + { REG_COM15, COM15_R00FF },/* Full range output */
> + { REG_COM16, 0x41 },/* 0x41 ? */
> + { OV9655_REG_COM17, OV9655_COM17_EDGE_AUTO |
> + OV9655_COM17_DENOISE_AUTO },
> + { OV9655_REG_RSVD(1), 0x0a },
> + { OV9655_REG_RSVD(2), 0xf0 },
> + { OV9655_REG_RSVD(3), 0x46 },
> + { OV9655_REG_RSVD(4), 0x62 },
> + { OV9655_REG_RSVD(5), 0x2a },
> + { OV9655_REG_RSVD(6), 0x3c },
> + { OV9655_REG_RSVD(7), 0xfc },
> + { OV9655_REG_RSVD(8), 0xfc },
> + { OV9655_REG_RSVD(9), 0x7f },
> + { OV9655_REG_RSVD(10), 0x7f },
> + { OV9655_REG_RSVD(11), 0x7f },
> + { REG_MTX(1), 0x98 },
> + { REG_MTX(2), 0x98 },
> + { REG_MTX(3), 0x00 },
> + { REG_MTX(4), 0x28 },
> + { REG_MTX(5), 0x70 },
> + { REG_MTX(6), 0x98 },
> + { REG_MTXS, 0x1a },
> + { REG_AWBOP(1), 0x85 },
> + { REG_AWBOP(2), 0xa9 },
> + { REG_AWBOP(3), 0x64 },
> + { REG_AWBOP(4), 0x84 },
> + { REG_AWBOP(5), 0x53 },
> + { REG_AWBOP(6), 0x0e },
> + { REG_BLMT, 0xf0 },
> + { REG_RLMT, 0xf0 },
> + { REG_GLMT, 0xf0 },
> + { REG_LCC(1), 0x00 },
> + { REG_LCC(2), 0x00 },
> + { REG_LCC(3), 0x02 },
> + { REG_LCC(4), 0x20 },
> + { REG_LCC(5), 0x00 },
> + { 0x69, 0x0a },/* Reserved... */
> + { OV9655_REG_DBLV, OV9655_DBLV_PLL_4X | OV9655_DBLV_LDO_BYPASS |
> + OV9655_DBLV_BANDGAP },
> + { 0x6c, 0x04 },/* Reserved... */
> + { 0x6d, 0x55 },/* Reserved... */
> + { 0x6e, 0x00 },/* Reserved... */
> + { 0x6f, 0x9d },/* Reserved... */
> + { OV9655_REG_DNSTH, 0x21 },
> + { 0x71, 0x78 },/* Reserved... */
> + { OV9655_REG_POIDX, 0x11 },/* QVGA */
> + { OV9655_REG_PCKDV, 0x01 },/* QVGA */
> + { OV9655_REG_XINDX, 0x10 },
> + { OV9655_REG_YINDX, 0x10 },
> + { 0x76, 0x01 },/* Reserved... */
> + { 0x77, 0x02 },/* Reserved... */
> + { 0x7A, 0x12 },/* Reserved... */
> + { OV9655_REG_GAM(1), 0x08 },
> + { OV9655_REG_GAM(2), 0x16 },
> + { OV9655_REG_GAM(3), 0x30 },
> + { OV9655_REG_GAM(4), 0x5e },
> + { OV9655_REG_GAM(5), 0x72 },
> + { OV9655_REG_GAM(6), 0x82 },
> + { OV9655_REG_GAM(7), 0x8e },
> + { OV9655_REG_GAM(8), 0x9a },
> + { OV9655_REG_GAM(9), 0xa4 },
> + { OV9655_REG_GAM(10), 0xac },
> + { OV9655_REG_GAM(11), 0xb8 },
> + { OV9655_REG_GAM(12), 0xc3 },
> + { OV9655_REG_GAM(13), 0xd6 },
> + { OV9655_REG_GAM(14), 0xe6 },
> + { OV9655_REG_GAM(15), 0xf2 },
> + { 0x8a, 0x24 },/* Reserved... */
> + { OV9655_REG_COM19, 0x80 },
> + { 0x90, 0x7d },/* Reserved... */
> + { 0x91, 0x7b },/* Reserved... */
> + { REG_LCCFB, 0x02 },
> + { REG_LCCFR, 0x02 },
> + { REG_DBLC_GB, 0x7a },
> + { REG_DBLC_GR, 0x79 },
> + { REG_AECHM, 0x40 },
> + { OV9655_REG_COM21, 0x50 },
> + { 0xa5, 0x68 },/* Reserved... */
> + { OV9655_REG_AWB_GREEN, 0x4a },
> + { OV9655_REG_REF_A8, 0xc1 },
> + { OV9655_REG_REF_A9, 0xef },
> + { 0xaa, 0x92 },/* Reserved... */
> + { 0xab, 0x04 },/* Reserved... */
> + { OV9655_REG_BLC(1), 0x80 },
> + { OV9655_REG_BLC(2), 0x80 },
> + { OV9655_REG_BLC(3), 0x80 },
> + { OV9655_REG_BLC(4), 0x80 },
> + { OV9655_REG_BLC(7), 0xf2 },
> + { OV9655_REG_BLC(8), 0x20 },
> + { OV9655_REG_CTRLB4, 0x20 },
> + { 0xb5, 0x00 },/* Reserved... */
> + { 0xb6, 0xaf },/* Reserved... */
> + { 0xb6, 0xaf },/* Reserved... */
> + { 0xbb, 0xae },/* Reserved... */
> + { OV9655_REG_ADBOFF, 0x7f },
> + { OV9655_REG_ADROFF, 0x7f },
> + { OV9655_REG_ADGBOFF, 0x7f },
> + { OV9655_REG_ADGEOFF, 0x7f },
> + { OV9655_REG_ADGEOFF, 0x7f },
> + { 0xc0, 0xaa },/* Reserved... */
> + { 0xc1, 0xc0 },/* Reserved... */
> + { 0xc2, 0x01 },/* Reserved... */
> + { 0xc3, 0x4e },/* Reserved... */
> + { 0xc6, 0x05 },/* Reserved... */
> + { OV9655_REG_COM24, 0x81 },/* QVGA */
> + { 0xc9, 0xe0 },/* Reserved... */
> + { 0xca, 0xe8 },/* Reserved... */
> + { 0xcb, 0xf0 },/* Reserved... */
> + { 0xcc, 0xd8 },/* Reserved... */
> + { 0xcd, 0x93 },/* Reserved... */
> + { REG_COM7, OV9655_COM7_VGA | OV9655_COM7_RGB },
> + { REG_COM15, COM15_RGB565 },
> + { REG_NULL, 0}
> +};
> +
> +static const struct i2c_rv ov9655_qvga_regs[] = {
> + { REG_HREF, 0x12 },
> + { OV9655_REG_COM14, OV9655_COM14_ZOOM },
> + { OV9655_REG_POIDX, 0x11 },
> + { OV9655_REG_PCKDV, 0x01 },
> + { OV9655_REG_COM24, 0x81 },
> + { REG_NULL, 0}
> +};
> +
> +static const struct i2c_rv ov9655_qqvga_regs[] = {
> + { REG_HREF, 0xa4 },
> + { REG_COM14, OV9655_COM14_BLACK_PIX | OV9655_COM14_WHITE_PIX |
> + OV9655_COM14_ZOOM },
> + { OV9655_REG_POIDX, 0x22 },
> + { OV9655_REG_PCKDV, 0x02 },
> + { OV9655_REG_COM24, 0x82 },
> + { REG_NULL, 0}
> +};
> +
> +static const struct i2c_rv ov9655_vga_regs[] = {
> + { REG_GAIN, 0x11 },
> + { REG_VREF, 0x12 },
> + { REG_B_AVE, 0x2e },
> + { REG_GB_AVE, 0x2e },
> + { REG_GR_AVE, 0x2e },
> + { REG_R_AVE, 0x2e },
> + { REG_COM6, 0x48 },
> + { REG_AECH, 0x7b },
> + { REG_CLKRC, 0x03 },
> + { REG_COM8, COM8_FASTAEC | COM8_AECSTEP | COM8_BFILT |
> + COM8_AGC | COM8_AWB | COM8_AEC },
> + { REG_HSTART, 0x16 },
> + { REG_HSTOP, 0x02 },
> + { REG_VSTART, 0x01 },
> + { REG_VSTOP, 0x3d },
> + { REG_MVFP, 0x04 },
> + { REG_YAVE, 0x2e },
> + { REG_HREF, 0xff },
> + { OV9655_AREF1, 0x3d },
> + { OV9655_AREF3, 0xfa },
> + { REG_TSLB, 0xcc },
> + { REG_COM11, 0xcc },
> + { REG_COM14, 0x0c },
> + { REG_EDGE, 0x82 },
> + { REG_COM15, COM15_R00FF | COM15_RGB565 },/* full range */
> + { REG_COM16, 0x40 },
> + { OV9655_REG_RSVD(1), 0x14 },
> + { OV9655_REG_RSVD(2), 0xf0 },
> + { OV9655_REG_RSVD(3), 0x46 },
> + { OV9655_REG_RSVD(4), 0x62 },
> + { OV9655_REG_RSVD(5), 0x2a },
> + { OV9655_REG_RSVD(6), 0x3c },
> + { OV9655_REG_RSVD(8), 0xe9 },
> + { OV9655_REG_RSVD(9), 0xdd },
> + { OV9655_REG_RSVD(10), 0xdd },
> + { OV9655_REG_RSVD(11), 0xdd },
> + { OV9655_REG_RSVD(12), 0xdd },
> + { REG_LCC(1), 0x00 },
> + { REG_LCC(2), 0x00 },
> + { REG_LCC(3), 0x02 },
> + { REG_LCC(4), 0x20 },
> + { REG_LCC(5), 0x01 },
> + { REG_GSP, 0x0c },
> + { 0x6f, 0x9e },/* Reserved... */
> + { OV9655_REG_DNSTH, 0x06 },
> + { OV9655_REG_POIDX, 0x00 },
> + { OV9655_REG_PCKDV, 0x00 },
> + { OV9655_REG_XINDX, 0x3a },
> + { OV9655_REG_YINDX, 0x35 },
> + { OV9655_REG_SLOP, 0x20 },
> + { OV9655_REG_GAM(1), 0x1c },
> + { OV9655_REG_GAM(2), 0x28 },
> + { OV9655_REG_GAM(3), 0x3c },
> + { OV9655_REG_GAM(4), 0x5a },
> + { OV9655_REG_GAM(5), 0x68 },
> + { OV9655_REG_GAM(6), 0x76 },
> + { OV9655_REG_GAM(7), 0x80 },
> + { OV9655_REG_GAM(8), 0x88 },
> + { OV9655_REG_GAM(9), 0x8f },
> + { OV9655_REG_GAM(10), 0x96 },
> + { OV9655_REG_GAM(11), 0xa3 },
> + { OV9655_REG_GAM(12), 0xaf },
> + { OV9655_REG_GAM(13), 0xc4 },
> + { OV9655_REG_GAM(14), 0xd7 },
> + { OV9655_REG_GAM(15), 0xe8 },
> + { 0x8a, 0x23 },/* Reserved... */
> + { OV9655_REG_COM19, 0x8d },
> + { 0x90, 0x92 },/* Reserved... */
> + { 0x91, 0x92 },/* Reserved... */
> + { REG_DBLC_GB, 0x90 },
> + { REG_DBLC_GR, 0x90 },
> + { OV9655_REG_AWB_GREEN, 0x40 },
> + { OV9655_REG_ADBOFF, 0x02 },
> + { OV9655_REG_ADROFF, 0x01 },
> + { OV9655_REG_ADGBOFF, 0x02 },
> + { OV9655_REG_ADGEOFF, 0x01 },
> + { 0xc1, 0xc8 },/* Reserved... */
> + { 0xc6, 0x85 },/* Reserved... */
> + { OV9655_REG_COM24, 0x80 },
> + { REG_NULL, 0}
> +};
> +
> +static const struct ov965x_framesize ov9655_framesizes[] = {
> + {
> + .width = VGA_WIDTH,
> + .height = VGA_HEIGHT,
> + .regs = ov9655_vga_regs,
> + .max_exp_lines = 498,
> + }, {
> + .width = QVGA_WIDTH,
> + .height = QVGA_HEIGHT,
> + .regs = ov9655_qvga_regs,
> + .max_exp_lines = 248,
> + },
> + {
> + .width = QQVGA_WIDTH,
> + .height = QQVGA_HEIGHT,
> + .regs = ov9655_qqvga_regs,
> + .max_exp_lines = 124,
> + },
> +};
> +
> +static const struct ov965x_pixfmt ov9655_formats[] = {
> + { MEDIA_BUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB, 0x08},
> +};
> +
> static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
> {
> return &container_of(ctrl->handler, struct ov965x, ctrls.handler)->sd;
> @@ -894,12 +1272,16 @@ static int ov965x_set_test_pattern(struct ov965x *ov965x, int value)
> {
> int ret;
> u8 reg;
> + u8 addr = (ov965x->id == OV9655V5_ID) ?
> + REG_COM3 : REG_COM23;
> + u8 mask = (ov965x->id == OV9655V5_ID) ?
> + COM3_COLORBAR : COM23_TEST_MODE;
>
> - ret = ov965x_read(ov965x->client, REG_COM23, &reg);
> + ret = ov965x_read(ov965x->client, addr, &reg);
> if (ret < 0)
> return ret;
> - reg = value ? reg | COM23_TEST_MODE : reg & ~COM23_TEST_MODE;
> - return ov965x_write(ov965x->client, REG_COM23, reg);
> + reg = value ? reg | mask : reg & ~mask;
> + return ov965x_write(ov965x->client, addr, reg);
> }
>
> static int __g_volatile_ctrl(struct ov965x *ov965x, struct v4l2_ctrl *ctrl)
> @@ -1102,6 +1484,30 @@ static int ov965x_initialize_controls(struct ov965x *ov965x)
> return 0;
> }
>
> +static int ov9655_initialize_controls(struct ov965x *ov965x)
> +{
> + const struct v4l2_ctrl_ops *ops = &ov965x_ctrl_ops;
> + struct ov965x_ctrls *ctrls = &ov965x->ctrls;
> + struct v4l2_ctrl_handler *hdl = &ctrls->handler;
> + int ret;
> +
> + ret = v4l2_ctrl_handler_init(hdl, 16);
> + if (ret < 0)
> + return ret;
> +
> + v4l2_ctrl_new_std_menu_items(hdl, ops, V4L2_CID_TEST_PATTERN,
> + ARRAY_SIZE(test_pattern_menu) - 1, 0, 0,
> + test_pattern_menu);
> + if (hdl->error) {
> + ret = hdl->error;
> + v4l2_ctrl_handler_free(hdl);
> + return ret;
> + }
> +
> + ov965x->sd.ctrl_handler = hdl;
> + return 0;
> +}
> +
> /*
> * V4L2 subdev video and pad level operations
> */
> @@ -1518,9 +1924,15 @@ static int ov965x_detect_sensor(struct v4l2_subdev *sd)
>
> if (!ret) {
> ov965x->id = OV965X_ID(pid, ver);
> - if (ov965x->id == OV9650_ID || ov965x->id == OV9652_ID) {
> + switch (ov965x->id) {
> + case OV9650_ID:
> + case OV9652_ID:
> v4l2_info(sd, "Found OV%04X sensor\n", ov965x->id);
> - } else {
> + break;
> + case OV9655V5_ID:
> + v4l2_info(sd, "Found OV%04X sensor\n", ov965x->id - 2);
> + break;
> + default:
> v4l2_err(sd, "Sensor detection failed (%04X, %d)\n",
> ov965x->id, ret);
> ret = -ENODEV;
> @@ -1598,18 +2010,28 @@ static int ov965x_probe(struct i2c_client *client,
> if (ret < 0)
> goto err_me;
>
> - ov965x->init_regs = ov965x_init_regs;
> - ov965x->initialize_controls = ov965x_initialize_controls;
> - ov965x->framesizes = ov965x_framesizes;
> - ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
> - ov965x->formats = ov965x_formats;
> - ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
> - ov965x->intervals = ov965x_intervals;
> - ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
> - ov965x->fiv = &ov965x_intervals[0];
> - ov965x->set_frame_interval = __ov965x_set_frame_interval;
> - ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
> - ov965x->set_params = __ov965x_set_params;
> + if (ov965x->id != OV9655V5_ID) {
> + ov965x->init_regs = ov965x_init_regs;
> + ov965x->initialize_controls = ov965x_initialize_controls;
> + ov965x->framesizes = ov965x_framesizes;
> + ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
> + ov965x->formats = ov965x_formats;
> + ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
> + ov965x->intervals = ov965x_intervals;
> + ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
> + ov965x->fiv = &ov965x_intervals[0];
> + ov965x->set_frame_interval = __ov965x_set_frame_interval;
> + ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
> + ov965x->set_params = __ov965x_set_params;
> + } else {
> + ov965x->init_regs = ov9655_init_regs;
> + ov965x->initialize_controls = ov9655_initialize_controls;
> + ov965x->framesizes = ov9655_framesizes;
> + ov965x->nb_of_framesizes = ARRAY_SIZE(ov9655_framesizes);
> + ov965x->formats = ov9655_formats;
> + ov965x->nb_of_formats = ARRAY_SIZE(ov9655_formats);
> + ov965x->set_params = ov965x_set_frame_size;
> + };
>
> ov965x->frame_size = &ov965x->framesizes[0];
> ov965x_get_default_format(ov965x, &ov965x->format);
> @@ -1652,6 +2074,7 @@ static int ov965x_remove(struct i2c_client *client)
> static const struct i2c_device_id ov965x_id[] = {
> { "OV9650", 0x9650 },
> { "OV9652", 0x9652 },
> + { "OV9655", 0x9655 },

i2c device ids should be lower case to match compatible-strings in DT for
automatic modprobing.

Please pick/merge/copy&paste

<http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=c310cbee131665893d2d1df0ab1246bd9b1d41fe;hp=ed5d0a53a9c72036d6e017094b68111b5eb7f00d;hb=115b9c59202aa2fb1fecb691ebeef51220d363b8;hpb=da8ae2b038a448c8f822b3a4f20ed378db6d2934>

With this change I get:

root@letux:~# dmesg|fgrep ov96
[ 12.727600] ov965x: Found OV9655 sensor
[ 12.747711] ov965x 1-0030: ov965x driver probed
root@letux:~#

during probe.

> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(i2c, ov965x_id);
> @@ -1659,6 +2082,7 @@ static int ov965x_remove(struct i2c_client *client)
> static const struct of_device_id ov965x_of_match[] = {
> { .compatible = "ovti,ov9650", .data = (void *)0x9650 },
> { .compatible = "ovti,ov9652", .data = (void *)0x9652 },
> + { .compatible = "ovti,ov9655", .data = (void *)0x9655 },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, ov965x_of_match);
> --
> 1.9.1
>


2017-06-26 06:06:02

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Pavel,

> Am 25.06.2017 um 11:18 schrieb Pavel Machek <[email protected]>:
>
> Hi!
>
>> * unfortunately we still get no image :(
>>
>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which
>> we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and
>> sync are correct. But we do not know since mplayer only shows a green screen.
>
> What mplayer command line do you use? How did you set up the pipeline
> with media-ctl?
>
> On kernel.org, I have tree called camera-fw5-6 , where camera works
> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> for testing.

We did have yet another (non-DT) camera driver and media-ctl working in with 3.12.37,
but had no success yet to update it to work with modern kernels or drivers. It
is either that the (newer) drivers missing something or the media-ctl has changed.

Here is the log of our scripts with Hugues' driver and our latest setup:

root@letux:~# ./camera-demo sxga
DISPLAY=:0
XAUTHORITY=tcp
Camera: /dev/v4l-subdev8
Setting mode sxga
media-ctl -r
media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
### starting mplayer in sxga mode ###
mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team

Playing tv://.
Detected file format: TV
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski <[email protected]>
comment: first try, more to come ;-)
v4l2: ioctl get standard failed: Invalid argument
Selected device: OMAP3 ISP CCDC output
Capabilities: video capture video output streaming
supported norms:
inputs: 0 = camera;
Current input: 0
Current format: unknown (0x0)
tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
v4l2: ioctl enum norm failed: Inappropriate ioctl for device
Error: Cannot set norm!
Selected input hasn't got a tuner!
v4l2: ioctl set mute failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl streamon failed: Broken pipe
[ass] auto-open
Opening video filter: [rotate=2]
VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
[swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
VO: [x11] 1024x1280 => 1024x1280 Planar YV12
[swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from yuv420p to bgra.
Colorspace details not fully supported by selected vo.
Selected video codec: RAW UYVY [raw]
Audio: no sound
Starting playback...
V: 0.0 10/ 10 ??% ??% ??,?% 0 0 $<3>


MPlayer interrupted by signal 2 in module: filter_video
V: 0.0 11/ 11 ??% ??% ??,?% 0 0 $<3>
v4l2: ioctl set mute failed: Inappropriate ioctl for device
v4l2: 0 frames successfully processed, 0 frames dropped.

Exiting... (Quit)
root@letux:~#

BR and thanks,
Nikolaus


Attachments:
signature.asc (801.00 B)
Message signed with OpenPGP using GPGMail

2017-06-26 08:39:32

by Pavel Machek

[permalink] [raw]
Subject: Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
> Hi Pavel,
>
> > Am 25.06.2017 um 11:18 schrieb Pavel Machek <[email protected]>:
> >
> > Hi!
> >
> >> * unfortunately we still get no image :(
> >>
> >> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which
> >> we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and
> >> sync are correct. But we do not know since mplayer only shows a green screen.
> >
> > What mplayer command line do you use? How did you set up the pipeline
> > with media-ctl?
> >
> > On kernel.org, I have tree called camera-fw5-6 , where camera works
> > for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> > for testing.
>
> We did have yet another (non-DT) camera driver and media-ctl working in with 3.12.37,
> but had no success yet to update it to work with modern kernels or drivers. It
> is either that the (newer) drivers missing something or the media-ctl has changed.
>
> Here is the log of our scripts with Hugues' driver and our latest setup:
>
> root@letux:~# ./camera-demo sxga
> DISPLAY=:0
> XAUTHORITY=tcp
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'

Ok, so you are using capture, not preview.

You may want to try this one:

commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
Author: Pavel <[email protected]>
Date: Mon Feb 13 21:26:51 2017 +0100

omap3isp: fix VP2SDR bit so capture (not preview) works

This is neccessary for capture (not preview) to work properly on
N900. Why is unknown.

Pavel

> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
> name: Video 4 Linux 2 input
> author: Martin Olschewski <[email protected]>
> comment: first try, more to come ;-)
> v4l2: ioctl get standard failed: Invalid argument
> Selected device: OMAP3 ISP CCDC output
> Capabilities: video capture video output streaming
> supported norms:
> inputs: 0 = camera;
> Current input: 0
> Current format: unknown (0x0)
> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
> Error: Cannot set norm!
> Selected input hasn't got a tuner!
> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl streamon failed: Broken pipe
> [ass] auto-open
> Opening video filter: [rotate=2]
> VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from yuv420p to bgra.
> Colorspace details not fully supported by selected vo.
> Selected video codec: RAW UYVY [raw]
> Audio: no sound
> Starting playback...
> V: 0.0 10/ 10 ??% ??% ??,?% 0 0 $<3>
>
>
> MPlayer interrupted by signal 2 in module: filter_video
> V: 0.0 11/ 11 ??% ??% ??,?% 0 0 $<3>
> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: 0 frames successfully processed, 0 frames dropped.
>
> Exiting... (Quit)
> root@letux:~#
>
> BR and thanks,
> Nikolaus
>



--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (4.05 kB)
signature.asc (181.00 B)
Digital signature
Download all attachments

2017-06-26 09:54:47

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Pavel,

> Am 26.06.2017 um 10:39 schrieb Pavel Machek <[email protected]>:
>
> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>>
>>> Am 25.06.2017 um 11:18 schrieb Pavel Machek <[email protected]>:
>>>
>>> Hi!
>>>
>>>> * unfortunately we still get no image :(
>>>>
>>>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which
>>>> we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and
>>>> sync are correct. But we do not know since mplayer only shows a green screen.
>>>
>>> What mplayer command line do you use? How did you set up the pipeline
>>> with media-ctl?
>>>
>>> On kernel.org, I have tree called camera-fw5-6 , where camera works
>>> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
>>> for testing.
>>
>> We did have yet another (non-DT) camera driver and media-ctl working in with 3.12.37,
>> but had no success yet to update it to work with modern kernels or drivers. It
>> is either that the (newer) drivers missing something or the media-ctl has changed.
>>
>> Here is the log of our scripts with Hugues' driver and our latest setup:
>>
>> root@letux:~# ./camera-demo sxga
>> DISPLAY=:0
>> XAUTHORITY=tcp
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>
> Ok, so you are using capture, not preview.

Yes.

>
> You may want to try this one:
>
> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> Author: Pavel <[email protected]>
> Date: Mon Feb 13 21:26:51 2017 +0100
>
> omap3isp: fix VP2SDR bit so capture (not preview) works
>
> This is neccessary for capture (not preview) to work properly on
> N900. Why is unknown.

Ah, interesting. I will give it a try.

Do you please have a link to the repo where this commit can be found?

BR and thanks,
Nikolaus

>
> Pavel
>
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski <[email protected]>
>> comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
>> Selected device: OMAP3 ISP CCDC output
>> Capabilities: video capture video output streaming
>> supported norms:
>> inputs: 0 = camera;
>> Current input: 0
>> Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl streamon failed: Broken pipe
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> V: 0.0 10/ 10 ??% ??% ??,?% 0 0 $<3>
>>
>>
>> MPlayer interrupted by signal 2 in module: filter_video
>> V: 0.0 11/ 11 ??% ??% ??,?% 0 0 $<3>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: 0 frames successfully processed, 0 frames dropped.
>>
>> Exiting... (Quit)
>> root@letux:~#
>>
>> BR and thanks,
>> Nikolaus
>>
>
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
signature.asc (801.00 B)
Message signed with OpenPGP using GPGMail

2017-06-26 10:06:25

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus,

On 06/22/2017 05:41 PM, H. Nikolaus Schaller wrote:
>
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>>
>> This patchset enables OV9655 camera support.
>>
>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>> plugged on connector P1 of STM32F746G-DISCO board.
>> Due to lack of OV9650/52 hardware support, the modified related code
>> could not have been checked for non-regression.
>>
>> First patches upgrade current support of OV9650/52 to prepare then
>> introduction of OV9655 variant patch.
>> Because of OV9655 register set slightly different from OV9650/9652,
>> not all of the driver features are supported (controls). Supported
>> resolutions are limited to VGA, QVGA, QQVGA.
>> Supported format is limited to RGB565.
>> Controls are limited to color bar test pattern for test purpose.
>>
>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller [1].
>
> Great!
>
> I will test as soon as possible.
>

Many thanks for your active review and testing Nikolaus !

>> OV9655 registers sequences come from STM32CubeF7 embedded software [2].
>
> There is also a preliminary data sheet, e.g. here:
>
> http://electricstuff.co.uk/OV9655-datasheet-annotated.pdf

This is the datasheet I've used for registers naming and signification.

BR,
Hugues.
>
>>
>> [1] http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
>> [2] https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
>>
>> ===========
>> = history =
>> ===========
>> version 1:
>> - Initial submission.
>>
>> H. Nikolaus Schaller (1):
>> DT bindings: add bindings for ov965x camera module
>>
>> Hugues Fruchet (5):
>> [media] ov9650: add device tree support
>> [media] ov9650: select the nearest higher resolution
>> [media] ov9650: use write_array() for resolution sequences
>> [media] ov9650: add multiple variant support
>> [media] ov9650: add support of OV9655 variant
>>
>> .../devicetree/bindings/media/i2c/ov965x.txt | 37 +
>> drivers/media/i2c/Kconfig | 6 +-
>> drivers/media/i2c/ov9650.c | 792 +++++++++++++++++----
>> 3 files changed, 704 insertions(+), 131 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>
>> --
>> 1.9.1
>>
>
> BR and thanks,
> Nikolaus Schaller
>

2017-06-26 10:36:38

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module



On 06/23/2017 12:25 PM, H. Nikolaus Schaller wrote:
> Hi Hugues,
>
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>>
>> From: "H. Nikolaus Schaller" <[email protected]>
>>
>> This adds documentation of device tree bindings
>> for the OV965X family camera sensor module.
>>
>> Signed-off-by: H. Nikolaus Schaller <[email protected]>
>> Signed-off-by: Hugues Fruchet <[email protected]>
>> ---
>> .../devicetree/bindings/media/i2c/ov965x.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> new file mode 100644
>> index 0000000..0e0de1f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> @@ -0,0 +1,37 @@
>> +* Omnivision OV9650/9652/9655 CMOS sensor
>> +
>> +The Omnivision OV965x sensor support multiple resolutions output, such as
>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>> +output format.
>> +
>> +Required Properties:
>> +- compatible: should be one of
>> + "ovti,ov9650"
>> + "ovti,ov9652"
>> + "ovti,ov9655"
>> +- clocks: reference to the mclk input clock.
>
> I wonder why you have removed the clock-frequency property?
>
> In some situations the camera driver must be able to tell the clock source
> which frequency it wants to see.
>
> For example we connect the camera to an OMAP3-ISP (image signal processor) and
> there it is assumed that camera modules know the frequency and set the clock, e.g.:
>
> http://elixir.free-electrons.com/linux/v4.4/source/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt#L52
> http://elixir.free-electrons.com/linux/v3.14/source/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
>
> If your clock is constant and defined elsewhere we should make this
> property optional instead of required. But it should not be missing.
>
> Here is a hack to get it into your code:
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=b7ab46c775b9e40087e427ae0777e9f7c283694a;hp=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hb=ca85196f6fd9a77e5a0f796aeaf7aa2cde60ce91;hpb=8a71f21b75543a6d99102be1ae4677b28c478ac9
>

Here is how it is used on my DT, the camera clock is a fixed crystal 24M
clock:

+ clocks {
+ clk_ext_camera: clk-ext-camera {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ };
+ };
[...]
+ ov9655: camera@30 {
+ compatible = "ovti,ov9655";
+ reg = <0x30>;
+ pwdn-gpios = <&gpioh 13 GPIO_ACTIVE_HIGH>;
+ clocks = <&clk_ext_camera>;
+ status = "okay";
+
+ port {
+ ov9655_0: endpoint {
+ remote-endpoint = <&dcmi_0>;
+ };
+ };
+ };


>> +
>> +Optional Properties:
>> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
>> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
>
> Here I wonder why you did split that up into two gpios. Each "*-gpios" can have
> multiple entries and if one is not used, a 0 can be specified to make it being ignored.
>
> But it is up to DT maintainers what they prefer: separate single gpios or a single gpio array.

I have followed the ov2640 binding, which have the same pins naming
(resetb/pwdn).
As far as I see, separate single gpios are commonly used in
Documentation/devicetree/bindings/media/i2c/

>
>
> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
> So the driver does not power up the camera module when needed and therefore probing fails.
>
> - vana-supply: a regulator to power up the camera module.
>
> Driver code is not complex to add:
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hp=c0819afdcefcb19da351741d51dad00aaf909254;hb=8a71f21b75543a6d99102be1ae4677b28c478ac9;hpb=6db55fc472eea2ec6db03833df027aecf6649f88

Yes, I saw it in your code, but as I don't have any programmable power
supply on my setup, I have not pushed this commit.
And I also don't have a clock to enable/disable -fixed clock-, I need to
check the behaviour when disabling/enabling a fixed clock, I will give
it a try.

>
>> +
>> +The device node must contain one 'port' child node for its digital output
>> +video port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Example:
>> +
>> +&i2c2 {
>> + ov9655: camera@30 {
>> + compatible = "ovti,ov9655";
>> + reg = <0x30>;
>> + pwdn-gpios = <&gpioh 13 GPIO_ACTIVE_HIGH>;
>> + clocks = <&clk_ext_camera>;
>> +
>> + port {
>> + ov9655: endpoint {
>> + remote-endpoint = <&dcmi_0>;
>> + };
>> + };
>> + };
>> +};
>> --
>> 1.9.1
>>
>
> BR and thanks,
> Nikolaus
>

2017-06-26 11:16:26

by Pavel Machek

[permalink] [raw]
Subject: Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi!

> > You may want to try this one:
> >
> > commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> > Author: Pavel <[email protected]>
> > Date: Mon Feb 13 21:26:51 2017 +0100
> >
> > omap3isp: fix VP2SDR bit so capture (not preview) works
> >
> > This is neccessary for capture (not preview) to work properly on
> > N900. Why is unknown.
>
> Ah, interesting. I will give it a try.
>
> Do you please have a link to the repo where this commit can be
> > found?

This branch, as mentioned before:

https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/log/?h=camera-fw5-6

Pavel


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (761.00 B)
signature.asc (181.00 B)
Digital signature
Download all attachments

2017-06-26 11:49:57

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant



On 06/26/2017 08:03 AM, H. Nikolaus Schaller wrote:
>
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
>>
>> Add a first support of OV9655 variant.
>> Because of register set slightly different from OV9650/9652,
>> not all of the driver features are supported (controls).
>> Supported resolutions are limited to VGA, QVGA, QQVGA.
>> Supported format is limited to RGB565.
>> Controls are limited to color bar test pattern for test purpose.
>>
>> Signed-off-by: H. Nikolaus Schaller <[email protected]>
>> Signed-off-by: Hugues Fruchet <[email protected]>
>> ---
>> drivers/media/i2c/Kconfig | 4 +-
>> drivers/media/i2c/ov9650.c | 486 ++++++++++++++++++++++++++++++++++++++++++---
>> 2 files changed, 457 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index efea14d..a8f638c 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -594,11 +594,11 @@ config VIDEO_OV7670
>> controller.
>>
>> config VIDEO_OV9650
>> - tristate "OmniVision OV9650/OV9652 sensor support"
>> + tristate "OmniVision OV9650/OV9652/OV9655 sensor support"
>> depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>> ---help---
>> This is a V4L2 sensor-level driver for the Omnivision
>> - OV9650 and OV9652 camera sensors.
>> + OV9650 and OV9652 and OV9655 camera sensors.
>>
>> config VIDEO_VS6624
>> tristate "ST VS6624 sensor support"
>> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
>> index a9d268d..c0819af 100644
>> --- a/drivers/media/i2c/ov9650.c
>> +++ b/drivers/media/i2c/ov9650.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * Omnivision OV9650/OV9652 CMOS Image Sensor driver
>> + * Omnivision OV9650/OV9652/OV9655 CMOS Image Sensor driver
>> *
>> * Copyright (C) 2013, Sylwester Nawrocki <[email protected]>
>> *
>> @@ -7,6 +7,15 @@
>> * by Vladimir Fonov.
>> * Copyright (c) 2010, Vladimir Fonov
>> *
>> + *
>> + * Copyright (C) STMicroelectronics SA 2017
>> + * Author: Hugues Fruchet <[email protected]> for STMicroelectronics.
>> + *
>> + * OV9655 initial support based on a driver written by H. Nikolaus Schaller:
>> + * http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
>> + * OV9655 registers sequence from STM32CubeF7 embedded software, see:
>> + * https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
>> + *
>> * This program is free software; you can redistribute it and/or modify
>> * it under the terms of the GNU General Public License version 2 as
>> * published by the Free Software Foundation.
>> @@ -58,14 +67,21 @@
>> #define REG_PID 0x0a /* Product ID MSB */
>> #define REG_VER 0x0b /* Product ID LSB */
>> #define REG_COM3 0x0c
>> -#define COM3_SWAP 0x40
>> +#define COM3_COLORBAR 0x80
>> +#define COM3_RGB565 0x00
>> +#define COM3_SWAP 0x40 /* Doesn't work in RGB */
>> +#define COM3_RESETB 0x08
>> #define COM3_VARIOPIXEL1 0x04
>> +#define OV9655_SINGLEFRAME 0x01
>> #define REG_COM4 0x0d /* Vario Pixels */
>> #define COM4_VARIOPIXEL2 0x80
>> +#define OV9655_TRISTATE /* seems to have a different function */
>> #define REG_COM5 0x0e /* System clock options */
>> #define COM5_SLAVE_MODE 0x10
>> -#define COM5_SYSTEMCLOCK48MHZ 0x80
>> +#define COM5_SYSTEMCLOCK48MHZ 0x80 /* not on OV9655 */
>> +#define OV9655_EXPOSURESTEP 0x01
>> #define REG_COM6 0x0f /* HREF & ADBLC options */
>> +#define COM6_BLC_OPTICAL 0x40 /* Optical black */
>> #define REG_AECH 0x10 /* Exposure value, AEC[9:2] */
>> #define REG_CLKRC 0x11 /* Clock control */
>> #define CLK_EXT 0x40 /* Use external clock directly */
>> @@ -74,13 +90,18 @@
>> #define COM7_RESET 0x80
>> #define COM7_FMT_MASK 0x38
>> #define COM7_FMT_VGA 0x40
>> -#define COM7_FMT_CIF 0x20
>> +#define COM7_FMT_CIF 0x20
>> #define COM7_FMT_QVGA 0x10
>> #define COM7_FMT_QCIF 0x08
>> -#define COM7_RGB 0x04
>> -#define COM7_YUV 0x00
>> -#define COM7_BAYER 0x01
>> -#define COM7_PBAYER 0x05
>> +#define COM7_RGB 0x04
>> +#define COM7_YUV 0x00
>> +#define COM7_BAYER 0x01
>> +#define COM7_PBAYER 0x05
>> +#define OV9655_COM7_VGA 0x60
>> +#define OV9655_COM7_RAWRGB 0x00 /* different format encoding */
>> +#define OV9655_COM7_RAWRGBINT 0x01
>> +#define OV9655_COM7_YUV 0x02
>> +#define OV9655_COM7_RGB 0x03
>> #define REG_COM8 0x13 /* AGC/AEC options */
>> #define COM8_FASTAEC 0x80 /* Enable fast AGC/AEC */
>> #define COM8_AECSTEP 0x40 /* Unlimited AEC step size */
>> @@ -89,14 +110,23 @@
>> #define COM8_AWB 0x02 /* White balance enable */
>> #define COM8_AEC 0x01 /* Auto exposure enable */
>> #define REG_COM9 0x14 /* Gain ceiling */
>> -#define COM9_GAIN_CEIL_MASK 0x70 /* */
>> +#define COM9_GAIN_CEIL_MASK 0x70
>> +#define COM9_GAIN_CEIL_16X 0x30
>> +#define OV9655_COM9_EXPTIMING 0x08
>> +#define OV9655_COM9_VSYNCDROP 0x04
>> +#define OV9655_COM9_AECDROP 0x02
>> #define REG_COM10 0x15 /* PCLK, HREF, HSYNC signals polarity */
>> +#define OV9655_SLAVE_PIN 0x80 /* SLHS/SLVS instead of RESETB/PWDN */
>> #define COM10_HSYNC 0x40 /* HSYNC instead of HREF */
>> #define COM10_PCLK_HB 0x20 /* Suppress PCLK on horiz blank */
>> -#define COM10_HREF_REV 0x08 /* Reverse HREF */
>> +#define OV9655_COM10_PCLK_REV 0x10 /* PCLK reverse */
>> +#define COM10_HREF_REV 0x08 /* Reverse HREF */
>> #define COM10_VS_LEAD 0x04 /* VSYNC on clock leading edge */
>> +#define OV9655_COM10_RESET_OPTION 0x04 /* Reset signal end point */
>> #define COM10_VS_NEG 0x02 /* VSYNC negative */
>> #define COM10_HS_NEG 0x01 /* HSYNC negative */
>> +#define OV9655_REG16 0x16 /* dummy frame and blanking */
>> +#define OV9655_REG16_DUMMY_8 0x20 /* dummy frame when gain > 8 */
>> #define REG_HSTART 0x17 /* Horiz start high bits */
>> #define REG_HSTOP 0x18 /* Horiz stop high bits */
>> #define REG_VSTART 0x19 /* Vert start high bits */
>> @@ -117,6 +147,7 @@
>> #define REG_BBIAS 0x27 /* B channel output bias */
>> #define REG_GBBIAS 0x28 /* Gb channel output bias */
>> #define REG_GRCOM 0x29 /* Analog BLC & regulator */
>> +#define OV9655_PREGAIN 0x29
>> #define REG_EXHCH 0x2a /* Dummy pixel insert MSB */
>> #define REG_EXHCL 0x2b /* Dummy pixel insert LSB */
>> #define REG_RBIAS 0x2c /* R channel output bias */
>> @@ -127,12 +158,30 @@
>> #define REG_HSYEN 0x31 /* HSYNC falling edge delay LSB*/
>> #define REG_HREF 0x32 /* HREF pieces */
>> #define REG_CHLF 0x33 /* reserved */
>> +#define OV9655_CLKF 0x33 /* Array current control */
>> +#define OV9655_AREF1 0x34 /* Array reference control */
>> +#define OV9655_AREF2 0x35 /* Array reference control */
>> +#define OV9655_AREF3 0x36 /* Array reference control */
>> #define REG_ADC 0x37 /* reserved */
>> +#define OV9655_ADC 0x37 /* ADC Control 1 (Range adjustment) */
>> #define REG_ACOM 0x38 /* reserved */
>> -#define REG_OFON 0x39 /* Power down register */
>> +#define OV9655_ADC2 0x38 /* ADC Control 2 (Range adjustment) */
>> +#define REG_OFON 0x39 /* Power down register (ov9650 only) */
>> #define OFON_PWRDN 0x08 /* Power down bit */
>> +#define OV9655_AREF4 0x39 /* Array reference control */
>> #define REG_TSLB 0x3a /* YUVU format */
>> +#define OV9655_PCLKDELAY2NS 0x40
>> +#define OV9655_PCLKDELAY4NS 0x80
>> +#define OV9655_PCLKDELAY6NS 0xc0
>> +#define OV9655_OUTREVERSE 0x20
>> +#define OV9655_FIXEDUV 0x10
>> #define TSLB_YUYV_MASK 0x0c /* UYVY or VYUY - see com13 */
>> +#define TSLB_YUYV 0x00
>> +#define TSLB_YVYU 0x04
>> +#define TSLB_VYUY 0x08
>> +#define TSLB_UYVY 0x0c
>> +#define OV9655_BANDINGAUTO 0x02
>> +
>> #define REG_COM11 0x3b /* Night mode, banding filter enable */
>> #define COM11_NIGHT 0x80 /* Night mode enable */
>> #define COM11_NMFR 0x60 /* Two bit NM frame rate */
>> @@ -142,25 +191,38 @@
>> #define COM12_HREF 0x80 /* HREF always */
>> #define REG_COM13 0x3d /* Gamma selection, Color matrix en. */
>> #define COM13_GAMMA 0x80 /* Gamma enable */
>> -#define COM13_UVSAT 0x40 /* UV saturation auto adjustment */
>> +#define COM13_UVSAT 0x40 /* UV saturation auto adjustment */
>> +#define COM13_Y_DELAY 0x08 /* Delay Y channel */
>> #define COM13_UVSWAP 0x01 /* V before U - w/TSLB */
>> #define REG_COM14 0x3e /* Edge enhancement options */
>> #define COM14_EDGE_EN 0x02
>> #define COM14_EEF_X2 0x01
>> +#define OV9655_REG_COM14 0x3e /* pixel correction/zoom ON/OFF sel. */
>> +#define OV9655_COM14_BLACK_PIX 0x08 /* Black pixel correction */
>> +#define OV9655_COM14_WHITE_PIX 0x04 /* White pixel correction */
>> +#define OV9655_COM14_ZOOM 0x02 /* Zoom function ON */
>> #define REG_EDGE 0x3f /* Edge enhancement factor */
>> #define EDGE_FACTOR_MASK 0x0f
>> #define REG_COM15 0x40 /* Output range, RGB 555/565 */
>> #define COM15_R10F0 0x00 /* Data range 10 to F0 */
>> -#define COM15_R01FE 0x80 /* 01 to FE */
>> +#define COM15_R01FE 0x80 /* 01 to FE */
>> #define COM15_R00FF 0xc0 /* 00 to FF */
>> #define COM15_RGB565 0x10 /* RGB565 output */
>> #define COM15_RGB555 0x30 /* RGB555 output */
>> #define COM15_SWAPRB 0x04 /* Swap R&B */
>> #define REG_COM16 0x41 /* Color matrix coeff options */
>> #define REG_COM17 0x42 /* Single frame out, banding filter */
>> +#define OV9655_REG_COM17 0x42 /* Denoise, edge, auto gain, ... */
>> +#define OV9655_COM17_EDGE_AUTO 0x40 /* Edge auto */
>> +#define OV9655_COM17_DENOISE_AUTO 0x80 /* Denoise auto */
>> +#define OV9655_REG_RSVD(__n) (0x43 + (__n) - 1) /* reserved but used... */
>> /* n = 1...9, 0x4f..0x57 */
>> -#define REG_MTX(__n) (0x4f + (__n) - 1)
>> +#define REG_MTX(__n) (0x4f + (__n) - 1)
>> #define REG_MTXS 0x58
>> +#define REG_AWBOP(__n) (0x59 + (__n) - 1) /* AWB control options */
>> +#define REG_BLMT 0x5F /* AWB Blue Component Gain Limit */
>> +#define REG_RLMT 0x60 /* AWB Red Component Gain Limit */
>> +#define REG_GLMT 0x61 /* AWB Green Component Gain Limit */
>> /* Lens Correction Option 1...5, __n = 0...5 */
>> #define REG_LCC(__n) (0x62 + (__n) - 1)
>> #define LCC5_LCC_ENABLE 0x01 /* LCC5, enable lens correction */
>> @@ -170,10 +232,26 @@
>> #define REG_HV 0x69 /* Manual banding filter MSB */
>> #define REG_MBD 0x6a /* Manual banding filter value */
>> #define REG_DBLV 0x6b /* reserved */
>> +#define OV9655_REG_DBLV 0x6b /* PLL, DVDD regu bypass, bandgap */
>> +#define OV9655_DBLV_BANDGAP 0x0a /* default value */
>> +#define OV9655_DBLV_LDO_BYPASS 0x10
>> +#define OV9655_DBLV_PLL_BYPASS 0x00
>> +#define OV9655_DBLV_PLL_4X 0x40
>> +#define OV9655_DBLV_PLL_6X 0x80
>> +#define OV9655_DBLV_PLL_8X 0xc0
>> #define REG_GSP 0x6c /* Gamma curve */
>> #define GSP_LEN 15
>> +#define OV9655_REG_DNSTH 0x70 /* De-noise Function Threshold Adj. */
>> +#define OV9655_REG_POIDX 0x72 /* Pixel output index */
>> +#define OV9655_REG_PCKDV 0x73 /* Pixel Clock Output Selection */
>> +#define OV9655_REG_XINDX 0x74 /* Horizontal Scaling Down Coeff. */
>> +#define OV9655_REG_YINDX 0x75 /* Vertical Scaling Down Coeff. */
>> +#define OV9655_REG_SLOP 0x7A /* Gamma Curve Highest Segment Slope */
>> +#define OV9655_REG_GAM(__n) (0x7B + (__n) - 1) /* Gamma curve */
>> #define REG_GST 0x7c /* Gamma curve */
>> #define GST_LEN 15
>> +#define OV9655_REG_COM18 0x8b /* Zoom mode in VGA */
>> +#define OV9655_REG_COM19 0x8c /* UV adjustment */
>> #define REG_COM21 0x8b
>> #define REG_COM22 0x8c /* Edge enhancement, denoising */
>> #define COM22_WHTPCOR 0x02 /* White pixel correction enable */
>> @@ -181,6 +259,8 @@
>> #define COM22_DENOISE 0x10 /* White pixel correction option */
>> #define REG_COM23 0x8d /* Color bar test, color gain */
>> #define COM23_TEST_MODE 0x10
>> +#define OV9655_REG_COM20 0x8d
>> +#define OV9655_COM20_TEST_MODE 0x10
>> #define REG_DBLC1 0x8f /* Digital BLC */
>> #define REG_DBLC_B 0x90 /* Digital BLC B channel offset */
>> #define REG_DBLC_R 0x91 /* Digital BLC R channel offset */
>> @@ -193,6 +273,17 @@
>> #define REG_AECHM 0xa1 /* Exposure value - bits AEC[15:10] */
>> #define REG_BD50ST 0xa2 /* Banding filter value for 50Hz */
>> #define REG_BD60ST 0xa3 /* Banding filter value for 60Hz */
>> +#define OV9655_REG_COM21 0xa4 /* Digital gain */
>> +#define OV9655_REG_AWB_GREEN 0xa6 /* AWB green */
>> +#define OV9655_REG_REF_A8 0xa8 /* Analog Reference Control */
>> +#define OV9655_REG_REF_A9 0xa9 /* Analog Reference Control */
>> +#define OV9655_REG_BLC(__n) (0xac + (__n) - 1) /* Black Level Control */
>> +#define OV9655_REG_CTRLB4 0xb4 /* UV adjustment */
>> +#define OV9655_REG_ADBOFF 0xbc /* ADC B channel offset setting */
>> +#define OV9655_REG_ADROFF 0xbd /* ADC R channel offset setting */
>> +#define OV9655_REG_ADGBOFF 0xbe /* ADC Gb channel offset setting */
>> +#define OV9655_REG_ADGEOFF 0xbf /* ADC Gr channel offset setting */
>> +#define OV9655_REG_COM24 0xc7 /* Pixel clock frequency selection */
>> #define REG_NULL 0xff /* Array end token */
>>
>> #define DEF_CLKRC 0x80
>> @@ -200,6 +291,7 @@
>> #define OV965X_ID(_msb, _lsb) ((_msb) << 8 | (_lsb))
>> #define OV9650_ID 0x9650
>> #define OV9652_ID 0x9652
>> +#define OV9655V5_ID 0x9657
>>
>> struct ov965x_ctrls {
>> struct v4l2_ctrl_handler handler;
>> @@ -458,6 +550,292 @@ struct ov965x_pixfmt {
>> {{ 1, 25 }, { QVGA_WIDTH, QVGA_HEIGHT }, 1 }, /* 25 fps */
>> };
>>
>> +/* OV9655 */
>> +static const struct i2c_rv ov9655_init_regs[] = {
>> + { REG_GAIN, 0x00 },
>> + { REG_BLUE, 0x80 },
>> + { REG_RED, 0x80 },
>> + { REG_VREF, 0x02 },
>> + { REG_COM1, 0x03 },
>> + { REG_COM2, 0x01 },/* Output drive x2 */
>> + { REG_COM3, COM3_RGB565 },/* Output drive x2, RGB565 */
>> + { REG_COM5, 0x60 | OV9655_EXPOSURESTEP },/* 0x60 ? */
>> + { REG_COM6, COM6_BLC_OPTICAL },
>> + { REG_CLKRC, 0x01 },/* F(internal clk) = F(input clk) / 2 */
>> + { REG_COM7, OV9655_COM7_VGA | OV9655_COM7_YUV },
>> + { REG_COM8, COM8_FASTAEC | COM8_AECSTEP |
>> + COM8_AGC | COM8_AWB | COM8_AEC },
>> + { REG_COM9, COM9_GAIN_CEIL_16X | OV9655_COM9_EXPTIMING |
>> + OV9655_COM9_AECDROP },
>> + { OV9655_REG16, OV9655_REG16_DUMMY_8 | 0x4 },
>> + { REG_HSTART, 0x18 },
>> + { REG_HSTOP, 0x04 },
>> + { REG_VSTART, 0x01 },
>> + { REG_VSTOP, 0x81 },
>> + { REG_MVFP, 0x00 },/* No mirror/flip */
>> + { REG_AEW, 0x3c },
>> + { REG_AEB, 0x36 },
>> + { REG_VPT, 0x72 },
>> + { REG_BBIAS, 0x08 },
>> + { REG_GBBIAS, 0x08 },
>> + { OV9655_PREGAIN, 0x15 },
>> + { REG_EXHCH, 0x00 },
>> + { REG_EXHCL, 0x00 },
>> + { REG_RBIAS, 0x08 },
>> + { REG_HREF, 0x12 },/* QVGA */
>> + { REG_CHLF, 0x00 },
>> + { OV9655_AREF1, 0x3f },
>> + { OV9655_AREF2, 0x00 },
>> + { OV9655_AREF3, 0x3a },
>> + { OV9655_ADC2, 0x72 },
>> + { OV9655_AREF4, 0x57 },
>> + { REG_TSLB, OV9655_PCLKDELAY6NS | TSLB_UYVY },
>> + { REG_COM11, 0x04 },/* 0x04 ? */
>> + { REG_COM13, COM13_GAMMA | 0x10 |
>> + COM13_Y_DELAY | COM13_UVSWAP },/* 0x10 ? */
>> + {OV9655_REG_COM14, OV9655_COM14_ZOOM }, /* QVGA */
>> + { REG_EDGE, 0xc1 },
>> + { REG_COM15, COM15_R00FF },/* Full range output */
>> + { REG_COM16, 0x41 },/* 0x41 ? */
>> + { OV9655_REG_COM17, OV9655_COM17_EDGE_AUTO |
>> + OV9655_COM17_DENOISE_AUTO },
>> + { OV9655_REG_RSVD(1), 0x0a },
>> + { OV9655_REG_RSVD(2), 0xf0 },
>> + { OV9655_REG_RSVD(3), 0x46 },
>> + { OV9655_REG_RSVD(4), 0x62 },
>> + { OV9655_REG_RSVD(5), 0x2a },
>> + { OV9655_REG_RSVD(6), 0x3c },
>> + { OV9655_REG_RSVD(7), 0xfc },
>> + { OV9655_REG_RSVD(8), 0xfc },
>> + { OV9655_REG_RSVD(9), 0x7f },
>> + { OV9655_REG_RSVD(10), 0x7f },
>> + { OV9655_REG_RSVD(11), 0x7f },
>> + { REG_MTX(1), 0x98 },
>> + { REG_MTX(2), 0x98 },
>> + { REG_MTX(3), 0x00 },
>> + { REG_MTX(4), 0x28 },
>> + { REG_MTX(5), 0x70 },
>> + { REG_MTX(6), 0x98 },
>> + { REG_MTXS, 0x1a },
>> + { REG_AWBOP(1), 0x85 },
>> + { REG_AWBOP(2), 0xa9 },
>> + { REG_AWBOP(3), 0x64 },
>> + { REG_AWBOP(4), 0x84 },
>> + { REG_AWBOP(5), 0x53 },
>> + { REG_AWBOP(6), 0x0e },
>> + { REG_BLMT, 0xf0 },
>> + { REG_RLMT, 0xf0 },
>> + { REG_GLMT, 0xf0 },
>> + { REG_LCC(1), 0x00 },
>> + { REG_LCC(2), 0x00 },
>> + { REG_LCC(3), 0x02 },
>> + { REG_LCC(4), 0x20 },
>> + { REG_LCC(5), 0x00 },
>> + { 0x69, 0x0a },/* Reserved... */
>> + { OV9655_REG_DBLV, OV9655_DBLV_PLL_4X | OV9655_DBLV_LDO_BYPASS |
>> + OV9655_DBLV_BANDGAP },
>> + { 0x6c, 0x04 },/* Reserved... */
>> + { 0x6d, 0x55 },/* Reserved... */
>> + { 0x6e, 0x00 },/* Reserved... */
>> + { 0x6f, 0x9d },/* Reserved... */
>> + { OV9655_REG_DNSTH, 0x21 },
>> + { 0x71, 0x78 },/* Reserved... */
>> + { OV9655_REG_POIDX, 0x11 },/* QVGA */
>> + { OV9655_REG_PCKDV, 0x01 },/* QVGA */
>> + { OV9655_REG_XINDX, 0x10 },
>> + { OV9655_REG_YINDX, 0x10 },
>> + { 0x76, 0x01 },/* Reserved... */
>> + { 0x77, 0x02 },/* Reserved... */
>> + { 0x7A, 0x12 },/* Reserved... */
>> + { OV9655_REG_GAM(1), 0x08 },
>> + { OV9655_REG_GAM(2), 0x16 },
>> + { OV9655_REG_GAM(3), 0x30 },
>> + { OV9655_REG_GAM(4), 0x5e },
>> + { OV9655_REG_GAM(5), 0x72 },
>> + { OV9655_REG_GAM(6), 0x82 },
>> + { OV9655_REG_GAM(7), 0x8e },
>> + { OV9655_REG_GAM(8), 0x9a },
>> + { OV9655_REG_GAM(9), 0xa4 },
>> + { OV9655_REG_GAM(10), 0xac },
>> + { OV9655_REG_GAM(11), 0xb8 },
>> + { OV9655_REG_GAM(12), 0xc3 },
>> + { OV9655_REG_GAM(13), 0xd6 },
>> + { OV9655_REG_GAM(14), 0xe6 },
>> + { OV9655_REG_GAM(15), 0xf2 },
>> + { 0x8a, 0x24 },/* Reserved... */
>> + { OV9655_REG_COM19, 0x80 },
>> + { 0x90, 0x7d },/* Reserved... */
>> + { 0x91, 0x7b },/* Reserved... */
>> + { REG_LCCFB, 0x02 },
>> + { REG_LCCFR, 0x02 },
>> + { REG_DBLC_GB, 0x7a },
>> + { REG_DBLC_GR, 0x79 },
>> + { REG_AECHM, 0x40 },
>> + { OV9655_REG_COM21, 0x50 },
>> + { 0xa5, 0x68 },/* Reserved... */
>> + { OV9655_REG_AWB_GREEN, 0x4a },
>> + { OV9655_REG_REF_A8, 0xc1 },
>> + { OV9655_REG_REF_A9, 0xef },
>> + { 0xaa, 0x92 },/* Reserved... */
>> + { 0xab, 0x04 },/* Reserved... */
>> + { OV9655_REG_BLC(1), 0x80 },
>> + { OV9655_REG_BLC(2), 0x80 },
>> + { OV9655_REG_BLC(3), 0x80 },
>> + { OV9655_REG_BLC(4), 0x80 },
>> + { OV9655_REG_BLC(7), 0xf2 },
>> + { OV9655_REG_BLC(8), 0x20 },
>> + { OV9655_REG_CTRLB4, 0x20 },
>> + { 0xb5, 0x00 },/* Reserved... */
>> + { 0xb6, 0xaf },/* Reserved... */
>> + { 0xb6, 0xaf },/* Reserved... */
>> + { 0xbb, 0xae },/* Reserved... */
>> + { OV9655_REG_ADBOFF, 0x7f },
>> + { OV9655_REG_ADROFF, 0x7f },
>> + { OV9655_REG_ADGBOFF, 0x7f },
>> + { OV9655_REG_ADGEOFF, 0x7f },
>> + { OV9655_REG_ADGEOFF, 0x7f },
>> + { 0xc0, 0xaa },/* Reserved... */
>> + { 0xc1, 0xc0 },/* Reserved... */
>> + { 0xc2, 0x01 },/* Reserved... */
>> + { 0xc3, 0x4e },/* Reserved... */
>> + { 0xc6, 0x05 },/* Reserved... */
>> + { OV9655_REG_COM24, 0x81 },/* QVGA */
>> + { 0xc9, 0xe0 },/* Reserved... */
>> + { 0xca, 0xe8 },/* Reserved... */
>> + { 0xcb, 0xf0 },/* Reserved... */
>> + { 0xcc, 0xd8 },/* Reserved... */
>> + { 0xcd, 0x93 },/* Reserved... */
>> + { REG_COM7, OV9655_COM7_VGA | OV9655_COM7_RGB },
>> + { REG_COM15, COM15_RGB565 },
>> + { REG_NULL, 0}
>> +};
>> +
>> +static const struct i2c_rv ov9655_qvga_regs[] = {
>> + { REG_HREF, 0x12 },
>> + { OV9655_REG_COM14, OV9655_COM14_ZOOM },
>> + { OV9655_REG_POIDX, 0x11 },
>> + { OV9655_REG_PCKDV, 0x01 },
>> + { OV9655_REG_COM24, 0x81 },
>> + { REG_NULL, 0}
>> +};
>> +
>> +static const struct i2c_rv ov9655_qqvga_regs[] = {
>> + { REG_HREF, 0xa4 },
>> + { REG_COM14, OV9655_COM14_BLACK_PIX | OV9655_COM14_WHITE_PIX |
>> + OV9655_COM14_ZOOM },
>> + { OV9655_REG_POIDX, 0x22 },
>> + { OV9655_REG_PCKDV, 0x02 },
>> + { OV9655_REG_COM24, 0x82 },
>> + { REG_NULL, 0}
>> +};
>> +
>> +static const struct i2c_rv ov9655_vga_regs[] = {
>> + { REG_GAIN, 0x11 },
>> + { REG_VREF, 0x12 },
>> + { REG_B_AVE, 0x2e },
>> + { REG_GB_AVE, 0x2e },
>> + { REG_GR_AVE, 0x2e },
>> + { REG_R_AVE, 0x2e },
>> + { REG_COM6, 0x48 },
>> + { REG_AECH, 0x7b },
>> + { REG_CLKRC, 0x03 },
>> + { REG_COM8, COM8_FASTAEC | COM8_AECSTEP | COM8_BFILT |
>> + COM8_AGC | COM8_AWB | COM8_AEC },
>> + { REG_HSTART, 0x16 },
>> + { REG_HSTOP, 0x02 },
>> + { REG_VSTART, 0x01 },
>> + { REG_VSTOP, 0x3d },
>> + { REG_MVFP, 0x04 },
>> + { REG_YAVE, 0x2e },
>> + { REG_HREF, 0xff },
>> + { OV9655_AREF1, 0x3d },
>> + { OV9655_AREF3, 0xfa },
>> + { REG_TSLB, 0xcc },
>> + { REG_COM11, 0xcc },
>> + { REG_COM14, 0x0c },
>> + { REG_EDGE, 0x82 },
>> + { REG_COM15, COM15_R00FF | COM15_RGB565 },/* full range */
>> + { REG_COM16, 0x40 },
>> + { OV9655_REG_RSVD(1), 0x14 },
>> + { OV9655_REG_RSVD(2), 0xf0 },
>> + { OV9655_REG_RSVD(3), 0x46 },
>> + { OV9655_REG_RSVD(4), 0x62 },
>> + { OV9655_REG_RSVD(5), 0x2a },
>> + { OV9655_REG_RSVD(6), 0x3c },
>> + { OV9655_REG_RSVD(8), 0xe9 },
>> + { OV9655_REG_RSVD(9), 0xdd },
>> + { OV9655_REG_RSVD(10), 0xdd },
>> + { OV9655_REG_RSVD(11), 0xdd },
>> + { OV9655_REG_RSVD(12), 0xdd },
>> + { REG_LCC(1), 0x00 },
>> + { REG_LCC(2), 0x00 },
>> + { REG_LCC(3), 0x02 },
>> + { REG_LCC(4), 0x20 },
>> + { REG_LCC(5), 0x01 },
>> + { REG_GSP, 0x0c },
>> + { 0x6f, 0x9e },/* Reserved... */
>> + { OV9655_REG_DNSTH, 0x06 },
>> + { OV9655_REG_POIDX, 0x00 },
>> + { OV9655_REG_PCKDV, 0x00 },
>> + { OV9655_REG_XINDX, 0x3a },
>> + { OV9655_REG_YINDX, 0x35 },
>> + { OV9655_REG_SLOP, 0x20 },
>> + { OV9655_REG_GAM(1), 0x1c },
>> + { OV9655_REG_GAM(2), 0x28 },
>> + { OV9655_REG_GAM(3), 0x3c },
>> + { OV9655_REG_GAM(4), 0x5a },
>> + { OV9655_REG_GAM(5), 0x68 },
>> + { OV9655_REG_GAM(6), 0x76 },
>> + { OV9655_REG_GAM(7), 0x80 },
>> + { OV9655_REG_GAM(8), 0x88 },
>> + { OV9655_REG_GAM(9), 0x8f },
>> + { OV9655_REG_GAM(10), 0x96 },
>> + { OV9655_REG_GAM(11), 0xa3 },
>> + { OV9655_REG_GAM(12), 0xaf },
>> + { OV9655_REG_GAM(13), 0xc4 },
>> + { OV9655_REG_GAM(14), 0xd7 },
>> + { OV9655_REG_GAM(15), 0xe8 },
>> + { 0x8a, 0x23 },/* Reserved... */
>> + { OV9655_REG_COM19, 0x8d },
>> + { 0x90, 0x92 },/* Reserved... */
>> + { 0x91, 0x92 },/* Reserved... */
>> + { REG_DBLC_GB, 0x90 },
>> + { REG_DBLC_GR, 0x90 },
>> + { OV9655_REG_AWB_GREEN, 0x40 },
>> + { OV9655_REG_ADBOFF, 0x02 },
>> + { OV9655_REG_ADROFF, 0x01 },
>> + { OV9655_REG_ADGBOFF, 0x02 },
>> + { OV9655_REG_ADGEOFF, 0x01 },
>> + { 0xc1, 0xc8 },/* Reserved... */
>> + { 0xc6, 0x85 },/* Reserved... */
>> + { OV9655_REG_COM24, 0x80 },
>> + { REG_NULL, 0}
>> +};
>> +
>> +static const struct ov965x_framesize ov9655_framesizes[] = {
>> + {
>> + .width = VGA_WIDTH,
>> + .height = VGA_HEIGHT,
>> + .regs = ov9655_vga_regs,
>> + .max_exp_lines = 498,
>> + }, {
>> + .width = QVGA_WIDTH,
>> + .height = QVGA_HEIGHT,
>> + .regs = ov9655_qvga_regs,
>> + .max_exp_lines = 248,
>> + },
>> + {
>> + .width = QQVGA_WIDTH,
>> + .height = QQVGA_HEIGHT,
>> + .regs = ov9655_qqvga_regs,
>> + .max_exp_lines = 124,
>> + },
>> +};
>> +
>> +static const struct ov965x_pixfmt ov9655_formats[] = {
>> + { MEDIA_BUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB, 0x08},
>> +};
>> +
>> static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
>> {
>> return &container_of(ctrl->handler, struct ov965x, ctrls.handler)->sd;
>> @@ -894,12 +1272,16 @@ static int ov965x_set_test_pattern(struct ov965x *ov965x, int value)
>> {
>> int ret;
>> u8 reg;
>> + u8 addr = (ov965x->id == OV9655V5_ID) ?
>> + REG_COM3 : REG_COM23;
>> + u8 mask = (ov965x->id == OV9655V5_ID) ?
>> + COM3_COLORBAR : COM23_TEST_MODE;
>>
>> - ret = ov965x_read(ov965x->client, REG_COM23, &reg);
>> + ret = ov965x_read(ov965x->client, addr, &reg);
>> if (ret < 0)
>> return ret;
>> - reg = value ? reg | COM23_TEST_MODE : reg & ~COM23_TEST_MODE;
>> - return ov965x_write(ov965x->client, REG_COM23, reg);
>> + reg = value ? reg | mask : reg & ~mask;
>> + return ov965x_write(ov965x->client, addr, reg);
>> }
>>
>> static int __g_volatile_ctrl(struct ov965x *ov965x, struct v4l2_ctrl *ctrl)
>> @@ -1102,6 +1484,30 @@ static int ov965x_initialize_controls(struct ov965x *ov965x)
>> return 0;
>> }
>>
>> +static int ov9655_initialize_controls(struct ov965x *ov965x)
>> +{
>> + const struct v4l2_ctrl_ops *ops = &ov965x_ctrl_ops;
>> + struct ov965x_ctrls *ctrls = &ov965x->ctrls;
>> + struct v4l2_ctrl_handler *hdl = &ctrls->handler;
>> + int ret;
>> +
>> + ret = v4l2_ctrl_handler_init(hdl, 16);
>> + if (ret < 0)
>> + return ret;
>> +
>> + v4l2_ctrl_new_std_menu_items(hdl, ops, V4L2_CID_TEST_PATTERN,
>> + ARRAY_SIZE(test_pattern_menu) - 1, 0, 0,
>> + test_pattern_menu);
>> + if (hdl->error) {
>> + ret = hdl->error;
>> + v4l2_ctrl_handler_free(hdl);
>> + return ret;
>> + }
>> +
>> + ov965x->sd.ctrl_handler = hdl;
>> + return 0;
>> +}
>> +
>> /*
>> * V4L2 subdev video and pad level operations
>> */
>> @@ -1518,9 +1924,15 @@ static int ov965x_detect_sensor(struct v4l2_subdev *sd)
>>
>> if (!ret) {
>> ov965x->id = OV965X_ID(pid, ver);
>> - if (ov965x->id == OV9650_ID || ov965x->id == OV9652_ID) {
>> + switch (ov965x->id) {
>> + case OV9650_ID:
>> + case OV9652_ID:
>> v4l2_info(sd, "Found OV%04X sensor\n", ov965x->id);
>> - } else {
>> + break;
>> + case OV9655V5_ID:
>> + v4l2_info(sd, "Found OV%04X sensor\n", ov965x->id - 2);
>> + break;
>> + default:
>> v4l2_err(sd, "Sensor detection failed (%04X, %d)\n",
>> ov965x->id, ret);
>> ret = -ENODEV;
>> @@ -1598,18 +2010,28 @@ static int ov965x_probe(struct i2c_client *client,
>> if (ret < 0)
>> goto err_me;
>>
>> - ov965x->init_regs = ov965x_init_regs;
>> - ov965x->initialize_controls = ov965x_initialize_controls;
>> - ov965x->framesizes = ov965x_framesizes;
>> - ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
>> - ov965x->formats = ov965x_formats;
>> - ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
>> - ov965x->intervals = ov965x_intervals;
>> - ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
>> - ov965x->fiv = &ov965x_intervals[0];
>> - ov965x->set_frame_interval = __ov965x_set_frame_interval;
>> - ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
>> - ov965x->set_params = __ov965x_set_params;
>> + if (ov965x->id != OV9655V5_ID) {
>> + ov965x->init_regs = ov965x_init_regs;
>> + ov965x->initialize_controls = ov965x_initialize_controls;
>> + ov965x->framesizes = ov965x_framesizes;
>> + ov965x->nb_of_framesizes = ARRAY_SIZE(ov965x_framesizes);
>> + ov965x->formats = ov965x_formats;
>> + ov965x->nb_of_formats = ARRAY_SIZE(ov965x_formats);
>> + ov965x->intervals = ov965x_intervals;
>> + ov965x->nb_of_intervals = ARRAY_SIZE(ov965x_intervals);
>> + ov965x->fiv = &ov965x_intervals[0];
>> + ov965x->set_frame_interval = __ov965x_set_frame_interval;
>> + ov965x->update_exposure_ctrl = ov965x_update_exposure_ctrl;
>> + ov965x->set_params = __ov965x_set_params;
>> + } else {
>> + ov965x->init_regs = ov9655_init_regs;
>> + ov965x->initialize_controls = ov9655_initialize_controls;
>> + ov965x->framesizes = ov9655_framesizes;
>> + ov965x->nb_of_framesizes = ARRAY_SIZE(ov9655_framesizes);
>> + ov965x->formats = ov9655_formats;
>> + ov965x->nb_of_formats = ARRAY_SIZE(ov9655_formats);
>> + ov965x->set_params = ov965x_set_frame_size;
>> + };
>>
>> ov965x->frame_size = &ov965x->framesizes[0];
>> ov965x_get_default_format(ov965x, &ov965x->format);
>> @@ -1652,6 +2074,7 @@ static int ov965x_remove(struct i2c_client *client)
>> static const struct i2c_device_id ov965x_id[] = {
>> { "OV9650", 0x9650 },
>> { "OV9652", 0x9652 },
>> + { "OV9655", 0x9655 },
>
> i2c device ids should be lower case to match compatible-strings in DT for
> automatic modprobing.
>
> Please pick/merge/copy&paste
>
> <http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=c310cbee131665893d2d1df0ab1246bd9b1d41fe;hp=ed5d0a53a9c72036d6e017094b68111b5eb7f00d;hb=115b9c59202aa2fb1fecb691ebeef51220d363b8;hpb=da8ae2b038a448c8f822b3a4f20ed378db6d2934>
>
> With this change I get:
>
> root@letux:~# dmesg|fgrep ov96
> [ 12.727600] ov965x: Found OV9655 sensor
> [ 12.747711] ov965x 1-0030: ov965x driver probed
> root@letux:~#
>
> during probe.
>

Thanks for patch, I'll fix in v2 !

>> { /* sentinel */ }
>> };
>> MODULE_DEVICE_TABLE(i2c, ov965x_id);
>> @@ -1659,6 +2082,7 @@ static int ov965x_remove(struct i2c_client *client)
>> static const struct of_device_id ov965x_of_match[] = {
>> { .compatible = "ovti,ov9650", .data = (void *)0x9650 },
>> { .compatible = "ovti,ov9652", .data = (void *)0x9652 },
>> + { .compatible = "ovti,ov9655", .data = (void *)0x9655 },
>> { /* sentinel */ }
>> };
>> MODULE_DEVICE_TABLE(of, ov965x_of_match);
>> --
>> 1.9.1
>>
>

2017-06-26 13:20:14

by Hugues Fruchet

[permalink] [raw]
Subject: Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

Nikolaus,
some comments about pixel format/resolution below:

On 06/26/2017 10:39 AM, Pavel Machek wrote:
> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>>
>>> Am 25.06.2017 um 11:18 schrieb Pavel Machek <[email protected]>:
>>>
>>> Hi!
>>>
>>>> * unfortunately we still get no image :(
>>>>
>>>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which
>>>> we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and
>>>> sync are correct. But we do not know since mplayer only shows a green screen.
>>>
>>> What mplayer command line do you use? How did you set up the pipeline
>>> with media-ctl?
>>>
>>> On kernel.org, I have tree called camera-fw5-6 , where camera works
>>> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
>>> for testing.
>>
>> We did have yet another (non-DT) camera driver and media-ctl working in with 3.12.37,
>> but had no success yet to update it to work with modern kernels or drivers. It
>> is either that the (newer) drivers missing something or the media-ctl has changed.
>>
>> Here is the log of our scripts with Hugues' driver and our latest setup:
>>
>> root@letux:~# ./camera-demo sxga
>> DISPLAY=:0
>> XAUTHORITY=tcp
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>
> Ok, so you are using capture, not preview.
>
> You may want to try this one:
>
> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> Author: Pavel <[email protected]>
> Date: Mon Feb 13 21:26:51 2017 +0100
>
> omap3isp: fix VP2SDR bit so capture (not preview) works
>
> This is neccessary for capture (not preview) to work properly on
> N900. Why is unknown.
>
> Pavel
>
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11

=> "outfmt=uyvy:width=1280:height=1024"

Nikolaus,
Be careful that only VGA/RGB565 is coded in this basic version of OV9655,
perhaps this explain partly your troubles ?

>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski <[email protected]>
>> comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
>> Selected device: OMAP3 ISP CCDC output
>> Capabilities: video capture video output streaming
>> supported norms:
>> inputs: 0 = camera;
>> Current input: 0
>> Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl streamon failed: Broken pipe
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> V: 0.0 10/ 10 ??% ??% ??,?% 0 0 $<3>
>>
>>
>> MPlayer interrupted by signal 2 in module: filter_video
>> V: 0.0 11/ 11 ??% ??% ??,?% 0 0 $<3>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: 0 frames successfully processed, 0 frames dropped.
>>
>> Exiting... (Quit)
>> root@letux:~#
>>
>> BR and thanks,
>> Nikolaus
>>
>
>
>

2017-06-26 16:31:54

by Sakari Ailus

[permalink] [raw]
Subject: Re: [PATCH v1 2/6] [media] ov9650: add device tree support

Hi Hugues,

On Thu, Jun 22, 2017 at 05:05:38PM +0200, Hugues Fruchet wrote:
> @@ -1545,15 +1577,22 @@ static int ov965x_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id ov965x_id[] = {
> - { "OV9650", 0 },
> - { "OV9652", 0 },
> + { "OV9650", 0x9650 },
> + { "OV9652", 0x9652 },

This change does not appear to match with the patch description nor it the
information is used. How about not changing it, unless there's a reason to?
The same for the data field of the of_device_id array below.

> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(i2c, ov965x_id);
>
> +static const struct of_device_id ov965x_of_match[] = {
> + { .compatible = "ovti,ov9650", .data = (void *)0x9650 },
> + { .compatible = "ovti,ov9652", .data = (void *)0x9652 },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, ov965x_of_match);
> static struct i2c_driver ov965x_i2c_driver = {
> .driver = {
> .name = DRIVER_NAME,
> + .of_match_table = of_match_ptr(ov965x_of_match),
> },
> .probe = ov965x_probe,
> .remove = ov965x_remove,

--
Regards,

Sakari Ailus
e-mail: [email protected] XMPP: [email protected]

2017-06-26 16:33:40

by Sakari Ailus

[permalink] [raw]
Subject: Re: [PATCH v1 4/6] [media] ov9650: use write_array() for resolution sequences

Hi Hugues,

On Thu, Jun 22, 2017 at 05:05:40PM +0200, Hugues Fruchet wrote:
> Align resolution sequences on initialization sequence using
> i2c_rv structure NULL terminated .This add flexibility
> on resolution sequence size.
> Document resolution related registers by using corresponding
> define instead of hexa address/value.
>
> Signed-off-by: Hugues Fruchet <[email protected]>
> ---
> drivers/media/i2c/ov9650.c | 98 ++++++++++++++++++++++++++++++----------------
> 1 file changed, 64 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> index 4311da6..8b283c9 100644
> --- a/drivers/media/i2c/ov9650.c
> +++ b/drivers/media/i2c/ov9650.c
> @@ -227,11 +227,16 @@ struct ov965x_ctrls {
> u8 update;
> };
>
> +struct i2c_rv {
> + u8 addr;
> + u8 value;
> +};
> +
> struct ov965x_framesize {
> u16 width;
> u16 height;
> u16 max_exp_lines;
> - const u8 *regs;
> + const struct i2c_rv *regs;
> };
>
> struct ov965x_interval {
> @@ -280,9 +285,11 @@ struct ov965x {
> u8 apply_frame_fmt;
> };
>
> -struct i2c_rv {
> - u8 addr;
> - u8 value;
> +struct ov965x_pixfmt {
> + u32 code;
> + u32 colorspace;
> + /* REG_TSLB value, only bits [3:2] may be set. */
> + u8 tslb_reg;
> };
>
> static const struct i2c_rv ov965x_init_regs[] = {
> @@ -342,30 +349,59 @@ struct i2c_rv {
> { REG_NULL, 0 }
> };
>
> -#define NUM_FMT_REGS 14
> -/*
> - * COM7, COM3, COM4, HSTART, HSTOP, HREF, VSTART, VSTOP, VREF,
> - * EXHCH, EXHCL, ADC, OCOM, OFON
> - */
> -static const u8 frame_size_reg_addr[NUM_FMT_REGS] = {
> - 0x12, 0x0c, 0x0d, 0x17, 0x18, 0x32, 0x19, 0x1a, 0x03,
> - 0x2a, 0x2b, 0x37, 0x38, 0x39,
> -};
> -
> -static const u8 ov965x_sxga_regs[NUM_FMT_REGS] = {
> - 0x00, 0x00, 0x00, 0x1e, 0xbe, 0xbf, 0x01, 0x81, 0x12,
> - 0x10, 0x34, 0x81, 0x93, 0x51,
> +static const struct i2c_rv ov965x_sxga_regs[] = {
> + { REG_COM7, 0x00 },
> + { REG_COM3, 0x00 },
> + { REG_COM4, 0x00 },
> + { REG_HSTART, 0x1e },
> + { REG_HSTOP, 0xbe },
> + { 0x32, 0xbf },
> + { REG_VSTART, 0x01 },
> + { REG_VSTOP, 0x81 },
> + { REG_VREF, 0x12 },
> + { REG_EXHCH, 0x10 },
> + { REG_EXHCL, 0x34 },
> + { REG_ADC, 0x81 },
> + { REG_ACOM, 0x93 },
> + { REG_OFON, 0x51 },
> + { REG_NULL, 0 },
> };
>
> -static const u8 ov965x_vga_regs[NUM_FMT_REGS] = {
> - 0x40, 0x04, 0x80, 0x26, 0xc6, 0xed, 0x01, 0x3d, 0x00,
> - 0x10, 0x40, 0x91, 0x12, 0x43,
> +static const struct i2c_rv ov965x_vga_regs[] = {
> + { REG_COM7, 0x40 },
> + { REG_COM3, 0x04 },
> + { REG_COM4, 0x80 },
> + { REG_HSTART, 0x26 },
> + { REG_HSTOP, 0xc6 },
> + { 0x32, 0xed },
> + { REG_VSTART, 0x01 },
> + { REG_VSTOP, 0x3d },
> + { REG_VREF, 0x00 },
> + { REG_EXHCH, 0x10 },
> + { REG_EXHCL, 0x40 },
> + { REG_ADC, 0x91 },
> + { REG_ACOM, 0x12 },
> + { REG_OFON, 0x43 },
> + { REG_NULL, 0 },
> };
>
> /* Determined empirically. */
> -static const u8 ov965x_qvga_regs[NUM_FMT_REGS] = {
> - 0x10, 0x04, 0x80, 0x25, 0xc5, 0xbf, 0x00, 0x80, 0x12,
> - 0x10, 0x40, 0x91, 0x12, 0x43,
> +static const struct i2c_rv ov965x_qvga_regs[] = {
> + { REG_COM7, 0x10 },
> + { REG_COM3, 0x04 },
> + { REG_COM4, 0x80 },
> + { REG_HSTART, 0x25 },
> + { REG_HSTOP, 0xc5 },
> + { 0x32, 0xbf },
> + { REG_VSTART, 0x00 },
> + { REG_VSTOP, 0x80 },
> + { REG_VREF, 0x12 },
> + { REG_EXHCH, 0x10 },
> + { REG_EXHCL, 0x40 },
> + { REG_ADC, 0x91 },
> + { REG_ACOM, 0x12 },
> + { REG_OFON, 0x43 },
> + { REG_NULL, 0 },
> };
>
> static const struct ov965x_framesize ov965x_framesizes[] = {
> @@ -387,13 +423,6 @@ struct i2c_rv {
> },
> };
>
> -struct ov965x_pixfmt {
> - u32 code;
> - u32 colorspace;
> - /* REG_TSLB value, only bits [3:2] may be set. */
> - u8 tslb_reg;
> -};

Any particular reason for moving struct ov965x_pixfmt definition?

> -
> static const struct ov965x_pixfmt ov965x_formats[] = {
> { MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG, 0x00},
> { MEDIA_BUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG, 0x04},
> @@ -1268,11 +1297,12 @@ static int ov965x_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
>
> static int ov965x_set_frame_size(struct ov965x *ov965x)
> {
> - int i, ret = 0;
> + int ret = 0;
> +
> + v4l2_dbg(1, debug, ov965x->client, "%s\n", __func__);
>
> - for (i = 0; ret == 0 && i < NUM_FMT_REGS; i++)
> - ret = ov965x_write(ov965x->client, frame_size_reg_addr[i],
> - ov965x->frame_size->regs[i]);
> + ret = ov965x_write_array(ov965x->client,
> + ov965x->frame_size->regs);
> return ret;
> }
>

--
Regards,

Sakari Ailus
e-mail: [email protected] XMPP: [email protected]

2017-06-26 17:47:11

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 2/6] [media] ov9650: add device tree support

Hi,

> Am 26.06.2017 um 18:31 schrieb Sakari Ailus <[email protected]>:
>
> Hi Hugues,
>
> On Thu, Jun 22, 2017 at 05:05:38PM +0200, Hugues Fruchet wrote:
>> @@ -1545,15 +1577,22 @@ static int ov965x_remove(struct i2c_client *client)
>> }
>>
>> static const struct i2c_device_id ov965x_id[] = {
>> - { "OV9650", 0 },
>> - { "OV9652", 0 },
>> + { "OV9650", 0x9650 },
>> + { "OV9652", 0x9652 },
>
> This change does not appear to match with the patch description nor it the
> information is used. How about not changing it, unless there's a reason to?
> The same for the data field of the of_device_id array below.

I think it could/should be used to check if the camera chip that is found
by reading the product-id and version registers does match what the device
tree expects and abort probing on a mismatch.

BR,
Nikolaus


2017-06-26 18:54:24

by Rob Herring

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On Thu, Jun 22, 2017 at 05:05:37PM +0200, Hugues Fruchet wrote:
> From: "H. Nikolaus Schaller" <[email protected]>
>
> This adds documentation of device tree bindings
> for the OV965X family camera sensor module.
>
> Signed-off-by: H. Nikolaus Schaller <[email protected]>
> Signed-off-by: Hugues Fruchet <[email protected]>
> ---
> .../devicetree/bindings/media/i2c/ov965x.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> new file mode 100644
> index 0000000..0e0de1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
> @@ -0,0 +1,37 @@
> +* Omnivision OV9650/9652/9655 CMOS sensor
> +
> +The Omnivision OV965x sensor support multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> +output format.
> +
> +Required Properties:
> +- compatible: should be one of
> + "ovti,ov9650"
> + "ovti,ov9652"
> + "ovti,ov9655"
> +- clocks: reference to the mclk input clock.
> +
> +Optional Properties:
> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.

reset-gpios and state it is active low.

> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.

powerdown-gpios and state it is active ???.

Those are semi-standard names.

With that,

Acked-by: Rob Herring <[email protected]>

2017-06-26 18:57:03

by Rob Herring

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On Fri, Jun 23, 2017 at 12:25:33PM +0200, H. Nikolaus Schaller wrote:
> Hi Hugues,
>
> > Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <[email protected]>:
> >
> > From: "H. Nikolaus Schaller" <[email protected]>
> >
> > This adds documentation of device tree bindings
> > for the OV965X family camera sensor module.
> >
> > Signed-off-by: H. Nikolaus Schaller <[email protected]>
> > Signed-off-by: Hugues Fruchet <[email protected]>
> > ---
> > .../devicetree/bindings/media/i2c/ov965x.txt | 37 ++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt

[...]

> > +Optional Properties:
> > +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
> > +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
>
> Here I wonder why you did split that up into two gpios. Each "*-gpios" can have
> multiple entries and if one is not used, a 0 can be specified to make it being ignored.
>
> But it is up to DT maintainers what they prefer: separate single gpios or a single gpio array.

I think that is pretty clear if you survey a number of bindings (hint:
it's the former).

Rob

2017-06-26 20:05:04

by Sylwester Nawrocki

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>> So the driver does not power up the camera module when needed and therefore probing fails.
>>
>> - vana-supply: a regulator to power up the camera module.
>>
>> Driver code is not complex to add:

> Yes, I saw it in your code, but as I don't have any programmable power
> supply on my setup, I have not pushed this commit.

Since you are about to add voltage supplies to the DT binding I'd suggest
to include all three voltage supplies of the sensor chip. Looking at the OV9650
and the OV9655 datasheet there are following names used for the voltage supply
pins:

AVDD - Analog power supply,
DVDD - Power supply for digital core logic,
DOVDD - Digital power supply for I/O.

I doubt the sensor can work without any of these voltage supplies, thus
regulator_get_optional() should not be used. I would just use the regulator
bulk API to handle all three power supplies.

--
Regards,
Sylwester




2017-06-27 05:37:25

by Sakari Ailus

[permalink] [raw]
Subject: Re: [PATCH v1 2/6] [media] ov9650: add device tree support

On Mon, Jun 26, 2017 at 07:46:34PM +0200, H. Nikolaus Schaller wrote:
> Hi,
>
> > Am 26.06.2017 um 18:31 schrieb Sakari Ailus <[email protected]>:
> >
> > Hi Hugues,
> >
> > On Thu, Jun 22, 2017 at 05:05:38PM +0200, Hugues Fruchet wrote:
> >> @@ -1545,15 +1577,22 @@ static int ov965x_remove(struct i2c_client *client)
> >> }
> >>
> >> static const struct i2c_device_id ov965x_id[] = {
> >> - { "OV9650", 0 },
> >> - { "OV9652", 0 },
> >> + { "OV9650", 0x9650 },
> >> + { "OV9652", 0x9652 },
> >
> > This change does not appear to match with the patch description nor it the
> > information is used. How about not changing it, unless there's a reason to?
> > The same for the data field of the of_device_id array below.
>
> I think it could/should be used to check if the camera chip that is found
> by reading the product-id and version registers does match what the device
> tree expects and abort probing on a mismatch.

Makes sense. But it should be a separate patch, shouldn't it?

You could also put the id to the ops struct, and choose the ops struct that
way. Entirely up to you.

--
Sakari Ailus
e-mail: [email protected] XMPP: [email protected]

2017-06-27 05:48:52

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module


> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <[email protected]>:
>
> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>>> So the driver does not power up the camera module when needed and therefore probing fails.
>>>
>>> - vana-supply: a regulator to power up the camera module.
>>>
>>> Driver code is not complex to add:
>
>> Yes, I saw it in your code, but as I don't have any programmable power
>> supply on my setup, I have not pushed this commit.
>
> Since you are about to add voltage supplies to the DT binding I'd suggest
> to include all three voltage supplies of the sensor chip. Looking at the OV9650
> and the OV9655 datasheet there are following names used for the voltage supply
> pins:
>
> AVDD - Analog power supply,
> DVDD - Power supply for digital core logic,
> DOVDD - Digital power supply for I/O.

The latter two are usually not independently switchable from the SoC power
the module is connected to.

And sometimes DVDD and DOVDD are connected together.

So the driver can't make much use of knowing or requesting them because the
1.8V supply is always active, even during suspend.

>
> I doubt the sensor can work without any of these voltage supplies, thus
> regulator_get_optional() should not be used. I would just use the regulator
> bulk API to handle all three power supplies.

The digital part works with AVDD turned off. So the LDO supplying AVDD should
be switchable to save power (&vaux3 on the GTA04 device).

But not all designs can switch it off. Hence the idea to define it as an
/optional/ regulator. If it is not defined by DT, the driver simply assumes
it is always powered on.

So in summary we only need AVDD switched for the GTA04 - but it does not
matter if the others are optional properties. We would not use them.

It does matter if they are mandatory because it adds DT complexity (size
and processing) without added function.

BR and thanks,
Nikolaus


2017-06-27 05:50:12

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera


> Am 26.06.2017 um 13:16 schrieb Pavel Machek <[email protected]>:
>
> Hi!
>
>>> You may want to try this one:
>>>
>>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
>>> Author: Pavel <[email protected]>
>>> Date: Mon Feb 13 21:26:51 2017 +0100
>>>
>>> omap3isp: fix VP2SDR bit so capture (not preview) works
>>>
>>> This is neccessary for capture (not preview) to work properly on
>>> N900. Why is unknown.
>>
>> Ah, interesting. I will give it a try.
>>
>> Do you please have a link to the repo where this commit can be
>>> found?
>
> This branch, as mentioned before:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/log/?h=camera-fw5-6

Thanks.

I have merged this patch but unfortunately, it does not make the green screen go away.

Neither with our own driver nor with the new one by Hugues (which turned out to not
support SXGA at all but I tried VGA).

I think we should postpone debugging this until Hugues proposed patches are better reviewed.

BR and thanks,
Nikolaus


Attachments:
signature.asc (801.00 B)
Message signed with OpenPGP using GPGMail

2017-06-27 07:58:07

by Hugues Fruchet

[permalink] [raw]
Subject: Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus,

I would propose to work first on YUV support, so you can test a YUV VGA
grabbing using your OMPA3 setup, I will add this support then in patch
serie.

For the co-work, let's continue on IRC (irc.freenode.net), chat #v4l, my
pseudo is "hfr".

BR,
Hugues.

On 06/26/2017 06:28 PM, H. Nikolaus Schaller wrote:
> Hi Hugues,
>
>> Am 26.06.2017 um 15:19 schrieb Hugues FRUCHET <[email protected]>:
>>
>> Nikolaus,
>> some comments about pixel format/resolution below:
>>
>> On 06/26/2017 10:39 AM, Pavel Machek wrote:
>>> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
>>>> Hi Pavel,
>>>>
>>>>> Am 25.06.2017 um 11:18 schrieb Pavel Machek <[email protected]>:
>>>>>
>>>>> Hi!
>>>>>
>>>>>> * unfortunately we still get no image :(
>>>>>>
>>>>>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image Signal Processor) which
>>>>>> we were not yet able to solve. Oscilloscoping signals on the interface indicated that signals and
>>>>>> sync are correct. But we do not know since mplayer only shows a green screen.
>>>>>
>>>>> What mplayer command line do you use? How did you set up the pipeline
>>>>> with media-ctl?
>>>>>
>>>>> On kernel.org, I have tree called camera-fw5-6 , where camera works
>>>>> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
>>>>> for testing.
>>>>
>>>> We did have yet another (non-DT) camera driver and media-ctl working in with 3.12.37,
>>>> but had no success yet to update it to work with modern kernels or drivers. It
>>>> is either that the (newer) drivers missing something or the media-ctl has changed.
>>>>
>>>> Here is the log of our scripts with Hugues' driver and our latest setup:
>>>>
>>>> root@letux:~# ./camera-demo sxga
>>>> DISPLAY=:0
>>>> XAUTHORITY=tcp
>>>> Camera: /dev/v4l-subdev8
>>>> Setting mode sxga
>>>> media-ctl -r
>>>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>>>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>>>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>>>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>>>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>>>
>>> Ok, so you are using capture, not preview.
>>>
>>> You may want to try this one:
>>>
>>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
>>> Author: Pavel <[email protected]>
>>> Date: Mon Feb 13 21:26:51 2017 +0100
>>>
>>> omap3isp: fix VP2SDR bit so capture (not preview) works
>>>
>>> This is neccessary for capture (not preview) to work properly on
>>> N900. Why is unknown.
>>>
>>> Pavel
>>>
>>>> ### starting mplayer in sxga mode ###
>>>> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
>>
>> => "outfmt=uyvy:width=1280:height=1024"
>>
>> Nikolaus,
>> Be careful that only VGA/RGB565 is coded in this basic version of OV9655,
>> perhaps this explain partly your troubles ?
>
> Ah, I see. The driver should support SXGA and UYVY2X8 (because our 3.12 compatible driver did).
>
> This very old (but working) non-DT driver for 3.12 kernels
> was not based on the ov9650.c code but mt9p031.c:
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/media/i2c/ov9655.c;hb=refs/heads/3.12.37
>
> We abandoned this independent driver because we felt (like you) that extending the existing
> ov9650 driver is a better solution for mainline.
>
>
> At least in theory. Therefore I assumed your submission supports SXGA and UYVY as well,
> since your work is based on ours.
>
> Nevertheless, VGA resolution doesn't work either.
>
> root@letux:~# ./camera-demo vga
> DISPLAY=:0
> XAUTHORITY=tcp
> Camera: /dev/v4l-subdev8
> Setting mode vga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 640x480]'
> ### starting mplayer in vga mode ###
> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=640:height=480:fps=30 -vo x11
>
>
> A little later it reports a NULL pointer dereference in ccdc_link_validate() / ccdc_is_shiftable().
>
> It appears as if the input format translates into a NULL pointer by
> omap3isp_video_format_info(0x00001008).
>
> This NULL pointer is not catched by ccdc_is_shiftable().
>
> And it indicates that the camera driver is doing a format that is not
> supported by omap3isp...
>
>
> So how should we proceed?
>
> It looks as if your driver supports your scenario (STM32F746G-DISCO) in VGA/RGB565
> and our drivers (basically) support ours (omap3isp) in VGA/SXGA but UYVY.
>
> We certainly need a generic driver that supports all platforms and formats. So
> we somehow need to get all this stuff into a single driver.
>
> Working on two different patch sets doesn't make sense and would be rejected
> my maintainers...
>
> Basically I could work on your basis to add what we need, but this requires your
> basis to be stabilized first. Or I would spend more time rebasing my code than
> fixing things.
>
> Or you implement the missing formats / features and I test and try to pinpoint
> and report issues to you for integration.
>
> So we have to agree on some way to coordinate the work, especially who submits
> patch sets for review here. Since you were faster than us to submit anything,
> so you should continue with this series.
>
> BR and thanks,
> Nikolaus
>

2017-06-27 10:15:47

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 2/6] [media] ov9650: add device tree support



On 06/27/2017 07:36 AM, Sakari Ailus wrote:
> On Mon, Jun 26, 2017 at 07:46:34PM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>>
>>> Am 26.06.2017 um 18:31 schrieb Sakari Ailus <[email protected]>:
>>>
>>> Hi Hugues,
>>>
>>> On Thu, Jun 22, 2017 at 05:05:38PM +0200, Hugues Fruchet wrote:
>>>> @@ -1545,15 +1577,22 @@ static int ov965x_remove(struct i2c_client *client)
>>>> }
>>>>
>>>> static const struct i2c_device_id ov965x_id[] = {
>>>> - { "OV9650", 0 },
>>>> - { "OV9652", 0 },
>>>> + { "OV9650", 0x9650 },
>>>> + { "OV9652", 0x9652 },
>>>
>>> This change does not appear to match with the patch description nor it the
>>> information is used. How about not changing it, unless there's a reason to?
>>> The same for the data field of the of_device_id array below.
>>
>> I think it could/should be used to check if the camera chip that is found
>> by reading the product-id and version registers does match what the device
>> tree expects and abort probing on a mismatch.
>
> Makes sense. But it should be a separate patch, shouldn't it?
>
> You could also put the id to the ops struct, and choose the ops struct that
> way. Entirely up to you.
>

I'll suggest to skip the id check between DT compatible string and real
device id read from sensor, this is not something I see in other drivers
currently.
But I would suggest to keep in a separate patch the switch of device id
names to lower case in order to align with other omnivision cameras and
not introduce upper/lower case potential bugs in DT later on (as the one
encountered by Nikolaus):

[media] ov9650: switch i2c device id to lower case

static const struct i2c_device_id ov965x_id[] = {
- { "OV9650", 0 },
- { "OV9652", 0 },
+ { "ov9650", 0 },
+ { "ov9652", 0 },


[media] ov9650: add device tree support

+static const struct of_device_id ov965x_of_match[] = {
+ { .compatible = "ovti,ov9650", },
+ { .compatible = "ovti,ov9652", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ov965x_of_match);
+
static struct i2c_driver ov965x_i2c_driver = {
.driver = {
.name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(ov965x_of_match),


2017-06-27 22:57:44

by Sylwester Nawrocki

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <[email protected]>:
>>
>> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>>>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>>>> So the driver does not power up the camera module when needed and therefore probing fails.
>>>>
>>>> - vana-supply: a regulator to power up the camera module.
>>>>
>>>> Driver code is not complex to add:
>>
>>> Yes, I saw it in your code, but as I don't have any programmable power
>>> supply on my setup, I have not pushed this commit.
>>
>> Since you are about to add voltage supplies to the DT binding I'd suggest
>> to include all three voltage supplies of the sensor chip. Looking at the OV9650
>> and the OV9655 datasheet there are following names used for the voltage supply
>> pins:
>>
>> AVDD - Analog power supply,
>> DVDD - Power supply for digital core logic,
>> DOVDD - Digital power supply for I/O.
>
> The latter two are usually not independently switchable from the SoC power
> the module is connected to.
>
> And sometimes DVDD and DOVDD are connected together.
>
> So the driver can't make much use of knowing or requesting them because the
> 1.8V supply is always active, even during suspend.
>
>>
>> I doubt the sensor can work without any of these voltage supplies, thus
>> regulator_get_optional() should not be used. I would just use the regulator
>> bulk API to handle all three power supplies.
>
> The digital part works with AVDD turned off. So the LDO supplying AVDD should
> be switchable to save power (&vaux3 on the GTA04 device).>
> But not all designs can switch it off. Hence the idea to define it as an
> /optional/ regulator. If it is not defined by DT, the driver simply assumes
> it is always powered on.

I didn't say we can't define regulator supply properties as optional in the DT
binding. If we define them as such and any of these *-supply properties is
missing in DT with regulator_get() the regulator core will use dummy regulator
for that particular voltage supply. While with regulator_get_optional()
-ENODEV is returned when the regulator cannot be found.

> So in summary we only need AVDD switched for the GTA04 - but it does not
> matter if the others are optional properties. We would not use them.
>
> It does matter if they are mandatory because it adds DT complexity (size
> and processing) without added function.

We should not be defining DT binding only with selected use cases/board
designs in mind. IMO all three voltage supplies should be listed in the
binding, presumably all can be made optional, with an assumption that when
the property is missing selected pin is hooked up to a fixed regulator.

--
Thanks,
Sylwester



2017-06-28 09:13:25

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module


> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <[email protected]>:
>
> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <[email protected]>:
>>>
>>> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>>>>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>>>>> So the driver does not power up the camera module when needed and therefore probing fails.
>>>>>
>>>>> - vana-supply: a regulator to power up the camera module.
>>>>>
>>>>> Driver code is not complex to add:
>>>
>>>> Yes, I saw it in your code, but as I don't have any programmable power
>>>> supply on my setup, I have not pushed this commit.
>>>
>>> Since you are about to add voltage supplies to the DT binding I'd suggest
>>> to include all three voltage supplies of the sensor chip. Looking at the OV9650
>>> and the OV9655 datasheet there are following names used for the voltage supply
>>> pins:
>>>
>>> AVDD - Analog power supply,
>>> DVDD - Power supply for digital core logic,
>>> DOVDD - Digital power supply for I/O.
>>
>> The latter two are usually not independently switchable from the SoC power
>> the module is connected to.
>>
>> And sometimes DVDD and DOVDD are connected together.
>>
>> So the driver can't make much use of knowing or requesting them because the
>> 1.8V supply is always active, even during suspend.
>>
>>>
>>> I doubt the sensor can work without any of these voltage supplies, thus
>>> regulator_get_optional() should not be used. I would just use the regulator
>>> bulk API to handle all three power supplies.
>>
>> The digital part works with AVDD turned off. So the LDO supplying AVDD should
>> be switchable to save power (&vaux3 on the GTA04 device).>
>> But not all designs can switch it off. Hence the idea to define it as an
>> /optional/ regulator. If it is not defined by DT, the driver simply assumes
>> it is always powered on.
>
> I didn't say we can't define regulator supply properties as optional in the DT
> binding. If we define them as such and any of these *-supply properties is
> missing in DT with regulator_get() the regulator core will use dummy regulator
> for that particular voltage supply. While with regulator_get_optional()
> -ENODEV is returned when the regulator cannot be found.

Ah, ok. I see.

I had thought that it is the right thing to do like devm_gpiod_get_optional().

That one it is described as:

"* This is equivalent to gpiod_get(), except that when no GPIO was assigned to
* the requested function it will return NULL. This is convenient for drivers
* that need to handle optional GPIOs."

Seems to be inconsistent definition of what "optional" means.

So we indeed should use devm_regulator_get() in this case. Thanks for pointing out!

>
>> So in summary we only need AVDD switched for the GTA04 - but it does not
>> matter if the others are optional properties. We would not use them.
>>
>> It does matter if they are mandatory because it adds DT complexity (size
>> and processing) without added function.
>
> We should not be defining DT binding only with selected use cases/board
> designs in mind. IMO all three voltage supplies should be listed in the
> binding, presumably all can be made optional, with an assumption that when
> the property is missing selected pin is hooked up to a fixed regulator.

Ok, then it should just be defined in the bindings but not used by the driver?

BR and thanks,
Nikolaus



2017-06-28 10:50:55

by Sylwester Nawrocki

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote:
>> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <[email protected]>:
>> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <[email protected]>:
>>>> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>>>>>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>>>>>> So the driver does not power up the camera module when needed and therefore probing fails.
>>>>>>
>>>>>> - vana-supply: a regulator to power up the camera module.
>>>>>>
>>>>>> Driver code is not complex to add:
>>>>
>>>>> Yes, I saw it in your code, but as I don't have any programmable power
>>>>> supply on my setup, I have not pushed this commit.
>>>>
>>>> Since you are about to add voltage supplies to the DT binding I'd suggest
>>>> to include all three voltage supplies of the sensor chip. Looking at the OV9650
>>>> and the OV9655 datasheet there are following names used for the voltage supply
>>>> pins:
>>>>
>>>> AVDD - Analog power supply,
>>>> DVDD - Power supply for digital core logic,
>>>> DOVDD - Digital power supply for I/O.
>>>
>>> The latter two are usually not independently switchable from the SoC power
>>> the module is connected to.
>>>
>>> And sometimes DVDD and DOVDD are connected together.
>>>
>>> So the driver can't make much use of knowing or requesting them because the
>>> 1.8V supply is always active, even during suspend.
>>>
>>>>
>>>> I doubt the sensor can work without any of these voltage supplies, thus
>>>> regulator_get_optional() should not be used. I would just use the regulator
>>>> bulk API to handle all three power supplies.
>>>
>>> The digital part works with AVDD turned off. So the LDO supplying AVDD should
>>> be switchable to save power (&vaux3 on the GTA04 device).>
>>> But not all designs can switch it off. Hence the idea to define it as an
>>> /optional/ regulator. If it is not defined by DT, the driver simply assumes
>>> it is always powered on.
>>
>> I didn't say we can't define regulator supply properties as optional in the DT
>> binding. If we define them as such and any of these *-supply properties is
>> missing in DT with regulator_get() the regulator core will use dummy regulator
>> for that particular voltage supply. While with regulator_get_optional()
>> -ENODEV is returned when the regulator cannot be found.
>
> Ah, ok. I see.
>
> I had thought that it is the right thing to do like devm_gpiod_get_optional().
>
> That one it is described as:
>
> "* This is equivalent to gpiod_get(), except that when no GPIO was assigned to
> * the requested function it will return NULL. This is convenient for drivers
> * that need to handle optional GPIOs."
>
> Seems to be inconsistent definition of what "optional" means.

Indeed, this commit explains it further:

commit de1dd9fd2156874b45803299b3b27e65d5defdd9
regulator: core: Provide hints to the core about optional supplies

> So we indeed should use devm_regulator_get() in this case. Thanks for > pointing out!

>>> So in summary we only need AVDD switched for the GTA04 - but it does not
>>> matter if the others are optional properties. We would not use them.
>>>
>>> It does matter if they are mandatory because it adds DT complexity (size
>>> and processing) without added function.
>>
>> We should not be defining DT binding only with selected use cases/board
>> designs in mind. IMO all three voltage supplies should be listed in the
>> binding, presumably all can be made optional, with an assumption that when
>> the property is missing selected pin is hooked up to a fixed regulator.
>
> Ok, then it should just be defined in the bindings but not used by
> the driver?

Yes, I think so. So we have a possibly complete binding right from the
beginning. I someone needs handling other supplies than AVDD they could
update the driver in future.


Regards,
Sylwester

2017-06-28 11:25:43

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module


> Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki <[email protected]>:
>
> On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote:
>>> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <[email protected]>:
>>> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <[email protected]>:
>>>>> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>>>>>>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>>>>>>> So the driver does not power up the camera module when needed and therefore probing fails.
>>>>>>>
>>>>>>> - vana-supply: a regulator to power up the camera module.
>>>>>>>
>>>>>>> Driver code is not complex to add:
>>>>>
>>>>>> Yes, I saw it in your code, but as I don't have any programmable power
>>>>>> supply on my setup, I have not pushed this commit.
>>>>>
>>>>> Since you are about to add voltage supplies to the DT binding I'd suggest
>>>>> to include all three voltage supplies of the sensor chip. Looking at the OV9650
>>>>> and the OV9655 datasheet there are following names used for the voltage supply
>>>>> pins:
>>>>>
>>>>> AVDD - Analog power supply,
>>>>> DVDD - Power supply for digital core logic,
>>>>> DOVDD - Digital power supply for I/O.
>>>>
>>>> The latter two are usually not independently switchable from the SoC power
>>>> the module is connected to.
>>>>
>>>> And sometimes DVDD and DOVDD are connected together.
>>>>
>>>> So the driver can't make much use of knowing or requesting them because the
>>>> 1.8V supply is always active, even during suspend.
>>>>
>>>>>
>>>>> I doubt the sensor can work without any of these voltage supplies, thus
>>>>> regulator_get_optional() should not be used. I would just use the regulator
>>>>> bulk API to handle all three power supplies.
>>>>
>>>> The digital part works with AVDD turned off. So the LDO supplying AVDD should
>>>> be switchable to save power (&vaux3 on the GTA04 device).>
>>>> But not all designs can switch it off. Hence the idea to define it as an
>>>> /optional/ regulator. If it is not defined by DT, the driver simply assumes
>>>> it is always powered on.
>>>
>>> I didn't say we can't define regulator supply properties as optional in the DT
>>> binding. If we define them as such and any of these *-supply properties is
>>> missing in DT with regulator_get() the regulator core will use dummy regulator
>>> for that particular voltage supply. While with regulator_get_optional()
>>> -ENODEV is returned when the regulator cannot be found.
>>
>> Ah, ok. I see.
>>
>> I had thought that it is the right thing to do like devm_gpiod_get_optional().
>>
>> That one it is described as:
>>
>> "* This is equivalent to gpiod_get(), except that when no GPIO was assigned to
>> * the requested function it will return NULL. This is convenient for drivers
>> * that need to handle optional GPIOs."
>>
>> Seems to be inconsistent definition of what "optional" means.
>
> Indeed, this commit explains it further:
>
> commit de1dd9fd2156874b45803299b3b27e65d5defdd9
> regulator: core: Provide hints to the core about optional supplies
>
>> So we indeed should use devm_regulator_get() in this case. Thanks for > pointing out!
>
>>>> So in summary we only need AVDD switched for the GTA04 - but it does not
>>>> matter if the others are optional properties. We would not use them.
>>>>
>>>> It does matter if they are mandatory because it adds DT complexity (size
>>>> and processing) without added function.
>>>
>>> We should not be defining DT binding only with selected use cases/board
>>> designs in mind. IMO all three voltage supplies should be listed in the
>>> binding, presumably all can be made optional, with an assumption that when
>>> the property is missing selected pin is hooked up to a fixed regulator.
>>
>> Ok, then it should just be defined in the bindings but not used by
>> the driver?
>
> Yes, I think so. So we have a possibly complete binding right from the
> beginning. I someone needs handling other supplies than AVDD they could
> update the driver in future.

Fine! I have sent some patches to Hughues so that he can integrate it in
his next version of the patch series.

BR and thanks,
Nikolaus


2017-06-28 12:29:34

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module



On 06/28/2017 01:24 PM, H. Nikolaus Schaller wrote:
>
>> Am 28.06.2017 um 12:50 schrieb Sylwester Nawrocki <[email protected]>:
>>
>> On 06/28/2017 11:12 AM, H. Nikolaus Schaller wrote:
>>>> Am 28.06.2017 um 00:57 schrieb Sylwester Nawrocki <[email protected]>:
>>>> On 06/27/2017 07:48 AM, H. Nikolaus Schaller wrote:
>>>>>> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki <[email protected]>:
>>>>>> On 06/26/2017 12:35 PM, Hugues FRUCHET wrote:
>>>>>>>> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
>>>>>>>> So the driver does not power up the camera module when needed and therefore probing fails.
>>>>>>>>
>>>>>>>> - vana-supply: a regulator to power up the camera module.
>>>>>>>>
>>>>>>>> Driver code is not complex to add:
>>>>>>
>>>>>>> Yes, I saw it in your code, but as I don't have any programmable power
>>>>>>> supply on my setup, I have not pushed this commit.
>>>>>>
>>>>>> Since you are about to add voltage supplies to the DT binding I'd suggest
>>>>>> to include all three voltage supplies of the sensor chip. Looking at the OV9650
>>>>>> and the OV9655 datasheet there are following names used for the voltage supply
>>>>>> pins:
>>>>>>
>>>>>> AVDD - Analog power supply,
>>>>>> DVDD - Power supply for digital core logic,
>>>>>> DOVDD - Digital power supply for I/O.
>>>>>
>>>>> The latter two are usually not independently switchable from the SoC power
>>>>> the module is connected to.
>>>>>
>>>>> And sometimes DVDD and DOVDD are connected together.
>>>>>
>>>>> So the driver can't make much use of knowing or requesting them because the
>>>>> 1.8V supply is always active, even during suspend.
>>>>>
>>>>>>
>>>>>> I doubt the sensor can work without any of these voltage supplies, thus
>>>>>> regulator_get_optional() should not be used. I would just use the regulator
>>>>>> bulk API to handle all three power supplies.
>>>>>
>>>>> The digital part works with AVDD turned off. So the LDO supplying AVDD should
>>>>> be switchable to save power (&vaux3 on the GTA04 device).>
>>>>> But not all designs can switch it off. Hence the idea to define it as an
>>>>> /optional/ regulator. If it is not defined by DT, the driver simply assumes
>>>>> it is always powered on.
>>>>
>>>> I didn't say we can't define regulator supply properties as optional in the DT
>>>> binding. If we define them as such and any of these *-supply properties is
>>>> missing in DT with regulator_get() the regulator core will use dummy regulator
>>>> for that particular voltage supply. While with regulator_get_optional()
>>>> -ENODEV is returned when the regulator cannot be found.
>>>
>>> Ah, ok. I see.
>>>
>>> I had thought that it is the right thing to do like devm_gpiod_get_optional().
>>>
>>> That one it is described as:
>>>
>>> "* This is equivalent to gpiod_get(), except that when no GPIO was assigned to
>>> * the requested function it will return NULL. This is convenient for drivers
>>> * that need to handle optional GPIOs."
>>>
>>> Seems to be inconsistent definition of what "optional" means.
>>
>> Indeed, this commit explains it further:
>>
>> commit de1dd9fd2156874b45803299b3b27e65d5defdd9
>> regulator: core: Provide hints to the core about optional supplies
>>
>>> So we indeed should use devm_regulator_get() in this case. Thanks for > pointing out!
>>
>>>>> So in summary we only need AVDD switched for the GTA04 - but it does not
>>>>> matter if the others are optional properties. We would not use them.
>>>>>
>>>>> It does matter if they are mandatory because it adds DT complexity (size
>>>>> and processing) without added function.
>>>>
>>>> We should not be defining DT binding only with selected use cases/board
>>>> designs in mind. IMO all three voltage supplies should be listed in the
>>>> binding, presumably all can be made optional, with an assumption that when
>>>> the property is missing selected pin is hooked up to a fixed regulator.
>>>
>>> Ok, then it should just be defined in the bindings but not used by
>>> the driver?
>>
>> Yes, I think so. So we have a possibly complete binding right from the
>> beginning. I someone needs handling other supplies than AVDD they could
>> update the driver in future.
>
> Fine! I have sent some patches to Hughues so that he can integrate it in
> his next version of the patch series.
>
> BR and thanks,
> Nikolaus
>

OK got it, I'll push in v2.

2017-06-29 14:00:44

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 4/6] [media] ov9650: use write_array() for resolution sequences



On 06/26/2017 06:33 PM, Sakari Ailus wrote:
> Hi Hugues,
>
> On Thu, Jun 22, 2017 at 05:05:40PM +0200, Hugues Fruchet wrote:
>> Align resolution sequences on initialization sequence using
>> i2c_rv structure NULL terminated .This add flexibility
>> on resolution sequence size.
>> Document resolution related registers by using corresponding
>> define instead of hexa address/value.
>>
>> Signed-off-by: Hugues Fruchet <[email protected]>
>> ---
>> drivers/media/i2c/ov9650.c | 98 ++++++++++++++++++++++++++++++----------------
>> 1 file changed, 64 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
>> index 4311da6..8b283c9 100644
>> --- a/drivers/media/i2c/ov9650.c
>> +++ b/drivers/media/i2c/ov9650.c
>> @@ -227,11 +227,16 @@ struct ov965x_ctrls {
>> u8 update;
>> };
>>
>> +struct i2c_rv {
>> + u8 addr;
>> + u8 value;
>> +};
>> +
>> struct ov965x_framesize {
>> u16 width;
>> u16 height;
>> u16 max_exp_lines;
>> - const u8 *regs;
>> + const struct i2c_rv *regs;
>> };
>>
>> struct ov965x_interval {
>> @@ -280,9 +285,11 @@ struct ov965x {
>> u8 apply_frame_fmt;
>> };
>>
>> -struct i2c_rv {
>> - u8 addr;
>> - u8 value;
>> +struct ov965x_pixfmt {
>> + u32 code;
>> + u32 colorspace;
>> + /* REG_TSLB value, only bits [3:2] may be set. */
>> + u8 tslb_reg;
>> };
>>
>> static const struct i2c_rv ov965x_init_regs[] = {
>> @@ -342,30 +349,59 @@ struct i2c_rv {
>> { REG_NULL, 0 }
>> };
>>
>> -#define NUM_FMT_REGS 14
>> -/*
>> - * COM7, COM3, COM4, HSTART, HSTOP, HREF, VSTART, VSTOP, VREF,
>> - * EXHCH, EXHCL, ADC, OCOM, OFON
>> - */
>> -static const u8 frame_size_reg_addr[NUM_FMT_REGS] = {
>> - 0x12, 0x0c, 0x0d, 0x17, 0x18, 0x32, 0x19, 0x1a, 0x03,
>> - 0x2a, 0x2b, 0x37, 0x38, 0x39,
>> -};
>> -
>> -static const u8 ov965x_sxga_regs[NUM_FMT_REGS] = {
>> - 0x00, 0x00, 0x00, 0x1e, 0xbe, 0xbf, 0x01, 0x81, 0x12,
>> - 0x10, 0x34, 0x81, 0x93, 0x51,
>> +static const struct i2c_rv ov965x_sxga_regs[] = {
>> + { REG_COM7, 0x00 },
>> + { REG_COM3, 0x00 },
>> + { REG_COM4, 0x00 },
>> + { REG_HSTART, 0x1e },
>> + { REG_HSTOP, 0xbe },
>> + { 0x32, 0xbf },
>> + { REG_VSTART, 0x01 },
>> + { REG_VSTOP, 0x81 },
>> + { REG_VREF, 0x12 },
>> + { REG_EXHCH, 0x10 },
>> + { REG_EXHCL, 0x34 },
>> + { REG_ADC, 0x81 },
>> + { REG_ACOM, 0x93 },
>> + { REG_OFON, 0x51 },
>> + { REG_NULL, 0 },
>> };
>>
>> -static const u8 ov965x_vga_regs[NUM_FMT_REGS] = {
>> - 0x40, 0x04, 0x80, 0x26, 0xc6, 0xed, 0x01, 0x3d, 0x00,
>> - 0x10, 0x40, 0x91, 0x12, 0x43,
>> +static const struct i2c_rv ov965x_vga_regs[] = {
>> + { REG_COM7, 0x40 },
>> + { REG_COM3, 0x04 },
>> + { REG_COM4, 0x80 },
>> + { REG_HSTART, 0x26 },
>> + { REG_HSTOP, 0xc6 },
>> + { 0x32, 0xed },
>> + { REG_VSTART, 0x01 },
>> + { REG_VSTOP, 0x3d },
>> + { REG_VREF, 0x00 },
>> + { REG_EXHCH, 0x10 },
>> + { REG_EXHCL, 0x40 },
>> + { REG_ADC, 0x91 },
>> + { REG_ACOM, 0x12 },
>> + { REG_OFON, 0x43 },
>> + { REG_NULL, 0 },
>> };
>>
>> /* Determined empirically. */
>> -static const u8 ov965x_qvga_regs[NUM_FMT_REGS] = {
>> - 0x10, 0x04, 0x80, 0x25, 0xc5, 0xbf, 0x00, 0x80, 0x12,
>> - 0x10, 0x40, 0x91, 0x12, 0x43,
>> +static const struct i2c_rv ov965x_qvga_regs[] = {
>> + { REG_COM7, 0x10 },
>> + { REG_COM3, 0x04 },
>> + { REG_COM4, 0x80 },
>> + { REG_HSTART, 0x25 },
>> + { REG_HSTOP, 0xc5 },
>> + { 0x32, 0xbf },
>> + { REG_VSTART, 0x00 },
>> + { REG_VSTOP, 0x80 },
>> + { REG_VREF, 0x12 },
>> + { REG_EXHCH, 0x10 },
>> + { REG_EXHCL, 0x40 },
>> + { REG_ADC, 0x91 },
>> + { REG_ACOM, 0x12 },
>> + { REG_OFON, 0x43 },
>> + { REG_NULL, 0 },
>> };
>>
>> static const struct ov965x_framesize ov965x_framesizes[] = {
>> @@ -387,13 +423,6 @@ struct i2c_rv {
>> },
>> };
>>
>> -struct ov965x_pixfmt {
>> - u32 code;
>> - u32 colorspace;
>> - /* REG_TSLB value, only bits [3:2] may be set. */
>> - u8 tslb_reg;
>> -};
>
> Any particular reason for moving struct ov965x_pixfmt definition?

Not in the right patch, must be in 5/6 [media] ov9650: add multiple
variant support, I'll fix in v2.

>
>> -
>> static const struct ov965x_pixfmt ov965x_formats[] = {
>> { MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG, 0x00},
>> { MEDIA_BUS_FMT_YVYU8_2X8, V4L2_COLORSPACE_JPEG, 0x04},
>> @@ -1268,11 +1297,12 @@ static int ov965x_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
>>
>> static int ov965x_set_frame_size(struct ov965x *ov965x)
>> {
>> - int i, ret = 0;
>> + int ret = 0;
>> +
>> + v4l2_dbg(1, debug, ov965x->client, "%s\n", __func__);
>>
>> - for (i = 0; ret == 0 && i < NUM_FMT_REGS; i++)
>> - ret = ov965x_write(ov965x->client, frame_size_reg_addr[i],
>> - ov965x->frame_size->regs[i]);
>> + ret = ov965x_write_array(ov965x->client,
>> + ov965x->frame_size->regs);
>> return ret;
>> }
>>
>

2017-07-01 21:00:37

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi,

Firstly, it turned out that we also must have V4L2_CID_PIXEL_RATE for omap3isp compatibility
(see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?&id=0bc77f3f06fcf2ca7b7fad782d70926cd4d235f1 ).

And secondly, I have tried to add some SXGA config and it looks good by oscilloscope:
- XCLK ca. 24 MHz
- PCLK ca. 12 MHz
- HREF ca. 15.6 kHz negative going impulses
- VSYNC ca. 15 Hz (fps) positive going impulses
- D8 data line shows changing 0/1 patterns which depend on light falling in camera lens

But mplayer still shows a green screen and reports v4l2: select timeout.

I assume we should see a at least scrambled image but not a green screen,
even if sync position and polarity or data format would not be correctly
set up.

This time the omap3isp is fully initialized and does a register dump:

> root@letux:~# ./camera-demo sxga
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11

NOTE: /dev/video2 is $(media-ctl -e "OMAP3 ISP CCDC output")

> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
> name: Video 4 Linux 2 input
> author: Martin Olschewski <[email protected]>
> comment: first try, more to come ;-)
> v4l2: ioctl get standard failed: Invalid argument

^^^ does not look harmful

> Selected device: OMAP3 ISP CCDC output
> Capabilities: video capture video output streaming
> supported norms:
> inputs: 0 = camera;
> Current input: 0
> Current format: unknown (0x0)
> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
> v4l2: ioctl enum norm failed: Inappropriate ioctl for device

^^^ does not look harmful

> Error: Cannot set norm!
> Selected input hasn't got a tuner!

^^^ does not look harmful

> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device

^^^ does not look harmful

> [ 558.848815] configuring for 1280(2560)x1024
> [ 558.854003] omap3isp 480bc000.isp: -------------CCDC Register dump-------------
> [ 558.863983] omap3isp 480bc000.isp: ###CCDC PCR=0x00000000
> [ 558.870880] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
> [ 558.877227] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x00000000
> [ 558.884613] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x00000000
> [ 558.891876] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x000004ff
> [ 558.898132] omap3isp 480bc000.isp: ###CCDC VERT_START=0x00000000
> [ 558.905700] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x000003ff
> [ 558.913421] omap3isp 480bc000.isp: ###CCDC CULLING=0xffff00ff
> [ 558.920471] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x00000a00
> [ 558.926727] omap3isp 480bc000.isp: ###CCDC SDOFST=0x00000000
> [ 558.933929] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x40000000
> [ 558.940948] omap3isp 480bc000.isp: ###CCDC CLAMP=0x00000010
> [ 558.946990] omap3isp 480bc000.isp: ###CCDC DCSUB=0x00000000
> [ 558.953948] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
> [ 558.960845] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x00000000
> [ 558.966888] omap3isp 480bc000.isp: ###CCDC FPC=0x00000000
> [ 558.973724] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x00000000
> [ 558.982757] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
> [ 558.988769] omap3isp 480bc000.isp: ###CCDC ALAW=0x00000004
> [ 558.995483] omap3isp 480bc000.isp: ###CCDC REC656IF=0x00000000
> [ 559.002380] omap3isp 480bc000.isp: ###CCDC CFG=0x00008800
> [ 559.008056] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x00000000
> [ 559.014892] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x00000000
> [ 559.021697] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x00000000
> [ 559.027954] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x00000000
> [ 559.034912] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x00000000
> [ 559.041748] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x00000000
> [ 559.047790] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x00000000
> [ 559.054687] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x00000000
> [ 559.061645] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x00006600
> [ 559.068084] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x00000000
> [ 559.075378] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x00000000
> [ 559.082916] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x00000000
> [ 559.090454] omap3isp 480bc000.isp: --------------------------------------------
> [ass] auto-open
> Opening video filter: [rotate=2]
> VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> [swscaler @ 0xb5d45980]using unscaled uyvy422 -> yuv420p special converter
> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
> [swscaler @ 0xb5d45980]No accelerated colorspace conversion found from yuv420p to bgra.
> Colorspace details not fully supported by selected vo.
> Selected video codec: RAW UYVY [raw]
> Audio: no sound
> Starting playback...
> v4l2: select timeout
> V: 0.0 1/ 1 ??% ??% ??,?% 0 0
> v4l2: select timeout
> V: 0.0 3/ 3 ??% ??% ??,?% 0 0
> v4l2: select timeout
> V: 0.0 4/ 4 ??% ??% ??,?% 0 0
> v4l2: select timeout
> V: 0.0 5/ 5 ??% ??% ??,?% 0 0
> v4l2: select timeout
>
>
> MPlayer interrupted by signal 2 in module: filter_video
> V: 0.0 6/ 6 ??% ??% ??,?% 0 0
> v4l2: select timeout
> [ 565.122406] omap3isp 480bc000.isp: OMAP3 ISP AEWB: user wants to disable module.
> [ 565.130950] omap3isp 480bc000.isp: OMAP3 ISP AEWB: module is being disabled
> [ 565.138397] omap3isp 480bc000.isp: OMAP3 ISP AF: user wants to disable module.
> [ 565.149047] omap3isp 480bc000.isp: OMAP3 ISP AF: module is being disabled
> [ 565.158660] omap3isp 480bc000.isp: OMAP3 ISP histogram: user wants to disable module.
> [ 565.168945] omap3isp 480bc000.isp: OMAP3 ISP histogram: module is being disabled
> [ 567.221099] omap3isp 480bc000.isp: CCDC stop timeout!
> [ 567.226593] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC

^^^ that looks like some lockup of the CCDC?

> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: 0 frames successfully processed, 1 frames dropped.
>
> Exiting... (Quit)
> root@letux:~#

Latest patches are here:

http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/extern/ov9655-v2

Device tree:

http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap3-gta04.dtsi;hb=80a33790b381c83fd6e99af15cb5bd6c97abb0a7#l941

Any ideas how to debug 'v4l2: select timeout'?

BR and thanks,
Nikolaus


2017-07-03 08:17:07

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus,
Could you enable V4L2 UAPI traces ? Something like:
echo 0xFF > /sys/devices/platform/soc/<isp address>.<isp
name>/video4linux/video2/dev_debug

you will see then in kernel dmesg the V4L2 calls and their
parameters/return values.

BR,
Hugues.

On 07/01/2017 11:00 PM, H. Nikolaus Schaller wrote:
> Hi,
>
> Firstly, it turned out that we also must have V4L2_CID_PIXEL_RATE for omap3isp compatibility
> (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?&id=0bc77f3f06fcf2ca7b7fad782d70926cd4d235f1 ).
>
> And secondly, I have tried to add some SXGA config and it looks good by oscilloscope:
> - XCLK ca. 24 MHz
> - PCLK ca. 12 MHz
> - HREF ca. 15.6 kHz negative going impulses
> - VSYNC ca. 15 Hz (fps) positive going impulses
> - D8 data line shows changing 0/1 patterns which depend on light falling in camera lens
>
> But mplayer still shows a green screen and reports v4l2: select timeout.
>
> I assume we should see a at least scrambled image but not a green screen,
> even if sync position and polarity or data format would not be correctly
> set up.
>
> This time the omap3isp is fully initialized and does a register dump:
>
>> root@letux:~# ./camera-demo sxga
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
>
> NOTE: /dev/video2 is $(media-ctl -e "OMAP3 ISP CCDC output")
>
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski <[email protected]>
>> comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
>
> ^^^ does not look harmful
>
>> Selected device: OMAP3 ISP CCDC output
>> Capabilities: video capture video output streaming
>> supported norms:
>> inputs: 0 = camera;
>> Current input: 0
>> Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
>
> ^^^ does not look harmful
>
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
>
> ^^^ does not look harmful
>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>
> ^^^ does not look harmful
>
>> [ 558.848815] configuring for 1280(2560)x1024
>> [ 558.854003] omap3isp 480bc000.isp: -------------CCDC Register dump-------------
>> [ 558.863983] omap3isp 480bc000.isp: ###CCDC PCR=0x00000000
>> [ 558.870880] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
>> [ 558.877227] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x00000000
>> [ 558.884613] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x00000000
>> [ 558.891876] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x000004ff
>> [ 558.898132] omap3isp 480bc000.isp: ###CCDC VERT_START=0x00000000
>> [ 558.905700] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x000003ff
>> [ 558.913421] omap3isp 480bc000.isp: ###CCDC CULLING=0xffff00ff
>> [ 558.920471] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x00000a00
>> [ 558.926727] omap3isp 480bc000.isp: ###CCDC SDOFST=0x00000000
>> [ 558.933929] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x40000000
>> [ 558.940948] omap3isp 480bc000.isp: ###CCDC CLAMP=0x00000010
>> [ 558.946990] omap3isp 480bc000.isp: ###CCDC DCSUB=0x00000000
>> [ 558.953948] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
>> [ 558.960845] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x00000000
>> [ 558.966888] omap3isp 480bc000.isp: ###CCDC FPC=0x00000000
>> [ 558.973724] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x00000000
>> [ 558.982757] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
>> [ 558.988769] omap3isp 480bc000.isp: ###CCDC ALAW=0x00000004
>> [ 558.995483] omap3isp 480bc000.isp: ###CCDC REC656IF=0x00000000
>> [ 559.002380] omap3isp 480bc000.isp: ###CCDC CFG=0x00008800
>> [ 559.008056] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x00000000
>> [ 559.014892] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x00000000
>> [ 559.021697] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x00000000
>> [ 559.027954] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x00000000
>> [ 559.034912] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x00000000
>> [ 559.041748] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x00000000
>> [ 559.047790] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x00000000
>> [ 559.054687] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x00000000
>> [ 559.061645] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x00006600
>> [ 559.068084] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x00000000
>> [ 559.075378] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x00000000
>> [ 559.082916] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x00000000
>> [ 559.090454] omap3isp 480bc000.isp: --------------------------------------------
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5d45980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5d45980]No accelerated colorspace conversion found from yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> v4l2: select timeout
>> V: 0.0 1/ 1 ??% ??% ??,?% 0 0
>> v4l2: select timeout
>> V: 0.0 3/ 3 ??% ??% ??,?% 0 0
>> v4l2: select timeout
>> V: 0.0 4/ 4 ??% ??% ??,?% 0 0
>> v4l2: select timeout
>> V: 0.0 5/ 5 ??% ??% ??,?% 0 0
>> v4l2: select timeout
>>
>>
>> MPlayer interrupted by signal 2 in module: filter_video
>> V: 0.0 6/ 6 ??% ??% ??,?% 0 0
>> v4l2: select timeout
>> [ 565.122406] omap3isp 480bc000.isp: OMAP3 ISP AEWB: user wants to disable module.
>> [ 565.130950] omap3isp 480bc000.isp: OMAP3 ISP AEWB: module is being disabled
>> [ 565.138397] omap3isp 480bc000.isp: OMAP3 ISP AF: user wants to disable module.
>> [ 565.149047] omap3isp 480bc000.isp: OMAP3 ISP AF: module is being disabled
>> [ 565.158660] omap3isp 480bc000.isp: OMAP3 ISP histogram: user wants to disable module.
>> [ 565.168945] omap3isp 480bc000.isp: OMAP3 ISP histogram: module is being disabled
>> [ 567.221099] omap3isp 480bc000.isp: CCDC stop timeout!
>> [ 567.226593] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC
>
> ^^^ that looks like some lockup of the CCDC?
>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: 0 frames successfully processed, 1 frames dropped.
>>
>> Exiting... (Quit)
>> root@letux:~#
>
> Latest patches are here:
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/extern/ov9655-v2
>
> Device tree:
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap3-gta04.dtsi;hb=80a33790b381c83fd6e99af15cb5bd6c97abb0a7#l941
>
> Any ideas how to debug 'v4l2: select timeout'?
>
> BR and thanks,
> Nikolaus
>

2017-07-03 09:14:46

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Hugues,

> Am 03.07.2017 um 10:16 schrieb Hugues FRUCHET <[email protected]>:
>
> Hi Nikolaus,
> Could you enable V4L2 UAPI traces ? Something like:
> echo 0xFF > /sys/devices/platform/soc/<isp address>.<isp
> name>/video4linux/video2/dev_debug
>
> you will see then in kernel dmesg the V4L2 calls and their
> parameters/return values.

Nice.

> root@letux:~# echo 255 >/sys/devices/platform/68000000.ocp/480bc000.isp/video4linux/video2/dev_debug
> root@letux:~# ./camera-demo sxga
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
> name: Video 4 Linux 2 input
> author: Martin Olschewski <[email protected]>
> comment: first try, more to come ;-)
> [ 425.216094] video2: open (0)
> [ 425.219329] video2: VIDIOC_QUERYCAP: driver=ispvideo, card=OMAP3 ISP CCDC output, bus=media, version=0x00040c00, capabilities=0x84200003, device_caps=0x04200001
> [ 425.236389] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.254699] video2: VIDIOC_G_STD: error -25: std=0x00000000
> [ 425.260620] video2: VIDIOC_G_PARM: error -22: type=vid-cap, capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0, readbuffers=0
> v4l2: ioctl get standard failed: Invalid argumen[ 425.275573] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
> t
> Selected device: OMAP3 ISP CCDC output
> Capa[ 425.289398] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, audioset=0x0, tuner=0, std=0x00000000, status=0x0, capabilities=0x0
> bilities: video capture video output streamin[ 425.306396] video2: VIDIOC_ENUMINPUT: error -22: index=1, name=, type=0, audioset=0x0, tuner=0, std=0x00000000, status=0x0, capabilities=0x0
> g
> supported norms:
> inputs: 0 = camera;[ 425.323822] video2: VIDIOC_G_INPUT: value=0
>
> Current input: 0
> [ 425.332580] video2: VIDIOC_ENUM_FMT: error -25: index=0, type=vid-cap, flags=0x0, pixelformat=, description=''
> Current format: unknown (0x0)
> [ 425.345428] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.367858] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.386627] video2: VIDIOC_G_FMT: type=vid-cap, width=640, height=480, pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.405334] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, pixelformat=UYVY, field=none, bytesperline=1280, sizeimage=614400, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.425720] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, audioset=0x0, tuner=0, std=0x00000000, status=0x0, capabilities=0x0
> [ 425.439727] video2: VIDIOC_S_INPUT: value=0
> [ 425.445159] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
> tv.c: norm_from_string(pal): Bogus norm paramete[ 425.455871] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
> r, setting default.
> v4l2: ioctl enum norm failed: In[ 425.470397] video2: VIDIOC_G_FMT: type=vid-cap, width=640, height=480, pixelformat=UYVY, field=none, bytesperline=1280, sizeimage=614400, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> appropriate ioctl for device
> Error: Cannot set [ 425.493743] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> norm!
> [ 425.517669] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.538238] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.558990] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> Selected input hasn't got a tuner!
> [ 425.600646] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.623840] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.644317] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [ 425.676971] video2: VIDIOC_REQBUFS: count=2, type=vid-cap, memory=mmap
> [ 425.684082] video2: VIDIOC_QUERYBUF: 00:00:00.00000000 index=0, type=vid-cap, flags=0x00002000, field=any, sequence=0, memory=mmap, bytesused=0, offset/userptr=0x0, length=2621440
> [ 425.702117] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
> [ 425.713073] video2: mmap (0)
> [ 425.716400] video2: VIDIOC_QBUF: 00:00:00.00000000 index=0, type=vid-cap, flags=0x00002003, field=any, sequence=0, memory=mmap, bytesused=2621440, offset/userptr=0x0, length=2621440
> [ 425.734436] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
> [ 425.743499] video2: VIDIOC_QUERYBUF: 00:00:00.00000000 index=1, type=vid-cap, flags=0x00002000, field=any, sequence=0, memory=mmap, bytesused=0, offset/userptr=0x280000, length=2621440
> [ 425.761688] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
> [ 425.772186] video2: mmap (0)
> [ 425.775299] video2: VIDIOC_QBUF: 00:00:00.00000000 index=1, type=vid-cap, flags=0x00002003, field=any, sequence=0, memory=mmap, bytesused=2621440, offset/userptr=0x280000, length=2621440
> [ 425.793670] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
> [ 425.802703] video2: VIDIOC_S_CTRL: error -25: id=0x980909, value=0
> v4l2: ioctl set mute failed: Inappropriate ioctl[ 425.809661] video2: VIDIOC_QUERYCTRL: error -25: id=0x980900, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
> for device
> v4l2: ioctl query control failed: Inappropriate [ 425.826965] video2: VIDIOC_QUERYCTRL: error -25: id=0x980903, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
> ioctl for device
> v4l2: ioctl query control failed[ 425.844055] video2: VIDIOC_QUERYCTRL: error -25: id=0x980902, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
> : Inappropriate ioctl for device
> v4l2: ioctl quer[ 425.860198] video2: VIDIOC_QUERYCTRL: error -25: id=0x980901, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
> y control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> [ 425.930206] configuring for 1280(2560)x1024
> [ 425.943481] omap3isp 480bc000.isp: -------------CCDC Register dump-------------
> [ 425.951171] omap3isp 480bc000.isp: ###CCDC PCR=0x00000000
> [ 425.958007] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
> [ 425.964996] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x00000000
> [ 425.972656] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x00000000
> [ 425.978881] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x000004ff
> [ 425.986114] omap3isp 480bc000.isp: ###CCDC VERT_START=0x00000000
> [ 425.993255] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x000003ff
> [ 425.999694] omap3isp 480bc000.isp: ###CCDC CULLING=0xffff00ff
> [ 426.006530] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x00000a00
> [ 426.013580] omap3isp 480bc000.isp: ###CCDC SDOFST=0x00000000
> [ 426.019531] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x40000000
> [ 426.026550] omap3isp 480bc000.isp: ###CCDC CLAMP=0x00000010
> [ 426.033142] omap3isp 480bc000.isp: ###CCDC DCSUB=0x00000000
> [ 426.039123] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
> [ 426.046020] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x00000000
> [ 426.052795] omap3isp 480bc000.isp: ###CCDC FPC=0x00000000
> [ 426.058532] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x00000000
> [ 426.065551] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
> [ 426.072143] omap3isp 480bc000.isp: ###CCDC ALAW=0x00000006
> [ 426.078033] omap3isp 480bc000.isp: ###CCDC REC656IF=0x00000000
> [ 426.084960] omap3isp 480bc000.isp: ###CCDC CFG=0x00008800
> [ 426.090759] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x00000000
> [ 426.097869] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x00000000
> [ 426.104949] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x00000000
> [ 426.111053] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x00000000
> [ 426.118103] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x00000000
> [ 426.124999] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x00000000
> [ 426.131164] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x00000000
> [ 426.138000] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x00000000
> [ 426.144744] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x00006600
> [ 426.151062] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x00000000
> [ 426.158325] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x00000000
> [ 426.165740] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x00000000
> [ 426.173400] omap3isp 480bc000.isp: --------------------------------------------
> [ 426.188140] video2: VIDIOC_STREAMON: type=vid-cap
> [ 426.194244] video2: poll: 00000000
> [ass] auto-open
> Opening video filter: [rotate=2]
> VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> [swscaler @ 0xb5d45980]using unscaled uyvy422 -> yuv420p special converter
> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
> [swscaler @ 0xb5d45980]No accelerated colorspace conversion found from yuv420p to bgra.
> Colorspace details not fully supported by selected vo.
> Selected video codec: RAW UYVY [raw]
> Audio: no sound
> Starting playback...
> [ 427.194793] video2: poll: 00000000
> v4l2: select timeout
> [ 427.203033] video2: poll: 00000000
> [ 428.204498] video2: poll: 00000000
>
> v4l2: select timeout
> [ 428.215667] video2: poll: 00000000
> [ 429.217102] video2: poll: 00000000
>
> v4l2: select timeout
> [ 429.233978] video2: poll: 00000000
> [ 430.235656] video2: poll: 00000000
>
> v4l2: select timeout
> [ 430.240661] video2: poll: 00000000
> [ 431.242889] video2: poll: 00000000
>
> v4l2: select timeout
> [ 431.249114] video2: poll: 00000000
> V: 0.0 6/ 6 ??% ??% ??,?% 0 0
>
>
> MPlayer interrupted by signal 2 in module: filter_video
> [ 432.251220] video2: poll: 00000000
> v4l2: select timeout
> [ 432.256713] video2: poll: 00000000
> [ 433.258941] video2: poll: 00000000
>
> v4l2: select timeout
> [ 433.266632] omap3isp 480bc000.isp: OMAP3 ISP AEWB: user wants to disable module.
> [ 433.280090] omap3isp 480bc000.isp: OMAP3 ISP AEWB: module is being disabled
> [ 433.290130] omap3isp 480bc000.isp: OMAP3 ISP AF: user wants to disable module.
> [ 433.300140] omap3isp 480bc000.isp: OMAP3 ISP AF: module is being disabled
> [ 433.309631] omap3isp 480bc000.isp: OMAP3 ISP histogram: user wants to disable module.
> [ 433.319885] omap3isp 480bc000.isp: OMAP3 ISP histogram: module is being disabled
> [ 435.373168] omap3isp 480bc000.isp: CCDC stop timeout!
> [ 435.380371] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC
> [ 435.391754] video2: VIDIOC_STREAMOFF: type=vid-cap
> [ 435.397583] video2: VIDIOC_DQBUF: error -22: 00:00:00.00000000 index=0, type=vid-cap, flags=0x00000000, field=any, sequence=0, memory=mmap, bytesused=0, offset/userptr=0x0, length=0
> [ 435.417175] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
> [ 435.431549] video2: VIDIOC_S_CTRL: error -25: id=0x980909, value=1
> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> [ 435.495422] video2: release
> v4l2: 0 frames successfully processed, 1 frames dropped.
>
> Exiting... (Quit)
> root@letux:~#

Seem as if it tells me not much more than setting "pal" norm does fail and there is no "MUTE".
VIDIOC_STREAMON is successful and the poll times out.

Anyways, this indicates that the problem is probably not in the v4l2 layer but below, i.e. omap3isp+camera.

Maybe as simple as the ISP ignoring the SYNC inputs and then of course failing to capture frames within given time.
I have checked our pinmux setup but didn't find anything suspicious.

So is it somehow possible to check if the omap3isp is running and receiving sync inpulses?

BR and thanks,
Nikolaus


2017-07-03 12:03:55

by Hugues Fruchet

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus,

nothing really strange in trace, I wanted to check the latest S_FMT and
it is well 1280x1024 YUV:
>> [ 425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280,
height=1024, pixelformat=UYVY, field=none, bytesperline=2560,
sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0,
xfer_func=0

You're right that it seems that the ISP is not seeing any data in input.
Have you double checked the polarities of sync signals ? I see
differences in devicetree:
960 ov9655: endpoint {
961 remote-endpoint = <&parallel_ep>;
962 #if 0 // not used by camera driver - define &parellel_ep for isp
963 bus-width = <8>;
964 data-shift = <2>; /* Lines
9:2 are used */
965 hsync-active = <1>; /* Active
high */
966 vsync-active = <1>; /* Active
high */
967 data-active = <1>; /* Active
high */
968 pclk-sample = <1>; /* Rising */
969 #endif

Which has been commented out in flavour of:

1011 /* parallel camera interface */
1012 &parallel_ep {
1013 remote-endpoint = <&ov9655>;
1014 ti,isp-clock-divisor = <1>;
1015 ti,strobe-mode;
1016 bus-width = <8>;/* Used data lines */
1017 data-shift = <2>; /* Lines 9:2 are used */
1018 hsync-active = <0>; /* Active low */
1019 vsync-active = <1>; /* Active high */
1020 data-active = <1>;/* Active high */
1021 pclk-sample = <1>;/* Rising */
1022 };

there is a difference regarding active level of hsync.

Nevertheless seems OK if I check OMAP3 ISP register:
CCDC SYN_MODE=0x00071704
#define ISPCCDC_SYN_MODE_VDPOL (1 << 2)
#define ISPCCDC_SYN_MODE_HDPOL (1 << 3)

seems well that vertical is 1 and horizontal is 0.


BR,
Hugues.

On 07/03/2017 11:14 AM, H. Nikolaus Schaller wrote:
> Hi Hugues,
>
>> Am 03.07.2017 um 10:16 schrieb Hugues FRUCHET <[email protected]>:
>>
>> Hi Nikolaus,
>> Could you enable V4L2 UAPI traces ? Something like:
>> echo 0xFF > /sys/devices/platform/soc/<isp address>.<isp
>> name>/video4linux/video2/dev_debug
>>
>> you will see then in kernel dmesg the V4L2 calls and their
>> parameters/return values.
>
> Nice.
>
>> root@letux:~# echo 255 >/sys/devices/platform/68000000.ocp/480bc000.isp/video4linux/video2/dev_debug
>> root@letux:~# ./camera-demo sxga
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski <[email protected]>
>> comment: first try, more to come ;-)
>> [ 425.216094] video2: open (0)
>> [ 425.219329] video2: VIDIOC_QUERYCAP: driver=ispvideo, card=OMAP3 ISP CCDC output, bus=media, version=0x00040c00, capabilities=0x84200003, device_caps=0x04200001
>> [ 425.236389] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.254699] video2: VIDIOC_G_STD: error -25: std=0x00000000
>> [ 425.260620] video2: VIDIOC_G_PARM: error -22: type=vid-cap, capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0, readbuffers=0
>> v4l2: ioctl get standard failed: Invalid argumen[ 425.275573] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
>> t
>> Selected device: OMAP3 ISP CCDC output
>> Capa[ 425.289398] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, audioset=0x0, tuner=0, std=0x00000000, status=0x0, capabilities=0x0
>> bilities: video capture video output streamin[ 425.306396] video2: VIDIOC_ENUMINPUT: error -22: index=1, name=, type=0, audioset=0x0, tuner=0, std=0x00000000, status=0x0, capabilities=0x0
>> g
>> supported norms:
>> inputs: 0 = camera;[ 425.323822] video2: VIDIOC_G_INPUT: value=0
>>
>> Current input: 0
>> [ 425.332580] video2: VIDIOC_ENUM_FMT: error -25: index=0, type=vid-cap, flags=0x0, pixelformat=, description=''
>> Current format: unknown (0x0)
>> [ 425.345428] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.367858] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.386627] video2: VIDIOC_G_FMT: type=vid-cap, width=640, height=480, pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.405334] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, pixelformat=UYVY, field=none, bytesperline=1280, sizeimage=614400, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.425720] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, audioset=0x0, tuner=0, std=0x00000000, status=0x0, capabilities=0x0
>> [ 425.439727] video2: VIDIOC_S_INPUT: value=0
>> [ 425.445159] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
>> tv.c: norm_from_string(pal): Bogus norm paramete[ 425.455871] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
>> r, setting default.
>> v4l2: ioctl enum norm failed: In[ 425.470397] video2: VIDIOC_G_FMT: type=vid-cap, width=640, height=480, pixelformat=UYVY, field=none, bytesperline=1280, sizeimage=614400, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> appropriate ioctl for device
>> Error: Cannot set [ 425.493743] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> norm!
>> [ 425.517669] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.538238] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.558990] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> Selected input hasn't got a tuner!
>> [ 425.600646] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.623840] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.644317] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [ 425.676971] video2: VIDIOC_REQBUFS: count=2, type=vid-cap, memory=mmap
>> [ 425.684082] video2: VIDIOC_QUERYBUF: 00:00:00.00000000 index=0, type=vid-cap, flags=0x00002000, field=any, sequence=0, memory=mmap, bytesused=0, offset/userptr=0x0, length=2621440
>> [ 425.702117] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
>> [ 425.713073] video2: mmap (0)
>> [ 425.716400] video2: VIDIOC_QBUF: 00:00:00.00000000 index=0, type=vid-cap, flags=0x00002003, field=any, sequence=0, memory=mmap, bytesused=2621440, offset/userptr=0x0, length=2621440
>> [ 425.734436] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
>> [ 425.743499] video2: VIDIOC_QUERYBUF: 00:00:00.00000000 index=1, type=vid-cap, flags=0x00002000, field=any, sequence=0, memory=mmap, bytesused=0, offset/userptr=0x280000, length=2621440
>> [ 425.761688] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
>> [ 425.772186] video2: mmap (0)
>> [ 425.775299] video2: VIDIOC_QBUF: 00:00:00.00000000 index=1, type=vid-cap, flags=0x00002003, field=any, sequence=0, memory=mmap, bytesused=2621440, offset/userptr=0x280000, length=2621440
>> [ 425.793670] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
>> [ 425.802703] video2: VIDIOC_S_CTRL: error -25: id=0x980909, value=0
>> v4l2: ioctl set mute failed: Inappropriate ioctl[ 425.809661] video2: VIDIOC_QUERYCTRL: error -25: id=0x980900, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
>> for device
>> v4l2: ioctl query control failed: Inappropriate [ 425.826965] video2: VIDIOC_QUERYCTRL: error -25: id=0x980903, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
>> ioctl for device
>> v4l2: ioctl query control failed[ 425.844055] video2: VIDIOC_QUERYCTRL: error -25: id=0x980902, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
>> : Inappropriate ioctl for device
>> v4l2: ioctl quer[ 425.860198] video2: VIDIOC_QUERYCTRL: error -25: id=0x980901, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
>> y control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> [ 425.930206] configuring for 1280(2560)x1024
>> [ 425.943481] omap3isp 480bc000.isp: -------------CCDC Register dump-------------
>> [ 425.951171] omap3isp 480bc000.isp: ###CCDC PCR=0x00000000
>> [ 425.958007] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
>> [ 425.964996] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x00000000
>> [ 425.972656] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x00000000
>> [ 425.978881] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x000004ff
>> [ 425.986114] omap3isp 480bc000.isp: ###CCDC VERT_START=0x00000000
>> [ 425.993255] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x000003ff
>> [ 425.999694] omap3isp 480bc000.isp: ###CCDC CULLING=0xffff00ff
>> [ 426.006530] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x00000a00
>> [ 426.013580] omap3isp 480bc000.isp: ###CCDC SDOFST=0x00000000
>> [ 426.019531] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x40000000
>> [ 426.026550] omap3isp 480bc000.isp: ###CCDC CLAMP=0x00000010
>> [ 426.033142] omap3isp 480bc000.isp: ###CCDC DCSUB=0x00000000
>> [ 426.039123] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
>> [ 426.046020] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x00000000
>> [ 426.052795] omap3isp 480bc000.isp: ###CCDC FPC=0x00000000
>> [ 426.058532] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x00000000
>> [ 426.065551] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
>> [ 426.072143] omap3isp 480bc000.isp: ###CCDC ALAW=0x00000006
>> [ 426.078033] omap3isp 480bc000.isp: ###CCDC REC656IF=0x00000000
>> [ 426.084960] omap3isp 480bc000.isp: ###CCDC CFG=0x00008800
>> [ 426.090759] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x00000000
>> [ 426.097869] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x00000000
>> [ 426.104949] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x00000000
>> [ 426.111053] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x00000000
>> [ 426.118103] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x00000000
>> [ 426.124999] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x00000000
>> [ 426.131164] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x00000000
>> [ 426.138000] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x00000000
>> [ 426.144744] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x00006600
>> [ 426.151062] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x00000000
>> [ 426.158325] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x00000000
>> [ 426.165740] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x00000000
>> [ 426.173400] omap3isp 480bc000.isp: --------------------------------------------
>> [ 426.188140] video2: VIDIOC_STREAMON: type=vid-cap
>> [ 426.194244] video2: poll: 00000000
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO: 1280x1024 15.000 fps 0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5d45980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5d45980]No accelerated colorspace conversion found from yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> [ 427.194793] video2: poll: 00000000
>> v4l2: select timeout
>> [ 427.203033] video2: poll: 00000000
>> [ 428.204498] video2: poll: 00000000
>>
>> v4l2: select timeout
>> [ 428.215667] video2: poll: 00000000
>> [ 429.217102] video2: poll: 00000000
>>
>> v4l2: select timeout
>> [ 429.233978] video2: poll: 00000000
>> [ 430.235656] video2: poll: 00000000
>>
>> v4l2: select timeout
>> [ 430.240661] video2: poll: 00000000
>> [ 431.242889] video2: poll: 00000000
>>
>> v4l2: select timeout
>> [ 431.249114] video2: poll: 00000000
>> V: 0.0 6/ 6 ??% ??% ??,?% 0 0
>>
>>
>> MPlayer interrupted by signal 2 in module: filter_video
>> [ 432.251220] video2: poll: 00000000
>> v4l2: select timeout
>> [ 432.256713] video2: poll: 00000000
>> [ 433.258941] video2: poll: 00000000
>>
>> v4l2: select timeout
>> [ 433.266632] omap3isp 480bc000.isp: OMAP3 ISP AEWB: user wants to disable module.
>> [ 433.280090] omap3isp 480bc000.isp: OMAP3 ISP AEWB: module is being disabled
>> [ 433.290130] omap3isp 480bc000.isp: OMAP3 ISP AF: user wants to disable module.
>> [ 433.300140] omap3isp 480bc000.isp: OMAP3 ISP AF: module is being disabled
>> [ 433.309631] omap3isp 480bc000.isp: OMAP3 ISP histogram: user wants to disable module.
>> [ 433.319885] omap3isp 480bc000.isp: OMAP3 ISP histogram: module is being disabled
>> [ 435.373168] omap3isp 480bc000.isp: CCDC stop timeout!
>> [ 435.380371] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC
>> [ 435.391754] video2: VIDIOC_STREAMOFF: type=vid-cap
>> [ 435.397583] video2: VIDIOC_DQBUF: error -22: 00:00:00.00000000 index=0, type=vid-cap, flags=0x00000000, field=any, sequence=0, memory=mmap, bytesused=0, offset/userptr=0x0, length=0
>> [ 435.417175] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
>> [ 435.431549] video2: VIDIOC_S_CTRL: error -25: id=0x980909, value=1
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> [ 435.495422] video2: release
>> v4l2: 0 frames successfully processed, 1 frames dropped.
>>
>> Exiting... (Quit)
>> root@letux:~#
>
> Seem as if it tells me not much more than setting "pal" norm does fail and there is no "MUTE".
> VIDIOC_STREAMON is successful and the poll times out.
>
> Anyways, this indicates that the problem is probably not in the v4l2 layer but below, i.e. omap3isp+camera.
>
> Maybe as simple as the ISP ignoring the SYNC inputs and then of course failing to capture frames within given time.
> I have checked our pinmux setup but didn't find anything suspicious.
>
> So is it somehow possible to check if the omap3isp is running and receiving sync inpulses?
>
> BR and thanks,
> Nikolaus
>

2017-07-03 12:23:46

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Hugues,

> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET <[email protected]>:
>
> Hi Nikolaus,
>
> nothing really strange in trace, I wanted to check the latest S_FMT and
> it is well 1280x1024 YUV:
>>> [ 425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280,
> height=1024, pixelformat=UYVY, field=none, bytesperline=2560,
> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0,
> xfer_func=0
>

Thanks for cross-checking.

> You're right that it seems that the ISP is not seeing any data in input.
> Have you double checked the polarities of sync signals ? I see
> differences in devicetree:
> 960 ov9655: endpoint {
> 961 remote-endpoint = <&parallel_ep>;
> 962 #if 0 // not used by camera driver - define &parellel_ep for isp
> 963 bus-width = <8>;
> 964 data-shift = <2>; /* Lines
> 9:2 are used */
> 965 hsync-active = <1>; /* Active
> high */
> 966 vsync-active = <1>; /* Active
> high */
> 967 data-active = <1>; /* Active
> high */
> 968 pclk-sample = <1>; /* Rising */
> 969 #endif
>
> Which has been commented out in flavour of:
>
> 1011 /* parallel camera interface */
> 1012 &parallel_ep {
> 1013 remote-endpoint = <&ov9655>;
> 1014 ti,isp-clock-divisor = <1>;
> 1015 ti,strobe-mode;
> 1016 bus-width = <8>;/* Used data lines */
> 1017 data-shift = <2>; /* Lines 9:2 are used */
> 1018 hsync-active = <0>; /* Active low */
> 1019 vsync-active = <1>; /* Active high */
> 1020 data-active = <1>;/* Active high */
> 1021 pclk-sample = <1>;/* Rising */
> 1022 };
>
> there is a difference regarding active level of hsync.

Yes, this is from experimenting with our driver patch series to
do the setup in the camera driver. Both chips can configure polarities
but we now have only system defaults in the camera driver. Therefore,
it is commented out for the camera DT node.

The problem is that we never had all this working in DT mode so
our setup here might indeed be buggy.

On the other hand the polarity (HSYNC act. low and VSYNC act. high)
does match the signals seen by oscilloscope.

I will try asap if this makes a difference. There are only 4 combinations...

My expectation is that wrong polarity would only move the
active trigger point around so that I would expect an image
shifted left/right or up/down.

But I don't know enough details of the isp. If it is triggering
sync not by edge but by state and stopping capture for the wrong
state of the sync signal it might not receive enough lines or pixels
as it was initialized for and therefore it may simply wait for
more data instead of reporting "done with 1280x1024 pixels".

>
> Nevertheless seems OK if I check OMAP3 ISP register:
> CCDC SYN_MODE=0x00071704
> #define ISPCCDC_SYN_MODE_VDPOL (1 << 2)
> #define ISPCCDC_SYN_MODE_HDPOL (1 << 3)
>
> seems well that vertical is 1 and horizontal is 0.
>

BR and thanks,
Nikolaus

2017-07-05 14:02:17

by H. Nikolaus Schaller

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Sakari,

> Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller <[email protected]>:
>
> Hi Hugues,
>
>> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET <[email protected]>:
>>
>> Hi Nikolaus,
>>
>> nothing really strange in trace, I wanted to check the latest S_FMT and
>> it is well 1280x1024 YUV:
>>>> [ 425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280,
>> height=1024, pixelformat=UYVY, field=none, bytesperline=2560,
>> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0,
>> xfer_func=0
>>
>
> Thanks for cross-checking.
>
>> You're right that it seems that the ISP is not seeing any data in input.
>> Have you double checked the polarities of sync signals ? I see
>> differences in devicetree:
>> 960 ov9655: endpoint {
>> 961 remote-endpoint = <&parallel_ep>;
>> 962 #if 0 // not used by camera driver - define &parellel_ep for isp
>> 963 bus-width = <8>;
>> 964 data-shift = <2>; /* Lines
>> 9:2 are used */
>> 965 hsync-active = <1>; /* Active
>> high */
>> 966 vsync-active = <1>; /* Active
>> high */
>> 967 data-active = <1>; /* Active
>> high */
>> 968 pclk-sample = <1>; /* Rising */
>> 969 #endif
>>
>> Which has been commented out in flavour of:
>>
>> 1011 /* parallel camera interface */
>> 1012 &parallel_ep {
>> 1013 remote-endpoint = <&ov9655>;
>> 1014 ti,isp-clock-divisor = <1>;
>> 1015 ti,strobe-mode;
>> 1016 bus-width = <8>;/* Used data lines */
>> 1017 data-shift = <2>; /* Lines 9:2 are used */
>> 1018 hsync-active = <0>; /* Active low */
>> 1019 vsync-active = <1>; /* Active high */
>> 1020 data-active = <1>;/* Active high */
>> 1021 pclk-sample = <1>;/* Rising */
>> 1022 };
>>
>> there is a difference regarding active level of hsync.
>
> Yes, this is from experimenting with our driver patch series to
> do the setup in the camera driver. Both chips can configure polarities
> but we now have only system defaults in the camera driver. Therefore,
> it is commented out for the camera DT node.
>
> The problem is that we never had all this working in DT mode so
> our setup here might indeed be buggy.
>
> On the other hand the polarity (HSYNC act. low and VSYNC act. high)
> does match the signals seen by oscilloscope.
>
> I will try asap if this makes a difference. There are only 4 combinations...
>
> My expectation is that wrong polarity would only move the
> active trigger point around so that I would expect an image
> shifted left/right or up/down.
>
> But I don't know enough details of the isp. If it is triggering
> sync not by edge but by state and stopping capture for the wrong
> state of the sync signal it might not receive enough lines or pixels
> as it was initialized for and therefore it may simply wait for
> more data instead of reporting "done with 1280x1024 pixels".
>
>>
>> Nevertheless seems OK if I check OMAP3 ISP register:
>> CCDC SYN_MODE=0x00071704
>> #define ISPCCDC_SYN_MODE_VDPOL (1 << 2)
>> #define ISPCCDC_SYN_MODE_HDPOL (1 << 3)
>>
>> seems well that vertical is 1 and horizontal is 0.
>>

I found your old e-mail with a similar issue (CCDC stop timeout):

https://www.spinics.net/lists/linux-media/msg60096.html

It looks as if our media-ctl commands are almost the same as in
the example given by Adriano and it confirms that /dev/video2
is the right channel.

In your answer you recommended to check /proc/interrupts which
did help Adriano.

Yes, we see the "OMAP3 ISP" entry go up roughly with 15-20
interrupts per second. This means VSYNC seems to arrive at ~15 fps.

But we still have the timeouts and no image in mplayer.

Can we easily check if HSYNC is also arriving at the CCDC or has
wrong polarity?

BR and thanks,
Nikolaus


2017-07-08 20:55:59

by Sakari Ailus

[permalink] [raw]
Subject: Re: [PATCH v1 0/6] Add support of OV9655 camera

Hi Nikolaus,

On Wed, Jul 05, 2017 at 04:02:04PM +0200, H. Nikolaus Schaller wrote:
> Hi Sakari,
>
> > Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller <[email protected]>:
> >
> > Hi Hugues,
> >
> >> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET <[email protected]>:
> >>
> >> Hi Nikolaus,
> >>
> >> nothing really strange in trace, I wanted to check the latest S_FMT and
> >> it is well 1280x1024 YUV:
> >>>> [ 425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280,
> >> height=1024, pixelformat=UYVY, field=none, bytesperline=2560,
> >> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0,
> >> xfer_func=0
> >>
> >
> > Thanks for cross-checking.
> >
> >> You're right that it seems that the ISP is not seeing any data in input.
> >> Have you double checked the polarities of sync signals ? I see
> >> differences in devicetree:
> >> 960 ov9655: endpoint {
> >> 961 remote-endpoint = <&parallel_ep>;
> >> 962 #if 0 // not used by camera driver - define &parellel_ep for isp
> >> 963 bus-width = <8>;
> >> 964 data-shift = <2>; /* Lines
> >> 9:2 are used */
> >> 965 hsync-active = <1>; /* Active
> >> high */
> >> 966 vsync-active = <1>; /* Active
> >> high */
> >> 967 data-active = <1>; /* Active
> >> high */
> >> 968 pclk-sample = <1>; /* Rising */
> >> 969 #endif
> >>
> >> Which has been commented out in flavour of:
> >>
> >> 1011 /* parallel camera interface */
> >> 1012 &parallel_ep {
> >> 1013 remote-endpoint = <&ov9655>;
> >> 1014 ti,isp-clock-divisor = <1>;
> >> 1015 ti,strobe-mode;
> >> 1016 bus-width = <8>;/* Used data lines */
> >> 1017 data-shift = <2>; /* Lines 9:2 are used */
> >> 1018 hsync-active = <0>; /* Active low */
> >> 1019 vsync-active = <1>; /* Active high */
> >> 1020 data-active = <1>;/* Active high */
> >> 1021 pclk-sample = <1>;/* Rising */
> >> 1022 };
> >>
> >> there is a difference regarding active level of hsync.
> >
> > Yes, this is from experimenting with our driver patch series to
> > do the setup in the camera driver. Both chips can configure polarities
> > but we now have only system defaults in the camera driver. Therefore,
> > it is commented out for the camera DT node.
> >
> > The problem is that we never had all this working in DT mode so
> > our setup here might indeed be buggy.
> >
> > On the other hand the polarity (HSYNC act. low and VSYNC act. high)
> > does match the signals seen by oscilloscope.
> >
> > I will try asap if this makes a difference. There are only 4 combinations...
> >
> > My expectation is that wrong polarity would only move the
> > active trigger point around so that I would expect an image
> > shifted left/right or up/down.
> >
> > But I don't know enough details of the isp. If it is triggering
> > sync not by edge but by state and stopping capture for the wrong
> > state of the sync signal it might not receive enough lines or pixels
> > as it was initialized for and therefore it may simply wait for
> > more data instead of reporting "done with 1280x1024 pixels".
> >
> >>
> >> Nevertheless seems OK if I check OMAP3 ISP register:
> >> CCDC SYN_MODE=0x00071704
> >> #define ISPCCDC_SYN_MODE_VDPOL (1 << 2)
> >> #define ISPCCDC_SYN_MODE_HDPOL (1 << 3)
> >>
> >> seems well that vertical is 1 and horizontal is 0.
> >>
>
> I found your old e-mail with a similar issue (CCDC stop timeout):
>
> https://www.spinics.net/lists/linux-media/msg60096.html
>
> It looks as if our media-ctl commands are almost the same as in
> the example given by Adriano and it confirms that /dev/video2
> is the right channel.
>
> In your answer you recommended to check /proc/interrupts which
> did help Adriano.
>
> Yes, we see the "OMAP3 ISP" entry go up roughly with 15-20
> interrupts per second. This means VSYNC seems to arrive at ~15 fps.
>
> But we still have the timeouts and no image in mplayer.
>
> Can we easily check if HSYNC is also arriving at the CCDC or has
> wrong polarity?

What you can try to switch the polarity in CCDC configuration. The CCDC
processes a pre-determined number of lines and if the hsync polarity
configuration is wrong, it will likely end up missing one. This should be
especially easy to misconfigure with serial busses but this isn't the
problem here as you have a parallel bus. You could try switching the vsync
polarity, too.

There are probably better informed people around, I've never used the
parallel interface (except with the CCP2 / CSI-2 receivers).

--
Regards,

Sakari Ailus
e-mail: [email protected] XMPP: [email protected]