Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Use 'edp_hot' function for hpd gpio

[Bjorn Andersson]

On Tue, Nov 11, 2025 at 05:14:54PM +0200, Dmitry Baryshkov wrote:
> On Thu, Nov 06, 2025 at 03:01:07PM +0530, Amit Singh wrote:
> > 
> > 
> > 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.
> 
> You are describing driver behaviour. It is known that this part of the
> DP driver is broken. There is nothing wrong with using HPD pin as a GPIO
> in the DP connector.
> 

I agree.

> > 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.
> 
> I think, this DT might have been purposedly written in order to show how
> the HPD signals can be coming from the GPIO pin through the external
> bridge. As such I'm really reluctant to ack this change.
> 

That is correct, I explicitly wanted to describe the connector and the
HPD signal therein, and at the time of merging this worked (I was even
under the impression that we do get the right HPD state at boot and
bring up the display, but it's been a while so I'm not 100% certain that
I tested that scenario).

I'm fine with dropping the hpd-gpios for reasons such that the HPD
hardware does a better job at HPD handling - but that's not what we have
here. So I share your reluctance.


PS. Using the internal HPD for detection implies that we need to keep
the DP block powered and (partially) clocked, so we should at some point
figure out how to dynamically switch between GPIO and HPD...

Regards,
Bjorn

> > 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
> 
> -- 
> With best wishes
> Dmitry