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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 09D96C44500 for ; Thu, 22 Jan 2026 08:36:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6C3AB10E908; Thu, 22 Jan 2026 08:36:33 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="NBgc6ozo"; dkim-atps=neutral Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) by gabe.freedesktop.org (Postfix) with ESMTPS id D21CB10E7C4; Wed, 21 Jan 2026 13:48:51 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1769003323; cv=none; d=zohomail.com; s=zohoarc; b=Qu5HcFI7eZQyiLafHMrl40Bks9ctbn3Ag/wWiDv4upwjKR2blsOUlAAB+pwG4gnk1oMbo6IckVIieq4tPo2co0flrE6JQDG75MFPG2S8idT5LkDpkZRny0maeIl33YuuAvdD8Wa1Hcqu7VlU76nJ4rFSTTi3fw7mqUR/byQ4XEQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769003323; 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=SfjcxeAT2W+o+UxrPmZJDMJEXHj1m3+fRUI5YUGISxM=; b=KhH6sT8FeyTWPQ93V/yBX/pRI+veKpouS2PgUmP8OeIaNEDLH4tu9tNIuh5NGYd4VowpJqrG5L8LoetvhaqhC13gGxEw/pFfh6b9XtAhyf5J54GPblqhxvTmTAmu6pd7bjSFhcGqnT32X0rrlhg0+5GWhbZerJ4jMWH9TxxPO4k= 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=1769003323; 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=SfjcxeAT2W+o+UxrPmZJDMJEXHj1m3+fRUI5YUGISxM=; b=NBgc6ozo0i/RTDRfPAIxxMCsaynl11+ueBDC0eT6tGUo92Lv21csWpMu8MW+PpwE HG8fPD/kd3L6KIb+sPpMgHUXL3U4hMtwD8b3oN8/K0qN3AdNNpVXmLt5KKxEhNA3ehu /RZi4IFp0AyKU9yvGug+X0zTy4RLOdZFb0bOtYKI= Received: by mx.zohomail.com with SMTPS id 1769003320832411.20417740809444; Wed, 21 Jan 2026 05:48:40 -0800 (PST) From: Nicolas Frattaroli Date: Wed, 21 Jan 2026 14:45:47 +0100 Subject: [PATCH v6 21/21] drm/bridge: Document bridge chain format selection MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260121-color-format-v6-21-7b81a771cd0b@collabora.com> References: <20260121-color-format-v6-0-7b81a771cd0b@collabora.com> In-Reply-To: <20260121-color-format-v6-0-7b81a771cd0b@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 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 X-Mailman-Approved-At: Thu, 22 Jan 2026 08:36:26 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" 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. Signed-off-by: Nicolas Frattaroli --- Documentation/gpu/drm-kms-helpers.rst | 6 ++++++ drivers/gpu/drm/drm_bridge.c | 39 +++++++++++++++++++++++++++++++++++ 2 files changed, 45 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 +Bridge Chain Format Selection +----------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_bridge.c + :doc: bridge chain format selection + Bridge Connector Helper ----------------------- diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index b0dfa03dbb81..a155b8aa4a3d 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -198,6 +198,45 @@ * driver. */ +/** + * 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 convert + * from RGB to YCbCr 4:4:4, and pass through YCbCr 4:2:0 as-is, but not convert + * from RGB to YCbCr 4:2:0. This means not all input formats map to all output + * formats. + * + * Further adding to this, a desired output color format, as specified with the + * "color format" DRM property, might not correspond to what the display driver + * should set at its output 1:1. The bridge chain it feeds into may only be able + * to reach the desired output format, if a conversion from a different starting + * format is performed. + * + * To deal with this complexity, the recursive bridge chain bus format selection + * logic starts with the last bridge in the chain, usually the connector, and + * then recursively walks the chain of bridges backwards to the first bridge, + * trying to find a path. + * + * For a display driver to work in such a scenario, it should read the first + * 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, then its + * output format should be used. + * + * Special handling is done for HDMI as it relates to format selection. Instead + * of directly using the "color format" DRM property for bridge chains that 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_COLOR_FORMAT_AUTO will allow 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_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); -- 2.52.0 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 EC320C4452E for ; Wed, 21 Jan 2026 13:49:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:In-Reply-To:References:Message-Id :MIME-Version:Subject:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BVkiz1mjRmrBCVEkkOm9hVWOsohgJJ66YROpcs4HgDg=; b=BkxAEYZHZ+c7vw Qed30nUQwfZ/VvnTNGpmhsMry/pec+xRt4I42wfGQr4c8cKWQ78B/o6ZtCYc+GUmd6lb/UVYNYcDi s+MDST0MXofQsEtVD1sVwiqYdGLrBQU+gPEqdpVZXY8jx5BAj4M6kjGwlvAmj4o2pLIXHmJGh1HQX Fp675LBygiKoUdLGNlB74h8pu+gt6G7eGPvxTWPCSn2OumOTECj/W0JU7OkpU4pw+V3JBpCp2Tl8A 99fwNHkmCLmARoiPN+v1x4oZ/vJd773ZC/oX3f3g+ELz4/O1OWFSgRIJihgiZe2j5p+V9fv0PhWf6 8TYWJ+GOGuw3mtddg5KA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1viYaM-00000005Xjh-3Bgt; Wed, 21 Jan 2026 13:49:26 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1viYaC-00000005XZz-2uFS; Wed, 21 Jan 2026 13:49:25 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1769003323; cv=none; d=zohomail.com; s=zohoarc; b=Qu5HcFI7eZQyiLafHMrl40Bks9ctbn3Ag/wWiDv4upwjKR2blsOUlAAB+pwG4gnk1oMbo6IckVIieq4tPo2co0flrE6JQDG75MFPG2S8idT5LkDpkZRny0maeIl33YuuAvdD8Wa1Hcqu7VlU76nJ4rFSTTi3fw7mqUR/byQ4XEQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769003323; 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=SfjcxeAT2W+o+UxrPmZJDMJEXHj1m3+fRUI5YUGISxM=; b=KhH6sT8FeyTWPQ93V/yBX/pRI+veKpouS2PgUmP8OeIaNEDLH4tu9tNIuh5NGYd4VowpJqrG5L8LoetvhaqhC13gGxEw/pFfh6b9XtAhyf5J54GPblqhxvTmTAmu6pd7bjSFhcGqnT32X0rrlhg0+5GWhbZerJ4jMWH9TxxPO4k= 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=1769003323; 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=SfjcxeAT2W+o+UxrPmZJDMJEXHj1m3+fRUI5YUGISxM=; b=NBgc6ozo0i/RTDRfPAIxxMCsaynl11+ueBDC0eT6tGUo92Lv21csWpMu8MW+PpwE HG8fPD/kd3L6KIb+sPpMgHUXL3U4hMtwD8b3oN8/K0qN3AdNNpVXmLt5KKxEhNA3ehu /RZi4IFp0AyKU9yvGug+X0zTy4RLOdZFb0bOtYKI= Received: by mx.zohomail.com with SMTPS id 1769003320832411.20417740809444; Wed, 21 Jan 2026 05:48:40 -0800 (PST) From: Nicolas Frattaroli Date: Wed, 21 Jan 2026 14:45:47 +0100 Subject: [PATCH v6 21/21] drm/bridge: Document bridge chain format selection MIME-Version: 1.0 Message-Id: <20260121-color-format-v6-21-7b81a771cd0b@collabora.com> References: <20260121-color-format-v6-0-7b81a771cd0b@collabora.com> In-Reply-To: <20260121-color-format-v6-0-7b81a771cd0b@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 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260121_054916_813107_DFCDBC6F X-CRM114-Status: GOOD ( 17.53 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org 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. Signed-off-by: Nicolas Frattaroli --- Documentation/gpu/drm-kms-helpers.rst | 6 ++++++ drivers/gpu/drm/drm_bridge.c | 39 +++++++++++++++++++++++++++++++++++ 2 files changed, 45 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 +Bridge Chain Format Selection +----------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_bridge.c + :doc: bridge chain format selection + Bridge Connector Helper ----------------------- diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index b0dfa03dbb81..a155b8aa4a3d 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -198,6 +198,45 @@ * driver. */ +/** + * 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 convert + * from RGB to YCbCr 4:4:4, and pass through YCbCr 4:2:0 as-is, but not convert + * from RGB to YCbCr 4:2:0. This means not all input formats map to all output + * formats. + * + * Further adding to this, a desired output color format, as specified with the + * "color format" DRM property, might not correspond to what the display driver + * should set at its output 1:1. The bridge chain it feeds into may only be able + * to reach the desired output format, if a conversion from a different starting + * format is performed. + * + * To deal with this complexity, the recursive bridge chain bus format selection + * logic starts with the last bridge in the chain, usually the connector, and + * then recursively walks the chain of bridges backwards to the first bridge, + * trying to find a path. + * + * For a display driver to work in such a scenario, it should read the first + * 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, then its + * output format should be used. + * + * Special handling is done for HDMI as it relates to format selection. Instead + * of directly using the "color format" DRM property for bridge chains that 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_COLOR_FORMAT_AUTO will allow 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_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); -- 2.52.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip