On 2/16/26 5:01 AM, Nicolas Frattaroli wrote:
> 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 <[email protected]>
> Signed-off-by: Nicolas Frattaroli <[email protected]>
> ---
> 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 36a5158f0554..93ef52c37e2c 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
Preferably put "1:1" after "might not correspond".
> + * 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_ENUM_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_ENUM_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);
>
Thanks.
--
~Randy
