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