[PATCH v9 0/2] Add support for Omnivision OV5647

[PATCH v9 0/2] Add support for Omnivision OV5647

[Ramiro Oliveira]

Hello,

This patchset adds support for the Omnivision OV5647 sensor.

At the moment it only supports 640x480 in RAW 8.

This is the ninth version of the OV5647 camera driver patchset.

v9:
 - Remove unused struct
 - Remove comments
 - Refactor error handling in i2c r/w functions
 - Change declarations to single line.
 - Remove value assignment in variable declarion
 - Refactor configurion write loop 
 - Change the variable type that received ov5647_read() read value
 - Remove print from probe function
 - Remove unused device struct
 - Remove OF dependency from Kconfig
Suggested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>

v8:
 - Remove a part of the initialization procedure which wasn't doing 
 anything
 - Check for i2c read/writes return values
 - Add stream_on/off functions
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>

v7:
 - Remove "0x" and leading 0 from DT documentation examples

v6:
 - Add example to DT documentation
 - Remove data-lanes and clock-lane property from DT
 - Add external clock property to DT
 - Order includes
 - Remove unused variables and functions
 - Add external clock handling
 - Add power on counter
 - Change from g/s_parm to g/s_frame_interval

v5:
 - Refactor code 
 - Change comments
 - Add missing error handling in some functions

v4: 
 - Add correct license
 - Revert debugging info to generic infrastructure
 - Turn defines into enums
 - Correct code style issues
 - Remove unused defines
 - Make sure all errors where being handled
 - Rename some functions to make code more readable
 - Add some debugging info

v3: 
 - No changes. Re-submitted due to lack of responses

v2: 
 - Corrections in DT documentation


Ramiro Oliveira (2):
  Add OV5647 device tree documentation
  Add support for OV5647 sensor.

 .../devicetree/bindings/media/i2c/ov5647.txt       |  35 ++
 MAINTAINERS                                        |   7 +
 drivers/media/i2c/Kconfig                          |  11 +
 drivers/media/i2c/Makefile                         |   1 +
 drivers/media/i2c/ov5647.c                         | 638 +++++++++++++++++++++
 5 files changed, 692 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
 create mode 100644 drivers/media/i2c/ov5647.c

-- 
2.11.0

[PATCH v9 0/2] Add support for Omnivision OV5647

[Ramiro Oliveira]

Hello,

This patchset adds support for the Omnivision OV5647 sensor.

At the moment it only supports 640x480 in RAW 8.

This is the ninth version of the OV5647 camera driver patchset.

v9:
 - Remove unused struct
 - Remove comments
 - Refactor error handling in i2c r/w functions
 - Change declarations to single line.
 - Remove value assignment in variable declarion
 - Refactor configurion write loop 
 - Change the variable type that received ov5647_read() read value
 - Remove print from probe function
 - Remove unused device struct
 - Remove OF dependency from Kconfig
Suggested-by: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>

v8:
 - Remove a part of the initialization procedure which wasn't doing 
 anything
 - Check for i2c read/writes return values
 - Add stream_on/off functions
Suggested-by: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

v7:
 - Remove "0x" and leading 0 from DT documentation examples

v6:
 - Add example to DT documentation
 - Remove data-lanes and clock-lane property from DT
 - Add external clock property to DT
 - Order includes
 - Remove unused variables and functions
 - Add external clock handling
 - Add power on counter
 - Change from g/s_parm to g/s_frame_interval

v5:
 - Refactor code 
 - Change comments
 - Add missing error handling in some functions

v4: 
 - Add correct license
 - Revert debugging info to generic infrastructure
 - Turn defines into enums
 - Correct code style issues
 - Remove unused defines
 - Make sure all errors where being handled
 - Rename some functions to make code more readable
 - Add some debugging info

v3: 
 - No changes. Re-submitted due to lack of responses

v2: 
 - Corrections in DT documentation


Ramiro Oliveira (2):
  Add OV5647 device tree documentation
  Add support for OV5647 sensor.

 .../devicetree/bindings/media/i2c/ov5647.txt       |  35 ++
 MAINTAINERS                                        |   7 +
 drivers/media/i2c/Kconfig                          |  11 +
 drivers/media/i2c/Makefile                         |   1 +
 drivers/media/i2c/ov5647.c                         | 638 +++++++++++++++++++++
 5 files changed, 692 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
 create mode 100644 drivers/media/i2c/ov5647.c

-- 
2.11.0


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Create device tree bindings documentation.

Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
new file mode 100644
index 000000000000..31956426d3b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
@@ -0,0 +1,35 @@
+Omnivision OV5647 raw image sensor
+---------------------------------
+
+OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
+and CCI (I2C compatible) control bus.
+
+Required properties:
+
+- compatible		: "ovti,ov5647".
+- reg			: I2C slave address of the sensor.
+- clocks		: Reference to the xclk clock.
+- clock-names		: Should be "xclk".
+- clock-frequency	: Frequency of the xclk clock.
+
+The common video interfaces bindings (see video-interfaces.txt) should be
+used to specify link to the image data receiver. The OV5647 device
+node should contain one 'port' child node with an 'endpoint' subnode.
+
+Example:
+
+	i2c@2000 {
+		...
+		ov: camera@36 {
+			compatible = "ovti,ov5647";
+			reg = <0x36>;
+			clocks = <&camera_clk>;
+			clock-names = "xclk";
+			clock-frequency = <25000000>;
+			port {
+				camera_1: endpoint {
+					remote-endpoint = <&csi1_ep1>;
+				};
+			};
+		};
+	};
-- 
2.11.0

[PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
and RAW 10 output formats, and MIPI CSI-2 interface.

The driver adds support for 640x480 RAW 8.

Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
 MAINTAINERS                |   7 +
 drivers/media/i2c/Kconfig  |  11 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 657 insertions(+)
 create mode 100644 drivers/media/i2c/ov5647.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e7e8d7855ee..7bbca271acc8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9109,6 +9109,13 @@ M:	Harald Welte <laforge@gnumonks.org>
 S:	Maintained
 F:	drivers/char/pcmcia/cm4040_cs.*
 
+OMNIVISION OV5647 SENSOR DRIVER
+M:	Ramiro Oliveira <roliveir@synopsys.com>
+L:	linux-media@vger.kernel.org
+T:	git git://linuxtv.org/media_tree.git
+S:	Maintained
+F:	drivers/media/i2c/ov5647.c
+
 OMNIVISION OV7670 SENSOR DRIVER
 M:	Jonathan Corbet <corbet@lwn.net>
 L:	linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cee1dae6e014..8435b99f38bc 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -531,6 +531,17 @@ config VIDEO_OV2659
 	  To compile this driver as a module, choose M here: the
 	  module will be called ov2659.
 
+config VIDEO_OV5647
+	tristate "OmniVision OV5647 sensor support"
+	depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+	depends on MEDIA_CAMERA_SUPPORT
+	---help---
+	  This is a Video4Linux2 sensor-level driver for the OmniVision
+	  OV5647 camera.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called ov5647.
+
 config VIDEO_OV7640
 	tristate "OmniVision OV7640 sensor support"
 	depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 5bc7bbeb5499..ef2ccf65f94c 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)	+= ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659)	+= ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)	+= tc358743.o
+obj-$(CONFIG_VIDEO_OV5647)	+= ov5647.o
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
new file mode 100644
index 000000000000..34e620fabbaf
--- /dev/null
+++ b/drivers/media/i2c/ov5647.c
@@ -0,0 +1,638 @@
+/*
+ * A V4L2 driver for OmniVision OV5647 cameras.
+ *
+ * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
+ * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki@samsung.com>
+ *
+ * Based on Omnivision OV7670 Camera Driver
+ * Copyright (C) 2006-7 Jonathan Corbet <corbet@lwn.net>
+ *
+ * Copyright (C) 2016, Synopsys, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/videodev2.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-image-sizes.h>
+#include <media/v4l2-mediabus.h>
+#include <media/v4l2-of.h>
+
+#define SENSOR_NAME "ov5647"
+
+#define OV5647_SW_RESET		0x1003
+#define OV5647_REG_CHIPID_H	0x300A
+#define OV5647_REG_CHIPID_L	0x300B
+
+#define REG_TERM 0xfffe
+#define VAL_TERM 0xfe
+#define REG_DLY  0xffff
+
+#define OV5647_ROW_START		0x01
+#define OV5647_ROW_START_MIN		0
+#define OV5647_ROW_START_MAX		2004
+#define OV5647_ROW_START_DEF		54
+
+#define OV5647_COLUMN_START		0x02
+#define OV5647_COLUMN_START_MIN		0
+#define OV5647_COLUMN_START_MAX		2750
+#define OV5647_COLUMN_START_DEF		16
+
+#define OV5647_WINDOW_HEIGHT		0x03
+#define OV5647_WINDOW_HEIGHT_MIN	2
+#define OV5647_WINDOW_HEIGHT_MAX	2006
+#define OV5647_WINDOW_HEIGHT_DEF	1944
+
+#define OV5647_WINDOW_WIDTH		0x04
+#define OV5647_WINDOW_WIDTH_MIN		2
+#define OV5647_WINDOW_WIDTH_MAX		2752
+#define OV5647_WINDOW_WIDTH_DEF		2592
+
+struct regval_list {
+	u16 addr;
+	u8 data;
+};
+
+struct ov5647 {
+	struct v4l2_subdev		sd;
+	struct media_pad		pad;
+	struct mutex			lock;
+	struct v4l2_mbus_framefmt	format;
+	unsigned int			width;
+	unsigned int			height;
+	int				power_count;
+	struct clk			*xclk;
+	/* External clock frequency currently supported is 30MHz */
+	u32				xclk_freq;
+};
+
+static inline struct ov5647 *to_state(struct v4l2_subdev *sd)
+{
+	return container_of(sd, struct ov5647, sd);
+}
+
+static struct regval_list sensor_oe_disable_regs[] = {
+	{0x3000, 0x00},
+	{0x3001, 0x00},
+	{0x3002, 0x00},
+};
+
+static struct regval_list sensor_oe_enable_regs[] = {
+	{0x3000, 0x0f},
+	{0x3001, 0xff},
+	{0x3002, 0xe4},
+};
+
+static struct regval_list ov5647_640x480[] = {
+	{0x0100, 0x00},
+	{0x0103, 0x01},
+	{0x3034, 0x08},
+	{0x3035, 0x21},
+	{0x3036, 0x46},
+	{0x303c, 0x11},
+	{0x3106, 0xf5},
+	{0x3821, 0x07},
+	{0x3820, 0x41},
+	{0x3827, 0xec},
+	{0x370c, 0x0f},
+	{0x3612, 0x59},
+	{0x3618, 0x00},
+	{0x5000, 0x06},
+	{0x5001, 0x01},
+	{0x5002, 0x41},
+	{0x5003, 0x08},
+	{0x5a00, 0x08},
+	{0x3000, 0x00},
+	{0x3001, 0x00},
+	{0x3002, 0x00},
+	{0x3016, 0x08},
+	{0x3017, 0xe0},
+	{0x3018, 0x44},
+	{0x301c, 0xf8},
+	{0x301d, 0xf0},
+	{0x3a18, 0x00},
+	{0x3a19, 0xf8},
+	{0x3c01, 0x80},
+	{0x3b07, 0x0c},
+	{0x380c, 0x07},
+	{0x380d, 0x68},
+	{0x380e, 0x03},
+	{0x380f, 0xd8},
+	{0x3814, 0x31},
+	{0x3815, 0x31},
+	{0x3708, 0x64},
+	{0x3709, 0x52},
+	{0x3808, 0x02},
+	{0x3809, 0x80},
+	{0x380a, 0x01},
+	{0x380b, 0xE0},
+	{0x3801, 0x00},
+	{0x3802, 0x00},
+	{0x3803, 0x00},
+	{0x3804, 0x0a},
+	{0x3805, 0x3f},
+	{0x3806, 0x07},
+	{0x3807, 0xa1},
+	{0x3811, 0x08},
+	{0x3813, 0x02},
+	{0x3630, 0x2e},
+	{0x3632, 0xe2},
+	{0x3633, 0x23},
+	{0x3634, 0x44},
+	{0x3636, 0x06},
+	{0x3620, 0x64},
+	{0x3621, 0xe0},
+	{0x3600, 0x37},
+	{0x3704, 0xa0},
+	{0x3703, 0x5a},
+	{0x3715, 0x78},
+	{0x3717, 0x01},
+	{0x3731, 0x02},
+	{0x370b, 0x60},
+	{0x3705, 0x1a},
+	{0x3f05, 0x02},
+	{0x3f06, 0x10},
+	{0x3f01, 0x0a},
+	{0x3a08, 0x01},
+	{0x3a09, 0x27},
+	{0x3a0a, 0x00},
+	{0x3a0b, 0xf6},
+	{0x3a0d, 0x04},
+	{0x3a0e, 0x03},
+	{0x3a0f, 0x58},
+	{0x3a10, 0x50},
+	{0x3a1b, 0x58},
+	{0x3a1e, 0x50},
+	{0x3a11, 0x60},
+	{0x3a1f, 0x28},
+	{0x4001, 0x02},
+	{0x4004, 0x02},
+	{0x4000, 0x09},
+	{0x4837, 0x24},
+	{0x4050, 0x6e},
+	{0x4051, 0x8f},
+	{0x0100, 0x01},
+};
+
+static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val)
+{
+	int ret;
+	unsigned char data[3] = { reg >> 8, reg & 0xff, val};
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	ret = i2c_master_send(client, data, 3);
+	if (ret < 0)
+		dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n",
+				__func__, reg);
+
+	return ret;
+}
+
+static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
+{
+	int ret;
+	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	ret = i2c_master_send(client, data_w, 2);
+	if (ret < 0) {
+		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
+			__func__, reg);
+		return ret;
+	}
+
+	ret = i2c_master_recv(client, val, 1);
+	if (ret < 0)
+		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
+				__func__, reg);
+
+	return ret;
+
+}
+
+static int ov5647_write_array(struct v4l2_subdev *sd,
+				struct regval_list *regs, int array_size)
+{
+	int i = 0, ret;
+
+	for (i = 0; i < array_size; i++) {
+		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
+{
+	u8 channel_id;
+	int ret;
+
+	ret = ov5647_read(sd, 0x4814, &channel_id);
+	if (ret < 0)
+		return ret;
+
+	channel_id &= ~(3 << 6);
+	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
+}
+
+static int ov5647_stream_on(struct v4l2_subdev *sd)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	ov5647_write(sd, 0x4202, 0x00);
+
+	dev_dbg(&client->dev, "Stream on");
+
+	return ov5647_write(sd, 0x300D, 0x00);
+}
+
+static int ov5647_stream_off(struct v4l2_subdev *sd)
+{
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	ov5647_write(sd, 0x4202, 0x0f);
+
+	dev_dbg(&client->dev, "Stream off");
+
+	return ov5647_write(sd, 0x300D, 0x01);
+}
+
+static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
+{
+	int ret;
+	u8 rdval;
+
+	ret = ov5647_read(sd, 0x0100, &rdval);
+	if (ret < 0)
+		return ret;
+
+	if (standby)
+		rdval &= ~0x01;
+	else
+		rdval |= 0x01;
+
+	return ov5647_write(sd, 0x0100, rdval);
+}
+
+static int __sensor_init(struct v4l2_subdev *sd)
+{
+	int ret;
+	u8 resetval;
+	u8 rdval;
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	dev_dbg(&client->dev, "sensor init\n");
+
+	ret = ov5647_read(sd, 0x0100, &rdval);
+	if (ret < 0)
+		return ret;
+
+	ret = ov5647_write_array(sd, ov5647_640x480,
+					ARRAY_SIZE(ov5647_640x480));
+	if (ret < 0) {
+		dev_err(&client->dev, "write sensor default regs error\n");
+		return ret;
+	}
+
+	ret = ov5647_set_virtual_channel(sd, 0);
+	if (ret < 0)
+		return ret;
+
+	ret = ov5647_read(sd, 0x0100, &resetval);
+	if (ret < 0)
+		return ret;
+
+	if (!(resetval & 0x01)) {
+		dev_err(&client->dev, "Device was in SW standby");
+		ret = ov5647_write(sd, 0x0100, 0x01);
+		if (ret < 0)
+			return ret;
+	}
+
+	return ov5647_write(sd, 0x4800, 0x04);
+}
+
+static int sensor_power(struct v4l2_subdev *sd, int on)
+{
+	int ret;
+	struct ov5647 *ov5647 = to_state(sd);
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	ret = 0;
+	mutex_lock(&ov5647->lock);
+
+	if (on && !ov5647->power_count)	{
+		dev_dbg(&client->dev, "OV5647 power on\n");
+
+		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
+
+		ret = clk_prepare_enable(ov5647->xclk);
+		if (ret < 0) {
+			dev_err(&client->dev, "clk prepare enable failed\n");
+			goto out;
+		}
+
+		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
+				ARRAY_SIZE(sensor_oe_enable_regs));
+		if (ret < 0) {
+			clk_disable_unprepare(ov5647->xclk);
+			dev_err(&client->dev,
+				"write sensor_oe_enable_regs error\n");
+			goto out;
+		}
+
+		ret = __sensor_init(sd);
+		if (ret < 0) {
+			clk_disable_unprepare(ov5647->xclk);
+			dev_err(&client->dev,
+				"Camera not available, check Power\n");
+			goto out;
+		}
+	} else if (!on && ov5647->power_count == 1) {
+		dev_dbg(&client->dev, "OV5647 power off\n");
+
+		dev_dbg(&client->dev, "disable oe\n");
+		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
+				ARRAY_SIZE(sensor_oe_disable_regs));
+
+		if (ret < 0)
+			dev_dbg(&client->dev, "disable oe failed\n");
+
+		ret = set_sw_standby(sd, true);
+
+		if (ret < 0)
+			dev_dbg(&client->dev, "soft stby failed\n");
+
+		clk_disable_unprepare(ov5647->xclk);
+	}
+
+	/* Update the power count. */
+	ov5647->power_count += on ? 1 : -1;
+	WARN_ON(ov5647->power_count < 0);
+
+out:
+	mutex_unlock(&ov5647->lock);
+
+	return ret;
+}
+
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int sensor_get_register(struct v4l2_subdev *sd,
+				struct v4l2_dbg_register *reg)
+{
+	u8 val;
+	int ret;
+
+	ret = ov5647_read(sd, reg->reg & 0xff, &val);
+	if (ret < 0)
+		return ret;
+
+	reg->val = val;
+	reg->size = 1;
+
+	return 0;
+}
+
+static int sensor_set_register(struct v4l2_subdev *sd,
+				const struct v4l2_dbg_register *reg)
+{
+	return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff);
+}
+#endif
+
+/**
+ * @short Subdev core operations registration
+ */
+static const struct v4l2_subdev_core_ops subdev_core_ops = {
+	.s_power		= sensor_power,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+	.g_register		= sensor_get_register,
+	.s_register		= sensor_set_register,
+#endif
+};
+
+static int s_stream(struct v4l2_subdev *sd, int enable)
+{
+	if (enable)
+		return ov5647_stream_on(sd);
+	else
+		return ov5647_stream_off(sd);
+}
+
+static const struct v4l2_subdev_video_ops subdev_video_ops = {
+	.s_stream =		s_stream,
+};
+
+static int enum_mbus_code(struct v4l2_subdev *sd,
+				struct v4l2_subdev_pad_config *cfg,
+				struct v4l2_subdev_mbus_code_enum *code)
+{
+	if (code->index > 0)
+		return -EINVAL;
+
+	code->code = MEDIA_BUS_FMT_SBGGR8_1X8;
+
+	return 0;
+}
+
+static const struct v4l2_subdev_pad_ops subdev_pad_ops = {
+	.enum_mbus_code =	enum_mbus_code,
+};
+
+/**
+ * @short Subdev operations registration
+ *
+ */
+static const struct v4l2_subdev_ops subdev_ops = {
+	.core		= &subdev_core_ops,
+	.video		= &subdev_video_ops,
+	.pad		= &subdev_pad_ops,
+};
+
+static int ov5647_detect(struct v4l2_subdev *sd)
+{
+	u8 read;
+	int ret;
+	struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+	ret = ov5647_write(sd, OV5647_SW_RESET, 0x01);
+	if (ret < 0)
+		return ret;
+
+	ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read);
+	if (ret < 0)
+		return ret;
+
+	if (read != 0x56) {
+		dev_err(&client->dev, "Wrong model version detected");
+		return -ENODEV;
+	}
+
+	ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read);
+	if (ret < 0)
+		return ret;
+
+	if (read != 0x47) {
+		dev_err(&client->dev, "Wrong model version detected");
+		return -ENODEV;
+	}
+
+	return ov5647_write(sd, OV5647_SW_RESET, 0x00);
+}
+
+static int ov5647_registered(struct v4l2_subdev *sd)
+{
+	return 0;
+}
+
+static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+	struct v4l2_mbus_framefmt *format =
+				v4l2_subdev_get_try_format(sd, fh->pad, 0);
+	struct v4l2_rect *crop =
+				v4l2_subdev_get_try_crop(sd, fh->pad, 0);
+
+	crop->left = OV5647_COLUMN_START_DEF;
+	crop->top = OV5647_ROW_START_DEF;
+	crop->width = OV5647_WINDOW_WIDTH_DEF;
+	crop->height = OV5647_WINDOW_HEIGHT_DEF;
+
+	format->code = MEDIA_BUS_FMT_SBGGR8_1X8;
+
+	format->width = OV5647_WINDOW_WIDTH_DEF;
+	format->height = OV5647_WINDOW_HEIGHT_DEF;
+	format->field = V4L2_FIELD_NONE;
+	format->colorspace = V4L2_COLORSPACE_SRGB;
+
+	return sensor_power(sd, true);
+}
+
+static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+	return sensor_power(sd, false);
+}
+
+/**
+ * @short Subdev internal operations registration
+ *
+ */
+static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = {
+	.registered = ov5647_registered,
+	.open = ov5647_open,
+	.close = ov5647_close,
+};
+
+static int ov5647_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct ov5647 *sensor;
+	int ret;
+	struct v4l2_subdev *sd;
+
+	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
+	if (sensor == NULL)
+		return -ENOMEM;
+
+	/* get system clock (xclk) */
+	sensor->xclk = devm_clk_get(dev, "xclk");
+	if (IS_ERR(sensor->xclk)) {
+		dev_err(dev, "could not get xclk");
+		return PTR_ERR(sensor->xclk);
+	}
+
+	sensor->xclk_freq = clk_get_rate(sensor->xclk);
+	if (sensor->xclk_freq != 25000000) {
+		dev_err(dev, "Unsupported clock frequency: %u\n",
+			sensor->xclk_freq);
+		return -EINVAL;
+	}
+
+	mutex_init(&sensor->lock);
+
+	sd = &sensor->sd;
+	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
+	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
+	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
+	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
+	if (ret < 0)
+		goto mutex_remove;
+
+	ret = ov5647_detect(sd);
+	if (ret < 0)
+		goto error;
+
+	ret = v4l2_async_register_subdev(sd);
+	if (ret < 0)
+		goto error;
+
+	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
+	return 0;
+error:
+	media_entity_cleanup(&sd->entity);
+mutex_remove:
+	mutex_destroy(&sensor->lock);
+	return ret;
+}
+
+static int ov5647_remove(struct i2c_client *client)
+{
+	struct v4l2_subdev *sd = i2c_get_clientdata(client);
+	struct ov5647 *ov5647 = to_state(sd);
+
+	v4l2_async_unregister_subdev(&ov5647->sd);
+	media_entity_cleanup(&ov5647->sd.entity);
+	v4l2_device_unregister_subdev(sd);
+	mutex_destroy(&ov5647->lock);
+
+	return 0;
+}
+
+static const struct i2c_device_id ov5647_id[] = {
+	{ "ov5647", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, ov5647_id);
+
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id ov5647_of_match[] = {
+	{ .compatible = "ovti,ov5647" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ov5647_of_match);
+#endif
+
+static struct i2c_driver ov5647_driver = {
+	.driver = {
+		.of_match_table = of_match_ptr(ov5647_of_match),
+		.name	= SENSOR_NAME,
+	},
+	.probe		= ov5647_probe,
+	.remove		= ov5647_remove,
+	.id_table	= ov5647_id,
+};
+
+module_i2c_driver(ov5647_driver);
+
+MODULE_AUTHOR("Ramiro Oliveira <roliveir@synopsys.com>");
+MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors");
+MODULE_LICENSE("GPL v2");
-- 
2.11.0

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index 000000000000..31956426d3b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +---------------------------------
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible		: "ovti,ov5647".
> +- reg			: I2C slave address of the sensor.
> +- clocks		: Reference to the xclk clock.
> +- clock-names		: Should be "xclk".
> +- clock-frequency	: Frequency of the xclk clock.
> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.

The remote-endpoint property in endpoint nodes should be mandatory,
shouldn't it? Otherwise the sensor isn't connected to anything and hardly
useful as such. The list of optional endpoint properties is a long one and
it should be documented here which ones are recognised, either as optional
or mandatory.

> +
> +Example:
> +
> +	i2c@2000 {
> +		...
> +		ov: camera@36 {
> +			compatible = "ovti,ov5647";
> +			reg = <0x36>;
> +			clocks = <&camera_clk>;
> +			clock-names = "xclk";
> +			clock-frequency = <25000000>;
> +			port {
> +				camera_1: endpoint {
> +					remote-endpoint = <&csi1_ep1>;
> +				};
> +			};
> +		};
> +	};

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index 000000000000..31956426d3b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +---------------------------------
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible		: "ovti,ov5647".
> +- reg			: I2C slave address of the sensor.
> +- clocks		: Reference to the xclk clock.
> +- clock-names		: Should be "xclk".
> +- clock-frequency	: Frequency of the xclk clock.
> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.

The remote-endpoint property in endpoint nodes should be mandatory,
shouldn't it? Otherwise the sensor isn't connected to anything and hardly
useful as such. The list of optional endpoint properties is a long one and
it should be documented here which ones are recognised, either as optional
or mandatory.

> +
> +Example:
> +
> +	i2c@2000 {
> +		...
> +		ov: camera@36 {
> +			compatible = "ovti,ov5647";
> +			reg = <0x36>;
> +			clocks = <&camera_clk>;
> +			clock-names = "xclk";
> +			clock-frequency = <25000000>;
> +			port {
> +				camera_1: endpoint {
> +					remote-endpoint = <&csi1_ep1>;
> +				};
> +			};
> +		};
> +	};

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Sakari Ailus]

Hi Ramiro,

A few minor comments below.

On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote:
> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
> and RAW 10 output formats, and MIPI CSI-2 interface.
> 
> The driver adds support for 640x480 RAW 8.
> 
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
>  MAINTAINERS                |   7 +
>  drivers/media/i2c/Kconfig  |  11 +
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 657 insertions(+)
>  create mode 100644 drivers/media/i2c/ov5647.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8e7e8d7855ee..7bbca271acc8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9109,6 +9109,13 @@ M:	Harald Welte <laforge@gnumonks.org>
>  S:	Maintained
>  F:	drivers/char/pcmcia/cm4040_cs.*
>  
> +OMNIVISION OV5647 SENSOR DRIVER
> +M:	Ramiro Oliveira <roliveir@synopsys.com>
> +L:	linux-media@vger.kernel.org
> +T:	git git://linuxtv.org/media_tree.git
> +S:	Maintained
> +F:	drivers/media/i2c/ov5647.c
> +
>  OMNIVISION OV7670 SENSOR DRIVER
>  M:	Jonathan Corbet <corbet@lwn.net>
>  L:	linux-media@vger.kernel.org
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cee1dae6e014..8435b99f38bc 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -531,6 +531,17 @@ config VIDEO_OV2659
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called ov2659.
>  
> +config VIDEO_OV5647
> +	tristate "OmniVision OV5647 sensor support"
> +	depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> +	depends on MEDIA_CAMERA_SUPPORT
> +	---help---
> +	  This is a Video4Linux2 sensor-level driver for the OmniVision
> +	  OV5647 camera.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called ov5647.
> +
>  config VIDEO_OV7640
>  	tristate "OmniVision OV7640 sensor support"
>  	depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 5bc7bbeb5499..ef2ccf65f94c 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>  obj-$(CONFIG_VIDEO_ML86V7667)	+= ml86v7667.o
>  obj-$(CONFIG_VIDEO_OV2659)	+= ov2659.o
>  obj-$(CONFIG_VIDEO_TC358743)	+= tc358743.o
> +obj-$(CONFIG_VIDEO_OV5647)	+= ov5647.o
> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> new file mode 100644
> index 000000000000..34e620fabbaf
> --- /dev/null
> +++ b/drivers/media/i2c/ov5647.c
> @@ -0,0 +1,638 @@
> +/*
> + * A V4L2 driver for OmniVision OV5647 cameras.
> + *
> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
> + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * Based on Omnivision OV7670 Camera Driver
> + * Copyright (C) 2006-7 Jonathan Corbet <corbet@lwn.net>
> + *
> + * Copyright (C) 2016, Synopsys, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/videodev2.h>
> +#include <media/v4l2-ctrls.h>

You don't seem to implement any controls.

The sensor likely supports exposure time (and maybe also gain) the user
might want to control. Is there an intent to add that? Otherwise the header
should be removed.

> +#include <media/v4l2-device.h>
> +#include <media/v4l2-image-sizes.h>
> +#include <media/v4l2-mediabus.h>
> +#include <media/v4l2-of.h>
> +
> +#define SENSOR_NAME "ov5647"
> +
> +#define OV5647_SW_RESET		0x1003
> +#define OV5647_REG_CHIPID_H	0x300A
> +#define OV5647_REG_CHIPID_L	0x300B
> +
> +#define REG_TERM 0xfffe
> +#define VAL_TERM 0xfe
> +#define REG_DLY  0xffff
> +
> +#define OV5647_ROW_START		0x01
> +#define OV5647_ROW_START_MIN		0
> +#define OV5647_ROW_START_MAX		2004
> +#define OV5647_ROW_START_DEF		54
> +
> +#define OV5647_COLUMN_START		0x02
> +#define OV5647_COLUMN_START_MIN		0
> +#define OV5647_COLUMN_START_MAX		2750
> +#define OV5647_COLUMN_START_DEF		16
> +
> +#define OV5647_WINDOW_HEIGHT		0x03
> +#define OV5647_WINDOW_HEIGHT_MIN	2
> +#define OV5647_WINDOW_HEIGHT_MAX	2006
> +#define OV5647_WINDOW_HEIGHT_DEF	1944
> +
> +#define OV5647_WINDOW_WIDTH		0x04
> +#define OV5647_WINDOW_WIDTH_MIN		2
> +#define OV5647_WINDOW_WIDTH_MAX		2752
> +#define OV5647_WINDOW_WIDTH_DEF		2592
> +
> +struct regval_list {
> +	u16 addr;
> +	u8 data;
> +};
> +
> +struct ov5647 {
> +	struct v4l2_subdev		sd;
> +	struct media_pad		pad;
> +	struct mutex			lock;
> +	struct v4l2_mbus_framefmt	format;
> +	unsigned int			width;
> +	unsigned int			height;
> +	int				power_count;
> +	struct clk			*xclk;
> +	/* External clock frequency currently supported is 30MHz */
> +	u32				xclk_freq;
> +};
> +
> +static inline struct ov5647 *to_state(struct v4l2_subdev *sd)
> +{
> +	return container_of(sd, struct ov5647, sd);
> +}
> +
> +static struct regval_list sensor_oe_disable_regs[] = {
> +	{0x3000, 0x00},
> +	{0x3001, 0x00},
> +	{0x3002, 0x00},
> +};
> +
> +static struct regval_list sensor_oe_enable_regs[] = {
> +	{0x3000, 0x0f},
> +	{0x3001, 0xff},
> +	{0x3002, 0xe4},
> +};
> +
> +static struct regval_list ov5647_640x480[] = {
> +	{0x0100, 0x00},
> +	{0x0103, 0x01},
> +	{0x3034, 0x08},
> +	{0x3035, 0x21},
> +	{0x3036, 0x46},
> +	{0x303c, 0x11},
> +	{0x3106, 0xf5},
> +	{0x3821, 0x07},
> +	{0x3820, 0x41},
> +	{0x3827, 0xec},
> +	{0x370c, 0x0f},
> +	{0x3612, 0x59},
> +	{0x3618, 0x00},
> +	{0x5000, 0x06},
> +	{0x5001, 0x01},
> +	{0x5002, 0x41},
> +	{0x5003, 0x08},
> +	{0x5a00, 0x08},
> +	{0x3000, 0x00},
> +	{0x3001, 0x00},
> +	{0x3002, 0x00},
> +	{0x3016, 0x08},
> +	{0x3017, 0xe0},
> +	{0x3018, 0x44},
> +	{0x301c, 0xf8},
> +	{0x301d, 0xf0},
> +	{0x3a18, 0x00},
> +	{0x3a19, 0xf8},
> +	{0x3c01, 0x80},
> +	{0x3b07, 0x0c},
> +	{0x380c, 0x07},
> +	{0x380d, 0x68},
> +	{0x380e, 0x03},
> +	{0x380f, 0xd8},
> +	{0x3814, 0x31},
> +	{0x3815, 0x31},
> +	{0x3708, 0x64},
> +	{0x3709, 0x52},
> +	{0x3808, 0x02},
> +	{0x3809, 0x80},
> +	{0x380a, 0x01},
> +	{0x380b, 0xE0},
> +	{0x3801, 0x00},
> +	{0x3802, 0x00},
> +	{0x3803, 0x00},
> +	{0x3804, 0x0a},
> +	{0x3805, 0x3f},
> +	{0x3806, 0x07},
> +	{0x3807, 0xa1},
> +	{0x3811, 0x08},
> +	{0x3813, 0x02},
> +	{0x3630, 0x2e},
> +	{0x3632, 0xe2},
> +	{0x3633, 0x23},
> +	{0x3634, 0x44},
> +	{0x3636, 0x06},
> +	{0x3620, 0x64},
> +	{0x3621, 0xe0},
> +	{0x3600, 0x37},
> +	{0x3704, 0xa0},
> +	{0x3703, 0x5a},
> +	{0x3715, 0x78},
> +	{0x3717, 0x01},
> +	{0x3731, 0x02},
> +	{0x370b, 0x60},
> +	{0x3705, 0x1a},
> +	{0x3f05, 0x02},
> +	{0x3f06, 0x10},
> +	{0x3f01, 0x0a},
> +	{0x3a08, 0x01},
> +	{0x3a09, 0x27},
> +	{0x3a0a, 0x00},
> +	{0x3a0b, 0xf6},
> +	{0x3a0d, 0x04},
> +	{0x3a0e, 0x03},
> +	{0x3a0f, 0x58},
> +	{0x3a10, 0x50},
> +	{0x3a1b, 0x58},
> +	{0x3a1e, 0x50},
> +	{0x3a11, 0x60},
> +	{0x3a1f, 0x28},
> +	{0x4001, 0x02},
> +	{0x4004, 0x02},
> +	{0x4000, 0x09},
> +	{0x4837, 0x24},
> +	{0x4050, 0x6e},
> +	{0x4051, 0x8f},
> +	{0x0100, 0x01},
> +};
> +
> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val)
> +{
> +	int ret;
> +	unsigned char data[3] = { reg >> 8, reg & 0xff, val};
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = i2c_master_send(client, data, 3);
> +	if (ret < 0)
> +		dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n",
> +				__func__, reg);
> +
> +	return ret;
> +}
> +
> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
> +{
> +	int ret;
> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = i2c_master_send(client, data_w, 2);
> +	if (ret < 0) {
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> +			__func__, reg);
> +		return ret;
> +	}
> +
> +	ret = i2c_master_recv(client, val, 1);
> +	if (ret < 0)
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> +				__func__, reg);
> +
> +	return ret;
> +
> +}
> +
> +static int ov5647_write_array(struct v4l2_subdev *sd,
> +				struct regval_list *regs, int array_size)
> +{
> +	int i = 0, ret;
> +
> +	for (i = 0; i < array_size; i++) {
> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
> +{
> +	u8 channel_id;
> +	int ret;
> +
> +	ret = ov5647_read(sd, 0x4814, &channel_id);
> +	if (ret < 0)
> +		return ret;
> +
> +	channel_id &= ~(3 << 6);
> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
> +}
> +
> +static int ov5647_stream_on(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x00);
> +
> +	dev_dbg(&client->dev, "Stream on");
> +
> +	return ov5647_write(sd, 0x300D, 0x00);
> +}
> +
> +static int ov5647_stream_off(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x0f);
> +
> +	dev_dbg(&client->dev, "Stream off");
> +
> +	return ov5647_write(sd, 0x300D, 0x01);
> +}
> +
> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
> +{
> +	int ret;
> +	u8 rdval;
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (standby)
> +		rdval &= ~0x01;
> +	else
> +		rdval |= 0x01;
> +
> +	return ov5647_write(sd, 0x0100, rdval);
> +}
> +
> +static int __sensor_init(struct v4l2_subdev *sd)
> +{
> +	int ret;
> +	u8 resetval;
> +	u8 rdval;
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	dev_dbg(&client->dev, "sensor init\n");
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_write_array(sd, ov5647_640x480,
> +					ARRAY_SIZE(ov5647_640x480));
> +	if (ret < 0) {
> +		dev_err(&client->dev, "write sensor default regs error\n");
> +		return ret;
> +	}
> +
> +	ret = ov5647_set_virtual_channel(sd, 0);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_read(sd, 0x0100, &resetval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (!(resetval & 0x01)) {
> +		dev_err(&client->dev, "Device was in SW standby");
> +		ret = ov5647_write(sd, 0x0100, 0x01);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return ov5647_write(sd, 0x4800, 0x04);
> +}
> +
> +static int sensor_power(struct v4l2_subdev *sd, int on)
> +{
> +	int ret;
> +	struct ov5647 *ov5647 = to_state(sd);
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = 0;

You can assign in variable declaration.

> +	mutex_lock(&ov5647->lock);
> +
> +	if (on && !ov5647->power_count)	{
> +		dev_dbg(&client->dev, "OV5647 power on\n");
> +
> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
> +
> +		ret = clk_prepare_enable(ov5647->xclk);
> +		if (ret < 0) {
> +			dev_err(&client->dev, "clk prepare enable failed\n");
> +			goto out;
> +		}
> +
> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
> +				ARRAY_SIZE(sensor_oe_enable_regs));
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"write sensor_oe_enable_regs error\n");
> +			goto out;
> +		}
> +
> +		ret = __sensor_init(sd);
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"Camera not available, check Power\n");
> +			goto out;
> +		}
> +	} else if (!on && ov5647->power_count == 1) {
> +		dev_dbg(&client->dev, "OV5647 power off\n");
> +
> +		dev_dbg(&client->dev, "disable oe\n");
> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
> +				ARRAY_SIZE(sensor_oe_disable_regs));
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "disable oe failed\n");
> +
> +		ret = set_sw_standby(sd, true);
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "soft stby failed\n");
> +
> +		clk_disable_unprepare(ov5647->xclk);
> +	}
> +
> +	/* Update the power count. */
> +	ov5647->power_count += on ? 1 : -1;
> +	WARN_ON(ov5647->power_count < 0);
> +
> +out:
> +	mutex_unlock(&ov5647->lock);
> +
> +	return ret;
> +}
> +
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +static int sensor_get_register(struct v4l2_subdev *sd,
> +				struct v4l2_dbg_register *reg)
> +{
> +	u8 val;
> +	int ret;
> +
> +	ret = ov5647_read(sd, reg->reg & 0xff, &val);
> +	if (ret < 0)
> +		return ret;
> +
> +	reg->val = val;
> +	reg->size = 1;
> +
> +	return 0;
> +}
> +
> +static int sensor_set_register(struct v4l2_subdev *sd,
> +				const struct v4l2_dbg_register *reg)
> +{
> +	return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff);
> +}
> +#endif
> +
> +/**
> + * @short Subdev core operations registration
> + */
> +static const struct v4l2_subdev_core_ops subdev_core_ops = {
> +	.s_power		= sensor_power,
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +	.g_register		= sensor_get_register,
> +	.s_register		= sensor_set_register,
> +#endif
> +};
> +
> +static int s_stream(struct v4l2_subdev *sd, int enable)
> +{
> +	if (enable)
> +		return ov5647_stream_on(sd);
> +	else
> +		return ov5647_stream_off(sd);
> +}
> +
> +static const struct v4l2_subdev_video_ops subdev_video_ops = {
> +	.s_stream =		s_stream,
> +};
> +
> +static int enum_mbus_code(struct v4l2_subdev *sd,
> +				struct v4l2_subdev_pad_config *cfg,
> +				struct v4l2_subdev_mbus_code_enum *code)
> +{
> +	if (code->index > 0)
> +		return -EINVAL;
> +
> +	code->code = MEDIA_BUS_FMT_SBGGR8_1X8;
> +
> +	return 0;
> +}
> +
> +static const struct v4l2_subdev_pad_ops subdev_pad_ops = {
> +	.enum_mbus_code =	enum_mbus_code,
> +};
> +
> +/**
> + * @short Subdev operations registration
> + *
> + */
> +static const struct v4l2_subdev_ops subdev_ops = {
> +	.core		= &subdev_core_ops,
> +	.video		= &subdev_video_ops,
> +	.pad		= &subdev_pad_ops,
> +};
> +
> +static int ov5647_detect(struct v4l2_subdev *sd)
> +{
> +	u8 read;
> +	int ret;
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = ov5647_write(sd, OV5647_SW_RESET, 0x01);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (read != 0x56) {
> +		dev_err(&client->dev, "Wrong model version detected");

You might want to tell whether it's high or low ID register that fails the
check. And possibly the bad value. Up to you.

> +		return -ENODEV;
> +	}
> +
> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (read != 0x47) {
> +		dev_err(&client->dev, "Wrong model version detected");
> +		return -ENODEV;
> +	}
> +
> +	return ov5647_write(sd, OV5647_SW_RESET, 0x00);
> +}
> +
> +static int ov5647_registered(struct v4l2_subdev *sd)
> +{
> +	return 0;
> +}

