On Fri, Sep 12, 2025 at 09:57:47PM +0300, Marius Vlad wrote: > On Fri, Sep 12, 2025 at 05:31:17PM +0200, Maxime Ripard wrote: > > Hi, > > > > On Thu, Sep 11, 2025 at 08:34:48PM +0300, Marius Vlad wrote: > > > > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c > > > > > b/drivers/gpu/drm/msm/dsi/dsi_manager.c > > > > > index ca400924d4ee..4b87f4f78d38 100644 > > > > > --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c > > > > > +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c > > > > > @@ -479,7 +479,7 @@ int msm_dsi_manager_connector_init(struct msm_dsi > > > > > *msm_dsi, > > > > > if (ret) > > > > > return ret; > > > > > > > > > > - connector = drm_bridge_connector_init(dev, encoder); > > > > > + connector = drm_bridge_connector_init(dev, encoder, > > > > > BIT(HDMI_COLORSPACE_RGB)); > > > > > > > > And this totally depends on the bridge chain. If we have a DSI-to-HDMI > > > > bridge somewhere in the middle, we are able to output YUV data to the > > > > HDMI connector. > > > That's actually the usecase for this patch: to allow passing other color > > > formats, but this patch is a transitory patch to further expose the fact > > > drm_bridge_connector_init was embedding BIT(HDMI_COLORSPACE_RGB) for the > > > format. See rockchip implementation for this bit, the last patch in this > > > series. > > > > I think Dmitry's point is that it needs to be integrated with the > > atomic_get_input_bus_fmt / atomic_get_output_bus_fmt, because not only > > we need to make sure the monitor supports it, and the userspace demands > > it, we also need to make sure every bridge in the chain (and possibly > > the encoder) can implement it. > Oookay. Will be looking at those bits then. Thanks for pointing where > I need to look at. > > tbh it isn't super clear to me why is it now that an issue. If you don't > mind replying back, it this patch actually exposing that, or that was a > thing that had to addressed at one point?
As I wrote, the encoder doesn't know which colorformats are supported at the end of the bridge chain. I think that at some point we will have to redo ycbcr420_supported too. Basically, consider the following chain: encoder -> DSI host -> DSI-to-HDMI bridge -> HDMI connector bridge The DSI host can send RGB only, but then the DSI-to-HDMI bridge might be able to do all the conversion and send YUV 444 or 420 over the wire. The HDMI connector (yes, it's a bridge too) doesn't really care, it just passes the data through. By adding supported_formats to drm_bridge_connector_init() you are insisting on the encoder / root driver knowing what formats are supported. It's not the case. The negotiation should start from the end of the chain and follow back until the bridge which says 'I can do this, no matter what comes in'. -- With best wishes Dmitry
