Hi Luca,

On 10/21/2025 6:31 PM, Luca Ceresoli wrote:
Hello Damon,

On Tue Oct 21, 2025 at 4:31 AM CEST, Damon Ding wrote:
When multiple bridges are present, EDID detection capability
(DRM_BRIDGE_OP_EDID) takes precedence over modes detection
(DRM_BRIDGE_OP_MODES). To ensure the above two capabilities are
determined by the last bridge in the chain, we handle three cases:

Case 1: The later bridge declares only DRM_BRIDGE_OP_MODES
  - If the previous bridge declares DRM_BRIDGE_OP_EDID, set
    &drm_bridge_connector.bridge_edid to NULL and set
    &drm_bridge_connector.bridge_modes to the later bridge.
  - Ensure modes detection capability of the later bridge will not
    be ignored.

Case 2: The later bridge declares only DRM_BRIDGE_OP_EDID
  - If the previous bridge declares DRM_BRIDGE_OP_MODES, set
    &drm_bridge_connector.bridge_modes to NULL and set
    &drm_bridge_connector.bridge_edid to the later bridge.
  - Although EDID detection capability has higher priority, this
    operation is for balance and makes sense.

Case 3: the later bridge declares both of them
  - Assign later bridge as &drm_bridge_connector.bridge_edid and
    and &drm_bridge_connector.bridge_modes to this bridge.
  - Just leave transfer of these two capabilities as before.

Signed-off-by: Damon Ding <[email protected]>
Suggested-by: Dmitry Baryshkov <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>

---

Changes in v7:
- As Luca suggested, simplify the code and related comment.
---
  drivers/gpu/drm/display/drm_bridge_connector.c | 16 ++++++++++++----
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c 
b/drivers/gpu/drm/display/drm_bridge_connector.c
index baacd21e7341..7c2936d59517 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -673,14 +673,22 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
                if (!bridge->ycbcr_420_allowed)
                        connector->ycbcr_420_allowed = false;

-               if (bridge->ops & DRM_BRIDGE_OP_EDID)
-                       bridge_connector->bridge_edid = bridge;
+               /*
+                * Ensure the last bridge declares OP_EDID or OP_MODES or both.
+                */
+               if (bridge->ops & DRM_BRIDGE_OP_EDID || bridge->ops & 
DRM_BRIDGE_OP_MODES) {
+                       bridge_connector->bridge_edid = NULL;
+                       bridge_connector->bridge_modes = NULL;
+                       if (bridge->ops & DRM_BRIDGE_OP_EDID)
+                               bridge_connector->bridge_edid = bridge;
+                       if (bridge->ops & DRM_BRIDGE_OP_MODES)
+                               bridge_connector->bridge_modes = bridge;
+               }
                if (bridge->ops & DRM_BRIDGE_OP_HPD)
                        bridge_connector->bridge_hpd = bridge;
                if (bridge->ops & DRM_BRIDGE_OP_DETECT)
                        bridge_connector->bridge_detect = bridge;
-               if (bridge->ops & DRM_BRIDGE_OP_MODES)
-                       bridge_connector->bridge_modes = bridge;
+

This does not apply on current drm-misc-next, due to the patch I mentioned
in a previous iteration, now applied as commit 2be300f9a0b6 ("drm/display:
bridge_connector: get/put the stored bridges").

However I'm sorry I have to mention that patch turned out being buggy, so
I've sent a series to apply a corrected version [0]. I suggest watching the
disucssion about the fix series, and if that gets approved rebase on top of
that and adapt your changes.

Sorry about the mess. :(

[0] 
https://lore.kernel.org/r/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-0-667abf6d4...@bootlin.com



I saw your fix patches before sending this series. I think your patches will likely be merged relatively quickly, so I plan to wait until the other patches in my patch series are confirmed to be fine, then submit v8 version based on the latest bridge_connector driver. :-)

Best regards,
Damon

Reply via email to