@@ -414,7 +414,7 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
drm_for_each_bridge_in_chain(encoder, bridge) {
if (!bridge->interlace_allowed)
connector->interlace_allowed = false;
- if (!bridge->ycbcr_420_allowed)
+ if (!bridge->ycbcr_420_allowed && !(bridge->ops & DRM_BRIDGE_OP_HDMI))
connector->ycbcr_420_allowed = false;
if (bridge->ops & DRM_BRIDGE_OP_EDID)
@@ -436,6 +436,10 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
if (bridge->supported_formats)
supported_formats = bridge->supported_formats;
+
+ if (!(bridge->supported_formats & HDMI_COLORSPACE_YUV420))
+ connector->ycbcr_420_allowed = false;
+
if (bridge->max_bpc)
max_bpc = bridge->max_bpc;
}
Bridges having the DRM_BRIDGE_OP_HDMI flag set in drm_bridge->ops are supposed to rely on drm_bridge->supported_formats bitmask to advertise the supported colorspaces, including HDMI_COLORSPACE_YUV420. Therefore, the newly introduced drm_bridge->ycbcr_420_allowed flag becomes redundant in this particular context. Moreover, when drm_bridge_connector gets initialised, only drm_bridge->ycbcr_420_allowed is considered in the process of adjusting the equivalent property of the base drm_connector, which effectively discards the formats advertised by the HDMI bridge. Handle the inconsistency by ignoring ycbcr_420_allowed for HDMI bridges and, instead, make use of the supported_formats bitmask when setting up the bridge connector. Fixes: 3ced1c687512 ("drm/display: bridge_connector: handle ycbcr_420_allowed") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> --- drivers/gpu/drm/display/drm_bridge_connector.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- base-commit: f486c8aa16b8172f63bddc70116a0c897a7f3f02 change-id: 20241130-bridge-conn-fmt-prio-c517c1407ed5