The registered() callback is optional, i.e. you can drop an empty callback.

> +
> +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> +	struct v4l2_mbus_framefmt *format =
> +				v4l2_subdev_get_try_format(sd, fh->pad, 0);
> +	struct v4l2_rect *crop =
> +				v4l2_subdev_get_try_crop(sd, fh->pad, 0);
> +
> +	crop->left = OV5647_COLUMN_START_DEF;
> +	crop->top = OV5647_ROW_START_DEF;
> +	crop->width = OV5647_WINDOW_WIDTH_DEF;
> +	crop->height = OV5647_WINDOW_HEIGHT_DEF;
> +
> +	format->code = MEDIA_BUS_FMT_SBGGR8_1X8;
> +
> +	format->width = OV5647_WINDOW_WIDTH_DEF;
> +	format->height = OV5647_WINDOW_HEIGHT_DEF;
> +	format->field = V4L2_FIELD_NONE;
> +	format->colorspace = V4L2_COLORSPACE_SRGB;
> +
> +	return sensor_power(sd, true);
> +}
> +
> +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> +	return sensor_power(sd, false);
> +}
> +
> +/**
> + * @short Subdev internal operations registration
> + *
> + */
> +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = {
> +	.registered = ov5647_registered,
> +	.open = ov5647_open,
> +	.close = ov5647_close,
> +};
> +
> +static int ov5647_probe(struct i2c_client *client,
> +			const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct ov5647 *sensor;
> +	int ret;
> +	struct v4l2_subdev *sd;
> +
> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
> +	if (sensor == NULL)
> +		return -ENOMEM;
> +
> +	/* get system clock (xclk) */
> +	sensor->xclk = devm_clk_get(dev, "xclk");
> +	if (IS_ERR(sensor->xclk)) {
> +		dev_err(dev, "could not get xclk");
> +		return PTR_ERR(sensor->xclk);
> +	}
> +
> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
> +	if (sensor->xclk_freq != 25000000) {
> +		dev_err(dev, "Unsupported clock frequency: %u\n",
> +			sensor->xclk_freq);
> +		return -EINVAL;
> +	}
> +
> +	mutex_init(&sensor->lock);
> +
> +	sd = &sensor->sd;
> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> +
> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
> +	if (ret < 0)
> +		goto mutex_remove;
> +
> +	ret = ov5647_detect(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	ret = v4l2_async_register_subdev(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
> +	return 0;
> +error:
> +	media_entity_cleanup(&sd->entity);
> +mutex_remove:
> +	mutex_destroy(&sensor->lock);
> +	return ret;
> +}
> +
> +static int ov5647_remove(struct i2c_client *client)
> +{
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct ov5647 *ov5647 = to_state(sd);
> +
> +	v4l2_async_unregister_subdev(&ov5647->sd);
> +	media_entity_cleanup(&ov5647->sd.entity);
> +	v4l2_device_unregister_subdev(sd);
> +	mutex_destroy(&ov5647->lock);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id ov5647_id[] = {
> +	{ "ov5647", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, ov5647_id);
> +
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id ov5647_of_match[] = {
> +	{ .compatible = "ovti,ov5647" },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, ov5647_of_match);
> +#endif
> +
> +static struct i2c_driver ov5647_driver = {
> +	.driver = {
> +		.of_match_table = of_match_ptr(ov5647_of_match),
> +		.name	= SENSOR_NAME,
> +	},
> +	.probe		= ov5647_probe,
> +	.remove		= ov5647_remove,
> +	.id_table	= ov5647_id,
> +};
> +
> +module_i2c_driver(ov5647_driver);
> +
> +MODULE_AUTHOR("Ramiro Oliveira <roliveir@synopsys.com>");
> +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors");
> +MODULE_LICENSE("GPL v2");

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Sakari Ailus]

Hi Ramiro,

A few minor comments below.

On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote:
> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
> and RAW 10 output formats, and MIPI CSI-2 interface.
> 
> The driver adds support for 640x480 RAW 8.
> 
> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
>  MAINTAINERS                |   7 +
>  drivers/media/i2c/Kconfig  |  11 +
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 657 insertions(+)
>  create mode 100644 drivers/media/i2c/ov5647.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8e7e8d7855ee..7bbca271acc8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9109,6 +9109,13 @@ M:	Harald Welte <laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org>
>  S:	Maintained
>  F:	drivers/char/pcmcia/cm4040_cs.*
>  
> +OMNIVISION OV5647 SENSOR DRIVER
> +M:	Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> +L:	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +T:	git git://linuxtv.org/media_tree.git
> +S:	Maintained
> +F:	drivers/media/i2c/ov5647.c
> +
>  OMNIVISION OV7670 SENSOR DRIVER
>  M:	Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
>  L:	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cee1dae6e014..8435b99f38bc 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -531,6 +531,17 @@ config VIDEO_OV2659
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called ov2659.
>  
> +config VIDEO_OV5647
> +	tristate "OmniVision OV5647 sensor support"
> +	depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> +	depends on MEDIA_CAMERA_SUPPORT
> +	---help---
> +	  This is a Video4Linux2 sensor-level driver for the OmniVision
> +	  OV5647 camera.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called ov5647.
> +
>  config VIDEO_OV7640
>  	tristate "OmniVision OV7640 sensor support"
>  	depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 5bc7bbeb5499..ef2ccf65f94c 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>  obj-$(CONFIG_VIDEO_ML86V7667)	+= ml86v7667.o
>  obj-$(CONFIG_VIDEO_OV2659)	+= ov2659.o
>  obj-$(CONFIG_VIDEO_TC358743)	+= tc358743.o
> +obj-$(CONFIG_VIDEO_OV5647)	+= ov5647.o
> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> new file mode 100644
> index 000000000000..34e620fabbaf
> --- /dev/null
> +++ b/drivers/media/i2c/ov5647.c
> @@ -0,0 +1,638 @@
> +/*
> + * A V4L2 driver for OmniVision OV5647 cameras.
> + *
> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
> + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> + *
> + * Based on Omnivision OV7670 Camera Driver
> + * Copyright (C) 2006-7 Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
> + *
> + * Copyright (C) 2016, Synopsys, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/videodev2.h>
> +#include <media/v4l2-ctrls.h>

You don't seem to implement any controls.

The sensor likely supports exposure time (and maybe also gain) the user
might want to control. Is there an intent to add that? Otherwise the header
should be removed.

> +#include <media/v4l2-device.h>
> +#include <media/v4l2-image-sizes.h>
> +#include <media/v4l2-mediabus.h>
> +#include <media/v4l2-of.h>
> +
> +#define SENSOR_NAME "ov5647"
> +
> +#define OV5647_SW_RESET		0x1003
> +#define OV5647_REG_CHIPID_H	0x300A
> +#define OV5647_REG_CHIPID_L	0x300B
> +
> +#define REG_TERM 0xfffe
> +#define VAL_TERM 0xfe
> +#define REG_DLY  0xffff
> +
> +#define OV5647_ROW_START		0x01
> +#define OV5647_ROW_START_MIN		0
> +#define OV5647_ROW_START_MAX		2004
> +#define OV5647_ROW_START_DEF		54
> +
> +#define OV5647_COLUMN_START		0x02
> +#define OV5647_COLUMN_START_MIN		0
> +#define OV5647_COLUMN_START_MAX		2750
> +#define OV5647_COLUMN_START_DEF		16
> +
> +#define OV5647_WINDOW_HEIGHT		0x03
> +#define OV5647_WINDOW_HEIGHT_MIN	2
> +#define OV5647_WINDOW_HEIGHT_MAX	2006
> +#define OV5647_WINDOW_HEIGHT_DEF	1944
> +
> +#define OV5647_WINDOW_WIDTH		0x04
> +#define OV5647_WINDOW_WIDTH_MIN		2
> +#define OV5647_WINDOW_WIDTH_MAX		2752
> +#define OV5647_WINDOW_WIDTH_DEF		2592
> +
> +struct regval_list {
> +	u16 addr;
> +	u8 data;
> +};
> +
> +struct ov5647 {
> +	struct v4l2_subdev		sd;
> +	struct media_pad		pad;
> +	struct mutex			lock;
> +	struct v4l2_mbus_framefmt	format;
> +	unsigned int			width;
> +	unsigned int			height;
> +	int				power_count;
> +	struct clk			*xclk;
> +	/* External clock frequency currently supported is 30MHz */
> +	u32				xclk_freq;
> +};
> +
> +static inline struct ov5647 *to_state(struct v4l2_subdev *sd)
> +{
> +	return container_of(sd, struct ov5647, sd);
> +}
> +
> +static struct regval_list sensor_oe_disable_regs[] = {
> +	{0x3000, 0x00},
> +	{0x3001, 0x00},
> +	{0x3002, 0x00},
> +};
> +
> +static struct regval_list sensor_oe_enable_regs[] = {
> +	{0x3000, 0x0f},
> +	{0x3001, 0xff},
> +	{0x3002, 0xe4},
> +};
> +
> +static struct regval_list ov5647_640x480[] = {
> +	{0x0100, 0x00},
> +	{0x0103, 0x01},
> +	{0x3034, 0x08},
> +	{0x3035, 0x21},
> +	{0x3036, 0x46},
> +	{0x303c, 0x11},
> +	{0x3106, 0xf5},
> +	{0x3821, 0x07},
> +	{0x3820, 0x41},
> +	{0x3827, 0xec},
> +	{0x370c, 0x0f},
> +	{0x3612, 0x59},
> +	{0x3618, 0x00},
> +	{0x5000, 0x06},
> +	{0x5001, 0x01},
> +	{0x5002, 0x41},
> +	{0x5003, 0x08},
> +	{0x5a00, 0x08},
> +	{0x3000, 0x00},
> +	{0x3001, 0x00},
> +	{0x3002, 0x00},
> +	{0x3016, 0x08},
> +	{0x3017, 0xe0},
> +	{0x3018, 0x44},
> +	{0x301c, 0xf8},
> +	{0x301d, 0xf0},
> +	{0x3a18, 0x00},
> +	{0x3a19, 0xf8},
> +	{0x3c01, 0x80},
> +	{0x3b07, 0x0c},
> +	{0x380c, 0x07},
> +	{0x380d, 0x68},
> +	{0x380e, 0x03},
> +	{0x380f, 0xd8},
> +	{0x3814, 0x31},
> +	{0x3815, 0x31},
> +	{0x3708, 0x64},
> +	{0x3709, 0x52},
> +	{0x3808, 0x02},
> +	{0x3809, 0x80},
> +	{0x380a, 0x01},
> +	{0x380b, 0xE0},
> +	{0x3801, 0x00},
> +	{0x3802, 0x00},
> +	{0x3803, 0x00},
> +	{0x3804, 0x0a},
> +	{0x3805, 0x3f},
> +	{0x3806, 0x07},
> +	{0x3807, 0xa1},
> +	{0x3811, 0x08},
> +	{0x3813, 0x02},
> +	{0x3630, 0x2e},
> +	{0x3632, 0xe2},
> +	{0x3633, 0x23},
> +	{0x3634, 0x44},
> +	{0x3636, 0x06},
> +	{0x3620, 0x64},
> +	{0x3621, 0xe0},
> +	{0x3600, 0x37},
> +	{0x3704, 0xa0},
> +	{0x3703, 0x5a},
> +	{0x3715, 0x78},
> +	{0x3717, 0x01},
> +	{0x3731, 0x02},
> +	{0x370b, 0x60},
> +	{0x3705, 0x1a},
> +	{0x3f05, 0x02},
> +	{0x3f06, 0x10},
> +	{0x3f01, 0x0a},
> +	{0x3a08, 0x01},
> +	{0x3a09, 0x27},
> +	{0x3a0a, 0x00},
> +	{0x3a0b, 0xf6},
> +	{0x3a0d, 0x04},
> +	{0x3a0e, 0x03},
> +	{0x3a0f, 0x58},
> +	{0x3a10, 0x50},
> +	{0x3a1b, 0x58},
> +	{0x3a1e, 0x50},
> +	{0x3a11, 0x60},
> +	{0x3a1f, 0x28},
> +	{0x4001, 0x02},
> +	{0x4004, 0x02},
> +	{0x4000, 0x09},
> +	{0x4837, 0x24},
> +	{0x4050, 0x6e},
> +	{0x4051, 0x8f},
> +	{0x0100, 0x01},
> +};
> +
> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val)
> +{
> +	int ret;
> +	unsigned char data[3] = { reg >> 8, reg & 0xff, val};
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = i2c_master_send(client, data, 3);
> +	if (ret < 0)
> +		dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n",
> +				__func__, reg);
> +
> +	return ret;
> +}
> +
> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
> +{
> +	int ret;
> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = i2c_master_send(client, data_w, 2);
> +	if (ret < 0) {
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> +			__func__, reg);
> +		return ret;
> +	}
> +
> +	ret = i2c_master_recv(client, val, 1);
> +	if (ret < 0)
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> +				__func__, reg);
> +
> +	return ret;
> +
> +}
> +
> +static int ov5647_write_array(struct v4l2_subdev *sd,
> +				struct regval_list *regs, int array_size)
> +{
> +	int i = 0, ret;
> +
> +	for (i = 0; i < array_size; i++) {
> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
> +{
> +	u8 channel_id;
> +	int ret;
> +
> +	ret = ov5647_read(sd, 0x4814, &channel_id);
> +	if (ret < 0)
> +		return ret;
> +
> +	channel_id &= ~(3 << 6);
> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
> +}
> +
> +static int ov5647_stream_on(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x00);
> +
> +	dev_dbg(&client->dev, "Stream on");
> +
> +	return ov5647_write(sd, 0x300D, 0x00);
> +}
> +
> +static int ov5647_stream_off(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x0f);
> +
> +	dev_dbg(&client->dev, "Stream off");
> +
> +	return ov5647_write(sd, 0x300D, 0x01);
> +}
> +
> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
> +{
> +	int ret;
> +	u8 rdval;
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (standby)
> +		rdval &= ~0x01;
> +	else
> +		rdval |= 0x01;
> +
> +	return ov5647_write(sd, 0x0100, rdval);
> +}
> +
> +static int __sensor_init(struct v4l2_subdev *sd)
> +{
> +	int ret;
> +	u8 resetval;
> +	u8 rdval;
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	dev_dbg(&client->dev, "sensor init\n");
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_write_array(sd, ov5647_640x480,
> +					ARRAY_SIZE(ov5647_640x480));
> +	if (ret < 0) {
> +		dev_err(&client->dev, "write sensor default regs error\n");
> +		return ret;
> +	}
> +
> +	ret = ov5647_set_virtual_channel(sd, 0);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_read(sd, 0x0100, &resetval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (!(resetval & 0x01)) {
> +		dev_err(&client->dev, "Device was in SW standby");
> +		ret = ov5647_write(sd, 0x0100, 0x01);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return ov5647_write(sd, 0x4800, 0x04);
> +}
> +
> +static int sensor_power(struct v4l2_subdev *sd, int on)
> +{
> +	int ret;
> +	struct ov5647 *ov5647 = to_state(sd);
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = 0;

You can assign in variable declaration.

> +	mutex_lock(&ov5647->lock);
> +
> +	if (on && !ov5647->power_count)	{
> +		dev_dbg(&client->dev, "OV5647 power on\n");
> +
> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
> +
> +		ret = clk_prepare_enable(ov5647->xclk);
> +		if (ret < 0) {
> +			dev_err(&client->dev, "clk prepare enable failed\n");
> +			goto out;
> +		}
> +
> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
> +				ARRAY_SIZE(sensor_oe_enable_regs));
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"write sensor_oe_enable_regs error\n");
> +			goto out;
> +		}
> +
> +		ret = __sensor_init(sd);
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"Camera not available, check Power\n");
> +			goto out;
> +		}
> +	} else if (!on && ov5647->power_count == 1) {
> +		dev_dbg(&client->dev, "OV5647 power off\n");
> +
> +		dev_dbg(&client->dev, "disable oe\n");
> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
> +				ARRAY_SIZE(sensor_oe_disable_regs));
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "disable oe failed\n");
> +
> +		ret = set_sw_standby(sd, true);
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "soft stby failed\n");
> +
> +		clk_disable_unprepare(ov5647->xclk);
> +	}
> +
> +	/* Update the power count. */
> +	ov5647->power_count += on ? 1 : -1;
> +	WARN_ON(ov5647->power_count < 0);
> +
> +out:
> +	mutex_unlock(&ov5647->lock);
> +
> +	return ret;
> +}
> +
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +static int sensor_get_register(struct v4l2_subdev *sd,
> +				struct v4l2_dbg_register *reg)
> +{
> +	u8 val;
> +	int ret;
> +
> +	ret = ov5647_read(sd, reg->reg & 0xff, &val);
> +	if (ret < 0)
> +		return ret;
> +
> +	reg->val = val;
> +	reg->size = 1;
> +
> +	return 0;
> +}
> +
> +static int sensor_set_register(struct v4l2_subdev *sd,
> +				const struct v4l2_dbg_register *reg)
> +{
> +	return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff);
> +}
> +#endif
> +
> +/**
> + * @short Subdev core operations registration
> + */
> +static const struct v4l2_subdev_core_ops subdev_core_ops = {
> +	.s_power		= sensor_power,
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +	.g_register		= sensor_get_register,
> +	.s_register		= sensor_set_register,
> +#endif
> +};
> +
> +static int s_stream(struct v4l2_subdev *sd, int enable)
> +{
> +	if (enable)
> +		return ov5647_stream_on(sd);
> +	else
> +		return ov5647_stream_off(sd);
> +}
> +
> +static const struct v4l2_subdev_video_ops subdev_video_ops = {
> +	.s_stream =		s_stream,
> +};
> +
> +static int enum_mbus_code(struct v4l2_subdev *sd,
> +				struct v4l2_subdev_pad_config *cfg,
> +				struct v4l2_subdev_mbus_code_enum *code)
> +{
> +	if (code->index > 0)
> +		return -EINVAL;
> +
> +	code->code = MEDIA_BUS_FMT_SBGGR8_1X8;
> +
> +	return 0;
> +}
> +
> +static const struct v4l2_subdev_pad_ops subdev_pad_ops = {
> +	.enum_mbus_code =	enum_mbus_code,
> +};
> +
> +/**
> + * @short Subdev operations registration
> + *
> + */
> +static const struct v4l2_subdev_ops subdev_ops = {
> +	.core		= &subdev_core_ops,
> +	.video		= &subdev_video_ops,
> +	.pad		= &subdev_pad_ops,
> +};
> +
> +static int ov5647_detect(struct v4l2_subdev *sd)
> +{
> +	u8 read;
> +	int ret;
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = ov5647_write(sd, OV5647_SW_RESET, 0x01);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (read != 0x56) {
> +		dev_err(&client->dev, "Wrong model version detected");

You might want to tell whether it's high or low ID register that fails the
check. And possibly the bad value. Up to you.

> +		return -ENODEV;
> +	}
> +
> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (read != 0x47) {
> +		dev_err(&client->dev, "Wrong model version detected");
> +		return -ENODEV;
> +	}
> +
> +	return ov5647_write(sd, OV5647_SW_RESET, 0x00);
> +}
> +
> +static int ov5647_registered(struct v4l2_subdev *sd)
> +{
> +	return 0;
> +}

