From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2768C433DF for ; Tue, 2 Jun 2020 09:57:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB64E20679 for ; Tue, 2 Jun 2020 09:57:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726012AbgFBJ5F (ORCPT ); Tue, 2 Jun 2020 05:57:05 -0400 Received: from mga12.intel.com ([192.55.52.136]:50609 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725811AbgFBJ5F (ORCPT ); Tue, 2 Jun 2020 05:57:05 -0400 IronPort-SDR: kgh/cr5DKADTl0fZ6IQClxEltISwO05NjvH5iCqp+Tsflx6YXEv/9sLKP9J6YZR1mP0T02oS35 25dLY2vw1PQw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2020 02:57:01 -0700 IronPort-SDR: f5pjhVT4Hj49CKceAZLTS74rIEdpoYh4/acIP08Zj1vAOUlBP6YhHPZuGdb0XaFyASIKWEl1L2 T9Kb4uSOJ+2A== X-IronPort-AV: E=Sophos;i="5.73,463,1583222400"; d="scan'208";a="416128886" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2020 02:56:56 -0700 Received: by paasikivi.fi.intel.com (Postfix, from userid 1000) id 9497820A25; Tue, 2 Jun 2020 12:56:54 +0300 (EEST) Date: Tue, 2 Jun 2020 12:56:54 +0300 From: Sakari Ailus To: Dongchun Zhu Cc: Tomasz Figa , Rob Herring , Linus Walleij , Bartosz Golaszewski , Mauro Carvalho Chehab , Andy Shevchenko , Mark Rutland , Nicolas Boichat , Matthias Brugger , Cao Bing Bu , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Sj Huang , Linux Media Mailing List , linux-devicetree , Louis Kuo , Shengnan Wang =?utf-8?B?KOeOi+Wco+eUtyk=?= Subject: Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings Message-ID: <20200602095654.GD29325@paasikivi.fi.intel.com> References: <1590569355.8804.448.camel@mhfsdcap03> <20200527211628.GT7618@paasikivi.fi.intel.com> <1590636882.8804.474.camel@mhfsdcap03> <20200528072332.GW7618@paasikivi.fi.intel.com> <1590653082.8804.517.camel@mhfsdcap03> <1590978816.8804.523.camel@mhfsdcap03> <1591078501.8804.539.camel@mhfsdcap03> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1591078501.8804.539.camel@mhfsdcap03> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Dongchun, On Tue, Jun 02, 2020 at 02:15:01PM +0800, Dongchun Zhu wrote: > Hi Tomasz, Sakari, > > On Mon, 2020-06-01 at 20:18 +0200, Tomasz Figa wrote: > > On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu wrote: > > > > > > Hi Tomasz, > > > > > > On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote: > > > > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu wrote: > > > > > > > > > > Hi Sakari, > > > > > > > > > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote: > > > > > > Hi Dongchun, > > > > > > > > > > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote: > > > > > > > Hi Sakari, Rob, > > > > > > > > > > > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote: > > > > > > > > Hi Rob, Dongchun, > > > > > > > > > > > > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote: > > > > > > > > > > > > + properties: > > > > > > > > > > > > + endpoint: > > > > > > > > > > > > + type: object > > > > > > > > > > > > + additionalProperties: false > > > > > > > > > > > > + > > > > > > > > > > > > + properties: > > > > > > > > > > > > > > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here? > > > > > > > > > > > > > > > > > > Yes, if you are using it. > > > > > > > > > > > > > > > > Dongchun, can you confirm the chip has a single data and a single clock > > > > > > > > lane and that it does not support lane reordering? > > > > > > > > > > > > > > > > > > > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single > > > > > > > uni-directional clock lane and one bi-directional data lane solution for > > > > > > > communication links between components inside a mobile device. > > > > > > > The data lane has full support for HS(uni-directional) and > > > > > > > LP(bi-directional) data transfer mode.' > > > > > > > > > > > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property > > > > > > > would not be added in next release. > > > > > > > > > > > > > > > So if there's nothing to convey to the driver, also the data-lanes should > > > > > > > > be removed IMO. > > > > > > > > > > > > > > > > > > > > > > However, 'data-lanes' property may still be required. > > > > > > > It is known that either data-lanes or clock-lanes is an array of > > > > > > > physical data lane indexes. Position of an entry determines the logical > > > > > > > lane number, while the value of an entry indicates physical lane, e.g., > > > > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming > > > > > > > the clock lane is on hardware lane 0. > > > > > > > > > > > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not > > > > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as > > > > > > > there is only a clock lane for OV02A10. > > > > > > > > > > > > > > Reminder: > > > > > > > If 'data-lanes' property is not present, the driver would assume > > > > > > > four-lane operation. This means for one-lane or two-lane operation, this > > > > > > > property must be present and set to the right physical lane indexes. > > > > > > > If the hardware does not support lane reordering, monotonically > > > > > > > incremented values shall be used from 0 or 1 onwards, depending on > > > > > > > whether or not there is also a clock lane. > > > > > > > > > > > > How can the driver use four lanes, considering the device only supports a > > > > > > single lane?? > > > > > > > > > > > > > > > > I understood your meaning. > > > > > If we omit the property 'data-lanes', the sensor should work still. > > > > > But then what's the meaning of the existence of 'data-lanes'? > > > > > If this property 'data-lanes' is always optional, then why dt-bindings > > > > > provide the interface? > > > > > > > > > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter) > > > > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2) > > > > > shall enable four-lane configuration, which may increase consumption of > > > > > both power and resource in the process of IIC communication. > > > > > > > > Wouldn't the receiver still have the data-lanes property under its > > > > endpoint node, telling it how many lanes and in which order should be > > > > used? > > > > > > > > > > The MIPI receiver(RX) shall use > > > v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property > > > "data-lanes" under sensor output port. > > > > That's not true. The MIPI receiver driver parses its own port node > > corresponding to the sensor. Also quoting the documentation [1]: > > > > "An endpoint subnode of a device contains all properties needed for > > _configuration of this device_ for data exchange with other device. In most > > cases properties at the peer 'endpoint' nodes will be identical, however they > > might need to be different when there is any signal modifications on the bus > > between two devices, e.g. there are logic signal inverters on the lines." > > > > In this case, there is such a signal modification if the sensor has a > > 1-lane bus and the receiver more lines, so the data-lanes properties > > would be different on both sides. > > > > [1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt > > > > Sorry for the misunderstanding. > After doing some experiments about the data-lanes property under sensor > i2c node, we found the API > v4l2_async_notifier_add_fwnode_remote_subdev() that MIPI receiver driver > used indeed parses the data-lanes under its own port node. > > Sorry make a mistake for the use case of sensor data-lanes previously. > Now We may encounter one new question for this patch. > In practice we haven't used the data-lanes under sensor i2c node > anywhere, if sensor driver itself doesn't parse that. > > But there is still one reason to keep the exactly right data-lanes in > DT. That is, the data-lanes under sensor i2c node could be used as a > reference for MIPI receiver driver. > Just as Tomasz said, 'The MIPI receiver driver parses its own port node > corresponding to the sensor'. > > Sakari, Tomasz, what's your opinions about the present of data-lanes > under sensor node or not? The receiver driver doesn't parse the properties in the sensor (transmitter) device's endpoint. If that property provides no information to the receiver, as is the case here, it should be omitted. -- Regards, Sakari Ailus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75417C433DF for ; Tue, 2 Jun 2020 09:57:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 486D220679 for ; Tue, 2 Jun 2020 09:57:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mjMNmmCO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 486D220679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tWwQxO0q83uJF8nhG1V3tnsPSZXjphMI7WC8TDmfwVk=; b=mjMNmmCOr5qlXD PZ+84wwwOEodPYHlPHjfHPJxFzpqPXUO1OnebGZf54SrJB9XiPjQnkQ1rH3ncIpI8TD1xkXPTwqym LCrRmZZoDE8cRAcOWN0SL3Qk/PCb9amHtZi6SFd/GYVNu5V3hcxTlXJnGGzL6LDDbIQ0d/LQxcTXa fk2P1sTIpznHE7Jkqpy4cvWUi+al8/K7frnpjFTtALikLv+tUy4olQCZgBlYfYqUHQPkmT2mw3jXv XwEWV9YTyHzzv1NOgh6XICVrmUeiWRvM8ezSAMI6RSFACAOK1Lqpt5/KzTOpge9VvNmCYqhCdyOmF GP9uiDoZVncd/XBxdaag==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jg3fU-00020G-Kh; Tue, 02 Jun 2020 09:57:12 +0000 Received: from mga17.intel.com ([192.55.52.151]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jg3fK-0001rS-6Q; Tue, 02 Jun 2020 09:57:03 +0000 IronPort-SDR: T9/AA9kJYaguA4x2cBJXWs2PW29N96e2CMT1tIAdnSCY31DtvKfxfuOHccqODTgIdMr8PVeQuW Kd+o9mAFhvnw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2020 02:57:01 -0700 IronPort-SDR: f5pjhVT4Hj49CKceAZLTS74rIEdpoYh4/acIP08Zj1vAOUlBP6YhHPZuGdb0XaFyASIKWEl1L2 T9Kb4uSOJ+2A== X-IronPort-AV: E=Sophos;i="5.73,463,1583222400"; d="scan'208";a="416128886" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2020 02:56:56 -0700 Received: by paasikivi.fi.intel.com (Postfix, from userid 1000) id 9497820A25; Tue, 2 Jun 2020 12:56:54 +0300 (EEST) Date: Tue, 2 Jun 2020 12:56:54 +0300 From: Sakari Ailus To: Dongchun Zhu Subject: Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings Message-ID: <20200602095654.GD29325@paasikivi.fi.intel.com> References: <1590569355.8804.448.camel@mhfsdcap03> <20200527211628.GT7618@paasikivi.fi.intel.com> <1590636882.8804.474.camel@mhfsdcap03> <20200528072332.GW7618@paasikivi.fi.intel.com> <1590653082.8804.517.camel@mhfsdcap03> <1590978816.8804.523.camel@mhfsdcap03> <1591078501.8804.539.camel@mhfsdcap03> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1591078501.8804.539.camel@mhfsdcap03> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200602_025702_261806_1CFB92BA X-CRM114-Status: GOOD ( 34.10 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Rob Herring , Andy Shevchenko , srv_heupstream , linux-devicetree , Linus Walleij , Shengnan Wang =?utf-8?B?KOeOi+Wco+eUtyk=?= , Tomasz Figa , Bartosz Golaszewski , Sj Huang , Nicolas Boichat , "moderated list:ARM/Mediatek SoC support" , Louis Kuo , Matthias Brugger , Cao Bing Bu , Mauro Carvalho Chehab , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hi Dongchun, On Tue, Jun 02, 2020 at 02:15:01PM +0800, Dongchun Zhu wrote: > Hi Tomasz, Sakari, > > On Mon, 2020-06-01 at 20:18 +0200, Tomasz Figa wrote: > > On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu wrote: > > > > > > Hi Tomasz, > > > > > > On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote: > > > > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu wrote: > > > > > > > > > > Hi Sakari, > > > > > > > > > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote: > > > > > > Hi Dongchun, > > > > > > > > > > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote: > > > > > > > Hi Sakari, Rob, > > > > > > > > > > > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote: > > > > > > > > Hi Rob, Dongchun, > > > > > > > > > > > > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote: > > > > > > > > > > > > + properties: > > > > > > > > > > > > + endpoint: > > > > > > > > > > > > + type: object > > > > > > > > > > > > + additionalProperties: false > > > > > > > > > > > > + > > > > > > > > > > > > + properties: > > > > > > > > > > > > > > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here? > > > > > > > > > > > > > > > > > > Yes, if you are using it. > > > > > > > > > > > > > > > > Dongchun, can you confirm the chip has a single data and a single clock > > > > > > > > lane and that it does not support lane reordering? > > > > > > > > > > > > > > > > > > > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single > > > > > > > uni-directional clock lane and one bi-directional data lane solution for > > > > > > > communication links between components inside a mobile device. > > > > > > > The data lane has full support for HS(uni-directional) and > > > > > > > LP(bi-directional) data transfer mode.' > > > > > > > > > > > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property > > > > > > > would not be added in next release. > > > > > > > > > > > > > > > So if there's nothing to convey to the driver, also the data-lanes should > > > > > > > > be removed IMO. > > > > > > > > > > > > > > > > > > > > > > However, 'data-lanes' property may still be required. > > > > > > > It is known that either data-lanes or clock-lanes is an array of > > > > > > > physical data lane indexes. Position of an entry determines the logical > > > > > > > lane number, while the value of an entry indicates physical lane, e.g., > > > > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming > > > > > > > the clock lane is on hardware lane 0. > > > > > > > > > > > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not > > > > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as > > > > > > > there is only a clock lane for OV02A10. > > > > > > > > > > > > > > Reminder: > > > > > > > If 'data-lanes' property is not present, the driver would assume > > > > > > > four-lane operation. This means for one-lane or two-lane operation, this > > > > > > > property must be present and set to the right physical lane indexes. > > > > > > > If the hardware does not support lane reordering, monotonically > > > > > > > incremented values shall be used from 0 or 1 onwards, depending on > > > > > > > whether or not there is also a clock lane. > > > > > > > > > > > > How can the driver use four lanes, considering the device only supports a > > > > > > single lane?? > > > > > > > > > > > > > > > > I understood your meaning. > > > > > If we omit the property 'data-lanes', the sensor should work still. > > > > > But then what's the meaning of the existence of 'data-lanes'? > > > > > If this property 'data-lanes' is always optional, then why dt-bindings > > > > > provide the interface? > > > > > > > > > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter) > > > > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2) > > > > > shall enable four-lane configuration, which may increase consumption of > > > > > both power and resource in the process of IIC communication. > > > > > > > > Wouldn't the receiver still have the data-lanes property under its > > > > endpoint node, telling it how many lanes and in which order should be > > > > used? > > > > > > > > > > The MIPI receiver(RX) shall use > > > v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property > > > "data-lanes" under sensor output port. > > > > That's not true. The MIPI receiver driver parses its own port node > > corresponding to the sensor. Also quoting the documentation [1]: > > > > "An endpoint subnode of a device contains all properties needed for > > _configuration of this device_ for data exchange with other device. In most > > cases properties at the peer 'endpoint' nodes will be identical, however they > > might need to be different when there is any signal modifications on the bus > > between two devices, e.g. there are logic signal inverters on the lines." > > > > In this case, there is such a signal modification if the sensor has a > > 1-lane bus and the receiver more lines, so the data-lanes properties > > would be different on both sides. > > > > [1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt > > > > Sorry for the misunderstanding. > After doing some experiments about the data-lanes property under sensor > i2c node, we found the API > v4l2_async_notifier_add_fwnode_remote_subdev() that MIPI receiver driver > used indeed parses the data-lanes under its own port node. > > Sorry make a mistake for the use case of sensor data-lanes previously. > Now We may encounter one new question for this patch. > In practice we haven't used the data-lanes under sensor i2c node > anywhere, if sensor driver itself doesn't parse that. > > But there is still one reason to keep the exactly right data-lanes in > DT. That is, the data-lanes under sensor i2c node could be used as a > reference for MIPI receiver driver. > Just as Tomasz said, 'The MIPI receiver driver parses its own port node > corresponding to the sensor'. > > Sakari, Tomasz, what's your opinions about the present of data-lanes > under sensor node or not? The receiver driver doesn't parse the properties in the sensor (transmitter) device's endpoint. If that property provides no information to the receiver, as is the case here, it should be omitted. -- Regards, Sakari Ailus _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D475C433E1 for ; Tue, 2 Jun 2020 09:57:06 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5133A207D0 for ; Tue, 2 Jun 2020 09:57:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SN40lTRl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5133A207D0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NuBPY8q3Ahm+VcwM5RUZqvecnqeBGB9Nw8bFe82ywW4=; b=SN40lTRlxpHpBb 2xydkrXr+3CxKRw5hRfi5v73pQtxXxqzebCfGqsrsJx6Q7CUV6buWkwdjStQ22sf78JddN0SMZR3M x50k0AadOVq9/i29oS3zaON3WswEG8fpzkkAiKmRBYFRx7quHWw3/n5Ge0P22O/gFWFUaJacKuZbP UyRrSLzQnglsx02YjAYHuvIMIk4mfKeTDAukehHRNf+40pcm6z5e55/ysCUuwkPOHGW36aMEH4FgR eg1yRXU4EOZtt1yJ5GRd2hBCJP1pTGeZ3R5mzgrq62UqAmztcL4WlSwWbbdrV4wtV0qqI5TSvZefJ N8VeA/voFDi3dJQT0kIQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jg3fN-0001sa-S6; Tue, 02 Jun 2020 09:57:05 +0000 Received: from mga17.intel.com ([192.55.52.151]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jg3fK-0001rS-6Q; Tue, 02 Jun 2020 09:57:03 +0000 IronPort-SDR: T9/AA9kJYaguA4x2cBJXWs2PW29N96e2CMT1tIAdnSCY31DtvKfxfuOHccqODTgIdMr8PVeQuW Kd+o9mAFhvnw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2020 02:57:01 -0700 IronPort-SDR: f5pjhVT4Hj49CKceAZLTS74rIEdpoYh4/acIP08Zj1vAOUlBP6YhHPZuGdb0XaFyASIKWEl1L2 T9Kb4uSOJ+2A== X-IronPort-AV: E=Sophos;i="5.73,463,1583222400"; d="scan'208";a="416128886" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2020 02:56:56 -0700 Received: by paasikivi.fi.intel.com (Postfix, from userid 1000) id 9497820A25; Tue, 2 Jun 2020 12:56:54 +0300 (EEST) Date: Tue, 2 Jun 2020 12:56:54 +0300 From: Sakari Ailus To: Dongchun Zhu Subject: Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings Message-ID: <20200602095654.GD29325@paasikivi.fi.intel.com> References: <1590569355.8804.448.camel@mhfsdcap03> <20200527211628.GT7618@paasikivi.fi.intel.com> <1590636882.8804.474.camel@mhfsdcap03> <20200528072332.GW7618@paasikivi.fi.intel.com> <1590653082.8804.517.camel@mhfsdcap03> <1590978816.8804.523.camel@mhfsdcap03> <1591078501.8804.539.camel@mhfsdcap03> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1591078501.8804.539.camel@mhfsdcap03> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200602_025702_261806_1CFB92BA X-CRM114-Status: GOOD ( 34.10 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Rob Herring , Andy Shevchenko , srv_heupstream , linux-devicetree , Linus Walleij , Shengnan Wang =?utf-8?B?KOeOi+Wco+eUtyk=?= , Tomasz Figa , Bartosz Golaszewski , Sj Huang , Nicolas Boichat , "moderated list:ARM/Mediatek SoC support" , Louis Kuo , Matthias Brugger , Cao Bing Bu , Mauro Carvalho Chehab , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Dongchun, On Tue, Jun 02, 2020 at 02:15:01PM +0800, Dongchun Zhu wrote: > Hi Tomasz, Sakari, > > On Mon, 2020-06-01 at 20:18 +0200, Tomasz Figa wrote: > > On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu wrote: > > > > > > Hi Tomasz, > > > > > > On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote: > > > > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu wrote: > > > > > > > > > > Hi Sakari, > > > > > > > > > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote: > > > > > > Hi Dongchun, > > > > > > > > > > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote: > > > > > > > Hi Sakari, Rob, > > > > > > > > > > > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote: > > > > > > > > Hi Rob, Dongchun, > > > > > > > > > > > > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote: > > > > > > > > > > > > + properties: > > > > > > > > > > > > + endpoint: > > > > > > > > > > > > + type: object > > > > > > > > > > > > + additionalProperties: false > > > > > > > > > > > > + > > > > > > > > > > > > + properties: > > > > > > > > > > > > > > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here? > > > > > > > > > > > > > > > > > > Yes, if you are using it. > > > > > > > > > > > > > > > > Dongchun, can you confirm the chip has a single data and a single clock > > > > > > > > lane and that it does not support lane reordering? > > > > > > > > > > > > > > > > > > > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single > > > > > > > uni-directional clock lane and one bi-directional data lane solution for > > > > > > > communication links between components inside a mobile device. > > > > > > > The data lane has full support for HS(uni-directional) and > > > > > > > LP(bi-directional) data transfer mode.' > > > > > > > > > > > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property > > > > > > > would not be added in next release. > > > > > > > > > > > > > > > So if there's nothing to convey to the driver, also the data-lanes should > > > > > > > > be removed IMO. > > > > > > > > > > > > > > > > > > > > > > However, 'data-lanes' property may still be required. > > > > > > > It is known that either data-lanes or clock-lanes is an array of > > > > > > > physical data lane indexes. Position of an entry determines the logical > > > > > > > lane number, while the value of an entry indicates physical lane, e.g., > > > > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming > > > > > > > the clock lane is on hardware lane 0. > > > > > > > > > > > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not > > > > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as > > > > > > > there is only a clock lane for OV02A10. > > > > > > > > > > > > > > Reminder: > > > > > > > If 'data-lanes' property is not present, the driver would assume > > > > > > > four-lane operation. This means for one-lane or two-lane operation, this > > > > > > > property must be present and set to the right physical lane indexes. > > > > > > > If the hardware does not support lane reordering, monotonically > > > > > > > incremented values shall be used from 0 or 1 onwards, depending on > > > > > > > whether or not there is also a clock lane. > > > > > > > > > > > > How can the driver use four lanes, considering the device only supports a > > > > > > single lane?? > > > > > > > > > > > > > > > > I understood your meaning. > > > > > If we omit the property 'data-lanes', the sensor should work still. > > > > > But then what's the meaning of the existence of 'data-lanes'? > > > > > If this property 'data-lanes' is always optional, then why dt-bindings > > > > > provide the interface? > > > > > > > > > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter) > > > > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2) > > > > > shall enable four-lane configuration, which may increase consumption of > > > > > both power and resource in the process of IIC communication. > > > > > > > > Wouldn't the receiver still have the data-lanes property under its > > > > endpoint node, telling it how many lanes and in which order should be > > > > used? > > > > > > > > > > The MIPI receiver(RX) shall use > > > v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property > > > "data-lanes" under sensor output port. > > > > That's not true. The MIPI receiver driver parses its own port node > > corresponding to the sensor. Also quoting the documentation [1]: > > > > "An endpoint subnode of a device contains all properties needed for > > _configuration of this device_ for data exchange with other device. In most > > cases properties at the peer 'endpoint' nodes will be identical, however they > > might need to be different when there is any signal modifications on the bus > > between two devices, e.g. there are logic signal inverters on the lines." > > > > In this case, there is such a signal modification if the sensor has a > > 1-lane bus and the receiver more lines, so the data-lanes properties > > would be different on both sides. > > > > [1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt > > > > Sorry for the misunderstanding. > After doing some experiments about the data-lanes property under sensor > i2c node, we found the API > v4l2_async_notifier_add_fwnode_remote_subdev() that MIPI receiver driver > used indeed parses the data-lanes under its own port node. > > Sorry make a mistake for the use case of sensor data-lanes previously. > Now We may encounter one new question for this patch. > In practice we haven't used the data-lanes under sensor i2c node > anywhere, if sensor driver itself doesn't parse that. > > But there is still one reason to keep the exactly right data-lanes in > DT. That is, the data-lanes under sensor i2c node could be used as a > reference for MIPI receiver driver. > Just as Tomasz said, 'The MIPI receiver driver parses its own port node > corresponding to the sensor'. > > Sakari, Tomasz, what's your opinions about the present of data-lanes > under sensor node or not? The receiver driver doesn't parse the properties in the sensor (transmitter) device's endpoint. If that property provides no information to the receiver, as is the case here, it should be omitted. -- Regards, Sakari Ailus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel