From: Louis Chauvet <louis.chauvet@bootlin.com>
To: "Maíra Canal" <mcanal@igalia.com>,
"Melissa Wen" <melissa.srw@gmail.com>,
"Maíra Canal" <mairacanal@riseup.net>,
"Haneen Mohammed" <hamohammed.sa@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Rodrigo Siqueira" <siqueira@igalia.com>,
"Simona Vetter" <simona.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, arthurgrillo@riseup.net,
linux-kernel@vger.kernel.org, jeremie.dautheribes@bootlin.com,
miquel.raynal@bootlin.com, thomas.petazzoni@bootlin.com,
seanpaul@google.com, nicolejadeyee@google.com
Subject: Re: [PATCH v4 6/8] drm/vkms: Change YUV helpers to support u16 inputs for conversion
Date: Fri, 13 Jun 2025 20:44:18 +0200 [thread overview]
Message-ID: <fb153302-4816-4a62-b59f-dc9e1963c1bf@bootlin.com> (raw)
In-Reply-To: <0d522681-8a48-4f66-9b4c-32966068c6b8@igalia.com>
Le 11/06/2025 à 22:24, Maíra Canal a écrit :
> Hi Louis,
>
> On 5/30/25 11:06, Louis Chauvet wrote:
>> Some YUV format uses 16 bit values, so change the helper function for
>> conversion to support those new formats.
>>
>> Add support for the YUV format P010
>
> Hum, I don't think this patch added support for P010.
Obviously not... It only adds support for 16 bits yuv conversions.
>>
>> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
>> ---
>> drivers/gpu/drm/vkms/tests/vkms_format_test.c | 103 +++++++++++++-------------
>> drivers/gpu/drm/vkms/vkms_formats.c | 26 ++++---
>> drivers/gpu/drm/vkms/vkms_formats.h | 4 +-
>> 3 files changed, 68 insertions(+), 65 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/tests/vkms_format_test.c b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
>> index 2e1daef94831..272e18a82f9c 100644
>> --- a/drivers/gpu/drm/vkms/tests/vkms_format_test.c
>> +++ b/drivers/gpu/drm/vkms/tests/vkms_format_test.c
>> @@ -23,7 +23,7 @@ MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING");
>> * machine endianness
>> */
>> struct pixel_yuv_u8 {
>> - u8 y, u, v;
>> + u16 y, u, v;
>> };
>>
>> /*
>> @@ -64,7 +64,7 @@ static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
>> * in_bits = 16,
>> * in_legal = False,
>> * in_int = True,
>> - * out_bits = 8,
>> + * out_bits = 16,
>> * out_legal = False,
>> * out_int = True)
>> *
>> @@ -76,13 +76,13 @@ static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
>> .range = DRM_COLOR_YCBCR_FULL_RANGE,
>> .n_colors = 6,
>> .colors = {
>> - { "white", { 0xff, 0x80, 0x80 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
>> - { "gray", { 0x80, 0x80, 0x80 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
>> - { "black", { 0x00, 0x80, 0x80 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
>> - { "red", { 0x4c, 0x55, 0xff }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
>> - { "green", { 0x96, 0x2c, 0x15 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
>> - { "blue", { 0x1d, 0xff, 0x6b }, { 0xffff, 0x0000, 0x0000, 0xffff }},
>> - },
>> + { "white", { 0xffff, 0x8000, 0x8000 }, { 0xffff, 0xffff, 0xffff, 0xffff }},
>> + { "gray", { 0x8080, 0x8000, 0x8000 }, { 0xffff, 0x8080, 0x8080, 0x8080 }},
>> + { "black", { 0x0000, 0x8000, 0x8000 }, { 0xffff, 0x0000, 0x0000, 0x0000 }},
>> + { "red", { 0x4c8b, 0x54ce, 0xffff }, { 0xffff, 0xffff, 0x0000, 0x0000 }},
>> + { "green", { 0x9645, 0x2b33, 0x14d1 }, { 0xffff, 0x0000, 0xffff, 0x0000 }},
>> + { "blue", { 0x1d2f, 0xffff, 0x6b2f }, { 0xffff, 0x0000, 0x0000, 0xffff }},
>
> Is there an explicit need of those tabs? They make the line length
> exceed 100 columns.
No explicit need, I don't know how I missed the checkpatch warning...
Fixed for v2.
> [...]
>
>> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/vkms_formats.c
>> index 5106441f916b..261e822e9618 100644
>> --- a/drivers/gpu/drm/vkms/vkms_formats.c
>> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
>> @@ -279,16 +279,17 @@ static struct pixel_argb_u16 argb_u16_from_BGR565(const __le16 *pixel)
>> return out_pixel;
>> }
>>
>> -VISIBLE_IF_KUNIT struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1, u8 channel_2,
>> - const struct conversion_matrix *matrix)
>> +VISIBLE_IF_KUNIT
>> +struct pixel_argb_u16 argb_u16_from_yuv161616(const struct conversion_matrix *matrix,
>> + u16 y, u16 channel_1, u16 channel_2)
>> {
>> u16 r, g, b;
>> s64 fp_y, fp_channel_1, fp_channel_2;
>> s64 fp_r, fp_g, fp_b;
>>
>> - fp_y = drm_int2fixp(((int)y - matrix->y_offset) * 257);
>> - fp_channel_1 = drm_int2fixp(((int)channel_1 - 128) * 257);
>> - fp_channel_2 = drm_int2fixp(((int)channel_2 - 128) * 257);
>> + fp_y = drm_int2fixp((int)y - matrix->y_offset * 257);
>> + fp_channel_1 = drm_int2fixp((int)channel_1 - 128 * 257);
>> + fp_channel_2 = drm_int2fixp((int)channel_2 - 128 * 257);
> > > fp_r = drm_fixp_mul(matrix->matrix[0][0], fp_y) +
>> drm_fixp_mul(matrix->matrix[0][1], fp_channel_1) +
>> @@ -310,7 +311,7 @@ VISIBLE_IF_KUNIT struct pixel_argb_u16 argb_u16_from_yuv888(u8 y, u8 channel_1,
>>
>> return argb_u16_from_u16161616(0xffff, r, g, b);
>> }
>> -EXPORT_SYMBOL_IF_KUNIT(argb_u16_from_yuv888);
>> +EXPORT_SYMBOL_IF_KUNIT(argb_u16_from_yuv161616);
>>
>> /**
>> * READ_LINE() - Generic generator for a read_line function which can be used for format with one
>> @@ -504,8 +505,8 @@ static void semi_planar_yuv_read_line(const struct vkms_plane_state *plane, int
>> const struct conversion_matrix *conversion_matrix = &plane->conversion_matrix;
>>
>> for (int i = 0; i < count; i++) {
>> - *out_pixel = argb_u16_from_yuv888(y_plane[0], uv_plane[0], uv_plane[1],
>> - conversion_matrix);
>> + *out_pixel = argb_u16_from_yuv161616(conversion_matrix, y_plane[0] * 257,
>> + uv_plane[0] * 257, uv_plane[1] * 257);
>> out_pixel += 1;
>> y_plane += step_y;
>> if ((i + subsampling_offset + 1) % subsampling == 0)
>> @@ -549,8 +550,9 @@ static void planar_yuv_read_line(const struct vkms_plane_state *plane, int x_sta
>> const struct conversion_matrix *conversion_matrix = &plane->conversion_matrix;
>>
>> for (int i = 0; i < count; i++) {
>> - *out_pixel = argb_u16_from_yuv888(*y_plane, *channel_1_plane, *channel_2_plane,
>> - conversion_matrix);
>> + *out_pixel = argb_u16_from_yuv161616(conversion_matrix,
>> + *y_plane * 257, *channel_1_plane * 257,
>> + *channel_2_plane * 257);
>> out_pixel += 1;
>> y_plane += step_y;
>> if ((i + subsampling_offset + 1) % subsampling == 0) {
>> @@ -690,9 +692,9 @@ pixel_read_line_t get_pixel_read_line_function(u32 format)
>> case DRM_FORMAT_BGRX8888:
>> return &BGRX8888_read_line;
>> case DRM_FORMAT_RGB888:
>> - return RGB888_read_line;
>> + return &RGB888_read_line;
>> case DRM_FORMAT_BGR888:
>> - return BGR888_read_line;
>> + return &BGR888_read_line;
>
> This should be in the previous patch.
Fixed for v5.
> Best Regards,
> - Maíra
>
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2025-06-13 18:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-30 14:05 [PATCH v4 0/8] drm/vkms: Add support for multiple plane formats Louis Chauvet
2025-05-30 14:05 ` [PATCH v4 1/8] drm/vkms: Create helpers macro to avoid code duplication in format callbacks Louis Chauvet
2025-06-11 19:51 ` Maíra Canal
2025-05-30 14:05 ` [PATCH v4 2/8] drm/vkms: Add support for ARGB8888 formats Louis Chauvet
2025-06-11 19:55 ` Maíra Canal
2025-06-13 17:28 ` Louis Chauvet
2025-06-21 10:52 ` Maíra Canal
2025-05-30 14:05 ` [PATCH v4 3/8] drm/vkms: Add support for ARGB16161616 formats Louis Chauvet
2025-06-11 19:57 ` Maíra Canal
2025-05-30 14:05 ` [PATCH v4 4/8] drm/vkms: Add support for RGB565 formats Louis Chauvet
2025-06-11 20:02 ` Maíra Canal
2025-06-13 17:38 ` Louis Chauvet
2025-05-30 14:06 ` [PATCH v4 5/8] drm/vkms: Add support for RGB888 formats Louis Chauvet
2025-06-11 20:02 ` Maíra Canal
2025-05-30 14:06 ` [PATCH v4 6/8] drm/vkms: Change YUV helpers to support u16 inputs for conversion Louis Chauvet
2025-06-11 20:24 ` Maíra Canal
2025-06-13 18:44 ` Louis Chauvet [this message]
2025-06-11 20:35 ` Maíra Canal
2025-05-30 14:06 ` [PATCH v4 7/8] drm/vkms: Create helper macro for YUV formats Louis Chauvet
2025-06-11 20:32 ` Maíra Canal
2025-05-30 14:06 ` [PATCH v4 8/8] drm/vkms: Add P01* formats Louis Chauvet
2026-08-13 15:19 ` 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=fb153302-4816-4a62-b59f-dc9e1963c1bf@bootlin.com \
--to=louis.chauvet@bootlin.com \
--cc=airlied@gmail.com \
--cc=arthurgrillo@riseup.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=jeremie.dautheribes@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mairacanal@riseup.net \
--cc=mcanal@igalia.com \
--cc=melissa.srw@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=mripard@kernel.org \
--cc=nicolejadeyee@google.com \
--cc=seanpaul@google.com \
--cc=simona.vetter@ffwll.ch \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=thomas.petazzoni@bootlin.com \
--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®