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=-6.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 738AAC2D0A8 for ; Wed, 23 Sep 2020 17:15:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1945721D43 for ; Wed, 23 Sep 2020 17:15:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="KwhKedNv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726599AbgIWRPf (ORCPT ); Wed, 23 Sep 2020 13:15:35 -0400 Received: from fllv0016.ext.ti.com ([198.47.19.142]:47050 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726596AbgIWRPf (ORCPT ); Wed, 23 Sep 2020 13:15:35 -0400 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 08NHFKXo087475; Wed, 23 Sep 2020 12:15:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1600881320; bh=r8HOyXiGU54STKU6S811Il3oIJwaV6yhgGzfkd2uQ10=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=KwhKedNvEiP8fYI6JZEmDGiZS/WagcavMjkPdA6YxtQD/mwyG+vZcquVV1fHIRYIa 9yVGGzRAbokDSoRUgM8OejJhG1o/bqcj5Dflm2nmoFDqyjR2HnK2zoXOmNH7Alz2P/ 1lzoysO8xely2tzEp/rslecey5B9NOyoRpnziGS0= Received: from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 08NHFKLV037525 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 23 Sep 2020 12:15:20 -0500 Received: from DFLE112.ent.ti.com (10.64.6.33) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Wed, 23 Sep 2020 12:15:19 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE112.ent.ti.com (10.64.6.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Wed, 23 Sep 2020 12:15:19 -0500 Received: from [192.168.2.10] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 08NHFHWR115783; Wed, 23 Sep 2020 12:15:17 -0500 Subject: Re: [PATCHv2] dt-bindings: dp-connector: add binding for DisplayPort connector To: Rob Herring CC: , , David Airlie , Daniel Vetter , Laurent Pinchart , Andrzej Hajda , Neil Armstrong , Swapnil Kashinath Jakhade References: <20200917055210.22868-1-tomi.valkeinen@ti.com> <20200923161712.GA836725@bogus> From: Tomi Valkeinen Message-ID: <04d93618-12b1-d8f5-ece5-0f87e644d52e@ti.com> Date: Wed, 23 Sep 2020 20:15:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200923161712.GA836725@bogus> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Rob, On 23/09/2020 19:17, Rob Herring wrote: >> * No eDP. There's really no "eDP connector", as it's always a custom >> made connection between the DP and the DP panel. So possibly there is >> no need for edp-connector binding, but even if there is, I don't want >> to guess what it could look like, and could it be part of the >> dp-connector binding. > > I don't think that's true. Do an image search for 'edp pinout'. AFAICT, > there's 2 lane 30 pin and 4 lane 40 pin. One image says 'Table 5-3 in > eDP v1.2'. Of course, I'm sure there's custom ones too. From a binding > perspective, we probably don't care about the differences, but just need > to be able to describe HPD, backlight power, enable, and pwm, and LCD > power. That's true. The eDP spec lists 4 different standard pinouts (how strictly those are followed, I have no idea). But it does not define a connector or a cable. And afaik eDP is defined to be not user-detachable. I think from the binding perspective the connectors present in the dts files are user-visible connectors, meant for plugging in and out. The connector node is the "end of the chain". And non user-detachable ones (like MIPI DPI) do not have a connector in the dts, but just the video source and the panel linked together, and the panel is the end of the chain. My thinking was that eDP is similar to MIPI DPI, and that we always define the eDP panel in the dts too. But I guess that might not be the case, as eDP does have all the bells and whistles to fully detect the panel. Although can it do all the probing needed for backlight and touch... And even then, should we have a generic-epd-panel present in the dts, or just a connector... I don't know. So as I said, I'd rather leave eDP out for now (and you agreed, so no disagreement =). I think we can later extend this binding, or if eDP just doesn't seem to fit into this, we can create a fully separate binding for eDP. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki