From: Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com
[ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ]
Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level: it requires reading the DPCD in order to check what kind of device is attached to the port and whether there is an actual display attached.
In order to let DRM framework handle such configurations, disable DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so it is valid for the bridge to report HPD events.
Currently inside the kernel there are only two targets which list hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and arm64/qcom/sa8295p-adp. Both should be fine with this change.
Cc: Bjorn Andersson andersson@kernel.org Cc: Konrad Dybcio konradybcio@kernel.org Cc: linux-arm-msm@vger.kernel.org Acked-by: Laurent Pinchart laurent.pinchart+renesas@ideasonboard.com Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.q... Signed-off-by: Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What it fixes - For DisplayPort connectors using the generic display-connector, detection was based solely on the HPD GPIO, which is insufficient for DP. The DP spec requires reading DPCD to determine sink type/presence; HPD high alone can be a false positive (e.g., adapters/hubs with no actual display). - This patch prevents the generic bridge from advertising “I can detect” for DP, so the DRM framework will delegate detection to the actual DP bridge/driver that can read DPCD.
- Code paths and behavior change - Previously, the generic connector always advertised `DRM_BRIDGE_OP_DETECT` if either DDC was present or an HPD GPIO existed: - `drivers/gpu/drm/bridge/display-connector.c:363` sets `DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT` when `conn->bridge.ddc` exists (DP doesn’t use DDC). - `drivers/gpu/drm/bridge/display-connector.c:367` sets `DRM_BRIDGE_OP_DETECT` whenever `conn->hpd_gpio` exists (this is the problematic path for DP). - The detection callback itself relies on `hpd_gpio` to return connected/disconnected (no DPCD), see `drivers/gpu/drm/bridge/display-connector.c:42`. - The patch changes the HPD path to skip `DRM_BRIDGE_OP_DETECT` for DP: - Replaces the unconditional HPD-based detect flag with: “if `conn->hpd_gpio` and `type != DRM_MODE_CONNECTOR_DisplayPort` then set `DRM_BRIDGE_OP_DETECT`.” Net effect: DP no longer claims detect via HPD only. - `DRM_BRIDGE_OP_HPD` remains enabled if the IRQ is available (`drivers/gpu/drm/bridge/display-connector.c:368-369`), so hotplug events still propagate correctly.
- Why this is correct in DRM’s bridge pipeline - DRM uses the last bridge in the chain that advertises `DRM_BRIDGE_OP_DETECT` to perform detection (`drivers/gpu/drm/display/drm_bridge_connector.c:177-188`). Before this change, that “last” bridge was often the dp-connector (generic) rather than the DP controller bridge, causing HPD-only detection to be used for DP. - By not setting `OP_DETECT` on dp-connector for DP, detection falls back to the DP bridge/driver, which generally implements proper DP detection (reads DPCD). Example: Qualcomm MSM DP sets `DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_HPD` and implements `.detect = dp_bridge_detect()` based on link readiness (`drivers/gpu/drm/msm/dp/dp_drm.c:312-352`).
- Scope and regression risk - Device tree usage audit shows that only two in-tree platforms currently define `hpd-gpios` on `dp-connector` nodes (exactly as the commit states), so the behavioral change is tightly scoped: - `arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts:46` (has `hpd- gpios`) - `arch/arm64/boot/dts/qcom/sa8295p-adp.dts:34,48,62,76,90,104` (several DP/eDP-labelled connectors with `hpd-gpios`) - `DRM_BRIDGE_OP_HPD` still gets set when the GPIO can provide interrupts, so hotplug remains functional. For these platforms, the MSM DP bridge advertises `OP_DETECT`, so detection naturally migrates to the DP driver which reads DPCD. - No architectural changes; the patch is a small, localized condition guarding one flag. It doesn’t alter EDID handling or power control and doesn’t affect non-DP connectors.
- Stable policy fit - This is a correctness fix for user-visible behavior (false “connected” status on DP due to HPD-only detection), small and well- contained, with minimal regression risk. It touches one driver file and only DP behavior when `hpd-gpios` is present on dp-connector nodes. It keeps HPD events intact and defers detect to the proper DP driver as intended by DRM’s bridge design.
Conclusion: Backporting will improve correctness of DP detection with very low risk and no architectural churn.
drivers/gpu/drm/bridge/display-connector.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c index 52b7b5889e6fe..4f0295efb8f68 100644 --- a/drivers/gpu/drm/bridge/display-connector.c +++ b/drivers/gpu/drm/bridge/display-connector.c @@ -373,7 +373,8 @@ static int display_connector_probe(struct platform_device *pdev) if (conn->bridge.ddc) conn->bridge.ops |= DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT; - if (conn->hpd_gpio) + /* Detecting the monitor requires reading DPCD */ + if (conn->hpd_gpio && type != DRM_MODE_CONNECTOR_DisplayPort) conn->bridge.ops |= DRM_BRIDGE_OP_DETECT; if (conn->hpd_irq >= 0) conn->bridge.ops |= DRM_BRIDGE_OP_HPD;