From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
kernel@collabora.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/7] drm/tests: hdmi: Add macros to simplify EDID setup
Date: Wed, 12 Mar 2025 00:44:26 +0200 [thread overview]
Message-ID: <a91cabd5-f0af-42a3-95b5-de68e30f7f23@collabora.com> (raw)
In-Reply-To: <20250311-spiritual-hornet-of-prestige-ef4132@houat>
On 3/11/25 6:12 PM, Maxime Ripard wrote:
> On Tue, Mar 11, 2025 at 12:57:37PM +0200, Cristian Ciocaltea wrote:
>> Introduce a few macros to facilitate setting custom (i.e. non-default)
>> EDID data during connector initialization.
>>
>> This helps reducing boilerplate code while also drops some redundant
>> calls to set_connector_edid().
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 245 ++++++++-------------
>> 1 file changed, 93 insertions(+), 152 deletions(-)
>>
>> 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 e97efd3af9ed18e6cf8ee66b4923dfc805b34e19..a3f7f3ce31c73335c2c2643bdc5395b6ceb6f071 100644
>> --- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
>> +++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
>> @@ -183,10 +183,12 @@ static const struct drm_connector_funcs dummy_connector_funcs = {
>>
>> static
>> struct drm_atomic_helper_connector_hdmi_priv *
>> -drm_kunit_helper_connector_hdmi_init_funcs(struct kunit *test,
>> - unsigned int formats,
>> - unsigned int max_bpc,
>> - const struct drm_connector_hdmi_funcs *hdmi_funcs)
>> +connector_hdmi_init_funcs_set_edid(struct kunit *test,
>> + unsigned int formats,
>> + unsigned int max_bpc,
>> + const struct drm_connector_hdmi_funcs *hdmi_funcs,
>> + const char *edid_data,
>> + size_t edid_len)
>> {
>> struct drm_atomic_helper_connector_hdmi_priv *priv;
>> struct drm_connector *conn;
>> @@ -240,30 +242,27 @@ drm_kunit_helper_connector_hdmi_init_funcs(struct kunit *test,
>>
>> drm_mode_config_reset(drm);
>>
>> + if (edid_data && edid_len) {
>> + ret = set_connector_edid(test, &priv->connector, edid_data, edid_len);
>> + KUNIT_ASSERT_GT(test, ret, 0);
>> + }
>> +
>> return priv;
>> }
>>
>> -static
>> -struct drm_atomic_helper_connector_hdmi_priv *
>> -drm_kunit_helper_connector_hdmi_init(struct kunit *test,
>> - unsigned int formats,
>> - unsigned int max_bpc)
>> -{
>> - struct drm_atomic_helper_connector_hdmi_priv *priv;
>> - int ret;
>> +#define drm_kunit_helper_connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, funcs, edid) \
>> + connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, funcs, edid, ARRAY_SIZE(edid))
>>
>> - priv = drm_kunit_helper_connector_hdmi_init_funcs(test,
>> - formats, max_bpc,
>> - &dummy_connector_hdmi_funcs);
>> - KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
>> +#define drm_kunit_helper_connector_hdmi_init_funcs(test, formats, max_bpc, funcs) \
>> + connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, funcs, NULL, 0)
>>
>> - ret = set_connector_edid(test, &priv->connector,
>> - test_edid_hdmi_1080p_rgb_max_200mhz,
>> - ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
>> - KUNIT_ASSERT_GT(test, ret, 0);
>> +#define drm_kunit_helper_connector_hdmi_init_set_edid(test, formats, max_bpc, edid) \
>> + drm_kunit_helper_connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, \
>> + &dummy_connector_hdmi_funcs, edid)
>>
>> - return priv;
>> -}
>> +#define drm_kunit_helper_connector_hdmi_init(test, formats, max_bpc) \
>> + drm_kunit_helper_connector_hdmi_init_set_edid(test, formats, max_bpc, \
>> + test_edid_hdmi_1080p_rgb_max_200mhz)
>
> I'd really prefer to have functions to macros here. They are easier to
> read, extend, and don't have any particular drawbacks.
Yeah, the main reason I opted for macros was to allow dropping
ARRAY_SIZE(edid) from the caller side, hence making the API as simple as
possible.
> I also don't think we need that many, looking at the tests:
>
> - We need drm_kunit_helper_connector_hdmi_init() to setup a connector
> with test_edid_hdmi_1080p_rgb_max_200mhz and
> dummy_connector_hdmi_funcs()
Correct.
> - We need to create a
> drm_kunit_helper_connector_hdmi_init_with_edid_funcs() to pass both
> the funcs and edid pointers
That's drm_kunit_helper_connector_hdmi_init_funcs_set_edid(), but I can
rename it if you prefer - I've just tried to keep the name length under
control, as there are already some indentation challenges when calling
the helpers.
Currently it's only used to implement
drm_kunit_helper_connector_hdmi_init_set_edid() by passing
&dummy_connector_hdmi_funcs, but there are a few test cases that can
benefit of it and help extend the cleanup - will do for v3.
drm_kunit_helper_connector_hdmi_init_set_edid() should also stay as it's
already being used to drop boilerplate code from a lot of places.
> And that's it, right?
There's also drm_kunit_helper_connector_hdmi_init_funcs() which has been
used for a few times, but it can be further optimized out via
drm_kunit_helper_connector_hdmi_init_funcs_set_edid(), so I'll drop it.
That means we could end up with just the following:
- drm_kunit_helper_connector_hdmi_init()
- drm_kunit_helper_connector_hdmi_init_set_edid()
- drm_kunit_helper_connector_hdmi_init_funcs_set_edid()
>> /*
>> * Test that if we change the RGB quantization property to a different
>> @@ -771,19 +770,15 @@ static void drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
>> struct drm_crtc *crtc;
>> int ret;
>>
>> - priv = drm_kunit_helper_connector_hdmi_init(test,
>> - BIT(HDMI_COLORSPACE_RGB),
>> - 10);
>> + priv = drm_kunit_helper_connector_hdmi_init_set_edid(test,
>> + BIT(HDMI_COLORSPACE_RGB),
>> + 10,
>> + test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz);
>
> I think that convertion should be part of another patch.
Ack, will move all conversions to a dedicated patch.
Thanks,
Cristian
next prev parent reply other threads:[~2025-03-11 22:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 10:57 [PATCH v2 0/7] drm/connector: hdmi: Allow using the YUV420 output format Cristian Ciocaltea
2025-03-11 10:57 ` [PATCH v2 1/7] drm/connector: hdmi: Evaluate limited range after computing format Cristian Ciocaltea
2025-03-11 19:36 ` Dmitry Baryshkov
2025-03-11 10:57 ` [PATCH v2 2/7] drm/connector: hdmi: Add support for YUV420 format verification Cristian Ciocaltea
2025-03-11 15:30 ` Maxime Ripard
2025-03-11 17:06 ` Cristian Ciocaltea
2025-03-11 10:57 ` [PATCH v2 3/7] drm/connector: hdmi: Improve debug message for supported format Cristian Ciocaltea
2025-03-11 15:31 ` Maxime Ripard
2025-03-11 10:57 ` [PATCH v2 4/7] drm/connector: hdmi: Use YUV420 output format as an RGB fallback Cristian Ciocaltea
2025-03-11 15:55 ` Maxime Ripard
2025-03-11 18:59 ` Cristian Ciocaltea
2025-03-14 13:57 ` Maxime Ripard
2025-03-11 19:46 ` Dmitry Baryshkov
2025-03-14 13:47 ` Maxime Ripard
2025-03-14 15:00 ` Dmitry Baryshkov
2025-03-11 10:57 ` [PATCH v2 5/7] drm/tests: hdmi: Add macros to simplify EDID setup Cristian Ciocaltea
2025-03-11 16:12 ` Maxime Ripard
2025-03-11 22:44 ` Cristian Ciocaltea [this message]
2025-03-19 15:32 ` Maxime Ripard
2025-03-19 21:33 ` Cristian Ciocaltea
2025-03-11 10:57 ` [PATCH v2 6/7] drm/tests: hdmi: Add limited range tests for YUV420 mode Cristian Ciocaltea
2025-03-11 16:17 ` Maxime Ripard
2025-03-11 22:54 ` Cristian Ciocaltea
2025-03-14 13:52 ` Maxime Ripard
2025-03-11 10:57 ` [PATCH v2 7/7] drm/tests: hdmi: Add max TMDS rate fallback " Cristian Ciocaltea
2025-03-12 12:02 ` kernel test robot
2025-03-12 18:14 ` kernel test robot
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=a91cabd5-f0af-42a3-95b5-de68e30f7f23@collabora.com \
--to=cristian.ciocaltea@collabora.com \
--cc=airlied@gmail.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--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
all inboxes | Powered by JetHome®