The registered() callback is optional, i.e. you can drop an empty callback.

> +
> +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> +	struct v4l2_mbus_framefmt *format =
> +				v4l2_subdev_get_try_format(sd, fh->pad, 0);
> +	struct v4l2_rect *crop =
> +				v4l2_subdev_get_try_crop(sd, fh->pad, 0);
> +
> +	crop->left = OV5647_COLUMN_START_DEF;
> +	crop->top = OV5647_ROW_START_DEF;
> +	crop->width = OV5647_WINDOW_WIDTH_DEF;
> +	crop->height = OV5647_WINDOW_HEIGHT_DEF;
> +
> +	format->code = MEDIA_BUS_FMT_SBGGR8_1X8;
> +
> +	format->width = OV5647_WINDOW_WIDTH_DEF;
> +	format->height = OV5647_WINDOW_HEIGHT_DEF;
> +	format->field = V4L2_FIELD_NONE;
> +	format->colorspace = V4L2_COLORSPACE_SRGB;
> +
> +	return sensor_power(sd, true);
> +}
> +
> +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> +	return sensor_power(sd, false);
> +}
> +
> +/**
> + * @short Subdev internal operations registration
> + *
> + */
> +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = {
> +	.registered = ov5647_registered,
> +	.open = ov5647_open,
> +	.close = ov5647_close,
> +};
> +
> +static int ov5647_probe(struct i2c_client *client,
> +			const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct ov5647 *sensor;
> +	int ret;
> +	struct v4l2_subdev *sd;
> +
> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
> +	if (sensor == NULL)
> +		return -ENOMEM;
> +
> +	/* get system clock (xclk) */
> +	sensor->xclk = devm_clk_get(dev, "xclk");
> +	if (IS_ERR(sensor->xclk)) {
> +		dev_err(dev, "could not get xclk");
> +		return PTR_ERR(sensor->xclk);
> +	}
> +
> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
> +	if (sensor->xclk_freq != 25000000) {
> +		dev_err(dev, "Unsupported clock frequency: %u\n",
> +			sensor->xclk_freq);
> +		return -EINVAL;
> +	}
> +
> +	mutex_init(&sensor->lock);
> +
> +	sd = &sensor->sd;
> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> +
> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
> +	if (ret < 0)
> +		goto mutex_remove;
> +
> +	ret = ov5647_detect(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	ret = v4l2_async_register_subdev(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
> +	return 0;
> +error:
> +	media_entity_cleanup(&sd->entity);
> +mutex_remove:
> +	mutex_destroy(&sensor->lock);
> +	return ret;
> +}
> +
> +static int ov5647_remove(struct i2c_client *client)
> +{
> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> +	struct ov5647 *ov5647 = to_state(sd);
> +
> +	v4l2_async_unregister_subdev(&ov5647->sd);
> +	media_entity_cleanup(&ov5647->sd.entity);
> +	v4l2_device_unregister_subdev(sd);
> +	mutex_destroy(&ov5647->lock);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id ov5647_id[] = {
> +	{ "ov5647", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, ov5647_id);
> +
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id ov5647_of_match[] = {
> +	{ .compatible = "ovti,ov5647" },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, ov5647_of_match);
> +#endif
> +
> +static struct i2c_driver ov5647_driver = {
> +	.driver = {
> +		.of_match_table = of_match_ptr(ov5647_of_match),
> +		.name	= SENSOR_NAME,
> +	},
> +	.probe		= ov5647_probe,
> +	.remove		= ov5647_remove,
> +	.id_table	= ov5647_id,
> +};
> +
> +module_i2c_driver(ov5647_driver);
> +
> +MODULE_AUTHOR("Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>");
> +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors");
> +MODULE_LICENSE("GPL v2");

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Sakari,

Thank you for your feedback.

On 2/21/2017 11:57 AM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote:
>> Create device tree bindings documentation.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> new file mode 100644
>> index 000000000000..31956426d3b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> @@ -0,0 +1,35 @@
>> +Omnivision OV5647 raw image sensor
>> +---------------------------------
>> +
>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>> +and CCI (I2C compatible) control bus.
>> +
>> +Required properties:
>> +
>> +- compatible		: "ovti,ov5647".
>> +- reg			: I2C slave address of the sensor.
>> +- clocks		: Reference to the xclk clock.
>> +- clock-names		: Should be "xclk".
>> +- clock-frequency	: Frequency of the xclk clock.
>> +
>> +The common video interfaces bindings (see video-interfaces.txt) should be
>> +used to specify link to the image data receiver. The OV5647 device
>> +node should contain one 'port' child node with an 'endpoint' subnode.
> 
> The remote-endpoint property in endpoint nodes should be mandatory,
> shouldn't it? Otherwise the sensor isn't connected to anything and hardly
> useful as such. The list of optional endpoint properties is a long one and
> it should be documented here which ones are recognised, either as optional
> or mandatory.
> 

I guess you're right, it should be mandatory, although at the moment I'm not
checking for it's presence in the driver so I'll add it to the driver.

At the moment that's the only property I think it should be mandatory, and I
don't believe I need any optional one.

Do you have a suggestion for any new property I should use?

>> +
>> +Example:
>> +
>> +	i2c@2000 {
>> +		...
>> +		ov: camera@36 {
>> +			compatible = "ovti,ov5647";
>> +			reg = <0x36>;
>> +			clocks = <&camera_clk>;
>> +			clock-names = "xclk";
>> +			clock-frequency = <25000000>;
>> +			port {
>> +				camera_1: endpoint {
>> +					remote-endpoint = <&csi1_ep1>;
>> +				};
>> +			};
>> +		};
>> +	};
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Tue, Feb 21, 2017 at 02:30:16PM +0000, Ramiro Oliveira wrote:
> Hi Sakari,
> 
> Thank you for your feedback.
> 
> On 2/21/2017 11:57 AM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote:
> >> Create device tree bindings documentation.
> >>
> >> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >> ---
> >>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
> >>  1 file changed, 35 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> new file mode 100644
> >> index 000000000000..31956426d3b9
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> @@ -0,0 +1,35 @@
> >> +Omnivision OV5647 raw image sensor
> >> +---------------------------------
> >> +
> >> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >> +and CCI (I2C compatible) control bus.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible		: "ovti,ov5647".
> >> +- reg			: I2C slave address of the sensor.
> >> +- clocks		: Reference to the xclk clock.
> >> +- clock-names		: Should be "xclk".
> >> +- clock-frequency	: Frequency of the xclk clock.
> >> +
> >> +The common video interfaces bindings (see video-interfaces.txt) should be
> >> +used to specify link to the image data receiver. The OV5647 device
> >> +node should contain one 'port' child node with an 'endpoint' subnode.
> > 
> > The remote-endpoint property in endpoint nodes should be mandatory,
> > shouldn't it? Otherwise the sensor isn't connected to anything and hardly
> > useful as such. The list of optional endpoint properties is a long one and
> > it should be documented here which ones are recognised, either as optional
> > or mandatory.
> > 
> 
> I guess you're right, it should be mandatory, although at the moment I'm not
> checking for it's presence in the driver so I'll add it to the driver.
> 
> At the moment that's the only property I think it should be mandatory, and I
> don't believe I need any optional one.
> 
> Do you have a suggestion for any new property I should use?

As you don't need any in the driver for the driver to work, you can omit
them.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Tue, Feb 21, 2017 at 02:30:16PM +0000, Ramiro Oliveira wrote:
> Hi Sakari,
> 
> Thank you for your feedback.
> 
> On 2/21/2017 11:57 AM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote:
> >> Create device tree bindings documentation.
> >>
> >> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> >> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> ---
> >>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
> >>  1 file changed, 35 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> new file mode 100644
> >> index 000000000000..31956426d3b9
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> @@ -0,0 +1,35 @@
> >> +Omnivision OV5647 raw image sensor
> >> +---------------------------------
> >> +
> >> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >> +and CCI (I2C compatible) control bus.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible		: "ovti,ov5647".
> >> +- reg			: I2C slave address of the sensor.
> >> +- clocks		: Reference to the xclk clock.
> >> +- clock-names		: Should be "xclk".
> >> +- clock-frequency	: Frequency of the xclk clock.
> >> +
> >> +The common video interfaces bindings (see video-interfaces.txt) should be
> >> +used to specify link to the image data receiver. The OV5647 device
> >> +node should contain one 'port' child node with an 'endpoint' subnode.
> > 
> > The remote-endpoint property in endpoint nodes should be mandatory,
> > shouldn't it? Otherwise the sensor isn't connected to anything and hardly
> > useful as such. The list of optional endpoint properties is a long one and
> > it should be documented here which ones are recognised, either as optional
> > or mandatory.
> > 
> 
> I guess you're right, it should be mandatory, although at the moment I'm not
> checking for it's presence in the driver so I'll add it to the driver.
> 
> At the moment that's the only property I think it should be mandatory, and I
> don't believe I need any optional one.
> 
> Do you have a suggestion for any new property I should use?

As you don't need any in the driver for the driver to work, you can omit
them.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Sakari,

Thank you for your feedback.

On 2/21/2017 12:09 PM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> A few minor comments below.
> 
> On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote:
>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>
>> The driver adds support for 640x480 RAW 8.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>> ---
>>  MAINTAINERS                |   7 +
>>  drivers/media/i2c/Kconfig  |  11 +
>>  drivers/media/i2c/Makefile |   1 +
>>  drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++
>>  4 files changed, 657 insertions(+)
>>  create mode 100644 drivers/media/i2c/ov5647.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8e7e8d7855ee..7bbca271acc8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9109,6 +9109,13 @@ M:	Harald Welte <laforge@gnumonks.org>
>>  S:	Maintained
>>  F:	drivers/char/pcmcia/cm4040_cs.*
>>  
>> +OMNIVISION OV5647 SENSOR DRIVER
>> +M:	Ramiro Oliveira <roliveir@synopsys.com>
>> +L:	linux-media@vger.kernel.org
>> +T:	git git://linuxtv.org/media_tree.git
>> +S:	Maintained
>> +F:	drivers/media/i2c/ov5647.c
>> +
>>  OMNIVISION OV7670 SENSOR DRIVER
>>  M:	Jonathan Corbet <corbet@lwn.net>
>>  L:	linux-media@vger.kernel.org
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index cee1dae6e014..8435b99f38bc 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -531,6 +531,17 @@ config VIDEO_OV2659
>>  	  To compile this driver as a module, choose M here: the
>>  	  module will be called ov2659.
>>  
>> +config VIDEO_OV5647
>> +	tristate "OmniVision OV5647 sensor support"
>> +	depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>> +	depends on MEDIA_CAMERA_SUPPORT
>> +	---help---
>> +	  This is a Video4Linux2 sensor-level driver for the OmniVision
>> +	  OV5647 camera.
>> +
>> +	  To compile this driver as a module, choose M here: the
>> +	  module will be called ov5647.
>> +
>>  config VIDEO_OV7640
>>  	tristate "OmniVision OV7640 sensor support"
>>  	depends on I2C && VIDEO_V4L2
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 5bc7bbeb5499..ef2ccf65f94c 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>>  obj-$(CONFIG_VIDEO_ML86V7667)	+= ml86v7667.o
>>  obj-$(CONFIG_VIDEO_OV2659)	+= ov2659.o
>>  obj-$(CONFIG_VIDEO_TC358743)	+= tc358743.o
>> +obj-$(CONFIG_VIDEO_OV5647)	+= ov5647.o
>> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
>> new file mode 100644
>> index 000000000000..34e620fabbaf
>> --- /dev/null
>> +++ b/drivers/media/i2c/ov5647.c
>> @@ -0,0 +1,638 @@
>> +/*
>> + * A V4L2 driver for OmniVision OV5647 cameras.
>> + *
>> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
>> + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki@samsung.com>
>> + *
>> + * Based on Omnivision OV7670 Camera Driver
>> + * Copyright (C) 2006-7 Jonathan Corbet <corbet@lwn.net>
>> + *
>> + * Copyright (C) 2016, Synopsys, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation version 2.
>> + *
>> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/i2c.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/videodev2.h>
>> +#include <media/v4l2-ctrls.h>
> 
> You don't seem to implement any controls.
> 
> The sensor likely supports exposure time (and maybe also gain) the user
> might want to control. Is there an intent to add that? Otherwise the header
> should be removed.
> 

I plan to add them in the future but for now I think I'll just remove the header.

>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-image-sizes.h>
>> +#include <media/v4l2-mediabus.h>
>> +#include <media/v4l2-of.h>
>> +
>> +#define SENSOR_NAME "ov5647"
>> +
>> +#define OV5647_SW_RESET		0x1003
>> +#define OV5647_REG_CHIPID_H	0x300A
>> +#define OV5647_REG_CHIPID_L	0x300B
>> +
>> +#define REG_TERM 0xfffe
>> +#define VAL_TERM 0xfe
>> +#define REG_DLY  0xffff
>> +
>> +#define OV5647_ROW_START		0x01
>> +#define OV5647_ROW_START_MIN		0
>> +#define OV5647_ROW_START_MAX		2004
>> +#define OV5647_ROW_START_DEF		54
>> +
>> +#define OV5647_COLUMN_START		0x02
>> +#define OV5647_COLUMN_START_MIN		0
>> +#define OV5647_COLUMN_START_MAX		2750
>> +#define OV5647_COLUMN_START_DEF		16
>> +
>> +#define OV5647_WINDOW_HEIGHT		0x03
>> +#define OV5647_WINDOW_HEIGHT_MIN	2
>> +#define OV5647_WINDOW_HEIGHT_MAX	2006
>> +#define OV5647_WINDOW_HEIGHT_DEF	1944
>> +
>> +#define OV5647_WINDOW_WIDTH		0x04
>> +#define OV5647_WINDOW_WIDTH_MIN		2
>> +#define OV5647_WINDOW_WIDTH_MAX		2752
>> +#define OV5647_WINDOW_WIDTH_DEF		2592
>> +
>> +struct regval_list {
>> +	u16 addr;
>> +	u8 data;
>> +};
>> +
>> +struct ov5647 {
>> +	struct v4l2_subdev		sd;
>> +	struct media_pad		pad;
>> +	struct mutex			lock;
>> +	struct v4l2_mbus_framefmt	format;
>> +	unsigned int			width;
>> +	unsigned int			height;
>> +	int				power_count;
>> +	struct clk			*xclk;
>> +	/* External clock frequency currently supported is 30MHz */
>> +	u32				xclk_freq;
>> +};
>> +
>> +static inline struct ov5647 *to_state(struct v4l2_subdev *sd)
>> +{
>> +	return container_of(sd, struct ov5647, sd);
>> +}
>> +
>> +static struct regval_list sensor_oe_disable_regs[] = {
>> +	{0x3000, 0x00},
>> +	{0x3001, 0x00},
>> +	{0x3002, 0x00},
>> +};
>> +
>> +static struct regval_list sensor_oe_enable_regs[] = {
>> +	{0x3000, 0x0f},
>> +	{0x3001, 0xff},
>> +	{0x3002, 0xe4},
>> +};
>> +
>> +static struct regval_list ov5647_640x480[] = {
>> +	{0x0100, 0x00},
>> +	{0x0103, 0x01},
>> +	{0x3034, 0x08},
>> +	{0x3035, 0x21},
>> +	{0x3036, 0x46},
>> +	{0x303c, 0x11},
>> +	{0x3106, 0xf5},
>> +	{0x3821, 0x07},
>> +	{0x3820, 0x41},
>> +	{0x3827, 0xec},
>> +	{0x370c, 0x0f},
>> +	{0x3612, 0x59},
>> +	{0x3618, 0x00},
>> +	{0x5000, 0x06},
>> +	{0x5001, 0x01},
>> +	{0x5002, 0x41},
>> +	{0x5003, 0x08},
>> +	{0x5a00, 0x08},
>> +	{0x3000, 0x00},
>> +	{0x3001, 0x00},
>> +	{0x3002, 0x00},
>> +	{0x3016, 0x08},
>> +	{0x3017, 0xe0},
>> +	{0x3018, 0x44},
>> +	{0x301c, 0xf8},
>> +	{0x301d, 0xf0},
>> +	{0x3a18, 0x00},
>> +	{0x3a19, 0xf8},
>> +	{0x3c01, 0x80},
>> +	{0x3b07, 0x0c},
>> +	{0x380c, 0x07},
>> +	{0x380d, 0x68},
>> +	{0x380e, 0x03},
>> +	{0x380f, 0xd8},
>> +	{0x3814, 0x31},
>> +	{0x3815, 0x31},
>> +	{0x3708, 0x64},
>> +	{0x3709, 0x52},
>> +	{0x3808, 0x02},
>> +	{0x3809, 0x80},
>> +	{0x380a, 0x01},
>> +	{0x380b, 0xE0},
>> +	{0x3801, 0x00},
>> +	{0x3802, 0x00},
>> +	{0x3803, 0x00},
>> +	{0x3804, 0x0a},
>> +	{0x3805, 0x3f},
>> +	{0x3806, 0x07},
>> +	{0x3807, 0xa1},
>> +	{0x3811, 0x08},
>> +	{0x3813, 0x02},
>> +	{0x3630, 0x2e},
>> +	{0x3632, 0xe2},
>> +	{0x3633, 0x23},
>> +	{0x3634, 0x44},
>> +	{0x3636, 0x06},
>> +	{0x3620, 0x64},
>> +	{0x3621, 0xe0},
>> +	{0x3600, 0x37},
>> +	{0x3704, 0xa0},
>> +	{0x3703, 0x5a},
>> +	{0x3715, 0x78},
>> +	{0x3717, 0x01},
>> +	{0x3731, 0x02},
>> +	{0x370b, 0x60},
>> +	{0x3705, 0x1a},
>> +	{0x3f05, 0x02},
>> +	{0x3f06, 0x10},
>> +	{0x3f01, 0x0a},
>> +	{0x3a08, 0x01},
>> +	{0x3a09, 0x27},
>> +	{0x3a0a, 0x00},
>> +	{0x3a0b, 0xf6},
>> +	{0x3a0d, 0x04},
>> +	{0x3a0e, 0x03},
>> +	{0x3a0f, 0x58},
>> +	{0x3a10, 0x50},
>> +	{0x3a1b, 0x58},
>> +	{0x3a1e, 0x50},
>> +	{0x3a11, 0x60},
>> +	{0x3a1f, 0x28},
>> +	{0x4001, 0x02},
>> +	{0x4004, 0x02},
>> +	{0x4000, 0x09},
>> +	{0x4837, 0x24},
>> +	{0x4050, 0x6e},
>> +	{0x4051, 0x8f},
>> +	{0x0100, 0x01},
>> +};
>> +
>> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val)
>> +{
>> +	int ret;
>> +	unsigned char data[3] = { reg >> 8, reg & 0xff, val};
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = i2c_master_send(client, data, 3);
>> +	if (ret < 0)
>> +		dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n",
>> +				__func__, reg);
>> +
>> +	return ret;
>> +}
>> +
>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>> +{
>> +	int ret;
>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = i2c_master_send(client, data_w, 2);
>> +	if (ret < 0) {
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>> +			__func__, reg);
>> +		return ret;
>> +	}
>> +
>> +	ret = i2c_master_recv(client, val, 1);
>> +	if (ret < 0)
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>> +				__func__, reg);
>> +
>> +	return ret;
>> +
>> +}
>> +
>> +static int ov5647_write_array(struct v4l2_subdev *sd,
>> +				struct regval_list *regs, int array_size)
>> +{
>> +	int i = 0, ret;
>> +
>> +	for (i = 0; i < array_size; i++) {
>> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
>> +{
>> +	u8 channel_id;
>> +	int ret;
>> +
>> +	ret = ov5647_read(sd, 0x4814, &channel_id);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	channel_id &= ~(3 << 6);
>> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
>> +}
>> +
>> +static int ov5647_stream_on(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x00);
>> +
>> +	dev_dbg(&client->dev, "Stream on");
>> +
>> +	return ov5647_write(sd, 0x300D, 0x00);
>> +}
>> +
>> +static int ov5647_stream_off(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x0f);
>> +
>> +	dev_dbg(&client->dev, "Stream off");
>> +
>> +	return ov5647_write(sd, 0x300D, 0x01);
>> +}
>> +
>> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
>> +{
>> +	int ret;
>> +	u8 rdval;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (standby)
>> +		rdval &= ~0x01;
>> +	else
>> +		rdval |= 0x01;
>> +
>> +	return ov5647_write(sd, 0x0100, rdval);
>> +}
>> +
>> +static int __sensor_init(struct v4l2_subdev *sd)
>> +{
>> +	int ret;
>> +	u8 resetval;
>> +	u8 rdval;
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	dev_dbg(&client->dev, "sensor init\n");
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_write_array(sd, ov5647_640x480,
>> +					ARRAY_SIZE(ov5647_640x480));
>> +	if (ret < 0) {
>> +		dev_err(&client->dev, "write sensor default regs error\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = ov5647_set_virtual_channel(sd, 0);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &resetval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (!(resetval & 0x01)) {
>> +		dev_err(&client->dev, "Device was in SW standby");
>> +		ret = ov5647_write(sd, 0x0100, 0x01);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return ov5647_write(sd, 0x4800, 0x04);
>> +}
>> +
>> +static int sensor_power(struct v4l2_subdev *sd, int on)
>> +{
>> +	int ret;
>> +	struct ov5647 *ov5647 = to_state(sd);
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = 0;
> 
> You can assign in variable declaration.
> 

Yes, you're right.

>> +	mutex_lock(&ov5647->lock);
>> +
>> +	if (on && !ov5647->power_count)	{
>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>> +
>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>> +
>> +		ret = clk_prepare_enable(ov5647->xclk);
>> +		if (ret < 0) {
>> +			dev_err(&client->dev, "clk prepare enable failed\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
>> +				ARRAY_SIZE(sensor_oe_enable_regs));
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"write sensor_oe_enable_regs error\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = __sensor_init(sd);
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"Camera not available, check Power\n");
>> +			goto out;
>> +		}
>> +	} else if (!on && ov5647->power_count == 1) {
>> +		dev_dbg(&client->dev, "OV5647 power off\n");
>> +
>> +		dev_dbg(&client->dev, "disable oe\n");
>> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
>> +				ARRAY_SIZE(sensor_oe_disable_regs));
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "disable oe failed\n");
>> +
>> +		ret = set_sw_standby(sd, true);
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "soft stby failed\n");
>> +
>> +		clk_disable_unprepare(ov5647->xclk);
>> +	}
>> +
>> +	/* Update the power count. */
>> +	ov5647->power_count += on ? 1 : -1;
>> +	WARN_ON(ov5647->power_count < 0);
>> +
>> +out:
>> +	mutex_unlock(&ov5647->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>> +static int sensor_get_register(struct v4l2_subdev *sd,
>> +				struct v4l2_dbg_register *reg)
>> +{
>> +	u8 val;
>> +	int ret;
>> +
>> +	ret = ov5647_read(sd, reg->reg & 0xff, &val);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	reg->val = val;
>> +	reg->size = 1;
>> +
>> +	return 0;
>> +}
>> +
>> +static int sensor_set_register(struct v4l2_subdev *sd,
>> +				const struct v4l2_dbg_register *reg)
>> +{
>> +	return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff);
>> +}
>> +#endif
>> +
>> +/**
>> + * @short Subdev core operations registration
>> + */
>> +static const struct v4l2_subdev_core_ops subdev_core_ops = {
>> +	.s_power		= sensor_power,
>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>> +	.g_register		= sensor_get_register,
>> +	.s_register		= sensor_set_register,
>> +#endif
>> +};
>> +
>> +static int s_stream(struct v4l2_subdev *sd, int enable)
>> +{
>> +	if (enable)
>> +		return ov5647_stream_on(sd);
>> +	else
>> +		return ov5647_stream_off(sd);
>> +}
>> +
>> +static const struct v4l2_subdev_video_ops subdev_video_ops = {
>> +	.s_stream =		s_stream,
>> +};
>> +
>> +static int enum_mbus_code(struct v4l2_subdev *sd,
>> +				struct v4l2_subdev_pad_config *cfg,
>> +				struct v4l2_subdev_mbus_code_enum *code)
>> +{
>> +	if (code->index > 0)
>> +		return -EINVAL;
>> +
>> +	code->code = MEDIA_BUS_FMT_SBGGR8_1X8;
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct v4l2_subdev_pad_ops subdev_pad_ops = {
>> +	.enum_mbus_code =	enum_mbus_code,
>> +};
>> +
>> +/**
>> + * @short Subdev operations registration
>> + *
>> + */
>> +static const struct v4l2_subdev_ops subdev_ops = {
>> +	.core		= &subdev_core_ops,
>> +	.video		= &subdev_video_ops,
>> +	.pad		= &subdev_pad_ops,
>> +};
>> +
>> +static int ov5647_detect(struct v4l2_subdev *sd)
>> +{
>> +	u8 read;
>> +	int ret;
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = ov5647_write(sd, OV5647_SW_RESET, 0x01);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (read != 0x56) {
>> +		dev_err(&client->dev, "Wrong model version detected");
> 
> You might want to tell whether it's high or low ID register that fails the
> check. And possibly the bad value. Up to you.
> 

I'll change the message and print the value that was read.

>> +		return -ENODEV;
>> +	}
>> +
>> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (read != 0x47) {
>> +		dev_err(&client->dev, "Wrong model version detected");
>> +		return -ENODEV;
>> +	}
>> +
>> +	return ov5647_write(sd, OV5647_SW_RESET, 0x00);
>> +}
>> +
>> +static int ov5647_registered(struct v4l2_subdev *sd)
>> +{
>> +	return 0;
>> +}
> 
> The registered() callback is optional, i.e. you can drop an empty callback.
> 

This is legacy code I was keeping in order to do something in the future with
the registered() callback, but I'll remove it.

>> +
>> +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
>> +{
>> +	struct v4l2_mbus_framefmt *format =
>> +				v4l2_subdev_get_try_format(sd, fh->pad, 0);
>> +	struct v4l2_rect *crop =
>> +				v4l2_subdev_get_try_crop(sd, fh->pad, 0);
>> +
>> +	crop->left = OV5647_COLUMN_START_DEF;
>> +	crop->top = OV5647_ROW_START_DEF;
>> +	crop->width = OV5647_WINDOW_WIDTH_DEF;
>> +	crop->height = OV5647_WINDOW_HEIGHT_DEF;
>> +
>> +	format->code = MEDIA_BUS_FMT_SBGGR8_1X8;
>> +
>> +	format->width = OV5647_WINDOW_WIDTH_DEF;
>> +	format->height = OV5647_WINDOW_HEIGHT_DEF;
>> +	format->field = V4L2_FIELD_NONE;
>> +	format->colorspace = V4L2_COLORSPACE_SRGB;
>> +
>> +	return sensor_power(sd, true);
>> +}
>> +
>> +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
>> +{
>> +	return sensor_power(sd, false);
>> +}
>> +
>> +/**
>> + * @short Subdev internal operations registration
>> + *
>> + */
>> +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = {
>> +	.registered = ov5647_registered,
>> +	.open = ov5647_open,
>> +	.close = ov5647_close,
>> +};
>> +
>> +static int ov5647_probe(struct i2c_client *client,
>> +			const struct i2c_device_id *id)
>> +{
>> +	struct device *dev = &client->dev;
>> +	struct ov5647 *sensor;
>> +	int ret;
>> +	struct v4l2_subdev *sd;
>> +
>> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
>> +	if (sensor == NULL)
>> +		return -ENOMEM;
>> +
>> +	/* get system clock (xclk) */
>> +	sensor->xclk = devm_clk_get(dev, "xclk");
>> +	if (IS_ERR(sensor->xclk)) {
>> +		dev_err(dev, "could not get xclk");
>> +		return PTR_ERR(sensor->xclk);
>> +	}
>> +
>> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
>> +	if (sensor->xclk_freq != 25000000) {
>> +		dev_err(dev, "Unsupported clock frequency: %u\n",
>> +			sensor->xclk_freq);
>> +		return -EINVAL;
>> +	}
>> +
>> +	mutex_init(&sensor->lock);
>> +
>> +	sd = &sensor->sd;
>> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
>> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>> +
>> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
>> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
>> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
>> +	if (ret < 0)
>> +		goto mutex_remove;
>> +
>> +	ret = ov5647_detect(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	ret = v4l2_async_register_subdev(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
>> +	return 0;
>> +error:
>> +	media_entity_cleanup(&sd->entity);
>> +mutex_remove:
>> +	mutex_destroy(&sensor->lock);
>> +	return ret;
>> +}
>> +
>> +static int ov5647_remove(struct i2c_client *client)
>> +{
>> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> +	struct ov5647 *ov5647 = to_state(sd);
>> +
>> +	v4l2_async_unregister_subdev(&ov5647->sd);
>> +	media_entity_cleanup(&ov5647->sd.entity);
>> +	v4l2_device_unregister_subdev(sd);
>> +	mutex_destroy(&ov5647->lock);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct i2c_device_id ov5647_id[] = {
>> +	{ "ov5647", 0 },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, ov5647_id);
>> +
>> +#if IS_ENABLED(CONFIG_OF)
>> +static const struct of_device_id ov5647_of_match[] = {
>> +	{ .compatible = "ovti,ov5647" },
>> +	{ /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, ov5647_of_match);
>> +#endif
>> +
>> +static struct i2c_driver ov5647_driver = {
>> +	.driver = {
>> +		.of_match_table = of_match_ptr(ov5647_of_match),
>> +		.name	= SENSOR_NAME,
>> +	},
>> +	.probe		= ov5647_probe,
>> +	.remove		= ov5647_remove,
>> +	.id_table	= ov5647_id,
>> +};
>> +
>> +module_i2c_driver(ov5647_driver);
>> +
>> +MODULE_AUTHOR("Ramiro Oliveira <roliveir@synopsys.com>");
>> +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors");
>> +MODULE_LICENSE("GPL v2");
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Sakari,

Thank you for your feedback.

On 2/21/2017 12:09 PM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> A few minor comments below.
> 
> On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote:
>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>
>> The driver adds support for 640x480 RAW 8.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> ---
>>  MAINTAINERS                |   7 +
>>  drivers/media/i2c/Kconfig  |  11 +
>>  drivers/media/i2c/Makefile |   1 +
>>  drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++
>>  4 files changed, 657 insertions(+)
>>  create mode 100644 drivers/media/i2c/ov5647.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8e7e8d7855ee..7bbca271acc8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9109,6 +9109,13 @@ M:	Harald Welte <laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org>
>>  S:	Maintained
>>  F:	drivers/char/pcmcia/cm4040_cs.*
>>  
>> +OMNIVISION OV5647 SENSOR DRIVER
>> +M:	Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> +L:	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> +T:	git git://linuxtv.org/media_tree.git
>> +S:	Maintained
>> +F:	drivers/media/i2c/ov5647.c
>> +
>>  OMNIVISION OV7670 SENSOR DRIVER
>>  M:	Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
>>  L:	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index cee1dae6e014..8435b99f38bc 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -531,6 +531,17 @@ config VIDEO_OV2659
>>  	  To compile this driver as a module, choose M here: the
>>  	  module will be called ov2659.
>>  
>> +config VIDEO_OV5647
>> +	tristate "OmniVision OV5647 sensor support"
>> +	depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>> +	depends on MEDIA_CAMERA_SUPPORT
>> +	---help---
>> +	  This is a Video4Linux2 sensor-level driver for the OmniVision
>> +	  OV5647 camera.
>> +
>> +	  To compile this driver as a module, choose M here: the
>> +	  module will be called ov5647.
>> +
>>  config VIDEO_OV7640
>>  	tristate "OmniVision OV7640 sensor support"
>>  	depends on I2C && VIDEO_V4L2
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index 5bc7bbeb5499..ef2ccf65f94c 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>>  obj-$(CONFIG_VIDEO_ML86V7667)	+= ml86v7667.o
>>  obj-$(CONFIG_VIDEO_OV2659)	+= ov2659.o
>>  obj-$(CONFIG_VIDEO_TC358743)	+= tc358743.o
>> +obj-$(CONFIG_VIDEO_OV5647)	+= ov5647.o
>> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
>> new file mode 100644
>> index 000000000000..34e620fabbaf
>> --- /dev/null
>> +++ b/drivers/media/i2c/ov5647.c
>> @@ -0,0 +1,638 @@
>> +/*
>> + * A V4L2 driver for OmniVision OV5647 cameras.
>> + *
>> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver
>> + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> + *
>> + * Based on Omnivision OV7670 Camera Driver
>> + * Copyright (C) 2006-7 Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>
>> + *
>> + * Copyright (C) 2016, Synopsys, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation version 2.
>> + *
>> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/i2c.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/videodev2.h>
>> +#include <media/v4l2-ctrls.h>
> 
> You don't seem to implement any controls.
> 
> The sensor likely supports exposure time (and maybe also gain) the user
> might want to control. Is there an intent to add that? Otherwise the header
> should be removed.
> 

I plan to add them in the future but for now I think I'll just remove the header.

>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-image-sizes.h>
>> +#include <media/v4l2-mediabus.h>
>> +#include <media/v4l2-of.h>
>> +
>> +#define SENSOR_NAME "ov5647"
>> +
>> +#define OV5647_SW_RESET		0x1003
>> +#define OV5647_REG_CHIPID_H	0x300A
>> +#define OV5647_REG_CHIPID_L	0x300B
>> +
>> +#define REG_TERM 0xfffe
>> +#define VAL_TERM 0xfe
>> +#define REG_DLY  0xffff
>> +
>> +#define OV5647_ROW_START		0x01
>> +#define OV5647_ROW_START_MIN		0
>> +#define OV5647_ROW_START_MAX		2004
>> +#define OV5647_ROW_START_DEF		54
>> +
>> +#define OV5647_COLUMN_START		0x02
>> +#define OV5647_COLUMN_START_MIN		0
>> +#define OV5647_COLUMN_START_MAX		2750
>> +#define OV5647_COLUMN_START_DEF		16
>> +
>> +#define OV5647_WINDOW_HEIGHT		0x03
>> +#define OV5647_WINDOW_HEIGHT_MIN	2
>> +#define OV5647_WINDOW_HEIGHT_MAX	2006
>> +#define OV5647_WINDOW_HEIGHT_DEF	1944
>> +
>> +#define OV5647_WINDOW_WIDTH		0x04
>> +#define OV5647_WINDOW_WIDTH_MIN		2
>> +#define OV5647_WINDOW_WIDTH_MAX		2752
>> +#define OV5647_WINDOW_WIDTH_DEF		2592
>> +
>> +struct regval_list {
>> +	u16 addr;
>> +	u8 data;
>> +};
>> +
>> +struct ov5647 {
>> +	struct v4l2_subdev		sd;
>> +	struct media_pad		pad;
>> +	struct mutex			lock;
>> +	struct v4l2_mbus_framefmt	format;
>> +	unsigned int			width;
>> +	unsigned int			height;
>> +	int				power_count;
>> +	struct clk			*xclk;
>> +	/* External clock frequency currently supported is 30MHz */
>> +	u32				xclk_freq;
>> +};
>> +
>> +static inline struct ov5647 *to_state(struct v4l2_subdev *sd)
>> +{
>> +	return container_of(sd, struct ov5647, sd);
>> +}
>> +
>> +static struct regval_list sensor_oe_disable_regs[] = {
>> +	{0x3000, 0x00},
>> +	{0x3001, 0x00},
>> +	{0x3002, 0x00},
>> +};
>> +
>> +static struct regval_list sensor_oe_enable_regs[] = {
>> +	{0x3000, 0x0f},
>> +	{0x3001, 0xff},
>> +	{0x3002, 0xe4},
>> +};
>> +
>> +static struct regval_list ov5647_640x480[] = {
>> +	{0x0100, 0x00},
>> +	{0x0103, 0x01},
>> +	{0x3034, 0x08},
>> +	{0x3035, 0x21},
>> +	{0x3036, 0x46},
>> +	{0x303c, 0x11},
>> +	{0x3106, 0xf5},
>> +	{0x3821, 0x07},
>> +	{0x3820, 0x41},
>> +	{0x3827, 0xec},
>> +	{0x370c, 0x0f},
>> +	{0x3612, 0x59},
>> +	{0x3618, 0x00},
>> +	{0x5000, 0x06},
>> +	{0x5001, 0x01},
>> +	{0x5002, 0x41},
>> +	{0x5003, 0x08},
>> +	{0x5a00, 0x08},
>> +	{0x3000, 0x00},
>> +	{0x3001, 0x00},
>> +	{0x3002, 0x00},
>> +	{0x3016, 0x08},
>> +	{0x3017, 0xe0},
>> +	{0x3018, 0x44},
>> +	{0x301c, 0xf8},
>> +	{0x301d, 0xf0},
>> +	{0x3a18, 0x00},
>> +	{0x3a19, 0xf8},
>> +	{0x3c01, 0x80},
>> +	{0x3b07, 0x0c},
>> +	{0x380c, 0x07},
>> +	{0x380d, 0x68},
>> +	{0x380e, 0x03},
>> +	{0x380f, 0xd8},
>> +	{0x3814, 0x31},
>> +	{0x3815, 0x31},
>> +	{0x3708, 0x64},
>> +	{0x3709, 0x52},
>> +	{0x3808, 0x02},
>> +	{0x3809, 0x80},
>> +	{0x380a, 0x01},
>> +	{0x380b, 0xE0},
>> +	{0x3801, 0x00},
>> +	{0x3802, 0x00},
>> +	{0x3803, 0x00},
>> +	{0x3804, 0x0a},
>> +	{0x3805, 0x3f},
>> +	{0x3806, 0x07},
>> +	{0x3807, 0xa1},
>> +	{0x3811, 0x08},
>> +	{0x3813, 0x02},
>> +	{0x3630, 0x2e},
>> +	{0x3632, 0xe2},
>> +	{0x3633, 0x23},
>> +	{0x3634, 0x44},
>> +	{0x3636, 0x06},
>> +	{0x3620, 0x64},
>> +	{0x3621, 0xe0},
>> +	{0x3600, 0x37},
>> +	{0x3704, 0xa0},
>> +	{0x3703, 0x5a},
>> +	{0x3715, 0x78},
>> +	{0x3717, 0x01},
>> +	{0x3731, 0x02},
>> +	{0x370b, 0x60},
>> +	{0x3705, 0x1a},
>> +	{0x3f05, 0x02},
>> +	{0x3f06, 0x10},
>> +	{0x3f01, 0x0a},
>> +	{0x3a08, 0x01},
>> +	{0x3a09, 0x27},
>> +	{0x3a0a, 0x00},
>> +	{0x3a0b, 0xf6},
>> +	{0x3a0d, 0x04},
>> +	{0x3a0e, 0x03},
>> +	{0x3a0f, 0x58},
>> +	{0x3a10, 0x50},
>> +	{0x3a1b, 0x58},
>> +	{0x3a1e, 0x50},
>> +	{0x3a11, 0x60},
>> +	{0x3a1f, 0x28},
>> +	{0x4001, 0x02},
>> +	{0x4004, 0x02},
>> +	{0x4000, 0x09},
>> +	{0x4837, 0x24},
>> +	{0x4050, 0x6e},
>> +	{0x4051, 0x8f},
>> +	{0x0100, 0x01},
>> +};
>> +
>> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val)
>> +{
>> +	int ret;
>> +	unsigned char data[3] = { reg >> 8, reg & 0xff, val};
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = i2c_master_send(client, data, 3);
>> +	if (ret < 0)
>> +		dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n",
>> +				__func__, reg);
>> +
>> +	return ret;
>> +}
>> +
>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>> +{
>> +	int ret;
>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = i2c_master_send(client, data_w, 2);
>> +	if (ret < 0) {
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>> +			__func__, reg);
>> +		return ret;
>> +	}
>> +
>> +	ret = i2c_master_recv(client, val, 1);
>> +	if (ret < 0)
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>> +				__func__, reg);
>> +
>> +	return ret;
>> +
>> +}
>> +
>> +static int ov5647_write_array(struct v4l2_subdev *sd,
>> +				struct regval_list *regs, int array_size)
>> +{
>> +	int i = 0, ret;
>> +
>> +	for (i = 0; i < array_size; i++) {
>> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
>> +{
>> +	u8 channel_id;
>> +	int ret;
>> +
>> +	ret = ov5647_read(sd, 0x4814, &channel_id);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	channel_id &= ~(3 << 6);
>> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
>> +}
>> +
>> +static int ov5647_stream_on(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x00);
>> +
>> +	dev_dbg(&client->dev, "Stream on");
>> +
>> +	return ov5647_write(sd, 0x300D, 0x00);
>> +}
>> +
>> +static int ov5647_stream_off(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x0f);
>> +
>> +	dev_dbg(&client->dev, "Stream off");
>> +
>> +	return ov5647_write(sd, 0x300D, 0x01);
>> +}
>> +
>> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
>> +{
>> +	int ret;
>> +	u8 rdval;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (standby)
>> +		rdval &= ~0x01;
>> +	else
>> +		rdval |= 0x01;
>> +
>> +	return ov5647_write(sd, 0x0100, rdval);
>> +}
>> +
>> +static int __sensor_init(struct v4l2_subdev *sd)
>> +{
>> +	int ret;
>> +	u8 resetval;
>> +	u8 rdval;
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	dev_dbg(&client->dev, "sensor init\n");
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_write_array(sd, ov5647_640x480,
>> +					ARRAY_SIZE(ov5647_640x480));
>> +	if (ret < 0) {
>> +		dev_err(&client->dev, "write sensor default regs error\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = ov5647_set_virtual_channel(sd, 0);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &resetval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (!(resetval & 0x01)) {
>> +		dev_err(&client->dev, "Device was in SW standby");
>> +		ret = ov5647_write(sd, 0x0100, 0x01);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return ov5647_write(sd, 0x4800, 0x04);
>> +}
>> +
>> +static int sensor_power(struct v4l2_subdev *sd, int on)
>> +{
>> +	int ret;
>> +	struct ov5647 *ov5647 = to_state(sd);
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = 0;
> 
> You can assign in variable declaration.
> 

Yes, you're right.

>> +	mutex_lock(&ov5647->lock);
>> +
>> +	if (on && !ov5647->power_count)	{
>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>> +
>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>> +
>> +		ret = clk_prepare_enable(ov5647->xclk);
>> +		if (ret < 0) {
>> +			dev_err(&client->dev, "clk prepare enable failed\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
>> +				ARRAY_SIZE(sensor_oe_enable_regs));
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"write sensor_oe_enable_regs error\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = __sensor_init(sd);
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"Camera not available, check Power\n");
>> +			goto out;
>> +		}
>> +	} else if (!on && ov5647->power_count == 1) {
>> +		dev_dbg(&client->dev, "OV5647 power off\n");
>> +
>> +		dev_dbg(&client->dev, "disable oe\n");
>> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
>> +				ARRAY_SIZE(sensor_oe_disable_regs));
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "disable oe failed\n");
>> +
>> +		ret = set_sw_standby(sd, true);
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "soft stby failed\n");
>> +
>> +		clk_disable_unprepare(ov5647->xclk);
>> +	}
>> +
>> +	/* Update the power count. */
>> +	ov5647->power_count += on ? 1 : -1;
>> +	WARN_ON(ov5647->power_count < 0);
>> +
>> +out:
>> +	mutex_unlock(&ov5647->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>> +static int sensor_get_register(struct v4l2_subdev *sd,
>> +				struct v4l2_dbg_register *reg)
>> +{
>> +	u8 val;
>> +	int ret;
>> +
>> +	ret = ov5647_read(sd, reg->reg & 0xff, &val);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	reg->val = val;
>> +	reg->size = 1;
>> +
>> +	return 0;
>> +}
>> +
>> +static int sensor_set_register(struct v4l2_subdev *sd,
>> +				const struct v4l2_dbg_register *reg)
>> +{
>> +	return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff);
>> +}
>> +#endif
>> +
>> +/**
>> + * @short Subdev core operations registration
>> + */
>> +static const struct v4l2_subdev_core_ops subdev_core_ops = {
>> +	.s_power		= sensor_power,
>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>> +	.g_register		= sensor_get_register,
>> +	.s_register		= sensor_set_register,
>> +#endif
>> +};
>> +
>> +static int s_stream(struct v4l2_subdev *sd, int enable)
>> +{
>> +	if (enable)
>> +		return ov5647_stream_on(sd);
>> +	else
>> +		return ov5647_stream_off(sd);
>> +}
>> +
>> +static const struct v4l2_subdev_video_ops subdev_video_ops = {
>> +	.s_stream =		s_stream,
>> +};
>> +
>> +static int enum_mbus_code(struct v4l2_subdev *sd,
>> +				struct v4l2_subdev_pad_config *cfg,
>> +				struct v4l2_subdev_mbus_code_enum *code)
>> +{
>> +	if (code->index > 0)
>> +		return -EINVAL;
>> +
>> +	code->code = MEDIA_BUS_FMT_SBGGR8_1X8;
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct v4l2_subdev_pad_ops subdev_pad_ops = {
>> +	.enum_mbus_code =	enum_mbus_code,
>> +};
>> +
>> +/**
>> + * @short Subdev operations registration
>> + *
>> + */
>> +static const struct v4l2_subdev_ops subdev_ops = {
>> +	.core		= &subdev_core_ops,
>> +	.video		= &subdev_video_ops,
>> +	.pad		= &subdev_pad_ops,
>> +};
>> +
>> +static int ov5647_detect(struct v4l2_subdev *sd)
>> +{
>> +	u8 read;
>> +	int ret;
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = ov5647_write(sd, OV5647_SW_RESET, 0x01);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (read != 0x56) {
>> +		dev_err(&client->dev, "Wrong model version detected");
> 
> You might want to tell whether it's high or low ID register that fails the
> check. And possibly the bad value. Up to you.
> 

I'll change the message and print the value that was read.

>> +		return -ENODEV;
>> +	}
>> +
>> +	ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (read != 0x47) {
>> +		dev_err(&client->dev, "Wrong model version detected");
>> +		return -ENODEV;
>> +	}
>> +
>> +	return ov5647_write(sd, OV5647_SW_RESET, 0x00);
>> +}
>> +
>> +static int ov5647_registered(struct v4l2_subdev *sd)
>> +{
>> +	return 0;
>> +}
> 
> The registered() callback is optional, i.e. you can drop an empty callback.
> 

This is legacy code I was keeping in order to do something in the future with
the registered() callback, but I'll remove it.

>> +
>> +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
>> +{
>> +	struct v4l2_mbus_framefmt *format =
>> +				v4l2_subdev_get_try_format(sd, fh->pad, 0);
>> +	struct v4l2_rect *crop =
>> +				v4l2_subdev_get_try_crop(sd, fh->pad, 0);
>> +
>> +	crop->left = OV5647_COLUMN_START_DEF;
>> +	crop->top = OV5647_ROW_START_DEF;
>> +	crop->width = OV5647_WINDOW_WIDTH_DEF;
>> +	crop->height = OV5647_WINDOW_HEIGHT_DEF;
>> +
>> +	format->code = MEDIA_BUS_FMT_SBGGR8_1X8;
>> +
>> +	format->width = OV5647_WINDOW_WIDTH_DEF;
>> +	format->height = OV5647_WINDOW_HEIGHT_DEF;
>> +	format->field = V4L2_FIELD_NONE;
>> +	format->colorspace = V4L2_COLORSPACE_SRGB;
>> +
>> +	return sensor_power(sd, true);
>> +}
>> +
>> +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
>> +{
>> +	return sensor_power(sd, false);
>> +}
>> +
>> +/**
>> + * @short Subdev internal operations registration
>> + *
>> + */
>> +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = {
>> +	.registered = ov5647_registered,
>> +	.open = ov5647_open,
>> +	.close = ov5647_close,
>> +};
>> +
>> +static int ov5647_probe(struct i2c_client *client,
>> +			const struct i2c_device_id *id)
>> +{
>> +	struct device *dev = &client->dev;
>> +	struct ov5647 *sensor;
>> +	int ret;
>> +	struct v4l2_subdev *sd;
>> +
>> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
>> +	if (sensor == NULL)
>> +		return -ENOMEM;
>> +
>> +	/* get system clock (xclk) */
>> +	sensor->xclk = devm_clk_get(dev, "xclk");
>> +	if (IS_ERR(sensor->xclk)) {
>> +		dev_err(dev, "could not get xclk");
>> +		return PTR_ERR(sensor->xclk);
>> +	}
>> +
>> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
>> +	if (sensor->xclk_freq != 25000000) {
>> +		dev_err(dev, "Unsupported clock frequency: %u\n",
>> +			sensor->xclk_freq);
>> +		return -EINVAL;
>> +	}
>> +
>> +	mutex_init(&sensor->lock);
>> +
>> +	sd = &sensor->sd;
>> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
>> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>> +
>> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
>> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
>> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
>> +	if (ret < 0)
>> +		goto mutex_remove;
>> +
>> +	ret = ov5647_detect(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	ret = v4l2_async_register_subdev(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
>> +	return 0;
>> +error:
>> +	media_entity_cleanup(&sd->entity);
>> +mutex_remove:
>> +	mutex_destroy(&sensor->lock);
>> +	return ret;
>> +}
>> +
>> +static int ov5647_remove(struct i2c_client *client)
>> +{
>> +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
>> +	struct ov5647 *ov5647 = to_state(sd);
>> +
>> +	v4l2_async_unregister_subdev(&ov5647->sd);
>> +	media_entity_cleanup(&ov5647->sd.entity);
>> +	v4l2_device_unregister_subdev(sd);
>> +	mutex_destroy(&ov5647->lock);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct i2c_device_id ov5647_id[] = {
>> +	{ "ov5647", 0 },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, ov5647_id);
>> +
>> +#if IS_ENABLED(CONFIG_OF)
>> +static const struct of_device_id ov5647_of_match[] = {
>> +	{ .compatible = "ovti,ov5647" },
>> +	{ /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, ov5647_of_match);
>> +#endif
>> +
>> +static struct i2c_driver ov5647_driver = {
>> +	.driver = {
>> +		.of_match_table = of_match_ptr(ov5647_of_match),
>> +		.name	= SENSOR_NAME,
>> +	},
>> +	.probe		= ov5647_probe,
>> +	.remove		= ov5647_remove,
>> +	.id_table	= ov5647_id,
>> +};
>> +
>> +module_i2c_driver(ov5647_driver);
>> +
>> +MODULE_AUTHOR("Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>");
>> +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors");
>> +MODULE_LICENSE("GPL v2");
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Sakari Ailus]

Hi Ramiro,

On Tue, Feb 21, 2017 at 02:49:12PM +0000, Ramiro Oliveira wrote:
> Hi Sakari,
> 
> Thank you for your feedback.

You're welcome.

An additional note as you don't implement any controls --- some CSI-2
receivers may need to know the link frequency to know how to program the
receiver; they'll simply fail to start streaming if you don't.

<URL:http://hverkuil.home.xs4all.nl/spec/uapi/v4l/extended-controls.html#image-process-control-reference>

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

Hi Ramiro,

please find some review comments below.

On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
> and RAW 10 output formats, and MIPI CSI-2 interface.
> 
> The driver adds support for 640x480 RAW 8.
> 
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---

[snip]

> +
> +struct ov5647 {
> +	struct v4l2_subdev		sd;
> +	struct media_pad		pad;
> +	struct mutex			lock;
> +	struct v4l2_mbus_framefmt	format;
> +	unsigned int			width;
> +	unsigned int			height;
> +	int				power_count;
> +	struct clk			*xclk;
> +	/* External clock frequency currently supported is 30MHz */
> +	u32				xclk_freq;

See a comment about 25MHz vs 30MHz below.

Also I assume you can remove 'xclk_freq' from the struct fields,
it can be replaced by a local variable.

> +};

[snip]

> +
> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
> +{
> +	int ret;
> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = i2c_master_send(client, data_w, 2);
> +	if (ret < 0) {
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",

s/i2c read error/i2c write error/

> +			__func__, reg);
> +		return ret;
> +	}
> +
> +	ret = i2c_master_recv(client, val, 1);
> +	if (ret < 0)
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> +				__func__, reg);
> +
> +	return ret;
> +

Please remove the empty line above.

> +}
> +
> +static int ov5647_write_array(struct v4l2_subdev *sd,
> +				struct regval_list *regs, int array_size)
> +{
> +	int i = 0, ret;

Assignment of 'i' on declaration is not needed, please remove.

> +
> +	for (i = 0; i < array_size; i++) {
> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
> +{
> +	u8 channel_id;
> +	int ret;
> +
> +	ret = ov5647_read(sd, 0x4814, &channel_id);
> +	if (ret < 0)
> +		return ret;
> +
> +	channel_id &= ~(3 << 6);
> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
> +}
> +
> +static int ov5647_stream_on(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x00);

Should you add a check of the returned value?

> +
> +	dev_dbg(&client->dev, "Stream on");

I would suggest to remove dev_dbg(), because ftrace will report to a user,
when this function is called.

Also dev_dbg() in the middle of two I2C transfers in a row looks as being
placed improperly.

> +
> +	return ov5647_write(sd, 0x300D, 0x00);
> +}
> +
> +static int ov5647_stream_off(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x0f);

Should you add a check of the returned value?

> +
> +	dev_dbg(&client->dev, "Stream off");

I would suggest to remove dev_dbg(), because ftrace will report to a user,
when this function is called.

Also dev_dbg() in the middle of two I2C transfers in a row looks as being
placed improperly.

> +
> +	return ov5647_write(sd, 0x300D, 0x01);
> +}
> +
> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
> +{
> +	int ret;
> +	u8 rdval;
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (standby)
> +		rdval &= ~0x01;
> +	else
> +		rdval |= 0x01;
> +
> +	return ov5647_write(sd, 0x0100, rdval);
> +}
> +
> +static int __sensor_init(struct v4l2_subdev *sd)
> +{
> +	int ret;
> +	u8 resetval;
> +	u8 rdval;

It could be possible to put declarations of 'resetval' and 'rdval' on the same line.

> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	dev_dbg(&client->dev, "sensor init\n");
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_write_array(sd, ov5647_640x480,
> +					ARRAY_SIZE(ov5647_640x480));
> +	if (ret < 0) {
> +		dev_err(&client->dev, "write sensor default regs error\n");
> +		return ret;
> +	}
> +
> +	ret = ov5647_set_virtual_channel(sd, 0);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_read(sd, 0x0100, &resetval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (!(resetval & 0x01)) {
> +		dev_err(&client->dev, "Device was in SW standby");
> +		ret = ov5647_write(sd, 0x0100, 0x01);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return ov5647_write(sd, 0x4800, 0x04);
> +}
> +
> +static int sensor_power(struct v4l2_subdev *sd, int on)
> +{
> +	int ret;
> +	struct ov5647 *ov5647 = to_state(sd);
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = 0;
> +	mutex_lock(&ov5647->lock);
> +
> +	if (on && !ov5647->power_count)	{
> +		dev_dbg(&client->dev, "OV5647 power on\n");
> +
> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);

Now clk_set_rate() is redundant, please remove it.

If once it is needed again, please move it to the .probe function, so
it is called only once in the runtime.

> +
> +		ret = clk_prepare_enable(ov5647->xclk);

I wonder would it be possible to unload the driver or to unbind the device
and leave the clock unintentionally enabled? If yes, then this is a bug.

> +		if (ret < 0) {
> +			dev_err(&client->dev, "clk prepare enable failed\n");
> +			goto out;
> +		}
> +
> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
> +				ARRAY_SIZE(sensor_oe_enable_regs));
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"write sensor_oe_enable_regs error\n");
> +			goto out;
> +		}
> +
> +		ret = __sensor_init(sd);
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"Camera not available, check Power\n");
> +			goto out;
> +		}
> +	} else if (!on && ov5647->power_count == 1) {
> +		dev_dbg(&client->dev, "OV5647 power off\n");
> +
> +		dev_dbg(&client->dev, "disable oe\n");

One of two dev_dbg()'s above is apparently redundant.

> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
> +				ARRAY_SIZE(sensor_oe_disable_regs));
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "disable oe failed\n");
> +
> +		ret = set_sw_standby(sd, true);
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "soft stby failed\n");
> +
> +		clk_disable_unprepare(ov5647->xclk);
> +	}
> +
> +	/* Update the power count. */
> +	ov5647->power_count += on ? 1 : -1;
> +	WARN_ON(ov5647->power_count < 0);
> +
> +out:
> +	mutex_unlock(&ov5647->lock);
> +
> +	return ret;
> +}
> +

