On Thu, Sep 11, 2025 at 05:47:57PM +0200, Miguel Gazquez wrote: > > > Le 11/09/2025 à 17:40, Miguel Gazquez a écrit : > > > > > > Le 11/09/2025 à 15:09, Dmitry Baryshkov a écrit : > > > On Thu, Sep 11, 2025 at 02:49:59PM +0200, Miguel Gazquez wrote: > > > > > > > > > > > > Le 11/09/2025 à 11:50, Maxime Ripard a écrit : > > > > > On Thu, Sep 11, 2025 at 10:51:06AM +0200, Miguel Gazquez wrote: > > > > > > > > > > > > > > > > > > Le 10/09/2025 à 04:28, Dmitry Baryshkov a écrit : > > > > > > > On Tue, Sep 09, 2025 at 06:16:43PM +0200, Miguel Gazquez wrote: > > > > > > > > From: Aradhya Bhatia <a-bhat...@ti.com> > > > > > > > > > > > > > > > > Add support for DRM connector and make the driver support the > > > > > > > > older > > > > > > > > format of attaching connectors onto the > > > > > > > > encoder->bridge->connector > > > > > > > > chain. > > > > > > > > This makes the driver compatible with display controller that > > > > > > > > only > > > > > > > > supports the old format. > > > > > > > > > > > > > > > > [Miguel Gazquez: Rebased + made driver work with or without > > > > > > > > DRM_BRIDGE_ATTACH_NO_CONNECTOR] > > > > > > > > > > > > > > What is the use case for not using DRM_BRIDGE_ATTACH_NO_CONNECTOR? > > > > > > > > > > > > Some display controller drivers (like the tilcdc) call > > > > > > drm_bridge_attach > > > > > > without DRM_BRIDGE_ATTACH_NO_CONNECTOR, so the bridge > > > > > > must support both with > > > > > > and without DRM_BRIDGE_ATTACH_NO_CONNECTOR to be > > > > > > compatible with all display > > > > > > controllers. > > > > > > > > > > I'd rather convert tilcdc to use DRM_BRIDGE_ATTACH_NO_CONNECTOR then. > > > > > > > > The problem is that doing that break devicetrees using the tilcdc and a > > > > bridge who doesn't support DRM_BRIDGE_ATTACH_NO_CONNECTOR (there are > > > > multiple bridges that don't support > > > > DRM_BRIDGE_ATTACH_NO_CONNECTOR), and if > > > > my understanding is correct breaking devicetrees is not allowed. > > > > > > How does it break devicetree? The drm_bridge_connector isn't a part of > > > DT. > > > > > > In the current situation, a board could have the tilcdc linked with a > > bridge that does not support DRM_BRIDGE_ATTACH_NO_CONNECTOR (for > > example, the analogix-anx6345) , and everything will work fine. > > If we convert the tilcdc to always use DRM_BRIDGE_ATTACH_NO_CONNECTOR, > > that same configuration will stop working. > > > > When I said "breaking devicetree" I meant that a devicetree describing > > this setup would no longer produce a working system, not that the DT > > files or bindings themselves are incorrect. > > I didn't find any upstream dts with this configuration, but maybe there > > is some out-of-tree dts which would be affected. > > As far as I understand, we should avoid that. > > > > If I can rephrase myself, is my understanding correct ? Do we care about > breaking out-of-tree dts ?
>From my practice: only in a very limited way, if there are well-known out-of-tree DTS (e.g. we kept some bits and pieces of panel code because of out-of-tree ChromeBook devices). But you can easility keep compatibility: inside the ticldc driver first try attaching the bridge with the flag set, then, if it fails, try attaching without the flag. Add dev_warn() and some grace period. his was the path that we used to migrate the drm/msm/dsi: enable DRM_BRIDGE_ATTACH_NO_CONNECTOR by default, keeping legacy support in place, then drop legacy after some time after converting all users. -- With best wishes Dmitry
