public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Liu Ying <victor.liu@nxp.com>
To: Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Marek Vasut <marex@denx.de>, Stefan Agner <stefan@agner.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Frank Li <Frank.Li@nxp.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Rob Herring <robh@kernel.org>,
	Saravana Kannan <saravanak@kernel.org>
Cc: "Kory Maincent (TI.com)" <kory.maincent@bootlin.com>,
	"Hervé Codina" <herve.codina@bootlin.com>,
	"Hui Pu" <Hui.Pu@gehealthcare.com>,
	"Ian Ray" <ian.ray@gehealthcare.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	dri-devel@lists.freedesktop.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	"Adam Ford" <aford173@gmail.com>,
	"Alexander Stein" <alexander.stein@ew.tq-group.com>,
	"Anson Huang" <Anson.Huang@nxp.com>,
	"Christopher Obbard" <christopher.obbard@linaro.org>,
	"Daniel Scally" <dan.scally@ideasonboard.com>,
	"Emanuele Ghidoli" <emanuele.ghidoli@toradex.com>,
	"Fabio Estevam" <festevam@denx.de>,
	"Francesco Dolcini" <francesco.dolcini@toradex.com>,
	"Frieder Schrempf" <frieder.schrempf@kontron.de>,
	"Gilles Talis" <gilles.talis@gmail.com>,
	"Goran Rađenović" <goran.radni@gmail.com>,
	"Heiko Schocher" <hs@denx.de>,
	"Joao Paulo Goncalves" <joao.goncalves@toradex.com>,
	"Josua Mayer" <josua@solid-run.com>,
	"Kieran Bingham" <kieran.bingham@ideasonboard.com>,
	"Marco Felsch" <m.felsch@pengutronix.de>,
	"Martyn Welch" <martyn.welch@collabora.com>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Peng Fan" <peng.fan@nxp.com>,
	"Philippe Schenker" <philippe.schenker@toradex.com>,
	"Richard Hu" <richard.hu@technexion.com>,
	"Shengjiu Wang" <shengjiu.wang@nxp.com>,
	"Stefan Eichenberger" <stefan.eichenberger@toradex.com>,
	"Vitor Soares" <vitor.soares@toradex.com>
Subject: Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
Date: Wed, 1 Apr 2026 14:45:03 +0800	[thread overview]
Message-ID: <246ca728-1be6-4dd9-b228-7d99f28e1abe@nxp.com> (raw)
In-Reply-To: <DHGWUIUIKETI.1F1636GUBB3VI@bootlin.com>

Hi Luca,

