Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp11739153rwl; Tue, 3 Jan 2023 04:08:10 -0800 (PST) X-Google-Smtp-Source: AMrXdXtqfh50arwMCixO+qK+Jak44ss7feH1CF5656b6MPP97iF702CTbKnmwI0cV/E8YKo32CYs X-Received: by 2002:a05:6402:538c:b0:472:f7c1:361 with SMTP id ew12-20020a056402538c00b00472f7c10361mr38468280edb.29.1672747690514; Tue, 03 Jan 2023 04:08:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672747690; cv=none; d=google.com; s=arc-20160816; b=zuD6Dc0Qjq14//foyWLY3I0n6z2aLdwQLQYrVcCRu9MTPuh0PEEHzWxglz+cDmb9uR xnwMyJi8ukxmxGwr5nqstGeyjRWvPdHGfNmLt4wR7iI7sAupISI5pvWLJANrFVwgvxFZ qmRVxlXEx/vZSJCTch3tlBvgdpsyxl4FxmUkwT02bKc7Aywz8RE6sn+I1RQQfn8zd1oo EQHEYUJf+0S13bGQr4e1CaFkGI+V2S4upHkMrGXR+hL5rAEvrFYXKEgr9qw8vcJhitr9 uhNFrrfFeZZd/KDW6xl9rh3eaaTngDDqPqg847G4k3Rtm3qXObxwxyYlr7Pue/zJJz/S x0XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=KWVfl2mXdavSJiJpzPpLv/sLBgbnODRVaY01wR+6ZTw=; b=CokQ3L4TYIfCGMkSJt6sGs8fbREEjT454Vyyz23nEIIRe1l6g8D6Ze5wKy/HSB6EGG wtgRV10Ufj3c0jS8XHIcxcMTjOqPSrlNe9g8qZVoJZWHxUBuD5VVbATHb18kdhGjis5T Th3IW+dWGWVZK1PDxiu/NKaOJOMIEMW3SA8AQQYw5hNfjcTsMdlUmDCRD7AQBUbKKSaK PowX4QbhN7aJzVAOPm7Qxh7QcWk5pAjW+ayKH6DJXYKORPenkQ40PqpIE0YyHRxToBB1 u/YRp1Cb9CtMo86bPKDoOt7kKFh9XeEvXhwo6GiJ2NAdhkpxfISwUINFk5SuXVf5R7gf /M7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=gG9UbXrr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji5-20020a170907980500b007addbdb9fbbsi29005236ejc.558.2023.01.03.04.07.56; Tue, 03 Jan 2023 04:08:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=gG9UbXrr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237483AbjACLwH (ORCPT + 60 others); Tue, 3 Jan 2023 06:52:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237496AbjACLvx (ORCPT ); Tue, 3 Jan 2023 06:51:53 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E922D6589; Tue, 3 Jan 2023 03:51:51 -0800 (PST) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 659896602CE7; Tue, 3 Jan 2023 11:51:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1672746709; bh=6chUOuhMbPwhQBYMQBmnbgN9yec/HXnOChceMVGoqic=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gG9UbXrrgSVeMwXELIxIuwXvRhEU35Fb89KnSK5SmwjjhQ9O3wB7j+BDd3lS8jkhk IXgHZgJELX2+QlzUlyCHHifndDkJ/2C1gc/F9rNweTIPXZBgR/cStGIXLdTInfoLBt fqAq68aomRHY5F6Agw7R+3syaZLI8BGtsv5gRrLWVFzk/aOzdA/QNPtdMRApVusFr8 wja6kGf3ePZt9CQfJkUIc1/xZxeB5SrDZ5kqIlna9JDTABicClm3FJzZX0XJIsahmP JAvAje3oGDflWCSLKcHLAvKvlArcK3wtj7nt16E5ROG0/Em2+bgbSRcE6Rq7SdWvIW i1+Njg4yfhRbQ== Message-ID: <09f1ca83-c7d5-a186-6fa6-09cdd7a0b9cc@collabora.com> Date: Tue, 3 Jan 2023 12:51:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel Content-Language: en-US To: Aradhya Bhatia , Rob Herring , Krzysztof Kozlowski , Tomi Valkeinen , Jyri Sarha , David Airlie , Daniel Vetter , Laurent Pinchart , Thierry Reding , Sam Ravnborg , Maxime Ripard , Liam Girdwood , Mark Brown , Lad Prabhakar , Paul Walmsley , Palmer Dabbelt , Albert Ou , Matthias Brugger , Guo Ren Cc: DRI Development List , Devicetree List , Linux Kernel List , Linux RISC-V List , Linux ARM Kernel List , Linux Mediatek List , Linux C-SKY Arch List , Nishanth Menon , Vignesh Raghavendra , Rahul T R , Devarsh Thakkar , Jai Luthra , Jayesh Choudhary References: <20230103064615.5311-1-a-bhatia1@ti.com> <20230103064615.5311-4-a-bhatia1@ti.com> From: AngeloGioacchino Del Regno In-Reply-To: <20230103064615.5311-4-a-bhatia1@ti.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 03/01/23 07:46, Aradhya Bhatia ha scritto: > Dual-link LVDS interfaces have 2 links, with even pixels traveling on > one link, and odd pixels on the other. These panels are also generic in > nature, with no documented constraints, much like their single-link > counterparts, "panel-lvds". > > Add a new compatible, "panel-dual-lvds", and a dt-binding document for > these panels. > > Signed-off-by: Aradhya Bhatia > --- > .../display/panel/panel-dual-lvds.yaml | 157 ++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 158 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml > new file mode 100644 > index 000000000000..88a7aa2410be > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml > @@ -0,0 +1,157 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Generic Dual-Link LVDS Display Panel > + > +maintainers: > + - Aradhya Bhatia > + - Thierry Reding > + > +description: | > + A dual-LVDS interface is a dual-link connection with the even pixels > + traveling on one link, and the odd pixels traveling on the other. > + > +allOf: > + - $ref: panel-common.yaml# > + - $ref: /schemas/display/lvds.yaml/# > + > +properties: > + compatible: > + oneOf: > + - items: > + - enum: > + - lincolntech,lcd185-101ct > + - microtips,13-101hieb0hf0-s > + - const: panel-dual-lvds > + - const: panel-dual-lvds > + > + ports: > + $ref: /schemas/graph.yaml#/properties/ports > + > + properties: > + port@0: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: The sink for first set of LVDS pixels. > + > + properties: > + dual-lvds-odd-pixels: > + type: boolean > + > + dual-lvds-even-pixels: > + type: boolean > + > + oneOf: > + - required: [dual-lvds-odd-pixels] One question: why do we need a "panel-dual-lvds" compatible? A Dual-LVDS panel is a LVDS panel using two ports, hence still a panel-lvds. If you're doing this to clearly distinguish, for human readability purposes, single-link vs dual-link panels, I think that this would still be clear even if we use panel-lvds alone because dual-link panels, as you wrote in this binding, does *require* two ports, with "dual-lvds-{odd,even}-pixels" properties. So... the devicetree node would look like this: panel { compatible = "vendor,panel", "panel-lvds"; .... ports { port@0 { ..... -> dual-lvds-odd-pixels <- } port@1 { ..... -> dual-lvds-even-pixels <- }; }; }; > + - required: [dual-lvds-even-pixels] ...Though, if you expect dual-lvds panels to get other quirks in the future, that's a whole different story and you may actually need the panel-dual-lvds compatible. Regards, Angelo