[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5c2265e82af8f755d649c0c36a462f19@codeaurora.org>
Date: Mon, 29 Jun 2020 19:20:09 +0530
From: harigovi@...eaurora.org
To: Stephen Boyd <swboyd@...omium.org>
Cc: devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
freedreno@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, robdclark@...il.com,
seanpaul@...omium.org, hoegsberg@...omium.org,
kalyan_t@...eaurora.org, nganji@...eaurora.org
Subject: Re: [v3] arm64: dts: sc7180: add nodes for idp display
On 2020-06-25 06:37, Stephen Boyd wrote:
> Quoting Harigovindan P (2020-02-17 00:58:42)
>> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
>> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
>> index 388f50ad4fde..349db8fe78a5 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
>> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
>> @@ -232,6 +233,57 @@ vreg_bob: bob {
>> };
>> };
>>
>> +&dsi0 {
>> + status = "okay";
>> +
>> + vdda-supply = <&vreg_l3c_1p2>;
>> +
>> + panel@0 {
>> + compatible = "visionox,rm69299-1080p-display";
>> + reg = <0>;
>> +
>> + vdda-supply = <&vreg_l8c_1p8>;
>> + vdd3p3-supply = <&vreg_l18a_2p8>;
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&disp_pins>;
>> +
>> + reset-gpios = <&pm6150l_gpio 3 GPIO_ACTIVE_HIGH>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 {
>> + reg = <0>;
>> + panel0_in: endpoint {
>> + remote-endpoint = <&dsi0_out>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + ports {
>> + port@1 {
>> + endpoint {
>> + remote-endpoint = <&panel0_in>;
>> + data-lanes = <0 1 2 3>;
>
> Is this property needed? If it's the default assumption it would be
> nice
> to omit it so that we don't have to think about it.
> This property is needed during panel probe. If this is not mentioned
> here,
mipi_dsi_attach() will fail during panel probe. In dsi_host.c,
dsi_host_attach()
fails since dsi lanes are greater than msm_host lanes. msm_host lanes
are updated
as part of dsi_host_parse_dt. If we dont provide data-lanes in dt, it'll
have default
value and fail in dsi_host_attach().
>> + };
>> + };
>> + };
>> +};
>> +
>> +&dsi_phy {
>> + status = "okay";
>> +};
>> +
>> +&mdp {
>> + status = "okay";
>> +};
>> +
>> +&mdss {
>> + status = "okay";
>> +};
>> +
>> &qspi {
>> status = "okay";
>> pinctrl-names = "default";
>> @@ -289,6 +341,17 @@ &usb_1_qmpphy {
>>
>> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>>
>> +&pm6150l_gpio {
>> + disp_pins: disp-pins {
>
> Curious how this works. It looks like PMIC GPIOS are expecting the node
> to look like:
>
> disp_pins: disp-pins {
> pinconf {
> pins = "gpio3";
> function = PMIC_GPIO_FUNC_FUNC1;
> qcom,drive-strength = <PMIC_GPIO_STRENGTH_MED>;
> power-source = <PM6150_GPIO_VPH>;
> bias-disable;
> output-low;
> };
>
> but this doesn't use the macros or the subnode for pinconf. Why? Also,
> the PM6150_GPIO_VPH macro doesn't exist.
We are discussing with PMIC team to have that macro in the header file.
Will add other macros as part of next version.
>
>> + pins = "gpio3";
>> + function = "func1";
>> + qcom,drive-strength = <2>;
>> + power-source = <0>;
>> + bias-disable;
>> + output-low;
>> + };
>> +};
>> +
Powered by blists - more mailing lists