[snip]

> +
> +static int ov5647_probe(struct i2c_client *client,
> +			const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct ov5647 *sensor;
> +	int ret;
> +	struct v4l2_subdev *sd;
> +
> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
> +	if (sensor == NULL)

if (!sensor) is a bit shorter.

> +		return -ENOMEM;
> +
> +	/* get system clock (xclk) */
> +	sensor->xclk = devm_clk_get(dev, "xclk");
> +	if (IS_ERR(sensor->xclk)) {
> +		dev_err(dev, "could not get xclk");
> +		return PTR_ERR(sensor->xclk);
> +	}
> +
> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
> +	if (sensor->xclk_freq != 25000000) {

A comment in "struct ov5647" declaration says about 30MHz, which one is correct?

> +		dev_err(dev, "Unsupported clock frequency: %u\n",
> +			sensor->xclk_freq);
> +		return -EINVAL;
> +	}
> +
> +	mutex_init(&sensor->lock);
> +
> +	sd = &sensor->sd;
> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> +
> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
> +	if (ret < 0)
> +		goto mutex_remove;
> +
> +	ret = ov5647_detect(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	ret = v4l2_async_register_subdev(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
> +	return 0;
> +error:
> +	media_entity_cleanup(&sd->entity);
> +mutex_remove:
> +	mutex_destroy(&sensor->lock);
> +	return ret;
> +}
> +

[snip]

The driver looks good in general IMO.

--
With best wishes,
Vladimir

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

Hi Ramiro,

please find some review comments below.

On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
> and RAW 10 output formats, and MIPI CSI-2 interface.
> 
> The driver adds support for 640x480 RAW 8.
> 
> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---

[snip]

> +
> +struct ov5647 {
> +	struct v4l2_subdev		sd;
> +	struct media_pad		pad;
> +	struct mutex			lock;
> +	struct v4l2_mbus_framefmt	format;
> +	unsigned int			width;
> +	unsigned int			height;
> +	int				power_count;
> +	struct clk			*xclk;
> +	/* External clock frequency currently supported is 30MHz */
> +	u32				xclk_freq;

See a comment about 25MHz vs 30MHz below.

Also I assume you can remove 'xclk_freq' from the struct fields,
it can be replaced by a local variable.

> +};

[snip]

> +
> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
> +{
> +	int ret;
> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = i2c_master_send(client, data_w, 2);
> +	if (ret < 0) {
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",

s/i2c read error/i2c write error/

> +			__func__, reg);
> +		return ret;
> +	}
> +
> +	ret = i2c_master_recv(client, val, 1);
> +	if (ret < 0)
> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> +				__func__, reg);
> +
> +	return ret;
> +

Please remove the empty line above.

> +}
> +
> +static int ov5647_write_array(struct v4l2_subdev *sd,
> +				struct regval_list *regs, int array_size)
> +{
> +	int i = 0, ret;

Assignment of 'i' on declaration is not needed, please remove.

> +
> +	for (i = 0; i < array_size; i++) {
> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
> +{
> +	u8 channel_id;
> +	int ret;
> +
> +	ret = ov5647_read(sd, 0x4814, &channel_id);
> +	if (ret < 0)
> +		return ret;
> +
> +	channel_id &= ~(3 << 6);
> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
> +}
> +
> +static int ov5647_stream_on(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x00);

Should you add a check of the returned value?

> +
> +	dev_dbg(&client->dev, "Stream on");

I would suggest to remove dev_dbg(), because ftrace will report to a user,
when this function is called.

Also dev_dbg() in the middle of two I2C transfers in a row looks as being
placed improperly.

> +
> +	return ov5647_write(sd, 0x300D, 0x00);
> +}
> +
> +static int ov5647_stream_off(struct v4l2_subdev *sd)
> +{
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ov5647_write(sd, 0x4202, 0x0f);

Should you add a check of the returned value?

> +
> +	dev_dbg(&client->dev, "Stream off");

I would suggest to remove dev_dbg(), because ftrace will report to a user,
when this function is called.

Also dev_dbg() in the middle of two I2C transfers in a row looks as being
placed improperly.

> +
> +	return ov5647_write(sd, 0x300D, 0x01);
> +}
> +
> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
> +{
> +	int ret;
> +	u8 rdval;
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (standby)
> +		rdval &= ~0x01;
> +	else
> +		rdval |= 0x01;
> +
> +	return ov5647_write(sd, 0x0100, rdval);
> +}
> +
> +static int __sensor_init(struct v4l2_subdev *sd)
> +{
> +	int ret;
> +	u8 resetval;
> +	u8 rdval;

It could be possible to put declarations of 'resetval' and 'rdval' on the same line.

> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	dev_dbg(&client->dev, "sensor init\n");
> +
> +	ret = ov5647_read(sd, 0x0100, &rdval);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_write_array(sd, ov5647_640x480,
> +					ARRAY_SIZE(ov5647_640x480));
> +	if (ret < 0) {
> +		dev_err(&client->dev, "write sensor default regs error\n");
> +		return ret;
> +	}
> +
> +	ret = ov5647_set_virtual_channel(sd, 0);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = ov5647_read(sd, 0x0100, &resetval);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (!(resetval & 0x01)) {
> +		dev_err(&client->dev, "Device was in SW standby");
> +		ret = ov5647_write(sd, 0x0100, 0x01);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return ov5647_write(sd, 0x4800, 0x04);
> +}
> +
> +static int sensor_power(struct v4l2_subdev *sd, int on)
> +{
> +	int ret;
> +	struct ov5647 *ov5647 = to_state(sd);
> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> +	ret = 0;
> +	mutex_lock(&ov5647->lock);
> +
> +	if (on && !ov5647->power_count)	{
> +		dev_dbg(&client->dev, "OV5647 power on\n");
> +
> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);

Now clk_set_rate() is redundant, please remove it.

If once it is needed again, please move it to the .probe function, so
it is called only once in the runtime.

> +
> +		ret = clk_prepare_enable(ov5647->xclk);

I wonder would it be possible to unload the driver or to unbind the device
and leave the clock unintentionally enabled? If yes, then this is a bug.

> +		if (ret < 0) {
> +			dev_err(&client->dev, "clk prepare enable failed\n");
> +			goto out;
> +		}
> +
> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
> +				ARRAY_SIZE(sensor_oe_enable_regs));
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"write sensor_oe_enable_regs error\n");
> +			goto out;
> +		}
> +
> +		ret = __sensor_init(sd);
> +		if (ret < 0) {
> +			clk_disable_unprepare(ov5647->xclk);
> +			dev_err(&client->dev,
> +				"Camera not available, check Power\n");
> +			goto out;
> +		}
> +	} else if (!on && ov5647->power_count == 1) {
> +		dev_dbg(&client->dev, "OV5647 power off\n");
> +
> +		dev_dbg(&client->dev, "disable oe\n");

One of two dev_dbg()'s above is apparently redundant.

> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
> +				ARRAY_SIZE(sensor_oe_disable_regs));
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "disable oe failed\n");
> +
> +		ret = set_sw_standby(sd, true);
> +
> +		if (ret < 0)
> +			dev_dbg(&client->dev, "soft stby failed\n");
> +
> +		clk_disable_unprepare(ov5647->xclk);
> +	}
> +
> +	/* Update the power count. */
> +	ov5647->power_count += on ? 1 : -1;
> +	WARN_ON(ov5647->power_count < 0);
> +
> +out:
> +	mutex_unlock(&ov5647->lock);
> +
> +	return ret;
> +}
> +

