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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7BFB7C46467 for ; Tue, 3 Jan 2023 11:52:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230006AbjACLwE (ORCPT ); Tue, 3 Jan 2023 06:52:04 -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 Precedence: bulk List-ID: X-Mailing-List: devicetree@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