[PATCH 0/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector

Luca Ceresoli posted 8 patches 2 weeks ago
There is a newer version of this series
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 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 45 ++++-------
drivers/gpu/drm/mxsfb/Kconfig                      |  1 +
drivers/gpu/drm/mxsfb/lcdif_drv.c                  | 88 +++++++++-------------
include/drm/bridge/dw_hdmi.h                       |  5 ++
9 files changed, 174 insertions(+), 83 deletions(-)
[PATCH 0/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
Posted by Luca Ceresoli 2 weeks ago
This series modernizes the i.mx8mp LCDIF driver to use the
bridge-connector, which is the current best practice in DRM.

== Call for testing on i.MX8MP boards (especially those using HDMI)!

This series applies changes to how video output devices are probed on
i.MX8MP, especially those using HDMI. Even though I have put care in not
breaking anything, there could potentially be pitfalls I haven't realized,
causing regressions on existing boards.

I have thus added in Cc all developers which appeared active on dts files
for imx8mp boards involving video. I would appreciate testing on as many
boards as possible, along with a Tested-by tag, or a report about any
issues encountered.

Thanks in advance to all testers!

== Review recommendation

I recommend reviewing patches in this order to be understood more
effectively:

 * Cover letter
 * Patches 1-5 are small preliminary cleanups/improvements
 * Patch 8 is the goal of this series, but would not work alone
 * Patch 7 this lets patch 8 work; but in turn it can't work alone
 * Patch 6 lets patch 7 work

== Series description

This series is not strictly related to DRM bridge hotplug, it is rather a
preparation step. Introducing hotplug would need two different approaches:
one for the new way, for drivers using bridge-connector and
DRM_BRIDGE_ATTACH_NO_CONNECTOR, another for drivers using the "old, legacy
way" where the last bridge is supposed to instantiate the
drm_connector. Hotplug is complicated enough in one case, so it makes sense
to only support the new way.

The hardware I'm working on is an i.MX8MP, whose LCDIF driver is still
using the old way. So this series converts to the new way as a preparation
step.

Patch 8 does the conversion, which is simple. However this would introduce
a regression on some boards. Here's why:

There are 3 instances of the LCDIF in i.MX8MP:

 * LCDIF1, driving the DSI output
 * LCDIF2, driving the LVDS output
 * LCDIF3, driving the HDMI output

The device drivers of peripherals connected to LCDIF1 and LCDIF2 already
support the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. So far so good.

LCDIF3 is more tricky. The HDMI pipeline is:

  LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector

The fsl,imx8mp-hdmi-tx (hdmi-tx) component supports both cases (with or
without DRM_BRIDGE_ATTACH_NO_CONNECTOR), but in the
DRM_BRIDGE_ATTACH_NO_CONNECTOR case it does not create a drm_connector,
thus preventing the creation of the pipeline. To make it work a connector
must be created, and the way to do so is describing the connector in the
device tree (compatible = "hdmi-connector"), so the display-driver will add
the connector along with a wrapping bridge.

Unfortunately not all device trees in mainline have an hdmi-connector
node. Adding one is easy, but would break existing hardware upgrading to a
newer kernel without upgrading the device tree blob. This is addressed by
patch 7 reusing an existing approach to add such a node to the live device
tree at init time using a device tree overlay for boards which don't have
one.

Finally, patch 7 cannot work alone because of a bad interaction between
devlink and device tree overlays. Patch 6 solves that.

== Grand plan

This is part of the work to support hotplug of DRM bridges. The grand plan
was discussed in [0].

Here's the work breakdown (➜ marks the current series):

 1. … add refcounting to DRM bridges struct drm_bridge,
      based on devm_drm_bridge_alloc()
    A. ✔ add new alloc API and refcounting (v6.16)
    B. ✔ convert all bridge drivers to new API (v6.17)
    C. ✔ kunit tests (v6.17)
    D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
         and warn on old allocation pattern (v6.17)
    E. … add get/put on drm_bridge accessors
       1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
       2. ✔ drm_bridge_get_prev_bridge() (v6.18)
       3. ✔ drm_bridge_get_next_bridge() (v6.19)
       4. ✔ drm_for_each_bridge_in_chain() (v6.19)
       5. ✔ drm_bridge_connector_init (v6.19)
       6. … protect encoder bridge chain with a mutex
       7. … of_drm_find_bridge
          a. ✔ add of_drm_get_bridge() (v7.0),
	       convert basic direct users (v7.0-v7.1)
	  b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
	  c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
	  d. ✔… convert direct of_drm_get_bridge() users, part 4
	        (some v7.1, some pending)
	  e.   convert bridge-only drm_of_find_panel_or_bridge() users
       8. drm_of_find_panel_or_bridge, *_of_get_bridge
       9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
    F. ✔ debugfs improvements
       1. ✔ add top-level 'bridges' file (v6.16)
       2. ✔ show refcount and list lingering bridges (v6.19)
 2. … handle gracefully atomic updates during bridge removal
    A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
    B. … protect private_obj removal from list
    C. ✔ Add drm_bridge_clear_and_put() (v7.1)
 3. … DSI host-device driver interaction
 4. ✔ removing the need for the "always-disconnected" connector
 5. ➜ Migrate i.MX LCDIF driver to bridge-connector
 6.   DRM bridge hotplug
    A.   Bridge hotplug management in the DRM core
    B.   Device tree description

[0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t

Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Luca Ceresoli (8):
      drm/mxsfb/lcdif: simplify remote pointer management using __free
      drm/mxsfb/lcdif: don't unnecessarily loop over ports
      drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
      drm/bridge: dw-hdmi: document the output_port field
      drm/bridge: dw-hdmi: warn on unsupported attach combination
      drm/bridge: dw-hdmi: move next_bridge lookup to attach time
      drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
      drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector

 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 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 45 ++++-------
 drivers/gpu/drm/mxsfb/Kconfig                      |  1 +
 drivers/gpu/drm/mxsfb/lcdif_drv.c                  | 88 +++++++++-------------
 include/drm/bridge/dw_hdmi.h                       |  5 ++
 9 files changed, 174 insertions(+), 83 deletions(-)
---
base-commit: 8402cf4fc8f8d5756dc81cf9fda1dccdb3622634
change-id: 20260306-drm-lcdif-dbanc-83dd948327de

Best regards,
-- 
Luca Ceresoli <luca.ceresoli@bootlin.com>

Re: [PATCH 0/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
Posted by Martyn Welch 1 week, 1 day ago
On 20/03/2026 10:46, Luca Ceresoli wrote:
> This series modernizes the i.mx8mp LCDIF driver to use the
> bridge-connector, which is the current best practice in DRM.
> 
> == Call for testing on i.MX8MP boards (especially those using HDMI)!
> 
> This series applies changes to how video output devices are probed on
> i.MX8MP, especially those using HDMI. Even though I have put care in not
> breaking anything, there could potentially be pitfalls I haven't realized,
> causing regressions on existing boards.
> 
> I have thus added in Cc all developers which appeared active on dts files
> for imx8mp boards involving video. I would appreciate testing on as many
> boards as possible, along with a Tested-by tag, or a report about any
> issues encountered.
> 
> Thanks in advance to all testers!
> 

Tested-by: Martyn Welch <martyn.welch@collabora.com>

Using Ezurio Nitrogen8M Plus ENC Carrier Board with i.MX88MP SOM and 
1280x800 HDMI display.


> == Review recommendation
> 
> I recommend reviewing patches in this order to be understood more
> effectively:
> 
>   * Cover letter
>   * Patches 1-5 are small preliminary cleanups/improvements
>   * Patch 8 is the goal of this series, but would not work alone
>   * Patch 7 this lets patch 8 work; but in turn it can't work alone
>   * Patch 6 lets patch 7 work
> 
> == Series description
> 
> This series is not strictly related to DRM bridge hotplug, it is rather a
> preparation step. Introducing hotplug would need two different approaches:
> one for the new way, for drivers using bridge-connector and
> DRM_BRIDGE_ATTACH_NO_CONNECTOR, another for drivers using the "old, legacy
> way" where the last bridge is supposed to instantiate the
> drm_connector. Hotplug is complicated enough in one case, so it makes sense
> to only support the new way.
> 
> The hardware I'm working on is an i.MX8MP, whose LCDIF driver is still
> using the old way. So this series converts to the new way as a preparation
> step.
> 
> Patch 8 does the conversion, which is simple. However this would introduce
> a regression on some boards. Here's why:
> 
> There are 3 instances of the LCDIF in i.MX8MP:
> 
>   * LCDIF1, driving the DSI output
>   * LCDIF2, driving the LVDS output
>   * LCDIF3, driving the HDMI output
> 
> The device drivers of peripherals connected to LCDIF1 and LCDIF2 already
> support the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. So far so good.
> 
> LCDIF3 is more tricky. The HDMI pipeline is:
> 
>    LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
> 
> The fsl,imx8mp-hdmi-tx (hdmi-tx) component supports both cases (with or
> without DRM_BRIDGE_ATTACH_NO_CONNECTOR), but in the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case it does not create a drm_connector,
> thus preventing the creation of the pipeline. To make it work a connector
> must be created, and the way to do so is describing the connector in the
> device tree (compatible = "hdmi-connector"), so the display-driver will add
> the connector along with a wrapping bridge.
> 
> Unfortunately not all device trees in mainline have an hdmi-connector
> node. Adding one is easy, but would break existing hardware upgrading to a
> newer kernel without upgrading the device tree blob. This is addressed by
> patch 7 reusing an existing approach to add such a node to the live device
> tree at init time using a device tree overlay for boards which don't have
> one.
> 
> Finally, patch 7 cannot work alone because of a bad interaction between
> devlink and device tree overlays. Patch 6 solves that.
> 
> == Grand plan
> 
> This is part of the work to support hotplug of DRM bridges. The grand plan
> was discussed in [0].
> 
> Here's the work breakdown (➜ marks the current series):
> 
>   1. … add refcounting to DRM bridges struct drm_bridge,
>        based on devm_drm_bridge_alloc()
>      A. ✔ add new alloc API and refcounting (v6.16)
>      B. ✔ convert all bridge drivers to new API (v6.17)
>      C. ✔ kunit tests (v6.17)
>      D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
>           and warn on old allocation pattern (v6.17)
>      E. … add get/put on drm_bridge accessors
>         1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
>         2. ✔ drm_bridge_get_prev_bridge() (v6.18)
>         3. ✔ drm_bridge_get_next_bridge() (v6.19)
>         4. ✔ drm_for_each_bridge_in_chain() (v6.19)
>         5. ✔ drm_bridge_connector_init (v6.19)
>         6. … protect encoder bridge chain with a mutex
>         7. … of_drm_find_bridge
>            a. ✔ add of_drm_get_bridge() (v7.0),
> 	       convert basic direct users (v7.0-v7.1)
> 	  b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
> 	  c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
> 	  d. ✔… convert direct of_drm_get_bridge() users, part 4
> 	        (some v7.1, some pending)
> 	  e.   convert bridge-only drm_of_find_panel_or_bridge() users
>         8. drm_of_find_panel_or_bridge, *_of_get_bridge
>         9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
>      F. ✔ debugfs improvements
>         1. ✔ add top-level 'bridges' file (v6.16)
>         2. ✔ show refcount and list lingering bridges (v6.19)
>   2. … handle gracefully atomic updates during bridge removal
>      A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
>      B. … protect private_obj removal from list
>      C. ✔ Add drm_bridge_clear_and_put() (v7.1)
>   3. … DSI host-device driver interaction
>   4. ✔ removing the need for the "always-disconnected" connector
>   5. ➜ Migrate i.MX LCDIF driver to bridge-connector
>   6.   DRM bridge hotplug
>      A.   Bridge hotplug management in the DRM core
>      B.   Device tree description
> 
> [0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> Luca Ceresoli (8):
>        drm/mxsfb/lcdif: simplify remote pointer management using __free
>        drm/mxsfb/lcdif: don't unnecessarily loop over ports
>        drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
>        drm/bridge: dw-hdmi: document the output_port field
>        drm/bridge: dw-hdmi: warn on unsupported attach combination
>        drm/bridge: dw-hdmi: move next_bridge lookup to attach time
>        drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
>        drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
> 
>   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 +
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 45 ++++-------
>   drivers/gpu/drm/mxsfb/Kconfig                      |  1 +
>   drivers/gpu/drm/mxsfb/lcdif_drv.c                  | 88 +++++++++-------------
>   include/drm/bridge/dw_hdmi.h                       |  5 ++
>   9 files changed, 174 insertions(+), 83 deletions(-)
> ---
> base-commit: 8402cf4fc8f8d5756dc81cf9fda1dccdb3622634
> change-id: 20260306-drm-lcdif-dbanc-83dd948327de
> 
> Best regards,

Re: [PATCH 0/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
Posted by Alexander Stein 1 week, 4 days ago
Hi Luca,

Am Freitag, 20. März 2026, 11:46:11 CET schrieb Luca Ceresoli:
> This series modernizes the i.mx8mp LCDIF driver to use the
> bridge-connector, which is the current best practice in DRM.
> 
> == Call for testing on i.MX8MP boards (especially those using HDMI)!
> 
> This series applies changes to how video output devices are probed on
> i.MX8MP, especially those using HDMI. Even though I have put care in not
> breaking anything, there could potentially be pitfalls I haven't realized,
> causing regressions on existing boards.
> 
> I have thus added in Cc all developers which appeared active on dts files
> for imx8mp boards involving video. I would appreciate testing on as many
> boards as possible, along with a Tested-by tag, or a report about any
> issues encountered.
> 
> Thanks in advance to all testers!

For the whole series:
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL

Because this platform falls into type A of patch 7
DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP has been disabled for me.

Best regards,
Alexander

> 
> == Review recommendation
> 
> I recommend reviewing patches in this order to be understood more
> effectively:
> 
>  * Cover letter
>  * Patches 1-5 are small preliminary cleanups/improvements
>  * Patch 8 is the goal of this series, but would not work alone
>  * Patch 7 this lets patch 8 work; but in turn it can't work alone
>  * Patch 6 lets patch 7 work
> 
> == Series description
> 
> This series is not strictly related to DRM bridge hotplug, it is rather a
> preparation step. Introducing hotplug would need two different approaches:
> one for the new way, for drivers using bridge-connector and
> DRM_BRIDGE_ATTACH_NO_CONNECTOR, another for drivers using the "old, legacy
> way" where the last bridge is supposed to instantiate the
> drm_connector. Hotplug is complicated enough in one case, so it makes sense
> to only support the new way.
> 
> The hardware I'm working on is an i.MX8MP, whose LCDIF driver is still
> using the old way. So this series converts to the new way as a preparation
> step.
> 
> Patch 8 does the conversion, which is simple. However this would introduce
> a regression on some boards. Here's why:
> 
> There are 3 instances of the LCDIF in i.MX8MP:
> 
>  * LCDIF1, driving the DSI output
>  * LCDIF2, driving the LVDS output
>  * LCDIF3, driving the HDMI output
> 
> The device drivers of peripherals connected to LCDIF1 and LCDIF2 already
> support the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. So far so good.
> 
> LCDIF3 is more tricky. The HDMI pipeline is:
> 
>   LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
> 
> The fsl,imx8mp-hdmi-tx (hdmi-tx) component supports both cases (with or
> without DRM_BRIDGE_ATTACH_NO_CONNECTOR), but in the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case it does not create a drm_connector,
> thus preventing the creation of the pipeline. To make it work a connector
> must be created, and the way to do so is describing the connector in the
> device tree (compatible = "hdmi-connector"), so the display-driver will add
> the connector along with a wrapping bridge.
> 
> Unfortunately not all device trees in mainline have an hdmi-connector
> node. Adding one is easy, but would break existing hardware upgrading to a
> newer kernel without upgrading the device tree blob. This is addressed by
> patch 7 reusing an existing approach to add such a node to the live device
> tree at init time using a device tree overlay for boards which don't have
> one.
> 
> Finally, patch 7 cannot work alone because of a bad interaction between
> devlink and device tree overlays. Patch 6 solves that.
> 
> == Grand plan
> 
> This is part of the work to support hotplug of DRM bridges. The grand plan
> was discussed in [0].
> 
> Here's the work breakdown (➜ marks the current series):
> 
>  1. … add refcounting to DRM bridges struct drm_bridge,
>       based on devm_drm_bridge_alloc()
>     A. ✔ add new alloc API and refcounting (v6.16)
>     B. ✔ convert all bridge drivers to new API (v6.17)
>     C. ✔ kunit tests (v6.17)
>     D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
>          and warn on old allocation pattern (v6.17)
>     E. … add get/put on drm_bridge accessors
>        1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
>        2. ✔ drm_bridge_get_prev_bridge() (v6.18)
>        3. ✔ drm_bridge_get_next_bridge() (v6.19)
>        4. ✔ drm_for_each_bridge_in_chain() (v6.19)
>        5. ✔ drm_bridge_connector_init (v6.19)
>        6. … protect encoder bridge chain with a mutex
>        7. … of_drm_find_bridge
>           a. ✔ add of_drm_get_bridge() (v7.0),
> 	       convert basic direct users (v7.0-v7.1)
> 	  b. ✔ convert direct of_drm_get_bridge() users, part 2 (v7.0)
> 	  c. ✔ convert direct of_drm_get_bridge() users, part 3 (v7.0)
> 	  d. ✔… convert direct of_drm_get_bridge() users, part 4
> 	        (some v7.1, some pending)
> 	  e.   convert bridge-only drm_of_find_panel_or_bridge() users
>        8. drm_of_find_panel_or_bridge, *_of_get_bridge
>        9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
>     F. ✔ debugfs improvements
>        1. ✔ add top-level 'bridges' file (v6.16)
>        2. ✔ show refcount and list lingering bridges (v6.19)
>  2. … handle gracefully atomic updates during bridge removal
>     A. ✔ Add drm_bridge_enter/exit() to protect device resources (v7.0)
>     B. … protect private_obj removal from list
>     C. ✔ Add drm_bridge_clear_and_put() (v7.1)
>  3. … DSI host-device driver interaction
>  4. ✔ removing the need for the "always-disconnected" connector
>  5. ➜ Migrate i.MX LCDIF driver to bridge-connector
>  6.   DRM bridge hotplug
>     A.   Bridge hotplug management in the DRM core
>     B.   Device tree description
> 
> [0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> Luca Ceresoli (8):
>       drm/mxsfb/lcdif: simplify remote pointer management using __free
>       drm/mxsfb/lcdif: don't unnecessarily loop over ports
>       drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
>       drm/bridge: dw-hdmi: document the output_port field
>       drm/bridge: dw-hdmi: warn on unsupported attach combination
>       drm/bridge: dw-hdmi: move next_bridge lookup to attach time
>       drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
>       drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
> 
>  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 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 45 ++++-------
>  drivers/gpu/drm/mxsfb/Kconfig                      |  1 +
>  drivers/gpu/drm/mxsfb/lcdif_drv.c                  | 88 +++++++++-------------
>  include/drm/bridge/dw_hdmi.h                       |  5 ++
>  9 files changed, 174 insertions(+), 83 deletions(-)
> ---
> base-commit: 8402cf4fc8f8d5756dc81cf9fda1dccdb3622634
> change-id: 20260306-drm-lcdif-dbanc-83dd948327de
> 
> Best regards,
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/