[snip]

> +
> +static int ov5647_probe(struct i2c_client *client,
> +			const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct ov5647 *sensor;
> +	int ret;
> +	struct v4l2_subdev *sd;
> +
> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
> +	if (sensor == NULL)

if (!sensor) is a bit shorter.

> +		return -ENOMEM;
> +
> +	/* get system clock (xclk) */
> +	sensor->xclk = devm_clk_get(dev, "xclk");
> +	if (IS_ERR(sensor->xclk)) {
> +		dev_err(dev, "could not get xclk");
> +		return PTR_ERR(sensor->xclk);
> +	}
> +
> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
> +	if (sensor->xclk_freq != 25000000) {

A comment in "struct ov5647" declaration says about 30MHz, which one is correct?

> +		dev_err(dev, "Unsupported clock frequency: %u\n",
> +			sensor->xclk_freq);
> +		return -EINVAL;
> +	}
> +
> +	mutex_init(&sensor->lock);
> +
> +	sd = &sensor->sd;
> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> +
> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
> +	if (ret < 0)
> +		goto mutex_remove;
> +
> +	ret = ov5647_detect(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	ret = v4l2_async_register_subdev(sd);
> +	if (ret < 0)
> +		goto error;
> +
> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
> +	return 0;
> +error:
> +	media_entity_cleanup(&sd->entity);
> +mutex_remove:
> +	mutex_destroy(&sensor->lock);
> +	return ret;
> +}
> +

[snip]

The driver looks good in general IMO.

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index 000000000000..31956426d3b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +---------------------------------
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible		: "ovti,ov5647".
> +- reg			: I2C slave address of the sensor.
> +- clocks		: Reference to the xclk clock.

Is "xclk" clock a pixel clock or something else?

> +- clock-names		: Should be "xclk".

You can remove this property, because there is only one source clock.

> +- clock-frequency	: Frequency of the xclk clock.

And after the last updates in the driver this property can be removed as well.

> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.
> +
> +Example:
> +
> +	i2c@2000 {
> +		...
> +		ov: camera@36 {
> +			compatible = "ovti,ov5647";
> +			reg = <0x36>;
> +			clocks = <&camera_clk>;
> +			clock-names = "xclk";
> +			clock-frequency = <25000000>;

When you remove two unused properties, please don't forget to update the
example.

> +			port {
> +				camera_1: endpoint {
> +					remote-endpoint = <&csi1_ep1>;
> +				};
> +			};
> +		};
> +	};
> 

--
With best wishes,
Vladimir

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
> 
> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index 000000000000..31956426d3b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +---------------------------------
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible		: "ovti,ov5647".
> +- reg			: I2C slave address of the sensor.
> +- clocks		: Reference to the xclk clock.

Is "xclk" clock a pixel clock or something else?

> +- clock-names		: Should be "xclk".

You can remove this property, because there is only one source clock.

> +- clock-frequency	: Frequency of the xclk clock.

And after the last updates in the driver this property can be removed as well.

> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.
> +
> +Example:
> +
> +	i2c@2000 {
> +		...
> +		ov: camera@36 {
> +			compatible = "ovti,ov5647";
> +			reg = <0x36>;
> +			clocks = <&camera_clk>;
> +			clock-names = "xclk";
> +			clock-frequency = <25000000>;

When you remove two unused properties, please don't forget to update the
example.

> +			port {
> +				camera_1: endpoint {
> +					remote-endpoint = <&csi1_ep1>;
> +				};
> +			};
> +		};
> +	};
> 

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Vladimir,

Thank you for your feedback

On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> please find some review comments below.
> 
> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>
>> The driver adds support for 640x480 RAW 8.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>> ---
> 
> [snip]
> 
>> +
>> +struct ov5647 {
>> +	struct v4l2_subdev		sd;
>> +	struct media_pad		pad;
>> +	struct mutex			lock;
>> +	struct v4l2_mbus_framefmt	format;
>> +	unsigned int			width;
>> +	unsigned int			height;
>> +	int				power_count;
>> +	struct clk			*xclk;
>> +	/* External clock frequency currently supported is 30MHz */
>> +	u32				xclk_freq;
> 
> See a comment about 25MHz vs 30MHz below.
> 
> Also I assume you can remove 'xclk_freq' from the struct fields,
> it can be replaced by a local variable.
> 

I'll do that.

>> +};
> 
> [snip]
> 
>> +
>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>> +{
>> +	int ret;
>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = i2c_master_send(client, data_w, 2);
>> +	if (ret < 0) {
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> 
> s/i2c read error/i2c write error/
> 

I'm not sure I understand what you mean.

>> +			__func__, reg);
>> +		return ret;
>> +	}
>> +
>> +	ret = i2c_master_recv(client, val, 1);
>> +	if (ret < 0)
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>> +				__func__, reg);
>> +
>> +	return ret;
>> +
> 
> Please remove the empty line above.
> 

Ok.

>> +}
>> +
>> +static int ov5647_write_array(struct v4l2_subdev *sd,
>> +				struct regval_list *regs, int array_size)
>> +{
>> +	int i = 0, ret;
> 
> Assignment of 'i' on declaration is not needed, please remove.
> 

Ok.

>> +
>> +	for (i = 0; i < array_size; i++) {
>> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
>> +{
>> +	u8 channel_id;
>> +	int ret;
>> +
>> +	ret = ov5647_read(sd, 0x4814, &channel_id);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	channel_id &= ~(3 << 6);
>> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
>> +}
>> +
>> +static int ov5647_stream_on(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x00);
> 
> Should you add a check of the returned value?
> 

I'll add it.

>> +
>> +	dev_dbg(&client->dev, "Stream on");
> 
> I would suggest to remove dev_dbg(), because ftrace will report to a user,
> when this function is called.
> 
> Also dev_dbg() in the middle of two I2C transfers in a row looks as being
> placed improperly.
> 

I'll remove it.

>> +
>> +	return ov5647_write(sd, 0x300D, 0x00);
>> +}
>> +
>> +static int ov5647_stream_off(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x0f);
> 
> Should you add a check of the returned value?
> 

I'll add it.

>> +
>> +	dev_dbg(&client->dev, "Stream off");
> 
> I would suggest to remove dev_dbg(), because ftrace will report to a user,
> when this function is called.
> 
> Also dev_dbg() in the middle of two I2C transfers in a row looks as being
> placed improperly.
> 

I'll remove it.

>> +
>> +	return ov5647_write(sd, 0x300D, 0x01);
>> +}
>> +
>> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
>> +{
>> +	int ret;
>> +	u8 rdval;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (standby)
>> +		rdval &= ~0x01;
>> +	else
>> +		rdval |= 0x01;
>> +
>> +	return ov5647_write(sd, 0x0100, rdval);
>> +}
>> +
>> +static int __sensor_init(struct v4l2_subdev *sd)
>> +{
>> +	int ret;
>> +	u8 resetval;
>> +	u8 rdval;
> 
> It could be possible to put declarations of 'resetval' and 'rdval' on the same line.
> 

Sure.

>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	dev_dbg(&client->dev, "sensor init\n");
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_write_array(sd, ov5647_640x480,
>> +					ARRAY_SIZE(ov5647_640x480));
>> +	if (ret < 0) {
>> +		dev_err(&client->dev, "write sensor default regs error\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = ov5647_set_virtual_channel(sd, 0);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &resetval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (!(resetval & 0x01)) {
>> +		dev_err(&client->dev, "Device was in SW standby");
>> +		ret = ov5647_write(sd, 0x0100, 0x01);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return ov5647_write(sd, 0x4800, 0x04);
>> +}
>> +
>> +static int sensor_power(struct v4l2_subdev *sd, int on)
>> +{
>> +	int ret;
>> +	struct ov5647 *ov5647 = to_state(sd);
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = 0;
>> +	mutex_lock(&ov5647->lock);
>> +
>> +	if (on && !ov5647->power_count)	{
>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>> +
>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
> 
> Now clk_set_rate() is redundant, please remove it.
> 
> If once it is needed again, please move it to the .probe function, so
> it is called only once in the runtime.
> 

Ok. I'll remove it for now.

>> +
>> +		ret = clk_prepare_enable(ov5647->xclk);
> 
> I wonder would it be possible to unload the driver or to unbind the device
> and leave the clock unintentionally enabled? If yes, then this is a bug.
> 

You're saying that if the driver was unloaded and the clock was left enabled
when the driver was loaded again this line would cause an error?

Should I disable the clock when the driver is removed?

>> +		if (ret < 0) {
>> +			dev_err(&client->dev, "clk prepare enable failed\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
>> +				ARRAY_SIZE(sensor_oe_enable_regs));
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"write sensor_oe_enable_regs error\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = __sensor_init(sd);
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"Camera not available, check Power\n");
>> +			goto out;
>> +		}
>> +	} else if (!on && ov5647->power_count == 1) {
>> +		dev_dbg(&client->dev, "OV5647 power off\n");
>> +
>> +		dev_dbg(&client->dev, "disable oe\n");
> 
> One of two dev_dbg()'s above is apparently redundant.
> 

I'll remove one.

>> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
>> +				ARRAY_SIZE(sensor_oe_disable_regs));
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "disable oe failed\n");
>> +
>> +		ret = set_sw_standby(sd, true);
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "soft stby failed\n");
>> +
>> +		clk_disable_unprepare(ov5647->xclk);
>> +	}
>> +
>> +	/* Update the power count. */
>> +	ov5647->power_count += on ? 1 : -1;
>> +	WARN_ON(ov5647->power_count < 0);
>> +
>> +out:
>> +	mutex_unlock(&ov5647->lock);
>> +
>> +	return ret;
>> +}
>> +
> 
> [snip]
> 
>> +
>> +static int ov5647_probe(struct i2c_client *client,
>> +			const struct i2c_device_id *id)
>> +{
>> +	struct device *dev = &client->dev;
>> +	struct ov5647 *sensor;
>> +	int ret;
>> +	struct v4l2_subdev *sd;
>> +
>> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
>> +	if (sensor == NULL)
> 
> if (!sensor) is a bit shorter.
> 

I'll change it.

>> +		return -ENOMEM;
>> +
>> +	/* get system clock (xclk) */
>> +	sensor->xclk = devm_clk_get(dev, "xclk");
>> +	if (IS_ERR(sensor->xclk)) {
>> +		dev_err(dev, "could not get xclk");
>> +		return PTR_ERR(sensor->xclk);
>> +	}
>> +
>> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
>> +	if (sensor->xclk_freq != 25000000) {
> 
> A comment in "struct ov5647" declaration says about 30MHz, which one is correct?
> 

25 MHz is the correct one.

>> +		dev_err(dev, "Unsupported clock frequency: %u\n",
>> +			sensor->xclk_freq);
>> +		return -EINVAL;
>> +	}
>> +
>> +	mutex_init(&sensor->lock);
>> +
>> +	sd = &sensor->sd;
>> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
>> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>> +
>> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
>> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
>> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
>> +	if (ret < 0)
>> +		goto mutex_remove;
>> +
>> +	ret = ov5647_detect(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	ret = v4l2_async_register_subdev(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
>> +	return 0;
>> +error:
>> +	media_entity_cleanup(&sd->entity);
>> +mutex_remove:
>> +	mutex_destroy(&sensor->lock);
>> +	return ret;
>> +}
>> +
> 
> [snip]
> 
> The driver looks good in general IMO.
> 
> --
> With best wishes,
> Vladimir
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Vladimir,

Thank you for your feedback

On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> please find some review comments below.
> 
> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>
>> The driver adds support for 640x480 RAW 8.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>> ---
> 
> [snip]
> 
>> +
>> +struct ov5647 {
>> +	struct v4l2_subdev		sd;
>> +	struct media_pad		pad;
>> +	struct mutex			lock;
>> +	struct v4l2_mbus_framefmt	format;
>> +	unsigned int			width;
>> +	unsigned int			height;
>> +	int				power_count;
>> +	struct clk			*xclk;
>> +	/* External clock frequency currently supported is 30MHz */
>> +	u32				xclk_freq;
> 
> See a comment about 25MHz vs 30MHz below.
> 
> Also I assume you can remove 'xclk_freq' from the struct fields,
> it can be replaced by a local variable.
> 

I'll do that.

>> +};
> 
> [snip]
> 
>> +
>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>> +{
>> +	int ret;
>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = i2c_master_send(client, data_w, 2);
>> +	if (ret < 0) {
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
> 
> s/i2c read error/i2c write error/
> 

I'm not sure I understand what you mean.

>> +			__func__, reg);
>> +		return ret;
>> +	}
>> +
>> +	ret = i2c_master_recv(client, val, 1);
>> +	if (ret < 0)
>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>> +				__func__, reg);
>> +
>> +	return ret;
>> +
> 
> Please remove the empty line above.
> 

Ok.

>> +}
>> +
>> +static int ov5647_write_array(struct v4l2_subdev *sd,
>> +				struct regval_list *regs, int array_size)
>> +{
>> +	int i = 0, ret;
> 
> Assignment of 'i' on declaration is not needed, please remove.
> 

Ok.

>> +
>> +	for (i = 0; i < array_size; i++) {
>> +		ret = ov5647_write(sd, regs[i].addr, regs[i].data);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel)
>> +{
>> +	u8 channel_id;
>> +	int ret;
>> +
>> +	ret = ov5647_read(sd, 0x4814, &channel_id);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	channel_id &= ~(3 << 6);
>> +	return ov5647_write(sd, 0x4814, channel_id | (channel << 6));
>> +}
>> +
>> +static int ov5647_stream_on(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x00);
> 
> Should you add a check of the returned value?
> 

I'll add it.

>> +
>> +	dev_dbg(&client->dev, "Stream on");
> 
> I would suggest to remove dev_dbg(), because ftrace will report to a user,
> when this function is called.
> 
> Also dev_dbg() in the middle of two I2C transfers in a row looks as being
> placed improperly.
> 

I'll remove it.

>> +
>> +	return ov5647_write(sd, 0x300D, 0x00);
>> +}
>> +
>> +static int ov5647_stream_off(struct v4l2_subdev *sd)
>> +{
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ov5647_write(sd, 0x4202, 0x0f);
> 
> Should you add a check of the returned value?
> 

I'll add it.

>> +
>> +	dev_dbg(&client->dev, "Stream off");
> 
> I would suggest to remove dev_dbg(), because ftrace will report to a user,
> when this function is called.
> 
> Also dev_dbg() in the middle of two I2C transfers in a row looks as being
> placed improperly.
> 

I'll remove it.

>> +
>> +	return ov5647_write(sd, 0x300D, 0x01);
>> +}
>> +
>> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
>> +{
>> +	int ret;
>> +	u8 rdval;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (standby)
>> +		rdval &= ~0x01;
>> +	else
>> +		rdval |= 0x01;
>> +
>> +	return ov5647_write(sd, 0x0100, rdval);
>> +}
>> +
>> +static int __sensor_init(struct v4l2_subdev *sd)
>> +{
>> +	int ret;
>> +	u8 resetval;
>> +	u8 rdval;
> 
> It could be possible to put declarations of 'resetval' and 'rdval' on the same line.
> 

Sure.

>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	dev_dbg(&client->dev, "sensor init\n");
>> +
>> +	ret = ov5647_read(sd, 0x0100, &rdval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_write_array(sd, ov5647_640x480,
>> +					ARRAY_SIZE(ov5647_640x480));
>> +	if (ret < 0) {
>> +		dev_err(&client->dev, "write sensor default regs error\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = ov5647_set_virtual_channel(sd, 0);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	ret = ov5647_read(sd, 0x0100, &resetval);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	if (!(resetval & 0x01)) {
>> +		dev_err(&client->dev, "Device was in SW standby");
>> +		ret = ov5647_write(sd, 0x0100, 0x01);
>> +		if (ret < 0)
>> +			return ret;
>> +	}
>> +
>> +	return ov5647_write(sd, 0x4800, 0x04);
>> +}
>> +
>> +static int sensor_power(struct v4l2_subdev *sd, int on)
>> +{
>> +	int ret;
>> +	struct ov5647 *ov5647 = to_state(sd);
>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> +	ret = 0;
>> +	mutex_lock(&ov5647->lock);
>> +
>> +	if (on && !ov5647->power_count)	{
>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>> +
>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
> 
> Now clk_set_rate() is redundant, please remove it.
> 
> If once it is needed again, please move it to the .probe function, so
> it is called only once in the runtime.
> 

Ok. I'll remove it for now.

>> +
>> +		ret = clk_prepare_enable(ov5647->xclk);
> 
> I wonder would it be possible to unload the driver or to unbind the device
> and leave the clock unintentionally enabled? If yes, then this is a bug.
> 

You're saying that if the driver was unloaded and the clock was left enabled
when the driver was loaded again this line would cause an error?

Should I disable the clock when the driver is removed?

>> +		if (ret < 0) {
>> +			dev_err(&client->dev, "clk prepare enable failed\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = ov5647_write_array(sd, sensor_oe_enable_regs,
>> +				ARRAY_SIZE(sensor_oe_enable_regs));
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"write sensor_oe_enable_regs error\n");
>> +			goto out;
>> +		}
>> +
>> +		ret = __sensor_init(sd);
>> +		if (ret < 0) {
>> +			clk_disable_unprepare(ov5647->xclk);
>> +			dev_err(&client->dev,
>> +				"Camera not available, check Power\n");
>> +			goto out;
>> +		}
>> +	} else if (!on && ov5647->power_count == 1) {
>> +		dev_dbg(&client->dev, "OV5647 power off\n");
>> +
>> +		dev_dbg(&client->dev, "disable oe\n");
> 
> One of two dev_dbg()'s above is apparently redundant.
> 

I'll remove one.

>> +		ret = ov5647_write_array(sd, sensor_oe_disable_regs,
>> +				ARRAY_SIZE(sensor_oe_disable_regs));
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "disable oe failed\n");
>> +
>> +		ret = set_sw_standby(sd, true);
>> +
>> +		if (ret < 0)
>> +			dev_dbg(&client->dev, "soft stby failed\n");
>> +
>> +		clk_disable_unprepare(ov5647->xclk);
>> +	}
>> +
>> +	/* Update the power count. */
>> +	ov5647->power_count += on ? 1 : -1;
>> +	WARN_ON(ov5647->power_count < 0);
>> +
>> +out:
>> +	mutex_unlock(&ov5647->lock);
>> +
>> +	return ret;
>> +}
>> +
> 
> [snip]
> 
>> +
>> +static int ov5647_probe(struct i2c_client *client,
>> +			const struct i2c_device_id *id)
>> +{
>> +	struct device *dev = &client->dev;
>> +	struct ov5647 *sensor;
>> +	int ret;
>> +	struct v4l2_subdev *sd;
>> +
>> +	sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL);
>> +	if (sensor == NULL)
> 
> if (!sensor) is a bit shorter.
> 

I'll change it.

