Message ID | 20230316140823.234263-2-j-choudhary@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp526102wrt; Thu, 16 Mar 2023 07:51:58 -0700 (PDT) X-Google-Smtp-Source: AK7set9QEWAiSeygsi+lshROVX4Ayq7hxCASMFRCrAlNgBeqeIJ6cPMa8vAMrHqhXxQRUqIvnQxe X-Received: by 2002:a17:903:d1:b0:1a1:a273:1812 with SMTP id x17-20020a17090300d100b001a1a2731812mr33689plc.45.1678978318579; Thu, 16 Mar 2023 07:51:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678978318; cv=none; d=google.com; s=arc-20160816; b=mY09UxZkoGycStDH4OpkdUXwHtgF81UXwvkibBbA/1rHBGxnPox7f8o+UlQSzElaT7 bDKAZVPSiP9J+7Pu4ok3RKGbY27E75rXQ00C+3c/Q+phf3E2CRokh2ezljIkLkJsNXPP YQ5Y4SjBai/2+/tkPEOqty/0Jme5tUaVyriONGgEPR3V+9tVjMwUYi5PlmDXllDCn8ZD euM8iJ1GUvQ/Q/m8L1LsI5msncYVYjY06EPfoAUjTWEJaBkPkawLwIJ7ouEUo0NU3/8X FZ4f7URVgg22RZC6icycduhn4Faa5mUk3//eJlJIu/WCAMT5KBP1CHmSgy+JNOWN3JiV vehw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=DFCetOEU3TZe5LK6V2//inRuqcocQaj/wwz3OvKoFtg=; b=AyCFw0uYUtgQvQ1Rdp+y8iDoTCmMdOMaoVIzKNG96jE8gcz6fec4Zzezrea/MnGmXi UetNO8F1FGau0f2CMpfWzoSAEtJmiO8xXvdAlWSWF/uAxizFHR48uXBQyv/rGG5L7KiJ BiTrCtsmHwMfm8F69HCbiyZqx3zIlFtiUObTDmJVpYmfL1GEiq4r4+LsLvnllTz6b4VY cTgsy7Q98IRoJldSZoJOmuE0zYAeuHBCnsI2TKIdu31dkJZ/8I9MIg3oz5ATT2HTFwgq R0Hy1K8awvGCf96bdbJGWSPcsvacTXfT/LAlgqhC23gFbOPmKTX5yidUZ7m0eT8/98mR lz/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=qLNvjAoH; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c10-20020a170902d48a00b001994a4f9d34si6233795plg.145.2023.03.16.07.51.43; Thu, 16 Mar 2023 07:51:58 -0700 (PDT) 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=@ti.com header.s=ti-com-17Q1 header.b=qLNvjAoH; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230344AbjCPOJN (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Thu, 16 Mar 2023 10:09:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230516AbjCPOJJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Mar 2023 10:09:09 -0400 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E9782410E; Thu, 16 Mar 2023 07:09:06 -0700 (PDT) Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 32GE8RD9042793; Thu, 16 Mar 2023 09:08:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1678975707; bh=DFCetOEU3TZe5LK6V2//inRuqcocQaj/wwz3OvKoFtg=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=qLNvjAoHPP6VojLtzH0LEfxpflcyfpac0Y4qKt0CgyrFCEW4pDUGVySGWAhSFlL+a h746l2h+7J4b8flMe29w1GJrG6SOXTtxwLi6OKLs4pOlyaPoor4x/DqY6LibUFbncJ GmadGPKbwr5Vi6wqgzi9huPq1HCyvz5zCwhi0l0w= Received: from DFLE103.ent.ti.com (dfle103.ent.ti.com [10.64.6.24]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 32GE8RP4058627 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Mar 2023 09:08:27 -0500 Received: from DFLE115.ent.ti.com (10.64.6.36) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.16; Thu, 16 Mar 2023 09:08:26 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.16 via Frontend Transport; Thu, 16 Mar 2023 09:08:26 -0500 Received: from localhost (ileaxei01-snat.itg.ti.com [10.180.69.5]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 32GE8QaX011450; Thu, 16 Mar 2023 09:08:26 -0500 From: Jayesh Choudhary <j-choudhary@ti.com> To: <dri-devel@lists.freedesktop.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org> CC: <andrzej.hajda@intel.com>, <neil.armstrong@linaro.org>, <rfoss@kernel.org>, <Laurent.pinchart@ideasonboard.com>, <jonas@kwiboo.se>, <jernej.skrabec@gmail.com>, <airlied@gmail.com>, <daniel@ffwll.ch>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <sam@ravnborg.org>, <jani.nikula@intel.com>, <tzimmermann@suse.de>, <javierm@redhat.com>, <ville.syrjala@linux.intel.com>, <r-ravikumar@ti.com>, <lyude@redhat.com>, <alexander.deucher@amd.com>, <sjakhade@cadence.com>, <yamonkar@cadence.com>, <j-choudhary@ti.com> Subject: [PATCH 1/2] dt-bindings: drm/bridge: Add no-hpd property Date: Thu, 16 Mar 2023 19:38:22 +0530 Message-ID: <20230316140823.234263-2-j-choudhary@ti.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230316140823.234263-1-j-choudhary@ti.com> References: <20230316140823.234263-1-j-choudhary@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760536369416814799?= X-GMAIL-MSGID: =?utf-8?q?1760536369416814799?= |
Series |
"no-hpd" support in CDNS DP bridge driver
|
|
Commit Message
Jayesh Choudhary
March 16, 2023, 2:08 p.m. UTC
From: Rahul T R <r-ravikumar@ti.com> Add no-hpd property to the bindings, to disable hpd when not connected or unusable Signed-off-by: Rahul T R <r-ravikumar@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> --- .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
Comments
On 16/03/2023 15:08, Jayesh Choudhary wrote: > From: Rahul T R <r-ravikumar@ti.com> > > Add no-hpd property to the bindings, to disable > hpd when not connected or unusable > > Signed-off-by: Rahul T R <r-ravikumar@ti.com> > Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> > --- > .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > index b2e8bc6da9d0..69d381195218 100644 > --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > @@ -57,6 +57,12 @@ properties: > interrupts: > maxItems: 1 > > + cdns,no-hpd: There is already no-hpd property. > + type: boolean > + description: > + Set if the HPD line on the bridge isn't hooked up to anything or is > + otherwise unusable. It's the property of the panel, not bridge. Unless you want to say that bridge physically does not have HPD? Does it follow the standard in such case? Best regards, Krzysztof
Hello Krzysztof, On 17/03/23 18:08, Krzysztof Kozlowski wrote: > On 16/03/2023 15:08, Jayesh Choudhary wrote: >> From: Rahul T R <r-ravikumar@ti.com> >> >> Add no-hpd property to the bindings, to disable >> hpd when not connected or unusable >> >> Signed-off-by: Rahul T R <r-ravikumar@ti.com> >> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> >> --- >> .../devicetree/bindings/display/bridge/cdns,mhdp8546.yaml | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml >> index b2e8bc6da9d0..69d381195218 100644 >> --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml >> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml >> @@ -57,6 +57,12 @@ properties: >> interrupts: >> maxItems: 1 >> >> + cdns,no-hpd: > > There is already no-hpd property. > >> + type: boolean >> + description: >> + Set if the HPD line on the bridge isn't hooked up to anything or is >> + otherwise unusable. > > It's the property of the panel, not bridge. Unless you want to say that > bridge physically does not have HPD? Does it follow the standard in such > case? MHDP does have hpd. But the mhdp driver should handle the cases when the hpd pin of bridge is not connected to that of the DP-connector. This is to add support for that. (optional property) -Jayesh > > Best regards, > Krzysztof >
On 21/03/2023 13:02, Jayesh Choudhary wrote: >> >>> + type: boolean >>> + description: >>> + Set if the HPD line on the bridge isn't hooked up to anything or is >>> + otherwise unusable. >> >> It's the property of the panel, not bridge. Unless you want to say that >> bridge physically does not have HPD? Does it follow the standard in such >> case? > > MHDP does have hpd. But the mhdp driver should handle the cases when the This is about bindings, not driver. Your driver can still handle this as it wishes. > hpd pin of bridge is not connected to that of the DP-connector. This is > to add support for that. (optional property) Which is indicated by panel no-hpd, right? Or you mean now that HPD physically cannot go to panel because it is cut on the bridge side? But isn't this the same case (from hardware/bindings point, not driver) as panel would not have HPD? Best regards, Krzysztof
On 21/03/23 18:08, Krzysztof Kozlowski wrote: > On 21/03/2023 13:02, Jayesh Choudhary wrote: >>> >>>> + type: boolean >>>> + description: >>>> + Set if the HPD line on the bridge isn't hooked up to anything or is >>>> + otherwise unusable. >>> >>> It's the property of the panel, not bridge. Unless you want to say that >>> bridge physically does not have HPD? Does it follow the standard in such >>> case? >> >> MHDP does have hpd. But the mhdp driver should handle the cases when the > > This is about bindings, not driver. Your driver can still handle this as > it wishes. > >> hpd pin of bridge is not connected to that of the DP-connector. This is >> to add support for that. (optional property) > > Which is indicated by panel no-hpd, right? Actually no panel is involved in this. For TI SoC J721S2, the data pipeline involves the bridge whose endpoint is directly the DP connector with compatible 'dp-connector'. And in the binding dp-connector.yaml, there isn't any 'no-hpd' property for this indication. Does this clarifies the issue? Or did I misinterpret your comment? > Or you mean now that HPD > physically cannot go to panel because it is cut on the bridge side? But > isn't this the same case (from hardware/bindings point, not driver) as > panel would not have HPD? Warm Regards, -Jayesh
On 21/03/2023 15:28, Jayesh Choudhary wrote: > > > On 21/03/23 18:08, Krzysztof Kozlowski wrote: >> On 21/03/2023 13:02, Jayesh Choudhary wrote: >>>> >>>>> + type: boolean >>>>> + description: >>>>> + Set if the HPD line on the bridge isn't hooked up to anything or is >>>>> + otherwise unusable. >>>> >>>> It's the property of the panel, not bridge. Unless you want to say that >>>> bridge physically does not have HPD? Does it follow the standard in such >>>> case? >>> >>> MHDP does have hpd. But the mhdp driver should handle the cases when the >> >> This is about bindings, not driver. Your driver can still handle this as >> it wishes. >> >>> hpd pin of bridge is not connected to that of the DP-connector. This is >>> to add support for that. (optional property) >> >> Which is indicated by panel no-hpd, right? > > Actually no panel is involved in this. For TI SoC J721S2, the data > pipeline involves the bridge whose endpoint is directly the DP connector > with compatible 'dp-connector'. And in the binding dp-connector.yaml, > there isn't any 'no-hpd' property for this indication. > > Does this clarifies the issue? Or did I misinterpret your comment? Yes, then you only need to narrow which hardware does not have HPD hooked up. Or at least clarify that it is not about driver having or not having HPD control... Best regards, Krzysztof
On 21/03/23 20:47, Krzysztof Kozlowski wrote: > On 21/03/2023 15:28, Jayesh Choudhary wrote: >> >> >> On 21/03/23 18:08, Krzysztof Kozlowski wrote: >>> On 21/03/2023 13:02, Jayesh Choudhary wrote: >>>>> >>>>>> + type: boolean >>>>>> + description: >>>>>> + Set if the HPD line on the bridge isn't hooked up to anything or is >>>>>> + otherwise unusable. >>>>> >>>>> It's the property of the panel, not bridge. Unless you want to say that >>>>> bridge physically does not have HPD? Does it follow the standard in such >>>>> case? >>>> >>>> MHDP does have hpd. But the mhdp driver should handle the cases when the >>> >>> This is about bindings, not driver. Your driver can still handle this as >>> it wishes. >>> >>>> hpd pin of bridge is not connected to that of the DP-connector. This is >>>> to add support for that. (optional property) >>> >>> Which is indicated by panel no-hpd, right? >> >> Actually no panel is involved in this. For TI SoC J721S2, the data >> pipeline involves the bridge whose endpoint is directly the DP connector >> with compatible 'dp-connector'. And in the binding dp-connector.yaml, >> there isn't any 'no-hpd' property for this indication. >> >> Does this clarifies the issue? Or did I misinterpret your comment? > > Yes, then you only need to narrow which hardware does not have HPD > hooked up. Or at least clarify that it is not about driver having or not > having HPD control... > Okay. I will edit the commit message in v2. (after further review of the driver changes for this series) I will mention that the mhdp bridge can work without its HPD pin hooked up to the connector, but the current bridge driver throws an error when hpd line is not connected to the connector. For such cases, using this optional property, we can bypass the hpd detection and instead use the auxiliary channels connected to the DP connector to confirm the connection. Thanks, -Jayesh
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index b2e8bc6da9d0..69d381195218 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -57,6 +57,12 @@ properties: interrupts: maxItems: 1 + cdns,no-hpd: + type: boolean + description: + Set if the HPD line on the bridge isn't hooked up to anything or is + otherwise unusable. + ports: $ref: /schemas/graph.yaml#/properties/ports