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 88870365A00 for ; Thu, 2 Apr 2026 08:29:05 +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=1775118548; cv=none; b=WRHhIBEnVqaUNgdDRjsFiwlCzaYfVOobYqmS5tx8tAPVLmhHCJprR4dIjy4hYAZvLVusXtCX5mee3J89Sse81hRec/JTwAD3jiVspPDUHJfcRHqeZKiKZsV/na9eJZ9JaDzcWDvA0xxLZ2UCWXC2J8NiCedLkSQi+sGhNr/uvtQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775118548; c=relaxed/simple; bh=uk0TRGZ/7j2WEcvC0XWuN/juRSLDcXKlLTVCpt473HY=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=adU11v6otI0slKVA9V5S/9GKyul86MuTT/x0L8emL9LwTno3JSiORlBt9LcMInYRnmZQS8qne/fMqzVWYyj4EpN4yW1PQPdSb9n6fXSY00VV4UW4bTK9Y/Ec2KpLeeWsIuccCCi7YEOMHm0KBRukqiw67Mc7b6lDvRrQ+W0apI4= 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=TNUHH2pA; 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="TNUHH2pA" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id C3CC41A30E9; Thu, 2 Apr 2026 08:29:03 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 837475FDEB; Thu, 2 Apr 2026 08:29:03 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 94AD710450221; Thu, 2 Apr 2026 10:28:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1775118541; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=PUXno5TxkjpeBoSqZm65CbuO+h64L2SVBgOxOmu2oIo=; b=TNUHH2pAZPAMP4NGLsz+uJewT7ce/5mkiukpdC9e/GF/cCgcQr2XiVigjiYOaiqLn0jVFV MT7V55Gngp/p+G3cUIgeeaGjdsunI4FxxTXZV1VCvaZp8Fu1NmDMH4fpCoySsakeh4UzpF lX48nkRylKWcwrlYejZxz4eLsr/mNruwRWad4ESyVHvE9nUIrx3Bx2UJfAcE1I0nEmmVXa l6SnamIUZgMY5xRvEVj9Yq2kwWG4Du2bg3fbFoea5Ew5M1g5zMxgDAAnIdY63ggTOMOue5 +WOpPf9dvsdGz8Qf5D4+FLkyjNYPxNRVRz6lM1LRBcgO1HZxCQRpeH0WvglegQ== 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: Thu, 02 Apr 2026 10:28:45 +0200 Message-Id: Cc: "Damon Ding" , "Kory Maincent (TI.com)" , =?utf-8?q?Herv=C3=A9_Codina?= , "Hui Pu" , "Ian Ray" , "Thomas Petazzoni" , , , , , , "Adam Ford" , "Alexander Stein" , "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" , "Josua Mayer" , "Kieran Bingham" , "Marco Felsch" , "Martyn Welch" , "Oleksij Rempel" , "Peng Fan" , "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" Subject: Re: [PATCH v2 10/10] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector X-Mailer: aerc 0.20.1 References: <20260330-drm-lcdif-dbanc-v2-0-c7f2af536a24@bootlin.com> <20260330-drm-lcdif-dbanc-v2-10-c7f2af536a24@bootlin.com> <1a8b1a34-89bd-436e-8b5c-64ea71e8f333@nxp.com> In-Reply-To: <1a8b1a34-89bd-436e-8b5c-64ea71e8f333@nxp.com> X-Last-TLS-Session-Version: TLSv1.3 Hello Liu, On Thu Apr 2, 2026 at 6:55 AM CEST, Liu Ying wrote: > Hi Luca, > > On Mon, Mar 30, 2026 at 09:25:51PM +0200, 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. >> >> Tested-by: Martyn Welch >> Tested-by: Alexander Stein # TQMa8MPxL= /MBa8MPxL >> Signed-off-by: Luca Ceresoli >> @@ -86,11 +88,23 @@ static int lcdif_attach_bridge(struct lcdif_drm_priv= ate *lcdif) >> "Failed to initialize encoder for endpoint%u\n", >> of_ep.id); >> >> - ret =3D drm_bridge_attach(encoder, bridge, NULL, 0); >> + ret =3D drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO= _CONNECTOR); > > It seems that only analogix-anx6345.c, analogix-anx78xx.c and analogix_dp= _core.c > don't allow DRM_BRIDGE_ATTACH_NO_CONNECTOR, since they error out when att= aching > the bridge with the flag: > > if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) { > DRM_ERROR("Fix bridge driver to make connector optional!"); > return -EINVAL; > } > > Looks like i.MX8MP platforms don't use these drivers. Exactly. I have checked all the drivers involved with the i.MX8MP and all of the support DRM_BRIDGE_ATTACH_NO_CONNECTOR. While converting all drivers is surely a good goal, converting all of them at once is not realistically doable. So the approach I took was to convert one specifically (lcdif_drv.c) plus all those which would break because they are used with the LCDIF. > But, are we completely safe here by adding the flag? You also mentioned > "pitfalls" in commit mesg, which makes me a bit more worried. I mentioned potential pitfalls in the cover letter mainly because of the DT overlay insertion patch, which is somewhat tricky as it impacts many boards. Additionally it's not easy to spot all usages of this component by parsing dozens of dts files, so I might have missed some. So overall every patch sent has a potential for pitfalls, but for the reasons above I think this series has a bit more. Does this reassure you? :) >> if (ret) >> return dev_err_probe(dev, ret, >> "Failed to attach bridge for endpoint%u\n", >> of_ep.id); >> + >> + connector =3D drm_bridge_connector_init(lcdif->drm, encoder); > > Also, kernel doc of drm_bridge_connector.c says: > > * To make use of this helper, all bridges in the chain shall report brid= ge > * operation flags (&drm_bridge->ops) and bridge output type > * (&drm_bridge->type), as well as the DRM_BRIDGE_ATTACH_NO_CONNECTOR att= ach > * flag (none of the bridges shall create a DRM connector directly). > > Are you sure that we are safe to use this helper? Yes. I have checked all in-tree dts[i] files for all the 3 LCDIFs. For the LCDIF3, the pipeline is: LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector And the involved bridges are: * fsl,imx8mp-hdmi-pvi has ops =3D 0 (it doesn't set it) because it implements none the optional features mentioned by those flags, and it honors the DRM_BRIDGE_ATTACH_NO_CONNECTOR by propagating it * fsl,imx8mp-hdmi-tx is implemented based on dw-hdmi, which sets ops as appropriate and also propagates the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag * display-connector (enabled via the DT overlay if needed) sets ops and makes DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory The LCDIF2 involves the panel-bridge, display-connector and lvds-decoder which also set ops as needed and propagate DRM_BRIDGE_ATTACH_NO_CONNECTOR or make it mandatory. The same applies to the drivers used with the LCDIF1: adv7511, tc358767 and the panel bridge. I assume this answers your doubts. Let me know if it doesn't. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com