Message ID | 20230516151708.213744-1-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp510509vqo; Tue, 16 May 2023 08:23:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5Pzs9jHNj8QMfvxR9/QYvlvIM3SHucpciGGMSeKPP71Zr7PRq85Xo73x+Z+IrZBc1zospl X-Received: by 2002:a05:6a00:2408:b0:643:aa2:4dd9 with SMTP id z8-20020a056a00240800b006430aa24dd9mr47319918pfh.7.1684250629553; Tue, 16 May 2023 08:23:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684250629; cv=none; d=google.com; s=arc-20160816; b=qrfBOMceRdEVnV3Tkn6Lx8fBLPlCHZr+8j91b/aNDqhj4v26vVc+iJ+P1Yr+xqlKpj QE46PE7hYRhm4yHC7zsRSEVbrRChYHupky6BHo+F6tByFYd77Oll+oujRpi4WTpzJ4lA X2kSUXETa6x4IkF5mec6SdjaULzEDhkLyocIkTUJCGJZI4TYw1ZQ/78Z3HOYr3chgyzY yP2VGQyBjVOx5WVePbkR6kzAhO6OHfC+JUPgRdpoaSzX0rEqBdbClmCLxF4fYq0bAapR ug+aYrIAjqdseIXiPPIB3tmz3u+Xmspm0PGmyGqyApoxfS3pAEUF2xcTzGkhePNd0O6r kA3g== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=s0lCm3iG0pXdFFf2LiZLAcS+oXB2fCjsEQx26FGefBo=; b=s/RoktL0peFHDNdTC848JQQeRc7WbfhzLAEHIucXwpHO7MoJaiEOzPoH4c9Tqdb9Oe D7yskXgnrymWVHyEKiuAEg0wBmp1HElf8EcdYIL0b3kJi5/Jizf9YSlIdYnxanVZNSES 92pEVie3C1isBbXHTwLu2SQ1+72Q0+x1VS0PkAceP80qkQQMgnqXog5oCdYyu72f5jQk dw2OmxQdG0SJrvj5JOXtAJUCVR0oHGMxvNHPbq9AcME+QwUyNqxKIsAL/+l5JRGe9rio XtptgxCCyaC/9NQm4lhLx/S+mDC6YlYCDbvyUUJknwbaZ5uQLbqEJAC7Q37GrVaOxYEk bxPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Ock+dXRp; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g206-20020a6252d7000000b0063f032d78efsi20614090pfb.269.2023.05.16.08.23.34; Tue, 16 May 2023 08:23:49 -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=@linaro.org header.s=google header.b=Ock+dXRp; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233511AbjEPPR0 (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Tue, 16 May 2023 11:17:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233371AbjEPPRS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 16 May 2023 11:17:18 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A9847A81 for <linux-kernel@vger.kernel.org>; Tue, 16 May 2023 08:17:13 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-96aa0cab88dso834965966b.1 for <linux-kernel@vger.kernel.org>; Tue, 16 May 2023 08:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1684250231; x=1686842231; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=s0lCm3iG0pXdFFf2LiZLAcS+oXB2fCjsEQx26FGefBo=; b=Ock+dXRpE6ZvT5f3R/3I6ixw0WaylD6JfMxORJ/RZP9zRQVqcYMs2S0spKA7vG/r2I nsed8ZaD6xNYInAV6H1xDGne2gG6CSAHzxx2l8b+moJ4qVFXWKZnbDkARwTFkhYvC03l fqNwM0T9hrIzjZ0NjwS+Ct/lXWjX+ddNKLUCt/JNkqWZcOAxRvzF8AFiVYz0PN1T7HUf kFCSyTFYm0qe1E3QkQpgGRnXamU6dw58u8be7yTDIs66KugMhWO/KrBzhkoog+h3/Tne 02ORlsCfUvvZZblGfDNRFmWjlkhHkUA/JlY9qCdCbsRIRjWMCcnvrQQSIB+uC+aaid01 0ijg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684250231; x=1686842231; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s0lCm3iG0pXdFFf2LiZLAcS+oXB2fCjsEQx26FGefBo=; b=hx+xqWrnu+8diQb3W/Egl7d5vUzpmVyWfZO5/bX+W4J5cHxB6qBRXsrysMGGL2ysfo 4wLJTm/iw4lSYtwBFjtXQkPsjyCKi0v2rDxxkqWL71LM87zDVoJ7hNpBwYsYJg7DSYmt UHoMJ7WyLaWuSG/xO748XtmSGdLoLWsHgDEhfTj5troKlGypJpkrVSdL6z/e8tD23c72 fuo7FXUrVeSVvaMBdESEJFTEJS/lI3weiZBoc8Fu5LXpTOyRbArNrRDIuqhyJFmn+JCE EC1EJQaDqsc2e5hKr1xWfGdmFB1hs82RiFJZ3U6o4yL+FhWliuWcenrSrtY3YVpKNNcN ErQg== X-Gm-Message-State: AC+VfDyEqgfC8b2GLnnldw7CUc9x0FkL/WZvISRHV7c0UbHIRpFenqBq W9QSJUUeHz4OwQIFGuCIrefaopGd8ouk/KXl59k= X-Received: by 2002:a17:907:d06:b0:966:37b2:734a with SMTP id gn6-20020a1709070d0600b0096637b2734amr36602432ejc.22.1684250231573; Tue, 16 May 2023 08:17:11 -0700 (PDT) Received: from krzk-bin.. ([2a02:810d:15c0:828:77d1:16a1:abe1:84fc]) by smtp.gmail.com with ESMTPSA id jr18-20020a170906515200b00965f5d778e3sm11096028ejc.120.2023.05.16.08.17.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 May 2023 08:17:11 -0700 (PDT) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Neil Armstrong <neil.armstrong@linaro.org>, "Signed-off-by : Abel Vesa" <abel.vesa@linaro.org>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Subject: [PATCH] arm64: dts: qcom: sm8550-qrd: add display and panel Date: Tue, 16 May 2023 17:17:08 +0200 Message-Id: <20230516151708.213744-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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?1766064787951090514?= X-GMAIL-MSGID: =?utf-8?q?1766064787951090514?= |
Series |
arm64: dts: qcom: sm8550-qrd: add display and panel
|
|
Commit Message
Krzysztof Kozlowski
May 16, 2023, 3:17 p.m. UTC
Enable Display Subsystem with Visionox VTDR6130 Panel (same as on
MTP8550).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Context in the patch depends on:
1. https://lore.kernel.org/linux-arm-msm/20230516133011.108093-1-krzysztof.kozlowski@linaro.org/T/#t
2. https://lore.kernel.org/linux-arm-msm/20230512160452.206585-1-krzysztof.kozlowski@linaro.org/
---
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 76 +++++++++++++++++++++++++
1 file changed, 76 insertions(+)
Comments
On 16.05.2023 17:17, Krzysztof Kozlowski wrote: > Enable Display Subsystem with Visionox VTDR6130 Panel (same as on > MTP8550). > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > --- > > Context in the patch depends on: > 1. https://lore.kernel.org/linux-arm-msm/20230516133011.108093-1-krzysztof.kozlowski@linaro.org/T/#t > 2. https://lore.kernel.org/linux-arm-msm/20230512160452.206585-1-krzysztof.kozlowski@linaro.org/ > --- > arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 76 +++++++++++++++++++++++++ > 1 file changed, 76 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts > index 30b36a149125..03bf6bc2db4d 100644 > --- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts > +++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts > @@ -420,6 +420,10 @@ vreg_l3g_1p2: ldo3 { > }; > }; > > +&dispcc { > + status = "okay"; > +}; Missed this in the bigpatchdrop review.. It makes no sense to keep dispcc disabled by default (other than for lazily "solving" UEFI framebuffer being shut down) > + > &gcc { > clocks = <&bi_tcxo_div2>, <&sleep_clk>, > <&pcie0_phy>, > @@ -431,6 +435,50 @@ &gcc { > <&usb_dp_qmpphy QMP_USB43DP_USB3_PIPE_CLK>; > }; > > +&mdss { > + status = "okay"; > +}; > + > +&mdss_dsi0 { > + vdda-supply = <&vreg_l3e_1p2>; > + status = "okay"; > + > + panel@0 { > + compatible = "visionox,vtdr6130"; > + reg = <0>; > + > + pinctrl-names = "default", "sleep"; > + pinctrl-0 = <&sde_dsi_active>, <&sde_te_active>; > + pinctrl-1 = <&sde_dsi_suspend>, <&sde_te_suspend>; property-n property-names > + > + vddio-supply = <&vreg_l12b_1p8>; > + vci-supply = <&vreg_l13b_3p0>; > + vdd-supply = <&vreg_l11b_1p2>; > + > + reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>; > + > + port { > + panel0_in: endpoint { > + remote-endpoint = <&mdss_dsi0_out>; > + }; > + }; > + }; > +}; > + > +&mdss_dsi0_out { > + remote-endpoint = <&panel0_in>; > + data-lanes = <0 1 2 3>; > +}; > + > +&mdss_dsi0_phy { > + vdds-supply = <&vreg_l1e_0p88>; > + status = "okay"; > +}; > + > +&mdss_mdp { > + status = "okay"; > +}; This should also be enabled by default, MDSS is useless when MDP is disabled. lgtm otherwise Konrad > + > &pcie_1_phy_aux_clk { > status = "disabled"; > }; > @@ -532,6 +580,34 @@ wcd_tx: codec@0,3 { > &tlmm { > gpio-reserved-ranges = <32 8>; > > + sde_dsi_active: sde-dsi-active-state { > + pins = "gpio133"; > + function = "gpio"; > + drive-strength = <8>; > + bias-disable; > + }; > + > + sde_dsi_suspend: sde-dsi-suspend-state { > + pins = "gpio133"; > + function = "gpio"; > + drive-strength = <2>; > + bias-pull-down; > + }; > + > + sde_te_active: sde-te-active-state { > + pins = "gpio86"; > + function = "mdp_vsync"; > + drive-strength = <2>; > + bias-pull-down; > + }; > + > + sde_te_suspend: sde-te-suspend-state { > + pins = "gpio86"; > + function = "mdp_vsync"; > + drive-strength = <2>; > + bias-pull-down; > + }; > + > wcd_default: wcd-reset-n-active-state { > pins = "gpio108"; > function = "gpio";
On 16/05/2023 17:20, Konrad Dybcio wrote: > > > On 16.05.2023 17:17, Krzysztof Kozlowski wrote: >> Enable Display Subsystem with Visionox VTDR6130 Panel (same as on >> MTP8550). >> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> >> --- >> >> Context in the patch depends on: >> 1. https://lore.kernel.org/linux-arm-msm/20230516133011.108093-1-krzysztof.kozlowski@linaro.org/T/#t >> 2. https://lore.kernel.org/linux-arm-msm/20230512160452.206585-1-krzysztof.kozlowski@linaro.org/ >> --- >> arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 76 +++++++++++++++++++++++++ >> 1 file changed, 76 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts >> index 30b36a149125..03bf6bc2db4d 100644 >> --- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts >> +++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts >> @@ -420,6 +420,10 @@ vreg_l3g_1p2: ldo3 { >> }; >> }; >> >> +&dispcc { >> + status = "okay"; >> +}; > Missed this in the bigpatchdrop review.. It makes no sense to keep > dispcc disabled by default (other than for lazily "solving" UEFI > framebuffer being shut down) Sure. > >> + >> &gcc { >> clocks = <&bi_tcxo_div2>, <&sleep_clk>, >> <&pcie0_phy>, >> @@ -431,6 +435,50 @@ &gcc { >> <&usb_dp_qmpphy QMP_USB43DP_USB3_PIPE_CLK>; >> }; >> >> +&mdss { >> + status = "okay"; >> +}; >> + >> +&mdss_dsi0 { >> + vdda-supply = <&vreg_l3e_1p2>; >> + status = "okay"; >> + >> + panel@0 { >> + compatible = "visionox,vtdr6130"; >> + reg = <0>; >> + >> + pinctrl-names = "default", "sleep"; >> + pinctrl-0 = <&sde_dsi_active>, <&sde_te_active>; >> + pinctrl-1 = <&sde_dsi_suspend>, <&sde_te_suspend>; > property-n > property-names Sure, copy-pasta from MTP8550. >> + >> +&mdss_mdp { >> + status = "okay"; >> +}; > This should also be enabled by default, MDSS is useless when MDP is > disabled. But don't we want to disable both when display is not used (not connected)? Best regards, Krzysztof
On 16.05.2023 17:23, Krzysztof Kozlowski wrote: > On 16/05/2023 17:20, Konrad Dybcio wrote: >> >> >> On 16.05.2023 17:17, Krzysztof Kozlowski wrote: >>> Enable Display Subsystem with Visionox VTDR6130 Panel (same as on >>> MTP8550). >>> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>> >>> --- >>> >>> Context in the patch depends on: >>> 1. https://lore.kernel.org/linux-arm-msm/20230516133011.108093-1-krzysztof.kozlowski@linaro.org/T/#t >>> 2. https://lore.kernel.org/linux-arm-msm/20230512160452.206585-1-krzysztof.kozlowski@linaro.org/ >>> --- >>> arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 76 +++++++++++++++++++++++++ >>> 1 file changed, 76 insertions(+) >>> >>> diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts >>> index 30b36a149125..03bf6bc2db4d 100644 >>> --- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts >>> +++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts >>> @@ -420,6 +420,10 @@ vreg_l3g_1p2: ldo3 { >>> }; >>> }; >>> >>> +&dispcc { >>> + status = "okay"; >>> +}; >> Missed this in the bigpatchdrop review.. It makes no sense to keep >> dispcc disabled by default (other than for lazily "solving" UEFI >> framebuffer being shut down) > > Sure. > >> >>> + >>> &gcc { >>> clocks = <&bi_tcxo_div2>, <&sleep_clk>, >>> <&pcie0_phy>, >>> @@ -431,6 +435,50 @@ &gcc { >>> <&usb_dp_qmpphy QMP_USB43DP_USB3_PIPE_CLK>; >>> }; >>> >>> +&mdss { >>> + status = "okay"; >>> +}; >>> + >>> +&mdss_dsi0 { >>> + vdda-supply = <&vreg_l3e_1p2>; >>> + status = "okay"; >>> + >>> + panel@0 { >>> + compatible = "visionox,vtdr6130"; >>> + reg = <0>; >>> + >>> + pinctrl-names = "default", "sleep"; >>> + pinctrl-0 = <&sde_dsi_active>, <&sde_te_active>; >>> + pinctrl-1 = <&sde_dsi_suspend>, <&sde_te_suspend>; >> property-n >> property-names > > Sure, copy-pasta from MTP8550. > >>> + >>> +&mdss_mdp { >>> + status = "okay"; >>> +}; >> This should also be enabled by default, MDSS is useless when MDP is >> disabled. > > But don't we want to disable both when display is not used (not connected)? The MDSS bus device only has a 0x1000 slice of the 0x90000-long "full MDSS", the rest is probed with MDP/DPU. It also calls of_something_populate that make DSI, DSIPHY and DP/HDMI probe. But all of them ultimately need a graph handle to MDP. If we have a display (of any kind), MDP has to be enabled (or the display engine will not have a way to be programmed). If we don't, enabling MDSS makes no sense as all of the hardware will be shut down right after probing. So I'd say either both or none. Konrad > > Best regards, > Krzysztof >
On 16/05/2023 17:26, Konrad Dybcio wrote: >>>> +&mdss_mdp { >>>> + status = "okay"; >>>> +}; >>> This should also be enabled by default, MDSS is useless when MDP is >>> disabled. >> >> But don't we want to disable both when display is not used (not connected)? > The MDSS bus device only has a 0x1000 slice of the 0x90000-long "full MDSS", > the rest is probed with MDP/DPU. It also calls of_something_populate that > make DSI, DSIPHY and DP/HDMI probe. But all of them ultimately need a graph > handle to MDP. > > If we have a display (of any kind), MDP has to be enabled (or the display > engine will not have a way to be programmed). > > If we don't, enabling MDSS makes no sense as all of the hardware will be > shut down right after probing. > > So I'd say either both or none. Yes, so the current state - both disabled - is matching it. Best regards, Krzysztof
On 16.05.2023 17:35, Krzysztof Kozlowski wrote: > On 16/05/2023 17:26, Konrad Dybcio wrote: >>>>> +&mdss_mdp { >>>>> + status = "okay"; >>>>> +}; >>>> This should also be enabled by default, MDSS is useless when MDP is >>>> disabled. >>> >>> But don't we want to disable both when display is not used (not connected)? >> The MDSS bus device only has a 0x1000 slice of the 0x90000-long "full MDSS", >> the rest is probed with MDP/DPU. It also calls of_something_populate that >> make DSI, DSIPHY and DP/HDMI probe. But all of them ultimately need a graph >> handle to MDP. >> >> If we have a display (of any kind), MDP has to be enabled (or the display >> engine will not have a way to be programmed). >> >> If we don't, enabling MDSS makes no sense as all of the hardware will be >> shut down right after probing. >> >> So I'd say either both or none. > > Yes, so the current state - both disabled - is matching it. Right, but what i was trying to say is that if we leave MDP without any status properties, it will follow MDSS. Konrad > > Best regards, > Krzysztof >
On 16/05/2023 17:36, Konrad Dybcio wrote: >>>> But don't we want to disable both when display is not used (not connected)? >>> The MDSS bus device only has a 0x1000 slice of the 0x90000-long "full MDSS", >>> the rest is probed with MDP/DPU. It also calls of_something_populate that >>> make DSI, DSIPHY and DP/HDMI probe. But all of them ultimately need a graph >>> handle to MDP. >>> >>> If we have a display (of any kind), MDP has to be enabled (or the display >>> engine will not have a way to be programmed). >>> >>> If we don't, enabling MDSS makes no sense as all of the hardware will be >>> shut down right after probing. >>> >>> So I'd say either both or none. >> >> Yes, so the current state - both disabled - is matching it. > Right, but what i was trying to say is that if we leave MDP without > any status properties, it will follow MDSS. Ah, I missed that it is MDSS child, so indeed there is no point to have it explicitly disabled. I'll fix it. Best regards, Krzysztof
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts index 30b36a149125..03bf6bc2db4d 100644 --- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts +++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts @@ -420,6 +420,10 @@ vreg_l3g_1p2: ldo3 { }; }; +&dispcc { + status = "okay"; +}; + &gcc { clocks = <&bi_tcxo_div2>, <&sleep_clk>, <&pcie0_phy>, @@ -431,6 +435,50 @@ &gcc { <&usb_dp_qmpphy QMP_USB43DP_USB3_PIPE_CLK>; }; +&mdss { + status = "okay"; +}; + +&mdss_dsi0 { + vdda-supply = <&vreg_l3e_1p2>; + status = "okay"; + + panel@0 { + compatible = "visionox,vtdr6130"; + reg = <0>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&sde_dsi_active>, <&sde_te_active>; + pinctrl-1 = <&sde_dsi_suspend>, <&sde_te_suspend>; + + vddio-supply = <&vreg_l12b_1p8>; + vci-supply = <&vreg_l13b_3p0>; + vdd-supply = <&vreg_l11b_1p2>; + + reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>; + + port { + panel0_in: endpoint { + remote-endpoint = <&mdss_dsi0_out>; + }; + }; + }; +}; + +&mdss_dsi0_out { + remote-endpoint = <&panel0_in>; + data-lanes = <0 1 2 3>; +}; + +&mdss_dsi0_phy { + vdds-supply = <&vreg_l1e_0p88>; + status = "okay"; +}; + +&mdss_mdp { + status = "okay"; +}; + &pcie_1_phy_aux_clk { status = "disabled"; }; @@ -532,6 +580,34 @@ wcd_tx: codec@0,3 { &tlmm { gpio-reserved-ranges = <32 8>; + sde_dsi_active: sde-dsi-active-state { + pins = "gpio133"; + function = "gpio"; + drive-strength = <8>; + bias-disable; + }; + + sde_dsi_suspend: sde-dsi-suspend-state { + pins = "gpio133"; + function = "gpio"; + drive-strength = <2>; + bias-pull-down; + }; + + sde_te_active: sde-te-active-state { + pins = "gpio86"; + function = "mdp_vsync"; + drive-strength = <2>; + bias-pull-down; + }; + + sde_te_suspend: sde-te-suspend-state { + pins = "gpio86"; + function = "mdp_vsync"; + drive-strength = <2>; + bias-pull-down; + }; + wcd_default: wcd-reset-n-active-state { pins = "gpio108"; function = "gpio";