>> +		return -ENOMEM;
>> +
>> +	/* get system clock (xclk) */
>> +	sensor->xclk = devm_clk_get(dev, "xclk");
>> +	if (IS_ERR(sensor->xclk)) {
>> +		dev_err(dev, "could not get xclk");
>> +		return PTR_ERR(sensor->xclk);
>> +	}
>> +
>> +	sensor->xclk_freq = clk_get_rate(sensor->xclk);
>> +	if (sensor->xclk_freq != 25000000) {
> 
> A comment in "struct ov5647" declaration says about 30MHz, which one is correct?
> 

25 MHz is the correct one.

>> +		dev_err(dev, "Unsupported clock frequency: %u\n",
>> +			sensor->xclk_freq);
>> +		return -EINVAL;
>> +	}
>> +
>> +	mutex_init(&sensor->lock);
>> +
>> +	sd = &sensor->sd;
>> +	v4l2_i2c_subdev_init(sd, client, &subdev_ops);
>> +	sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>> +
>> +	sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
>> +	sd->entity.function = MEDIA_ENT_F_CAM_SENSOR;
>> +	ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad);
>> +	if (ret < 0)
>> +		goto mutex_remove;
>> +
>> +	ret = ov5647_detect(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	ret = v4l2_async_register_subdev(sd);
>> +	if (ret < 0)
>> +		goto error;
>> +
>> +	dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n");
>> +	return 0;
>> +error:
>> +	media_entity_cleanup(&sd->entity);
>> +mutex_remove:
>> +	mutex_destroy(&sensor->lock);
>> +	return ret;
>> +}
>> +
> 
> [snip]
> 
> The driver looks good in general IMO.
> 
> --
> With best wishes,
> Vladimir
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Vladimir,

Thank you for your feedback

On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>> Create device tree bindings documentation.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> new file mode 100644
>> index 000000000000..31956426d3b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> @@ -0,0 +1,35 @@
>> +Omnivision OV5647 raw image sensor
>> +---------------------------------
>> +
>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>> +and CCI (I2C compatible) control bus.
>> +
>> +Required properties:
>> +
>> +- compatible		: "ovti,ov5647".
>> +- reg			: I2C slave address of the sensor.
>> +- clocks		: Reference to the xclk clock.
> 
> Is "xclk" clock a pixel clock or something else?
> 

It's an external oscillator.

>> +- clock-names		: Should be "xclk".
> 
> You can remove this property, because there is only one source clock.
> 

Ok.

>> +- clock-frequency	: Frequency of the xclk clock.
> 
> And after the last updates in the driver this property can be removed as well.
> 

But I'm still using clk_get_rate in the driver, if I remove the frequency here
the probing will fail.

>> +
>> +The common video interfaces bindings (see video-interfaces.txt) should be
>> +used to specify link to the image data receiver. The OV5647 device
>> +node should contain one 'port' child node with an 'endpoint' subnode.
>> +
>> +Example:
>> +
>> +	i2c@2000 {
>> +		...
>> +		ov: camera@36 {
>> +			compatible = "ovti,ov5647";
>> +			reg = <0x36>;
>> +			clocks = <&camera_clk>;
>> +			clock-names = "xclk";
>> +			clock-frequency = <25000000>;
> 
> When you remove two unused properties, please don't forget to update the
> example.
> 

Ok.

>> +			port {
>> +				camera_1: endpoint {
>> +					remote-endpoint = <&csi1_ep1>;
>> +				};
>> +			};
>> +		};
>> +	};
>>
> 
> --
> With best wishes,
> Vladimir
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Vladimir,

Thank you for your feedback

On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>> Create device tree bindings documentation.
>>
>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> new file mode 100644
>> index 000000000000..31956426d3b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> @@ -0,0 +1,35 @@
>> +Omnivision OV5647 raw image sensor
>> +---------------------------------
>> +
>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>> +and CCI (I2C compatible) control bus.
>> +
>> +Required properties:
>> +
>> +- compatible		: "ovti,ov5647".
>> +- reg			: I2C slave address of the sensor.
>> +- clocks		: Reference to the xclk clock.
> 
> Is "xclk" clock a pixel clock or something else?
> 

It's an external oscillator.

>> +- clock-names		: Should be "xclk".
> 
> You can remove this property, because there is only one source clock.
> 

Ok.

>> +- clock-frequency	: Frequency of the xclk clock.
> 
> And after the last updates in the driver this property can be removed as well.
> 

But I'm still using clk_get_rate in the driver, if I remove the frequency here
the probing will fail.

>> +
>> +The common video interfaces bindings (see video-interfaces.txt) should be
>> +used to specify link to the image data receiver. The OV5647 device
>> +node should contain one 'port' child node with an 'endpoint' subnode.
>> +
>> +Example:
>> +
>> +	i2c@2000 {
>> +		...
>> +		ov: camera@36 {
>> +			compatible = "ovti,ov5647";
>> +			reg = <0x36>;
>> +			clocks = <&camera_clk>;
>> +			clock-names = "xclk";
>> +			clock-frequency = <25000000>;
> 
> When you remove two unused properties, please don't forget to update the
> example.
> 

Ok.

>> +			port {
>> +				camera_1: endpoint {
>> +					remote-endpoint = <&csi1_ep1>;
>> +				};
>> +			};
>> +		};
>> +	};
>>
> 
> --
> With best wishes,
> Vladimir
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/21/2017 06:42 PM, Ramiro Oliveira wrote:
> Hi Vladimir,
> 
> Thank you for your feedback
> 
> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> please find some review comments below.
>>
>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>>
>>> The driver adds support for 640x480 RAW 8.
>>>
>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>> ---
>>
>> [snip]
>>
>>> +
>>> +struct ov5647 {
>>> +	struct v4l2_subdev		sd;
>>> +	struct media_pad		pad;
>>> +	struct mutex			lock;
>>> +	struct v4l2_mbus_framefmt	format;
>>> +	unsigned int			width;
>>> +	unsigned int			height;
>>> +	int				power_count;
>>> +	struct clk			*xclk;
>>> +	/* External clock frequency currently supported is 30MHz */
>>> +	u32				xclk_freq;
>>
>> See a comment about 25MHz vs 30MHz below.
>>
>> Also I assume you can remove 'xclk_freq' from the struct fields,
>> it can be replaced by a local variable.
>>
> 
> I'll do that.
> 
>>> +};
>>
>> [snip]
>>
>>> +
>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>>> +{
>>> +	int ret;
>>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> +
>>> +	ret = i2c_master_send(client, data_w, 2);
>>> +	if (ret < 0) {
>>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>>
>> s/i2c read error/i2c write error/
>>
> 
> I'm not sure I understand what you mean.

That's a sed expression for string substitution. Here you do i2c_master_send()
but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix.

>>> +			__func__, reg);
>>> +		return ret;
>>> +	}
>>> +

[snip]

>>> +
>>> +static int sensor_power(struct v4l2_subdev *sd, int on)

On the caller's side (functions ov5647_open() and ov5647_close()) the second
argument of the function is of 'bool' type, however .s_power callback from
struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as
'int'.

It's just a nitpicking, please feel free to ignore the comment above or
please consider to change the arguments on callers' side to integers.

Also you may consider to add 'ov5647_' prefix to the function name to
distinguish it from a potentially added in future sensor_power() function,
the original name sounds too generic.

>>> +{
>>> +	int ret;
>>> +	struct ov5647 *ov5647 = to_state(sd);
>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> +
>>> +	ret = 0;
>>> +	mutex_lock(&ov5647->lock);
>>> +
>>> +	if (on && !ov5647->power_count)	{
>>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>>> +
>>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>>
>> Now clk_set_rate() is redundant, please remove it.
>>
>> If once it is needed again, please move it to the .probe function, so
>> it is called only once in the runtime.
>>
> 
> Ok. I'll remove it for now.
> 
>>> +
>>> +		ret = clk_prepare_enable(ov5647->xclk);
>>
>> I wonder would it be possible to unload the driver or to unbind the device
>> and leave the clock unintentionally enabled? If yes, then this is a bug.
>>
> 
> You're saying that if the driver was unloaded and the clock was left enabled
> when the driver was loaded again this line would cause an error?

Not exactly, here I saw a potential resource leak, namely a potentially left
prepared/enabled clock.

> 
> Should I disable the clock when the driver is removed?
> 

The driver (and framework) shall guarantee that when it is detached from
device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device),
all acquired resources are released.

But in this particular case most probably I've been overly alert, I believe
that V4L2 framework correcly handles device power states, so please ignore my
comment.

To add something valuable to the review, could you please confirm that
ov5647_subdev_internal_ops data is in use by the driver?

E.g. shouldn't it be registered by

  sd->internal_ops = &ov5647_subdev_internal_ops;

before calling v4l2_async_register_subdev(sd) ?

--
With best wishes,
Vladimir

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/21/2017 06:42 PM, Ramiro Oliveira wrote:
> Hi Vladimir,
> 
> Thank you for your feedback
> 
> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> please find some review comments below.
>>
>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>>
>>> The driver adds support for 640x480 RAW 8.
>>>
>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>> ---
>>
>> [snip]
>>
>>> +
>>> +struct ov5647 {
>>> +	struct v4l2_subdev		sd;
>>> +	struct media_pad		pad;
>>> +	struct mutex			lock;
>>> +	struct v4l2_mbus_framefmt	format;
>>> +	unsigned int			width;
>>> +	unsigned int			height;
>>> +	int				power_count;
>>> +	struct clk			*xclk;
>>> +	/* External clock frequency currently supported is 30MHz */
>>> +	u32				xclk_freq;
>>
>> See a comment about 25MHz vs 30MHz below.
>>
>> Also I assume you can remove 'xclk_freq' from the struct fields,
>> it can be replaced by a local variable.
>>
> 
> I'll do that.
> 
>>> +};
>>
>> [snip]
>>
>>> +
>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>>> +{
>>> +	int ret;
>>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> +
>>> +	ret = i2c_master_send(client, data_w, 2);
>>> +	if (ret < 0) {
>>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>>
>> s/i2c read error/i2c write error/
>>
> 
> I'm not sure I understand what you mean.

That's a sed expression for string substitution. Here you do i2c_master_send()
but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix.

>>> +			__func__, reg);
>>> +		return ret;
>>> +	}
>>> +

[snip]

>>> +
>>> +static int sensor_power(struct v4l2_subdev *sd, int on)

On the caller's side (functions ov5647_open() and ov5647_close()) the second
argument of the function is of 'bool' type, however .s_power callback from
struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as
'int'.

It's just a nitpicking, please feel free to ignore the comment above or
please consider to change the arguments on callers' side to integers.

Also you may consider to add 'ov5647_' prefix to the function name to
distinguish it from a potentially added in future sensor_power() function,
the original name sounds too generic.

>>> +{
>>> +	int ret;
>>> +	struct ov5647 *ov5647 = to_state(sd);
>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> +
>>> +	ret = 0;
>>> +	mutex_lock(&ov5647->lock);
>>> +
>>> +	if (on && !ov5647->power_count)	{
>>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>>> +
>>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>>
>> Now clk_set_rate() is redundant, please remove it.
>>
>> If once it is needed again, please move it to the .probe function, so
>> it is called only once in the runtime.
>>
> 
> Ok. I'll remove it for now.
> 
>>> +
>>> +		ret = clk_prepare_enable(ov5647->xclk);
>>
>> I wonder would it be possible to unload the driver or to unbind the device
>> and leave the clock unintentionally enabled? If yes, then this is a bug.
>>
> 
> You're saying that if the driver was unloaded and the clock was left enabled
> when the driver was loaded again this line would cause an error?

Not exactly, here I saw a potential resource leak, namely a potentially left
prepared/enabled clock.

> 
> Should I disable the clock when the driver is removed?
> 

The driver (and framework) shall guarantee that when it is detached from
device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device),
all acquired resources are released.

But in this particular case most probably I've been overly alert, I believe
that V4L2 framework correcly handles device power states, so please ignore my
comment.

To add something valuable to the review, could you please confirm that
ov5647_subdev_internal_ops data is in use by the driver?

E.g. shouldn't it be registered by

  sd->internal_ops = &ov5647_subdev_internal_ops;

before calling v4l2_async_register_subdev(sd) ?

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> Hi Vladimir,
> 
> Thank you for your feedback
> 
> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>> Create device tree bindings documentation.
>>>
>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>  1 file changed, 35 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> new file mode 100644
>>> index 000000000000..31956426d3b9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> @@ -0,0 +1,35 @@
>>> +Omnivision OV5647 raw image sensor
>>> +---------------------------------
>>> +
>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>> +and CCI (I2C compatible) control bus.
>>> +
>>> +Required properties:
>>> +
>>> +- compatible		: "ovti,ov5647".
>>> +- reg			: I2C slave address of the sensor.
>>> +- clocks		: Reference to the xclk clock.
>>
>> Is "xclk" clock a pixel clock or something else?
>>
> 
> It's an external oscillator.

hmm, I suppose a clock of any type could serve as a clock for the sensor.
It can be an external oscillator on a particular board, or it can be
something else on another board.

Can you please describe what for does ov5647 sensor need this clock, what
is its function?

> 
>>> +- clock-names		: Should be "xclk".
>>
>> You can remove this property, because there is only one source clock.
>>
> 
> Ok.
> 
>>> +- clock-frequency	: Frequency of the xclk clock.
>>
>> And after the last updates in the driver this property can be removed as well.
>>
> 
> But I'm still using clk_get_rate in the driver, if I remove the frequency here
> the probing will fail.
> 

I doubt it, there should be no connection between a custom "clock-frequency"
device tree property in a clock consumer device node and clk_get_rate() function
from the CCF, which takes a clock provider as its argument.

>>> +
>>> +The common video interfaces bindings (see video-interfaces.txt) should be
>>> +used to specify link to the image data receiver. The OV5647 device
>>> +node should contain one 'port' child node with an 'endpoint' subnode.
>>> +
>>> +Example:
>>> +
>>> +	i2c@2000 {
>>> +		...
>>> +		ov: camera@36 {
>>> +			compatible = "ovti,ov5647";
>>> +			reg = <0x36>;
>>> +			clocks = <&camera_clk>;
>>> +			clock-names = "xclk";
>>> +			clock-frequency = <25000000>;
>>
>> When you remove two unused properties, please don't forget to update the
>> example.
>>
> 
> Ok.
> 
>>> +			port {
>>> +				camera_1: endpoint {
>>> +					remote-endpoint = <&csi1_ep1>;
>>> +				};
>>> +			};
>>> +		};
>>> +	};
>>>
>>

--
With best wishes,
Vladimir

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> Hi Vladimir,
> 
> Thank you for your feedback
> 
> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>> Create device tree bindings documentation.
>>>
>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> ---
>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>  1 file changed, 35 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> new file mode 100644
>>> index 000000000000..31956426d3b9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> @@ -0,0 +1,35 @@
>>> +Omnivision OV5647 raw image sensor
>>> +---------------------------------
>>> +
>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>> +and CCI (I2C compatible) control bus.
>>> +
>>> +Required properties:
>>> +
>>> +- compatible		: "ovti,ov5647".
>>> +- reg			: I2C slave address of the sensor.
>>> +- clocks		: Reference to the xclk clock.
>>
>> Is "xclk" clock a pixel clock or something else?
>>
> 
> It's an external oscillator.

hmm, I suppose a clock of any type could serve as a clock for the sensor.
It can be an external oscillator on a particular board, or it can be
something else on another board.

Can you please describe what for does ov5647 sensor need this clock, what
is its function?

> 
>>> +- clock-names		: Should be "xclk".
>>
>> You can remove this property, because there is only one source clock.
>>
> 
> Ok.
> 
>>> +- clock-frequency	: Frequency of the xclk clock.
>>
>> And after the last updates in the driver this property can be removed as well.
>>
> 
> But I'm still using clk_get_rate in the driver, if I remove the frequency here
> the probing will fail.
> 

I doubt it, there should be no connection between a custom "clock-frequency"
device tree property in a clock consumer device node and clk_get_rate() function
from the CCF, which takes a clock provider as its argument.

>>> +
>>> +The common video interfaces bindings (see video-interfaces.txt) should be
>>> +used to specify link to the image data receiver. The OV5647 device
>>> +node should contain one 'port' child node with an 'endpoint' subnode.
>>> +
>>> +Example:
>>> +
>>> +	i2c@2000 {
>>> +		...
>>> +		ov: camera@36 {
>>> +			compatible = "ovti,ov5647";
>>> +			reg = <0x36>;
>>> +			clocks = <&camera_clk>;
>>> +			clock-names = "xclk";
>>> +			clock-frequency = <25000000>;
>>
>> When you remove two unused properties, please don't forget to update the
>> example.
>>
> 
> Ok.
> 
>>> +			port {
>>> +				camera_1: endpoint {
>>> +					remote-endpoint = <&csi1_ep1>;
>>> +				};
>>> +			};
>>> +		};
>>> +	};
>>>
>>

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi, Vladimir!

How do you do? :-)

On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> > Hi Vladimir,
> > 
> > Thank you for your feedback
> > 
> > On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> >> Hi Ramiro,
> >>
> >> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> >>> Create device tree bindings documentation.
> >>>
> >>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> >>> Acked-by: Rob Herring <robh@kernel.org>
> >>> ---
> >>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
> >>>  1 file changed, 35 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>> new file mode 100644
> >>> index 000000000000..31956426d3b9
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>> @@ -0,0 +1,35 @@
> >>> +Omnivision OV5647 raw image sensor
> >>> +---------------------------------
> >>> +
> >>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >>> +and CCI (I2C compatible) control bus.
> >>> +
> >>> +Required properties:
> >>> +
> >>> +- compatible		: "ovti,ov5647".
> >>> +- reg			: I2C slave address of the sensor.
> >>> +- clocks		: Reference to the xclk clock.
> >>
> >> Is "xclk" clock a pixel clock or something else?
> >>
> > 
> > It's an external oscillator.
> 
> hmm, I suppose a clock of any type could serve as a clock for the sensor.
> It can be an external oscillator on a particular board, or it can be
> something else on another board.

Any clock source could be used I presume.

> 
> Can you please describe what for does ov5647 sensor need this clock, what
> is its function?

Camera modules (sensors) quite commonly require an external clock as they do
not have an oscillator on their own. A lot of devices under
Documentation/devicetree/bindings/media/i2c/ have similar properties.

> 
> > 
> >>> +- clock-names		: Should be "xclk".
> >>
> >> You can remove this property, because there is only one source clock.
> >>
> > 
> > Ok.
> > 
> >>> +- clock-frequency	: Frequency of the xclk clock.
> >>
> >> And after the last updates in the driver this property can be removed as well.
> >>
> > 
> > But I'm still using clk_get_rate in the driver, if I remove the frequency here
> > the probing will fail.
> > 
> 
> I doubt it, there should be no connection between a custom "clock-frequency"
> device tree property in a clock consumer device node and clk_get_rate() function
> from the CCF, which takes a clock provider as its argument.

The purpose is to make sure the clock frequency is really usable for the
device, in this particular case the driver can work with one particular
frequency.

That said, the driver does not appear to use the property at the moment. It
should.

It'd be good to verify that the rate matches: clk_set_rate() is not
guaranteed to produce the requested clock rate, and the driver could
conceivably be updated with support for more frequencies. There are
typically a few frequencies that a SoC such a sensor is connected can
support, and 25 MHz is not one of the common frequencies. With this
property, the frequency would be always there explicitly.

> 
> >>> +
> >>> +The common video interfaces bindings (see video-interfaces.txt) should be
> >>> +used to specify link to the image data receiver. The OV5647 device
> >>> +node should contain one 'port' child node with an 'endpoint' subnode.
> >>> +
> >>> +Example:
> >>> +
> >>> +	i2c@2000 {
> >>> +		...
> >>> +		ov: camera@36 {
> >>> +			compatible = "ovti,ov5647";
> >>> +			reg = <0x36>;
> >>> +			clocks = <&camera_clk>;
> >>> +			clock-names = "xclk";
> >>> +			clock-frequency = <25000000>;
> >>
> >> When you remove two unused properties, please don't forget to update the
> >> example.
> >>
> > 
> > Ok.
> > 
> >>> +			port {
> >>> +				camera_1: endpoint {
> >>> +					remote-endpoint = <&csi1_ep1>;
> >>> +				};
> >>> +			};
> >>> +		};
> >>> +	};
> >>>
> >>
> 
> --
    ^
There's a space missing here.

> With best wishes,
> Vladimir

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi, Vladimir!

How do you do? :-)

On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> > Hi Vladimir,
> > 
> > Thank you for your feedback
> > 
> > On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> >> Hi Ramiro,
> >>
> >> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> >>> Create device tree bindings documentation.
> >>>
> >>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> >>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>> ---
> >>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
> >>>  1 file changed, 35 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>> new file mode 100644
> >>> index 000000000000..31956426d3b9
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>> @@ -0,0 +1,35 @@
> >>> +Omnivision OV5647 raw image sensor
> >>> +---------------------------------
> >>> +
> >>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >>> +and CCI (I2C compatible) control bus.
> >>> +
> >>> +Required properties:
> >>> +
> >>> +- compatible		: "ovti,ov5647".
> >>> +- reg			: I2C slave address of the sensor.
> >>> +- clocks		: Reference to the xclk clock.
> >>
> >> Is "xclk" clock a pixel clock or something else?
> >>
> > 
> > It's an external oscillator.
> 
> hmm, I suppose a clock of any type could serve as a clock for the sensor.
> It can be an external oscillator on a particular board, or it can be
> something else on another board.

Any clock source could be used I presume.

> 
> Can you please describe what for does ov5647 sensor need this clock, what
> is its function?

Camera modules (sensors) quite commonly require an external clock as they do
not have an oscillator on their own. A lot of devices under
Documentation/devicetree/bindings/media/i2c/ have similar properties.

> 
> > 
> >>> +- clock-names		: Should be "xclk".
> >>
> >> You can remove this property, because there is only one source clock.
> >>
> > 
> > Ok.
> > 
> >>> +- clock-frequency	: Frequency of the xclk clock.
> >>
> >> And after the last updates in the driver this property can be removed as well.
> >>
> > 
> > But I'm still using clk_get_rate in the driver, if I remove the frequency here
> > the probing will fail.
> > 
> 
> I doubt it, there should be no connection between a custom "clock-frequency"
> device tree property in a clock consumer device node and clk_get_rate() function
> from the CCF, which takes a clock provider as its argument.

The purpose is to make sure the clock frequency is really usable for the
device, in this particular case the driver can work with one particular
frequency.

That said, the driver does not appear to use the property at the moment. It
should.

It'd be good to verify that the rate matches: clk_set_rate() is not
guaranteed to produce the requested clock rate, and the driver could
conceivably be updated with support for more frequencies. There are
typically a few frequencies that a SoC such a sensor is connected can
support, and 25 MHz is not one of the common frequencies. With this
property, the frequency would be always there explicitly.

> 
> >>> +
> >>> +The common video interfaces bindings (see video-interfaces.txt) should be
> >>> +used to specify link to the image data receiver. The OV5647 device
> >>> +node should contain one 'port' child node with an 'endpoint' subnode.
> >>> +
> >>> +Example:
> >>> +
> >>> +	i2c@2000 {
> >>> +		...
> >>> +		ov: camera@36 {
> >>> +			compatible = "ovti,ov5647";
> >>> +			reg = <0x36>;
> >>> +			clocks = <&camera_clk>;
> >>> +			clock-names = "xclk";
> >>> +			clock-frequency = <25000000>;
> >>
> >> When you remove two unused properties, please don't forget to update the
> >> example.
> >>
> > 
> > Ok.
> > 
> >>> +			port {
> >>> +				camera_1: endpoint {
> >>> +					remote-endpoint = <&csi1_ep1>;
> >>> +				};
> >>> +			};
> >>> +		};
> >>> +	};
> >>>
> >>
> 
> --
    ^
There's a space missing here.

> With best wishes,
> Vladimir

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Sakari,

On 02/21/2017 11:48 PM, Sakari Ailus wrote:
> Hi, Vladimir!
> 
> How do you do? :-)

deferring execution of boring tasks by doing code review :)

> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>> Hi Vladimir,
>>>
>>> Thank you for your feedback
>>>
>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>> Hi Ramiro,
>>>>
>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>> Create device tree bindings documentation.
>>>>>
>>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>> ---
>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>  1 file changed, 35 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>> new file mode 100644
>>>>> index 000000000000..31956426d3b9
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>> @@ -0,0 +1,35 @@
>>>>> +Omnivision OV5647 raw image sensor
>>>>> +---------------------------------
>>>>> +
>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>> +and CCI (I2C compatible) control bus.
>>>>> +
>>>>> +Required properties:
>>>>> +
>>>>> +- compatible		: "ovti,ov5647".
>>>>> +- reg			: I2C slave address of the sensor.
>>>>> +- clocks		: Reference to the xclk clock.
>>>>
>>>> Is "xclk" clock a pixel clock or something else?
>>>>
>>>
>>> It's an external oscillator.
>>
>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>> It can be an external oscillator on a particular board, or it can be
>> something else on another board.
> 
> Any clock source could be used I presume.
> 

That's exactly my point, and it is a reason to rename "xclk" to something
more generic.

>>
>> Can you please describe what for does ov5647 sensor need this clock, what
>> is its function?
> 
> Camera modules (sensors) quite commonly require an external clock as they do
> not have an oscillator on their own. A lot of devices under
> Documentation/devicetree/bindings/media/i2c/ have similar properties.
> 

So, what should be a better replacement of "xclk" in the description above?

E.g.

- clocks		: Phandle to a device supply clock.

>>
>>>
>>>>> +- clock-names		: Should be "xclk".

We got an agreement that "clock-names" property is removed, nevertheless
if it is added back, is should not be "xclk".

>>>>
>>>> You can remove this property, because there is only one source clock.
>>>>
>>>
>>> Ok.
>>>
>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>
>>>> And after the last updates in the driver this property can be removed as well.
>>>>
>>>
>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>> the probing will fail.
>>>
>>
>> I doubt it, there should be no connection between a custom "clock-frequency"
>> device tree property in a clock consumer device node and clk_get_rate() function
>> from the CCF, which takes a clock provider as its argument.
> 
> The purpose is to make sure the clock frequency is really usable for the
> device, in this particular case the driver can work with one particular
> frequency.
> 
> That said, the driver does not appear to use the property at the moment. It
> should.
> 
> It'd be good to verify that the rate matches: clk_set_rate() is not
> guaranteed to produce the requested clock rate, and the driver could
> conceivably be updated with support for more frequencies. There are
> typically a few frequencies that a SoC such a sensor is connected can
> support, and 25 MHz is not one of the common frequencies. With this
> property, the frequency would be always there explicitly.
> 

I can provide my arguments given at v8 review time again, since I don't
see a contradiction with my older comments.

Briefly "clock-frequency" as a device tree property on a consumer side
can be considered as redundant, because there is a mechanism to specify
a wanted clock frequency on a clock provider side right in a board DTB.

So, the clock frequency set up is delegated to CCF, and when any other
than 25 MHz frequencies are got supported, that's only the matter of
driver updates, DTBs won't be touched.

--
With best wishes,
Vladimir

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Sakari,

On 02/21/2017 11:48 PM, Sakari Ailus wrote:
> Hi, Vladimir!
> 
> How do you do? :-)

deferring execution of boring tasks by doing code review :)

> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>> Hi Vladimir,
>>>
>>> Thank you for your feedback
>>>
>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>> Hi Ramiro,
>>>>
>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>> Create device tree bindings documentation.
>>>>>
>>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>> ---
>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>  1 file changed, 35 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>> new file mode 100644
>>>>> index 000000000000..31956426d3b9
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>> @@ -0,0 +1,35 @@
>>>>> +Omnivision OV5647 raw image sensor
>>>>> +---------------------------------
>>>>> +
>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>> +and CCI (I2C compatible) control bus.
>>>>> +
>>>>> +Required properties:
>>>>> +
>>>>> +- compatible		: "ovti,ov5647".
>>>>> +- reg			: I2C slave address of the sensor.
>>>>> +- clocks		: Reference to the xclk clock.
>>>>
>>>> Is "xclk" clock a pixel clock or something else?
>>>>
>>>
>>> It's an external oscillator.
>>
>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>> It can be an external oscillator on a particular board, or it can be
>> something else on another board.
> 
> Any clock source could be used I presume.
> 

That's exactly my point, and it is a reason to rename "xclk" to something
more generic.

>>
>> Can you please describe what for does ov5647 sensor need this clock, what
>> is its function?
> 
> Camera modules (sensors) quite commonly require an external clock as they do
> not have an oscillator on their own. A lot of devices under
> Documentation/devicetree/bindings/media/i2c/ have similar properties.
> 

So, what should be a better replacement of "xclk" in the description above?

E.g.

- clocks		: Phandle to a device supply clock.

>>
>>>
>>>>> +- clock-names		: Should be "xclk".

We got an agreement that "clock-names" property is removed, nevertheless
if it is added back, is should not be "xclk".

>>>>
>>>> You can remove this property, because there is only one source clock.
>>>>
>>>
>>> Ok.
>>>
>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>
>>>> And after the last updates in the driver this property can be removed as well.
>>>>
>>>
>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>> the probing will fail.
>>>
>>
>> I doubt it, there should be no connection between a custom "clock-frequency"
>> device tree property in a clock consumer device node and clk_get_rate() function
>> from the CCF, which takes a clock provider as its argument.
> 
> The purpose is to make sure the clock frequency is really usable for the
> device, in this particular case the driver can work with one particular
> frequency.
> 
> That said, the driver does not appear to use the property at the moment. It
> should.
> 
> It'd be good to verify that the rate matches: clk_set_rate() is not
> guaranteed to produce the requested clock rate, and the driver could
> conceivably be updated with support for more frequencies. There are
> typically a few frequencies that a SoC such a sensor is connected can
> support, and 25 MHz is not one of the common frequencies. With this
> property, the frequency would be always there explicitly.
> 

