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=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 2BE53C433E7 for ; Fri, 16 Oct 2020 12:32:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 7B2C1207BC for ; Fri, 16 Oct 2020 12:32:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JwHJNml6"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="rlwJ0Iob"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=microchiptechnology.onmicrosoft.com header.i=@microchiptechnology.onmicrosoft.com header.b="UBBllEfG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B2C1207BC Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Content-ID:In-Reply-To:References: Message-ID:Date:Subject:To:From:Reply-To:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hoFEYosZRHvuBZXd8ESuJXUUwse6A7jK2Cqoq8dywZU=; b=JwHJNml6pc2cFdn9gccGmudC2 9LxrbVdIMDt/CX215gTJyrhzRRMmaVUy5/05/mNA/0P89F5NaKUPgCzLDPU5HhmSSMirVyKRhnC7Q 02jMX9wOuVXxfp5rDmr0hPElI5TjwV4cG17R7VMOhmb4c3hpZCS5ZU91D1yTMwEgwBXyzG5dgNHL5 IbJHMfz5AcfO/7oc4vVFOUrdFkEYeHsBBbXZ1TB/y6KHphfljg/O/GCKSEYMnQkoLZUMVgP+o5kyD K3o67/2RasfxdDZHAxraX5mCdeCtbRBpekv8lNpzrzrlGWFO6mSy/i0hv/Wehj7xYyLedLYLAkbDi HKcMbGczA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTOt5-0001d1-8a; Fri, 16 Oct 2020 12:31:11 +0000 Received: from esa5.microchip.iphmx.com ([216.71.150.166]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTOt0-0001cH-7H for linux-arm-kernel@lists.infradead.org; Fri, 16 Oct 2020 12:31:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1602851467; x=1634387467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zh27I/Uz2zyFeJvjF7bVO87bmHYsfRUInWYCr/x5XOw=; b=rlwJ0Iob1Yud3b33AYSX1DF1eSQrK23/4PqhmSOvzcziQ2+p9LtPVpXV mhPay9OGnQrrxj2Il8B5Y7ct9h4ipYYSLjNDn85rr79i5A6IMf0FtLwpc /An7WCPQSTkL1YPG20oSSTJI0CquXevdS+m8GxbVf+XSnVRsLFvtlLalx Ha5CR6ijhLlLJKkL9h/kqyJtqLymwHUZ9Q2QBeLBi1cRNDDO8b60CJYjJ 1ibRQldC2zMzUmoeTOUiOkXc7rqRGWAhM0mTsDEGz8ljKui+cnnQlEFg9 YjYsz3jTyQqebZD4LPqE7e2nBCL0AK6ZCnwKXrS/jPYg2APBO5NutGMz2 g==; IronPort-SDR: G8W3ajbjL3um8uKUAcCmcHiuK9rqWsvDz+AqOdUPFLwPlWdYmHfrmuDxs9gIDV/beYKe0DbReo YMoQSwHlNFqbKI+yLhm/Ghc6eBqx7tpJjr9UYc9PjPmchSFPMqY/JnqYPHTzU5Xb9Jr+jC6z0r Zc0uOIYNin2V0Lnm+U2lFV0JxXDl8wTHfV+B+fPmjRfCnK1g1rjEPKPWvEmkutdbRIpj5H6f+M 8/81kG8RAYRsVRzldGt8q+R+xxG/Q3Jf7i4NAfJzHlaM++IqW49Up3POjzq+yRLZYd9NojTugD 3uY= X-IronPort-AV: E=Sophos;i="5.77,382,1596524400"; d="scan'208";a="94876972" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa5.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 16 Oct 2020 05:31:04 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 16 Oct 2020 05:31:02 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (10.10.215.89) by email.microchip.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3 via Frontend Transport; Fri, 16 Oct 2020 05:31:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vq7fRFf4QS048/hlVgV+C1tCFK7QGGdSON6o0njwh8VF1I2pQatCk9hbekPm97xZxDTijODF/PhDrCHVi/njlhuF1bWiEEArTdPjJKTujwn5tVqxRSfIO2D7c538uytkpLaSPkwNyzDVkiypXsBChnrK5atJ4oG0Jkgrf8GDTfWmY4UglTIDYonGX7h8XDNUNZxraK6shjTFcLE3eRu06GtF4czDp31MAT9mGEdAucczDmIob2+uXALoJZlU3+TKJpKsxG6TAve6EHGnMD7hFNxf5Kea2/lAkYGejP7Ko08c2PEZ8+6PESYUToPVBuY5qdRnZJJr9iChg0ogYtFriw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zh27I/Uz2zyFeJvjF7bVO87bmHYsfRUInWYCr/x5XOw=; b=N45of7f6cOdyf7HTgJGSEe7n5jnteytcaCSZ6l5ary8XJPy6BAmYxKGJIylJas5XFTiYXm64QfxfMYFix+gzX+QmoHVu+jT071uRu+/Nt6jdZ9bINKty9Q3Gs/L1ESGQjy/tPSSdVhn8Il3+DMRNDdqd9XIPMPKOndGo8ep35I/FHzk1wlYU3un+kQVPpPcKqTapVHcs3YC3N4gWtbzcDdKQoxmwIUPduWjsUPeRQ8qg2x1oFoP0o2COI9sbJF63hBsODf04zJKbxX0lNqDzMRlBsGtKvIiUtiqtbRoIYZ2ig1yyzYA4Y9xIhO/Lv0+fWcYa4fmjuZ0O28/TXe00MA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microchip.com; dmarc=pass action=none header.from=microchip.com; dkim=pass header.d=microchip.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microchiptechnology.onmicrosoft.com; s=selector2-microchiptechnology-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zh27I/Uz2zyFeJvjF7bVO87bmHYsfRUInWYCr/x5XOw=; b=UBBllEfG6xxA8Ohnh7eRuJtYz/z/hY0vnDDT7I0SjRRnnQHcvz6OQDJ3ax4cdFQ5bqbi1AcQe1SLLURVJ2ureJaYD7lZKGCB8unmcq+hkOaxJU+tUHG2uVk+S9PRYojiQMpDJObskmc/q9NH1N89L8RTJWjF/cAfqxrlOEj7bo0= Received: from BYAPR11MB2999.namprd11.prod.outlook.com (2603:10b6:a03:90::17) by BY5PR11MB4276.namprd11.prod.outlook.com (2603:10b6:a03:1b9::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.28; Fri, 16 Oct 2020 12:31:00 +0000 Received: from BYAPR11MB2999.namprd11.prod.outlook.com ([fe80::4854:dda7:8d0f:bb51]) by BYAPR11MB2999.namprd11.prod.outlook.com ([fe80::4854:dda7:8d0f:bb51%7]) with mapi id 15.20.3477.025; Fri, 16 Oct 2020 12:30:59 +0000 From: To: Subject: Re: [PATCH v3 1/3] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc Thread-Topic: [PATCH v3 1/3] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc Thread-Index: AQHWe3Vqn0L0AW6OnE6uFIjSaVH1XKmRnqqAgAI6iACAAGBOgIAGP/sA Date: Fri, 16 Oct 2020 12:30:59 +0000 Message-ID: References: <20200826065142.205000-1-eugen.hristev@microchip.com> <20201010211743.GB3939@pendragon.ideasonboard.com> <20201012130425.2rszhgd7eh7nffrv@uno.localdomain> In-Reply-To: <20201012130425.2rszhgd7eh7nffrv@uno.localdomain> Accept-Language: en-US, ro-RO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: jmondi.org; dkim=none (message not signed) header.d=none;jmondi.org; dmarc=none action=none header.from=microchip.com; x-originating-ip: [188.27.154.238] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9643038c-5b3c-408c-f837-08d871cf56ad x-ms-traffictypediagnostic: BY5PR11MB4276: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5nHyJaImIvF/VBJJk0AvB8OAAClk/uFXadJh8UzngTPGx0fAs7M97bfCroViICPtL8aSK58z0IBfdUl1VgEOidztXvHm8qY8SbsQnCQD7Id2GmI9JZT8ZVwOSSo/vK0UkNJe2Gb7b4aaZfv96ouFrDMYKUlBSCSMWsUeF/vwvfKFBRShG9vxgk+v9gk8ef+NHhdqfHuljSEjGRVDFc90C2aAsJPeTvs6aYHf7ZR6l3vFHk+7IsTCsr8w1Pf1bnuqMdQjsNP46LS4K2Ll4FNO9LyJg7oTLfVkZdlbCF52o4iUbtEp6OnUmyVrsOXWC5Zxp6ca4kBIovwHKri7u4Fxqjo5mn9KijyK2uQvDaBxeNsW1WKIPc0Xd6zq4pzU0i98kgedNQmdXb34KoHQYpgzhgmSCCOzXKKJAEc5QeAp8B+7+GKuYwk+iKZsbLP9CrURdrTmvU7Y1gFoSOMiXXhFFw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2999.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(376002)(396003)(366004)(136003)(2906002)(6486002)(76116006)(6512007)(36756003)(86362001)(4326008)(53546011)(6916009)(316002)(31696002)(2616005)(6506007)(8936002)(966005)(66556008)(26005)(186003)(66446008)(66946007)(91956017)(5660300002)(478600001)(54906003)(83380400001)(71200400001)(66476007)(8676002)(31686004)(64756008)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WKewxrWhGGs3ZLvoPO2dE2oxdrgA7IgJYTYymCSth5H7TkqShnBTZ7R/bk9fyeEr4oI2M/e+rxMZuD6dkTy1bEyelQiaVKZQbeosVXlsdIjdlxjxkkdQ1XAAmfNZV8MykkNadnO0L2FxaIbbwwjyRun3LAJjo3oeZ1hXtC3dIW1zFHzt6tiZG37JYsDYjMxSDv9HSJBGKrg9ezruuX/AAg22PTrzw8MUhhhzY21Aik4XRAAQbeKIQ2pvFo7IAVCZAe/wWjU+oncdWaO6SWm6e9OAOb61Fd1H0gHSRRECqyRSze9PJxWwmSR1P6RCxR1vBthAOVy7V3cmacu7VJKmeD+caKYPFtc7/w82gzW9ceZee/r/ExZPywOlI8fD0bONw+MPrexWvVptfFlzsxvWQoeR4TSWZryv7wt4ZpWkRibv0vHSrrHkPLvvb0uuk5b1n48RkLukegk6OE8b4bZgcW187UvmwuqmCP5wJK431/kSURR/X4A2tOcl1FqW8cB+Olw4RokKCfq+2nxnf1fFF2k3CNLdi1nhV0JoyhRS74GvbZEliybEHRfNuFiruzAXjNEOsurePfMM2odNn8xTnrfMs1xQIfIFYVBZL3qQmBKmHfh7a+K2oDEoZ4CH6+lipvHn8ZsuVkCjCiZRpkgWwQ== x-ms-exchange-transport-forked: True Content-ID: <1FB083EF8F835C47A2FB162A0AE9E23C@namprd11.prod.outlook.com> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2999.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9643038c-5b3c-408c-f837-08d871cf56ad X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 12:30:59.7626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oJ5rDcmzBrUFemL+a6x4dZ30VJJLOodWx7yiliBBnXqWR8eTU12VbENCjN0rPh1hhdUvnsc2pgkUqs+wT41kr4oXeWXTlloBeKN/VMrwwlM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4276 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201016_083107_223163_7C090C7C X-CRM114-Status: GOOD ( 26.05 ) 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: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, sakari.ailus@iki.fi, laurent.pinchart@ideasonboard.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 12.10.2020 16:04, Jacopo Mondi wrote: > Hello, > just my 2 cents, as I've noticed this patch skimming through the > list > > On Mon, Oct 12, 2020 at 07:19:43AM +0000, Eugen.Hristev@microchip.com wrote: >> On 11.10.2020 00:17, Laurent Pinchart wrote: >>> Hi Eugen, >>> >>> Thank you for the patch. >> >> Hi, >> >> Thank you for your review, >> >>> >>> On Wed, Aug 26, 2020 at 09:51:40AM +0300, Eugen Hristev wrote: >>>> Add bindings documentation for Microchip CSI2 Demultiplexer controller. >>>> >>>> CSI2DC is a demultiplexer from Synopsys IDI interface specification to >>>> parallel interface connection or direct memory access. >>>> >>>> Signed-off-by: Eugen Hristev >>>> --- >>>> Changes in v3: >>>> - Removed some text from description, as it was explained in the schema >>>> - fixed other things as per Rob's review >>>> - moved some text inside the schema, like the clock description >>>> >>>> Changes in v2: >>>> - fixed warnings reported by dt_binding_check >>>> >>>> .../bindings/media/microchip,csi2dc.yaml | 174 ++++++++++++++++++ >>>> 1 file changed, 174 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >>>> new file mode 100644 >>>> index 000000000000..b4c1b8800a3b >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >>>> @@ -0,0 +1,174 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Microchip CSI2 Demux Controller (CSI2DC) >>>> + >>>> +maintainers: >>>> + - Eugen Hristev >>>> + >>>> +description: >>>> + CSI2DC - Camera Serial Interface 2 Demux Controller >>>> + >>>> + CSI2DC is a hardware block that receives incoming data from an IDI interface >>>> + and filters packets based on their data type and virtual channel identifier, >>>> + then converts the byte stream into a cross clock domain to a pixel stream >>>> + to a parallel interface that can be read by a sensor controller. >>>> + >>>> + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe >>>> + is connected to a sensor controller and the data pipe is accessible >>>> + as a DMA slave port to a DMA controller. >>>> + >>>> + CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit >>>> + IDI interface. The connected endpoint must be a IDI interface compatible >>>> + device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface >>>> + connection as sink pad. >>>> + For media entity and endpoints please refer to the bindings defined in >>>> + Documentation/devicetree/bindings/media/video-interfaces.txt. >>>> + For Synopsys IDI interface please refer to >>>> + Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt >>>> + >>>> + CSI2DC supports one 'port' node as sink pad with parallel interface. This is >>>> + called video pipe. >>>> + This port has an 'endpoint' can then be used as a source pad for another >>>> + controller (next in pipeline). >>>> + Please refer to the bindings defined in >>>> + Documentation/devicetree/bindings/media/video-interfaces.txt. >>>> + >>>> + CSI2DC also supports direct access to the data through AHB, via DMA channel, >>>> + called data pipe. >>>> + Because of this, the sink 'port' child node (second) is not mandatory. >>>> + If the sink 'port' child node is missing, only data pipe is available. >>>> + >>>> +properties: >>>> + compatible: >>>> + const: microchip,sama7g5-csi2dc >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + clocks: >>>> + maxItems: 2 >>>> + >>>> + clock-names: >>>> + description: >>>> + CSI2DC must have two clocks to function correctly. One clock is the >>>> + peripheral clock for the inside functionality of the hardware block. >>>> + This is named 'pclk'. The second clock must be the cross domain clock, >>>> + in which CSI2DC will perform clock crossing. This clock must be fed >>>> + by the next controller in pipeline, which usually is a sensor controller. >>>> + Normally this clock should be given by this sensor controller who >>>> + is also a clock source. This clock is named 'scck', sensor controller clock. >>>> + items: >>>> + - const: pclk >>>> + - const: scck >>>> + >>>> + microchip,clk-gated: >>>> + type: boolean >>>> + description: >>>> + If present, indicates that the clock is gated. >>>> + Otherwise, the clock is free-running. >>> >>> I don't think this belongs to the DT bindings, it should instead be >>> queried from the source subdev at runtime. >> >> If this should be queried, do you know what is the v4l2 mechanism to >> query such information ? >> The subdevice is connected through a port interface to this device, so >> it was natural for me to fully describe the interface in the devicetree >> port description >> Hi, Thanks for helping, > > Is this property describing the CSI-2 clock continuous, non-continuous > mode configuration, or did I mis-interpreted it ? I think so. This is a setting inside the csi2dc regarding clock. If we can obtain it from pads operations, then it's good, but the question is, if the devices can provide this or not ? > > We added support for retrieving run-time configuration of the media > bus with the get_mbus_config pad operations recently. Among the > configuration flags for MBUS_CSI2_DPHY there are inded CONTINUOUS and > NON_CONTINUOUS clock flags. > >>> >>>> + >>>> + microchip,inter-line-delay: >>>> + allOf: >>>> + - $ref: /schemas/types.yaml#/definitions/uint32 >>>> + - minimum: 1 >>>> + - maximum: 16 >>>> + default: 16 >>>> + description: >>>> + Indicates how many clock cycles should be introduced between each line. >>> >>> This also sounds like a configuration parameter. How does one compute >>> the right value for this ? >> >> I think this is a delay that can be added inside the hardware block, >> depending on the interface speed and bandwidth. I will try to understand >> more details from the hardware design and come back with a more detailed >> answer. >> Regarding this, I will remove it. Our design team advised to have a hardcoded value for this product. >>> >>>> + >>>> + port@0: >>>> + type: object >>>> + description: >>>> + Input port node, single endpoint describing the input pad. >>>> + >>>> + properties: >>>> + reg: >>>> + const: 0 >>>> + >>>> + endpoint: >>>> + type: object >>>> + >>>> + properties: >>>> + remote-endpoint: true >>>> + >>>> + required: >>>> + - remote-endpoint >>>> + >>>> + additionalProperties: false >>>> + >>>> + additionalProperties: false >>>> + >>>> + port@1: >>>> + type: object >>>> + description: >>>> + Output port node, single endpoint, describing the output pad. >>>> + >>>> + properties: >>>> + '#address-cells': >>>> + const: 1 >>>> + >>>> + '#size-cells': >>>> + const: 0 >>>> + >>>> + reg: >>>> + const: 1 >>>> + >>>> + patternProperties: >>>> + "^endpoint@[0-3]$": >>>> + type: object >>>> + >>>> + properties: >>>> + reg: >>>> + enum: [0, 1, 2, 3] >>>> + description: virtual channel for the endpoint >>> >>> The virtual channel used by the source is also something that needs to >>> be queried from the source at runtime, it doesn't belong to this >>> binding. >> >> The same question as for the gated clock configuration. How can we use >> v4l2 subdevice API to obtain such information from the subdevice? And if >> the subdevice does not offer such information ? > > I think the subdev driver should be instrumented to report it instead of > hard-coding the information in DT which should be otherwise updated > depending on which sensor is connected to the board. Does it make > sense to you ? It does, but then, it won't work unless connected to instrumented subdevices. Which is not really something I would do, since it would completely limit the usability. Do you have any example on how to get the virtual id from the subdev ? Thanks again, Eugen > > Cheers > j > >> >> Thanks again, >> >> Eugen >>> >>>> + >>>> + remote-endpoint: true >>>> + >>>> + required: >>>> + - remote-endpoint >>>> + - reg >>>> + >>>> + additionalProperties: false >>>> + >>>> + additionalProperties: false >>>> + >>>> +required: >>>> + - compatible >>>> + - reg >>>> + - clocks >>>> + - clock-names >>>> + - port@0 >>>> + >>>> +examples: >>>> + - | >>>> + csi2dc@e1404000 { >>>> + compatible = "microchip,sama7g5-csi2dc"; >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + reg = <0xe1404000 0x500>; >>>> + clocks = <&pclk>, <&scck>; >>>> + clock-names = "pclk", "scck"; >>>> + >>>> + port@0 { >>>> + reg = <0>; /* must be 0, first child port */ >>>> + csi2dc_in: endpoint { /* input from IDI interface */ >>>> + remote-endpoint = <&csi2host_out>; >>>> + }; >>>> + }; >>>> + >>>> + port@1 { >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + reg = <1>; /* must be 1, second child port */ >>>> + csi2dc_out: endpoint@2 { >>>> + reg = <2>; /* virtual channel identifier */ >>>> + remote-endpoint = <&xisc_in>; /* output to sensor controller */ >>>> + }; >>>> + }; >>>> + }; >>>> + >>>> +... >>> >>> -- >>> Regards, >>> >>> Laurent Pinchart >>> >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel