Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1106699ybg; Thu, 4 Jun 2020 00:53:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYa7wK9H2tgVieGrPceXton+QVRQzYD+2AMOb7B96MKkqPLrUFLh3OOY3o4f6lYiBG80h3 X-Received: by 2002:a17:906:f46:: with SMTP id h6mr2741492ejj.144.1591257195686; Thu, 04 Jun 2020 00:53:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591257195; cv=none; d=google.com; s=arc-20160816; b=p458Yodr+PQ3UMqIa0x7jj9ASRoVQCyRcma5HF37OnIH1q9YpmQqH7metP1CjRSplJ 7jbNo4GTVDAUhF7DLb9j/iUBMq/55wUl54NaaUbk2n0W6EgMBrEHkylMu31gvlr8iXDV w88tGYEvMuIfys4IqK5AMLI4+k3b2eXVntpZ0KvPGE1LVaM+JvlS8dlyKqxt8WyTuJsz otx57jjFdt8mcTBM24mdg78uiuwhO+PsI5eKOa5H3PCVH02oS7ro8CWRW/Vb3xt1TtpO aOr7+qtR7jr2F83kjnBsfTy+TKbPKOeOa/Lt1RtfVxSofEwMLsN2//6KmXXQiirCWwWZ jgsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=rZh3eltCaqpy2G/2HDI5roFqEwZX8ODx17iQOq061Lc=; b=ZXtVenqOO6MquGbf9d73qrZHgJoNNhOe2uDmAHya/TZBcoFn2dKOdfDCQt4NWppDwC PQ0UNTXNBhe1dZXWuz/Ph/Wc4ddBUIVq2rDM5iEJbXzeEISNOGgPTKerK9NkKdt7eN1d CYrkLC1ffmz5SiNgdVt9qfTA4F9mNPudgtby90OLP1Cmob9HpcnGZohlc55w+Si14/Y/ yb+6qPGLV6eJoUYTnO6+8pCVwWD/QqoKv2BNo9Klh2RXJ0hfZ1H4Zpr4xu+YvwvqdWAQ rcWtlJ5Ml9kGncZ0SoDga6RfRTm2BPZ7jP29AOXKi+pAIFXkQZiQTuoRWGLhH/R7I21J 1Kdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=MeXPWyDH; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e9si1145282edn.18.2020.06.04.00.52.51; Thu, 04 Jun 2020 00:53:15 -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; dkim=pass header.i=@kernel.org header.s=default header.b=MeXPWyDH; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727886AbgFDHTI (ORCPT + 99 others); Thu, 4 Jun 2020 03:19:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:51642 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726987AbgFDHTH (ORCPT ); Thu, 4 Jun 2020 03:19:07 -0400 Received: from localhost (unknown [122.179.53.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3DFF3206DC; Thu, 4 Jun 2020 07:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591255146; bh=nCkSZ5YI8jHz/QYFJheERHTTJHELbWC5BLEjucaQ9dc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MeXPWyDH7J9jG4fhQpfPg/I89NkjW170cIj6TEKj1Gy8E4bbhSDxec5FPn/jXuQGj AKd6o3Tnj2qDlAjxOEMXCm7+Hemp0D6eMu/N56HGSceFVM4rfcLe3+V93f/AAh6JqH iDEzrbcE86JD4QauX+JMe4LHC+a3tNZ0LCc8Tpr8= Date: Thu, 4 Jun 2020 12:48:59 +0530 From: Vinod Koul To: Laurent Pinchart Cc: Daniel Vetter , David Airlie , Rob Clark , linux-arm-msm@vger.kernel.org, Bjorn Andersson , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec , Rob Herring , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH 2/3] dt-bindings: display: bridge: Add documentation for LT9611 Message-ID: <20200604071859.GD3521@vkoul-mobl> References: <20200513100533.42996-1-vkoul@kernel.org> <20200513100533.42996-3-vkoul@kernel.org> <20200528014837.GD4670@pendragon.ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200528014837.GD4670@pendragon.ideasonboard.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, Sorry for late reply, I was out last week. On 28-05-20, 04:48, Laurent Pinchart wrote: > > + > > + interrupts: > > + maxItems: 1 > > + description: interrupt line for the chip > > I think you could drop the descriptions for the reg and interrupt > properties, they don't add much. Sure, will do > > + reset-gpios: > > + maxItems: 1 > > + description: GPIO connected to active high RESET pin. > > + > > + vdd-supply: > > + description: Regulator for 1.8V MIPI phy power. > > + > > + vcc-supply: > > + description: Regulator for 3.3V IO power. > > + > > + ports: > > + type: object > > + > > + properties: > > + "#address-cells": > > + const: 1 > > + > > + "#size-cells": > > + const: 0 > > + > > + port@0: > > + type: object > > + additionalProperties: false > > + > > + description: | > > + HDMI port for HDMI output > > The usual practice is to have the input ports first, followed by the > output ports. Is there a reason not to follow that rule ? I was not aware of this rule, is it documented somewhere? Nevertheless will update.. > > + > > + properties: > > + reg: > > + const: 0 > > + > > + patternProperties: > > + endpoint: > > If you want to use patternProperties, this should be > > "^endpoint@[0-9]+$": > > (including the quotes). Same below. Ok > > > + type: object > > + additionalProperties: false > > + > > + properties: > > + remote-endpoint: true > > How about > > remote-endpoint: > $ref: /schemas/types.yaml#/definitions/phandle > > and the same below ? Ok > > You also need a reg property if multiple endpoints are present. Will update > > > + > > + required: > > + - reg > > + > > + port@1: > > + type: object > > + additionalProperties: false > > + > > + description: | > > + MIPI port-1 for MIPI input > > + > > + properties: > > + reg: > > + const: 1 > > + > > + patternProperties: > > + endpoint: > > + type: object > > + additionalProperties: false > > + > > + properties: > > + remote-endpoint: true > > + > > + required: > > + - reg > > + > > + port@2: > > + type: object > > + additionalProperties: false > > + > > + description: | > > + MIPI port-2 for MIPI input > > A description of how the two MIPI inputs differ would be useful. In > particular, are both mandatory, or is it valid to connect only one of > the two ? If using a single input is supported, can it be either, or > does it have to be the first one ? When using both inputs, what should > be connected to them ? Sure I will add details. port-1 is mandatory and port-2 optional. port-2 is used in combination with port-1 to drive displays for higher resolution like 4k > > + > > + properties: > > + reg: > > + const: 2 > > + > > + patternProperties: > > + endpoint: > > + type: object > > + additionalProperties: false > > + > > + properties: > > + remote-endpoint: true > > + > > + required: > > + - reg > > + > > + required: > > + - "#address-cells" > > + - "#size-cells" > > + - port@0 > > + - port@1 > > + > > +required: > > + - compatible > > + - reg > > + - interrupts > > + - vdd-supply > > + - vcc-supply > > + - ports > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include > > + #include > > + > > + i2c10 { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + lt9611_codec: hdmi-bridge@3b { > > Please drop unused labels. ok > > > + compatible = "lontium,lt9611"; > > + reg = <0x3b>; > > + > > + reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>; > > + interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>; > > + > > + vdd-supply = <<9611_1v8>; > > + vcc-supply = <<9611_3v3>; > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + port@0 { > > + reg = <0>; > > + lt9611_out: endpoint { > > + remote-endpoint = <&hdmi_con>; > > + }; > > + }; > > + > > + port@1 { > > + reg = <1>; > > + lt9611_a: endpoint { > > + remote-endpoint = <&dsi0_out>; > > + }; > > + }; > > + > > + port@2 { > > + reg = <2>; > > + lt9611_b: endpoint { > > + remote-endpoint = <&dsi1_out>; > > + }; > > + }; > > + }; > > + }; > > + }; > > It's customary to end YAML schema files with ... on a separate line. Will update Thanks for the review -- ~Vinod