I can provide my arguments given at v8 review time again, since I don't
see a contradiction with my older comments.

Briefly "clock-frequency" as a device tree property on a consumer side
can be considered as redundant, because there is a mechanism to specify
a wanted clock frequency on a clock provider side right in a board DTB.

So, the clock frequency set up is delegated to CCF, and when any other
than 25 MHz frequencies are got supported, that's only the matter of
driver updates, DTBs won't be touched.

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Zakari,

On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/21/2017 06:42 PM, Ramiro Oliveira wrote:
>> Hi Vladimir,
>>
>> Thank you for your feedback
>>
>> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
>>> Hi Ramiro,
>>>
>>> please find some review comments below.
>>>
>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>>>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>>>
>>>> The driver adds support for 640x480 RAW 8.
>>>>
>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>>> ---
>>>
>>> [snip]
>>>
>>>> +
>>>> +struct ov5647 {
>>>> +	struct v4l2_subdev		sd;
>>>> +	struct media_pad		pad;
>>>> +	struct mutex			lock;
>>>> +	struct v4l2_mbus_framefmt	format;
>>>> +	unsigned int			width;
>>>> +	unsigned int			height;
>>>> +	int				power_count;
>>>> +	struct clk			*xclk;
>>>> +	/* External clock frequency currently supported is 30MHz */
>>>> +	u32				xclk_freq;
>>>
>>> See a comment about 25MHz vs 30MHz below.
>>>
>>> Also I assume you can remove 'xclk_freq' from the struct fields,
>>> it can be replaced by a local variable.
>>>
>>
>> I'll do that.
>>
>>>> +};
>>>
>>> [snip]
>>>
>>>> +
>>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>>>> +{
>>>> +	int ret;
>>>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>> +
>>>> +	ret = i2c_master_send(client, data_w, 2);
>>>> +	if (ret < 0) {
>>>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>>>
>>> s/i2c read error/i2c write error/
>>>
>>
>> I'm not sure I understand what you mean.
> 
> That's a sed expression for string substitution. Here you do i2c_master_send()
> but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix.
> 

Ohh... now I see. I'll change it.

>>>> +			__func__, reg);
>>>> +		return ret;
>>>> +	}
>>>> +
> 
> [snip]
> 
>>>> +
>>>> +static int sensor_power(struct v4l2_subdev *sd, int on)
> 
> On the caller's side (functions ov5647_open() and ov5647_close()) the second
> argument of the function is of 'bool' type, however .s_power callback from
> struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as
> 'int'.
> 
> It's just a nitpicking, please feel free to ignore the comment above or
> please consider to change the arguments on callers' side to integers.
> 
> Also you may consider to add 'ov5647_' prefix to the function name to
> distinguish it from a potentially added in future sensor_power() function,
> the original name sounds too generic.
> 

OK. I'll add the prefix and change the variable type from int to bool.

>>>> +{
>>>> +	int ret;
>>>> +	struct ov5647 *ov5647 = to_state(sd);
>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>> +
>>>> +	ret = 0;
>>>> +	mutex_lock(&ov5647->lock);
>>>> +
>>>> +	if (on && !ov5647->power_count)	{
>>>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>>>> +
>>>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>>>
>>> Now clk_set_rate() is redundant, please remove it.
>>>
>>> If once it is needed again, please move it to the .probe function, so
>>> it is called only once in the runtime.
>>>
>>
>> Ok. I'll remove it for now.
>>
>>>> +
>>>> +		ret = clk_prepare_enable(ov5647->xclk);
>>>
>>> I wonder would it be possible to unload the driver or to unbind the device
>>> and leave the clock unintentionally enabled? If yes, then this is a bug.
>>>
>>
>> You're saying that if the driver was unloaded and the clock was left enabled
>> when the driver was loaded again this line would cause an error?
> 
> Not exactly, here I saw a potential resource leak, namely a potentially left
> prepared/enabled clock.
> 
>>
>> Should I disable the clock when the driver is removed?
>>
> 
> The driver (and framework) shall guarantee that when it is detached from
> device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device),
> all acquired resources are released.
> 
> But in this particular case most probably I've been overly alert, I believe
> that V4L2 framework correcly handles device power states, so please ignore my
> comment.
> 
> To add something valuable to the review, could you please confirm that
> ov5647_subdev_internal_ops data is in use by the driver?
> 
> E.g. shouldn't it be registered by
> 
>   sd->internal_ops = &ov5647_subdev_internal_ops;
> 
> before calling v4l2_async_register_subdev(sd) ?
> 

You're right, it's not being registered. I think I'll remove them since they
aren't being used.

> --
> With best wishes,
> Vladimir
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Ramiro Oliveira]

Hi Zakari,

On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/21/2017 06:42 PM, Ramiro Oliveira wrote:
>> Hi Vladimir,
>>
>> Thank you for your feedback
>>
>> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
>>> Hi Ramiro,
>>>
>>> please find some review comments below.
>>>
>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>>>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>>>
>>>> The driver adds support for 640x480 RAW 8.
>>>>
>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>
>>> [snip]
>>>
>>>> +
>>>> +struct ov5647 {
>>>> +	struct v4l2_subdev		sd;
>>>> +	struct media_pad		pad;
>>>> +	struct mutex			lock;
>>>> +	struct v4l2_mbus_framefmt	format;
>>>> +	unsigned int			width;
>>>> +	unsigned int			height;
>>>> +	int				power_count;
>>>> +	struct clk			*xclk;
>>>> +	/* External clock frequency currently supported is 30MHz */
>>>> +	u32				xclk_freq;
>>>
>>> See a comment about 25MHz vs 30MHz below.
>>>
>>> Also I assume you can remove 'xclk_freq' from the struct fields,
>>> it can be replaced by a local variable.
>>>
>>
>> I'll do that.
>>
>>>> +};
>>>
>>> [snip]
>>>
>>>> +
>>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>>>> +{
>>>> +	int ret;
>>>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>> +
>>>> +	ret = i2c_master_send(client, data_w, 2);
>>>> +	if (ret < 0) {
>>>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>>>
>>> s/i2c read error/i2c write error/
>>>
>>
>> I'm not sure I understand what you mean.
> 
> That's a sed expression for string substitution. Here you do i2c_master_send()
> but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix.
> 

Ohh... now I see. I'll change it.

>>>> +			__func__, reg);
>>>> +		return ret;
>>>> +	}
>>>> +
> 
> [snip]
> 
>>>> +
>>>> +static int sensor_power(struct v4l2_subdev *sd, int on)
> 
> On the caller's side (functions ov5647_open() and ov5647_close()) the second
> argument of the function is of 'bool' type, however .s_power callback from
> struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as
> 'int'.
> 
> It's just a nitpicking, please feel free to ignore the comment above or
> please consider to change the arguments on callers' side to integers.
> 
> Also you may consider to add 'ov5647_' prefix to the function name to
> distinguish it from a potentially added in future sensor_power() function,
> the original name sounds too generic.
> 

OK. I'll add the prefix and change the variable type from int to bool.

>>>> +{
>>>> +	int ret;
>>>> +	struct ov5647 *ov5647 = to_state(sd);
>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>> +
>>>> +	ret = 0;
>>>> +	mutex_lock(&ov5647->lock);
>>>> +
>>>> +	if (on && !ov5647->power_count)	{
>>>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>>>> +
>>>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>>>
>>> Now clk_set_rate() is redundant, please remove it.
>>>
>>> If once it is needed again, please move it to the .probe function, so
>>> it is called only once in the runtime.
>>>
>>
>> Ok. I'll remove it for now.
>>
>>>> +
>>>> +		ret = clk_prepare_enable(ov5647->xclk);
>>>
>>> I wonder would it be possible to unload the driver or to unbind the device
>>> and leave the clock unintentionally enabled? If yes, then this is a bug.
>>>
>>
>> You're saying that if the driver was unloaded and the clock was left enabled
>> when the driver was loaded again this line would cause an error?
> 
> Not exactly, here I saw a potential resource leak, namely a potentially left
> prepared/enabled clock.
> 
>>
>> Should I disable the clock when the driver is removed?
>>
> 
> The driver (and framework) shall guarantee that when it is detached from
> device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device),
> all acquired resources are released.
> 
> But in this particular case most probably I've been overly alert, I believe
> that V4L2 framework correcly handles device power states, so please ignore my
> comment.
> 
> To add something valuable to the review, could you please confirm that
> ov5647_subdev_internal_ops data is in use by the driver?
> 
> E.g. shouldn't it be registered by
> 
>   sd->internal_ops = &ov5647_subdev_internal_ops;
> 
> before calling v4l2_async_register_subdev(sd) ?
> 

You're right, it's not being registered. I think I'll remove them since they
aren't being used.

> --
> With best wishes,
> Vladimir
> 

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Vladimir

On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote:
> Hi Sakari,
> 
> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
>> Hi, Vladimir!
>>
>> How do you do? :-)
> 
> deferring execution of boring tasks by doing code review :)
> 
>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>>> Hi Ramiro,
>>>
>>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>>> Hi Vladimir,
>>>>
>>>> Thank you for your feedback
>>>>
>>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>>> Hi Ramiro,
>>>>>
>>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>>> Create device tree bindings documentation.
>>>>>>
>>>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>> ---
>>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>>  1 file changed, 35 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>> new file mode 100644
>>>>>> index 000000000000..31956426d3b9
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>> @@ -0,0 +1,35 @@
>>>>>> +Omnivision OV5647 raw image sensor
>>>>>> +---------------------------------
>>>>>> +
>>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>>> +and CCI (I2C compatible) control bus.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> +- compatible		: "ovti,ov5647".
>>>>>> +- reg			: I2C slave address of the sensor.
>>>>>> +- clocks		: Reference to the xclk clock.
>>>>>
>>>>> Is "xclk" clock a pixel clock or something else?
>>>>>
>>>>
>>>> It's an external oscillator.
>>>
>>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>>> It can be an external oscillator on a particular board, or it can be
>>> something else on another board.
>>
>> Any clock source could be used I presume.
>>
> 
> That's exactly my point, and it is a reason to rename "xclk" to something
> more generic.
> 

xclk it's the name being used in the camera datasheet, but I can change it to
something more generic

>>>
>>> Can you please describe what for does ov5647 sensor need this clock, what
>>> is its function?
>>
>> Camera modules (sensors) quite commonly require an external clock as they do
>> not have an oscillator on their own. A lot of devices under
>> Documentation/devicetree/bindings/media/i2c/ have similar properties.
>>
> 
> So, what should be a better replacement of "xclk" in the description above?
> 
> E.g.
> 
> - clocks		: Phandle to a device supply clock.
> 
>>>
>>>>
>>>>>> +- clock-names		: Should be "xclk".
> 
> We got an agreement that "clock-names" property is removed, nevertheless
> if it is added back, is should not be "xclk".
> 
>>>>>
>>>>> You can remove this property, because there is only one source clock.
>>>>>
>>>>
>>>> Ok.
>>>>
>>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>>
>>>>> And after the last updates in the driver this property can be removed as well.
>>>>>
>>>>
>>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>>> the probing will fail.
>>>>
>>>
>>> I doubt it, there should be no connection between a custom "clock-frequency"
>>> device tree property in a clock consumer device node and clk_get_rate() function
>>> from the CCF, which takes a clock provider as its argument.
>>
>> The purpose is to make sure the clock frequency is really usable for the
>> device, in this particular case the driver can work with one particular
>> frequency.
>>
>> That said, the driver does not appear to use the property at the moment. It
>> should.
>>
>> It'd be good to verify that the rate matches: clk_set_rate() is not
>> guaranteed to produce the requested clock rate, and the driver could
>> conceivably be updated with support for more frequencies. There are
>> typically a few frequencies that a SoC such a sensor is connected can
>> support, and 25 MHz is not one of the common frequencies. With this
>> property, the frequency would be always there explicitly.
>>
> 
> I can provide my arguments given at v8 review time again, since I don't
> see a contradiction with my older comments.
> 
> Briefly "clock-frequency" as a device tree property on a consumer side
> can be considered as redundant, because there is a mechanism to specify
> a wanted clock frequency on a clock provider side right in a board DTB.
> 
> So, the clock frequency set up is delegated to CCF, and when any other
> than 25 MHz frequencies are got supported, that's only the matter of
> driver updates, DTBs won't be touched.
> 

In the driver, I'm using this piece of code to check that the frequency is 25Mhz

	xclk_freq = clk_get_rate(sensor->xclk);
	if (xclk_freq != 25000000) {
		dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq);
		return -EINVAL;
	}

So if I don't define it here the probing will fail. Do you have another
suggestion for this?

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Vladimir

On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote:
> Hi Sakari,
> 
> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
>> Hi, Vladimir!
>>
>> How do you do? :-)
> 
> deferring execution of boring tasks by doing code review :)
> 
>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>>> Hi Ramiro,
>>>
>>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>>> Hi Vladimir,
>>>>
>>>> Thank you for your feedback
>>>>
>>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>>> Hi Ramiro,
>>>>>
>>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>>> Create device tree bindings documentation.
>>>>>>
>>>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>> ---
>>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>>  1 file changed, 35 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>> new file mode 100644
>>>>>> index 000000000000..31956426d3b9
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>> @@ -0,0 +1,35 @@
>>>>>> +Omnivision OV5647 raw image sensor
>>>>>> +---------------------------------
>>>>>> +
>>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>>> +and CCI (I2C compatible) control bus.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> +- compatible		: "ovti,ov5647".
>>>>>> +- reg			: I2C slave address of the sensor.
>>>>>> +- clocks		: Reference to the xclk clock.
>>>>>
>>>>> Is "xclk" clock a pixel clock or something else?
>>>>>
>>>>
>>>> It's an external oscillator.
>>>
>>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>>> It can be an external oscillator on a particular board, or it can be
>>> something else on another board.
>>
>> Any clock source could be used I presume.
>>
> 
> That's exactly my point, and it is a reason to rename "xclk" to something
> more generic.
> 

xclk it's the name being used in the camera datasheet, but I can change it to
something more generic

>>>
>>> Can you please describe what for does ov5647 sensor need this clock, what
>>> is its function?
>>
>> Camera modules (sensors) quite commonly require an external clock as they do
>> not have an oscillator on their own. A lot of devices under
>> Documentation/devicetree/bindings/media/i2c/ have similar properties.
>>
> 
> So, what should be a better replacement of "xclk" in the description above?
> 
> E.g.
> 
> - clocks		: Phandle to a device supply clock.
> 
>>>
>>>>
>>>>>> +- clock-names		: Should be "xclk".
> 
> We got an agreement that "clock-names" property is removed, nevertheless
> if it is added back, is should not be "xclk".
> 
>>>>>
>>>>> You can remove this property, because there is only one source clock.
>>>>>
>>>>
>>>> Ok.
>>>>
>>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>>
>>>>> And after the last updates in the driver this property can be removed as well.
>>>>>
>>>>
>>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>>> the probing will fail.
>>>>
>>>
>>> I doubt it, there should be no connection between a custom "clock-frequency"
>>> device tree property in a clock consumer device node and clk_get_rate() function
>>> from the CCF, which takes a clock provider as its argument.
>>
>> The purpose is to make sure the clock frequency is really usable for the
>> device, in this particular case the driver can work with one particular
>> frequency.
>>
>> That said, the driver does not appear to use the property at the moment. It
>> should.
>>
>> It'd be good to verify that the rate matches: clk_set_rate() is not
>> guaranteed to produce the requested clock rate, and the driver could
>> conceivably be updated with support for more frequencies. There are
>> typically a few frequencies that a SoC such a sensor is connected can
>> support, and 25 MHz is not one of the common frequencies. With this
>> property, the frequency would be always there explicitly.
>>
> 
> I can provide my arguments given at v8 review time again, since I don't
> see a contradiction with my older comments.
> 
> Briefly "clock-frequency" as a device tree property on a consumer side
> can be considered as redundant, because there is a mechanism to specify
> a wanted clock frequency on a clock provider side right in a board DTB.
> 
> So, the clock frequency set up is delegated to CCF, and when any other
> than 25 MHz frequencies are got supported, that's only the matter of
> driver updates, DTBs won't be touched.
> 

In the driver, I'm using this piece of code to check that the frequency is 25Mhz

	xclk_freq = clk_get_rate(sensor->xclk);
	if (xclk_freq != 25000000) {
		dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq);
		return -EINVAL;
	}

So if I don't define it here the probing will fail. Do you have another
suggestion for this?

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/22/2017 12:57 PM, Ramiro Oliveira wrote:
> Hi Vladimir
> 
> On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote:
>> Hi Sakari,
>>
>> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
>>> Hi, Vladimir!
>>>
>>> How do you do? :-)
>>
>> deferring execution of boring tasks by doing code review :)
>>
>>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>>>> Hi Ramiro,
>>>>
>>>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>>>> Hi Vladimir,
>>>>>
>>>>> Thank you for your feedback
>>>>>
>>>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>>>> Hi Ramiro,
>>>>>>
>>>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>>>> Create device tree bindings documentation.
>>>>>>>
>>>>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>> ---
>>>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>>>  1 file changed, 35 insertions(+)
>>>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..31956426d3b9
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>> @@ -0,0 +1,35 @@
>>>>>>> +Omnivision OV5647 raw image sensor
>>>>>>> +---------------------------------
>>>>>>> +
>>>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>>>> +and CCI (I2C compatible) control bus.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +
>>>>>>> +- compatible		: "ovti,ov5647".
>>>>>>> +- reg			: I2C slave address of the sensor.
>>>>>>> +- clocks		: Reference to the xclk clock.
>>>>>>
>>>>>> Is "xclk" clock a pixel clock or something else?
>>>>>>
>>>>>
>>>>> It's an external oscillator.
>>>>
>>>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>>>> It can be an external oscillator on a particular board, or it can be
>>>> something else on another board.
>>>
>>> Any clock source could be used I presume.
>>>
>>
>> That's exactly my point, and it is a reason to rename "xclk" to something
>> more generic.
>>
> 
> xclk it's the name being used in the camera datasheet, but I can change it to
> something more generic
> 

Ah, if the name comes from the sensor datasheet, then it should be okay
to keep it.

>>>>
>>>> Can you please describe what for does ov5647 sensor need this clock, what
>>>> is its function?
>>>
>>> Camera modules (sensors) quite commonly require an external clock as they do
>>> not have an oscillator on their own. A lot of devices under
>>> Documentation/devicetree/bindings/media/i2c/ have similar properties.
>>>
>>
>> So, what should be a better replacement of "xclk" in the description above?
>>
>> E.g.
>>
>> - clocks		: Phandle to a device supply clock.
>>
>>>>
>>>>>
>>>>>>> +- clock-names		: Should be "xclk".
>>
>> We got an agreement that "clock-names" property is removed, nevertheless
>> if it is added back, is should not be "xclk".
>>
>>>>>>
>>>>>> You can remove this property, because there is only one source clock.
>>>>>>
>>>>>
>>>>> Ok.
>>>>>
>>>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>>>
>>>>>> And after the last updates in the driver this property can be removed as well.
>>>>>>
>>>>>
>>>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>>>> the probing will fail.
>>>>>
>>>>
>>>> I doubt it, there should be no connection between a custom "clock-frequency"
>>>> device tree property in a clock consumer device node and clk_get_rate() function
>>>> from the CCF, which takes a clock provider as its argument.
>>>
>>> The purpose is to make sure the clock frequency is really usable for the
>>> device, in this particular case the driver can work with one particular
>>> frequency.
>>>
>>> That said, the driver does not appear to use the property at the moment. It
>>> should.
>>>
>>> It'd be good to verify that the rate matches: clk_set_rate() is not
>>> guaranteed to produce the requested clock rate, and the driver could
>>> conceivably be updated with support for more frequencies. There are
>>> typically a few frequencies that a SoC such a sensor is connected can
>>> support, and 25 MHz is not one of the common frequencies. With this
>>> property, the frequency would be always there explicitly.
>>>
>>
>> I can provide my arguments given at v8 review time again, since I don't
>> see a contradiction with my older comments.
>>
>> Briefly "clock-frequency" as a device tree property on a consumer side
>> can be considered as redundant, because there is a mechanism to specify
>> a wanted clock frequency on a clock provider side right in a board DTB.
>>
>> So, the clock frequency set up is delegated to CCF, and when any other
>> than 25 MHz frequencies are got supported, that's only the matter of
>> driver updates, DTBs won't be touched.
>>
> 
> In the driver, I'm using this piece of code to check that the frequency is 25Mhz
> 
> 	xclk_freq = clk_get_rate(sensor->xclk);
> 	if (xclk_freq != 25000000) {
> 		dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq);
> 		return -EINVAL;
> 	}
> 
> So if I don't define it here the probing will fail. Do you have another
> suggestion for this?
> 

I don't completely understand, why does it fail? "clock-frequency" property
is not a standard device node property on a clock consumer side, so, if we're
still talking about v9 version of the driver, adding the property or removing
it should have no effect.

Let's consider the simplest possible situation, when "xclk" is actually
a fixed rate 25MHz oscillator (the clock device node is "fixed-clock"
compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert
has to be passed. In case of a more complex scenario please reference to
clock-bindings.txt documentation, in particular please take a look at
"assigned-clocks" and "assigned-clock-rates" properties.

--
With best wishes,
Vladimir

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Vladimir Zapolskiy]

Hi Ramiro,

On 02/22/2017 12:57 PM, Ramiro Oliveira wrote:
> Hi Vladimir
> 
> On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote:
>> Hi Sakari,
>>
>> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
>>> Hi, Vladimir!
>>>
>>> How do you do? :-)
>>
>> deferring execution of boring tasks by doing code review :)
>>
>>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>>>> Hi Ramiro,
>>>>
>>>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>>>> Hi Vladimir,
>>>>>
>>>>> Thank you for your feedback
>>>>>
>>>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>>>> Hi Ramiro,
>>>>>>
>>>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>>>> Create device tree bindings documentation.
>>>>>>>
>>>>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>> ---
>>>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>>>  1 file changed, 35 insertions(+)
>>>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..31956426d3b9
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>> @@ -0,0 +1,35 @@
>>>>>>> +Omnivision OV5647 raw image sensor
>>>>>>> +---------------------------------
>>>>>>> +
>>>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>>>> +and CCI (I2C compatible) control bus.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +
>>>>>>> +- compatible		: "ovti,ov5647".
>>>>>>> +- reg			: I2C slave address of the sensor.
>>>>>>> +- clocks		: Reference to the xclk clock.
>>>>>>
>>>>>> Is "xclk" clock a pixel clock or something else?
>>>>>>
>>>>>
>>>>> It's an external oscillator.
>>>>
>>>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>>>> It can be an external oscillator on a particular board, or it can be
>>>> something else on another board.
>>>
>>> Any clock source could be used I presume.
>>>
>>
>> That's exactly my point, and it is a reason to rename "xclk" to something
>> more generic.
>>
> 
> xclk it's the name being used in the camera datasheet, but I can change it to
> something more generic
> 

Ah, if the name comes from the sensor datasheet, then it should be okay
to keep it.

>>>>
>>>> Can you please describe what for does ov5647 sensor need this clock, what
>>>> is its function?
>>>
>>> Camera modules (sensors) quite commonly require an external clock as they do
>>> not have an oscillator on their own. A lot of devices under
>>> Documentation/devicetree/bindings/media/i2c/ have similar properties.
>>>
>>
>> So, what should be a better replacement of "xclk" in the description above?
>>
>> E.g.
>>
>> - clocks		: Phandle to a device supply clock.
>>
>>>>
>>>>>
>>>>>>> +- clock-names		: Should be "xclk".
>>
>> We got an agreement that "clock-names" property is removed, nevertheless
>> if it is added back, is should not be "xclk".
>>
>>>>>>
>>>>>> You can remove this property, because there is only one source clock.
>>>>>>
>>>>>
>>>>> Ok.
>>>>>
>>>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>>>
>>>>>> And after the last updates in the driver this property can be removed as well.
>>>>>>
>>>>>
>>>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>>>> the probing will fail.
>>>>>
>>>>
>>>> I doubt it, there should be no connection between a custom "clock-frequency"
>>>> device tree property in a clock consumer device node and clk_get_rate() function
>>>> from the CCF, which takes a clock provider as its argument.
>>>
>>> The purpose is to make sure the clock frequency is really usable for the
>>> device, in this particular case the driver can work with one particular
>>> frequency.
>>>
>>> That said, the driver does not appear to use the property at the moment. It
>>> should.
>>>
>>> It'd be good to verify that the rate matches: clk_set_rate() is not
>>> guaranteed to produce the requested clock rate, and the driver could
>>> conceivably be updated with support for more frequencies. There are
>>> typically a few frequencies that a SoC such a sensor is connected can
>>> support, and 25 MHz is not one of the common frequencies. With this
>>> property, the frequency would be always there explicitly.
>>>
>>
>> I can provide my arguments given at v8 review time again, since I don't
>> see a contradiction with my older comments.
>>
>> Briefly "clock-frequency" as a device tree property on a consumer side
>> can be considered as redundant, because there is a mechanism to specify
>> a wanted clock frequency on a clock provider side right in a board DTB.
>>
>> So, the clock frequency set up is delegated to CCF, and when any other
>> than 25 MHz frequencies are got supported, that's only the matter of
>> driver updates, DTBs won't be touched.
>>
> 
> In the driver, I'm using this piece of code to check that the frequency is 25Mhz
> 
> 	xclk_freq = clk_get_rate(sensor->xclk);
> 	if (xclk_freq != 25000000) {
> 		dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq);
> 		return -EINVAL;
> 	}
> 
> So if I don't define it here the probing will fail. Do you have another
> suggestion for this?
> 

I don't completely understand, why does it fail? "clock-frequency" property
is not a standard device node property on a clock consumer side, so, if we're
still talking about v9 version of the driver, adding the property or removing
it should have no effect.