On Tue, Mar 31, 2026 at 12:54:30PM +0200, Luca Ceresoli wrote:
> Hello Liu,
> 
> On Tue Mar 31, 2026 at 5:03 AM CEST, Liu Ying wrote:
>> Hi Luca,
>>
>> On Mon, Mar 30, 2026 at 05:47:23PM +0200, Luca Ceresoli wrote:
>>> Hello Liu,
>>>
>>> On Mon Mar 30, 2026 at 5:02 AM CEST, Liu Ying wrote:
>>
>> [...]
>>
>>>>>>> +	fixup-hdmi-connector {
>>>>>>> +		compatible = "hdmi-connector";
>>>>>>> +		label = "HDMI";
>>>>>>> +		type = "a";
>>>>>>
>>>>>> What if a board uses another type?
>>>>>
>>>>> For boards affected by this patch, currently the connector is created by
>>>>> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
>>>>> difference.
>>>>
>>>> Yes, that's from driver's PoV.  However, userspace may get the type
>>>> from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
>>>> to do something.
>>>
>>> I'd say this is incorrect, the device tree is not an API for that. The
>>> connector type might be known to the driver by other means (ACPI, DP MST,
>>> whatever). So I think this is a non-problem.
>>
>> I just feel that it's not great to report potentially wrong type to users
>> through the above sys node ...
>>
>>>
>>> If userspace needs to know the connector type, that should come from the
>>> ioctl (DRM_IOCTL_MODE_GETCONNECTOR perhaps).
>>>
>>>> Maybe, that's trivial.
>>>
>>> Not sure I got what you mean here, sorry. What are you referring to?
>>
>> ... with the above potentially wrong type being said, I think maybe this
>> drawback is not a big deal and could be ignored.  Sorry for not being
>> clear in my last reply.
> 
> Ah, clear now. No problem!
> 
>>>>> Boards with a different connector should describe the connector in the
>>>>> device tree, if they need to instantiate the exact type.
>>>
>>> I think this is the only valid solution. It's very easy to do, nothing new
>>> to invent.
>>>
>>> Maybe on top of that we could add a warning when the overlay is applied,
>>> e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
>>> adding a type A connector as a fallback; please add a valid description to
>>> your device tree".
>>
>> I'd say this doesn't sound a bad idea but I hope the message is clear and
>> short.
> 
> What about:
> 
>   Connector description not found in device tree, please add one. Falling back to Type A.

Maybe:
Please add a hdmi-connector DT node for imx8mp-hdmi-tx. A fixup node in type a is added for now.

> 
>>> Maybe pointing to a TODO entry in the documentation.
>>
>> To parameterize the HDMI connector type?  If so, I'm okay with that.
> 
> I was meaning a TODO entry to suggest people to add a connector description
> to the dts. E.g., expanding on the above suggested warning:
> 
>   Connector description not found in device tree, please add one. See https://docs.kernel.org/gpu/todo.html#<...>
> 
> And of course adding a TODO entry describing what one needs to do (add an
> hdmi-connector node and link it to port@1 of the hdmi-tx).
> 
> The drawback of the TODO is that items in todo.rst are supposed to be
> removed eventually when done in the code, but this one cannot be removed
> until some kernels printing the above logging message will be around,
> i.e. potentially for decades.

Not a big fan of adding a TODO entry, because those DT blobs without a
hdmi-connector node could be out there forever, meaning the added TODO
entry can never be removed.

> 
> So maybe the simplest solution is just the first warning message + a
> comment in the code right before the warning line, so it easily found with
> grep or a web search by who sees the warning.

+1.

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

-- 
Regards,
Liu Ying

  reply	other threads:[~2026-04-01  6:44 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20 10:46 [PATCH 0/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector Luca Ceresoli
2026-03-20 10:46 ` [PATCH 1/8] drm/mxsfb/lcdif: simplify remote pointer management using __free Luca Ceresoli
2026-03-20 11:11   ` Luca Ceresoli
2026-03-26  6:40   ` Liu Ying
2026-03-26  6:48     ` Liu Ying
2026-03-20 10:46 ` [PATCH 2/8] drm/mxsfb/lcdif: don't unnecessarily loop over ports Luca Ceresoli
2026-03-26  6:59   ` Liu Ying
2026-03-27 11:10     ` Luca Ceresoli
2026-03-20 10:46 ` [PATCH 3/8] drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge Luca Ceresoli
2026-03-26  7:03   ` Liu Ying
2026-03-20 10:46 ` [PATCH 4/8] drm/bridge: dw-hdmi: document the output_port field Luca Ceresoli
2026-03-26  7:25   ` Liu Ying
2026-03-26  9:15     ` Damon Ding
2026-03-27 11:10       ` Luca Ceresoli
2026-03-30  1:13         ` Damon Ding
2026-03-30 15:10           ` Luca Ceresoli
2026-03-20 10:46 ` [PATCH 5/8] drm/bridge: dw-hdmi: warn on unsupported attach combination Luca Ceresoli
2026-03-26  7:35   ` Liu Ying
2026-03-20 10:46 ` [PATCH 6/8] drm/bridge: dw-hdmi: move next_bridge lookup to attach time Luca Ceresoli
2026-03-26  7:50   ` Liu Ying
2026-03-20 10:46 ` [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time Luca Ceresoli
2026-03-26  8:15   ` Liu Ying
2026-03-27 14:46     ` Luca Ceresoli
2026-03-30  3:02       ` Liu Ying
2026-03-30 15:47         ` Luca Ceresoli
2026-03-31  3:03           ` Liu Ying
2026-03-31 10:54             ` Luca Ceresoli
2026-04-01  6:45               ` Liu Ying [this message]
2026-04-01  7:51                 ` Luca Ceresoli
2026-03-26  8:28   ` Laurent Pinchart
2026-03-27 15:17     ` Luca Ceresoli
2026-03-20 10:46 ` [PATCH 8/8] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector Luca Ceresoli
2026-03-26  8:24   ` Liu Ying
2026-03-23  8:46 ` [PATCH 0/8] " Alexander Stein
2026-03-26 17:13 ` Martyn Welch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=246ca728-1be6-4dd9-b228-7d99f28e1abe@nxp.com \
    --to=victor.liu@nxp.com \
    --cc=Anson.Huang@nxp.com \
    --cc=Frank.Li@nxp.com \
    --cc=Hui.Pu@gehealthcare.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=aford173@gmail.com \
    --cc=airlied@gmail.com \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=andrzej.hajda@intel.com \
    --cc=christopher.obbard@linaro.org \
    --cc=dan.scally@ideasonboard.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emanuele.ghidoli@toradex.com \
    --cc=festevam@denx.de \
    --cc=festevam@gmail.com \
    --cc=francesco.dolcini@toradex.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=gilles.talis@gmail.com \
    --cc=goran.radni@gmail.com \
    --cc=herve.codina@bootlin.com \
    --cc=hs@denx.de \
    --cc=ian.ray@gehealthcare.com \
    --cc=imx@lists.linux.dev \
    --cc=jernej.skrabec@gmail.com \
    --cc=joao.goncalves@toradex.com \
    --cc=jonas@kwiboo.se \
    --cc=josua@solid-run.com \
    --cc=kernel@pengutronix.de \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=kory.maincent@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=m.felsch@pengutronix.de \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marex@denx.de \
    --cc=martyn.welch@collabora.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=o.rempel@pengutronix.de \
    --cc=peng.fan@nxp.com \
    --cc=philippe.schenker@toradex.com \
    --cc=rfoss@kernel.org \
    --cc=richard.hu@technexion.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=saravanak@kernel.org \
    --cc=shengjiu.wang@nxp.com \
    --cc=simona@ffwll.ch \
    --cc=stefan.eichenberger@toradex.com \
    --cc=stefan@agner.ch \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tzimmermann@suse.de \
    --cc=vitor.soares@toradex.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox