From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D0DC3A9DB6 for ; Tue, 31 Mar 2026 10:54:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774954495; cv=none; b=b33Y7ntLzKGEDIHkOl8qrWvCBzHBWEnHpzeUDoxWG2LDWx7xYO2b2Pw3oNYX5zUnxP+LO+d4P4K842+s1w/l8SfjdFzf/l8IZ3R6mBHObVE5gTaibQ7THVZK8x45OeKITCYTzC0w0cMtcA9/JfqGRu1j0JXWkGdCKAAuNo3GwLk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774954495; c=relaxed/simple; bh=01BLDUIE042rdiUNErhUHuYN+13nkq8UQhcqVy5Kq4M=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=AA6mOLB5Pvx0Su7QNgsHYbqttROvfxyp65mw8scgjPCeJ3tMMb5YNV6LrFqjWalUPWcfKeR5Cd6WqCOh7mgPVxD+5kUodRCmzWBGakupZjCm7tKtO+v3MWCH0Bg1ghgrzy79qym9upVez6FznacfVeIFJtJj/uCOajiQL2Gq3vQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=M+B7mJwU; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="M+B7mJwU" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id D39991A30BF; Tue, 31 Mar 2026 10:54:50 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 9BF5A602CD; Tue, 31 Mar 2026 10:54:50 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 4F8B6104505CA; Tue, 31 Mar 2026 12:54:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1774954487; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=qDgz531RmkefuEvnhqpL6F+0n4jtWlVFpT0D9ukPSnc=; b=M+B7mJwUdJ737gkyUjDrg4ZfLPjmt2IDlaNDsNRqt54vtdI6gQ+Mkj7hI5XdBJLv54LuIU yKINAVdHwdzszU0t/NgEZa7ZLOBl7sXd09v3YNE8YBbRhw05IhDgj5pN4ps+2y/+7XSGo3 10YtEYZeSjABRSgWpzAOCRT2V8tiyJxh/HjFPMWsYWpFAYJYu5k8ti0GTQd9afDQzp2MmK cwbhFdWF/EU6zuWYHMtdLN2McxBSEtoU9p0z6cHWy+U9bPXOAyUja5yp5FLrYF8uuhIaKr rYRCm3ByzO+YyFf4cubFsULwxKDH2mZRHZ6qhyCRouk+aHMfCMxhEd5MCZVaRQ== Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 31 Mar 2026 12:54:30 +0200 Message-Id: Subject: Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time Cc: "Kory Maincent (TI.com)" , =?utf-8?q?Herv=C3=A9_Codina?= , "Hui Pu" , "Ian Ray" , "Thomas Petazzoni" , , , , , , "Adam Ford" , "Alexander Stein" , "Anson Huang" , "Christopher Obbard" , "Daniel Scally" , "Emanuele Ghidoli" , "Fabio Estevam" , "Francesco Dolcini" , "Frieder Schrempf" , "Gilles Talis" , =?utf-8?q?Goran_Ra=C4=91enovi=C4=87?= , "Heiko Schocher" , "Joao Paulo Goncalves" , "Josua Mayer" , "Kieran Bingham" , "Marco Felsch" , "Martyn Welch" , "Oleksij Rempel" , "Peng Fan" , "Philippe Schenker" , "Richard Hu" , "Shengjiu Wang" , "Stefan Eichenberger" , "Vitor Soares" To: "Liu Ying" , "Marek Vasut" , "Stefan Agner" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Frank Li" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Andrzej Hajda" , "Neil Armstrong" , "Robert Foss" , "Laurent Pinchart" , "Jonas Karlman" , "Jernej Skrabec" , "Rob Herring" , "Saravana Kannan" From: "Luca Ceresoli" X-Mailer: aerc 0.20.1 References: <20260320-drm-lcdif-dbanc-v1-0-479a04133e70@bootlin.com> <20260320-drm-lcdif-dbanc-v1-7-479a04133e70@bootlin.com> <544112ab-8ca0-4622-b680-233457198e3e@nxp.com> <5f06ea5a-5388-440f-91d6-cebb0bee0a88@nxp.com> <9a6e74ed-d4ab-4f11-ab17-25e1a2b64b2d@nxp.com> In-Reply-To: <9a6e74ed-d4ab-4f11-ab17-25e1a2b64b2d@nxp.com> X-Last-TLS-Session-Version: TLSv1.3 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 =3D "hdmi-connector"; >>>>>> + label =3D "HDMI"; >>>>>> + type =3D "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 n= ew >> 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 b= ack 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