From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4F4A5CDB479 for ; Wed, 24 Jun 2026 16:07:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Cc: Subject:From:To:Message-Id:Date:Content-Type:Content-Transfer-Encoding: Mime-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=N3v36YslEFTvIe9aSboloVtZTLcZwXqsmCLNtL+8QuI=; b=qGMrKWI73JH1FxNFGrkdcYKPlD DJ6RAe2EIDzgMwxzwlq5fIQ7u86D6ipWhQseO4gtW9yS/QOnBHueOqDHE2KeCp6kLkH3bgkp3/0x4 9VKMZqnVysVNJFx+00XsjCBp2vX9g7GboJ6He5q99p5kfL3CU2Xn7PTyVrYTyCjOWuQN+lUml7IPs T9gSIYVsrJUQ9x/D7xu+81uOL3nsd1VQtgdrliVlUZ7cW9r2PKC9fwkxAqUGu3KY6xTDe63e27ajC ts1QzKO5KAyacWXvwIr3i94uEjQmD5lTSF3mhnpNA2yKqjMWOboym7233KUtHdwzptA0X0etkiy7+ FSKkGI6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wcQ7y-000000085Jo-3xHa; Wed, 24 Jun 2026 16:07:02 +0000 Received: from smtpout-02.galae.net ([185.246.84.56]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wcQ7v-000000085IP-2OJW for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2026 16:07:01 +0000 Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id D48791A0923; Wed, 24 Jun 2026 16:06:56 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id A3C69601C5; Wed, 24 Jun 2026 16:06:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 502E1106C8468; Wed, 24 Jun 2026 18:06:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1782317215; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=N3v36YslEFTvIe9aSboloVtZTLcZwXqsmCLNtL+8QuI=; b=RjmT+un4qnnBjmGoKLf/boh6gu+rTh4ct3BN5juGXqgOv7bgnvX9vEWv3HUtBp+QuzJD5Q N6vRla5R96P4XxouiUhAdC1HzU5C4ileLGLhhO+vxj2PB3zdepND0Fu6fyhHaKGIe2Ku8Z DsWzrXMd/nqD0xS+lLv8vZrf2rrg+kz0mJZ9Ojb7zCXHExHam5OZsbEeLNZWrV5+UUAQRQ Ue1+yCqg1OKk8ghIpB+KxGaSy3evpBqIWgzGFLWS0HhHotZcB3KbL7lSv4CbEf5NBC58at T6WLbK/qhE2i8Gacrjtc7yinm3pm+aC4JaMPb/LLS/JSyTkS6L6ebzc+kO+bDQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 24 Jun 2026 18:06:47 +0200 Message-Id: To: "Maxime Ripard" , "Luca Ceresoli" From: "Luca Ceresoli" Subject: Re: [PATCH 30/37] drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline Cc: "Maarten Lankhorst" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Andrzej Hajda" , "Neil Armstrong" , "Robert Foss" , "Laurent Pinchart" , "Jonas Karlman" , "Jernej Skrabec" , "Inki Dae" , "Jagan Teki" , "Marek Szyprowski" , "Marek Vasut" , "Stefan Agner" , "Frank Li" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Hui Pu" , "Ian Ray" , "Thomas Petazzoni" , , , , X-Mailer: aerc 0.21.0 References: <20260519-drm-bridge-hotplug-v1-0-45e2bdb3dfb4@bootlin.com> <20260519-drm-bridge-hotplug-v1-30-45e2bdb3dfb4@bootlin.com> <20260608-shapeless-opal-ferret-c8b105@houat> <20260624-vagabond-neon-gorilla-cd6487@houat> In-Reply-To: <20260624-vagabond-neon-gorilla-cd6487@houat> X-Last-TLS-Session-Version: TLSv1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260624_090659_753564_A648FD12 X-CRM114-Status: GOOD ( 38.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed Jun 24, 2026 at 3:04 PM CEST, Maxime Ripard wrote: > On Tue, Jun 09, 2026 at 10:23:24AM +0200, Luca Ceresoli wrote: >> Hi Maxime, >> >> thanks for the review of this long series! >> >> On Mon Jun 8, 2026 at 2:34 PM CEST, Maxime Ripard wrote: >> ... >> >> --- a/include/drm/drm_bridge.h >> >> +++ b/include/drm/drm_bridge.h >> >> @@ -78,6 +78,19 @@ struct drm_bridge_funcs { >> >> int (*attach)(struct drm_bridge *bridge, struct drm_encoder *encode= r, >> >> enum drm_bridge_attach_flags flags); >> >> >> >> + /** >> >> + * @is_tail: >> >> + * >> >> + * Returns true if this is a tail bridge, i.e. it does not need a >> >> + * next bridge to work. E.g. a panel_bridge is a tail bridge, a >> >> + * DSI-to-LVDS bridge is not a tail bridge (no matter whether the >> >> + * next bridge is present or not). >> > >> > Why a DSI-to-LDVS bridge isn't a tail bridge? It only needs a panel >> > next, right? >> >> Uhm, good point, but I'd say it can be a tail bridge or not: in the >> ATTACH_NO_CONNECTOR case it will need a bridge (a panel_bridge most >> likely), no? > > Yeah, I think it cannot (always) be a blanket statement from the driver. > For drivers that do not support ATTACH_NO_CONNECTOR, then it's always > going to be a tail, but if the driver supports it, we should use a > helper because it's going to depend on the DT, basically. > >> However this is possibly irrelevant as the whole .is_tail is meant to >> disappear in v2, see below. >> >> >> + * The @is_tail callback is optional but it is required if the >> >> + * bridge is part of a pipeline with hot-pluggable components. >> >> + */ >> >> + bool (*is_tail)(struct drm_bridge *bridge); >> >> + >> > >> > I don't think that's the right way to think about it, if only because >> > you never really know at the driver level if you're supposed to be las= t >> > or not. A DSI-to-LVDS bridge might just as well be chained with an >> > LVDS-to-eDP bridge, or feed the panel directly without any additional >> > bridge. >> > >> > I *think* that what you're trying to find out here is whether the chai= n >> > is complete or not. >> >> You nailed it. >> >> That was the main point discussed during the Display Next Hackfest 2026 >> (see the report [0]) and we all agreed the .is_tail along with the >> -EPROBE_DEFER changes (patches 20+35) are not a good approach. >> >> This is actually the most crucial aspect of the whole work still not hav= ing >> no well-defined solution. > > Ok > >> > I think you can get the same information by checking >> > whether you have a connector for that bridge chain. If you don't, you >> > know the chain isn't complete, and if you do, it's supposed to be. >> >> There's a checken-egg problem here. Knowing whether the pipeline is >> complete or not is needed to know whether we have to create a >> connector. See patch 36: >> >> + if (drm_bridge_connector_pipeline_is_complete(bridge_connector)) >> + drm_bridge_connector_add_connector(bridge_connector); >> >> So the question is still open, what I need the most right now is comment= s >> on the overall architecture of this aspecs. Maybe replying to [0] can be >> more effective than here. >> >> In a nutshell what we need is: >> >> * when a bridge needs a following element (a bridge, or a panel which >> however might/should have a panel_bridge), but that element is not >> present, instead of deferring the whole card probe the card should be >> allowed to probe but without a connector >> >> * when something is added to an incomplete pipeline we need to know >> whether the pipeline has become complete (in order to create the >> connector) >> >> How to implement this is still an open point. I'll welcome proposals in >> addition to the ones in [0]. > > Thanks for the notes, I think I largely agree with the discussion. Good! :) > Reading through it, I thought it would be nice for a new callback called > get_next_bridge or something that would return either an error, NULL or a > (refcounted) pointer to the next bridge in the chain. And have some kind > of special error (ENODEV?) when the bridge should be there but isn't > (and thus the chain isn't complete). I initially preferred exposing the fwnode of the next bridge as discussed with Dmitry during the Display Next Hackfest, which looks simpler for driver writers. But then I realized it would be tricyk in cases such as dual-LVDS output bridges (ti-sn65dsi83.c) which have two output ports in DT, none of which is mandatory. So I've come to thinking a callback is better as it should be flexible enough. Picking the best errno is probably the only aspect needing special attention now. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com