[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2db06bcc-f04b-4a57-afd2-1d0c665d376a@kernel.org>
Date: Wed, 29 Oct 2025 07:27:29 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Mahadevan P <mahadevan.p@....qualcomm.com>,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 jesszhan0024@...il.com, Dmitry Baryshkov
 <dmitry.baryshkov@....qualcomm.com>, quic_rajeevny@...cinc.com
Cc: Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Abhinav Kumar <abhinavk@...cinc.com>,
 Abel Vesa <abel.vesa@...aro.org>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC/WIP 0/4] arm64: dts: qcom: sm8750: Enable display
On 29/10/2025 07:20, Mahadevan P wrote:
> Hi Krzysztof,
> 
> On 4/26/2025 1:24 AM, Krzysztof Kozlowski wrote:
>> On 25/04/2025 21:34, Dmitry Baryshkov wrote:
>>> On Thu, Apr 24, 2025 at 03:04:24PM +0200, Krzysztof Kozlowski wrote:
>>>> DTS is ready and I consider it ready for review, but still RFC because:
>>>> 1. Display has unresolved issues which might result in change in
>>>>     bindings (clock parents),
>>>> 2. I did not test it since some time on my board...
>>>> 3. Just want to share it fast to unblock any dependent work.
>>>>
>>>> DTS build dependencies - as in b4 deps, so:
>>>> https://lore.kernel.org/r/20250421-sm8750_usb_master-v5-0-25c79ed01d02@oss.qualcomm.com/
>>>> https://lore.kernel.org/r/20250424-sm8750-audio-part-2-v1-0-50133a0ec35f@linaro.org/
>>>> https://lore.kernel.org/r/20250113-sm8750_gpmic_master-v1-2-ef45cf206979@quicinc.com/
>>>>
>>>> Bindings:
>>>> 1. Panel:https://github.com/krzk/linux/tree/b4/sm8750-display-panel
>>>> 2. MDSS:https://lore.kernel.org/r/20250311-b4-sm8750-display-v4-0-da6b3e959c76@linaro.org/
>>>>
>>>> Patchset based on next-20250424.
>>> If the DisplayPort works on this platform, I'd kindly ask to send
>>> separate DP+DPU only series (both driver and arm64/dts). It would make
>>> it much easier (at least for me) to land the series, while you and
>>> Qualcomm engineers are working on the DSI issues.
>> DP has also issues - link training failures, although it feels as
>> different one, because DSI issue Jessica narrowed to DSI PHY PLL VCO
>> rate and I have a working display (just don't know how to actually solve
>> this).
> 
> We at Qualcomm are currently working on bringing up the DSI display on 
> MTP. For this, I’ve picked the following patches on top of |v6.18-rc2|:
Display on MTP8750 was fully brought already. I don't understand why you
are doing the same.
> 
>  1. All the DT changes mentioned in this series
>  2. [PATCH v2] drm/msm/dpu: Fix adjusted mode clock check for 3d merge
>     https://lore.kernel.org/all/1154f275-f934-46ae-950a-209d31463525@kernel.org/
>  3. [PATCH v2 0/2] drm/panel: Add Novatek NT37801 panel driver
>     https://lore.kernel.org/all/20250508-sm8750-display-panel-v2-0-3ca072e3d1fa@linaro.org/
> 
> However, when testing with |modetest|, the panel appears blank. I wanted 
> to check if there are any additional patches already posted that I might 
> have missed and should be included.
Many patches are missing because Qualcomm did not send them for months.
I was pinging multiple times and I gave up - my job is not ping Qualcomm
to send their patches.
I have no clue what you have already, what is your base, what errors you
have and I will not be guessing this. For convenience, you can use my
integration WIP branch from my github. I already shared that tree with
Qualcomm more than once. Please reach internally first, instead of
poking community.
> 
> Also, I’m curious to understand more about the DSI PHY PLL VCO rate 
> issue that Jessica had narrowed down—could you please share some details?
Sorry, I am not going to repeat stuff done year ago. Please reach to the
archives.
> 
> Lastly, I’d appreciate it if you could share the plan for merging these 
> changes upstream.
I don't understand what you ask me. Process of contributing to Linux
kernel is well documented.
Best regards,
Krzysztof
Powered by blists - more mailing lists
 
