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

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

[Alexander Stein]

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/

Re: [PATCH 1/8] drm/mxsfb/lcdif: simplify remote pointer management using __free

[Liu Ying]

Hi Luca,

On Fri, Mar 20, 2026 at 11:46:12AM +0100, Luca Ceresoli wrote:
> Putting the remote device_node reference requires a of_node_put(ep) in both

s/of_node_put(ep)/of_node_put(remote)/

> error return points.

Should be cleanup points instead?

> Use a cleanup action to simplify the code.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
>  drivers/gpu/drm/mxsfb/lcdif_drv.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> index 47da1d9336b9..756ca96373c8 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -53,16 +53,13 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
>  	int ret;
>  
>  	for_each_endpoint_of_node(dev->of_node, ep) {
> -		struct device_node *remote;
> +		struct device_node *remote __free(drm_bridge_put) =

s/drm_bridge_put/device_node/, though I know you've already realized the
mistake in a separate reply.

With the above comments addressed:
Reviewed-by: Liu Ying <victor.liu@nxp.com>

> +			of_graph_get_remote_port_parent(ep);
>  		struct of_endpoint of_ep;
>  		struct drm_encoder *encoder;
>  
> -		remote = of_graph_get_remote_port_parent(ep);
> -		if (!of_device_is_available(remote)) {
> -			of_node_put(remote);
> +		if (!of_device_is_available(remote))
>  			continue;
> -		}
> -		of_node_put(remote);
>  
>  		ret = of_graph_parse_endpoint(ep, &of_ep);
>  		if (ret < 0) {
> 

-- 
Regards,
Liu Ying

Re: [PATCH 1/8] drm/mxsfb/lcdif: simplify remote pointer management using __free

[Liu Ying]

On Thu, Mar 26, 2026 at 02:40:25PM +0800, Liu Ying wrote:
> Hi Luca,
> 
> On Fri, Mar 20, 2026 at 11:46:12AM +0100, Luca Ceresoli wrote:
>> Putting the remote device_node reference requires a of_node_put(ep) in both
> 
> s/of_node_put(ep)/of_node_put(remote)/
> 
>> error return points.
> 
> Should be cleanup points instead?
> 
>> Use a cleanup action to simplify the code.
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> ---
>>  drivers/gpu/drm/mxsfb/lcdif_drv.c | 9 +++------
>>  1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
>> index 47da1d9336b9..756ca96373c8 100644
>> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
>> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
>> @@ -53,16 +53,13 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
>>  	int ret;
>>  
>>  	for_each_endpoint_of_node(dev->of_node, ep) {
>> -		struct device_node *remote;
>> +		struct device_node *remote __free(drm_bridge_put) =
> 
> s/drm_bridge_put/device_node/, though I know you've already realized the
> mistake in a separate reply.
> 
> With the above comments addressed:

+1 comment: include linux/cleanup.h as __free() is used.

> Reviewed-by: Liu Ying <victor.liu@nxp.com>
> 
>> +			of_graph_get_remote_port_parent(ep);
>>  		struct of_endpoint of_ep;
>>  		struct drm_encoder *encoder;
>>  
>> -		remote = of_graph_get_remote_port_parent(ep);
>> -		if (!of_device_is_available(remote)) {
>> -			of_node_put(remote);
>> +		if (!of_device_is_available(remote))
>>  			continue;
>> -		}
>> -		of_node_put(remote);
>>  
>>  		ret = of_graph_parse_endpoint(ep, &of_ep);
>>  		if (ret < 0) {
>>
> 

-- 
Regards,
Liu Ying

Re: [PATCH 2/8] drm/mxsfb/lcdif: don't unnecessarily loop over ports

[Liu Ying]

Hi Luca,

On Fri, Mar 20, 2026 at 11:46:13AM +0100, Luca Ceresoli wrote:
> According to the bindings [0] there can be only one port. The in-tree board
> device trees also don't contain multiple ports (searched thos matching

s/thos/those/

> 'fsl,imx(23|28|6sx|8mp|93)-lcdif').
> 
> Avoid an unnecessary loop around multipltle ports. This allows to greatly

s/multipltle/multiple/

> simplify the code.
> 
> [0] Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> 
> ---
> 
> Viewing this patch with '--ignore-all-space' is recommended
> ---
>  drivers/gpu/drm/mxsfb/lcdif_drv.c | 77 ++++++++++++++-------------------------
>  1 file changed, 27 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> index 756ca96373c8..83e134c04882 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -48,61 +48,38 @@ static const struct drm_encoder_funcs lcdif_encoder_funcs = {
>  static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
>  {
>  	struct device *dev = lcdif->drm->dev;
> -	struct device_node *ep;
> +	struct drm_encoder *encoder;
>  	struct drm_bridge *bridge;
>  	int ret;
>  
> -	for_each_endpoint_of_node(dev->of_node, ep) {

The single i.MX93 LCDIF may connect with a DPI/LVDS/MIPI DSI encoder.
Each encoder maps to an endpoint in a port, hence 3 endpoints in all.
See lcdif node in imx91_93_common.dtsi and imx93.dtsi in linux-next/master.

-- 
Regards,
Liu Ying

Re: [PATCH 2/8] drm/mxsfb/lcdif: don't unnecessarily loop over ports

[Luca Ceresoli]

Hello Liu,

thanks for the careful and timely review of this series!

On Thu Mar 26, 2026 at 7:59 AM CET, Liu Ying wrote:
> Hi Luca,
>
> On Fri, Mar 20, 2026 at 11:46:13AM +0100, Luca Ceresoli wrote:
>> According to the bindings [0] there can be only one port. The in-tree board
>> device trees also don't contain multiple ports (searched thos matching
>
> s/thos/those/
>
>> 'fsl,imx(23|28|6sx|8mp|93)-lcdif').
>>
>> Avoid an unnecessary loop around multipltle ports. This allows to greatly
>
> s/multipltle/multiple/
>
>> simplify the code.
>>
>> [0] Documentation/devicetree/bindings/display/fsl,lcdif.yaml
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>
>> ---
>>
>> Viewing this patch with '--ignore-all-space' is recommended
>> ---
>>  drivers/gpu/drm/mxsfb/lcdif_drv.c | 77 ++++++++++++++-------------------------
>>  1 file changed, 27 insertions(+), 50 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
>> index 756ca96373c8..83e134c04882 100644
>> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
>> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
>> @@ -48,61 +48,38 @@ static const struct drm_encoder_funcs lcdif_encoder_funcs = {
>>  static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
>>  {
>>  	struct device *dev = lcdif->drm->dev;
>> -	struct device_node *ep;
>> +	struct drm_encoder *encoder;
>>  	struct drm_bridge *bridge;
>>  	int ret;
>>
>> -	for_each_endpoint_of_node(dev->of_node, ep) {
>
> The single i.MX93 LCDIF may connect with a DPI/LVDS/MIPI DSI encoder.
> Each encoder maps to an endpoint in a port, hence 3 endpoints in all.
> See lcdif node in imx91_93_common.dtsi and imx93.dtsi in linux-next/master.

My bad, I hadn't realized that, perhaps because it was not yet on
drm-misc-next when I did my research. Thanks for noticing.

Luckily the fundamental reason for which I thought I needed this changed
has vanished even before I sent this v1, so I'll just drop this patch and
adapt the follwing ones as needed.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 3/8] drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge

[Liu Ying]

On Fri, Mar 20, 2026 at 11:46:14AM +0100, Luca Ceresoli wrote:
> lcdif_attach_bridge() uses dev_err_probe() in some error paths, dev_err() +
> return in others. Use dev_err_probe() for all of them to make code
> consistent and simpler.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
>  drivers/gpu/drm/mxsfb/lcdif_drv.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)

Reviewed-by: Liu Ying <victor.liu@nxp.com>

-- 
Regards,
Liu Ying

Re: [PATCH 4/8] drm/bridge: dw-hdmi: document the output_port field

[Liu Ying]

Hi Luca,

On Fri, Mar 20, 2026 at 11:46:15AM +0100, Luca Ceresoli wrote:
> The meaning of this flag may not be obvious at first sight.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
>  include/drm/bridge/dw_hdmi.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index 336f062e1f9d..45f6ba1a8ee1 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -126,6 +126,11 @@ struct dw_hdmi_phy_ops {
>  struct dw_hdmi_plat_data {
>  	struct regmap *regm;
>  
> +	/*
> +	 * The HDMI output port number (which must be 1) if it is described

I'd rephrase:
The HDMI output port number must be 1 ...

> +	 * in the device tree. 0 if the device tree does not describe the
> +	 * next component (legacy mode).

Maybe be a bit more specific about "legacy mode":
legacy mode without DRM_BRIDGE_ATTACH_NO_CONNECTOR flag when attaching bridge
?

Reviewed-by: Liu Ying <victor.liu@nxp.com>

> +	 */
>  	unsigned int output_port;
>  
>  	unsigned long input_bus_encoding;
> 

-- 
Regards,
Liu Ying

Re: [PATCH 4/8] drm/bridge: dw-hdmi: document the output_port field

[Damon Ding]

On 3/26/2026 3:25 PM, Liu Ying wrote:
> Hi Luca,
> 
> On Fri, Mar 20, 2026 at 11:46:15AM +0100, Luca Ceresoli wrote:
>> The meaning of this flag may not be obvious at first sight.
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> ---
>>   include/drm/bridge/dw_hdmi.h | 5 +++++
>>   1 file changed, 5 insertions(+)
>>

First of all, these changes related to the DW HDMI controller work well 
when tested on RK3399 HDMI.

>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>> index 336f062e1f9d..45f6ba1a8ee1 100644
>> --- a/include/drm/bridge/dw_hdmi.h
>> +++ b/include/drm/bridge/dw_hdmi.h
>> @@ -126,6 +126,11 @@ struct dw_hdmi_phy_ops {
>>   struct dw_hdmi_plat_data {
>>   	struct regmap *regm;
>>   
>> +	/*
>> +	 * The HDMI output port number (which must be 1) if it is described
> 
> I'd rephrase:
> The HDMI output port number must be 1 ...
> 

Yes, the output port number should be 1, but I found that the output 
port number in the Rockchip-side dw-hdmi driver remains 0.

Therefore, it may be better to adapt the dw-hdmi drivers across all 
platforms to the bridge-connector architecture simultaneously.

This would allow removing &dw_hdmi_plat_data.output_port and unify the 
setting of DRM_BRIDGE_ATTACH_NO_CONNECTOR during the attach stage.
(Just as the Analogix DP driver does [0])

[0] 
https://lore.kernel.org/all/20260319071452.1961274-1-damon.ding@rock-chips.com/

>> +	 * in the device tree. 0 if the device tree does not describe the
>> +	 * next component (legacy mode).
> 
> Maybe be a bit more specific about "legacy mode":
> legacy mode without DRM_BRIDGE_ATTACH_NO_CONNECTOR flag when attaching bridge
> ?
> 
> Reviewed-by: Liu Ying <victor.liu@nxp.com>
> 
>> +	 */
>>   	unsigned int output_port;
>>   
>>   	unsigned long input_bus_encoding;
>>
> 

Best regards,
Damon

Re: [PATCH 4/8] drm/bridge: dw-hdmi: document the output_port field

[Luca Ceresoli]

Hello Damon,

On Thu Mar 26, 2026 at 10:15 AM CET, Damon Ding wrote:
> On 3/26/2026 3:25 PM, Liu Ying wrote:
>> Hi Luca,
>>
>> On Fri, Mar 20, 2026 at 11:46:15AM +0100, Luca Ceresoli wrote:
>>> The meaning of this flag may not be obvious at first sight.
>>>
>>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>> ---
>>>   include/drm/bridge/dw_hdmi.h | 5 +++++
>>>   1 file changed, 5 insertions(+)
>>>
>
> First of all, these changes related to the DW HDMI controller work well
> when tested on RK3399 HDMI.

Great!

You'd be welcome to send your Tested-by: tag if you tested the series on
hardware, that would be useful.

However at this point I suggest to wait for v2, which I'm sending soon, and
test that. I added you in Cc for it.

>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>> index 336f062e1f9d..45f6ba1a8ee1 100644
>>> --- a/include/drm/bridge/dw_hdmi.h
>>> +++ b/include/drm/bridge/dw_hdmi.h
>>> @@ -126,6 +126,11 @@ struct dw_hdmi_phy_ops {
>>>   struct dw_hdmi_plat_data {
>>>   	struct regmap *regm;
>>>
>>> +	/*
>>> +	 * The HDMI output port number (which must be 1) if it is described
>>
>> I'd rephrase:
>> The HDMI output port number must be 1 ...
>>
>
> Yes, the output port number should be 1, but I found that the output
> port number in the Rockchip-side dw-hdmi driver remains 0.

Really? I checked all the bindings in
Documentation/devicetree/bindings/display/rockchip/*hdmi* and all mention
port@1 as the output port number. Can you point to code using port@0 as the
output port?

Should it be true, that would be unfortunate because the output_port
variable does not handle this case. It's used as a sort of bool-or-int
variable:

 * as a bool [0] to find out whether the DT is supposed to describe the
   output port
 * as an integer to tell the port number to parse in DT [1]

So saying "please parse port 0" is impossible.

[0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
[1] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3315

> Therefore, it may be better to adapt the dw-hdmi drivers across all
> platforms to the bridge-connector architecture simultaneously.
>
> This would allow removing &dw_hdmi_plat_data.output_port and unify the
> setting of DRM_BRIDGE_ATTACH_NO_CONNECTOR during the attach stage.
> (Just as the Analogix DP driver does [0])
>
> [0]
> https://lore.kernel.org/all/20260319071452.1961274-1-damon.ding@rock-chips.com/

I agree converting all users is a good goal, but I disagree it should be
done simultaneously. There are various users of dw-hdmi, and converting one
having the hardware to test it was painful enough for me. Converting all of
them without testing on hardware would be a hell.

However I might be wrong. Having a precise list of all users, which ones
need to be converted, and whether they have any special detail to be taken
care of would be good to estimate the work to convert all users. Without
that I'd rather let users convert one by one and hopefully get rid of
legacy code eventually.

Best regards,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 4/8] drm/bridge: dw-hdmi: document the output_port field

[Damon Ding]

On 3/27/2026 7:10 PM, Luca Ceresoli wrote:
> Hello Damon,
> 
> On Thu Mar 26, 2026 at 10:15 AM CET, Damon Ding wrote:
>> On 3/26/2026 3:25 PM, Liu Ying wrote:
>>> Hi Luca,
>>>
>>> On Fri, Mar 20, 2026 at 11:46:15AM +0100, Luca Ceresoli wrote:
>>>> The meaning of this flag may not be obvious at first sight.
>>>>
>>>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>>> ---
>>>>    include/drm/bridge/dw_hdmi.h | 5 +++++
>>>>    1 file changed, 5 insertions(+)
>>>>
>>
>> First of all, these changes related to the DW HDMI controller work well
>> when tested on RK3399 HDMI.
> 
> Great!
> 
> You'd be welcome to send your Tested-by: tag if you tested the series on
> hardware, that would be useful.
> 
> However at this point I suggest to wait for v2, which I'm sending soon, and
> test that. I added you in Cc for it.
> 
>>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>>> index 336f062e1f9d..45f6ba1a8ee1 100644
>>>> --- a/include/drm/bridge/dw_hdmi.h
>>>> +++ b/include/drm/bridge/dw_hdmi.h
>>>> @@ -126,6 +126,11 @@ struct dw_hdmi_phy_ops {
>>>>    struct dw_hdmi_plat_data {
>>>>    	struct regmap *regm;
>>>>
>>>> +	/*
>>>> +	 * The HDMI output port number (which must be 1) if it is described
>>>
>>> I'd rephrase:
>>> The HDMI output port number must be 1 ...
>>>
>>
>> Yes, the output port number should be 1, but I found that the output
>> port number in the Rockchip-side dw-hdmi driver remains 0.
> 
> Really? I checked all the bindings in
> Documentation/devicetree/bindings/display/rockchip/*hdmi* and all mention
> port@1 as the output port number. Can you point to code using port@0 as the
> output port?
> 
> Should it be true, that would be unfortunate because the output_port
> variable does not handle this case. It's used as a sort of bool-or-int
> variable:
> 
>   * as a bool [0] to find out whether the DT is supposed to describe the
>     output port
>   * as an integer to tell the port number to parse in DT [1]
> 
> So saying "please parse port 0" is impossible.
> 
> [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
> [1] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3315
> 

Aha, my description might be a little misleading. The 
&dw_hdmi_plat_data.output_port is 0 on the Rockchip side, so the next 
bridge will not be parsed for it.

Then I think the &dw_hdmi_plat_data.output_port should be 1, as this 
helps support the hdmi-connector and other bridge chips.

>> Therefore, it may be better to adapt the dw-hdmi drivers across all
>> platforms to the bridge-connector architecture simultaneously.
>>
>> This would allow removing &dw_hdmi_plat_data.output_port and unify the
>> setting of DRM_BRIDGE_ATTACH_NO_CONNECTOR during the attach stage.
>> (Just as the Analogix DP driver does [0])
>>
>> [0]
>> https://lore.kernel.org/all/20260319071452.1961274-1-damon.ding@rock-chips.com/
> 
> I agree converting all users is a good goal, but I disagree it should be
> done simultaneously. There are various users of dw-hdmi, and converting one
> having the hardware to test it was painful enough for me. Converting all of
> them without testing on hardware would be a hell.
> 
> However I might be wrong. Having a precise list of all users, which ones
> need to be converted, and whether they have any special detail to be taken
> care of would be good to estimate the work to convert all users. Without
> that I'd rather let users convert one by one and hopefully get rid of
> legacy code eventually.
> 

Yes, I've noticed that there are quite a few drivers associated with the 
DW HDMI controller. It would be a better idea to let users handle this 
themselves.

BTW: The Rockchip side dw-hdmi patches for bridge connector support will 
be updated as a follow-up to your patch series. :-)

Best regards,
Damon

Re: [PATCH 4/8] drm/bridge: dw-hdmi: document the output_port field

[Luca Ceresoli]

Hello Damon,

On Mon Mar 30, 2026 at 3:13 AM CEST, Damon Ding wrote:
>>>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>>>> index 336f062e1f9d..45f6ba1a8ee1 100644
>>>>> --- a/include/drm/bridge/dw_hdmi.h
>>>>> +++ b/include/drm/bridge/dw_hdmi.h
>>>>> @@ -126,6 +126,11 @@ struct dw_hdmi_phy_ops {
>>>>>    struct dw_hdmi_plat_data {
>>>>>    	struct regmap *regm;
>>>>>
>>>>> +	/*
>>>>> +	 * The HDMI output port number (which must be 1) if it is described
>>>>
>>>> I'd rephrase:
>>>> The HDMI output port number must be 1 ...
>>>>
>>>
>>> Yes, the output port number should be 1, but I found that the output
>>> port number in the Rockchip-side dw-hdmi driver remains 0.
>>
>> Really? I checked all the bindings in
>> Documentation/devicetree/bindings/display/rockchip/*hdmi* and all mention
>> port@1 as the output port number. Can you point to code using port@0 as the
>> output port?
>>
>> Should it be true, that would be unfortunate because the output_port
>> variable does not handle this case. It's used as a sort of bool-or-int
>> variable:
>>
>>   * as a bool [0] to find out whether the DT is supposed to describe the
>>     output port
>>   * as an integer to tell the port number to parse in DT [1]
>>
>> So saying "please parse port 0" is impossible.
>>
>> [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
>> [1] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3315
>>
>
> Aha, my description might be a little misleading. The
> &dw_hdmi_plat_data.output_port is 0 on the Rockchip side, so the next
> bridge will not be parsed for it.
>
> Then I think the &dw_hdmi_plat_data.output_port should be 1, as this
> helps support the hdmi-connector and other bridge chips.

Ah, OK, that's all clear now.

> BTW: The Rockchip side dw-hdmi patches for bridge connector support will
> be updated as a follow-up to your patch series. :-)

Great! Don't forget to Cc me.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 5/8] drm/bridge: dw-hdmi: warn on unsupported attach combination

[Liu Ying]

On Fri, Mar 20, 2026 at 11:46:16AM +0100, Luca Ceresoli wrote:
> dw-hdmi 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
> 
>  B. hdmi->plat_data->output_port = 1:
>     the HDMI output (port@1) is parsed to find the next bridge
> 
> Only case B is supported when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is
> passed to the attach callback. Emit a warning when this is violated. Also
> return -EINVAL which would be returned by drm_bridge_attach() right after
> anyway.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> 
> ---
> 
> Note: Returning when teh warning triggers does not change the functional
> behaviour of this function. It is not strictly necessary in this patch but
> it will have to be done anyway in the following patch.
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++++
>  1 file changed, 4 insertions(+)

Reviewed-by: Liu Ying <victor.liu@nxp.com>

-- 
Regards,
Liu Ying

Re: [PATCH 6/8] drm/bridge: dw-hdmi: move next_bridge lookup to attach time

[Liu Ying]

Hi Luca,

On Fri, Mar 20, 2026 at 11:46:17AM +0100, Luca Ceresoli wrote:
> This driver looks up the next_bridge at probe time and stores it in
> hdmi->bridge.next_bridge, but only uses the stored value when attaching,
> and only in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
> 
> This will be problematic with an upcoming change, adding an hdmi-connector
> using a device tree overlay when not present. That change is in turn
> necessary to migrate the i.MX LCDIF driver to the bridge-connector.
> 
> The problem is that, adding the hdmi-connector via an overlay, devlink
> considers hdmi-connector a consumer of the dw-hdmi device, generating a
> chicken-egg problem:
> 
>  * hdmi-connector probe won't be tried until dw-hdmi is probed (devlink)
>  * dw-hdmi probe will defer until it finds the next_bridge (the
>    hdmi-connector wrapper bridge)
> 
> In preparation for those changes, move the next_bridge lookup from probe to
> attach, when it is actually used. This allows dw-hdmi to probe, so that the
> hdmi-connector can probe as well.
> 
> Also avoid storing the pointer in hdmi->bridge.next_bridge: the value is
> computed when needed, thus a local variable is enough.
> 
> Finally, this also allows to slightly improve the code by not doing any DT
> lookup in the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 41 +++++++++----------------------
>  1 file changed, 12 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a668d66aeece..4ee865a1a6c8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2914,9 +2914,18 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
>  	if (WARN_ON((flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) && !hdmi->plat_data->output_port))
>  		return -EINVAL;
>  
> -	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> -		return drm_bridge_attach(encoder, hdmi->bridge.next_bridge,
> -					 bridge, flags);
> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> +		struct device_node *remote __free(device_node) =

Include linux/cleanup.h as __free() is used.

> +			of_graph_get_remote_node(hdmi->dev->of_node,
> +						 hdmi->plat_data->output_port, -1);
> +		if (!remote)
> +			return -EPROBE_DEFER;

Should return -ENODEV instead?

> +
> +		struct drm_bridge *next_bridge __free(drm_bridge_put) =
> +			of_drm_find_and_get_bridge(remote);
> +
> +		return drm_bridge_attach(encoder, next_bridge, bridge, flags);
> +	}
>  
>  	return dw_hdmi_connector_create(hdmi);
>  }

-- 
Regards,
Liu Ying

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

[Liu Ying]

Hi Luca,

On Fri, Mar 20, 2026 at 11:46:19AM +0100, Luca Ceresoli wrote:
> Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the
> drm_bridge_connector framework which is the current DRM bridge best
> practice.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
>  drivers/gpu/drm/mxsfb/Kconfig     |  1 +
>  drivers/gpu/drm/mxsfb/lcdif_drv.c | 12 +++++++++++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 264e74f45554..1a8a5d1ba8c0 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -33,6 +33,7 @@ config DRM_IMX_LCDIF
>  	select DRM_GEM_DMA_HELPER
>  	select DRM_PANEL
>  	select DRM_PANEL_BRIDGE
> +	select DRM_BRIDGE_CONNECTOR

Also, select DRM_DISPLAY_HELPER.

>  	help
>  	  Choose this option if you have an LCDIFv3 LCD controller.
>  	  Those devices are found in various i.MX SoC (i.MX8MP,

-- 
Regards,
Liu Ying

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Liu Ying]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Luca Ceresoli]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Liu Ying]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Luca Ceresoli]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Liu Ying]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Luca Ceresoli]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Liu Ying]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Luca Ceresoli]

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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Laurent Pinchart]

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
> 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

Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time

[Luca Ceresoli]

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

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

[Martyn Welch]

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,