Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp561132pxk; Wed, 16 Sep 2020 10:48:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwGdnVGSMkd/BYy1Pow5jsOOpJ6AxgkPyjfT9Q/i3t51QdEF2uMODChSGSHNdO0JgGlbjX X-Received: by 2002:a17:906:594c:: with SMTP id g12mr27517867ejr.347.1600278501050; Wed, 16 Sep 2020 10:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600278501; cv=none; d=google.com; s=arc-20160816; b=cR9vBWrdDRXKMWMmzIXJVEB3JN5HZISpR/18CjcNcJzWmE3YkucfcxJ0UFDPvPPfv7 8hoK3y/L7n/w8ppz46gMr4kAzKp/X5RBRO54AGlH3EAialMtHDURvZvm4bc8neSwdRhT eqBl0USWYNrnUg9phv277Q3O4RxhgHZhlXBTkcHGY7sjZiWP4vm1Pwnwg8cexNdpl/FG NWDCqw9Ua4itkJ+SkWhRdzDzqA9z4Fe/SbsugJtm5AMSxy9JgcnjdrXRlrLtHWZBRkqY ipoA3YiMsf+mKFMaoixwnZOYYZrkcNQiNpIJYog4nE0d5Zt8I4NLzR99Wg3D2gOwyhXt Eqew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=EO+4gPN8i5IG7OmzQ6DZ3QOn9zqEzfzZ8vdgWfwJ3GI=; b=uVxFvsJ3rJVUvrIxZt0pfAPNaZ4zWs7M662OLlAkiaY+mHxgnL/c/tQxB38VoQrHQE DD2AZIfJwb78Q50ATlxd0nSUMYKyYxl6Tt4c9cPNiT2pGnyPL06CpTBJ5LqJGF1+7smk xx3JsSCxbYvE//ixdcvRRPDNENH2Fvv2gdFG3SUNX+BHE8lrlRAwEFoae5n2Tiy3Ivok WPGQw0Bqq15Br8Bc9UwQfyvEetXFlrYMriiL0J69HUzY1Foe+uYK9bXoYkklKoEyax4x 6YxlruMa+NW15KHHTunXDrsRXtRnjFkpHI99NdGF6pnG2ocqX0QOebvKyy1Klux9n+fZ H/Dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f23si12574942edm.413.2020.09.16.10.47.58; Wed, 16 Sep 2020 10:48:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727388AbgIPRqq (ORCPT + 99 others); Wed, 16 Sep 2020 13:46:46 -0400 Received: from mslow2.mail.gandi.net ([217.70.178.242]:52634 "EHLO mslow2.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727010AbgIPRog (ORCPT ); Wed, 16 Sep 2020 13:44:36 -0400 Received: from relay10.mail.gandi.net (unknown [217.70.178.230]) by mslow2.mail.gandi.net (Postfix) with ESMTP id 298A13AB401; Wed, 16 Sep 2020 15:45:18 +0000 (UTC) Received: from uno.lan (93-34-118-233.ip49.fastwebnet.it [93.34.118.233]) (Authenticated sender: jacopo@jmondi.org) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 8435A24000F; Wed, 16 Sep 2020 15:39:54 +0000 (UTC) From: Jacopo Mondi To: kieran.bingham+renesas@ideasonboard.com, laurent.pinchart+renesas@ideasonboard.com, niklas.soderlund+renesas@ragnatech.se, mchehab@kernel.org Cc: Jacopo Mondi , linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, Sakari Ailus , Hans Verkuil , Hyun Kwon , Manivannan Sadhasivam Subject: [PATCH 0/2] media: i2c: Add support for RDACM21 camera module Date: Wed, 16 Sep 2020 17:43:36 +0200 Message-Id: <20200916154338.159747-1-jacopo+renesas@jmondi.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, this series introduces support for the RDACM21 camera module, an automotive camera module based on GMSL technology. The camera module integrates a MAX9271 serializer, and OV10640 image sensor coupled with an OV490 ISP. The image sensor and the ISP are programmed loading the content of an EEPROM chip integrated in the camera module package and are configured to produce images in 1280x1080 YUYV8 format. The camera module driver uses the max9271 library to control the serializer, as the RDACM20 does, to maximize code reuse. And that's for patch 2/2: it's all unicorns and rainbows! Patch 1/2 is the less nice one, and is sent as RFC to trigger discussions. The camera module is connected to a MAXIM development board which integrates a MAX9286 deserializer. The same expansion board is used with the RDACM20 camera module and the max9286 driver is meant to work with both cameras without modifications. Unfortunately, each camera module has its own characteristics, in details: - the RDACM20 module integrates a micro-controller unit that pre-programs the embedded max9271 serializer at power-up time. The serializer then operates with the GMSL reverse channel towards the de-serializer with electrical noise immunity feature enabled ("high-threshold" as per chip manual), and requires the de-serializer to communicate with the camera module with the reverse channel amplitude compensated to 170mV. - the RDACM21 module is not pre-programmed by any micro-controller, and requires the de-serializer to initially maintain the reverse channel amplitude to 100mV, then after the remote ends have been probed and have enabled the noise immunity feature on their reverse channels to increase the amplitude to 170mV to guarantee stability of the communications. For that reason, a mechanism to control the reverse channel amplitude of the GMSL channel is required. The channel amplitude is controlled by the de-serializer, but depends on the properties of the remote serializer. We have explored a few solutions in the past: 1) A dt property that specifies the initial reverse channel amplitude (or simply a boolean property that specifies if any channel pre-compensation is required). Issue is that the property should be set in the de-serializer but depends on the remote side configuration and on which camera module is currently connected. 2) Use get_mbus_config to retrieve the GMSL channel configuration. Hyun has added to get_mbus_config support for GMSL parameters to control the signal polarities[1]. This seems nice, but the channel amplitude has to be set -before- the remote end is probed and no subdev operation can be called until the remote sub-device have registered. In this initial version, [1/2] simply adjust the reverse channel after all remotes have probed, allowing support for RDACM21 but breaking compatibility with RDACM20. Any comment on how this should better be handled ? Thanks j [1] https://github.com/xlnx-hyunkwon/linux-xlnx/commits/hyunk/vision-wip-5.4-next Jacopo Mondi (2): RFC: media: i2c: max9286: Compensate reverse channel media: i2c: Add driver for RDACM21 camera module MAINTAINERS | 12 + drivers/media/i2c/Kconfig | 13 + drivers/media/i2c/Makefile | 2 + drivers/media/i2c/max9286.c | 8 +- drivers/media/i2c/rdacm21.c | 541 ++++++++++++++++++++++++++++++++++++ 5 files changed, 574 insertions(+), 2 deletions(-) create mode 100644 drivers/media/i2c/rdacm21.c -- 2.28.0