| Message ID | 20241224-bridge-conn-fmt-prio-v4-1-a9ceb5671379@collabora.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Fix ycbcr_420_allowed inconsistency for HDMI bridges | expand |
On Tue, Dec 24, 2024 at 08:22:41PM +0200, Cristian Ciocaltea wrote: > Bridges having DRM_BRIDGE_OP_HDMI set in their ->ops are supposed to > rely on the ->supported_formats bitmask to advertise the permitted > colorspaces, including HDMI_COLORSPACE_YUV420. > > However, a new flag ->ycbcr_420_allowed has been recently introduced, > which brings the necessity to require redundant and potentially > inconsistent information to be provided on HDMI bridges initialization. > > Adjust ->ycbcr_420_allowed for HDMI bridges according to > ->supported_formats, right before adding them to the global bridge list. > This keeps the initialization process straightforward and unambiguous, > thereby preventing any further confusion. > > Fixes: 3ced1c687512 ("drm/display: bridge_connector: handle ycbcr_420_allowed") > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> > --- > drivers/gpu/drm/drm_bridge.c | 4 ++++ > 1 file changed, 4 insertions(+) I'm still slightly torn between this patch and a simple drm_WARN_ON(bridge->dev, bridge->ycbcr_420_allowed != (bridge->supported_formats & BIT(HDMI_COLORSPACE_YUV420))) Nevertheless, Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index c6af46dd02bfa9e15b59e4c460debdd7fd84be44..241a384ebce39b4a3db58c208af27960904fc662 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -207,6 +207,10 @@ void drm_bridge_add(struct drm_bridge *bridge) > { > mutex_init(&bridge->hpd_mutex); > > + if (bridge->ops & DRM_BRIDGE_OP_HDMI) > + bridge->ycbcr_420_allowed = !!(bridge->supported_formats & > + BIT(HDMI_COLORSPACE_YUV420)); > + > mutex_lock(&bridge_lock); > list_add_tail(&bridge->list, &bridge_list); > mutex_unlock(&bridge_lock); > > -- > 2.47.0 >
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index c6af46dd02bfa9e15b59e4c460debdd7fd84be44..241a384ebce39b4a3db58c208af27960904fc662 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -207,6 +207,10 @@ void drm_bridge_add(struct drm_bridge *bridge) { mutex_init(&bridge->hpd_mutex); + if (bridge->ops & DRM_BRIDGE_OP_HDMI) + bridge->ycbcr_420_allowed = !!(bridge->supported_formats & + BIT(HDMI_COLORSPACE_YUV420)); + mutex_lock(&bridge_lock); list_add_tail(&bridge->list, &bridge_list); mutex_unlock(&bridge_lock);
Bridges having DRM_BRIDGE_OP_HDMI set in their ->ops are supposed to rely on the ->supported_formats bitmask to advertise the permitted colorspaces, including HDMI_COLORSPACE_YUV420. However, a new flag ->ycbcr_420_allowed has been recently introduced, which brings the necessity to require redundant and potentially inconsistent information to be provided on HDMI bridges initialization. Adjust ->ycbcr_420_allowed for HDMI bridges according to ->supported_formats, right before adding them to the global bridge list. This keeps the initialization process straightforward and unambiguous, thereby preventing any further confusion. Fixes: 3ced1c687512 ("drm/display: bridge_connector: handle ycbcr_420_allowed") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> --- drivers/gpu/drm/drm_bridge.c | 4 ++++ 1 file changed, 4 insertions(+)