drivers/gpu/drm/bridge/ite-it66121.c | 121 ++++++++++++++++++++++++++++++++--- 1 file changed, 112 insertions(+), 9 deletions(-)
From: Aradhya Bhatia <a-bhatia1@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]
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com>
---
drivers/gpu/drm/bridge/ite-it66121.c | 121 ++++++++++++++++++++++++++++++++---
1 file changed, 112 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c
index aa7b1dcc5d70e5d15199e071e4cd96e08b4bda1b..cd1d926fed8560fb5f8e1ab585b9bf72a70ee8e3 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -284,6 +284,10 @@
#define IT66121_AFE_CLK_HIGH 80000 /* Khz */
+#define IT66121_MAX_CLOCK_12BIT 74250 /* Khz */
+#define IT66121_MAX_CLOCK_24BIT 148500 /* Khz */
+#define IT66121_MIN_CLOCK 25000 /* Khz */
+
enum chip_id {
ID_IT6610,
ID_IT66121,
@@ -299,6 +303,7 @@ struct it66121_ctx {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector *connector;
+ struct drm_connector conn;
struct device *dev;
struct gpio_desc *gpio_reset;
struct i2c_client *client;
@@ -315,6 +320,11 @@ struct it66121_ctx {
const struct it66121_chip_info *info;
};
+static inline struct it66121_ctx *connector_to_it66121(struct drm_connector *con)
+{
+ return container_of(con, struct it66121_ctx, conn);
+}
+
static const struct regmap_range_cfg it66121_regmap_banks[] = {
{
.name = "it66121",
@@ -585,19 +595,112 @@ static bool it66121_is_hpd_detect(struct it66121_ctx *ctx)
return val & IT66121_SYS_STATUS_HPDETECT;
}
+static enum drm_mode_status it66121_mode_valid(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
+{
+ struct it66121_ctx *ctx = connector_to_it66121(connector);
+ unsigned long max_clock;
+
+ max_clock = (ctx->bus_width == 12) ? IT66121_MAX_CLOCK_12BIT : IT66121_MAX_CLOCK_24BIT;
+
+ if (mode->clock > max_clock)
+ return MODE_CLOCK_HIGH;
+
+ if (mode->clock < 25000)
+ return MODE_CLOCK_LOW;
+
+ return MODE_OK;
+}
+
+static const struct drm_edid *it66121_get_edid(struct it66121_ctx *ctx,
+ struct drm_connector *connector)
+{
+ const struct drm_edid *drm_edid;
+
+ mutex_lock(&ctx->lock);
+ drm_edid = drm_edid_read_custom(connector, it66121_get_edid_block, ctx);
+ mutex_unlock(&ctx->lock);
+
+ return drm_edid;
+}
+
+static int it66121_get_modes(struct drm_connector *connector)
+{
+ struct it66121_ctx *ctx = connector_to_it66121(connector);
+ const struct drm_edid *drm_edid;
+ int num = 0;
+
+ drm_edid = it66121_get_edid(ctx, connector);
+ drm_edid_connector_update(connector, drm_edid);
+ if (drm_edid) {
+ num = drm_edid_connector_add_modes(connector);
+ drm_edid_free(drm_edid);
+ }
+
+ return num;
+}
+
+static const struct drm_connector_helper_funcs it66121_connector_helper_funcs = {
+ .get_modes = it66121_get_modes,
+ .mode_valid = it66121_mode_valid,
+};
+
+static enum drm_connector_status
+it66121_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct it66121_ctx *ctx = connector_to_it66121(connector);
+
+ return it66121_is_hpd_detect(ctx) ? connector_status_connected
+ : connector_status_disconnected;
+}
+
+static const struct drm_connector_funcs it66121_connector_funcs = {
+ .detect = it66121_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
static int it66121_bridge_attach(struct drm_bridge *bridge,
struct drm_encoder *encoder,
enum drm_bridge_attach_flags flags)
{
struct it66121_ctx *ctx = container_of(bridge, struct it66121_ctx, bridge);
+ u32 bus_format;
int ret;
- if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
- return -EINVAL;
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+ ret = drm_bridge_attach(encoder, ctx->next_bridge, bridge, flags);
+ if (ret)
+ return ret;
+ } else {
+ if (ctx->bus_width == 12) {
+ bus_format = MEDIA_BUS_FMT_RGB888_2X12_LE;
+ } else if (ctx->bus_width == 24) {
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ } else {
+ dev_err(ctx->dev, "Invalid bus width\n");
+ return -EINVAL;
+ }
- ret = drm_bridge_attach(encoder, ctx->next_bridge, bridge, flags);
- if (ret)
- return ret;
+ drm_connector_helper_add(&ctx->conn,
+ &it66121_connector_helper_funcs);
+
+ ret = drm_connector_init(bridge->dev, &ctx->conn,
+ &it66121_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
+ if (ret)
+ return ret;
+
+ ret = drm_display_info_set_bus_formats(&ctx->conn.display_info,
+ &bus_format, 1);
+ if (ret)
+ return ret;
+
+ drm_connector_attach_encoder(&ctx->conn, bridge->encoder);
+ }
if (ctx->info->id == ID_IT66121) {
ret = regmap_write_bits(ctx->regmap, IT66121_CLK_BANK_REG,
@@ -830,14 +933,14 @@ static enum drm_mode_status it66121_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
{
struct it66121_ctx *ctx = container_of(bridge, struct it66121_ctx, bridge);
- unsigned long max_clock;
+ unsigned long max_clock_khz;
- max_clock = (ctx->bus_width == 12) ? 74250 : 148500;
+ max_clock_khz = (ctx->bus_width == 12) ? IT66121_MAX_CLOCK_12BIT : IT66121_MAX_CLOCK_24BIT;
- if (mode->clock > max_clock)
+ if (mode->clock > max_clock_khz)
return MODE_CLOCK_HIGH;
- if (mode->clock < 25000)
+ if (mode->clock < IT66121_MIN_CLOCK)
return MODE_CLOCK_LOW;
return MODE_OK;
---
base-commit: 9e05c8dc4e8bb14bdb86eccff1d07169cfd69df8
change-id: 20250905-it66121-fix-1bd3888759b1
Best regards,
--
Miguel Gazquez <miguel.gazquez@bootlin.com>On Tue, Sep 09, 2025 at 06:16:43PM +0200, Miguel Gazquez wrote: > From: Aradhya Bhatia <a-bhatia1@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? > > Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> > Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com> > --- > drivers/gpu/drm/bridge/ite-it66121.c | 121 ++++++++++++++++++++++++++++++++--- > 1 file changed, 112 insertions(+), 9 deletions(-) -- With best wishes Dmitry
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@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. > >> >> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> >> Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com> >> --- >> drivers/gpu/drm/bridge/ite-it66121.c | 121 ++++++++++++++++++++++++++++++++--- >> 1 file changed, 112 insertions(+), 9 deletions(-) > -- Miguel Gazquez, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
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@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. Maxime
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@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. > > Maxime -- Miguel Gazquez, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
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@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. -- With best wishes Dmitry
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@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. On top of that, having the it66121 handle both cases makes it compatible with display controllers that don’t use DRM_BRIDGE_ATTACH_NO_CONNECTOR, which are still fairly common. -- Miguel Gazquez, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
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@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 ? -- Miguel Gazquez, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
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-bhatia1@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
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-bhatia1@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 ? There's only so much we can do, and we can't fix issues we can't know about. So no. Maxime
© 2016 - 2025 Red Hat, Inc.