From: Maxime Ripard <mripard@kernel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: "Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Dmitry Baryshkov" <lumag@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Rob Herring" <robh@kernel.org>,
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
Subject: Re: [PATCH v5 17/17] drm/tests: hdmi: Add tests for the color_format property
Date: Fri, 12 Dec 2025 10:19:13 +0100 [thread overview]
Message-ID: <20251212-discreet-wisteria-perch-edccad@penduick> (raw)
In-Reply-To: <20251128-color-format-v5-17-63e82f1db1e1@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 6008 bytes --]
On Fri, Nov 28, 2025 at 10:05:53PM +0100, Nicolas Frattaroli wrote:
> Add some KUnit tests to check the color_format property is working as
> expected with the HDMI state helper.
>
> The added tests check that AUTO results in RGB, and the YCBCR modes
> result in the corresponding YUV modes. An additional test ensures that
> only DRM_COLOR_FORMAT_AUTO falls back to YUV420 with a YUV420-only mode,
> and RGB errors out instead, while explicitly asking for YUV420 still
> works.
>
> This requires exporting hdmi_compute_config, so that it is accessible
> from the tests.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 3 +-
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 109 +++++++++++++++++++++
> include/drm/display/drm_hdmi_state_helper.h | 4 +
> 3 files changed, 115 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> index 1800e00b30c5..e86fb837ceaf 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> @@ -641,7 +641,7 @@ hdmi_compute_format_bpc(const struct drm_connector *connector,
> return -EINVAL;
> }
>
> -static int
> +int
> hdmi_compute_config(const struct drm_connector *connector,
> struct drm_connector_state *conn_state,
> const struct drm_display_mode *mode)
> @@ -680,6 +680,7 @@ hdmi_compute_config(const struct drm_connector *connector,
>
> return ret;
> }
> +EXPORT_SYMBOL(hdmi_compute_config);
I don't think we need to export hdmi_compute_config directly, and if we
do, it shouldn't be named that way.
The rest of the tests in the suite manage to test everything fine
without exporting it. Is there any reason you can't do it for these
tests?
> static int hdmi_generate_avi_infoframe(const struct drm_connector *connector,
> struct drm_connector_state *conn_state)
> diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> index 8bd412735000..e7050cd9cb12 100644
> --- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> @@ -55,6 +55,23 @@ static struct drm_display_mode *find_preferred_mode(struct drm_connector *connec
> return preferred;
> }
>
> +static struct drm_display_mode *find_420_only_mode(struct drm_connector *connector)
> +{
> + struct drm_device *drm = connector->dev;
> + struct drm_display_mode *mode;
> +
> + mutex_lock(&drm->mode_config.mutex);
> + list_for_each_entry(mode, &connector->modes, head) {
> + if (drm_mode_is_420_only(&connector->display_info, mode)) {
> + mutex_unlock(&drm->mode_config.mutex);
> + return mode;
> + }
> + }
> + mutex_unlock(&drm->mode_config.mutex);
> +
> + return NULL;
> +}
> +
> static int set_connector_edid(struct kunit *test, struct drm_connector *connector,
> const void *edid, size_t edid_len)
> {
> @@ -1999,6 +2016,95 @@ static void drm_test_check_disable_connector(struct kunit *test)
> drm_modeset_acquire_fini(&ctx);
> }
>
> +struct color_format_test_param {
> + enum drm_color_format fmt;
> + enum hdmi_colorspace expected;
> + const char *desc;
> +};
> +
> +/* Test that AUTO results in RGB, and explicit choices result in those */
We need a bit more details. Which EDID are you using, with which monitor
capabilities?
IIRC, we already have tests to make sure that the fallback happens and
only when it's supposed to. We just need to make sure we have asserts on
the property being auto for those.
This means we only need to test the !auto values, but we need to test it
both ways: that when the property is set and the display supports it,
the format chosen is indeed the one we asked for, but also that when the
property is set but the display doesn't support it, we get an error.
> +static void drm_test_check_hdmi_color_format(struct kunit *test)
> +{
> + const struct color_format_test_param *param = test->param_value;
> + struct drm_atomic_helper_connector_hdmi_priv *priv;
> + struct drm_connector_state *conn_state;
> + struct drm_display_info *info;
> + struct drm_display_mode *preferred;
> + int ret;
> +
> + priv = drm_kunit_helper_connector_hdmi_init_with_edid_funcs(test,
> + BIT(HDMI_COLORSPACE_RGB) |
> + BIT(HDMI_COLORSPACE_YUV422) |
> + BIT(HDMI_COLORSPACE_YUV420) |
> + BIT(HDMI_COLORSPACE_YUV444),
> + 12,
> + &dummy_connector_hdmi_funcs,
> + test_edid_hdmi_4k_rgb_yuv420_dc_max_340mhz);
> + KUNIT_ASSERT_NOT_NULL(test, priv);
> +
> + conn_state = priv->connector.state;
> + info = &priv->connector.display_info;
> + conn_state->color_format = param->fmt;
> + KUNIT_ASSERT_TRUE(test, priv->connector.ycbcr_420_allowed);
> +
> + preferred = find_preferred_mode(&priv->connector);
> + KUNIT_ASSERT_TRUE(test, drm_mode_is_420(info, preferred));
> +
> + ret = hdmi_compute_config(&priv->connector, conn_state, preferred);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> + KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format, param->expected);
> +}
> +
> +static const struct color_format_test_param hdmi_color_format_params[] = {
> + { DRM_COLOR_FORMAT_AUTO, HDMI_COLORSPACE_RGB, "AUTO -> RGB" },
> + { DRM_COLOR_FORMAT_YCBCR422, HDMI_COLORSPACE_YUV422, "YCBCR422 -> YUV422" },
> + { DRM_COLOR_FORMAT_YCBCR420, HDMI_COLORSPACE_YUV420, "YCBCR420 -> YUV420" },
> + { DRM_COLOR_FORMAT_YCBCR444, HDMI_COLORSPACE_YUV444, "YCBCR444 -> YUV444" },
> + { DRM_COLOR_FORMAT_RGB444, HDMI_COLORSPACE_RGB, "RGB -> RGB" },
> +};
> +
> +KUNIT_ARRAY_PARAM_DESC(check_hdmi_color_format,
> + hdmi_color_format_params, desc);
> +
> +
> +/* Test that AUTO falls back to YUV420, and that RGB does not, but YUV420 works */
Same thing, the description needs to be improved here.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
next prev parent reply other threads:[~2025-12-12 9:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 21:05 [PATCH v5 00/17] Add new general DRM property "color format" Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 02/17] drm: Add new general DRM property "color format" Nicolas Frattaroli
2025-12-09 14:11 ` Maxime Ripard
2025-11-28 21:05 ` [PATCH v5 03/17] drm: Add enum conversion from DRM_COLOR_FORMAT to HDMI_COLORSPACE Nicolas Frattaroli
2025-12-09 14:12 ` Maxime Ripard
2025-11-28 21:05 ` [PATCH v5 04/17] drm/bridge: Act on the DRM color format property Nicolas Frattaroli
2025-12-09 14:27 ` Maxime Ripard
2025-12-11 19:34 ` Nicolas Frattaroli
2025-12-12 9:50 ` Maxime Ripard
2025-12-12 14:45 ` Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 05/17] drm/display: hdmi-state-helper: Act on color format DRM property Nicolas Frattaroli
2025-12-09 14:16 ` Maxime Ripard
2025-12-11 19:42 ` Nicolas Frattaroli
2025-12-12 9:20 ` Maxime Ripard
2025-11-28 21:05 ` [PATCH v5 06/17] drm/display: hdmi-state-helper: Try subsampling in mode_valid Nicolas Frattaroli
2025-12-09 14:18 ` Maxime Ripard
2025-12-11 19:59 ` Nicolas Frattaroli
2025-12-12 9:29 ` Maxime Ripard
2025-11-28 21:05 ` [PATCH v5 07/17] drm/i915: Implement the "color format" DRM property Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 08/17] drm/amdgpu: Implement " Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 09/17] drm/rockchip: Add YUV422 output mode constants for VOP2 Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 10/17] drm/rockchip: vop2: Fix YUV444 output Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 11/17] drm/rockchip: vop2: Add RK3576 to the RG swap special case Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 12/17] drm/rockchip: vop2: Recognise 10/12-bit YUV422 as YUV formats Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 13/17] drm/rockchip: vop2: Set correct output format for RK3576 YUV422 Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 14/17] drm/rockchip: dw_hdmi_qp: Implement "color format" DRM property Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 15/17] drm/rockchip: dw_hdmi_qp: Set supported_formats platdata Nicolas Frattaroli
2025-11-28 21:05 ` [PATCH v5 16/17] drm/connector: Register color format property on HDMI connectors Nicolas Frattaroli
2025-12-09 14:22 ` Maxime Ripard
2025-11-28 21:05 ` [PATCH v5 17/17] drm/tests: hdmi: Add tests for the color_format property Nicolas Frattaroli
2025-12-12 9:19 ` Maxime Ripard [this message]
2025-12-12 20:28 ` Nicolas Frattaroli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251212-discreet-wisteria-perch-edccad@penduick \
--to=mripard@kernel.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=neil.armstrong@linaro.org \
--cc=nicolas.frattaroli@collabora.com \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=s.hauer@pengutronix.de \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox