Re: [PATCH v3 5/7] media: i2c: max9286: Configure reverse channel amplitude

Re: [PATCH v3 5/7] media: i2c: max9286: Configure reverse channel amplitude

[Kieran Bingham]

Hi Jacopo,

On 16/10/2020 13:06, Jacopo Mondi wrote:
> Adjust reverse channel amplitude according to the presence of
> the 'high-threshold" DTS property.
> 
> If no high threshold compensation is required, start with a low
> amplitude (100mV) and increase it after the remote serializers
> have probed and have enabled noise immunity on their reverse
> channels.
> 
> If high threshold compensation is required, configure the reverse
> channel with a 170mV amplitude before the remote serializers have
> probed.
> 
> This change is required for both rdacm20 and rdacm21 camera modules
> to be correctly probed when used in combination with the max9286
> deserializer.

My only fear here would be that perhaps on other cameras we need a more
fine-grained control of the amplitudes?

But I'll leave that discussion to the binding itself,

For this patch ...

Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>


> 
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
>  drivers/media/i2c/max9286.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
> index 31e27d0f34f1..4c72e1e6b27b 100644
> --- a/drivers/media/i2c/max9286.c
> +++ b/drivers/media/i2c/max9286.c
> @@ -163,6 +163,8 @@ struct max9286_priv {
>  	unsigned int mux_channel;
>  	bool mux_open;
>  
> +	bool high_threshold;
> +
>  	struct v4l2_ctrl_handler ctrls;
>  	struct v4l2_ctrl *pixelrate;
>  
> @@ -557,10 +559,14 @@ static int max9286_notify_bound(struct v4l2_async_notifier *notifier,
>  	 * All enabled sources have probed and enabled their reverse control
>  	 * channels:
>  	 *
> +	 * - Increase the reverse channel amplitude to compensate for the
> +	 *   remote ends high threshold, if not done already
>  	 * - Verify all configuration links are properly detected
>  	 * - Disable auto-ack as communication on the control channel are now
>  	 *   stable.
>  	 */
> +	if (!priv->high_threshold)
> +		max9286_reverse_channel_setup(priv, 170);
>  	max9286_check_config_link(priv, priv->source_mask);
>  
>  	/*
> @@ -967,7 +973,12 @@ static int max9286_setup(struct max9286_priv *priv)
>  	 * only. This should be disabled after the mux is initialised.
>  	 */
>  	max9286_configure_i2c(priv, true);
> -	max9286_reverse_channel_setup(priv, 170);
> +
> +	/*
> +	 * Compensate the remote end high threshold with a larger channel
> +	 * amplitude if necessary.
> +	 */
> +	max9286_reverse_channel_setup(priv, priv->high_threshold ? 170 : 100);
>  
>  	/*
>  	 * Enable GMSL links, mask unused ones and autodetect link
> @@ -1235,6 +1246,12 @@ static int max9286_parse_dt(struct max9286_priv *priv)
>  	}
>  	of_node_put(node);
>  
> +	/*
> +	 * Parse 'high_threshold' property to configure the reverse channel
> +	 * amplitude.
> +	 */
> +	priv->high_threshold = device_property_present(dev, "high_threshold");
> +
>  	priv->route_mask = priv->source_mask;
>  
>  	return 0;
> 

Re: [PATCH v3 2/7] dt-bindings: media: max9286: Document 'maxim,high-threshold'

[Geert Uytterhoeven]

Hi Jacopo,

On Fri, Oct 16, 2020 at 12:09 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> Document the 'maxim,high-threshold' vendor property in the bindings
> document of the max9286 driver.
>
> The newly introduced boolean property allows controlling the initial
> configuration of the GMSL reverse control channel to accommodate
> remote serializers pre-programmed with the high threshold power
> supply noise immunity enabled.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> @@ -51,6 +51,19 @@ properties:
>    '#gpio-cells':
>      const: 2
>
> +  maxim,high-threshold:
> +    description: |
> +      A boolean property to increase the initial amplitude of the reverse
> +      control channel to compensate for remote serializers pre-programmed with
> +      high threshold noise-immunity.
> +
> +      Some camera modules (in example the RDACM20 one) include an on-board MCU
> +      that pre-programs the embedded serializer with reverse channel power
> +      supply noise immunity enabled. The deserializer shall increase its
> +      reverse channel amplitude to compensate that and be able to communicate
> +      with the remote end.
> +    type: boolean

Does this "high" threshold correspond to some numerical value?
I.e. could we run into a future need to support more values than just
true/false?
If yes, we may want to use a numerical value from the start.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH v3 0/7] media: i2c: Add support for RDACM21 camera module

[Jacopo Mondi]

v3:
- small update in 3/7 as suggested by Kieran and Sergei
- Add Kieran's tag to 3/7 and 4/7

Copy of v2 copy letter for reference:

Patch [1/7] introduces the camera module driver.
Only change compared to v1:
- Increase pixel clock to 55MHz

From [2/7] to [5/7] there's a proposal of a possible way to support
both RDACM20 and RDACM21 with the same deserializer driver.
See v1 cover letter for details:
https://www.spinics.net/lists/linux-renesas-soc/msg52886.html

I have tested on Eagle V3M with 4 RDACM21, but the whole point of
this series is to retain compatibility with RDACM20.

For this reason I have included 2 patches on top, not intended for merge
that re-propose DTS support for the MAXIM max9286 expansion board connected
to Salvator-X and add the newly introduced property to the DTS file.

Kieran, I know you have a working setup with RDACM20, the final two patches are
meant for ease your testing. Can you give this series a spin ?
For your convenience I pushed a branch
git://jmondi.org/linux #gmsl/jmondi/renesas-drivers-2020-10-13-v5.9/rdacm21_high-threshold

Series based on latest renesas-drivers tag: renesas-drivers-2020-10-13-v5.9

If I get a confirmation this setup works on Salvator-X, I'll submit the new
property for inclusion to devicetree people, which I have left out at the
moment.

Thanks
  j

Jacopo Mondi (6):
  media: i2c: Add driver for RDACM21 camera module
  dt-bindings: media: max9286: Document 'maxim,high-threshold'
  media: i2c: max9286: Break-out reverse channel setup
  media: i2c: max9286: Make channel amplitude programmable
  media: i2c: max9286: Configure reverse channel amplitude
  [DNI] arm64: dts: renesas: salvator-x-max9286: Use high-threshold

Laurent Pinchart (1):
  arm64: dts: renesas: salvator-x: Add MAX9286 expansion board

 .../bindings/media/i2c/maxim,max9286.yaml     |  15 +
 MAINTAINERS                                   |  12 +
 .../boot/dts/renesas/salvator-x-max9286.dtsi  | 396 +++++++++++++
 drivers/media/i2c/Kconfig                     |  13 +
 drivers/media/i2c/Makefile                    |   2 +
 drivers/media/i2c/max9286.c                   |  51 +-
 drivers/media/i2c/rdacm21.c                   | 538 ++++++++++++++++++
 7 files changed, 1017 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
 create mode 100644 drivers/media/i2c/rdacm21.c

--
2.28.0

[PATCH v3 1/7] media: i2c: Add driver for RDACM21 camera module

[Jacopo Mondi]

The RDACM21 is a GMSL camera supporting 1280x1080 resolution images
developed by IMI based on an Omnivision OV10640 sensor, an Omnivision
OV490 ISP and a Maxim MAX9271 GMSL serializer.

The driver uses the max9271 library module, to maximize code reuse with
other camera module drivers using the same serializer, such as rdacm20.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 MAINTAINERS                 |  12 +
 drivers/media/i2c/Kconfig   |  13 +
 drivers/media/i2c/Makefile  |   2 +
 drivers/media/i2c/rdacm21.c | 538 ++++++++++++++++++++++++++++++++++++
 4 files changed, 565 insertions(+)
 create mode 100644 drivers/media/i2c/rdacm21.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 05ebf59d7685..574fe011c661 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14668,6 +14668,18 @@ F:	drivers/media/i2c/max9271.c
 F:	drivers/media/i2c/max9271.h
 F:	drivers/media/i2c/rdacm20.c
 
+RDACM21 Camera Sensor
+M:	Jacopo Mondi <jacopo+renesas@jmondi.org>
+M:	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
+M:	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+M:	Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
+L:	linux-media@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/media/i2c/rdacm2x-gmsl.yaml
+F:	drivers/media/i2c/max9271.c
+F:	drivers/media/i2c/max9271.h
+F:	drivers/media/i2c/rdacm21.c
+
 RDC R-321X SoC
 M:	Florian Fainelli <florian@openwrt.org>
 S:	Maintained
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 878f66ef2719..cfb3f0bcc4fc 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -1184,6 +1184,19 @@ config VIDEO_RDACM20
 	  This camera should be used in conjunction with a GMSL
 	  deserialiser such as the MAX9286.
 
+config VIDEO_RDACM21
+	tristate "IMI RDACM21 camera support"
+	depends on I2C
+	select V4L2_FWNODE
+	select VIDEO_V4L2_SUBDEV_API
+	select MEDIA_CONTROLLER
+	help
+	  This driver supports the IMI RDACM21 GMSL camera, used in
+	  ADAS systems.
+
+	  This camera should be used in conjunction with a GMSL
+	  deserialiser such as the MAX9286.
+
 config VIDEO_RJ54N1
 	tristate "Sharp RJ54N1CB0C sensor support"
 	depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..f3641b58929d 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -122,6 +122,8 @@ obj-$(CONFIG_VIDEO_IMX355)	+= imx355.o
 obj-$(CONFIG_VIDEO_MAX9286)	+= max9286.o
 rdacm20-camera_module-objs	:= rdacm20.o max9271.o
 obj-$(CONFIG_VIDEO_RDACM20)	+= rdacm20-camera_module.o
+rdacm21-camera_module-objs	:= rdacm21.o max9271.o
+obj-$(CONFIG_VIDEO_RDACM21)	+= rdacm21-camera_module.o
 obj-$(CONFIG_VIDEO_ST_MIPID02) += st-mipid02.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c
new file mode 100644
index 000000000000..279cbe213f32
--- /dev/null
+++ b/drivers/media/i2c/rdacm21.c
@@ -0,0 +1,538 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * IMI RDACM21 GMSL Camera Driver
+ *
+ * Copyright (C) 2017-2020 Jacopo Mondi
+ * Copyright (C) 2017-2019 Kieran Bingham
+ * Copyright (C) 2017-2019 Laurent Pinchart
+ * Copyright (C) 2017-2019 Niklas Söderlund
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ */
+
+#include <linux/delay.h>
+#include <linux/fwnode.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/videodev2.h>
+
+#include <media/v4l2-async.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-subdev.h>
+#include "max9271.h"
+
+#define OV10640_I2C_ADDRESS		0x30
+#define OV10640_ID_LOW			0xa6
+
+#define OV490_I2C_ADDRESS		0x24
+
+#define OV490_ISP_HSIZE_LOW		0x60
+#define OV490_ISP_HSIZE_HIGH		0x61
+#define OV490_ISP_VSIZE_LOW		0x62
+#define OV490_ISP_VSIZE_HIGH		0x63
+
+#define OV490_PID			0x300a
+#define OV490_VER			0x300b
+#define OV490_ID_VAL			0x0490
+#define OV490_ID(_p, _v)		((((_p) & 0xff) << 8) | ((_v) & 0xff))
+
+#define OV10640_PIXEL_RATE		(55000000)
+
+struct rdacm21_device {
+	struct device			*dev;
+	struct max9271_device		*serializer;
+	struct i2c_client		*isp;
+	struct v4l2_subdev		sd;
+	struct media_pad		pad;
+	struct v4l2_mbus_framefmt	fmt;
+	struct v4l2_ctrl_handler	ctrls;
+	u32				addrs[32];
+};
+
+static inline struct rdacm21_device *sd_to_rdacm21(struct v4l2_subdev *sd)
+{
+	return container_of(sd, struct rdacm21_device, sd);
+}
+
+static inline struct rdacm21_device *i2c_to_rdacm21(struct i2c_client *client)
+{
+	return sd_to_rdacm21(i2c_get_clientdata(client));
+}
+
+static const struct ov490_reg {
+	u16 reg;
+	u8 val;
+} ov490_regs_wizard[] = {
+	{0xfffd, 0x80},
+	{0xfffe, 0x82},
+	{0x0071, 0x11},
+	{0x0075, 0x11},
+	{0xfffe, 0x29},
+	{0x6010, 0x01},
+	/*
+	 * OV490 EMB line disable in YUV and RAW data,
+	 * NOTE: EMB line is still used in ISP and sensor
+	 */
+	{0xe000, 0x14},
+	{0xfffe, 0x28},
+	{0x6000, 0x04},
+	{0x6004, 0x00},
+	/*
+	 * PCLK polarity - useless due to silicon bug.
+	 * Use 0x808000bb register instead.
+	 */
+	{0x6008, 0x00},
+	{0xfffe, 0x80},
+	{0x0091, 0x00},
+	/* bit[3]=0 - PCLK polarity workaround. */
+	{0x00bb, 0x1d},
+	/* Ov490 FSIN: app_fsin_from_fsync */
+	{0xfffe, 0x85},
+	{0x0008, 0x00},
+	{0x0009, 0x01},
+	/* FSIN0 source. */
+	{0x000A, 0x05},
+	{0x000B, 0x00},
+	/* FSIN0 delay. */
+	{0x0030, 0x02},
+	{0x0031, 0x00},
+	{0x0032, 0x00},
+	{0x0033, 0x00},
+	/* FSIN1 delay. */
+	{0x0038, 0x02},
+	{0x0039, 0x00},
+	{0x003A, 0x00},
+	{0x003B, 0x00},
+	/* FSIN0 length. */
+	{0x0070, 0x2C},
+	{0x0071, 0x01},
+	{0x0072, 0x00},
+	{0x0073, 0x00},
+	/* FSIN1 length. */
+	{0x0074, 0x64},
+	{0x0075, 0x00},
+	{0x0076, 0x00},
+	{0x0077, 0x00},
+	{0x0000, 0x14},
+	{0x0001, 0x00},
+	{0x0002, 0x00},
+	{0x0003, 0x00},
+	/*
+	 * Load fsin0,load fsin1,load other,
+	 * It will be cleared automatically.
+	 */
+	{0x0004, 0x32},
+	{0x0005, 0x00},
+	{0x0006, 0x00},
+	{0x0007, 0x00},
+	{0xfffe, 0x80},
+	/* Sensor FSIN. */
+	{0x0081, 0x00},
+	/* ov10640 FSIN enable */
+	{0xfffe, 0x19},
+	{0x5000, 0x00},
+	{0x5001, 0x30},
+	{0x5002, 0x8c},
+	{0x5003, 0xb2},
+	{0xfffe, 0x80},
+	{0x00c0, 0xc1},
+	/* ov10640 HFLIP=1 by default */
+	{0xfffe, 0x19},
+	{0x5000, 0x01},
+	{0x5001, 0x00},
+	{0xfffe, 0x80},
+	{0x00c0, 0xdc},
+};
+
+static int ov490_read(struct rdacm21_device *dev, u16 reg, u8 *val)
+{
+	u8 buf[2] = { reg >> 8, reg & 0xff };
+	int ret;
+
+	ret = i2c_master_send(dev->isp, buf, 2);
+	if (ret == 2)
+		ret = i2c_master_recv(dev->isp, val, 1);
+
+	if (ret < 0) {
+		dev_dbg(dev->dev, "%s: register 0x%04x read failed (%d)\n",
+			__func__, reg, ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int ov490_write(struct rdacm21_device *dev, u16 reg, u8 val)
+{
+	u8 buf[3] = { reg >> 8, reg & 0xff, val };
+	int ret;
+
+	dev_dbg(dev->dev, "%s: 0x%04x = 0x%02x\n", __func__, reg, val);
+
+	ret = i2c_master_send(dev->isp, buf, 3);
+	if (ret < 0) {
+		dev_err(dev->dev, "%s: register 0x%04x write failed (%d)\n",
+			__func__, reg, ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int rdacm21_s_stream(struct v4l2_subdev *sd, int enable)
+{
+	struct rdacm21_device *dev = sd_to_rdacm21(sd);
+
+	/*
+	 * Enable serial link now that the ISP provides a valid pixel clock
+	 * to start serializing video data on the GMSL link.
+	 */
+	return max9271_set_serial_link(dev->serializer, enable);
+}
+
+static int rdacm21_enum_mbus_code(struct v4l2_subdev *sd,
+				  struct v4l2_subdev_pad_config *cfg,
+				  struct v4l2_subdev_mbus_code_enum *code)
+{
+	if (code->pad || code->index > 0)
+		return -EINVAL;
+
+	code->code = MEDIA_BUS_FMT_YUYV8_1X16;
+
+	return 0;
+}
+
+static int rdacm21_get_fmt(struct v4l2_subdev *sd,
+			   struct v4l2_subdev_pad_config *cfg,
+			   struct v4l2_subdev_format *format)
+{
+	struct v4l2_mbus_framefmt *mf = &format->format;
+	struct rdacm21_device *dev = sd_to_rdacm21(sd);
+
+	if (format->pad)
+		return -EINVAL;
+
+	mf->width		= dev->fmt.width;
+	mf->height		= dev->fmt.height;
+	mf->code		= MEDIA_BUS_FMT_YUYV8_1X16;
+	mf->colorspace		= V4L2_COLORSPACE_SRGB;
+	mf->field		= V4L2_FIELD_NONE;
+	mf->ycbcr_enc		= V4L2_YCBCR_ENC_601;
+	mf->quantization	= V4L2_QUANTIZATION_FULL_RANGE;
+	mf->xfer_func		= V4L2_XFER_FUNC_NONE;
+
+	return 0;
+}
+
+static struct v4l2_subdev_video_ops rdacm21_video_ops = {
+	.s_stream	= rdacm21_s_stream,
+};
+
+static const struct v4l2_subdev_pad_ops rdacm21_subdev_pad_ops = {
+	.enum_mbus_code = rdacm21_enum_mbus_code,
+	.get_fmt	= rdacm21_get_fmt,
+	.set_fmt	= rdacm21_get_fmt,
+};
+
+static struct v4l2_subdev_ops rdacm21_subdev_ops = {
+	.video		= &rdacm21_video_ops,
+	.pad		= &rdacm21_subdev_pad_ops,
+};
+
+static int ov490_initialize(struct rdacm21_device *dev)
+{
+	unsigned int ov490_pid_retry = 20;
+	unsigned int timeout;
+	u8 pid, ver, val;
+	unsigned int i;
+	int ret;
+
+	/* Read OV490 Id to test communications. */
+pid_retry:
+	ret = ov490_write(dev, 0xfffd, 0x80);
+	ret = ov490_write(dev, 0xfffe, 0x80);
+	usleep_range(100, 150);
+
+	ret = ov490_read(dev, OV490_PID, &pid);
+	if (ret < 0) {
+		/* Give OV490 a few more cycles to exit from reset. */
+		if (ov490_pid_retry--) {
+			usleep_range(500, 1000);
+			goto pid_retry;
+		}
+
+		dev_err(dev->dev, "OV490 PID read failed (%d)\n", ret);
+		return ret;
+	}
+
+	ret = ov490_read(dev, OV490_VER, &ver);
+	if (ret < 0) {
+		dev_err(dev->dev, "OV490 VERSION read failed (%d)\n", ret);
+		return ret;
+	}
+
+	if (OV490_ID(pid, ver) != OV490_ID_VAL) {
+		dev_err(dev->dev, "OV490 ID mismatch: (0x%04x)\n",
+			OV490_ID(pid, ver));
+		return -ENODEV;
+	}
+
+	/* Wait for firmware boot by reading streamon status. */
+	ov490_write(dev, 0xfffd, 0x80);
+	ov490_write(dev, 0xfffe, 0x29);
+	usleep_range(100, 150);
+	for (timeout = 300; timeout > 0; timeout--) {
+		ov490_read(dev, 0xd000, &val);
+		if (val == 0x0c)
+			break;
+		mdelay(1);
+	}
+	if (!timeout) {
+		dev_err(dev->dev, "Timeout firmware boot wait\n");
+		return -ENODEV;
+	}
+	dev_dbg(dev->dev, "Firmware booted in %u msec\n", 300 - timeout);
+
+	/* Read OV10640 Id to test communications. */
+	ov490_write(dev, 0xfffd, 0x80);
+	ov490_write(dev, 0xfffe, 0x19);
+	usleep_range(100, 150);
+
+	ov490_write(dev, 0x5000, 0x01);
+	ov490_write(dev, 0x5001, 0x30);
+	ov490_write(dev, 0x5002, 0x0a);
+
+	ov490_write(dev, 0xfffe, 0x80);
+	usleep_range(100, 150);
+	ov490_write(dev, 0xc0, 0xc1);
+	ov490_write(dev, 0xfffe, 0x19);
+	usleep_range(1000, 1500);
+	ov490_read(dev, 0x5000, &val);
+	if (val != OV10640_ID_LOW) {
+		dev_err(dev->dev, "OV10640 ID mismatch: (0x%02x)\n", val);
+		return -ENODEV;
+	}
+
+	dev_dbg(dev->dev, "OV10640 ID = 0x%2x\n", val);
+
+	for (i = 0; i < ARRAY_SIZE(ov490_regs_wizard); ++i) {
+		ret = ov490_write(dev, ov490_regs_wizard[i].reg,
+				  ov490_regs_wizard[i].val);
+		if (ret < 0) {
+			dev_err(dev->dev,
+				"%s: register %u (0x%04x) write failed (%d)\n",
+				__func__, i, ov490_regs_wizard[i].reg, ret);
+
+			return -EIO;
+		}
+
+		usleep_range(100, 150);
+	}
+
+	/*
+	 * The ISP is programmed with the content of a serial flash memory.
+	 * Read the firmware configuration to reflect it through the V4L2 APIs.
+	 */
+	ov490_write(dev, 0xfffd, 0x80);
+	ov490_write(dev, 0xfffe, 0x82);
+	usleep_range(100, 150);
+	ov490_read(dev, OV490_ISP_HSIZE_HIGH, &val);
+	dev->fmt.width = (val & 0xf) << 8;
+	ov490_read(dev, OV490_ISP_HSIZE_LOW, &val);
+	dev->fmt.width |= (val & 0xff);
+
+	ov490_read(dev, OV490_ISP_VSIZE_HIGH, &val);
+	dev->fmt.height = (val & 0xf) << 8;
+	ov490_read(dev, OV490_ISP_VSIZE_LOW, &val);
+	dev->fmt.height |= val & 0xff;
+
+	/* Set bus width to 12 bits [0:11] */
+	ov490_write(dev, 0xfffd, 0x80);
+	ov490_write(dev, 0xfffe, 0x28);
+	usleep_range(100, 150);
+	ov490_write(dev, 0x6009, 0x10);
+
+	dev_info(dev->dev, "Identified RDACM21 camera module\n");
+
+	return 0;
+}
+
+static int rdacm21_initialize(struct rdacm21_device *dev)
+{
+	int ret;
+
+	/* Verify communication with the MAX9271: ping to wakeup. */
+	dev->serializer->client->addr = MAX9271_DEFAULT_ADDR;
+	i2c_smbus_read_byte(dev->serializer->client);
+
+	/* Serial link disabled during config as it needs a valid pixel clock. */
+	ret = max9271_set_serial_link(dev->serializer, false);
+	if (ret)
+		return ret;
+
+	/* Set GPO high to hold OV490 in reset during max9271 configuration. */
+	ret = max9271_set_gpios(dev->serializer, MAX9271_GPO);
+	if (ret)
+		return ret;
+
+	/* Configure I2C bus at 105Kbps speed and configure GMSL link. */
+	ret = max9271_configure_i2c(dev->serializer,
+				    MAX9271_I2CSLVSH_469NS_234NS |
+				    MAX9271_I2CSLVTO_1024US |
+				    MAX9271_I2CMSTBT_105KBPS);
+	if (ret)
+		return ret;
+
+	ret = max9271_configure_gmsl_link(dev->serializer);
+	if (ret)
+		return ret;
+
+	ret = max9271_set_address(dev->serializer, dev->addrs[0]);
+	if (ret)
+		return ret;
+	dev->serializer->client->addr = dev->addrs[0];
+
+	/*
+	 * Release OV490 from reset and program address translation
+	 * before performing OV490 configuration.
+	 */
+	ret = max9271_clear_gpios(dev->serializer, MAX9271_GPO);
+	if (ret)
+		return ret;
+
+	ret = max9271_set_translation(dev->serializer, dev->addrs[1],
+				      OV490_I2C_ADDRESS);
+	if (ret)
+		return ret;
+	dev->isp->addr = dev->addrs[1];
+
+	ret = ov490_initialize(dev);
+	if (ret)
+		return ret;
+
+	/*
+	 * Set reverse channel high threshold to increase noise immunity.
+	 *
+	 * This should be compensated by increasing the reverse channel
+	 * amplitude on the remote deserializer side.
+	 */
+	ret = max9271_set_high_threshold(dev->serializer, true);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int rdacm21_probe(struct i2c_client *client)
+{
+	struct rdacm21_device *dev;
+	struct fwnode_handle *ep;
+	int ret;
+
+	dev = devm_kzalloc(&client->dev, sizeof(*dev), GFP_KERNEL);
+	if (!dev)
+		return -ENOMEM;
+	dev->dev = &client->dev;
+
+	dev->serializer = devm_kzalloc(&client->dev, sizeof(*dev->serializer),
+				       GFP_KERNEL);
+	if (!dev->serializer)
+		return -ENOMEM;
+
+	dev->serializer->client = client;
+
+	ret = of_property_read_u32_array(client->dev.of_node, "reg",
+					 dev->addrs, 2);
+	if (ret < 0) {
+		dev_err(dev->dev, "Invalid DT reg property: %d\n", ret);
+		return -EINVAL;
+	}
+
+	/* Create the dummy I2C client for the sensor. */
+	dev->isp = i2c_new_dummy_device(client->adapter, OV490_I2C_ADDRESS);
+	if (IS_ERR(dev->isp))
+		return PTR_ERR(dev->isp);
+
+	ret = rdacm21_initialize(dev);
+	if (ret < 0)
+		goto error;
+
+	/* Initialize and register the subdevice. */
+	v4l2_i2c_subdev_init(&dev->sd, client, &rdacm21_subdev_ops);
+	dev->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+	v4l2_ctrl_handler_init(&dev->ctrls, 1);
+	v4l2_ctrl_new_std(&dev->ctrls, NULL, V4L2_CID_PIXEL_RATE,
+			  OV10640_PIXEL_RATE, OV10640_PIXEL_RATE, 1,
+			  OV10640_PIXEL_RATE);
+	dev->sd.ctrl_handler = &dev->ctrls;
+
+	ret = dev->ctrls.error;
+	if (ret)
+		goto error_free_ctrls;
+
+	dev->pad.flags = MEDIA_PAD_FL_SOURCE;
+	dev->sd.entity.flags |= MEDIA_ENT_F_CAM_SENSOR;
+	ret = media_entity_pads_init(&dev->sd.entity, 1, &dev->pad);
+	if (ret < 0)
+		goto error_free_ctrls;
+
+	ep = fwnode_graph_get_next_endpoint(dev_fwnode(&client->dev), NULL);
+	if (!ep) {
+		dev_err(&client->dev,
+			"Unable to get endpoint in node %pOF\n",
+			client->dev.of_node);
+		ret = -ENOENT;
+		goto error_free_ctrls;
+	}
+	dev->sd.fwnode = ep;
+
+	ret = v4l2_async_register_subdev(&dev->sd);
+	if (ret)
+		goto error_put_node;
+
+	return 0;
+
+error_put_node:
+	fwnode_handle_put(dev->sd.fwnode);
+error_free_ctrls:
+	v4l2_ctrl_handler_free(&dev->ctrls);
+error:
+	i2c_unregister_device(dev->isp);
+
+	return ret;
+}
+
+static int rdacm21_remove(struct i2c_client *client)
+{
+	struct rdacm21_device *dev = i2c_to_rdacm21(client);
+
+	fwnode_handle_put(dev->sd.fwnode);
+	v4l2_async_unregister_subdev(&dev->sd);
+	i2c_unregister_device(dev->isp);
+
+	return 0;
+}
+
+static const struct of_device_id rdacm21_of_ids[] = {
+	{ .compatible = "imi,rdacm21" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, rdacm21_of_ids);
+
+static struct i2c_driver rdacm21_i2c_driver = {
+	.driver	= {
+		.name	= "rdacm21",
+		.of_match_table = rdacm21_of_ids,
+	},
+	.probe_new	= rdacm21_probe,
+	.remove		= rdacm21_remove,
+};
+
+module_i2c_driver(rdacm21_i2c_driver);
+
+MODULE_DESCRIPTION("GMSL Camera driver for RDACM21");
+MODULE_AUTHOR("Jacopo Mondi, Kieran Bingham, Laurent Pinchart, Niklas Söderlund, Vladimir Barinov");
+MODULE_LICENSE("GPL v2");
-- 
2.28.0

[PATCH v3 2/7] dt-bindings: media: max9286: Document 'maxim,high-threshold'

[Jacopo Mondi]

Document the 'maxim,high-threshold' vendor property in the bindings
document of the max9286 driver.

The newly introduced boolean property allows controlling the initial
configuration of the GMSL reverse control channel to accommodate
remote serializers pre-programmed with the high threshold power
supply noise immunity enabled.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 .../bindings/media/i2c/maxim,max9286.yaml         | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 9ea827092fdd..50e08a7d3204 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -51,6 +51,19 @@ properties:
   '#gpio-cells':
     const: 2
 
+  maxim,high-threshold:
+    description: |
+      A boolean property to increase the initial amplitude of the reverse
+      control channel to compensate for remote serializers pre-programmed with
+      high threshold noise-immunity.
+
+      Some camera modules (in example the RDACM20 one) include an on-board MCU
+      that pre-programs the embedded serializer with reverse channel power
+      supply noise immunity enabled. The deserializer shall increase its
+      reverse channel amplitude to compensate that and be able to communicate
+      with the remote end.
+    type: boolean
+
   ports:
     type: object
     description: |
@@ -243,6 +256,8 @@ examples:
         gpio-controller;
         #gpio-cells = <2>;
 
+        maxim,high-threshold;
+
         ports {
           #address-cells = <1>;
           #size-cells = <0>;
-- 
2.28.0

[PATCH v3 3/7] media: i2c: max9286: Break-out reverse channel setup

[Jacopo Mondi]

Break out the reverse channel setup configuration procedure to its own
function.

This change prepares for configuring the reverse channel conditionally
to the remote side high threshold configuration.

No functional changes intended.

Reviewed-by: Kieran Bingham <kieran.bingham+renesasa@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 drivers/media/i2c/max9286.c | 30 +++++++++++++++++-------------
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
index d969ac21a058..526b6e557dfb 100644
--- a/drivers/media/i2c/max9286.c
+++ b/drivers/media/i2c/max9286.c
@@ -336,6 +336,22 @@ static void max9286_configure_i2c(struct max9286_priv *priv, bool localack)
 	usleep_range(3000, 5000);
 }
 
+static void max9286_reverse_channel_setup(struct max9286_priv *priv)
+{
+	/*
+	 * Reverse channel setup.
+	 *
+	 * - Enable custom reverse channel configuration (through register 0x3f)
+	 *   and set the first pulse length to 35 clock cycles.
+	 * - Increase the reverse channel amplitude to 170mV to accommodate the
+	 *   high threshold enabled by the serializer driver.
+	 */
+	max9286_write(priv, 0x3f, MAX9286_EN_REV_CFG | MAX9286_REV_FLEN(35));
+	max9286_write(priv, 0x3b, MAX9286_REV_TRF(1) | MAX9286_REV_AMP(70) |
+		      MAX9286_REV_AMP_X);
+	usleep_range(2000, 2500);
+}
+
 /*
  * max9286_check_video_links() - Make sure video links are detected and locked
  *
@@ -941,19 +957,7 @@ static int max9286_setup(struct max9286_priv *priv)
 	 * only. This should be disabled after the mux is initialised.
 	 */
 	max9286_configure_i2c(priv, true);
-
-	/*
-	 * Reverse channel setup.
-	 *
-	 * - Enable custom reverse channel configuration (through register 0x3f)
-	 *   and set the first pulse length to 35 clock cycles.
-	 * - Increase the reverse channel amplitude to 170mV to accommodate the
-	 *   high threshold enabled by the serializer driver.
-	 */
-	max9286_write(priv, 0x3f, MAX9286_EN_REV_CFG | MAX9286_REV_FLEN(35));
-	max9286_write(priv, 0x3b, MAX9286_REV_TRF(1) | MAX9286_REV_AMP(70) |
-		      MAX9286_REV_AMP_X);
-	usleep_range(2000, 2500);
+	max9286_reverse_channel_setup(priv);
 
 	/*
 	 * Enable GMSL links, mask unused ones and autodetect link
-- 
2.28.0

[PATCH v3 4/7] media: i2c: max9286: Make channel amplitude programmable

[Jacopo Mondi]

Instrument the function that configures the reverse channel with a
programmable amplitude value.

This change serves to prepare to adjust the reverse channel amplitude
depending on the remote end high-threshold configuration.

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 drivers/media/i2c/max9286.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
index 526b6e557dfb..31e27d0f34f1 100644
--- a/drivers/media/i2c/max9286.c
+++ b/drivers/media/i2c/max9286.c
@@ -336,19 +336,29 @@ static void max9286_configure_i2c(struct max9286_priv *priv, bool localack)
 	usleep_range(3000, 5000);
 }
 
-static void max9286_reverse_channel_setup(struct max9286_priv *priv)
+static void max9286_reverse_channel_setup(struct max9286_priv *priv,
+					  unsigned int chan_amplitude)
 {
+	/* Reverse channel transmission time: default to 1. */
+	u8 chan_config = MAX9286_REV_TRF(1);
+
 	/*
 	 * Reverse channel setup.
 	 *
 	 * - Enable custom reverse channel configuration (through register 0x3f)
 	 *   and set the first pulse length to 35 clock cycles.
-	 * - Increase the reverse channel amplitude to 170mV to accommodate the
-	 *   high threshold enabled by the serializer driver.
+	 * - Adjust reverse channel amplitude: values > 130 are programmed
+	 *   using the additional +100mV REV_AMP_X boost flag
 	 */
 	max9286_write(priv, 0x3f, MAX9286_EN_REV_CFG | MAX9286_REV_FLEN(35));
-	max9286_write(priv, 0x3b, MAX9286_REV_TRF(1) | MAX9286_REV_AMP(70) |
-		      MAX9286_REV_AMP_X);
+
+	if (chan_amplitude > 100) {
+		/* It is not possible to express values (100 < x < 130) */
+		chan_amplitude = chan_amplitude < 130
+			       ? 30 : chan_amplitude - 100;
+		chan_config |= MAX9286_REV_AMP_X;
+	}
+	max9286_write(priv, 0x3b, chan_config | MAX9286_REV_AMP(chan_amplitude));
 	usleep_range(2000, 2500);
 }
 
@@ -957,7 +967,7 @@ static int max9286_setup(struct max9286_priv *priv)
 	 * only. This should be disabled after the mux is initialised.
 	 */
 	max9286_configure_i2c(priv, true);
-	max9286_reverse_channel_setup(priv);
+	max9286_reverse_channel_setup(priv, 170);
 
 	/*
 	 * Enable GMSL links, mask unused ones and autodetect link
-- 
2.28.0

[PATCH v3 5/7] media: i2c: max9286: Configure reverse channel amplitude

[Jacopo Mondi]

Adjust reverse channel amplitude according to the presence of
the 'high-threshold" DTS property.

If no high threshold compensation is required, start with a low
amplitude (100mV) and increase it after the remote serializers
have probed and have enabled noise immunity on their reverse
channels.

If high threshold compensation is required, configure the reverse
channel with a 170mV amplitude before the remote serializers have
probed.

This change is required for both rdacm20 and rdacm21 camera modules
to be correctly probed when used in combination with the max9286
deserializer.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 drivers/media/i2c/max9286.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
index 31e27d0f34f1..4c72e1e6b27b 100644
--- a/drivers/media/i2c/max9286.c
+++ b/drivers/media/i2c/max9286.c
@@ -163,6 +163,8 @@ struct max9286_priv {
 	unsigned int mux_channel;
 	bool mux_open;
 
+	bool high_threshold;
+
 	struct v4l2_ctrl_handler ctrls;
 	struct v4l2_ctrl *pixelrate;
 
@@ -557,10 +559,14 @@ static int max9286_notify_bound(struct v4l2_async_notifier *notifier,
 	 * All enabled sources have probed and enabled their reverse control
 	 * channels:
 	 *
+	 * - Increase the reverse channel amplitude to compensate for the
+	 *   remote ends high threshold, if not done already
 	 * - Verify all configuration links are properly detected
 	 * - Disable auto-ack as communication on the control channel are now
 	 *   stable.
 	 */
+	if (!priv->high_threshold)
+		max9286_reverse_channel_setup(priv, 170);
 	max9286_check_config_link(priv, priv->source_mask);
 
 	/*
@@ -967,7 +973,12 @@ static int max9286_setup(struct max9286_priv *priv)
 	 * only. This should be disabled after the mux is initialised.
 	 */
 	max9286_configure_i2c(priv, true);
-	max9286_reverse_channel_setup(priv, 170);
+
+	/*
+	 * Compensate the remote end high threshold with a larger channel
+	 * amplitude if necessary.
+	 */
+	max9286_reverse_channel_setup(priv, priv->high_threshold ? 170 : 100);
 
 	/*
 	 * Enable GMSL links, mask unused ones and autodetect link
@@ -1235,6 +1246,12 @@ static int max9286_parse_dt(struct max9286_priv *priv)
 	}
 	of_node_put(node);
 
+	/*
+	 * Parse 'high_threshold' property to configure the reverse channel
+	 * amplitude.
+	 */
+	priv->high_threshold = device_property_present(dev, "high_threshold");
+
 	priv->route_mask = priv->source_mask;
 
 	return 0;
-- 
2.28.0

[PATCH v3 6/7] arm64: dts: renesas: salvator-x: Add MAX9286 expansion board

[Jacopo Mondi]

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Add a .dtsi fragment to describe the MAX9286-based expansion board for
the Renesas Salvator-X board.

The MAX9286 expansion board has eight RDACM20 cameras connected to it.
They can be individually controlled by enabling or disabling the macro
defines.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>

---
v2:
 - Use SPDX headers
 - Remove link from ADV748x TXA (HDMI)
 - Use 0x31-0x38, and 0x41-0x48 for the 8 cameras. 0x30 and 0x40 are the
   base addresses for the OV10635 and MAX9271 (0x50 for the MCU)
 - Provide RDACM20 MCU I2C address reservations. (0x51-0x58)

v3:
 - Fix gmsl-serializer@ i2c node addressing

v6:
 - Make i2c-mux child node and update to be conformant to new bindings.

v7:
 - Separate register arguments
---
 .../boot/dts/renesas/salvator-x-max9286.dtsi  | 394 ++++++++++++++++++
 1 file changed, 394 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi

diff --git a/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi b/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
new file mode 100644
index 000000000000..6f4798859542
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Device Tree Source for the Salvator-X MAX9286 expansion board
+ *
+ * Copyright (C) 2017 Ideas on Board <laurent.pinchart@ideasonboard.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/*
+ * MAX9286 A
+ */
+#define MAXIM_CAMERA0 "imi,rdacm20"
+#define MAXIM_CAMERA1 "imi,rdacm20"
+#define MAXIM_CAMERA2 "imi,rdacm20"
+#define MAXIM_CAMERA3 "imi,rdacm20"
+
+/*
+ * MAX9286 B
+ */
+#define MAXIM_CAMERA4 "imi,rdacm20"
+#define MAXIM_CAMERA5 "imi,rdacm20"
+#define MAXIM_CAMERA6 "imi,rdacm20"
+#define MAXIM_CAMERA7 "imi,rdacm20"
+
+/ {
+/*
+ * Powered MCU IMI cameras need delay between power-on and R-Car access
+ * to avoid I2C bus conflicts since the R-Car I2C does not support I2C
+ * multi-master. The I2C bus conflict would result in R-Car I2C IP stall.
+ */
+#define IMI_MCU_V0_DELAY	8000000	/* delay for powered MCU firmware v0 */
+#define IMI_MCU_V1_DELAY	3000000	/* delay for powered MCU firmware v1 */
+#define IMI_MCU_NO_DELAY	0	/* delay for unpowered MCU  */
+#define IMI_MCU_DELAY		IMI_MCU_V0_DELAY
+
+	poc_12v: regulator-vcc-poc-12v {
+		compatible = "regulator-fixed";
+
+		regulator-name = "Camera PoC 12V";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+		startup-delay-us = <(250000 + IMI_MCU_DELAY)>;
+
+		gpio = <&gpio6 30 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+};
+
+&vin0 {
+	status = "okay";
+};
+
+&vin1 {
+	status = "okay";
+};
+
+&vin2 {
+	status = "okay";
+};
+
+&vin3 {
+	status = "okay";
+};
+
+&vin4 {
+	status = "okay";
+};
+
+&vin5 {
+	status = "okay";
+};
+
+&vin6 {
+	status = "okay";
+};
+
+&vin7 {
+	status = "okay";
+};
+
+/* Disconnect the csi40 endpoint from the ADV748x TXA (HDMI) */
+&adv7482_txa {
+	/delete-property/ remote-endpoint;
+	status = "disabled";
+};
+
+&csi40 {
+	status = "okay";
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			csi40_in: endpoint {
+				clock-lanes = <0>;
+				data-lanes = <1 2 3 4>;
+				remote-endpoint = <&max9286_out0>;
+			};
+		};
+	};
+};
+
+&csi41 {
+	status = "okay";
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			csi41_in: endpoint {
+				clock-lanes = <0>;
+				data-lanes = <1 2 3 4>;
+				remote-endpoint = <&max9286_out1>;
+			};
+		};
+	};
+};
+
+&i2c4 {
+	gmsl-deserializer@4c {
+		compatible = "maxim,max9286";
+		reg = <0x4c>;
+		poc-supply = <&poc_12v>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				max9286_in0: endpoint {
+#ifdef MAXIM_CAMERA0
+					remote-endpoint = <&rdacm20_out0>;
+#endif
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				max9286_in1: endpoint {
+#ifdef MAXIM_CAMERA1
+					remote-endpoint = <&rdacm20_out1>;
+#endif
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+				max9286_in2: endpoint {
+#ifdef MAXIM_CAMERA2
+					remote-endpoint = <&rdacm20_out2>;
+#endif
+				};
+			};
+
+			port@3 {
+				reg = <3>;
+				max9286_in3: endpoint {
+#ifdef MAXIM_CAMERA3
+					remote-endpoint = <&rdacm20_out3>;
+#endif
+				};
+			};
+
+			port@4 {
+				reg = <4>;
+				max9286_out0: endpoint {
+					clock-lanes = <0>;
+					data-lanes = <1 2 3 4>;
+					remote-endpoint = <&csi40_in>;
+				};
+			};
+		};
+
+		i2c-mux {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@0 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0>;
+
+#ifdef MAXIM_CAMERA0
+				camera@31 {
+					compatible = MAXIM_CAMERA0;
+					reg = <0x31>, <0x41>, <0x51>;
+
+					port {
+						rdacm20_out0: endpoint {
+							remote-endpoint = <&max9286_in0>;
+						};
+					};
+
+				};
+#endif
+			};
+
+			i2c@1 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <1>;
+
+#ifdef MAXIM_CAMERA1
+				camera@32 {
+					compatible = MAXIM_CAMERA1;
+					reg = <0x32>, <0x42>, <0x52>;
+					port {
+						rdacm20_out1: endpoint {
+							remote-endpoint = <&max9286_in1>;
+						};
+					};
+				};
+#endif
+			};
+
+			i2c@2 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <2>;
+
+#ifdef MAXIM_CAMERA2
+				camera@33 {
+					compatible = MAXIM_CAMERA2;
+					reg = <0x33>, <0x43>, <0x53>;
+					port {
+						rdacm20_out2: endpoint {
+							remote-endpoint = <&max9286_in2>;
+						};
+					};
+				};
+#endif
+			};
+
+			i2c@3 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <3>;
+
+#ifdef MAXIM_CAMERA3
+				camera@34 {
+					compatible = MAXIM_CAMERA3;
+					reg = <0x34>, <0x44>, <0x54>;
+					port {
+						rdacm20_out3: endpoint {
+							remote-endpoint = <&max9286_in3>;
+						};
+					};
+				};
+#endif
+			};
+		};
+	};
+
+	gmsl-deserializer@6c {
+		compatible = "maxim,max9286";
+		reg = <0x6c>;
+		poc-supply = <&poc_12v>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				max9286_in4: endpoint {
+#ifdef MAXIM_CAMERA4
+					remote-endpoint = <&rdacm20_out4>;
+#endif
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				max9286_in5: endpoint {
+#ifdef MAXIM_CAMERA5
+					remote-endpoint = <&rdacm20_out5>;
+#endif
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+				max9286_in6: endpoint {
+#ifdef MAXIM_CAMERA6
+					remote-endpoint = <&rdacm20_out6>;
+#endif
+				};
+			};
+
+			port@3 {
+				reg = <3>;
+				max9286_in7: endpoint {
+#ifdef MAXIM_CAMERA7
+					remote-endpoint = <&rdacm20_out7>;
+#endif
+				};
+			};
+
+			port@4 {
+				reg = <4>;
+				max9286_out1: endpoint {
+					clock-lanes = <0>;
+					data-lanes = <1 2 3 4>;
+					remote-endpoint = <&csi41_in>;
+				};
+			};
+		};
+
+		i2c-mux {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			i2c@0 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0>;
+
+#ifdef MAXIM_CAMERA4
+				camera@35 {
+					compatible = MAXIM_CAMERA4;
+					reg = <0x35>, <0x45>, <0x55>;
+					port {
+						rdacm20_out4: endpoint {
+							remote-endpoint = <&max9286_in4>;
+						};
+					};
+				};
+#endif
+			};
+
+			i2c@1 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <1>;
+
+#ifdef MAXIM_CAMERA5
+				camera@36 {
+					compatible = MAXIM_CAMERA5;
+					reg = <0x36>, <0x46>, <0x56>;
+					port {
+						rdacm20_out5: endpoint {
+							remote-endpoint = <&max9286_in5>;
+						};
+					};
+				};
+#endif
+			};
+
+			i2c@2 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <2>;
+
+#ifdef MAXIM_CAMERA6
+				camera@37 {
+					compatible = MAXIM_CAMERA6;
+					reg = <0x37>, <0x47>, <0x57>;
+					port {
+						rdacm20_out6: endpoint {
+							remote-endpoint = <&max9286_in6>;
+						};
+					};
+				};
+#endif
+			};
+
+			i2c@3 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <3>;
+
+#ifdef MAXIM_CAMERA7
+				camera@38 {
+					compatible = MAXIM_CAMERA7;
+					reg = <0x38>, <0x48>, <0x58>;
+					port {
+						rdacm20_out7: endpoint {
+							remote-endpoint = <&max9286_in7>;
+						};
+					};
+				};
+#endif
+			};
+		};
+	};
+};
-- 
2.28.0

