arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 3 --- 1 file changed, 3 deletions(-)
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
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
>
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
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
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
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
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
>>
>
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;
> };
>
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;
>> };
>>
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
© 2016 - 2026 Red Hat, Inc.