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

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

[Amit Singh]

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.

Fixes: 756efb7cb7293 ("arm64: dts: qcom: qcs6490-rb3gen2: Add DP output")
Signed-off-by: Amit Singh <quic_amitsi@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index c146161e4bb4..caa0b6784df3 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -49,8 +49,6 @@ dp-connector {
 		label = "DP";
 		type = "mini";
 
-		hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
-
 		port {
 			dp_connector_in: endpoint {
 				remote-endpoint = <&mdss_edp_out>;
@@ -1420,7 +1418,6 @@ &wifi {
 /* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
 
 &edp_hot_plug_det {
-	function = "gpio";
 	bias-disable;
 };
 
-- 
2.34.1

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

[Konrad Dybcio]

On 10/31/25 9:57 AM, 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.
> 
> Fixes: 756efb7cb7293 ("arm64: dts: qcom: qcs6490-rb3gen2: Add DP output")
> Signed-off-by: Amit Singh <quic_amitsi@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index c146161e4bb4..caa0b6784df3 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -49,8 +49,6 @@ dp-connector {
>  		label = "DP";
>  		type = "mini";
>  
> -		hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;

I think this change will take away DRM_BRIDGE_OP_DETECT which is very
much desired to have.. (via display_connector_probe())

Konrad

> -
>  		port {
>  			dp_connector_in: endpoint {
>  				remote-endpoint = <&mdss_edp_out>;
> @@ -1420,7 +1418,6 @@ &wifi {
>  /* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
>  
>  &edp_hot_plug_det {
> -	function = "gpio";
>  	bias-disable;
>  };
>  

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

[Amit Singh]

On 10/31/2025 2:37 PM, Konrad Dybcio wrote:
> On 10/31/25 9:57 AM, 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.
>>
>> Fixes: 756efb7cb7293 ("arm64: dts: qcom: qcs6490-rb3gen2: Add DP output")
>> Signed-off-by: Amit Singh <quic_amitsi@quicinc.com>
>> ---
>>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index c146161e4bb4..caa0b6784df3 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> @@ -49,8 +49,6 @@ dp-connector {
>>  		label = "DP";
>>  		type = "mini";
>>  
>> -		hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> 
> I think this change will take away DRM_BRIDGE_OP_DETECT which is very
> much desired to have.. (via display_connector_probe())
> 
> Konrad

Yes, this change will indeed remove DRM_BRIDGE_OP_DETECT.
We'll be relying on the internal HPD line (edp_hot) that's directly connected to the DP controller instead.

Do you foresee any specific issues with this approach?

> 
>> -
>>  		port {
>>  			dp_connector_in: endpoint {
>>  				remote-endpoint = <&mdss_edp_out>;
>> @@ -1420,7 +1418,6 @@ &wifi {
>>  /* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
>>  
>>  &edp_hot_plug_det {
>> -	function = "gpio";
>>  	bias-disable;
>>  };
>>  

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

[Konrad Dybcio]

On 11/6/25 9:23 AM, Amit Singh wrote:
> 
> 
> On 10/31/2025 2:37 PM, Konrad Dybcio wrote:
>> On 10/31/25 9:57 AM, 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.
>>>
>>> Fixes: 756efb7cb7293 ("arm64: dts: qcom: qcs6490-rb3gen2: Add DP output")
>>> Signed-off-by: Amit Singh <quic_amitsi@quicinc.com>
>>> ---
>>>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>>> index c146161e4bb4..caa0b6784df3 100644
>>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>>> @@ -49,8 +49,6 @@ dp-connector {
>>>  		label = "DP";
>>>  		type = "mini";
>>>  
>>> -		hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
>>
>> I think this change will take away DRM_BRIDGE_OP_DETECT which is very
>> much desired to have.. (via display_connector_probe())
>>
>> Konrad
> 
> Yes, this change will indeed remove DRM_BRIDGE_OP_DETECT.
> We'll be relying on the internal HPD line (edp_hot) that's directly connected to the DP controller instead.
> 
> Do you foresee any specific issues with this approach?

No, looks like I was overly cautious

Konrad

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

[Dmitry Baryshkov]

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

HPD, GPIO

> not support interrupt generation.

This is not true. GPIOs support interrupt generation.

> This change removes the generic

Documentation/process/submitting-patches.rst, see the paragraph around
"This patch" words.

> hpd-gpios property and assigns the edp_hot function to the pin,
> enabling proper irq support.

What for?

> 
> Fixes: 756efb7cb7293 ("arm64: dts: qcom: qcs6490-rb3gen2: Add DP output")
> Signed-off-by: Amit Singh <quic_amitsi@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index c146161e4bb4..caa0b6784df3 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -49,8 +49,6 @@ dp-connector {
>  		label = "DP";
>  		type = "mini";
>  
> -		hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> -
>  		port {
>  			dp_connector_in: endpoint {
>  				remote-endpoint = <&mdss_edp_out>;
> @@ -1420,7 +1418,6 @@ &wifi {
>  /* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
>  
>  &edp_hot_plug_det {
> -	function = "gpio";
>  	bias-disable;
>  };
>  
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

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

[Amit Singh]

On 11/1/2025 2:48 PM, Dmitry Baryshkov 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
> 
> HPD, GPIO

Sure, will update in next version.

> 
>> not support interrupt generation.
> 
> This is not true. GPIOs support interrupt generation.

Will update the commit message.

> 
>> This change removes the generic
> 
> Documentation/process/submitting-patches.rst, see the paragraph around
> "This patch" words.

Sure, will follow the guidelines. 

> 
>> hpd-gpios property and assigns the edp_hot function to the pin,
>> enabling proper irq support.
> 
> What for?

I'll update more details in the commit message.

> 
>>
>> Fixes: 756efb7cb7293 ("arm64: dts: qcom: qcs6490-rb3gen2: Add DP output")
>> Signed-off-by: Amit Singh <quic_amitsi@quicinc.com>
>> ---
>>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index c146161e4bb4..caa0b6784df3 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> @@ -49,8 +49,6 @@ dp-connector {
>>  		label = "DP";
>>  		type = "mini";
>>  
>> -		hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
>> -
>>  		port {
>>  			dp_connector_in: endpoint {
>>  				remote-endpoint = <&mdss_edp_out>;
>> @@ -1420,7 +1418,6 @@ &wifi {
>>  /* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
>>  
>>  &edp_hot_plug_det {
>> -	function = "gpio";
>>  	bias-disable;
>>  };
>>  
>> -- 
>> 2.34.1
>>
> 

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

[Bjorn Andersson]

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

> Fixes: 756efb7cb7293 ("arm64: dts: qcom: qcs6490-rb3gen2: Add DP output")
> Signed-off-by: Amit Singh <quic_amitsi@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index c146161e4bb4..caa0b6784df3 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -49,8 +49,6 @@ dp-connector {
>  		label = "DP";
>  		type = "mini";
>  
> -		hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> -
>  		port {
>  			dp_connector_in: endpoint {
>  				remote-endpoint = <&mdss_edp_out>;
> @@ -1420,7 +1418,6 @@ &wifi {
>  /* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
>  
>  &edp_hot_plug_det {
> -	function = "gpio";
>  	bias-disable;
>  };
>  
> -- 
> 2.34.1
> 

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

[Amit Singh]

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

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

[Dmitry Baryshkov]

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.

> 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.

> 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

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