mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Amit Singh <quic_amitsi@quicinc.com>
To: Bjorn Andersson <andersson@kernel.org>
Cc: <konradybcio@kernel.org>, <robh@kernel.org>, <krzk+dt@kernel.org>,
	<conor+dt@kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<quic_riteshk@quicinc.com>, <quic_rajeevny@quicinc.com>,
	<quic_vproddut@quicinc.com>
Subject: Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Use 'edp_hot' function for hpd gpio
Date: Thu, 6 Nov 2025 15:01:07 +0530	[thread overview]
Message-ID: <c6ef0324-c932-4c80-8252-97dd3ee255d3@quicinc.com> (raw)
In-Reply-To: <nzg7auudxocxnpnjsc2emot7sgh5azvucl72jqzgqsp4jhzint@hykb2xyx66uh>



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

  reply	other threads:[~2025-11-06  9:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-31  8:57 Amit Singh
2025-10-31  9:07 ` Konrad Dybcio
2025-11-06  8:23   ` Amit Singh
2025-11-06 10:24     ` Konrad Dybcio
2025-11-01  9:18 ` Dmitry Baryshkov
2025-11-06  8:29   ` Amit Singh
2025-11-01 18:59 ` Bjorn Andersson
2025-11-06  9:31   ` Amit Singh [this message]
2025-11-11 15:14     ` Dmitry Baryshkov
2025-11-11 16:47       ` Bjorn Andersson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6ef0324-c932-4c80-8252-97dd3ee255d3@quicinc.com \
    --to=quic_amitsi@quicinc.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_rajeevny@quicinc.com \
    --cc=quic_riteshk@quicinc.com \
    --cc=quic_vproddut@quicinc.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®