Hi,

On Wed, Jan 21, 2026 at 03:45:28PM +0100, Nicolas Frattaroli wrote:
> With the "color format" property, the bridge chain format selection has
> gained increased complexity. Instead of simply finding any sequence of
> bus formats that works, the bridge chain format selection needs to pick
> a sequence that results in the requested color format.
> 
> Add KUnit tests for this new logic. These take the form of some pleasant
> preprocessor macros to make it less cumbersome to define test bridges
> with a set of possible input and output formats.
> 
> The input and output formats are defined for bridges in the form of
> tuples, where the first member defines the input format, and the second
> member defines the output format that can be produced from this input
> format. This means the tests can construct scenarios in which not all
> inputs can be converted to all outputs.
> 
> Some tests are added to test interesting scenarios to exercise the bus
> format selection in the presence of a specific color format request.
> 
> Furthermore, tests are added to verify that bridge chains that end in an
> HDMI connector will always prefer RGB when the color format is
> DRM_COLOR_FORMAT_AUTO, as is the behaviour in the HDMI state helpers.
> 
> Signed-off-by: Nicolas Frattaroli <[email protected]>
> ---
>  drivers/gpu/drm/tests/drm_bridge_test.c | 812 
> ++++++++++++++++++++++++++++++++
>  1 file changed, 812 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tests/drm_bridge_test.c 
> b/drivers/gpu/drm/tests/drm_bridge_test.c
> index 887020141c7f..ac86f3dfe518 100644
> --- a/drivers/gpu/drm/tests/drm_bridge_test.c
> +++ b/drivers/gpu/drm/tests/drm_bridge_test.c
> @@ -2,15 +2,23 @@
>  /*
>   * Kunit test for drm_bridge functions
>   */
> +#include <linux/cleanup.h>
> +#include <linux/media-bus-format.h>
> +
>  #include <drm/drm_atomic_state_helper.h>
> +#include <drm/drm_atomic_uapi.h>
>  #include <drm/drm_bridge.h>
>  #include <drm/drm_bridge_connector.h>
>  #include <drm/drm_bridge_helper.h>
> +#include <drm/drm_edid.h>
>  #include <drm/drm_kunit_helpers.h>
> +#include <drm/drm_managed.h>
>  
>  #include <kunit/device.h>
>  #include <kunit/test.h>
>  
> +#include "drm_kunit_edid.h"
> +
>  /*
>   * Mimick the typical "private" struct defined by a bridge driver, which
>   * embeds a bridge plus other fields.
> @@ -37,6 +45,27 @@ struct drm_bridge_init_priv {
>       bool destroyed;
>  };
>  
> +struct drm_bridge_chain_priv {
> +     struct drm_device drm;
> +     struct drm_encoder encoder;
> +     struct drm_plane *plane;
> +     struct drm_crtc *crtc;
> +     struct drm_connector *connector;
> +     unsigned int num_bridges;
> +
> +     /**
> +      * @test_bridges: array of pointers to &struct drm_bridge_priv entries
> +      *                of which the first @num_bridges entries are valid.
> +      */
> +     struct drm_bridge_priv **test_bridges;
> +     /**
> +      * @destroyed: bool array of size @num_bridges serving the same function
> +      *             as &struct drm_bridge_init_priv::destroyed does for a
> +      *             single bridge test.
> +      */
> +     bool *destroyed;

AFAIK, the destroyed field was added to test the refcounting work. We
don't really need it here, so there's no point in adding it I.

> +};
> +
>  static struct drm_bridge_priv *bridge_to_priv(struct drm_bridge *bridge)
>  {
>       return container_of(bridge, struct drm_bridge_priv, bridge);
> @@ -50,6 +79,21 @@ static void drm_test_bridge_priv_destroy(struct drm_bridge 
> *bridge)
>       priv->destroyed = true;
>  }
>  
> +static void drm_test_bridge_chain_priv_destroy(struct drm_bridge *bridge)
> +{
> +     struct drm_bridge_priv *bridge_priv = bridge_to_priv(bridge);
> +     struct drm_bridge_chain_priv *priv = (struct drm_bridge_chain_priv 
> *)bridge_priv->data;
> +     unsigned int i;
> +
> +     for (i = 0; i < priv->num_bridges; i++) {
> +             if (priv->test_bridges[i] != bridge_priv)
> +                     continue;
> +
> +             priv->destroyed[i] = true;
> +             break;
> +     }
> +}
> +

And similarly, we probably can drop that hook.

With this fixed,
Reviewed-by: Maxime Ripard <[email protected]>

Maxime

Attachment: signature.asc
Description: PGP signature

Reply via email to