Re: [PATCH] drm/bridge: ite-it66121: Add drm_connector support

From: Miguel Gazquez

Date: Thu Sep 11 2025 - 11:48:07 EST




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-bhatia1@xxxxxx>

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 ?

--
Miguel Gazquez, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com