From nobody Thu Mar 19 05:38:03 2026 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (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 866CE3A963C; Thu, 5 Mar 2026 14:23:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772720607; cv=pass; b=JSYY/VkdG2+J9UuQTfVXy2U8ZGeQqdDcFCO1pW26MmWEvyPlefDNm4AtHSWpHu7Uyqr2ec6nWRUfYD8o/wkOpn0FDnKyh9JuTJYuJ4sBgy2yZ9LSmHZwYWU9po9jjFJwQvVYOtn8/ZPsmwjTdql7D6xGRFJY6oTdNZw71ndXG88= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772720607; c=relaxed/simple; bh=bLd8Uu0e9nJuphcl9D2pXwY1JYP1ONvBa3+qkzpNOo8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=CTc6z/BoMtPcDX4Wf9wHHbZ47z/7Svfq9vk8ClyTzw/XeQvNm2bnFgqud4WbOspPeWfm2LVYY+28d2AkKoACJzKUnatnuGTCVi2q/vXWSFGW1uLU73N04aaWC4ycW9aWljVSJflJXbtf1M9IQzC2QTmwykCff++JE4ZzHIANz1I= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b=R3BTto6H; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="R3BTto6H" ARC-Seal: i=1; a=rsa-sha256; t=1772720565; cv=none; d=zohomail.com; s=zohoarc; b=QO7S6+tMxYLUuPbcO1pLetZx8TWaiv7sSs9huh2qqwUqPqxB753ovpQMr9s0MqIOtUx84k8ZYOm2RgKzmRwqWm5AQV7VYzbRwbFUj/jTgbaWfuo6H8nrGAFC4VbYi7bLuo/BAACJNVM/IsDhZumC0R5JVli/8y3Fg4hYd3AJupc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772720565; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=yE8vbeYdKcftvYs+PymllWj2E1+jwIq94xvRBnlmVWA=; b=VWeSKUxEcuISXPdF/ECTat7ENYuPtHg11EyI2q0B3+gochGu2/NPdlsjvpYeDNjhb1RYAG6eryoG8LFl3gNTGwmgOFLGfQdCcA4Lt7bxAxmDL/W75rrHZGt72bL3xcd+VGKe6ZoMavXW4sJP97o998Kr/cjtbuzmz+dP14EMv/Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1772720565; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:Date:Date:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Message-Id:References:In-Reply-To:To:To:Cc:Cc:Reply-To; bh=yE8vbeYdKcftvYs+PymllWj2E1+jwIq94xvRBnlmVWA=; b=R3BTto6H/5Kl0ixzAFRKP2l3+2zayBXVO42c8lsz0pYykas8PF7bi2fKrL3HnApz dPUVNP3DWMwNXqK2bhAV//hSWh/4ywfSYpUufsI56X/nBfxoF3VYuse8Es5mA5ExJQd B7qEIZRstoljb7U4+B+NktmpET4Uw8DYccQnOKv0= Received: by mx.zohomail.com with SMTPS id 1772720564028953.1845608441924; Thu, 5 Mar 2026 06:22:44 -0800 (PST) From: Nicolas Frattaroli Date: Thu, 05 Mar 2026 15:19:48 +0100 Subject: [PATCH v10 22/22] drm/bridge: Document bridge chain format selection Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260305-color-format-v10-22-a58c68a11868@collabora.com> References: <20260305-color-format-v10-0-a58c68a11868@collabora.com> In-Reply-To: <20260305-color-format-v10-0-a58c68a11868@collabora.com> To: Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , =?utf-8?q?Christian_K=C3=B6nig?= , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Sandy Huang , =?utf-8?q?Heiko_St=C3=BCbner?= , Andy Yan , Jani Nikula , Rodrigo Vivi , Joonas Lahtinen , Tvrtko Ursulin , Dmitry Baryshkov , Sascha Hauer , Rob Herring , Jonathan Corbet , Shuah Khan Cc: kernel@collabora.com, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-doc@vger.kernel.org, Nicolas Frattaroli X-Mailer: b4 0.14.3 The bridge chain format selection behaviour was, until now, undocumented. With the addition of the "color format" DRM property, it's not sufficiently complex enough that documentation is warranted, especially for driver authors trying to do the right thing. Add a high-level overview of how the process is supposed to work, and mention what the display driver is supposed to do if it wants to make use of this functionality. Reviewed-by: Maxime Ripard Signed-off-by: Nicolas Frattaroli --- Documentation/gpu/drm-kms-helpers.rst | 6 ++++++ drivers/gpu/drm/drm_bridge.c | 40 +++++++++++++++++++++++++++++++= ++++ 2 files changed, 46 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-= kms-helpers.rst index 781129f78b06..47c4f593cf9d 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -181,6 +181,12 @@ Bridge Operations .. kernel-doc:: drivers/gpu/drm/drm_bridge.c :doc: bridge operations =20 +Bridge Chain Format Selection +----------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_bridge.c + :doc: bridge chain format selection + Bridge Connector Helper ----------------------- =20 diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 6ad725e511f3..da021b49acc6 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -198,6 +198,46 @@ * driver. */ =20 +/** + * DOC: bridge chain format selection + * + * A bridge chain, from display output processor to connector, may contain + * bridges capable of converting between bus formats on their inputs, and + * output formats on their outputs. For example, a bridge may be able to c= onvert + * from RGB to YCbCr 4:4:4, and pass through YCbCr 4:2:0 as-is, but not co= nvert + * from RGB to YCbCr 4:2:0. This means not all input formats map to all ou= tput + * formats. + * + * Further adding to this, a desired output color format, as specified wit= h the + * "color format" DRM property, might not correspond 1:1 to what the displ= ay + * driver should set at its output. The bridge chain it feeds into may onl= y be + * able to reach the desired output format, if a conversion from a differe= nt + * starting format is performed. + * + * To deal with this complexity, the recursive bridge chain bus format sel= ection + * logic starts with the last bridge in the chain, usually the connector, = and + * then recursively walks the chain of bridges backwards to the first brid= ge, + * trying to find a path. + * + * For a display driver to work in such a scenario, it should read the fir= st + * bridge's bridge state to figure out which bus format the chain resolved= to. + * If the first bridge's input format resolved to %MEDIA_BUS_FMT_FIXED, th= en its + * output format should be used. + * + * Special handling is done for HDMI as it relates to format selection. In= stead + * of directly using the "color format" DRM property for bridge chains tha= t end + * in HDMI bridges, the bridge chain format selection logic will trust the= logic + * that set the HDMI output format. For the common HDMI state helper + * functionality, this means that %DRM_CONNECTOR_COLOR_FORMAT_AUTO will al= low + * fallbacks to YCBCr 4:2:0 if the bandwidth requirements would otherwise = be too + * high but the mode and connector allow it. + * + * For bridge chains that do not end in an HDMI bridge, + * %DRM_CONNECTOR_COLOR_FORMAT_AUTO will be satisfied with the first output + * format on the last bridge for which it can find a path back to the first + * bridge. + */ + /* Protect bridge_list and bridge_lingering_list */ static DEFINE_MUTEX(bridge_lock); static LIST_HEAD(bridge_list); --=20 2.53.0