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=-5.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 B87B1C433DB for ; Thu, 4 Feb 2021 18:48:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 69CCA64E3F for ; Thu, 4 Feb 2021 18:48:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239378AbhBDSsh (ORCPT ); Thu, 4 Feb 2021 13:48:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239329AbhBDSrz (ORCPT ); Thu, 4 Feb 2021 13:47:55 -0500 Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77299C061786 for ; Thu, 4 Feb 2021 10:46:59 -0800 (PST) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4DWnb50SKhz1s479; Thu, 4 Feb 2021 19:46:57 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4DWnb46ppsz1t6pp; Thu, 4 Feb 2021 19:46:56 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id SR-7xsAzxyQK; Thu, 4 Feb 2021 19:46:55 +0100 (CET) X-Auth-Info: bxnTP5xuJO9A07TpN758S5k87NX4EzxiN/09vLEQ3nY= Received: from [IPv6:::1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 4 Feb 2021 19:46:55 +0100 (CET) Subject: Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 bindings To: Doug Anderson Cc: dri-devel , Laurent Pinchart , Linus Walleij , Sam Ravnborg , Stephen Boyd , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" References: <20210130181014.161457-1-marex@denx.de> From: Marek Vasut Message-ID: <0a92a80a-e4cb-2e3f-326e-1250a2787258@denx.de> Date: Thu, 4 Feb 2021 19:46:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 2/4/21 7:38 PM, Doug Anderson wrote: > Hi, Hi, [...] >>>> +properties: >>>> + compatible: >>>> + const: ti,sn65dsi83 >>>> + >>>> + reg: >>>> + const: 0x2d >>>> + >>>> + enable-gpios: >>>> + maxItems: 1 >>>> + description: GPIO specifier for bridge_en pin (active high). >>> >>> I see two regulators: vcc and vcore. Shouldn't those be listed? >> >> Those are not implemented and not tested, so if someone needs them later >> on, they can be added then. > > Sure. I guess it can go either way. For the regulator it'd the kind > of thing that's super easy to add support for and hard to mess up. If someone can test those regulators (I might be able to, in next revision of hardware, we'll see), then this can be added. >>>> + endpoint: >>>> + type: object >>>> + additionalProperties: false >>>> + properties: >>>> + remote-endpoint: true >>>> + data-lanes: >>>> + description: array of physical DSI data lane indexes. >>> >>> The chip doesn't allow for arbitrary remapping here, right? So you're >>> just using this as the official way to specify the number of lanes? I >>> guess the only valid values are: >>> >>> <0> >>> <0 1> >>> <0 1 2> >>> <0 1 2 3> >> >> Shouldn't that be <1 2 3 4> ? > > The data manual refers to the channels starting at 0, so if it's > arbitrary that seems a better way to go? Either way is OK, but before I change this, I would like some confirmation this enumeration really is arbitrary. >>> In sn65dsi86 we attempted to enforce that a valid option was selected >>> for the output lanes. Could you do something similar? If nothing >>> else adding a description of the valid options would be good. >> >> I saw the binding, but I was under the impressions the DSI86 can do lane >> reordering, isn't that the case ? Maybe I misunderstood it. > > DSI86 can reorder the output lanes quite flexibly. It can't reorder > the input lanes, though. The eDP ones ? OK >> But yes, if you have a suggestion how to make a non-cryptic list of >> those four lane mapping options, please do share this info. > > I doubt I can write this correctly without a whole lot of futzing / > messing, but maybe something like: > > data-lanes: > oneOf: > - items: > - 0 > - items: > - 0 > - 1 > - items: > - 0 > - 1 > - 2 > - items: > - 0 > - 1 > - 2 > - 3 > I was hoping for some better syntax. Maybe there is one ? 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=-5.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 8E2D8C433E6 for ; Thu, 4 Feb 2021 19:34:54 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 38B3864F38 for ; Thu, 4 Feb 2021 19:34:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38B3864F38 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9FFD06EE36; Thu, 4 Feb 2021 19:34:38 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by gabe.freedesktop.org (Postfix) with ESMTPS id 869E589C51 for ; Thu, 4 Feb 2021 18:46:59 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4DWnb50SKhz1s479; Thu, 4 Feb 2021 19:46:57 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4DWnb46ppsz1t6pp; Thu, 4 Feb 2021 19:46:56 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id SR-7xsAzxyQK; Thu, 4 Feb 2021 19:46:55 +0100 (CET) X-Auth-Info: bxnTP5xuJO9A07TpN758S5k87NX4EzxiN/09vLEQ3nY= Received: from [IPv6:::1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 4 Feb 2021 19:46:55 +0100 (CET) Subject: Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 bindings To: Doug Anderson References: <20210130181014.161457-1-marex@denx.de> From: Marek Vasut Message-ID: <0a92a80a-e4cb-2e3f-326e-1250a2787258@denx.de> Date: Thu, 4 Feb 2021 19:46:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mailman-Approved-At: Thu, 04 Feb 2021 19:34:32 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , dri-devel , Stephen Boyd , Laurent Pinchart , Sam Ravnborg Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2/4/21 7:38 PM, Doug Anderson wrote: > Hi, Hi, [...] >>>> +properties: >>>> + compatible: >>>> + const: ti,sn65dsi83 >>>> + >>>> + reg: >>>> + const: 0x2d >>>> + >>>> + enable-gpios: >>>> + maxItems: 1 >>>> + description: GPIO specifier for bridge_en pin (active high). >>> >>> I see two regulators: vcc and vcore. Shouldn't those be listed? >> >> Those are not implemented and not tested, so if someone needs them later >> on, they can be added then. > > Sure. I guess it can go either way. For the regulator it'd the kind > of thing that's super easy to add support for and hard to mess up. If someone can test those regulators (I might be able to, in next revision of hardware, we'll see), then this can be added. >>>> + endpoint: >>>> + type: object >>>> + additionalProperties: false >>>> + properties: >>>> + remote-endpoint: true >>>> + data-lanes: >>>> + description: array of physical DSI data lane indexes. >>> >>> The chip doesn't allow for arbitrary remapping here, right? So you're >>> just using this as the official way to specify the number of lanes? I >>> guess the only valid values are: >>> >>> <0> >>> <0 1> >>> <0 1 2> >>> <0 1 2 3> >> >> Shouldn't that be <1 2 3 4> ? > > The data manual refers to the channels starting at 0, so if it's > arbitrary that seems a better way to go? Either way is OK, but before I change this, I would like some confirmation this enumeration really is arbitrary. >>> In sn65dsi86 we attempted to enforce that a valid option was selected >>> for the output lanes. Could you do something similar? If nothing >>> else adding a description of the valid options would be good. >> >> I saw the binding, but I was under the impressions the DSI86 can do lane >> reordering, isn't that the case ? Maybe I misunderstood it. > > DSI86 can reorder the output lanes quite flexibly. It can't reorder > the input lanes, though. The eDP ones ? OK >> But yes, if you have a suggestion how to make a non-cryptic list of >> those four lane mapping options, please do share this info. > > I doubt I can write this correctly without a whole lot of futzing / > messing, but maybe something like: > > data-lanes: > oneOf: > - items: > - 0 > - items: > - 0 > - 1 > - items: > - 0 > - 1 > - 2 > - items: > - 0 > - 1 > - 2 > - 3 > I was hoping for some better syntax. Maybe there is one ? _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel