[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20a8efd1-e243-434e-8f75-aa786ac8014f@linaro.org>
Date: Tue, 16 Jan 2024 13:06:26 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Ritesh Kumar <quic_riteshk@...cinc.com>, andersson@...nel.org,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
catalin.marinas@....com, will@...nel.org, quic_bjorande@...cinc.com,
geert+renesas@...der.be, arnd@...db.de, neil.armstrong@...aro.org,
dmitry.baryshkov@...aro.org, nfraprado@...labora.com,
m.szyprowski@...sung.com
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
quic_abhinavk@...cinc.com, quic_rajeevny@...cinc.com,
quic_vproddut@...cinc.com
Subject: Re: [PATCH 2/2] arm64: dts: qcom: qcm6490-idp: add display and panel
On 1/16/24 10:49, Ritesh Kumar wrote:
> Enable Display Subsystem with Novatek NT36672E Panel
> on qcm6490 idp platform.
>
> Signed-off-by: Ritesh Kumar <quic_riteshk@...cinc.com>
> ---
> arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 100 +++++++++++++++++++++++
> 1 file changed, 100 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> index 2a6e4907c5ee..efa5252130a1 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
> @@ -9,6 +9,7 @@
> #define PM7250B_SID 8
> #define PM7250B_SID1 9
>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> #include "sc7280.dtsi"
> #include "pm7250b.dtsi"
> @@ -38,6 +39,25 @@
> stdout-path = "serial0:115200n8";
> };
>
> + lcd_disp_bias: lcd-disp-bias-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_disp_bias";
> + regulator-min-microvolt = <5500000>;
> + regulator-max-microvolt = <5500000>;
> + gpio = <&pm7250b_gpios 2 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_disp_bias_en>;
property-n
property-names
all throughout the patch
> +&gpu {
> + status = "disabled";
> +};
Hm.. generally we disable the GPU in the SoC DT, but that doesn't
seem to have happened here..
Thinking about it more, is disabling it here necessary? Does it
not fail gracefully?
Konrad
Powered by blists - more mailing lists