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 <damon.ding@rock-chips.com>
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
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;
+
if (bridge->ops & DRM_BRIDGE_OP_HDMI) {
if (bridge_connector->bridge_hdmi)
return ERR_PTR(-EBUSY);
--
2.34.1
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 <damon.ding@rock-chips.com>
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> ---
>
> 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-667abf6d47c0@bootlin.com
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
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 <damon.ding@rock-chips.com>
>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> ---
>>
>> 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-667abf6d47c0@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
Am Mittwoch, 22. Oktober 2025, 03:15:52 Mitteleuropäische Normalzeit schrieb Damon Ding:
> 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:
> >
> > 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-667abf6d47c0@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. :-)
I think with 6.19-rc1 out, now is a great time for v8? :-)
Heiko
Hi Heiko,
On 12/16/2025 9:48 PM, Heiko Stuebner wrote:
> Am Mittwoch, 22. Oktober 2025, 03:15:52 Mitteleuropäische Normalzeit schrieb Damon Ding:
>> 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:
>
>>>
>>> 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-667abf6d47c0@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. :-)
>
> I think with 6.19-rc1 out, now is a great time for v8? :-)
>
Agreed! Luca's patches have been merged. I will reconfirm these commits
on the latest branch and update v8 in a few day. :-)
Best regards,
Damon
© 2016 - 2025 Red Hat, Inc.