Message ID | 20230929-topic-x13s_edpphy-v1-1-ce59f9eb4226@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp251063vqb; Sat, 30 Sep 2023 00:41:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH4+P/kzEvKZofyqNv5xDAXYyuMGeV1EBwSbaj5Je1MgadOIkWC09jU/tUELX8gszXdfriP X-Received: by 2002:a17:903:244d:b0:1b8:8682:62fb with SMTP id l13-20020a170903244d00b001b8868262fbmr11367987pls.4.1696059712528; Sat, 30 Sep 2023 00:41:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696059712; cv=none; d=google.com; s=arc-20160816; b=BlNqTpghxqNoHLiW6D/UlbcUIS6+ExaxeuzK6EaOgDFp/2dOTHQjNSuf458RpO15qS 4ZYYbM4RwWAaVqlSc4pGQFBo+IxP8TTDt2YiHKUTIaXaMclWYHUipvrkZyPkcMmzspgW 0vYZJ3fAvruFAyxb40yqUEazoOjaGa7ArS9Djn0CKdgWJynIGPTbCYj+t8NzapUs9Ahs W27s13p6T5Yx7X0+EBKb0VmV9bOm2k0LY/QXps9vzW+tLu5WWRZ9RdgaVsuhDK3K40Ml YkbzPonWmLZQoZo7kOOu6c9dsFL5g2/8xom50QmJ9go02G2MgZpjipG/z0a3wMvy2L3b emZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=dTHdLZvZRtA3Iqqnp6A3lBx/EWxmXoRrCoZvxKDaOvU=; fh=Lq7VqEC2tc09BHjjpATkTdbtkPHaZGDfXHHftcCglVk=; b=ObV1zwRsCwvJ0sH4cbvcD3jeAInC99nI1MOYGmeQmK+i6PVBrUE0GfEanux+2oSiiz 8HZUpRWbM1oQD8C8ndqnPPeVCto7l3MplybqgLD1rIxu5AdDjo/9qkXxdIPWuParBX6e deU/2QUhQy3dqoV5fzi1nD7Wmx6BmMugjbovFSt047/difS6VD0Wo82+SYIu8mkDw8ZA +G+yRFa5PBSlVuz/e0esPdpmL9Rqdb/bhNAvCw2qO8FuEQ4qrrc0rxma2JRqInVn327Q TCYFIcaWQrL3gBOkBRMsDegRFghFc+wtiBszEfUBA5VCVkKKpt7og5QDgeMY8LkT6rYx ZSMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=WhOnBXgi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id j72-20020a638b4b000000b0057751b4abe2si23782345pge.111.2023.09.30.00.41.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Sep 2023 00:41:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=WhOnBXgi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id AA256801C918; Fri, 29 Sep 2023 09:03:13 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233537AbjI2QDE (ORCPT <rfc822;pwkd43@gmail.com> + 20 others); Fri, 29 Sep 2023 12:03:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230104AbjI2QDD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 29 Sep 2023 12:03:03 -0400 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8881199 for <linux-kernel@vger.kernel.org>; Fri, 29 Sep 2023 09:03:00 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-9ad810be221so1947247466b.2 for <linux-kernel@vger.kernel.org>; Fri, 29 Sep 2023 09:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696003379; x=1696608179; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=dTHdLZvZRtA3Iqqnp6A3lBx/EWxmXoRrCoZvxKDaOvU=; b=WhOnBXgizzvXYWGzxvsJiFJFYEPo0sdZz8JtDw7KnI+yrHi8lCZyKlMo9jTmGpYeZA LAb5LNKXnQi39wmut0wNGaJ0TfqMoIKZGj/24Jow7g0RqbZexEtdzqP7UXiAjbXiPBrv 6XIrxFfV7AFJfin83EnjgIIPyGAcjvfmrgCKH4zZN5UL3fSG09F36ZSfSj1LVbVbsEmj 7YERpqQiMTYADQIaZfSqn/vwIDT5DPTYwVcpxX0XH3fmRy3NgH7yxUyh64CZ5YwyGwD1 Qdwy1iUuyBgHYVCDdF+4hpvXgaEphc5CCZtJsFJRHAsttcDeYu23aWUkP9CCfZzwFCIx NTdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696003379; x=1696608179; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dTHdLZvZRtA3Iqqnp6A3lBx/EWxmXoRrCoZvxKDaOvU=; b=J1MCGfb33mRbercwClxa4c6/LLnZcRYh6FqFoaGHH22Nv237tXhj6a1elLDFhbUJwQ t7H/AT68U9Mt1nZ4b5VCge7/+2LcgHQcN3n3p2OsuLums9GT+5YTWc1T2qnOZ7uCRGs/ m/6pracaZfeRG+/UY4MbSMB3Gj/4eEtS6UbRLLEyOhGNfRZBuA0OqCwoFSm0/vG6iMYO P2yo4E+Eupmx8nR1hVvXGV71mL/te18bTTWcqzvBHf8j+s3LTjI6wtmy59UfvvKpwb2A p6h3cfqTbcXXbVSpJh85qSBeM/d2IMzvV3ewu1vg5ghqUkWUmqLV8cGEDhDUCNd20N4t wYvw== X-Gm-Message-State: AOJu0Yxtt2Xf3zMhvh/yhW/m41MbjEZN8EQOJVN4JnvUAnSzDRiuPq56 BKL3sL5X/bLVqSemtnejl5Aacg== X-Received: by 2002:a17:906:5dc1:b0:9aa:16c4:be16 with SMTP id p1-20020a1709065dc100b009aa16c4be16mr3898907ejv.57.1696003379099; Fri, 29 Sep 2023 09:02:59 -0700 (PDT) Received: from [127.0.1.1] (178235177217.dynamic-4-waw-k-1-1-0.vectranet.pl. [178.235.177.217]) by smtp.gmail.com with ESMTPSA id v6-20020a170906380600b0099c53c4407dsm12548202ejc.78.2023.09.29.09.02.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 09:02:58 -0700 (PDT) From: Konrad Dybcio <konrad.dybcio@linaro.org> Date: Fri, 29 Sep 2023 18:02:57 +0200 Subject: [PATCH] arm64: dts: qcom: sc8280xp-x13s: Use the correct DP PHY compatible MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230929-topic-x13s_edpphy-v1-1-ce59f9eb4226@linaro.org> X-B4-Tracking: v=1; b=H4sIADD1FmUC/x3MQQqAIBBA0avErBN0FMquEhFhU87GRCMK6e5Jy 7f4v0CmxJRhaAokujjzESpU24DzS9hJ8FoNKFFLi1acR2QnbqXzTGuM/hGSVIfG9s5ohNrFRBv f/3Oc3vcDIE2DzWMAAAA= To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Johan Hovold <johan+linaro@kernel.org> Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Konrad Dybcio <konrad.dybcio@linaro.org> X-Mailer: b4 0.13-dev-0438c X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 29 Sep 2023 09:03:13 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778447508871191386 X-GMAIL-MSGID: 1778447508871191386 |
Series |
arm64: dts: qcom: sc8280xp-x13s: Use the correct DP PHY compatible
|
|
Commit Message
Konrad Dybcio
Sept. 29, 2023, 4:02 p.m. UTC
The DP PHY needs different settings when an eDP display is used.
Make sure these apply on the X13s.
FWIW
I could not notice any user-facing change stemming from this commit.
Fixes: f48c70b111b4 ("arm64: dts: qcom: sc8280xp-x13s: enable eDP display")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
I have no idea whether DP3 is hardwired to be eDP, like it
seems to be on the last DP controller of SC7280. In that
case this would be moved to the SoC DTSI.
---
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 1 +
1 file changed, 1 insertion(+)
---
base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6
change-id: 20230929-topic-x13s_edpphy-0e172498c432
Best regards,
Comments
On Fri, Sep 29, 2023 at 06:02:57PM +0200, Konrad Dybcio wrote: > The DP PHY needs different settings when an eDP display is used. > Make sure these apply on the X13s. Good catch. This looks to be more in line with what Bjorn intended. You should fix up sc8280xp-crd and sa8295p-adp.dts as well however. > FWIW > I could not notice any user-facing change stemming from this commit. I've seen some infrequent link-training failures (e.g. on resume) even if it's been a while since last time now. > Fixes: f48c70b111b4 ("arm64: dts: qcom: sc8280xp-x13s: enable eDP display") > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > I have no idea whether DP3 is hardwired to be eDP, like it > seems to be on the last DP controller of SC7280. In that > case this would be moved to the SoC DTSI. sa8295p-adp appears to use mdss[01]_dp[23] for eDP. > --- > arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts > index 38edaf51aa34..6a4c6cc19c09 100644 > --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts > +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts > @@ -601,6 +601,7 @@ mdss0_dp3_out: endpoint { > }; > > &mdss0_dp3_phy { > + compatible = "qcom,sc8280xp-edp-phy"; Nit: Can you add a newline here after the compatible, please? > vdda-phy-supply = <&vreg_l6b>; > vdda-pll-supply = <&vreg_l3b>; Johan
On Mon, Oct 02, 2023 at 10:54:57AM +0200, Johan Hovold wrote: > On Fri, Sep 29, 2023 at 06:02:57PM +0200, Konrad Dybcio wrote: > > The DP PHY needs different settings when an eDP display is used. > > Make sure these apply on the X13s. > > Good catch. This looks to be more in line with what Bjorn intended. > > You should fix up sc8280xp-crd and sa8295p-adp.dts as well however. As we discussed off-list, some of the ADP DP PHYs are apparently just confusingly named "eDP" for some reason so that does not need fixing. I sent a fix for the CRD here: https://lore.kernel.org/all/20231016080658.6667-1-johan+linaro@kernel.org/ > > &mdss0_dp3_phy { > > + compatible = "qcom,sc8280xp-edp-phy"; > > Nit: Can you add a newline here after the compatible, please? Would you mind respinning this one with an added newline here for consistency, though? > > vdda-phy-supply = <&vreg_l6b>; > > vdda-pll-supply = <&vreg_l3b>; Johan
On Fri, 29 Sept 2023 at 19:03, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > The DP PHY needs different settings when an eDP display is used. > Make sure these apply on the X13s. Could you please clarify, is it the same PHY type, just being repurposed for eDP or is it a different PHY type? If the former is the case (and the same PHY can be used for both DP and eDP), it should carry the same compatible string and use software mechanisms (e.g. phy_set_mode_ext()) to be programmed for the correct operation mode. > > FWIW > I could not notice any user-facing change stemming from this commit. > > Fixes: f48c70b111b4 ("arm64: dts: qcom: sc8280xp-x13s: enable eDP display") > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > I have no idea whether DP3 is hardwired to be eDP, like it > seems to be on the last DP controller of SC7280. In that > case this would be moved to the SoC DTSI. > --- > arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts > index 38edaf51aa34..6a4c6cc19c09 100644 > --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts > +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts > @@ -601,6 +601,7 @@ mdss0_dp3_out: endpoint { > }; > > &mdss0_dp3_phy { > + compatible = "qcom,sc8280xp-edp-phy"; > vdda-phy-supply = <&vreg_l6b>; > vdda-pll-supply = <&vreg_l3b>; > > > --- > base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6 > change-id: 20230929-topic-x13s_edpphy-0e172498c432 > > Best regards, > -- > Konrad Dybcio <konrad.dybcio@linaro.org> >
On Mon, Oct 16, 2023 at 11:51:33AM +0300, Dmitry Baryshkov wrote: > On Fri, 29 Sept 2023 at 19:03, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > The DP PHY needs different settings when an eDP display is used. > > Make sure these apply on the X13s. > > Could you please clarify, is it the same PHY type, just being > repurposed for eDP or is it a different PHY type? Same PHY, just different settings AFAIK. > If the former is the case (and the same PHY can be used for both DP > and eDP), it should carry the same compatible string and use software > mechanisms (e.g. phy_set_mode_ext()) to be programmed for the correct > operation mode. Possibly, but that's not how the current binding and implementation works: 6993c079cd58 ("dt-bindings: phy: qcom-edp: Add SC8280XP PHY compatibles") 2300d1cb24b3 ("phy: qcom: edp: Introduce support for DisplayPort") 3b7267dec445 ("phy: qcom: edp: Add SC8280XP eDP and DP PHYs") https://lore.kernel.org/lkml/20220810040745.3582985-1-bjorn.andersson@linaro.org/ And you'd still need to infer the mode from DT somehow. Johan
On Mon, 16 Oct 2023 at 12:01, Johan Hovold <johan@kernel.org> wrote: > > On Mon, Oct 16, 2023 at 11:51:33AM +0300, Dmitry Baryshkov wrote: > > On Fri, 29 Sept 2023 at 19:03, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > The DP PHY needs different settings when an eDP display is used. > > > Make sure these apply on the X13s. > > > > Could you please clarify, is it the same PHY type, just being > > repurposed for eDP or is it a different PHY type? > > Same PHY, just different settings AFAIK. > > > If the former is the case (and the same PHY can be used for both DP > > and eDP), it should carry the same compatible string and use software > > mechanisms (e.g. phy_set_mode_ext()) to be programmed for the correct > > operation mode. > > Possibly, but that's not how the current binding and implementation > works: > > 6993c079cd58 ("dt-bindings: phy: qcom-edp: Add SC8280XP PHY compatibles") > 2300d1cb24b3 ("phy: qcom: edp: Introduce support for DisplayPort") > 3b7267dec445 ("phy: qcom: edp: Add SC8280XP eDP and DP PHYs") > > https://lore.kernel.org/lkml/20220810040745.3582985-1-bjorn.andersson@linaro.org/ > > And you'd still need to infer the mode from DT somehow. If it is the same hardware block, it seems incorrect to have two different compat entries. For example, for PCIe RC vs PCIe EP we specify the PHY mode from the host controller driver. I'd say, we need to fix the bindings for both DP/eDP controller and the PHY. See the `phy-mode` DT property for example.
On Mon, Oct 16, 2023 at 12:10:18PM +0300, Dmitry Baryshkov wrote: > On Mon, 16 Oct 2023 at 12:01, Johan Hovold <johan@kernel.org> wrote: > > > > On Mon, Oct 16, 2023 at 11:51:33AM +0300, Dmitry Baryshkov wrote: > > > On Fri, 29 Sept 2023 at 19:03, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > The DP PHY needs different settings when an eDP display is used. > > > > Make sure these apply on the X13s. > > > > > > Could you please clarify, is it the same PHY type, just being > > > repurposed for eDP or is it a different PHY type? > > > > Same PHY, just different settings AFAIK. > > > > > If the former is the case (and the same PHY can be used for both DP > > > and eDP), it should carry the same compatible string and use software > > > mechanisms (e.g. phy_set_mode_ext()) to be programmed for the correct > > > operation mode. > > > > Possibly, but that's not how the current binding and implementation > > works: > > > > 6993c079cd58 ("dt-bindings: phy: qcom-edp: Add SC8280XP PHY compatibles") > > 2300d1cb24b3 ("phy: qcom: edp: Introduce support for DisplayPort") > > 3b7267dec445 ("phy: qcom: edp: Add SC8280XP eDP and DP PHYs") > > > > https://lore.kernel.org/lkml/20220810040745.3582985-1-bjorn.andersson@linaro.org/ > > > > And you'd still need to infer the mode from DT somehow. > > If it is the same hardware block, it seems incorrect to have two > different compat entries. For example, for PCIe RC vs PCIe EP we > specify the PHY mode from the host controller driver. > I'd say, we need to fix the bindings for both DP/eDP controller and > the PHY. See the `phy-mode` DT property for example. > It is one hardware block, supporting both eDP and DP, so I like your suggestion of having a single compatible instead and using some other means of defining the configuration. I just wasn't able to find a better way to do so back when I wrote the binding/driver... Regards, Bjorn
On 10/17/23 05:28, Bjorn Andersson wrote: > On Mon, Oct 16, 2023 at 12:10:18PM +0300, Dmitry Baryshkov wrote: >> On Mon, 16 Oct 2023 at 12:01, Johan Hovold <johan@kernel.org> wrote: >>> >>> On Mon, Oct 16, 2023 at 11:51:33AM +0300, Dmitry Baryshkov wrote: >>>> On Fri, 29 Sept 2023 at 19:03, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >>>>> >>>>> The DP PHY needs different settings when an eDP display is used. >>>>> Make sure these apply on the X13s. >>>> >>>> Could you please clarify, is it the same PHY type, just being >>>> repurposed for eDP or is it a different PHY type? >>> >>> Same PHY, just different settings AFAIK. >>> >>>> If the former is the case (and the same PHY can be used for both DP >>>> and eDP), it should carry the same compatible string and use software >>>> mechanisms (e.g. phy_set_mode_ext()) to be programmed for the correct >>>> operation mode. >>> >>> Possibly, but that's not how the current binding and implementation >>> works: >>> >>> 6993c079cd58 ("dt-bindings: phy: qcom-edp: Add SC8280XP PHY compatibles") >>> 2300d1cb24b3 ("phy: qcom: edp: Introduce support for DisplayPort") >>> 3b7267dec445 ("phy: qcom: edp: Add SC8280XP eDP and DP PHYs") >>> >>> https://lore.kernel.org/lkml/20220810040745.3582985-1-bjorn.andersson@linaro.org/ >>> >>> And you'd still need to infer the mode from DT somehow. >> >> If it is the same hardware block, it seems incorrect to have two >> different compat entries. For example, for PCIe RC vs PCIe EP we >> specify the PHY mode from the host controller driver. >> I'd say, we need to fix the bindings for both DP/eDP controller and >> the PHY. See the `phy-mode` DT property for example. >> > > It is one hardware block, supporting both eDP and DP, so I like your > suggestion of having a single compatible instead and using some other > means of defining the configuration. I just wasn't able to find a > better way to do so back when I wrote the binding/driver... Since this one is still unused, we can deprecate it (not sure if remove, but deprecate) and add phy-type instead. I was quite surprised to see that a new compatible was added as well :/ Konrad
On Fri, 29 Sep 2023 18:02:57 +0200, Konrad Dybcio wrote: > The DP PHY needs different settings when an eDP display is used. > Make sure these apply on the X13s. > > FWIW > I could not notice any user-facing change stemming from this commit. > > > [...] Applied, thanks! [1/1] arm64: dts: qcom: sc8280xp-x13s: Use the correct DP PHY compatible commit: 0cd080dd6d08817c9980d2069197b066636b0f23 Best regards,
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts index 38edaf51aa34..6a4c6cc19c09 100644 --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts @@ -601,6 +601,7 @@ mdss0_dp3_out: endpoint { }; &mdss0_dp3_phy { + compatible = "qcom,sc8280xp-edp-phy"; vdda-phy-supply = <&vreg_l6b>; vdda-pll-supply = <&vreg_l3b>;