Let's consider the simplest possible situation, when "xclk" is actually
a fixed rate 25MHz oscillator (the clock device node is "fixed-clock"
compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert
has to be passed. In case of a more complex scenario please reference to
clock-bindings.txt documentation, in particular please take a look at
"assigned-clocks" and "assigned-clock-rates" properties.

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

On 02/22/2017 12:51 PM, Ramiro Oliveira wrote:
> Hi Zakari,
> 
> On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/21/2017 06:42 PM, Ramiro Oliveira wrote:
>>> Hi Vladimir,
>>>
>>> Thank you for your feedback
>>>
>>> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
>>>> Hi Ramiro,
>>>>
>>>> please find some review comments below.
>>>>
>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>>>>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>>>>
>>>>> The driver adds support for 640x480 RAW 8.
>>>>>
>>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>>>> ---
>>>>
>>>> [snip]
>>>>
>>>>> +
>>>>> +struct ov5647 {
>>>>> +	struct v4l2_subdev		sd;
>>>>> +	struct media_pad		pad;
>>>>> +	struct mutex			lock;
>>>>> +	struct v4l2_mbus_framefmt	format;
>>>>> +	unsigned int			width;
>>>>> +	unsigned int			height;
>>>>> +	int				power_count;
>>>>> +	struct clk			*xclk;
>>>>> +	/* External clock frequency currently supported is 30MHz */
>>>>> +	u32				xclk_freq;
>>>>
>>>> See a comment about 25MHz vs 30MHz below.
>>>>
>>>> Also I assume you can remove 'xclk_freq' from the struct fields,
>>>> it can be replaced by a local variable.
>>>>
>>>
>>> I'll do that.
>>>
>>>>> +};
>>>>
>>>> [snip]
>>>>
>>>>> +
>>>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>>>>> +{
>>>>> +	int ret;
>>>>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>>> +
>>>>> +	ret = i2c_master_send(client, data_w, 2);
>>>>> +	if (ret < 0) {
>>>>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>>>>
>>>> s/i2c read error/i2c write error/
>>>>
>>>
>>> I'm not sure I understand what you mean.
>>
>> That's a sed expression for string substitution. Here you do i2c_master_send()
>> but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix.
>>
> 
> Ohh... now I see. I'll change it.
> 
>>>>> +			__func__, reg);
>>>>> +		return ret;
>>>>> +	}
>>>>> +
>>
>> [snip]
>>
>>>>> +
>>>>> +static int sensor_power(struct v4l2_subdev *sd, int on)
>>
>> On the caller's side (functions ov5647_open() and ov5647_close()) the second
>> argument of the function is of 'bool' type, however .s_power callback from
>> struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as
>> 'int'.
>>
>> It's just a nitpicking, please feel free to ignore the comment above or
>> please consider to change the arguments on callers' side to integers.
>>
>> Also you may consider to add 'ov5647_' prefix to the function name to
>> distinguish it from a potentially added in future sensor_power() function,
>> the original name sounds too generic.
>>
> 
> OK. I'll add the prefix and change the variable type from int to bool.
> 

Just to eliminate any potential misunderstanding, if you consider to reuse
the current sensor_power() function, please change variables from bool to int
on a caller's side, the signature of the function shall not be changed to
match .s_power type.

>>>>> +{
>>>>> +	int ret;
>>>>> +	struct ov5647 *ov5647 = to_state(sd);
>>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>>> +
>>>>> +	ret = 0;
>>>>> +	mutex_lock(&ov5647->lock);
>>>>> +
>>>>> +	if (on && !ov5647->power_count)	{
>>>>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>>>>> +
>>>>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>>>>
>>>> Now clk_set_rate() is redundant, please remove it.
>>>>
>>>> If once it is needed again, please move it to the .probe function, so
>>>> it is called only once in the runtime.
>>>>
>>>
>>> Ok. I'll remove it for now.
>>>
>>>>> +
>>>>> +		ret = clk_prepare_enable(ov5647->xclk);
>>>>
>>>> I wonder would it be possible to unload the driver or to unbind the device
>>>> and leave the clock unintentionally enabled? If yes, then this is a bug.
>>>>
>>>
>>> You're saying that if the driver was unloaded and the clock was left enabled
>>> when the driver was loaded again this line would cause an error?
>>
>> Not exactly, here I saw a potential resource leak, namely a potentially left
>> prepared/enabled clock.
>>
>>>
>>> Should I disable the clock when the driver is removed?
>>>
>>
>> The driver (and framework) shall guarantee that when it is detached from
>> device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device),
>> all acquired resources are released.
>>
>> But in this particular case most probably I've been overly alert, I believe
>> that V4L2 framework correcly handles device power states, so please ignore my
>> comment.
>>
>> To add something valuable to the review, could you please confirm that
>> ov5647_subdev_internal_ops data is in use by the driver?
>>
>> E.g. shouldn't it be registered by
>>
>>   sd->internal_ops = &ov5647_subdev_internal_ops;
>>
>> before calling v4l2_async_register_subdev(sd) ?
>>
> 
> You're right, it's not being registered. I think I'll remove them since they
> aren't being used.
> 

--
With best wishes,
Vladimir

Re: [PATCH v9 2/2] Add support for OV5647 sensor.

[Vladimir Zapolskiy]

On 02/22/2017 12:51 PM, Ramiro Oliveira wrote:
> Hi Zakari,
> 
> On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/21/2017 06:42 PM, Ramiro Oliveira wrote:
>>> Hi Vladimir,
>>>
>>> Thank you for your feedback
>>>
>>> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote:
>>>> Hi Ramiro,
>>>>
>>>> please find some review comments below.
>>>>
>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8
>>>>> and RAW 10 output formats, and MIPI CSI-2 interface.
>>>>>
>>>>> The driver adds support for 640x480 RAW 8.
>>>>>
>>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>
>>>> [snip]
>>>>
>>>>> +
>>>>> +struct ov5647 {
>>>>> +	struct v4l2_subdev		sd;
>>>>> +	struct media_pad		pad;
>>>>> +	struct mutex			lock;
>>>>> +	struct v4l2_mbus_framefmt	format;
>>>>> +	unsigned int			width;
>>>>> +	unsigned int			height;
>>>>> +	int				power_count;
>>>>> +	struct clk			*xclk;
>>>>> +	/* External clock frequency currently supported is 30MHz */
>>>>> +	u32				xclk_freq;
>>>>
>>>> See a comment about 25MHz vs 30MHz below.
>>>>
>>>> Also I assume you can remove 'xclk_freq' from the struct fields,
>>>> it can be replaced by a local variable.
>>>>
>>>
>>> I'll do that.
>>>
>>>>> +};
>>>>
>>>> [snip]
>>>>
>>>>> +
>>>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val)
>>>>> +{
>>>>> +	int ret;
>>>>> +	unsigned char data_w[2] = { reg >> 8, reg & 0xff };
>>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>>> +
>>>>> +	ret = i2c_master_send(client, data_w, 2);
>>>>> +	if (ret < 0) {
>>>>> +		dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n",
>>>>
>>>> s/i2c read error/i2c write error/
>>>>
>>>
>>> I'm not sure I understand what you mean.
>>
>> That's a sed expression for string substitution. Here you do i2c_master_send()
>> but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix.
>>
> 
> Ohh... now I see. I'll change it.
> 
>>>>> +			__func__, reg);
>>>>> +		return ret;
>>>>> +	}
>>>>> +
>>
>> [snip]
>>
>>>>> +
>>>>> +static int sensor_power(struct v4l2_subdev *sd, int on)
>>
>> On the caller's side (functions ov5647_open() and ov5647_close()) the second
>> argument of the function is of 'bool' type, however .s_power callback from
>> struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as
>> 'int'.
>>
>> It's just a nitpicking, please feel free to ignore the comment above or
>> please consider to change the arguments on callers' side to integers.
>>
>> Also you may consider to add 'ov5647_' prefix to the function name to
>> distinguish it from a potentially added in future sensor_power() function,
>> the original name sounds too generic.
>>
> 
> OK. I'll add the prefix and change the variable type from int to bool.
> 

Just to eliminate any potential misunderstanding, if you consider to reuse
the current sensor_power() function, please change variables from bool to int
on a caller's side, the signature of the function shall not be changed to
match .s_power type.

>>>>> +{
>>>>> +	int ret;
>>>>> +	struct ov5647 *ov5647 = to_state(sd);
>>>>> +	struct i2c_client *client = v4l2_get_subdevdata(sd);
>>>>> +
>>>>> +	ret = 0;
>>>>> +	mutex_lock(&ov5647->lock);
>>>>> +
>>>>> +	if (on && !ov5647->power_count)	{
>>>>> +		dev_dbg(&client->dev, "OV5647 power on\n");
>>>>> +
>>>>> +		clk_set_rate(ov5647->xclk, ov5647->xclk_freq);
>>>>
>>>> Now clk_set_rate() is redundant, please remove it.
>>>>
>>>> If once it is needed again, please move it to the .probe function, so
>>>> it is called only once in the runtime.
>>>>
>>>
>>> Ok. I'll remove it for now.
>>>
>>>>> +
>>>>> +		ret = clk_prepare_enable(ov5647->xclk);
>>>>
>>>> I wonder would it be possible to unload the driver or to unbind the device
>>>> and leave the clock unintentionally enabled? If yes, then this is a bug.
>>>>
>>>
>>> You're saying that if the driver was unloaded and the clock was left enabled
>>> when the driver was loaded again this line would cause an error?
>>
>> Not exactly, here I saw a potential resource leak, namely a potentially left
>> prepared/enabled clock.
>>
>>>
>>> Should I disable the clock when the driver is removed?
>>>
>>
>> The driver (and framework) shall guarantee that when it is detached from
>> device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device),
>> all acquired resources are released.
>>
>> But in this particular case most probably I've been overly alert, I believe
>> that V4L2 framework correcly handles device power states, so please ignore my
>> comment.
>>
>> To add something valuable to the review, could you please confirm that
>> ov5647_subdev_internal_ops data is in use by the driver?
>>
>> E.g. shouldn't it be registered by
>>
>>   sd->internal_ops = &ov5647_subdev_internal_ops;
>>
>> before calling v4l2_async_register_subdev(sd) ?
>>
> 
> You're right, it's not being registered. I think I'll remove them since they
> aren't being used.
> 

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Vladimir

On 2/22/2017 11:39 AM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/22/2017 12:57 PM, Ramiro Oliveira wrote:
>> Hi Vladimir
>>
>> On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote:
>>> Hi Sakari,
>>>
>>> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
>>>> Hi, Vladimir!
>>>>
>>>> How do you do? :-)
>>>
>>> deferring execution of boring tasks by doing code review :)
>>>
>>>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>>>>> Hi Ramiro,
>>>>>
>>>>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>>>> Thank you for your feedback
>>>>>>
>>>>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>>>>> Hi Ramiro,
>>>>>>>
>>>>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>>>>> Create device tree bindings documentation.
>>>>>>>>
>>>>>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>> ---
>>>>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>>>>  1 file changed, 35 insertions(+)
>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..31956426d3b9
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>> @@ -0,0 +1,35 @@
>>>>>>>> +Omnivision OV5647 raw image sensor
>>>>>>>> +---------------------------------
>>>>>>>> +
>>>>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>>>>> +and CCI (I2C compatible) control bus.
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +
>>>>>>>> +- compatible		: "ovti,ov5647".
>>>>>>>> +- reg			: I2C slave address of the sensor.
>>>>>>>> +- clocks		: Reference to the xclk clock.
>>>>>>>
>>>>>>> Is "xclk" clock a pixel clock or something else?
>>>>>>>
>>>>>>
>>>>>> It's an external oscillator.
>>>>>
>>>>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>>>>> It can be an external oscillator on a particular board, or it can be
>>>>> something else on another board.
>>>>
>>>> Any clock source could be used I presume.
>>>>
>>>
>>> That's exactly my point, and it is a reason to rename "xclk" to something
>>> more generic.
>>>
>>
>> xclk it's the name being used in the camera datasheet, but I can change it to
>> something more generic
>>
> 
> Ah, if the name comes from the sensor datasheet, then it should be okay
> to keep it.
> 
>>>>>
>>>>> Can you please describe what for does ov5647 sensor need this clock, what
>>>>> is its function?
>>>>
>>>> Camera modules (sensors) quite commonly require an external clock as they do
>>>> not have an oscillator on their own. A lot of devices under
>>>> Documentation/devicetree/bindings/media/i2c/ have similar properties.
>>>>
>>>
>>> So, what should be a better replacement of "xclk" in the description above?
>>>
>>> E.g.
>>>
>>> - clocks		: Phandle to a device supply clock.
>>>
>>>>>
>>>>>>
>>>>>>>> +- clock-names		: Should be "xclk".
>>>
>>> We got an agreement that "clock-names" property is removed, nevertheless
>>> if it is added back, is should not be "xclk".
>>>
>>>>>>>
>>>>>>> You can remove this property, because there is only one source clock.
>>>>>>>
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>>>>
>>>>>>> And after the last updates in the driver this property can be removed as well.
>>>>>>>
>>>>>>
>>>>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>>>>> the probing will fail.
>>>>>>
>>>>>
>>>>> I doubt it, there should be no connection between a custom "clock-frequency"
>>>>> device tree property in a clock consumer device node and clk_get_rate() function
>>>>> from the CCF, which takes a clock provider as its argument.
>>>>
>>>> The purpose is to make sure the clock frequency is really usable for the
>>>> device, in this particular case the driver can work with one particular
>>>> frequency.
>>>>
>>>> That said, the driver does not appear to use the property at the moment. It
>>>> should.
>>>>
>>>> It'd be good to verify that the rate matches: clk_set_rate() is not
>>>> guaranteed to produce the requested clock rate, and the driver could
>>>> conceivably be updated with support for more frequencies. There are
>>>> typically a few frequencies that a SoC such a sensor is connected can
>>>> support, and 25 MHz is not one of the common frequencies. With this
>>>> property, the frequency would be always there explicitly.
>>>>
>>>
>>> I can provide my arguments given at v8 review time again, since I don't
>>> see a contradiction with my older comments.
>>>
>>> Briefly "clock-frequency" as a device tree property on a consumer side
>>> can be considered as redundant, because there is a mechanism to specify
>>> a wanted clock frequency on a clock provider side right in a board DTB.
>>>
>>> So, the clock frequency set up is delegated to CCF, and when any other
>>> than 25 MHz frequencies are got supported, that's only the matter of
>>> driver updates, DTBs won't be touched.
>>>
>>
>> In the driver, I'm using this piece of code to check that the frequency is 25Mhz
>>
>> 	xclk_freq = clk_get_rate(sensor->xclk);
>> 	if (xclk_freq != 25000000) {
>> 		dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq);
>> 		return -EINVAL;
>> 	}
>>
>> So if I don't define it here the probing will fail. Do you have another
>> suggestion for this?
>>
> 
> I don't completely understand, why does it fail? "clock-frequency" property
> is not a standard device node property on a clock consumer side, so, if we're
> still talking about v9 version of the driver, adding the property or removing
> it should have no effect.
> 
> Let's consider the simplest possible situation, when "xclk" is actually
> a fixed rate 25MHz oscillator (the clock device node is "fixed-clock"
> compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert
> has to be passed. In case of a more complex scenario please reference to
> clock-bindings.txt documentation, in particular please take a look at
> "assigned-clocks" and "assigned-clock-rates" properties.
> 

You're right, I was forgetting about the frequency being defined in the fixed
clock declaration. I'll remove clock-frequency from the example.

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira@synopsys.com

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Vladimir

On 2/22/2017 11:39 AM, Vladimir Zapolskiy wrote:
> Hi Ramiro,
> 
> On 02/22/2017 12:57 PM, Ramiro Oliveira wrote:
>> Hi Vladimir
>>
>> On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote:
>>> Hi Sakari,
>>>
>>> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
>>>> Hi, Vladimir!
>>>>
>>>> How do you do? :-)
>>>
>>> deferring execution of boring tasks by doing code review :)
>>>
>>>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
>>>>> Hi Ramiro,
>>>>>
>>>>> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>>>> Thank you for your feedback
>>>>>>
>>>>>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>>>>>>> Hi Ramiro,
>>>>>>>
>>>>>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>>>>>>> Create device tree bindings documentation.
>>>>>>>>
>>>>>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>>> ---
>>>>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>>>>>>  1 file changed, 35 insertions(+)
>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..31956426d3b9
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>>> @@ -0,0 +1,35 @@
>>>>>>>> +Omnivision OV5647 raw image sensor
>>>>>>>> +---------------------------------
>>>>>>>> +
>>>>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>>>>> +and CCI (I2C compatible) control bus.
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +
>>>>>>>> +- compatible		: "ovti,ov5647".
>>>>>>>> +- reg			: I2C slave address of the sensor.
>>>>>>>> +- clocks		: Reference to the xclk clock.
>>>>>>>
>>>>>>> Is "xclk" clock a pixel clock or something else?
>>>>>>>
>>>>>>
>>>>>> It's an external oscillator.
>>>>>
>>>>> hmm, I suppose a clock of any type could serve as a clock for the sensor.
>>>>> It can be an external oscillator on a particular board, or it can be
>>>>> something else on another board.
>>>>
>>>> Any clock source could be used I presume.
>>>>
>>>
>>> That's exactly my point, and it is a reason to rename "xclk" to something
>>> more generic.
>>>
>>
>> xclk it's the name being used in the camera datasheet, but I can change it to
>> something more generic
>>
> 
> Ah, if the name comes from the sensor datasheet, then it should be okay
> to keep it.
> 
>>>>>
>>>>> Can you please describe what for does ov5647 sensor need this clock, what
>>>>> is its function?
>>>>
>>>> Camera modules (sensors) quite commonly require an external clock as they do
>>>> not have an oscillator on their own. A lot of devices under
>>>> Documentation/devicetree/bindings/media/i2c/ have similar properties.
>>>>
>>>
>>> So, what should be a better replacement of "xclk" in the description above?
>>>
>>> E.g.
>>>
>>> - clocks		: Phandle to a device supply clock.
>>>
>>>>>
>>>>>>
>>>>>>>> +- clock-names		: Should be "xclk".
>>>
>>> We got an agreement that "clock-names" property is removed, nevertheless
>>> if it is added back, is should not be "xclk".
>>>
>>>>>>>
>>>>>>> You can remove this property, because there is only one source clock.
>>>>>>>
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>>>> +- clock-frequency	: Frequency of the xclk clock.
>>>>>>>
>>>>>>> And after the last updates in the driver this property can be removed as well.
>>>>>>>
>>>>>>
>>>>>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
>>>>>> the probing will fail.
>>>>>>
>>>>>
>>>>> I doubt it, there should be no connection between a custom "clock-frequency"
>>>>> device tree property in a clock consumer device node and clk_get_rate() function
>>>>> from the CCF, which takes a clock provider as its argument.
>>>>
>>>> The purpose is to make sure the clock frequency is really usable for the
>>>> device, in this particular case the driver can work with one particular
>>>> frequency.
>>>>
>>>> That said, the driver does not appear to use the property at the moment. It
>>>> should.
>>>>
>>>> It'd be good to verify that the rate matches: clk_set_rate() is not
>>>> guaranteed to produce the requested clock rate, and the driver could
>>>> conceivably be updated with support for more frequencies. There are
>>>> typically a few frequencies that a SoC such a sensor is connected can
>>>> support, and 25 MHz is not one of the common frequencies. With this
>>>> property, the frequency would be always there explicitly.
>>>>
>>>
>>> I can provide my arguments given at v8 review time again, since I don't
>>> see a contradiction with my older comments.
>>>
>>> Briefly "clock-frequency" as a device tree property on a consumer side
>>> can be considered as redundant, because there is a mechanism to specify
>>> a wanted clock frequency on a clock provider side right in a board DTB.
>>>
>>> So, the clock frequency set up is delegated to CCF, and when any other
>>> than 25 MHz frequencies are got supported, that's only the matter of
>>> driver updates, DTBs won't be touched.
>>>
>>
>> In the driver, I'm using this piece of code to check that the frequency is 25Mhz
>>
>> 	xclk_freq = clk_get_rate(sensor->xclk);
>> 	if (xclk_freq != 25000000) {
>> 		dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq);
>> 		return -EINVAL;
>> 	}
>>
>> So if I don't define it here the probing will fail. Do you have another
>> suggestion for this?
>>
> 
> I don't completely understand, why does it fail? "clock-frequency" property
> is not a standard device node property on a clock consumer side, so, if we're
> still talking about v9 version of the driver, adding the property or removing
> it should have no effect.
> 
> Let's consider the simplest possible situation, when "xclk" is actually
> a fixed rate 25MHz oscillator (the clock device node is "fixed-clock"
> compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert
> has to be passed. In case of a more complex scenario please reference to
> clock-bindings.txt documentation, in particular please take a look at
> "assigned-clocks" and "assigned-clock-rates" properties.
> 

You're right, I was forgetting about the frequency being defined in the fixed
clock declaration. I'll remove clock-frequency from the example.

-- 
Best Regards

Ramiro Oliveira
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Vladimir,

On Wed, Feb 22, 2017 at 12:37:51AM +0200, Vladimir Zapolskiy wrote:
> Hi Sakari,
> 
> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
> > Hi, Vladimir!
> > 
> > How do you do? :-)
> 
> deferring execution of boring tasks by doing code review :)

X-)

> 
> > On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
> >> Hi Ramiro,
> >>
> >> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> >>> Hi Vladimir,
> >>>
> >>> Thank you for your feedback
> >>>
> >>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> >>>> Hi Ramiro,
> >>>>
> >>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> >>>>> Create device tree bindings documentation.
> >>>>>
> >>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> >>>>> Acked-by: Rob Herring <robh@kernel.org>
> >>>>> ---
> >>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
> >>>>>  1 file changed, 35 insertions(+)
> >>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>> new file mode 100644
> >>>>> index 000000000000..31956426d3b9
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>> @@ -0,0 +1,35 @@
> >>>>> +Omnivision OV5647 raw image sensor
> >>>>> +---------------------------------
> >>>>> +
> >>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >>>>> +and CCI (I2C compatible) control bus.
> >>>>> +
> >>>>> +Required properties:
> >>>>> +
> >>>>> +- compatible		: "ovti,ov5647".
> >>>>> +- reg			: I2C slave address of the sensor.
> >>>>> +- clocks		: Reference to the xclk clock.
> >>>>
> >>>> Is "xclk" clock a pixel clock or something else?
> >>>>
> >>>
> >>> It's an external oscillator.
> >>
> >> hmm, I suppose a clock of any type could serve as a clock for the sensor.
> >> It can be an external oscillator on a particular board, or it can be
> >> something else on another board.
> > 
> > Any clock source could be used I presume.
> > 
> 
> That's exactly my point, and it is a reason to rename "xclk" to something
> more generic.

That's a sensor specific name, the one in the hardware datasheet should be
used if there's one, shouldn't it?

An alternative is not to use a name, as there's just a single clock.

> 
> >>
> >> Can you please describe what for does ov5647 sensor need this clock, what
> >> is its function?
> > 
> > Camera modules (sensors) quite commonly require an external clock as they do
> > not have an oscillator on their own. A lot of devices under
> > Documentation/devicetree/bindings/media/i2c/ have similar properties.
> > 
> 
> So, what should be a better replacement of "xclk" in the description above?
> 
> E.g.
> 
> - clocks		: Phandle to a device supply clock.
> 
> >>
> >>>
> >>>>> +- clock-names		: Should be "xclk".
> 
> We got an agreement that "clock-names" property is removed, nevertheless
> if it is added back, is should not be "xclk".
> 
> >>>>
> >>>> You can remove this property, because there is only one source clock.
> >>>>
> >>>
> >>> Ok.
> >>>
> >>>>> +- clock-frequency	: Frequency of the xclk clock.
> >>>>
> >>>> And after the last updates in the driver this property can be removed as well.
> >>>>
> >>>
> >>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
> >>> the probing will fail.
> >>>
> >>
> >> I doubt it, there should be no connection between a custom "clock-frequency"
> >> device tree property in a clock consumer device node and clk_get_rate() function
> >> from the CCF, which takes a clock provider as its argument.
> > 
> > The purpose is to make sure the clock frequency is really usable for the
> > device, in this particular case the driver can work with one particular
> > frequency.
> > 
> > That said, the driver does not appear to use the property at the moment. It
> > should.
> > 
> > It'd be good to verify that the rate matches: clk_set_rate() is not
> > guaranteed to produce the requested clock rate, and the driver could
> > conceivably be updated with support for more frequencies. There are
> > typically a few frequencies that a SoC such a sensor is connected can
> > support, and 25 MHz is not one of the common frequencies. With this
> > property, the frequency would be always there explicitly.
> > 
> 
> I can provide my arguments given at v8 review time again, since I don't
> see a contradiction with my older comments.
> 
> Briefly "clock-frequency" as a device tree property on a consumer side
> can be considered as redundant, because there is a mechanism to specify
> a wanted clock frequency on a clock provider side right in a board DTB.

You can, but there's no guarantee that the frequency what you get is going
to be what you asked for.

Although, the driver could try to work on the actual obtained frequency.
This is unlikely to work though, but it won't be very easy to figure out
why the device isn't working. Having the frequency in DT accessible for the
driver to check makes failing early with a clear error message possible.

> 
> So, the clock frequency set up is delegated to CCF, and when any other
> than 25 MHz frequencies are got supported, that's only the matter of
> driver updates, DTBs won't be touched.

Indeed. The new supported frequencies in this case will be additional
single values; there won't be ranges or such. The register lists the
driver contains are more or less dependent on that frequency.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Vladimir,

On Wed, Feb 22, 2017 at 12:37:51AM +0200, Vladimir Zapolskiy wrote:
> Hi Sakari,
> 
> On 02/21/2017 11:48 PM, Sakari Ailus wrote:
> > Hi, Vladimir!
> > 
> > How do you do? :-)
> 
> deferring execution of boring tasks by doing code review :)

X-)

> 
> > On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote:
> >> Hi Ramiro,
> >>
> >> On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> >>> Hi Vladimir,
> >>>
> >>> Thank you for your feedback
> >>>
> >>> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
> >>>> Hi Ramiro,
> >>>>
> >>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
> >>>>> Create device tree bindings documentation.
> >>>>>
> >>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> >>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>>>> ---
> >>>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
> >>>>>  1 file changed, 35 insertions(+)
> >>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>> new file mode 100644
> >>>>> index 000000000000..31956426d3b9
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>> @@ -0,0 +1,35 @@
> >>>>> +Omnivision OV5647 raw image sensor
> >>>>> +---------------------------------
> >>>>> +
> >>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >>>>> +and CCI (I2C compatible) control bus.
> >>>>> +
> >>>>> +Required properties:
> >>>>> +
> >>>>> +- compatible		: "ovti,ov5647".
> >>>>> +- reg			: I2C slave address of the sensor.
> >>>>> +- clocks		: Reference to the xclk clock.
> >>>>
> >>>> Is "xclk" clock a pixel clock or something else?
> >>>>
> >>>
> >>> It's an external oscillator.
> >>
> >> hmm, I suppose a clock of any type could serve as a clock for the sensor.
> >> It can be an external oscillator on a particular board, or it can be
> >> something else on another board.
> > 
> > Any clock source could be used I presume.
> > 
> 
> That's exactly my point, and it is a reason to rename "xclk" to something
> more generic.

That's a sensor specific name, the one in the hardware datasheet should be
used if there's one, shouldn't it?

An alternative is not to use a name, as there's just a single clock.

> 
> >>
> >> Can you please describe what for does ov5647 sensor need this clock, what
> >> is its function?
> > 
> > Camera modules (sensors) quite commonly require an external clock as they do
> > not have an oscillator on their own. A lot of devices under
> > Documentation/devicetree/bindings/media/i2c/ have similar properties.
> > 
> 
> So, what should be a better replacement of "xclk" in the description above?
> 
> E.g.
> 
> - clocks		: Phandle to a device supply clock.
> 
> >>
> >>>
> >>>>> +- clock-names		: Should be "xclk".
> 
> We got an agreement that "clock-names" property is removed, nevertheless
> if it is added back, is should not be "xclk".
> 
> >>>>
> >>>> You can remove this property, because there is only one source clock.
> >>>>
> >>>
> >>> Ok.
> >>>
> >>>>> +- clock-frequency	: Frequency of the xclk clock.
> >>>>
> >>>> And after the last updates in the driver this property can be removed as well.
> >>>>
> >>>
> >>> But I'm still using clk_get_rate in the driver, if I remove the frequency here
> >>> the probing will fail.
> >>>
> >>
> >> I doubt it, there should be no connection between a custom "clock-frequency"
> >> device tree property in a clock consumer device node and clk_get_rate() function
> >> from the CCF, which takes a clock provider as its argument.
> > 
> > The purpose is to make sure the clock frequency is really usable for the
> > device, in this particular case the driver can work with one particular
> > frequency.
> > 
> > That said, the driver does not appear to use the property at the moment. It
> > should.
> > 
> > It'd be good to verify that the rate matches: clk_set_rate() is not
> > guaranteed to produce the requested clock rate, and the driver could
> > conceivably be updated with support for more frequencies. There are
> > typically a few frequencies that a SoC such a sensor is connected can
> > support, and 25 MHz is not one of the common frequencies. With this
> > property, the frequency would be always there explicitly.
> > 
> 
> I can provide my arguments given at v8 review time again, since I don't
> see a contradiction with my older comments.
> 
> Briefly "clock-frequency" as a device tree property on a consumer side
> can be considered as redundant, because there is a mechanism to specify
> a wanted clock frequency on a clock provider side right in a board DTB.

You can, but there's no guarantee that the frequency what you get is going
to be what you asked for.

Although, the driver could try to work on the actual obtained frequency.
This is unlikely to work though, but it won't be very easy to figure out
why the device isn't working. Having the frequency in DT accessible for the
driver to check makes failing early with a clear error message possible.

> 
> So, the clock frequency set up is delegated to CCF, and when any other
> than 25 MHz frequencies are got supported, that's only the matter of
> driver updates, DTBs won't be touched.

Indeed. The new supported frequencies in this case will be additional
single values; there won't be ranges or such. The register lists the
driver contains are more or less dependent on that frequency.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

On Sat, Feb 25, 2017 at 04:50:53PM +0200, Sakari Ailus wrote:
> Although, the driver could try to work on the actual obtained frequency.
> This is unlikely to work though, but it won't be very easy to figure out
> why the device isn't working. Having the frequency in DT accessible for the
> driver to check makes failing early with a clear error message possible.

The below point actually makes the above matter a non-issue: this driver
will contain a list of supported frequencies. A SMIA driver that I
typically work with, for instance, does not. So I think your suggestion of
having the CCF handle setting the frequency is a good one.

> 
> > 
> > So, the clock frequency set up is delegated to CCF, and when any other
> > than 25 MHz frequencies are got supported, that's only the matter of
> > driver updates, DTBs won't be touched.
> 
> Indeed. The new supported frequencies in this case will be additional
> single values; there won't be ranges or such. The register lists the
> driver contains are more or less dependent on that frequency.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v9 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

On Sat, Feb 25, 2017 at 04:50:53PM +0200, Sakari Ailus wrote:
> Although, the driver could try to work on the actual obtained frequency.
> This is unlikely to work though, but it won't be very easy to figure out
> why the device isn't working. Having the frequency in DT accessible for the
> driver to check makes failing early with a clear error message possible.

The below point actually makes the above matter a non-issue: this driver
will contain a list of supported frequencies. A SMIA driver that I
typically work with, for instance, does not. So I think your suggestion of
having the CCF handle setting the frequency is a good one.

> 
> > 
> > So, the clock frequency set up is delegated to CCF, and when any other
> > than 25 MHz frequencies are got supported, that's only the matter of
> > driver updates, DTBs won't be touched.
> 
> Indeed. The new supported frequencies in this case will be additional
> single values; there won't be ranges or such. The register lists the
> driver contains are more or less dependent on that frequency.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html