[PATCH v3 7/7] [DNI] arm64: dts: renesas: salvator-x-max9286: Use high-threshold

[Jacopo Mondi]

Use the newly introduced 'maxim,high-threshold' property to maintain
compatibility with RDACM20 camera module.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi b/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
index 6f4798859542..e207436f8690 100644
--- a/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
@@ -128,6 +128,7 @@ gmsl-deserializer@4c {
 		compatible = "maxim,max9286";
 		reg = <0x4c>;
 		poc-supply = <&poc_12v>;
+		maxim,high-threshold;
 
 		ports {
 			#address-cells = <1>;
@@ -263,6 +264,7 @@ gmsl-deserializer@6c {
 		compatible = "maxim,max9286";
 		reg = <0x6c>;
 		poc-supply = <&poc_12v>;
+		maxim,high-threshold;
 
 		ports {
 			#address-cells = <1>;
-- 
2.28.0

Re: [PATCH v3 2/7] dt-bindings: media: max9286: Document 'maxim,high-threshold'

[Geert Uytterhoeven]

Hi Jacopo,

On Fri, Oct 16, 2020 at 2:56 PM Jacopo Mondi <jacopo@jmondi.org> wrote:
> On Fri, Oct 16, 2020 at 01:50:34PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Oct 16, 2020 at 12:09 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > > Document the 'maxim,high-threshold' vendor property in the bindings
> > > document of the max9286 driver.
> > >
> > > The newly introduced boolean property allows controlling the initial
> > > configuration of the GMSL reverse control channel to accommodate
> > > remote serializers pre-programmed with the high threshold power
> > > supply noise immunity enabled.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > Thanks for your patch!
> >
> > > --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > @@ -51,6 +51,19 @@ properties:
> > >    '#gpio-cells':
> > >      const: 2
> > >
> > > +  maxim,high-threshold:
> > > +    description: |
> > > +      A boolean property to increase the initial amplitude of the reverse
> > > +      control channel to compensate for remote serializers pre-programmed with
> > > +      high threshold noise-immunity.
> > > +
> > > +      Some camera modules (in example the RDACM20 one) include an on-board MCU
> > > +      that pre-programs the embedded serializer with reverse channel power
> > > +      supply noise immunity enabled. The deserializer shall increase its
> > > +      reverse channel amplitude to compensate that and be able to communicate
> > > +      with the remote end.
> > > +    type: boolean
> >
> > Does this "high" threshold correspond to some numerical value?
> > I.e. could we run into a future need to support more values than just
> > true/false?
> > If yes, we may want to use a numerical value from the start.
>
> So, this boolean property controls the initial setting of the reverse
> channel amplitude, which has to be opportunely adjusted to be able to
> probe the remote devices as i2c messages are bridged on the reverse
> channel from the deserializer to the remote serializers.
>
> It also implies that if the initial setting is not "high" it has to be
> increased after the remotes have probed, as it is assumed at the end
> the remotes' probe() routine they have enabled their high threshold
> noise immunity feature.
>
> The register that controls the de-serializer reverse channel amplitude
> is not fully documented in the chip manual version I have, but the
> application developer guide shows that it can range from 30mV to
> 200mV. The same developer guide shows 100mV and 170mV as "initial" and
> "high threshold" values to be used.
>
> On the serializer's side (MAX9271 at least) high threshold is a
> boolean control, it is either enabled or disabled.
>
> Hence I suspect that for the max9286-max9271 combo, using fixed 100mV
> and 170mV values is enough. Other serializers might allow a more fine
> grained control of the noise cancelling threshold, and might require a
> more precise adjustment of the deserializer side. I'm honestly not
> sure at this point not having seen any other one.
>
> So yes, this is a deserializer setting that depends on the serializer
> in use, and I'm not 100% comfortable expressing it as a deserializer
> property. That said, having an initial numerical value might serve the
> same purpose allowing more flexibility, if other serializers require a
> more precise control of the initial amplitude.
>
> After the remotes have probed, we could also re-explore the
> possibility of getting the bus configuration using get_mbus_config, as
> detailed in the v1 cover letter [1] as at that time their sub-devices
> have been registered and we can call operations on them. But again,
> this might be not required at all.

Sounds like "maxim,<foo>-threshold-mV" is the way to go?
If you don't know the exact register configuration, and need to
convert to a boolean in the driver, you can still use something like
"threshold < 150 ? ... : ...".

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3 2/7] dt-bindings: media: max9286: Document 'maxim,high-threshold'

[Kieran Bingham]

Hi Jacopo,

On 16/10/2020 14:04, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Fri, Oct 16, 2020 at 2:56 PM Jacopo Mondi <jacopo@jmondi.org> wrote:
>> On Fri, Oct 16, 2020 at 01:50:34PM +0200, Geert Uytterhoeven wrote:
>>> On Fri, Oct 16, 2020 at 12:09 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>>>> Document the 'maxim,high-threshold' vendor property in the bindings
>>>> document of the max9286 driver.
>>>>
>>>> The newly introduced boolean property allows controlling the initial
>>>> configuration of the GMSL reverse control channel to accommodate
>>>> remote serializers pre-programmed with the high threshold power
>>>> supply noise immunity enabled.
>>>>
>>>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
>>>> @@ -51,6 +51,19 @@ properties:
>>>>    '#gpio-cells':
>>>>      const: 2
>>>>
>>>> +  maxim,high-threshold:
>>>> +    description: |
>>>> +      A boolean property to increase the initial amplitude of the reverse
>>>> +      control channel to compensate for remote serializers pre-programmed with
>>>> +      high threshold noise-immunity.
>>>> +
>>>> +      Some camera modules (in example the RDACM20 one) include an on-board MCU
>>>> +      that pre-programs the embedded serializer with reverse channel power
>>>> +      supply noise immunity enabled. The deserializer shall increase its
>>>> +      reverse channel amplitude to compensate that and be able to communicate
>>>> +      with the remote end.
>>>> +    type: boolean
>>>
>>> Does this "high" threshold correspond to some numerical value?
>>> I.e. could we run into a future need to support more values than just
>>> true/false?
>>> If yes, we may want to use a numerical value from the start.
>>
>> So, this boolean property controls the initial setting of the reverse
>> channel amplitude, which has to be opportunely adjusted to be able to
>> probe the remote devices as i2c messages are bridged on the reverse
>> channel from the deserializer to the remote serializers.
>>
>> It also implies that if the initial setting is not "high" it has to be
>> increased after the remotes have probed, as it is assumed at the end
>> the remotes' probe() routine they have enabled their high threshold
>> noise immunity feature.
>>
>> The register that controls the de-serializer reverse channel amplitude
>> is not fully documented in the chip manual version I have, but the
>> application developer guide shows that it can range from 30mV to
>> 200mV. The same developer guide shows 100mV and 170mV as "initial" and
>> "high threshold" values to be used.
>>
>> On the serializer's side (MAX9271 at least) high threshold is a
>> boolean control, it is either enabled or disabled.
>>
>> Hence I suspect that for the max9286-max9271 combo, using fixed 100mV
>> and 170mV values is enough. Other serializers might allow a more fine
>> grained control of the noise cancelling threshold, and might require a
>> more precise adjustment of the deserializer side. I'm honestly not
>> sure at this point not having seen any other one.
>>
>> So yes, this is a deserializer setting that depends on the serializer
>> in use, and I'm not 100% comfortable expressing it as a deserializer
>> property. That said, having an initial numerical value might serve the
>> same purpose allowing more flexibility, if other serializers require a
>> more precise control of the initial amplitude.

And one of the benefits of your series, is that you've codified the
conversion from the input value to the register value, which is really
helpful.

I think the fact that you've implemented the required feature, means
exposing the value here makes more sense.

However, once exposed outside of the driver, I'd add some clamping on
the allowed min/max values in the max9286_reverse_channel_setup() function.

>>
>> After the remotes have probed, we could also re-explore the
>> possibility of getting the bus configuration using get_mbus_config, as
>> detailed in the v1 cover letter [1] as at that time their sub-devices
>> have been registered and we can call operations on them. But again,
>> this might be not required at all.
> 
> Sounds like "maxim,<foo>-threshold-mV" is the way to go?
> If you don't know the exact register configuration, and need to
> convert to a boolean in the driver, you can still use something like
> "threshold < 150 ? ... : ...".

This sounds like a reasonable path to me - I'm still really weary that
it's defining it on the deser, rather than the serialiser - but perhaps
there's no current option to do that.


I presume we can't wait until we can obtain a value through
get_mbus_config() ?

That's going to be chicken and egg, as the camera can't probe until we
have the i2c channels set up ... yet the information we want, doesn't
need the bus to be configured... so there's indeed some missing pieces
to the puzzle for that to happen ;-(

also - I guess the other key issue that would make me believe we keep
this as a deserialiser property, is that it affects the whole
configuration right? It's not just one of the four links - it's all of
them collectively.

(well, unless we called max9286_reverse_channel_setup() separately for
each link bring up ...)

--
Kieran


> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: [PATCH v3 2/7] dt-bindings: media: max9286: Document 'maxim,high-threshold'

[Jacopo Mondi]

Hi Geert
   (and Kieran, as his question on the other patch is actually on
   the same point)

On Fri, Oct 16, 2020 at 01:50:34PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Fri, Oct 16, 2020 at 12:09 PM Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > Document the 'maxim,high-threshold' vendor property in the bindings
> > document of the max9286 driver.
> >
> > The newly introduced boolean property allows controlling the initial
> > configuration of the GMSL reverse control channel to accommodate
> > remote serializers pre-programmed with the high threshold power
> > supply noise immunity enabled.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> Thanks for your patch!
>
> > --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > @@ -51,6 +51,19 @@ properties:
> >    '#gpio-cells':
> >      const: 2
> >
> > +  maxim,high-threshold:
> > +    description: |
> > +      A boolean property to increase the initial amplitude of the reverse
> > +      control channel to compensate for remote serializers pre-programmed with
> > +      high threshold noise-immunity.
> > +
> > +      Some camera modules (in example the RDACM20 one) include an on-board MCU
> > +      that pre-programs the embedded serializer with reverse channel power
> > +      supply noise immunity enabled. The deserializer shall increase its
> > +      reverse channel amplitude to compensate that and be able to communicate
> > +      with the remote end.
> > +    type: boolean
>
> Does this "high" threshold correspond to some numerical value?
> I.e. could we run into a future need to support more values than just
> true/false?
> If yes, we may want to use a numerical value from the start.

So, this boolean property controls the initial setting of the reverse
channel amplitude, which has to be opportunely adjusted to be able to
probe the remote devices as i2c messages are bridged on the reverse
channel from the deserializer to the remote serializers.

It also implies that if the initial setting is not "high" it has to be
increased after the remotes have probed, as it is assumed at the end
the remotes' probe() routine they have enabled their high threshold
noise immunity feature.

The register that controls the de-serializer reverse channel amplitude
is not fully documented in the chip manual version I have, but the
application developer guide shows that it can range from 30mV to
200mV. The same developer guide shows 100mV and 170mV as "initial" and
"high threshold" values to be used.

On the serializer's side (MAX9271 at least) high threshold is a
boolean control, it is either enabled or disabled.

Hence I suspect that for the max9286-max9271 combo, using fixed 100mV
and 170mV values is enough. Other serializers might allow a more fine
grained control of the noise cancelling threshold, and might require a
more precise adjustment of the deserializer side. I'm honestly not
sure at this point not having seen any other one.

So yes, this is a deserializer setting that depends on the serializer
in use, and I'm not 100% comfortable expressing it as a deserializer
property. That said, having an initial numerical value might serve the
same purpose allowing more flexibility, if other serializers require a
more precise control of the initial amplitude.

After the remotes have probed, we could also re-explore the
possibility of getting the bus configuration using get_mbus_config, as
detailed in the v1 cover letter [1] as at that time their sub-devices
have been registered and we can call operations on them. But again,
this might be not required at all.

Thanks
   j

[1] https://www.spinics.net/lists/linux-renesas-soc/msg52886.html

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds