The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
can operate in two different modes, depending on the platform data as set
by the driver:
A. hdmi->plat_data->output_port = 0:
the HDMI output (port@1) in device tree is not used [0]
B. hdmi->plat_data->output_port = 1:
the HDMI output (port@1) is parsed to find the next bridge
The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
in that case it adds the connector programmatically at bridge attach time.
Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
However this change requires that port@1 is connected to a "next
bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Many dts files for imx8mp-based boards in the kernel have such a connector
described and linked to port@1, so a connector is added by the
display-connector driver along with a bridge wrapping it. Sadly some of
those dts files don't have the connector described. Adding it would solve
the problem easily, but this would break existing devices which do not
update the dtb when upgrading to a newer kernel.
To preserve backward compatibility for such devices, introduce a module
adding the hdmi-connector node to the live device tree at init time. This
allows the dw-hdmi code to find the next bridge (the one wrapping the
hdmi-connector) and let the pipeline work as before.
[0] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
[1] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2907
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
This patch is inspired by commit 0ff223d99147 ("drm/tilcdc: Convert legacy
panel binding via DT overlay at boot time")
---
drivers/gpu/drm/bridge/imx/Kconfig | 17 ++++++
drivers/gpu/drm/bridge/imx/Makefile | 2 +
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 60 ++++++++++++++++++++++
.../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 38 ++++++++++++++
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
5 files changed, 118 insertions(+)
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
index b9028a5e5a06..b9ce140a93dc 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
Choose this to enable support for the internal HDMI encoder found
on the i.MX8MP SoC.
+config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
+ bool "Support device tree blobs without an hdmi-connector node"
+ default y
+ depends on DRM_IMX8MP_DW_HDMI_BRIDGE
+ depends on OF
+ select OF_OVERLAY
+ select DRM_DISPLAY_CONNECTOR
+ help
+ Modifies at early boot the live device tree of boards using the
+ i.MX8MP fsl,imx8mp-hdmi-tx adding a hdmi-connector node linked to
+ the htmi-tx. This is needed to support bridge-connector usage in
+ the i.MX8MP LCDIF driver.
+
+ You need this if you use the i.MX8MP HDMI output and your board
+ device tree file does not have an hdmi-connector node connected
+ to it.
+
config DRM_IMX8MP_HDMI_PAI
tristate "Freescale i.MX8MP HDMI PAI bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
index 8d01fda25451..84499fe2e444 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,6 +1,8 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
obj-$(CONFIG_DRM_IMX_LEGACY_BRIDGE) += imx-legacy-bridge.o
obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE) += imx8mp-hdmi-tx.o
+obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP) += imx8mp-hdmi-tx-connector-fixup.o \
+ imx8mp-hdmi-tx-connector-fixup.dtbo.o
obj-$(CONFIG_DRM_IMX8MP_HDMI_PAI) += imx8mp-hdmi-pai.o
obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
new file mode 100644
index 000000000000..8c423b9bfa50
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Add an hdmi-connector node to boards using the imx8mp hdmi_tx which
+ * don't have one. This is needed for the i.MX LCDIF to work with
+ * DRM_BRIDGE_ATTACH_NO_CONNECTOR.
+ *
+ * Copyright (C) 2026 GE HealthCare
+ * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/slab.h>
+
+/* Embedded dtbo symbols created by cmd_wrap_S_dtb in scripts/Makefile.dtbs */
+extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_begin[];
+extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_end[];
+
+static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
+{
+ struct device_node *hdmi_tx __free(device_node) = NULL;
+ struct device_node *endpoint __free(device_node) = NULL;
+ struct device_node *hdmi_conn __free(device_node) = NULL;
+ void *dtbo_start;
+ u32 dtbo_size;
+ int ovcs_id;
+ int err;
+
+ hdmi_tx = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000");
+ if (!of_device_is_available(hdmi_tx))
+ return 0;
+
+ /* If endpoint exists, assume an hdmi-connector exists already */
+ endpoint = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1/endpoint");
+ if (endpoint)
+ return 0;
+
+ dtbo_start = __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
+ dtbo_size = __dtbo_imx8mp_hdmi_tx_connector_fixup_end -
+ __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
+
+ err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
+ if (err)
+ return err;
+
+ hdmi_conn = of_find_node_by_name(NULL, "fixup-hdmi-connector");
+ if (!hdmi_conn) {
+ err = -ENODEV;
+ goto overlay_remove;
+ }
+
+ return 0;
+
+overlay_remove:
+ of_overlay_remove(&ovcs_id);
+ return err;
+}
+
+subsys_initcall(imx8mp_hdmi_tx_connector_fixup_init);
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
new file mode 100644
index 000000000000..ee718ca1b11b
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
+ *
+ * Copyright (C) 2026 GE HealthCare
+ * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ fixup-hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "HDMI";
+ type = "a";
+
+ port {
+ fixup_hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ soc@0 {
+ bus@32c00000 {
+ hdmi@32fd8000 {
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&fixup_hdmi_connector_in>;
+ };
+ };
+ };
+ };
+ };
+ };
+};
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
index 32fd3554e267..8e8cfd66f23b 100644
--- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
@@ -138,6 +138,7 @@ static int imx8mp_dw_hdmi_probe(struct platform_device *pdev)
plat_data->phy_name = "SAMSUNG HDMI TX PHY";
plat_data->priv_data = hdmi;
plat_data->phy_force_vendor = true;
+ plat_data->output_port = 1;
platform_set_drvdata(pdev, hdmi);
--
2.53.0Hi Luca,
On Fri, Mar 20, 2026 at 11:46:18AM +0100, Luca Ceresoli wrote:
> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
> can operate in two different modes, depending on the platform data as set
> by the driver:
>
> A. hdmi->plat_data->output_port = 0:
> the HDMI output (port@1) in device tree is not used [0]
>
> B. hdmi->plat_data->output_port = 1:
> the HDMI output (port@1) is parsed to find the next bridge
>
> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>
> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
> in that case it adds the connector programmatically at bridge attach time.
>
> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
> case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
> imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
>
> However this change requires that port@1 is connected to a "next
> bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
> the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Many dts files for imx8mp-based boards in the kernel have such a connector
> described and linked to port@1, so a connector is added by the
> display-connector driver along with a bridge wrapping it. Sadly some of
> those dts files don't have the connector described. Adding it would solve
> the problem easily, but this would break existing devices which do not
> update the dtb when upgrading to a newer kernel.
I think this series should also fix the in-tree dts files, to pave the
way for removing the workaround.
> To preserve backward compatibility for such devices, introduce a module
> adding the hdmi-connector node to the live device tree at init time. This
> allows the dw-hdmi code to find the next bridge (the one wrapping the
> hdmi-connector) and let the pipeline work as before.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
> [1] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2907
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> This patch is inspired by commit 0ff223d99147 ("drm/tilcdc: Convert legacy
> panel binding via DT overlay at boot time")
> ---
> drivers/gpu/drm/bridge/imx/Kconfig | 17 ++++++
> drivers/gpu/drm/bridge/imx/Makefile | 2 +
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 60 ++++++++++++++++++++++
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 38 ++++++++++++++
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
> 5 files changed, 118 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
> index b9028a5e5a06..b9ce140a93dc 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
> Choose this to enable support for the internal HDMI encoder found
> on the i.MX8MP SoC.
>
> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
> + bool "Support device tree blobs without an hdmi-connector node"
> + default y
Can't we enable the workaround unconditionally ? Distributions will need
to enable this option anyway as they can't know what device they will
boot on. I fear a configuration option will confuse users and waste time
on debugging.
> + depends on DRM_IMX8MP_DW_HDMI_BRIDGE
> + depends on OF
> + select OF_OVERLAY
> + select DRM_DISPLAY_CONNECTOR
> + help
> + Modifies at early boot the live device tree of boards using the
> + i.MX8MP fsl,imx8mp-hdmi-tx adding a hdmi-connector node linked to
> + the htmi-tx. This is needed to support bridge-connector usage in
> + the i.MX8MP LCDIF driver.
> +
> + You need this if you use the i.MX8MP HDMI output and your board
> + device tree file does not have an hdmi-connector node connected
> + to it.
> +
> config DRM_IMX8MP_HDMI_PAI
> tristate "Freescale i.MX8MP HDMI PAI bridge support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
> index 8d01fda25451..84499fe2e444 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,6 +1,8 @@
> obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> obj-$(CONFIG_DRM_IMX_LEGACY_BRIDGE) += imx-legacy-bridge.o
> obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE) += imx8mp-hdmi-tx.o
> +obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP) += imx8mp-hdmi-tx-connector-fixup.o \
> + imx8mp-hdmi-tx-connector-fixup.dtbo.o
> obj-$(CONFIG_DRM_IMX8MP_HDMI_PAI) += imx8mp-hdmi-pai.o
> obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
> obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> new file mode 100644
> index 000000000000..8c423b9bfa50
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> @@ -0,0 +1,60 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Add an hdmi-connector node to boards using the imx8mp hdmi_tx which
> + * don't have one. This is needed for the i.MX LCDIF to work with
> + * DRM_BRIDGE_ATTACH_NO_CONNECTOR.
> + *
> + * Copyright (C) 2026 GE HealthCare
> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/slab.h>
> +
> +/* Embedded dtbo symbols created by cmd_wrap_S_dtb in scripts/Makefile.dtbs */
> +extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_begin[];
> +extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_end[];
> +
> +static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
> +{
> + struct device_node *hdmi_tx __free(device_node) = NULL;
> + struct device_node *endpoint __free(device_node) = NULL;
> + struct device_node *hdmi_conn __free(device_node) = NULL;
> + void *dtbo_start;
> + u32 dtbo_size;
> + int ovcs_id;
> + int err;
> +
> + hdmi_tx = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000");
> + if (!of_device_is_available(hdmi_tx))
> + return 0;
> +
> + /* If endpoint exists, assume an hdmi-connector exists already */
> + endpoint = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1/endpoint");
> + if (endpoint)
> + return 0;
> +
> + dtbo_start = __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
> + dtbo_size = __dtbo_imx8mp_hdmi_tx_connector_fixup_end -
> + __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
> +
> + err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
> + if (err)
> + return err;
> +
> + hdmi_conn = of_find_node_by_name(NULL, "fixup-hdmi-connector");
> + if (!hdmi_conn) {
> + err = -ENODEV;
> + goto overlay_remove;
> + }
> +
> + return 0;
> +
> +overlay_remove:
> + of_overlay_remove(&ovcs_id);
> + return err;
> +}
> +
> +subsys_initcall(imx8mp_hdmi_tx_connector_fixup_init);
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> new file mode 100644
> index 000000000000..ee718ca1b11b
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
> + *
> + * Copyright (C) 2026 GE HealthCare
> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
> + fixup-hdmi-connector {
> + compatible = "hdmi-connector";
> + label = "HDMI";
> + type = "a";
> +
> + port {
> + fixup_hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_out>;
> + };
> + };
> + };
> +
> + soc@0 {
> + bus@32c00000 {
> + hdmi@32fd8000 {
> + ports {
> + port@1 {
> + hdmi_tx_out: endpoint {
> + remote-endpoint = <&fixup_hdmi_connector_in>;
> + };
> + };
> + };
> + };
> + };
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> index 32fd3554e267..8e8cfd66f23b 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> @@ -138,6 +138,7 @@ static int imx8mp_dw_hdmi_probe(struct platform_device *pdev)
> plat_data->phy_name = "SAMSUNG HDMI TX PHY";
> plat_data->priv_data = hdmi;
> plat_data->phy_force_vendor = true;
> + plat_data->output_port = 1;
>
> platform_set_drvdata(pdev, hdmi);
>
--
Regards,
Laurent Pinchart
Hi Laurent, On Thu Mar 26, 2026 at 9:28 AM CET, Laurent Pinchart wrote: >> Many dts files for imx8mp-based boards in the kernel have such a connector >> described and linked to port@1, so a connector is added by the >> display-connector driver along with a bridge wrapping it. Sadly some of >> those dts files don't have the connector described. Adding it would solve >> the problem easily, but this would break existing devices which do not >> update the dtb when upgrading to a newer kernel. > > I think this series should also fix the in-tree dts files, to pave the > way for removing the workaround. Fixing all dts files can surely be done, but it won't allow removing the workaround. Any devices shipped with a dtb without the connector and upgrading their kernel later on but not the dtb will fail as soon as they upgrade to a kernel with patch 8 but with this workaround removed. That said, do you still think it's worth adding the hdmi-connector node to all dtbs missing it? It should be fairly simple and IIRC it would involve a couple dozen drivers at most based on my initial research. However for most of them I have no way to know which type of connector is installed, would it be OK if we describe type A when the type is unknown, just like dw_hdmi_connector_create() does right now programmatically [0]? [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601 Also, if such a change is to be done, I'd definitely do it as a separate series, to avoid adding more stuff to this series in-flight. >> --- a/drivers/gpu/drm/bridge/imx/Kconfig >> +++ b/drivers/gpu/drm/bridge/imx/Kconfig >> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE >> Choose this to enable support for the internal HDMI encoder found >> on the i.MX8MP SoC. >> >> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP >> + bool "Support device tree blobs without an hdmi-connector node" >> + default y > > Can't we enable the workaround unconditionally ? Distributions will need > to enable this option anyway as they can't know what device they will > boot on. I fear a configuration option will confuse users and waste time > on debugging. Sure, good point. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Hi Luca,
On Fri, Mar 20, 2026 at 11:46:18AM +0100, Luca Ceresoli wrote:
> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
> can operate in two different modes, depending on the platform data as set
> by the driver:
>
> A. hdmi->plat_data->output_port = 0:
> the HDMI output (port@1) in device tree is not used [0]
>
> B. hdmi->plat_data->output_port = 1:
> the HDMI output (port@1) is parsed to find the next bridge
>
> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>
> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
> in that case it adds the connector programmatically at bridge attach time.
>
> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
> case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
> imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
>
> However this change requires that port@1 is connected to a "next
> bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
> the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Many dts files for imx8mp-based boards in the kernel have such a connector
> described and linked to port@1, so a connector is added by the
> display-connector driver along with a bridge wrapping it. Sadly some of
Hmm, display-connector driver is a bridge driver so it cannot add a connector.
I assume that you mean a connector will be added by the bridge connector
driver.
> those dts files don't have the connector described. Adding it would solve
> the problem easily, but this would break existing devices which do not
> update the dtb when upgrading to a newer kernel.
>
> To preserve backward compatibility for such devices, introduce a module
> adding the hdmi-connector node to the live device tree at init time. This
> allows the dw-hdmi code to find the next bridge (the one wrapping the
> hdmi-connector) and let the pipeline work as before.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
> [1] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2907
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> This patch is inspired by commit 0ff223d99147 ("drm/tilcdc: Convert legacy
> panel binding via DT overlay at boot time")
> ---
> drivers/gpu/drm/bridge/imx/Kconfig | 17 ++++++
> drivers/gpu/drm/bridge/imx/Makefile | 2 +
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 60 ++++++++++++++++++++++
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 38 ++++++++++++++
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
> 5 files changed, 118 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
> index b9028a5e5a06..b9ce140a93dc 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
> Choose this to enable support for the internal HDMI encoder found
> on the i.MX8MP SoC.
>
> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
> + bool "Support device tree blobs without an hdmi-connector node"
> + default y
depends on DRM_IMX_LCDIF ?
> + depends on DRM_IMX8MP_DW_HDMI_BRIDGE
> + depends on OF
> + select OF_OVERLAY
> + select DRM_DISPLAY_CONNECTOR
> + help
> + Modifies at early boot the live device tree of boards using the
> + i.MX8MP fsl,imx8mp-hdmi-tx adding a hdmi-connector node linked to
> + the htmi-tx. This is needed to support bridge-connector usage in
s/htmi/hdmi/
> + the i.MX8MP LCDIF driver.
> +
> + You need this if you use the i.MX8MP HDMI output and your board
> + device tree file does not have an hdmi-connector node connected
> + to it.
> +
> config DRM_IMX8MP_HDMI_PAI
> tristate "Freescale i.MX8MP HDMI PAI bridge support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
> index 8d01fda25451..84499fe2e444 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,6 +1,8 @@
> obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> obj-$(CONFIG_DRM_IMX_LEGACY_BRIDGE) += imx-legacy-bridge.o
> obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE) += imx8mp-hdmi-tx.o
> +obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP) += imx8mp-hdmi-tx-connector-fixup.o \
> + imx8mp-hdmi-tx-connector-fixup.dtbo.o
> obj-$(CONFIG_DRM_IMX8MP_HDMI_PAI) += imx8mp-hdmi-pai.o
> obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
> obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> new file mode 100644
> index 000000000000..8c423b9bfa50
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> @@ -0,0 +1,60 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Add an hdmi-connector node to boards using the imx8mp hdmi_tx which
> + * don't have one. This is needed for the i.MX LCDIF to work with
> + * DRM_BRIDGE_ATTACH_NO_CONNECTOR.
> + *
> + * Copyright (C) 2026 GE HealthCare
> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
> + */
> +
> +#include <linux/kernel.h>
Unneeded?
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/slab.h>
Unneeded?
> +
> +/* Embedded dtbo symbols created by cmd_wrap_S_dtb in scripts/Makefile.dtbs */
> +extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_begin[];
> +extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_end[];
> +
> +static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
> +{
> + struct device_node *hdmi_tx __free(device_node) = NULL;
Include linux/cleanup.h as __free() is used.
> + struct device_node *endpoint __free(device_node) = NULL;
> + struct device_node *hdmi_conn __free(device_node) = NULL;
> + void *dtbo_start;
> + u32 dtbo_size;
> + int ovcs_id;
> + int err;
> +
> + hdmi_tx = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000");
> + if (!of_device_is_available(hdmi_tx))
> + return 0;
> +
> + /* If endpoint exists, assume an hdmi-connector exists already */
> + endpoint = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1/endpoint");
> + if (endpoint)
> + return 0;
> +
> + dtbo_start = __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
> + dtbo_size = __dtbo_imx8mp_hdmi_tx_connector_fixup_end -
> + __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
> +
> + err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
> + if (err)
> + return err;
> +
> + hdmi_conn = of_find_node_by_name(NULL, "fixup-hdmi-connector");
Do you really need to find the node, since the overlay was just applied?
> + if (!hdmi_conn) {
> + err = -ENODEV;
> + goto overlay_remove;
I'd just return -ENODEV and drop overlay_remove.
> + }
> +
> + return 0;
> +
> +overlay_remove:
> + of_overlay_remove(&ovcs_id);
> + return err;
> +}
> +
> +subsys_initcall(imx8mp_hdmi_tx_connector_fixup_init);
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> new file mode 100644
> index 000000000000..ee718ca1b11b
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
> + *
> + * Copyright (C) 2026 GE HealthCare
> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
I see build warnings(W=1):
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:25.8-37.4: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0: node has a unit name, but no reg or ranges property
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:26.16-36.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000: node has a unit name, but no reg or ranges property
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:27.18-35.6: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000: node has a unit name, but no reg or ranges property
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:29.13-33.8: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1: node has a unit name, but no reg or ranges property
Here is a patch to suppress them:
--- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
@@ -10,6 +10,9 @@
/plugin/;
&{/} {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
fixup-hdmi-connector {
compatible = "hdmi-connector";
label = "HDMI";
@@ -23,10 +26,25 @@ fixup_hdmi_connector_in: endpoint {
};
soc@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x3e000000>;
+
bus@32c00000 {
+ reg = <0x32c00000 0x400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
hdmi@32fd8000 {
+ reg = <0x32fd8000 0x7eff>;
+
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@1 {
+ reg = <1>;
+
hdmi_tx_out: endpoint {
remote-endpoint = <&fixup_hdmi_connector_in>;
};
> + fixup-hdmi-connector {
> + compatible = "hdmi-connector";
> + label = "HDMI";
> + type = "a";
What if a board uses another type?
--
Regards,
Liu Ying
Hello Liu,
On Thu Mar 26, 2026 at 9:15 AM CET, Liu Ying wrote:
> Hi Luca,
>
> On Fri, Mar 20, 2026 at 11:46:18AM +0100, Luca Ceresoli wrote:
>> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
>> can operate in two different modes, depending on the platform data as set
>> by the driver:
>>
>> A. hdmi->plat_data->output_port = 0:
>> the HDMI output (port@1) in device tree is not used [0]
>>
>> B. hdmi->plat_data->output_port = 1:
>> the HDMI output (port@1) is parsed to find the next bridge
>>
>> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
>> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
>> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>>
>> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
>> in that case it adds the connector programmatically at bridge attach time.
>>
>> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
>> case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
>> imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
>>
>> However this change requires that port@1 is connected to a "next
>> bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
>> the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>>
>> Many dts files for imx8mp-based boards in the kernel have such a connector
>> described and linked to port@1, so a connector is added by the
>> display-connector driver along with a bridge wrapping it. Sadly some of
>
> Hmm, display-connector driver is a bridge driver so it cannot add a connector.
> I assume that you mean a connector will be added by the bridge connector
> driver.
Indeed, rewording as:
Many dts files for imx8mp-based boards in the kernel have such a
connector described and linked to port@1, so the pipeline will be fully
attached up to a display-connector and a drm_connector added by the
bridge-connector.
>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>> Choose this to enable support for the internal HDMI encoder found
>> on the i.MX8MP SoC.
>>
>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>> + bool "Support device tree blobs without an hdmi-connector node"
>> + default y
>
> depends on DRM_IMX_LCDIF ?
If the imx hdmi-tx is not enabled then HDMI won't work anyway, so users are
not affected and the overlay is not needed. Am I missing something?
>> + err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
>> + if (err)
>> + return err;
>> +
>> + hdmi_conn = of_find_node_by_name(NULL, "fixup-hdmi-connector");
>
> Do you really need to find the node, since the overlay was just applied?
That was to ensure the node is present and error out if it isn't. But
thinking again about it after your question I don't see how it could be
missing if the overlay was successfully applied.
Removing this check in v2, which makes this function a lot simpler!
>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> new file mode 100644
>> index 000000000000..ee718ca1b11b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> @@ -0,0 +1,38 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
>> + *
>> + * Copyright (C) 2026 GE HealthCare
>> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> + */
>> +
>> +/dts-v1/;
>> +/plugin/;
>> +
>> +&{/} {
>
> I see build warnings(W=1):
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:25.8-37.4: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:26.16-36.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:27.18-35.6: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000: node has a unit name, but no reg or ranges property
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:29.13-33.8: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1: node has a unit name, but no reg or ranges property
AFAIK the device tree checkes just can't work on overlays. The tools just
cannot know on which base tree the overlay can be applied, so they cannot
know the existing properties. That might change in the future, but for now
my understanding is that it is OK to have overlays which produce such
harmless warnings, at least for driver-specific overlays like the tilcdc
one [0] which is already in linux-next since a few weeks.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0ff223d991477fa4677dcb0f1fb00065847e2212
> Here is a patch to suppress them:
>
> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> @@ -10,6 +10,9 @@
> /plugin/;
>
> &{/} {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> fixup-hdmi-connector {
> compatible = "hdmi-connector";
> label = "HDMI";
> @@ -23,10 +26,25 @@ fixup_hdmi_connector_in: endpoint {
> };
>
> soc@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x3e000000>;
> +
> bus@32c00000 {
> + reg = <0x32c00000 0x400000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> hdmi@32fd8000 {
> + reg = <0x32fd8000 0x7eff>;
> +
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@1 {
> + reg = <1>;
> +
> hdmi_tx_out: endpoint {
> remote-endpoint = <&fixup_hdmi_connector_in>;
> };
Thanks for taking time to look into how to get rid of the warnings.
However the sheer amount of lines added, by just duplicating lines already
in the base tree and no added value, reinforces my opinion that we should
keep the overlay as simple as it is.
Also, what if one of the property values that your diff is duplicating from
the base tree turns out being wrong in the base tree and gets fixed later
there? The wrong value would be re-added by the overlay unless someone goes
hunting all the duplicated lines around.
Based on this, do you think we really need to get rid of those warnings?
Side note: this discussion made me think about what would happen if
DRM_IMX8MP_DW_HDMI_BRIDGE is enabled on a non-imx8mp board (as for
distribution kernels as mentioned by Laurent). I think it makes sense to
add a check that /soc@0/compatible matches "fsl,imx8mp-soc" and not apply
the overlay otherwise. I'll look into that for v2.
>> + fixup-hdmi-connector {
>> + compatible = "hdmi-connector";
>> + label = "HDMI";
>> + type = "a";
>
> What if a board uses another type?
For boards affected by this patch, currently the connector is created by
dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
difference.
OTOH how can a common module know the specific connector?
Boards with a different connector should describe the connector in the
device tree, if they need to instantiate the exact type.
[0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Luca,
On Fri, Mar 27, 2026 at 03:46:43PM +0100, Luca Ceresoli wrote:
> Hello Liu,
>
> On Thu Mar 26, 2026 at 9:15 AM CET, Liu Ying wrote:
>> Hi Luca,
>>
>> On Fri, Mar 20, 2026 at 11:46:18AM +0100, Luca Ceresoli wrote:
>>> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
>>> can operate in two different modes, depending on the platform data as set
>>> by the driver:
>>>
>>> A. hdmi->plat_data->output_port = 0:
>>> the HDMI output (port@1) in device tree is not used [0]
>>>
>>> B. hdmi->plat_data->output_port = 1:
>>> the HDMI output (port@1) is parsed to find the next bridge
>>>
>>> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
>>> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
>>> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>>>
>>> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
>>> in that case it adds the connector programmatically at bridge attach time.
>>>
>>> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
>>> case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
>>> imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
>>>
>>> However this change requires that port@1 is connected to a "next
>>> bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
>>> the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>>>
>>> Many dts files for imx8mp-based boards in the kernel have such a connector
>>> described and linked to port@1, so a connector is added by the
>>> display-connector driver along with a bridge wrapping it. Sadly some of
>>
>> Hmm, display-connector driver is a bridge driver so it cannot add a connector.
>> I assume that you mean a connector will be added by the bridge connector
>> driver.
>
> Indeed, rewording as:
>
> Many dts files for imx8mp-based boards in the kernel have such a
> connector described and linked to port@1, so the pipeline will be fully
> attached up to a display-connector and a drm_connector added by the
> bridge-connector.
LGTM.
>
>>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>>> Choose this to enable support for the internal HDMI encoder found
>>> on the i.MX8MP SoC.
>>>
>>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>>> + bool "Support device tree blobs without an hdmi-connector node"
>>> + default y
>>
>> depends on DRM_IMX_LCDIF ?
>
> If the imx hdmi-tx is not enabled then HDMI won't work anyway, so users are
> not affected and the overlay is not needed. Am I missing something?
I meant I'm fine with "default y" and think that this could also depend on
DRM_IMX_LCDIF, because no display controller driver other than the LCDIF
driver needs the fixup.
[...]
>>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>>> new file mode 100644
>>> index 000000000000..ee718ca1b11b
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>>> @@ -0,0 +1,38 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
>>> + *
>>> + * Copyright (C) 2026 GE HealthCare
>>> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>> + */
>>> +
>>> +/dts-v1/;
>>> +/plugin/;
>>> +
>>> +&{/} {
>>
>> I see build warnings(W=1):
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:25.8-37.4: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0: node has a unit name, but no reg or ranges property
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:26.16-36.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000: node has a unit name, but no reg or ranges property
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:27.18-35.6: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000: node has a unit name, but no reg or ranges property
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:29.13-33.8: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1: node has a unit name, but no reg or ranges property
>
> AFAIK the device tree checkes just can't work on overlays. The tools just
> cannot know on which base tree the overlay can be applied, so they cannot
> know the existing properties. That might change in the future, but for now
> my understanding is that it is OK to have overlays which produce such
> harmless warnings, at least for driver-specific overlays like the tilcdc
> one [0] which is already in linux-next since a few weeks.
Hmm, not sure a few weeks in linux-next is long enough ;)
I'd say, I saw the warnings, so simply reported along with a fix to suppress
them. TBH, build warnings make me nervous, especially this DT overlay is
under the "DRM DRIVERS FOR FREESCALE IMX BRIDGE" umbrella.
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0ff223d991477fa4677dcb0f1fb00065847e2212
>
>> Here is a patch to suppress them:
>>
>> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> @@ -10,6 +10,9 @@
>> /plugin/;
>>
>> &{/} {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> fixup-hdmi-connector {
>> compatible = "hdmi-connector";
>> label = "HDMI";
>> @@ -23,10 +26,25 @@ fixup_hdmi_connector_in: endpoint {
>> };
>>
>> soc@0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x0 0x0 0x3e000000>;
>> +
>> bus@32c00000 {
>> + reg = <0x32c00000 0x400000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> hdmi@32fd8000 {
>> + reg = <0x32fd8000 0x7eff>;
>> +
>> ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> port@1 {
>> + reg = <1>;
>> +
>> hdmi_tx_out: endpoint {
>> remote-endpoint = <&fixup_hdmi_connector_in>;
>> };
>
> Thanks for taking time to look into how to get rid of the warnings.
>
> However the sheer amount of lines added, by just duplicating lines already
> in the base tree and no added value, reinforces my opinion that we should
> keep the overlay as simple as it is.
>
> Also, what if one of the property values that your diff is duplicating from
> the base tree turns out being wrong in the base tree and gets fixed later
> there? The wrong value would be re-added by the overlay unless someone goes
> hunting all the duplicated lines around.
>
> Based on this, do you think we really need to get rid of those warnings?
Well, I tend to get rid of those warning, because it seems that people
usually avoid this kind of warnings for regular DT overlays, but I might
be wrong.
>
> Side note: this discussion made me think about what would happen if
> DRM_IMX8MP_DW_HDMI_BRIDGE is enabled on a non-imx8mp board (as for
> distribution kernels as mentioned by Laurent). I think it makes sense to
> add a check that /soc@0/compatible matches "fsl,imx8mp-soc" and not apply
> the overlay otherwise. I'll look into that for v2.
Makes sense to me.
>
>>> + fixup-hdmi-connector {
>>> + compatible = "hdmi-connector";
>>> + label = "HDMI";
>>> + type = "a";
>>
>> What if a board uses another type?
>
> For boards affected by this patch, currently the connector is created by
> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
> difference.
Yes, that's from driver's PoV. However, userspace may get the type
from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
to do something.
Maybe, that's trivial.
>
> OTOH how can a common module know the specific connector?
Hmm, maybe add a module parameter or let users set the type through Kconfig
or even define an unknown type to honestly tell users that we don't know it?
>
> Boards with a different connector should describe the connector in the
> device tree, if they need to instantiate the exact type.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com/
--
Regards,
Liu Ying
Hello Liu,
On Mon Mar 30, 2026 at 5:02 AM CEST, Liu Ying wrote:
>>>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>>>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>>>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>>>> Choose this to enable support for the internal HDMI encoder found
>>>> on the i.MX8MP SoC.
>>>>
>>>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>>>> + bool "Support device tree blobs without an hdmi-connector node"
>>>> + default y
>>>
>>> depends on DRM_IMX_LCDIF ?
>>
>> If the imx hdmi-tx is not enabled then HDMI won't work anyway, so users are
>> not affected and the overlay is not needed. Am I missing something?
>
> I meant I'm fine with "default y" and think that this could also depend on
> DRM_IMX_LCDIF, because no display controller driver other than the LCDIF
> driver needs the fixup.
Ah, I see your point. OK, I'll add 'depends on DRM_IMX_LCDIF'.
>>> I see build warnings(W=1):
>>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:25.8-37.4: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0: node has a unit name, but no reg or ranges property
>>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:26.16-36.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000: node has a unit name, but no reg or ranges property
>>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:27.18-35.6: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000: node has a unit name, but no reg or ranges property
>>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:29.13-33.8: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1: node has a unit name, but no reg or ranges property
>>
>> AFAIK the device tree checkes just can't work on overlays. The tools just
>> cannot know on which base tree the overlay can be applied, so they cannot
>> know the existing properties. That might change in the future, but for now
>> my understanding is that it is OK to have overlays which produce such
>> harmless warnings, at least for driver-specific overlays like the tilcdc
>> one [0] which is already in linux-next since a few weeks.
>
> Hmm, not sure a few weeks in linux-next is long enough ;)
> I'd say, I saw the warnings, so simply reported along with a fix to suppress
> them. TBH, build warnings make me nervous, especially this DT overlay is
> under the "DRM DRIVERS FOR FREESCALE IMX BRIDGE" umbrella.
That's fine, I'll add the lines needed to suppress the warnings then.
>>>> + fixup-hdmi-connector {
>>>> + compatible = "hdmi-connector";
>>>> + label = "HDMI";
>>>> + type = "a";
>>>
>>> What if a board uses another type?
>>
>> For boards affected by this patch, currently the connector is created by
>> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
>> difference.
>
> Yes, that's from driver's PoV. However, userspace may get the type
> from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
> to do something.
I'd say this is incorrect, the device tree is not an API for that. The
connector type might be known to the driver by other means (ACPI, DP MST,
whatever). So I think this is a non-problem.
If userspace needs to know the connector type, that should come from the
ioctl (DRM_IOCTL_MODE_GETCONNECTOR perhaps).
> Maybe, that's trivial.
Not sure I got what you mean here, sorry. What are you referring to?
>> OTOH how can a common module know the specific connector?
>
> Hmm, maybe add a module parameter or let users set the type through Kconfig
I'm afraid none of this would work for distribution kernels, where who
configures the distribution has no idea on how many different hardware it
will run.
> or even define an unknown type to honestly tell users that we don't know it?
This sounds like a potentially valid idea, even though I'm not fully
convinced. Also I suspect it would be a pretty large change, and also
adding "unknown type" in the device tree seems not compliant with the rule
that DT describes the hardware (not the lack of info about the hardware).
But definitely it's not needed for this specific case, because:
* with current code, every imx8mp-hdmi-tx usage adds a type-A connector [0]
* with this patch the correct type will be created when described in DT,
and type-A will be used only as a fallback when the DT is lacking
So after the patch we'd do sometimes better, never worse in this respect.
Based on the above I'm sending v2 soon, but don't hesitate in following up
in case I may be missing something (this topic is tricky).
[0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
>> Boards with a different connector should describe the connector in the
>> device tree, if they need to instantiate the exact type.
I think this is the only valid solution. It's very easy to do, nothing new
to invent.
Maybe on top of that we could add a warning when the overlay is applied,
e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
adding a type A connector as a fallback; please add a valid description to
your device tree". Maybe pointing to a TODO entry in the documentation.
What do you think about this?
Thanks again for your careful review!
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Luca,
On Mon, Mar 30, 2026 at 05:47:23PM +0200, Luca Ceresoli wrote:
> Hello Liu,
>
> On Mon Mar 30, 2026 at 5:02 AM CEST, Liu Ying wrote:
[...]
>>>>> + fixup-hdmi-connector {
>>>>> + compatible = "hdmi-connector";
>>>>> + label = "HDMI";
>>>>> + type = "a";
>>>>
>>>> What if a board uses another type?
>>>
>>> For boards affected by this patch, currently the connector is created by
>>> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
>>> difference.
>>
>> Yes, that's from driver's PoV. However, userspace may get the type
>> from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
>> to do something.
>
> I'd say this is incorrect, the device tree is not an API for that. The
> connector type might be known to the driver by other means (ACPI, DP MST,
> whatever). So I think this is a non-problem.
I just feel that it's not great to report potentially wrong type to users
through the above sys node ...
>
> If userspace needs to know the connector type, that should come from the
> ioctl (DRM_IOCTL_MODE_GETCONNECTOR perhaps).
>
>> Maybe, that's trivial.
>
> Not sure I got what you mean here, sorry. What are you referring to?
... with the above potentially wrong type being said, I think maybe this
drawback is not a big deal and could be ignored. Sorry for not being
clear in my last reply.
>
>>> OTOH how can a common module know the specific connector?
>>
>> Hmm, maybe add a module parameter or let users set the type through Kconfig
>
> I'm afraid none of this would work for distribution kernels, where who
> configures the distribution has no idea on how many different hardware it
> will run.
>
>> or even define an unknown type to honestly tell users that we don't know it?
>
> This sounds like a potentially valid idea, even though I'm not fully
> convinced. Also I suspect it would be a pretty large change, and also
> adding "unknown type" in the device tree seems not compliant with the rule
> that DT describes the hardware (not the lack of info about the hardware).
>
> But definitely it's not needed for this specific case, because:
>
> * with current code, every imx8mp-hdmi-tx usage adds a type-A connector [0]
> * with this patch the correct type will be created when described in DT,
> and type-A will be used only as a fallback when the DT is lacking
>
> So after the patch we'd do sometimes better, never worse in this respect.
Well, kind of a bit worse since the sys node exposes a potentially wrong type.
>
> Based on the above I'm sending v2 soon, but don't hesitate in following up
> in case I may be missing something (this topic is tricky).
Agreed, it's tricky.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
>
>>> Boards with a different connector should describe the connector in the
>>> device tree, if they need to instantiate the exact type.
>
> I think this is the only valid solution. It's very easy to do, nothing new
> to invent.
>
> Maybe on top of that we could add a warning when the overlay is applied,
> e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
> adding a type A connector as a fallback; please add a valid description to
> your device tree".
I'd say this doesn't sound a bad idea but I hope the message is clear and
short.
> Maybe pointing to a TODO entry in the documentation.
To parameterize the HDMI connector type? If so, I'm okay with that.
>
> What do you think about this?
>
> Thanks again for your careful review!
Thanks for your patches! Appreciated.
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com/
--
Regards,
Liu Ying
Hello Liu,
On Tue Mar 31, 2026 at 5:03 AM CEST, Liu Ying wrote:
> Hi Luca,
>
> On Mon, Mar 30, 2026 at 05:47:23PM +0200, Luca Ceresoli wrote:
>> Hello Liu,
>>
>> On Mon Mar 30, 2026 at 5:02 AM CEST, Liu Ying wrote:
>
> [...]
>
>>>>>> + fixup-hdmi-connector {
>>>>>> + compatible = "hdmi-connector";
>>>>>> + label = "HDMI";
>>>>>> + type = "a";
>>>>>
>>>>> What if a board uses another type?
>>>>
>>>> For boards affected by this patch, currently the connector is created by
>>>> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
>>>> difference.
>>>
>>> Yes, that's from driver's PoV. However, userspace may get the type
>>> from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
>>> to do something.
>>
>> I'd say this is incorrect, the device tree is not an API for that. The
>> connector type might be known to the driver by other means (ACPI, DP MST,
>> whatever). So I think this is a non-problem.
>
> I just feel that it's not great to report potentially wrong type to users
> through the above sys node ...
>
>>
>> If userspace needs to know the connector type, that should come from the
>> ioctl (DRM_IOCTL_MODE_GETCONNECTOR perhaps).
>>
>>> Maybe, that's trivial.
>>
>> Not sure I got what you mean here, sorry. What are you referring to?
>
> ... with the above potentially wrong type being said, I think maybe this
> drawback is not a big deal and could be ignored. Sorry for not being
> clear in my last reply.
Ah, clear now. No problem!
>>>> Boards with a different connector should describe the connector in the
>>>> device tree, if they need to instantiate the exact type.
>>
>> I think this is the only valid solution. It's very easy to do, nothing new
>> to invent.
>>
>> Maybe on top of that we could add a warning when the overlay is applied,
>> e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
>> adding a type A connector as a fallback; please add a valid description to
>> your device tree".
>
> I'd say this doesn't sound a bad idea but I hope the message is clear and
> short.
What about:
Connector description not found in device tree, please add one. Falling back to Type A.
>> Maybe pointing to a TODO entry in the documentation.
>
> To parameterize the HDMI connector type? If so, I'm okay with that.
I was meaning a TODO entry to suggest people to add a connector description
to the dts. E.g., expanding on the above suggested warning:
Connector description not found in device tree, please add one. See https://docs.kernel.org/gpu/todo.html#<...>
And of course adding a TODO entry describing what one needs to do (add an
hdmi-connector node and link it to port@1 of the hdmi-tx).
The drawback of the TODO is that items in todo.rst are supposed to be
removed eventually when done in the code, but this one cannot be removed
until some kernels printing the above logging message will be around,
i.e. potentially for decades.
So maybe the simplest solution is just the first warning message + a
comment in the code right before the warning line, so it easily found with
grep or a web search by who sees the warning.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Luca,
On Tue, Mar 31, 2026 at 12:54:30PM +0200, Luca Ceresoli wrote:
> Hello Liu,
>
> On Tue Mar 31, 2026 at 5:03 AM CEST, Liu Ying wrote:
>> Hi Luca,
>>
>> On Mon, Mar 30, 2026 at 05:47:23PM +0200, Luca Ceresoli wrote:
>>> Hello Liu,
>>>
>>> On Mon Mar 30, 2026 at 5:02 AM CEST, Liu Ying wrote:
>>
>> [...]
>>
>>>>>>> + fixup-hdmi-connector {
>>>>>>> + compatible = "hdmi-connector";
>>>>>>> + label = "HDMI";
>>>>>>> + type = "a";
>>>>>>
>>>>>> What if a board uses another type?
>>>>>
>>>>> For boards affected by this patch, currently the connector is created by
>>>>> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
>>>>> difference.
>>>>
>>>> Yes, that's from driver's PoV. However, userspace may get the type
>>>> from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
>>>> to do something.
>>>
>>> I'd say this is incorrect, the device tree is not an API for that. The
>>> connector type might be known to the driver by other means (ACPI, DP MST,
>>> whatever). So I think this is a non-problem.
>>
>> I just feel that it's not great to report potentially wrong type to users
>> through the above sys node ...
>>
>>>
>>> If userspace needs to know the connector type, that should come from the
>>> ioctl (DRM_IOCTL_MODE_GETCONNECTOR perhaps).
>>>
>>>> Maybe, that's trivial.
>>>
>>> Not sure I got what you mean here, sorry. What are you referring to?
>>
>> ... with the above potentially wrong type being said, I think maybe this
>> drawback is not a big deal and could be ignored. Sorry for not being
>> clear in my last reply.
>
> Ah, clear now. No problem!
>
>>>>> Boards with a different connector should describe the connector in the
>>>>> device tree, if they need to instantiate the exact type.
>>>
>>> I think this is the only valid solution. It's very easy to do, nothing new
>>> to invent.
>>>
>>> Maybe on top of that we could add a warning when the overlay is applied,
>>> e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
>>> adding a type A connector as a fallback; please add a valid description to
>>> your device tree".
>>
>> I'd say this doesn't sound a bad idea but I hope the message is clear and
>> short.
>
> What about:
>
> Connector description not found in device tree, please add one. Falling back to Type A.
Maybe:
Please add a hdmi-connector DT node for imx8mp-hdmi-tx. A fixup node in type a is added for now.
>
>>> Maybe pointing to a TODO entry in the documentation.
>>
>> To parameterize the HDMI connector type? If so, I'm okay with that.
>
> I was meaning a TODO entry to suggest people to add a connector description
> to the dts. E.g., expanding on the above suggested warning:
>
> Connector description not found in device tree, please add one. See https://docs.kernel.org/gpu/todo.html#<...>
>
> And of course adding a TODO entry describing what one needs to do (add an
> hdmi-connector node and link it to port@1 of the hdmi-tx).
>
> The drawback of the TODO is that items in todo.rst are supposed to be
> removed eventually when done in the code, but this one cannot be removed
> until some kernels printing the above logging message will be around,
> i.e. potentially for decades.
Not a big fan of adding a TODO entry, because those DT blobs without a
hdmi-connector node could be out there forever, meaning the added TODO
entry can never be removed.
>
> So maybe the simplest solution is just the first warning message + a
> comment in the code right before the warning line, so it easily found with
> grep or a web search by who sees the warning.
+1.
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com/
--
Regards,
Liu Ying
Hello Liu, On Wed Apr 1, 2026 at 8:45 AM CEST, Liu Ying wrote: >>>>>> Boards with a different connector should describe the connector in the >>>>>> device tree, if they need to instantiate the exact type. >>>> >>>> I think this is the only valid solution. It's very easy to do, nothing new >>>> to invent. >>>> >>>> Maybe on top of that we could add a warning when the overlay is applied, >>>> e.g. "imx8mp-hdmi-tx used without a connector described in device tree; >>>> adding a type A connector as a fallback; please add a valid description to >>>> your device tree". >>> >>> I'd say this doesn't sound a bad idea but I hope the message is clear and >>> short. >> >> What about: >> >> Connector description not found in device tree, please add one. Falling back to Type A. > > Maybe: > Please add a hdmi-connector DT node for imx8mp-hdmi-tx. A fixup node in type a is added for now. > >> >>>> Maybe pointing to a TODO entry in the documentation. >>> >>> To parameterize the HDMI connector type? If so, I'm okay with that. >> >> I was meaning a TODO entry to suggest people to add a connector description >> to the dts. E.g., expanding on the above suggested warning: >> >> Connector description not found in device tree, please add one. See https://docs.kernel.org/gpu/todo.html#<...> >> >> And of course adding a TODO entry describing what one needs to do (add an >> hdmi-connector node and link it to port@1 of the hdmi-tx). >> >> The drawback of the TODO is that items in todo.rst are supposed to be >> removed eventually when done in the code, but this one cannot be removed >> until some kernels printing the above logging message will be around, >> i.e. potentially for decades. > > Not a big fan of adding a TODO entry, because those DT blobs without a > hdmi-connector node could be out there forever, meaning the added TODO > entry can never be removed. > >> >> So maybe the simplest solution is just the first warning message + a >> comment in the code right before the warning line, so it easily found with >> grep or a web search by who sees the warning. > > +1. Agreed. I've already sent v2, so I'll queue this for v3. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
© 2016 - 2026 Red Hat, Inc.