dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "José Expósito" <jose.exposito89@gmail.com>
To: javierm@redhat.com
Cc: tzimmermann@suse.de, airlied@linux.ie,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"José Expósito" <jose.exposito89@gmail.com>
Subject: [RFC PATCH 0/1] KUnit tests for drm_format_helper
Date: Mon, 30 May 2022 12:20:16 +0200	[thread overview]
Message-ID: <20220530102017.471865-1-jose.exposito89@gmail.com> (raw)

Hello everyone,

Recently Javier added a new task in the ToDo list [1] to create KUnit
tests for the functions present in "drm_format_helper".

This patch, marked as RFC to start the conversation, includes tests for
"drm_fb_xrgb8888_to_rgb332".

Since the conversion functions present in "drm_format_helper" convert
from XRGB8888 to another format, my plan is to create a set of XRGB8888
data to test all the available conversions.

To illustrate it with an example, the code present in this patch:

	{
		.name = "Single pixel source",
		.pitch = 1 * 4,
		.dst_pitch = 0,
		.clip = CLIP(0, 0, 1, 1),
		.xrgb8888 = { 0x01FF0000 },
		.expected = { 0xE0 },
	}

In a follow up patch, should look like:

	{
		.name = "Single pixel source",
		.pitch = 1 * 4,
		.clip = CLIP(0, 0, 1, 1),
		.xrgb8888 = { 0x01FF0000 },
		.expected = {
			{
				.dst_format = DRM_FORMAT_RGB332,
				.dst_pitch = 0,
				.conv_func = drm_fb_xrgb8888_to_rgb332,
				.result = { 0xE0 },
			},
			{ ... },
		},
	}

What is tested?

 - Different values for the X in XRGB8888 to make sure it is ignored
 - Different clip values: Single pixel and full and partial buffer
 - Well know colors: White, black, red, green, blue, magenta, yellow
   and cyan
 - Other colors: Randomly picked
 - Destination pitch

What is NOT tested?

 - NULL destination buffer: Because there is not validation in place
 - Out of bounds destination buffer: The size of the buffer is not
   checked. The conversion function could cause out of bound errors
 - Out of bounds source buffer: Similary to the destination buffer, the
   source buffer is read without checking its size
 - Invalid clip values: Because there is no clip validation.
   Example: clip out of or bigger than the source buffer
 - Invalid destination pitch: A dst_pitch < (clip->width * dst_pixsize)
   could cause issues.
 - "Big" source buffers. I don't know if this kind of tests could be of
   interest

How to run the tests?

 My .kunitconfig:

 	CONFIG_KUNIT=y
 	CONFIG_DRM=y
 	CONFIG_DRM_FORMAR_HELPER_TEST=y

 $ ./tools/testing/kunit/kunit.py run --arch=x86_64

Feedback?

 It'd be great to know your ideas about what else we could test, if you
 think that we should make the functions safer by checking the buffers
 and clip sizes or anything else.

Thanks a lot,
José Expósito

[1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=596c35b1440e

José Expósito (1):
  drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()

 drivers/gpu/drm/Kconfig                  |  12 ++
 drivers/gpu/drm/Makefile                 |   3 +
 drivers/gpu/drm/drm_format_helper_test.c | 166 +++++++++++++++++++++++
 3 files changed, 181 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_format_helper_test.c

-- 
2.25.1


             reply	other threads:[~2022-05-30 10:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-30 10:20 José Expósito [this message]
2022-05-30 10:20 ` [RFC PATCH 1/1] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332() José Expósito
2022-05-30 13:11   ` Maxime Ripard
2022-05-30 16:29     ` José Expósito
2022-05-30 22:57       ` Daniel Latypov
2022-05-31 18:44         ` José Expósito
2022-05-31 20:42           ` Daniel Latypov
2022-06-02 17:12       ` David Gow
2022-06-02 17:29         ` Javier Martinez Canillas
2022-06-02 17:45           ` Daniel Latypov
2022-06-02 16:26   ` Javier Martinez Canillas
2022-06-02 16:53     ` Daniel Latypov
2022-06-02 17:07     ` David Gow
2022-06-02 17:21       ` Javier Martinez Canillas
2022-06-06  9:43         ` José Expósito

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=20220530102017.471865-1-jose.exposito89@gmail.com \
    --to=jose.exposito89@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).