Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5961335imu; Tue, 13 Nov 2018 14:43:47 -0800 (PST) X-Google-Smtp-Source: AJdET5eI0a4ltPuD3ugIcJdz1wh8XgAnyu5P3E7nFHYcbJ/wB8sB0KnQVKnvpWpsyn8ouOmufMhi X-Received: by 2002:a63:5c61:: with SMTP id n33-v6mr6230275pgm.1.1542149027071; Tue, 13 Nov 2018 14:43:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542149027; cv=none; d=google.com; s=arc-20160816; b=jGiOeVAyBcw/lM1Q1d+QvLwk9upKcyYQnurO7/swDeLrDmu2InUcuj0o+wbWUVFJbf RU2g2pAjFObnJhUt2p33J3z+I69Y4GBqejpvoczyf/7a6r7FmRABqzf3ZoKWC0pOkUmw 0jbZwAIJrlwZbPgomf920VdrJguP49vkcdAzyuaJEQHd7cCXKuzWvckVmJp9nIGw5sdC ImUHDkyDObMu45I9uQdYkeXk5t/2/7gB4HUFKjraSETC/Qyr520y8WMOhEf8lokLrY0T Gf2kcBtuwjhUZG0W/WG4Dzth/dJzxOImrQ3NaEjIjiiOBlFrlqBdP5pHLO76kqwsCoDO cw+w== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=V1VqOjGegcUNEYQ0nNoyH/n8Jd1KUXsQDJvvy6CAWto=; b=On9ZjqvBkm6Yn0kZQyK+mTBurz0Hr480IFltl/9XccU+ZZH2gmMQS9Fnitc2aKdXkX 89sc1hSGj+sV361Uj16scqFiwDzvwwafW8TGvZbm2HJcq4qvfdfLnzbtuCM/RZGFLlWq yd55SlvKmXlyIy5dvdWCX4Ns3xU5QPiRZBvgFklnZxCxmA/JHepsZR46/uG5ruvVGsyE D39Oq/C0Gvxo1E2jjO4W646KhmuqRHFObLap0EFGspkSEfYLQRN1IaB9K1IqkwMGX0ze b3mJVXjr/fJXD5jxiDg876vCbAj3yL8T9teiQxzUT9qM/WkCFnqVdp+F9yp3GrAGT3u2 H0mQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u69si3083116pfj.219.2018.11.13.14.43.31; Tue, 13 Nov 2018 14:43:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731307AbeKNIn3 (ORCPT + 99 others); Wed, 14 Nov 2018 03:43:29 -0500 Received: from srv-hp10-72.netsons.net ([94.141.22.72]:53082 "EHLO srv-hp10-72.netsons.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726022AbeKNIn3 (ORCPT ); Wed, 14 Nov 2018 03:43:29 -0500 Received: from [5.157.104.112] (port=36764 helo=[192.168.77.57]) by srv-hp10.netsons.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gMhOY-005luB-Mt; Tue, 13 Nov 2018 23:42:54 +0100 From: Luca Ceresoli Subject: Re: [PATCH v4 1/4] dt-bindings: media: i2c: Add bindings for Maxim Integrated MAX9286 To: Kieran Bingham , linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, sakari.ailus@iki.fi Cc: =?UTF-8?Q?Niklas_S=c3=b6derlund?= , Jacopo Mondi , Laurent Pinchart , Kieran Bingham , linux-kernel@vger.kernel.org, Laurent Pinchart , Jacopo Mondi References: <20181102154723.23662-1-kieran.bingham@ideasonboard.com> <20181102154723.23662-2-kieran.bingham@ideasonboard.com> Message-ID: Date: Tue, 13 Nov 2018 23:42:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181102154723.23662-2-kieran.bingham@ideasonboard.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - srv-hp10.netsons.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lucaceresoli.net X-Get-Message-Sender-Via: srv-hp10.netsons.net: authenticated_id: luca+lucaceresoli.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: srv-hp10.netsons.net: luca@lucaceresoli.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kieran, All, sorry for joining this late... See below my considerations. On 02/11/18 16:47, Kieran Bingham wrote: > From: Laurent Pinchart > > The MAX9286 deserializes video data received on up to 4 Gigabit > Multimedia Serial Links (GMSL) and outputs them on a CSI-2 port using up > to 4 data lanes. > > Signed-off-by: Laurent Pinchart > Signed-off-by: Jacopo Mondi > Signed-off-by: Kieran Bingham > > --- > v3: > - Update binding descriptions > > v4: > - Define the use of a CSI2 D-PHY > - Rename pwdn-gpios to enable-gpios (with inverted polarity) > - Remove clock-lanes mapping support > - rewrap text blocks > - Fix typos > --- > .../bindings/media/i2c/maxim,max9286.txt | 182 ++++++++++++++++++ > 1 file changed, 182 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt > > diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt > new file mode 100644 > index 000000000000..672f6a4d417d > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt > @@ -0,0 +1,182 @@ > +Maxim Integrated Quad GMSL Deserializer > +--------------------------------------- > + > +The MAX9286 deserializer receives video data on up to 4 Gigabit Multimedia > +Serial Links (GMSL) and outputs them on a CSI-2 D-PHY port using up to 4 data > +lanes. > + > +In addition to video data, the GMSL links carry a bidirectional control channel > +that encapsulates I2C messages. The MAX9286 forwards all I2C traffic not > +addressed to itself to the other side of the links, where a GMSL serializer > +will output it on a local I2C bus. In the other direction all I2C traffic > +received over GMSL by the MAX9286 is output on the local I2C bus. > + > +Required Properties: > + > +- compatible: Shall be "maxim,max9286" > +- reg: I2C device address > + > +Optional Properties: > + > +- poc-supply: Regulator providing Power over Coax to the cameras > +- enable-gpios: GPIO connected to the #PWDN pin with inverted polarity > + > +Required endpoint nodes: > +----------------------- > + > +The connections to the MAX9286 GMSL and its endpoint nodes are modeled using > +the OF graph bindings in accordance with the video interface bindings defined > +in Documentation/devicetree/bindings/media/video-interfaces.txt. > + > +The following table lists the port number corresponding to each device port. > + > + Port Description > + ---------------------------------------- > + Port 0 GMSL Input 0 > + Port 1 GMSL Input 1 > + Port 2 GMSL Input 2 > + Port 3 GMSL Input 3 > + Port 4 CSI-2 Output > + > +Optional Endpoint Properties for GMSL Input Ports (Port [0-3]): > + > +- remote-endpoint: phandle to the remote GMSL source endpoint subnode in the > + remote node port. > + > +Required Endpoint Properties for CSI-2 Output Port (Port 4): > + > +- remote-endpoint: phandle to the remote CSI-2 sink endpoint node. > +- data-lanes: array of physical CSI-2 data lane indexes. > + > +Required i2c-mux nodes: > +---------------------- > + > +Each GMSL link is modeled as a child bus of an i2c bus multiplexer/switch, in > +accordance with bindings described in > +Documentation/devicetree/bindings/i2c/i2c-mux.txt. The serializer device on the > +remote end of the GMSL link shall be modelled as a child node of the > +corresponding I2C bus. > + > +Required i2c child bus properties: > +- all properties described as required i2c child bus nodes properties in > + Documentation/devicetree/bindings/i2c/i2c-mux.txt. > + > +Example: > +------- > + > + gmsl-deserializer@2c { > + compatible = "maxim,max9286"; > + reg = <0x2c>; > + poc-supply = <&camera_poc_12v>; > + enable-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + max9286_in0: endpoint { > + remote-endpoint = <&rdacm20_out0>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + max9286_in1: endpoint { > + remote-endpoint = <&rdacm20_out1>; > + }; > + }; > + > + port@2 { > + reg = <2>; > + max9286_in2: endpoint { > + remote-endpoint = <&rdacm20_out2>; > + }; > + }; > + > + port@3 { > + reg = <3>; > + max9286_in3: endpoint { > + remote-endpoint = <&rdacm20_out3>; > + }; > + }; > + > + port@4 { > + reg = <4>; > + max9286_out: endpoint { > + data-lanes = <1 2 3 4>; > + remote-endpoint = <&csi40_in>; > + }; > + }; > + }; > + > + i2c@0 { > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0>; > + > + camera@51 { > + compatible = "imi,rdacm20"; > + reg = <0x51 0x61>; I find this kind of address mapping is the weak point in this patchset. The ser-deser chipset splits the world in "local" and "remote" side. The camera node belongs to the remote side, but the 0x51 and 0x61 addresses belong to the local side. Think about supporting N different main boards and M remote boards. 0x51 might be available on some main boards but not all. IMO under the camera@51 (even the i2c@0) node there should be only remote hardware description. To support the N*M possible combinations, there should be: * a DT for the main board mentioning only addresses for the local i2c bus, down to the i2c@0 with address-cells, size-cells and reg properties * a DT overlay for each remote board, mentioning the remote i2c chips with their physical addresses, but no local addresses The only way I could devise to be generic is to bind each physical remote address to a local address at runtime. Also, to be implemented reliably, an address translation feature is required on the local (de)ser chip. So the question is: can the max9286 chip do i2c address translation? Thanks, -- Luca