Received-SPF: pass (google.com: domain of linux-kernel+bounces-35397-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <99a9a562-9f6f-411c-be1c-0a28fc2524dd@quicinc.com>
Date: Tue, 23 Jan 2024 19:13:23 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] arm64: dts: qcom: qcm6490-idp: add display and panel
Content-Language: en-US
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Konrad Dybcio
	<konrad.dybcio@linaro.org>
CC: <andersson@kernel.org>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <catalin.marinas@arm.com>, <will@kernel.org>,
        <quic_bjorande@quicinc.com>, <geert+renesas@glider.be>,
        <arnd@arndb.de>, <neil.armstrong@linaro.org>,
        <nfraprado@collabora.com>, <m.szyprowski@samsung.com>,
        <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
        <quic_abhinavk@quicinc.com>, <quic_rajeevny@quicinc.com>,
        <quic_vproddut@quicinc.com>
References: <20240116094935.9988-1-quic_riteshk@quicinc.com>
 <20240116094935.9988-3-quic_riteshk@quicinc.com>
 <20a8efd1-e243-434e-8f75-aa786ac8014f@linaro.org>
 <CAA8EJpqQVuS+yqXQ2y5sNQrRVg7tcQAJ3ywsEjg+O=7TkUZWLQ@mail.gmail.com>
From: Ritesh Kumar <quic_riteshk@quicinc.com>
In-Reply-To: <CAA8EJpqQVuS+yqXQ2y5sNQrRVg7tcQAJ3ywsEjg+O=7TkUZWLQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit


On 1/16/2024 6:27 PM, Dmitry Baryshkov wrote:

> On Tue, 16 Jan 2024 at 14:06, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>>
>>
>> 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@quicinc.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

Thanks, I will update in the new version.

>>> +&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?
> Missed this.
>
> I'd say, I don't see a reason to disable it at all. The GPU should be
> working on sc7280 / qcm4290.

With GPU device node enabled, adreno_bind failure is seen as the 
"speed_bin" was not populated on QCM6490 target which leads to display 
bind failure.
Spoke with GPU team and on QCM6490 board, only CPU rendering is 
supported for now and there is no plan to enable GPU rendering in near 
future.

In this regard, what do you suggest

1) Disable GPU in QCM6490 DT (as per the current patch)
2) Disable GPU in the SoC DT, but enable it in other platform DTs. (This 
will prompt change in all the dt's and we don't have all the devices to 
test)

Please let me know your views on it.


Thanks,
Ritesh