linux-kernel - Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Use 'edp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c6ef0324-c932-4c80-8252-97dd3ee255d3@quicinc.com>
Date: Thu, 6 Nov 2025 15:01:07 +0530
From: Amit Singh <quic_amitsi@...cinc.com>
To: Bjorn Andersson <andersson@...nel.org>
CC: <konradybcio@...nel.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_riteshk@...cinc.com>, <quic_rajeevny@...cinc.com>,
        <quic_vproddut@...cinc.com>
Subject: Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Use 'edp_hot' function
 for hpd gpio

On 11/2/2025 12:29 AM, Bjorn Andersson wrote:
> On Fri, Oct 31, 2025 at 02:27:39PM +0530, Amit Singh wrote:
>> Currently, hpd gpio is configured as a general-purpose gpio, which does
>> not support interrupt generation. This change removes the generic
>> hpd-gpios property and assigns the edp_hot function to the pin,
>> enabling proper irq support.
>>
> 
> No, it replaces the use of display-connector for hotplug detect with the
> DP-controller's internal HPD logic.
> 
> There might be good reasons to do so, but you need to describe them.
> 
> I'm guessing that there are still some issues in the DP driver's logic
> for handling of external HPD? This should be addressed by fixing that
> logic in the DP driver, to ensure that this (display-connector +
> hpd-gpios) works, and then you should send this patch again explaining
> why the internal HPD hardware does a better job.
> 
> Regards,
> Bjorn

Thanks for the feedback and clarification.

We observed a specific use case where using the GPIO-based external HPD
handling via display-connector leads to a functional issue.
When the DisplayPort cable is already connected and the display is active,
and we perform a system reboot, the display does not come up automatically
after boot with the current configuration (using hpd-gpios).
This happens because we do not receive a connect event post boot —
the GPIO-based HPD path does not generate an interrupt in this scenario,
as the line remains high and no edge event is triggered.

However, when we configure the pin with the edp_hot function and use the
internal HPD logic of the DP controller, the controller correctly detects
the HPD state after reboot. The internal HPD block generates the necessary
interrupt, and the display comes up automatically without requiring a
replug event.

This behavior aligns with other Qualcomm reference platforms where,
if the controller’s internal HPD is available, it is preferred over
the external GPIO path. Using the internal HPD provides more reliable
detection and keeps the configuration consistent across platforms.
So, this change ensures:
1. The display recovers correctly after reboot when the cable
remains connected.
2. We leverage the controller’s native HPD interrupt capability for
better reliability.
3. We maintain consistency with other DP-enabled Qualcomm boards that
use internal HPD.
4. edp_hot follows the Source device behavior upon HPD pulse
Detection [VESA DP standard v1.4 section 5.1.4].

I’ll add these details to the commit message in the next revision.

Thanks,
Amit