[PATCH v2 00/10] drm: Add new pixel formats for Xilinx Zynqmp

[PATCH v2 00/10] drm: Add new pixel formats for Xilinx Zynqmp

[Tomi Valkeinen]

Add new DRM pixel formats and add support for those in the Xilinx zynqmp
display driver.

All of these formats are already supported in upstream gstreamer, except
in the gstreamer kmssink, which obviously cannot support the formats
without kernel having the formats.

Xilinx has support for these formats in their BSP kernel, and Xilinx has
a branch here, adding the support to gstreamer kmssink:

https://github.com/Xilinx/gst-plugins-bad.git xlnx-rebase-v1.18.5

New formats added:

DRM_FORMAT_Y8
- 8-bit Y-only
- fourcc: "GREY"
- gstreamer: GRAY8

DRM_FORMAT_Y10_LE32
- 10-bit Y-only
- fourcc: "YPA4"
- gstreamer: GRAY10_LE32

DRM_FORMAT_XV15
- Like NV12, but with 10-bit components
- fourcc: "XV15"
- gstreamer: NV12_10LE32

DRM_FORMAT_XV20
- Like NV16, but with 10-bit components
- fourcc: "XV20"
- gstreamer: NV16_10LE32

DRM_FORMAT_X403
- 10-bit 4:4:4
- fourcc: "X403"
- gstreamer: Y444_10LE32

Some notes:

I know the 8-bit greyscale format has been discussed before, and the
guidance was to use DRM_FORMAT_R8. While I'm not totally against that, I
would argue that adding DRM_FORMAT_Y8 makes sense, as: 1) we can mark it
as 'is_yuv' in the drm_format_info, 2) we can have the same fourcc as in
v4l2, 3) it makes more sense for the user to use Y8/GREY format instead
of R8.

Also, if we go with DRM_FORMAT_R8, then I think it would make sense to
also add the 10-bit grayscale version as R10, instead of Y10, and it
would also have to have 'is_yuv' false, and I feel that would just
create even more confusion.

I have made some adjustments to the formats compared to the Xilinx's
branch. E.g. The DRM_FORMAT_Y10_LE32 format in Xilinx's kmssink uses
fourcc "Y10 ", and DRM_FORMAT_Y10. I didn't like those, as the format is
a packed format, three 10-bit pixels in a 32-bit container, and I think
Y10 means a 10-bit pixel in a 16-bit container.

Generally speaking, if someone has good ideas for the format define
names or fourccs, speak up, as it's not easy to invent good names =).
That said, keeping them the same as in the Xilinx trees will, of course,
be slightly easier for the users of Xilinx platforms.

There's also a bit unrelated path on top, fixing the missing max dma
seegment size in the zynqmp driver which I encountered while testing
these.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Changes in v2:
- I noticed V4L2 already has fourcc Y10P, referring to MIPI-style packed
  Y10 format. So I changed Y10_LE32 fourcc to YPA4. If logic has any
  relevance here, P means packed, A means 10, 4 means "in 4 bytes".
- Added tags to "Fix max dma segment size" patch
- Updated description for "Add warning for bad bpp"
- Link to v1: https://lore.kernel.org/r/20241204-xilinx-formats-v1-0-0bf2c5147db1@ideasonboard.com

---
Tomi Valkeinen (10):
      drm/fourcc: Add warning for bad bpp
      drm/fourcc: Add DRM_FORMAT_XV15/XV20
      drm/fourcc: Add DRM_FORMAT_Y8
      drm/fourcc: Add DRM_FORMAT_Y10_LE32
      drm/fourcc: Add DRM_FORMAT_X403
      drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizes
      drm: xlnx: zynqmp: Add support for XV15 & XV20
      drm: xlnx: zynqmp: Add support for Y8 and Y10_LE32
      drm: xlnx: zynqmp: Add support for X403
      drm: xlnx: zynqmp: Fix max dma segment size

 drivers/gpu/drm/drm_fourcc.c        | 24 ++++++++++++++++++
 drivers/gpu/drm/xlnx/zynqmp_disp.c  | 49 ++++++++++++++++++++++++++++++++++---
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c |  2 ++
 include/uapi/drm/drm_fourcc.h       | 20 +++++++++++++++
 4 files changed, 91 insertions(+), 4 deletions(-)
---
base-commit: adc218676eef25575469234709c2d87185ca223a
change-id: 20241120-xilinx-formats-f71901621833

Best regards,
-- 
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

[PATCH v2 01/10] drm/fourcc: Add warning for bad bpp

[Tomi Valkeinen]

drm_format_info_bpp() cannot be used for formats which do not have an
integer bits-per-pixel in a pixel block.

E.g. DRM_FORMAT_XV15's (not yet in upstream) plane 0 has three 10-bit
pixels (Y components), and two padding bits, in a 4 byte block. That is
10.666... bits per pixel when considering the whole 4 byte block, which
is what drm_format_info_bpp() does. Thus a driver that supports such
formats cannot use drm_format_info_bpp(),

It is a driver bug if this happens, but so handle wrong calls by
printing a warning and returning 0.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/drm_fourcc.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 193cf8ed7912..e84c4ed6928c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -429,6 +429,13 @@ unsigned int drm_format_info_bpp(const struct drm_format_info *info, int plane)
 	if (!info || plane < 0 || plane >= info->num_planes)
 		return 0;
 
+	if (info->char_per_block[plane] * 8 %
+	    (drm_format_info_block_width(info, plane) *
+	     drm_format_info_block_height(info, plane))) {
+		pr_warn("unable to return an integer bpp\n");
+		return 0;
+	}
+
 	return info->char_per_block[plane] * 8 /
 	       (drm_format_info_block_width(info, plane) *
 		drm_format_info_block_height(info, plane));

-- 
2.43.0

[PATCH v2 02/10] drm/fourcc: Add DRM_FORMAT_XV15/XV20

[Tomi Valkeinen]

Add two new pixel formats:

DRM_FORMAT_XV15 ("XV15")
DRM_FORMAT_XV20 ("XV20")

The formats are 2 plane 10 bit per component YCbCr, with the XV15 2x2
subsampled whereas XV20 is 2x1 subsampled.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/drm_fourcc.c  | 8 ++++++++
 include/uapi/drm/drm_fourcc.h | 8 ++++++++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index e84c4ed6928c..adb2d44630ee 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -318,6 +318,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
 		{ .format = DRM_FORMAT_P030,            .depth = 0,  .num_planes = 2,
 		  .char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 }, .block_h = { 1, 1, 0 },
 		  .hsub = 2, .vsub = 2, .is_yuv = true},
+		{ .format = DRM_FORMAT_XV15,		.depth = 0,
+		  .num_planes = 2, .char_per_block = { 4, 8, 0 },
+		  .block_w = { 3, 3, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+		  .vsub = 2, .is_yuv = true },
+		{ .format = DRM_FORMAT_XV20,		.depth = 0,
+		  .num_planes = 2, .char_per_block = { 4, 8, 0 },
+		  .block_w = { 3, 3, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+		  .vsub = 1, .is_yuv = true },
 	};
 
 	unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 78abd819fd62..2a00adcfb1ff 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -304,6 +304,14 @@ extern "C" {
 #define DRM_FORMAT_RGB565_A8	fourcc_code('R', '5', 'A', '8')
 #define DRM_FORMAT_BGR565_A8	fourcc_code('B', '5', 'A', '8')
 
+/*
+ * 2 plane 10 bit per component YCrCb
+ * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
+ * index 1 = Cb:Cr plane, [63:0] x:Cr2:Cb2:Cr1:x:Cb1:Cr0:Cb0 2:10:10:10:2:10:10:10 little endian
+ */
+#define DRM_FORMAT_XV15		fourcc_code('X', 'V', '1', '5') /* 2x2 subsampled Cr:Cb plane 2:10:10:10 */
+#define DRM_FORMAT_XV20		fourcc_code('X', 'V', '2', '0') /* 2x1 subsampled Cr:Cb plane 2:10:10:10 */
+
 /*
  * 2 plane YCbCr
  * index 0 = Y plane, [7:0] Y

-- 
2.43.0

[PATCH v2 03/10] drm/fourcc: Add DRM_FORMAT_Y8

[Tomi Valkeinen]

Add greyscale Y8 format.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/drm_fourcc.c  | 1 +
 include/uapi/drm/drm_fourcc.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index adb2d44630ee..d721d9fdbe98 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -239,6 +239,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
 		{ .format = DRM_FORMAT_YVU422,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 1, .is_yuv = true },
 		{ .format = DRM_FORMAT_YUV444,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true },
 		{ .format = DRM_FORMAT_YVU444,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+		{ .format = DRM_FORMAT_Y8,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
 		{ .format = DRM_FORMAT_NV12,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
 		{ .format = DRM_FORMAT_NV21,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
 		{ .format = DRM_FORMAT_NV16,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2a00adcfb1ff..f79ee3b93f09 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -405,6 +405,9 @@ extern "C" {
 #define DRM_FORMAT_YUV444	fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
 #define DRM_FORMAT_YVU444	fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
 
+/* Greyscale formats */
+
+#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
 
 /*
  * Format Modifiers:

-- 
2.43.0

Re: [PATCH v2 03/10] drm/fourcc: Add DRM_FORMAT_Y8

[Geert Uytterhoeven]

Hi Tomi,

On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> Add greyscale Y8 format.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

Thanks for your patch!

> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -405,6 +405,9 @@ extern "C" {
>  #define DRM_FORMAT_YUV444      fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
>  #define DRM_FORMAT_YVU444      fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
>
> +/* Greyscale formats */
> +
> +#define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */

I don't think you need this. We already have:

    /* 8 bpp Red (direct relationship between channel value and brightness) */
    #define DRM_FORMAT_R8           fourcc_code('R', '8', ' ', ' ') /*
[7:0] R */

See also commit 8aba4d30520ed656 ("drm/fourcc: Clarify the meaning of
single-channel "red"").

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 03/10] drm/fourcc: Add DRM_FORMAT_Y8

[Tomi Valkeinen]

Hi,

On 15/01/2025 12:30, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> Add greyscale Y8 format.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> 
> Thanks for your patch!
> 
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -405,6 +405,9 @@ extern "C" {
>>   #define DRM_FORMAT_YUV444      fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
>>   #define DRM_FORMAT_YVU444      fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
>>
>> +/* Greyscale formats */
>> +
>> +#define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
> 
> I don't think you need this. We already have:
> 
>      /* 8 bpp Red (direct relationship between channel value and brightness) */
>      #define DRM_FORMAT_R8           fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
> 
> See also commit 8aba4d30520ed656 ("drm/fourcc: Clarify the meaning of
> single-channel "red"").

Yes, I discuss this topic in the cover letter.

  Tomi

[PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Tomi Valkeinen]

Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
32-bit container.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/drm_fourcc.c  | 4 ++++
 include/uapi/drm/drm_fourcc.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d721d9fdbe98..6048e0a191dc 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -327,6 +327,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
 		  .num_planes = 2, .char_per_block = { 4, 8, 0 },
 		  .block_w = { 3, 3, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
 		  .vsub = 1, .is_yuv = true },
+		{ .format = DRM_FORMAT_Y10_LE32,        .depth = 0,
+		  .num_planes = 1, .char_per_block =  { 4, 0, 0 },
+		  .block_w = { 3, 0, 0 }, .block_h = { 1, 0, 0 }, .hsub = 1,
+		  .vsub = 1, .is_yuv = true },
 	};
 
 	unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index f79ee3b93f09..03be2aa40265 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -408,6 +408,7 @@ extern "C" {
 /* Greyscale formats */
 
 #define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
+#define DRM_FORMAT_Y10_LE32	fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
 
 /*
  * Format Modifiers:

-- 
2.43.0

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Geert Uytterhoeven]

Hi Tomi,

On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
> 32-bit container.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

Thanks for your patch!

> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -408,6 +408,7 @@ extern "C" {
>  /* Greyscale formats */
>
>  #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */

R10_LE32? Or R10_PA4?

Does LE32 have a meaning?  My first guess just reading the subject
was wrong ("little endian  32-bit" ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Tomi Valkeinen]

Hi,

On 15/01/2025 12:33, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
>> 32-bit container.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> 
> Thanks for your patch!
> 
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -408,6 +408,7 @@ extern "C" {
>>   /* Greyscale formats */
>>
>>   #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
>> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
> 
> R10_LE32? Or R10_PA4?

Can we discuss the "R" vs "Y" question under the cover letter? There's 
some more context about it in there.

I took the "LE32" from Gstreamer's format. Maybe it's a bit pointless.

I don't know if it makes sense to add the fourcc to the DRM format name. 
The fourcc is very limited. Rather, we could, say, have 
DRM_FORMAT_Y10_PACKED_32 (or "R", if you insist =).

> 
> Does LE32 have a meaning?  My first guess just reading the subject
> was wrong ("little endian  32-bit" ;-)

I'm not sure I follow. It's little-endian. The pixel group/unit is a 
32-bit number, where the leftmost pixel on the screen is in bits 9-0, 
and the padding is in bits 31-30, and stored in memory as little-endian.

  Tomi

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Geert Uytterhoeven]

Hi Tomi,

On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
> > On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> >> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
> >> 32-bit container.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> >
> > Thanks for your patch!
> >
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -408,6 +408,7 @@ extern "C" {
> >>   /* Greyscale formats */
> >>
> >>   #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
> >> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
> >
> > R10_LE32? Or R10_PA4?
>
> Can we discuss the "R" vs "Y" question under the cover letter? There's
> some more context about it in there.

Sorry, hadn't read the cover letter. I got attracted by "Y8" and "Y10".

> I took the "LE32" from Gstreamer's format. Maybe it's a bit pointless.
>
> I don't know if it makes sense to add the fourcc to the DRM format name.
> The fourcc is very limited. Rather, we could, say, have
> DRM_FORMAT_Y10_PACKED_32 (or "R", if you insist =).
>
> > Does LE32 have a meaning?  My first guess just reading the subject
> > was wrong ("little endian  32-bit" ;-)
>
> I'm not sure I follow. It's little-endian. The pixel group/unit is a
> 32-bit number, where the leftmost pixel on the screen is in bits 9-0,
> and the padding is in bits 31-30, and stored in memory as little-endian.

Ah, the "LE" applies to the pixels inside each word.

DRM formats stored in memory are always little-endian, unless the
DRM_FORMAT_BIG_ENDIAN bit is set, which is what I was hinting
at...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Tomi Valkeinen]

Hi,

On 15/01/2025 14:33, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
>>> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
>>>> 32-bit container.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/include/uapi/drm/drm_fourcc.h
>>>> +++ b/include/uapi/drm/drm_fourcc.h
>>>> @@ -408,6 +408,7 @@ extern "C" {
>>>>    /* Greyscale formats */
>>>>
>>>>    #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
>>>> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
>>>
>>> R10_LE32? Or R10_PA4?
>>
>> Can we discuss the "R" vs "Y" question under the cover letter? There's
>> some more context about it in there.
> 
> Sorry, hadn't read the cover letter. I got attracted by "Y8" and "Y10".
> 
>> I took the "LE32" from Gstreamer's format. Maybe it's a bit pointless.
>>
>> I don't know if it makes sense to add the fourcc to the DRM format name.
>> The fourcc is very limited. Rather, we could, say, have
>> DRM_FORMAT_Y10_PACKED_32 (or "R", if you insist =).
>>
>>> Does LE32 have a meaning?  My first guess just reading the subject
>>> was wrong ("little endian  32-bit" ;-)
>>
>> I'm not sure I follow. It's little-endian. The pixel group/unit is a
>> 32-bit number, where the leftmost pixel on the screen is in bits 9-0,
>> and the padding is in bits 31-30, and stored in memory as little-endian.
> 
> Ah, the "LE" applies to the pixels inside each word.

No, to the 32-bit container.

> DRM formats stored in memory are always little-endian, unless the
> DRM_FORMAT_BIG_ENDIAN bit is set, which is what I was hinting
> at...

Indeed you're right. The "LE" is pointless. So back to the bike-shedding 
about the name =).

  Tomi

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Geert Uytterhoeven]

Hi Tomi,

On Wed, Jan 15, 2025 at 1:42 PM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> On 15/01/2025 14:33, Geert Uytterhoeven wrote:
> > On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> >> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
> >>> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
> >>> <tomi.valkeinen@ideasonboard.com> wrote:
> >>>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
> >>>> 32-bit container.
> >>>>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> >>>
> >>> Thanks for your patch!
> >>>
> >>>> --- a/include/uapi/drm/drm_fourcc.h
> >>>> +++ b/include/uapi/drm/drm_fourcc.h
> >>>> @@ -408,6 +408,7 @@ extern "C" {
> >>>>    /* Greyscale formats */
> >>>>
> >>>>    #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
> >>>> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
> >>>
> >>> R10_LE32? Or R10_PA4?
> >>
> >> Can we discuss the "R" vs "Y" question under the cover letter? There's
> >> some more context about it in there.
> >
> > Sorry, hadn't read the cover letter. I got attracted by "Y8" and "Y10".
> >
> >> I took the "LE32" from Gstreamer's format. Maybe it's a bit pointless.
> >>
> >> I don't know if it makes sense to add the fourcc to the DRM format name.
> >> The fourcc is very limited. Rather, we could, say, have
> >> DRM_FORMAT_Y10_PACKED_32 (or "R", if you insist =).
> >>
> >>> Does LE32 have a meaning?  My first guess just reading the subject
> >>> was wrong ("little endian  32-bit" ;-)
> >>
> >> I'm not sure I follow. It's little-endian. The pixel group/unit is a
> >> 32-bit number, where the leftmost pixel on the screen is in bits 9-0,
> >> and the padding is in bits 31-30, and stored in memory as little-endian.
> >
> > Ah, the "LE" applies to the pixels inside each word.
>
> No, to the 32-bit container.
>
> > DRM formats stored in memory are always little-endian, unless the
> > DRM_FORMAT_BIG_ENDIAN bit is set, which is what I was hinting
> > at...
>
> Indeed you're right. The "LE" is pointless. So back to the bike-shedding
> about the name =).

As the order inside the container is Y2:Y1:Y0, it _is_ little endian.
Cfr.

#define DRM_FORMAT_YUYV  fourcc_code('Y', 'U', 'Y', 'V') /* [31:0]
Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Tomi Valkeinen]

Hi,

On 15/01/2025 14:52, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Wed, Jan 15, 2025 at 1:42 PM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> On 15/01/2025 14:33, Geert Uytterhoeven wrote:
>>> On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
>>>>> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
>>>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>>>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
>>>>>> 32-bit container.
>>>>>>
>>>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>>>>>
>>>>> Thanks for your patch!
>>>>>
>>>>>> --- a/include/uapi/drm/drm_fourcc.h
>>>>>> +++ b/include/uapi/drm/drm_fourcc.h
>>>>>> @@ -408,6 +408,7 @@ extern "C" {
>>>>>>     /* Greyscale formats */
>>>>>>
>>>>>>     #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
>>>>>> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
>>>>>
>>>>> R10_LE32? Or R10_PA4?
>>>>
>>>> Can we discuss the "R" vs "Y" question under the cover letter? There's
>>>> some more context about it in there.
>>>
>>> Sorry, hadn't read the cover letter. I got attracted by "Y8" and "Y10".
>>>
>>>> I took the "LE32" from Gstreamer's format. Maybe it's a bit pointless.
>>>>
>>>> I don't know if it makes sense to add the fourcc to the DRM format name.
>>>> The fourcc is very limited. Rather, we could, say, have
>>>> DRM_FORMAT_Y10_PACKED_32 (or "R", if you insist =).
>>>>
>>>>> Does LE32 have a meaning?  My first guess just reading the subject
>>>>> was wrong ("little endian  32-bit" ;-)
>>>>
>>>> I'm not sure I follow. It's little-endian. The pixel group/unit is a
>>>> 32-bit number, where the leftmost pixel on the screen is in bits 9-0,
>>>> and the padding is in bits 31-30, and stored in memory as little-endian.
>>>
>>> Ah, the "LE" applies to the pixels inside each word.
>>
>> No, to the 32-bit container.
>>
>>> DRM formats stored in memory are always little-endian, unless the
>>> DRM_FORMAT_BIG_ENDIAN bit is set, which is what I was hinting
>>> at...
>>
>> Indeed you're right. The "LE" is pointless. So back to the bike-shedding
>> about the name =).
> 
> As the order inside the container is Y2:Y1:Y0, it _is_ little endian.
> Cfr.
> 
> #define DRM_FORMAT_YUYV  fourcc_code('Y', 'U', 'Y', 'V') /* [31:0]
> Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */

Hmm, I see. I hadn't thought LE in that context, but I think it makes 
sense when there are multiple pixels in one container. So the "little 
endian" above would refer to the order of Y1 and Y0. So is Y1 the 
least-significant-pixel? =)

But, say, in

#define DRM_FORMAT_RG88		fourcc_code('R', 'G', '8', '8') /* [15:0] R:G 
8:8 little endian */

the "little endian" refers to the 16-bit value itself? Which is not 
necessary, as the default assumption is little endian.

In any case, when considering your latest point... "LE" in the name 
makes sense? But with a quick look I didn't find any formats that would 
have "big endian pixel order", so maybe we can just assume little endian 
pixel order too.

  Tomi

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Geert Uytterhoeven]

Hi Tomi,

On Wed, Jan 15, 2025 at 2:46 PM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> On 15/01/2025 14:52, Geert Uytterhoeven wrote:
> > On Wed, Jan 15, 2025 at 1:42 PM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> >> On 15/01/2025 14:33, Geert Uytterhoeven wrote:
> >>> On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
> >>> <tomi.valkeinen@ideasonboard.com> wrote:
> >>>> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
> >>>>> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
> >>>>> <tomi.valkeinen@ideasonboard.com> wrote:
> >>>>>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
> >>>>>> 32-bit container.
> >>>>>>
> >>>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> >>>>>
> >>>>> Thanks for your patch!
> >>>>>
> >>>>>> --- a/include/uapi/drm/drm_fourcc.h
> >>>>>> +++ b/include/uapi/drm/drm_fourcc.h
> >>>>>> @@ -408,6 +408,7 @@ extern "C" {
> >>>>>>     /* Greyscale formats */
> >>>>>>
> >>>>>>     #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
> >>>>>> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
> >>>>>
> >>>>> R10_LE32? Or R10_PA4?
> >>>>
> >>>> Can we discuss the "R" vs "Y" question under the cover letter? There's
> >>>> some more context about it in there.
> >>>
> >>> Sorry, hadn't read the cover letter. I got attracted by "Y8" and "Y10".
> >>>
> >>>> I took the "LE32" from Gstreamer's format. Maybe it's a bit pointless.
> >>>>
> >>>> I don't know if it makes sense to add the fourcc to the DRM format name.
> >>>> The fourcc is very limited. Rather, we could, say, have
> >>>> DRM_FORMAT_Y10_PACKED_32 (or "R", if you insist =).
> >>>>
> >>>>> Does LE32 have a meaning?  My first guess just reading the subject
> >>>>> was wrong ("little endian  32-bit" ;-)
> >>>>
> >>>> I'm not sure I follow. It's little-endian. The pixel group/unit is a
> >>>> 32-bit number, where the leftmost pixel on the screen is in bits 9-0,
> >>>> and the padding is in bits 31-30, and stored in memory as little-endian.
> >>>
> >>> Ah, the "LE" applies to the pixels inside each word.
> >>
> >> No, to the 32-bit container.
> >>
> >>> DRM formats stored in memory are always little-endian, unless the
> >>> DRM_FORMAT_BIG_ENDIAN bit is set, which is what I was hinting
> >>> at...
> >>
> >> Indeed you're right. The "LE" is pointless. So back to the bike-shedding
> >> about the name =).
> >
> > As the order inside the container is Y2:Y1:Y0, it _is_ little endian.
> > Cfr.
> >
> > #define DRM_FORMAT_YUYV  fourcc_code('Y', 'U', 'Y', 'V') /* [31:0]
> > Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
>
> Hmm, I see. I hadn't thought LE in that context, but I think it makes
> sense when there are multiple pixels in one container. So the "little
> endian" above would refer to the order of Y1 and Y0. So is Y1 the
> least-significant-pixel? =)

No, Y0 is the least-significant member of the container, which
corresponds to the first pixel ("little end first").

> But, say, in
>
> #define DRM_FORMAT_RG88         fourcc_code('R', 'G', '8', '8') /* [15:0] R:G
> 8:8 little endian */
>
> the "little endian" refers to the 16-bit value itself? Which is not
> necessary, as the default assumption is little endian.

I think so.

> In any case, when considering your latest point... "LE" in the name
> makes sense? But with a quick look I didn't find any formats that would
> have "big endian pixel order", so maybe we can just assume little endian
> pixel order too.

[CDR][124] have. See the descriptions of the commits that introduced
them for the rationale behind this:

b92db7e4fe740daa drm/fourcc: Add DRM_FORMAT_D[1248]
d093100b425df6fe drm/fourcc: Add DRM_FORMAT_R[124]
e5bd7e3e4a68f0be drm/fourcc: Add DRM_FORMAT_C[124]

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Tomi Valkeinen]

On 15/01/2025 16:08, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Wed, Jan 15, 2025 at 2:46 PM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> On 15/01/2025 14:52, Geert Uytterhoeven wrote:
>>> On Wed, Jan 15, 2025 at 1:42 PM Tomi Valkeinen
>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>> On 15/01/2025 14:33, Geert Uytterhoeven wrote:
>>>>> On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
>>>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>>>> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
>>>>>>> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
>>>>>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>>>>>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
>>>>>>>> 32-bit container.
>>>>>>>>
>>>>>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>>>>>>>
>>>>>>> Thanks for your patch!
>>>>>>>
>>>>>>>> --- a/include/uapi/drm/drm_fourcc.h
>>>>>>>> +++ b/include/uapi/drm/drm_fourcc.h
>>>>>>>> @@ -408,6 +408,7 @@ extern "C" {
>>>>>>>>      /* Greyscale formats */
>>>>>>>>
>>>>>>>>      #define DRM_FORMAT_Y8          fourcc_code('G', 'R', 'E', 'Y')  /* 8-bit Y-only */
>>>>>>>> +#define DRM_FORMAT_Y10_LE32    fourcc_code('Y', 'P', 'A', '4')  /* [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian */
>>>>>>>
>>>>>>> R10_LE32? Or R10_PA4?
>>>>>>
>>>>>> Can we discuss the "R" vs "Y" question under the cover letter? There's
>>>>>> some more context about it in there.
>>>>>
>>>>> Sorry, hadn't read the cover letter. I got attracted by "Y8" and "Y10".
>>>>>
>>>>>> I took the "LE32" from Gstreamer's format. Maybe it's a bit pointless.
>>>>>>
>>>>>> I don't know if it makes sense to add the fourcc to the DRM format name.
>>>>>> The fourcc is very limited. Rather, we could, say, have
>>>>>> DRM_FORMAT_Y10_PACKED_32 (or "R", if you insist =).
>>>>>>
>>>>>>> Does LE32 have a meaning?  My first guess just reading the subject
>>>>>>> was wrong ("little endian  32-bit" ;-)
>>>>>>
>>>>>> I'm not sure I follow. It's little-endian. The pixel group/unit is a
>>>>>> 32-bit number, where the leftmost pixel on the screen is in bits 9-0,
>>>>>> and the padding is in bits 31-30, and stored in memory as little-endian.
>>>>>
>>>>> Ah, the "LE" applies to the pixels inside each word.
>>>>
>>>> No, to the 32-bit container.
>>>>
>>>>> DRM formats stored in memory are always little-endian, unless the
>>>>> DRM_FORMAT_BIG_ENDIAN bit is set, which is what I was hinting
>>>>> at...
>>>>
>>>> Indeed you're right. The "LE" is pointless. So back to the bike-shedding
>>>> about the name =).
>>>
>>> As the order inside the container is Y2:Y1:Y0, it _is_ little endian.
>>> Cfr.
>>>
>>> #define DRM_FORMAT_YUYV  fourcc_code('Y', 'U', 'Y', 'V') /* [31:0]
>>> Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
>>
>> Hmm, I see. I hadn't thought LE in that context, but I think it makes
>> sense when there are multiple pixels in one container. So the "little
>> endian" above would refer to the order of Y1 and Y0. So is Y1 the
>> least-significant-pixel? =)
> 
> No, Y0 is the least-significant member of the container, which
> corresponds to the first pixel ("little end first").

In the number 0x1234, 0x34 is the least-significant byte, and stored 
first in memory in little endian.

So, similarly, with Y0:Y1, Y1 is stored first in little-endian order, so 
it's the least-significant-pixel =).

>> But, say, in
>>
>> #define DRM_FORMAT_RG88         fourcc_code('R', 'G', '8', '8') /* [15:0] R:G
>> 8:8 little endian */
>>
>> the "little endian" refers to the 16-bit value itself? Which is not
>> necessary, as the default assumption is little endian.
> 
> I think so.
> 
>> In any case, when considering your latest point... "LE" in the name
>> makes sense? But with a quick look I didn't find any formats that would
>> have "big endian pixel order", so maybe we can just assume little endian
>> pixel order too.
> 
> [CDR][124] have. See the descriptions of the commits that introduced
> them for the rationale behind this:
> 
> b92db7e4fe740daa drm/fourcc: Add DRM_FORMAT_D[1248]
> d093100b425df6fe drm/fourcc: Add DRM_FORMAT_R[124]
> e5bd7e3e4a68f0be drm/fourcc: Add DRM_FORMAT_C[124]

Ah, I see. But they don't call the pixel ordering "big endian".

Well, this is all somewhat beside the point. So is "_Y10_32" (or 
"_R10_32" if we use R) fine?

  Tomi

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Geert Uytterhoeven]

Hi Tomi,

On Wed, Jan 15, 2025 at 3:34 PM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
> On 15/01/2025 16:08, Geert Uytterhoeven wrote:
> > On Wed, Jan 15, 2025 at 2:46 PM Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> >> On 15/01/2025 14:52, Geert Uytterhoeven wrote:
> >>> On Wed, Jan 15, 2025 at 1:42 PM Tomi Valkeinen
> >>> <tomi.valkeinen@ideasonboard.com> wrote:
> >>>> On 15/01/2025 14:33, Geert Uytterhoeven wrote:
> >>>>> On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
> >>>>> <tomi.valkeinen@ideasonboard.com> wrote:
> >>>>>> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
> >>>>>>> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
> >>>>>>> <tomi.valkeinen@ideasonboard.com> wrote:
> >>>>>>>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
> >>>>>>>> 32-bit container.

> Well, this is all somewhat beside the point. So is "_Y10_32" (or
> "_R10_32" if we use R) fine?

IAARDD[*], but "10_32" makes me think it stores one 10-bit pixel in a
32-bit word (i.e. a 32-bit variant of R10). So [YR]PA4 would be better.

[*] I am a rookie DRM developer...


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 04/10] drm/fourcc: Add DRM_FORMAT_Y10_LE32

[Tomi Valkeinen]

On 15/01/2025 16:49, Geert Uytterhoeven wrote:
> Hi Tomi,
> 
> On Wed, Jan 15, 2025 at 3:34 PM Tomi Valkeinen
> <tomi.valkeinen@ideasonboard.com> wrote:
>> On 15/01/2025 16:08, Geert Uytterhoeven wrote:
>>> On Wed, Jan 15, 2025 at 2:46 PM Tomi Valkeinen
>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>> On 15/01/2025 14:52, Geert Uytterhoeven wrote:
>>>>> On Wed, Jan 15, 2025 at 1:42 PM Tomi Valkeinen
>>>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>>>> On 15/01/2025 14:33, Geert Uytterhoeven wrote:
>>>>>>> On Wed, Jan 15, 2025 at 12:11 PM Tomi Valkeinen
>>>>>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>>>>>> On 15/01/2025 12:33, Geert Uytterhoeven wrote:
>>>>>>>>> On Wed, Jan 15, 2025 at 10:04 AM Tomi Valkeinen
>>>>>>>>> <tomi.valkeinen@ideasonboard.com> wrote:
>>>>>>>>>> Add Y10_LE32, a 10 bit greyscale format, with 3 pixels packed into
>>>>>>>>>> 32-bit container.
> 
>> Well, this is all somewhat beside the point. So is "_Y10_32" (or
>> "_R10_32" if we use R) fine?
> 
> IAARDD[*], but "10_32" makes me think it stores one 10-bit pixel in a
> 32-bit word (i.e. a 32-bit variant of R10). So [YR]PA4 would be better.

That would be a very silly format. So I think some HW guy is already 
designing chips that have it.

[YR]10_PACKED_32? We can have longer names, we don't need to do encoding 
like [YR]PA4.

> [*] I am a rookie DRM developer...

I haven't heard that before...

  Tomi

[PATCH v2 05/10] drm/fourcc: Add DRM_FORMAT_X403

[Tomi Valkeinen]

Add X403, a 3 plane non-subsampled YCbCr format.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/drm_fourcc.c  | 4 ++++
 include/uapi/drm/drm_fourcc.h | 8 ++++++++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 6048e0a191dc..219113b5924c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -331,6 +331,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
 		  .num_planes = 1, .char_per_block =  { 4, 0, 0 },
 		  .block_w = { 3, 0, 0 }, .block_h = { 1, 0, 0 }, .hsub = 1,
 		  .vsub = 1, .is_yuv = true },
+		{ .format = DRM_FORMAT_X403,		.depth = 0,
+		  .num_planes = 3, .char_per_block =  { 4, 4, 4 },
+		  .block_w = { 3, 3, 3 }, .block_h = { 1, 1, 1 },
+		  .hsub = 1, .vsub = 1, .is_yuv = true },
 	};
 
 	unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 03be2aa40265..a7a814a1472b 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -385,6 +385,14 @@ extern "C" {
  */
 #define DRM_FORMAT_Q401		fourcc_code('Q', '4', '0', '1')
 
+/* 3 plane non-subsampled (444) YCbCr
+ * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
+ * index 0: Y plane,  [31:0] x:Y2:Y1:Y0    [2:10:10:10] little endian
+ * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
+ * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
+ */
+#define DRM_FORMAT_X403		fourcc_code('X', '4', '0', '3')
+
 /*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y

-- 
2.43.0

[PATCH v2 06/10] drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizes

[Tomi Valkeinen]

Use drm helpers, drm_format_info_plane_width(),
drm_format_info_plane_height() and drm_format_info_min_pitch() to
calculate sizes for the DMA.

This cleans up the code, but also makes it possible to support more
complex formats (like XV15, XV20).

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 9368acf56eaf..57221575cbd6 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1154,16 +1154,18 @@ int zynqmp_disp_layer_update(struct zynqmp_disp_layer *layer,
 		return 0;
 
 	for (i = 0; i < info->num_planes; i++) {
-		unsigned int width = state->crtc_w / (i ? info->hsub : 1);
-		unsigned int height = state->crtc_h / (i ? info->vsub : 1);
 		struct zynqmp_disp_layer_dma *dma = &layer->dmas[i];
 		struct dma_async_tx_descriptor *desc;
+		unsigned int width, height;
 		dma_addr_t dma_addr;
 
+		width = drm_format_info_plane_width(info, state->crtc_w, i);
+		height = drm_format_info_plane_height(info, state->crtc_h, i);
+
 		dma_addr = drm_fb_dma_get_gem_addr(state->fb, state, i);
 
 		dma->xt.numf = height;
-		dma->sgl.size = width * info->cpp[i];
+		dma->sgl.size = drm_format_info_min_pitch(info, i, width);
 		dma->sgl.icg = state->fb->pitches[i] - dma->sgl.size;
 		dma->xt.src_start = dma_addr;
 		dma->xt.frame_size = 1;

-- 
2.43.0

[PATCH v2 07/10] drm: xlnx: zynqmp: Add support for XV15 & XV20

[Tomi Valkeinen]

Add support for XV15 & XV20 formats.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 57221575cbd6..3998754e367e 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -299,6 +299,16 @@ static const struct zynqmp_disp_format avbuf_vid_fmts[] = {
 		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_420,
 		.swap		= true,
 		.sf		= scaling_factors_888,
+	}, {
+		.drm_fmt	= DRM_FORMAT_XV15,
+		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_420_10,
+		.swap		= false,
+		.sf		= scaling_factors_101010,
+	}, {
+		.drm_fmt	= DRM_FORMAT_XV20,
+		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_10,
+		.swap		= false,
+		.sf		= scaling_factors_101010,
 	},
 };
 

-- 
2.43.0

[PATCH v2 08/10] drm: xlnx: zynqmp: Add support for Y8 and Y10_LE32

[Tomi Valkeinen]

Add support for Y8 and Y10_LE32 formats. We also need to add new csc
matrices for the y-only formats.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 3998754e367e..44cfee6a0e32 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -309,6 +309,16 @@ static const struct zynqmp_disp_format avbuf_vid_fmts[] = {
 		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_10,
 		.swap		= false,
 		.sf		= scaling_factors_101010,
+	}, {
+		.drm_fmt	= DRM_FORMAT_Y8,
+		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MONO,
+		.swap		= false,
+		.sf		= scaling_factors_888,
+	}, {
+		.drm_fmt	= DRM_FORMAT_Y10_LE32,
+		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YONLY_10,
+		.swap		= false,
+		.sf		= scaling_factors_101010,
 	},
 };
 
@@ -699,6 +709,16 @@ static const u32 csc_sdtv_to_rgb_offsets[] = {
 	0x0, 0x1800, 0x1800
 };
 
+static const u16 csc_sdtv_to_rgb_yonly_matrix[] = {
+	0x0, 0x0, 0x1000,
+	0x0, 0x0, 0x1000,
+	0x0, 0x0, 0x1000,
+};
+
+static const u32 csc_sdtv_to_rgb_yonly_offsets[] = {
+	0x1800, 0x1800, 0x0
+};
+
 /**
  * zynqmp_disp_blend_set_output_format - Set the output format of the blender
  * @disp: Display controller
@@ -848,7 +868,11 @@ static void zynqmp_disp_blend_layer_enable(struct zynqmp_disp *disp,
 				ZYNQMP_DISP_V_BLEND_LAYER_CONTROL(layer->id),
 				val);
 
-	if (layer->drm_fmt->is_yuv) {
+	if (layer->drm_fmt->format == DRM_FORMAT_Y8 ||
+	    layer->drm_fmt->format == DRM_FORMAT_Y10_LE32) {
+		coeffs = csc_sdtv_to_rgb_yonly_matrix;
+		offsets = csc_sdtv_to_rgb_yonly_offsets;
+	} else if (layer->drm_fmt->is_yuv) {
 		coeffs = csc_sdtv_to_rgb_matrix;
 		offsets = csc_sdtv_to_rgb_offsets;
 	} else {

-- 
2.43.0

[PATCH v2 09/10] drm: xlnx: zynqmp: Add support for X403

[Tomi Valkeinen]

Add support for X403 format.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 44cfee6a0e32..622d1dfac42d 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -319,6 +319,11 @@ static const struct zynqmp_disp_format avbuf_vid_fmts[] = {
 		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YONLY_10,
 		.swap		= false,
 		.sf		= scaling_factors_101010,
+	}, {
+		.drm_fmt	= DRM_FORMAT_X403,
+		.buf_fmt	= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV24_10,
+		.swap		= false,
+		.sf		= scaling_factors_101010,
 	},
 };
 

-- 
2.43.0

[PATCH v2 10/10] drm: xlnx: zynqmp: Fix max dma segment size

[Tomi Valkeinen]

Fix "mapping sg segment longer than device claims to support" warning by
setting the max segment size.

Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem")
Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
Tested-by: Sean Anderson <sean.anderson@linux.dev>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index f5781939de9c..a25b22238e3d 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -231,6 +231,8 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
+
 	/* Try the reserved memory. Proceed if there's none. */
 	of_reserved_mem_device_init(&pdev->dev);
 

-- 
2.43.0

Re: [PATCH v2 10/10] drm: xlnx: zynqmp: Fix max dma segment size

[Sean Anderson]

Hi Tomi,

On 1/15/25 04:03, Tomi Valkeinen wrote:
> Fix "mapping sg segment longer than device claims to support" warning by
> setting the max segment size.
> 
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem")
> Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
> Tested-by: Sean Anderson <sean.anderson@linux.dev>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>  drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index f5781939de9c..a25b22238e3d 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -231,6 +231,8 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> +	dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
> +
>  	/* Try the reserved memory. Proceed if there's none. */
>  	of_reserved_mem_device_init(&pdev->dev);
>  
> 

Can you apply this patch? I ran into this warning again today and I think this change
is independent from the rest of the series.

--Sean

Re: [PATCH v2 10/10] drm: xlnx: zynqmp: Fix max dma segment size

[Tomi Valkeinen]

Hi,

On 06/02/2025 21:48, Sean Anderson wrote:
> Hi Tomi,
> 
> On 1/15/25 04:03, Tomi Valkeinen wrote:
>> Fix "mapping sg segment longer than device claims to support" warning by
>> setting the max segment size.
>>
>> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem")
>> Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
>> Tested-by: Sean Anderson <sean.anderson@linux.dev>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>> ---
>>   drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
>> index f5781939de9c..a25b22238e3d 100644
>> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
>> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
>> @@ -231,6 +231,8 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
>>   	if (ret)
>>   		return ret;
>>   
>> +	dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
>> +
>>   	/* Try the reserved memory. Proceed if there's none. */
>>   	of_reserved_mem_device_init(&pdev->dev);
>>   
>>
> 
> Can you apply this patch? I ran into this warning again today and I think this change
> is independent from the rest of the series.

Yes, I'll push this.

  Tomi

Re: [PATCH v2 00/10] drm: Add new pixel formats for Xilinx Zynqmp

[Dmitry Baryshkov]

On Wed, Jan 15, 2025 at 11:03:29AM +0200, Tomi Valkeinen wrote:
> Add new DRM pixel formats and add support for those in the Xilinx zynqmp
> display driver.
> 
> All of these formats are already supported in upstream gstreamer, except
> in the gstreamer kmssink, which obviously cannot support the formats
> without kernel having the formats.
> 
> Xilinx has support for these formats in their BSP kernel, and Xilinx has
> a branch here, adding the support to gstreamer kmssink:
> 
> https://github.com/Xilinx/gst-plugins-bad.git xlnx-rebase-v1.18.5
> 
> New formats added:
> 
> DRM_FORMAT_Y8
> - 8-bit Y-only
> - fourcc: "GREY"
> - gstreamer: GRAY8
> 
> DRM_FORMAT_Y10_LE32
> - 10-bit Y-only
> - fourcc: "YPA4"
> - gstreamer: GRAY10_LE32
> 
> DRM_FORMAT_XV15
> - Like NV12, but with 10-bit components
> - fourcc: "XV15"
> - gstreamer: NV12_10LE32
> 
> DRM_FORMAT_XV20
> - Like NV16, but with 10-bit components
> - fourcc: "XV20"
> - gstreamer: NV16_10LE32
> 
> DRM_FORMAT_X403
> - 10-bit 4:4:4
> - fourcc: "X403"
> - gstreamer: Y444_10LE32

Could you possibly add support for those formats to the modetest util?

> 
> Some notes:
> 
> I know the 8-bit greyscale format has been discussed before, and the
> guidance was to use DRM_FORMAT_R8. While I'm not totally against that, I
> would argue that adding DRM_FORMAT_Y8 makes sense, as: 1) we can mark it
> as 'is_yuv' in the drm_format_info, 2) we can have the same fourcc as in
> v4l2, 3) it makes more sense for the user to use Y8/GREY format instead
> of R8.
> 
> Also, if we go with DRM_FORMAT_R8, then I think it would make sense to
> also add the 10-bit grayscale version as R10, instead of Y10, and it
> would also have to have 'is_yuv' false, and I feel that would just
> create even more confusion.
> 
> I have made some adjustments to the formats compared to the Xilinx's
> branch. E.g. The DRM_FORMAT_Y10_LE32 format in Xilinx's kmssink uses
> fourcc "Y10 ", and DRM_FORMAT_Y10. I didn't like those, as the format is
> a packed format, three 10-bit pixels in a 32-bit container, and I think
> Y10 means a 10-bit pixel in a 16-bit container.
> 
> Generally speaking, if someone has good ideas for the format define
> names or fourccs, speak up, as it's not easy to invent good names =).
> That said, keeping them the same as in the Xilinx trees will, of course,
> be slightly easier for the users of Xilinx platforms.
> 
> There's also a bit unrelated path on top, fixing the missing max dma
> seegment size in the zynqmp driver which I encountered while testing
> these.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
> Changes in v2:
> - I noticed V4L2 already has fourcc Y10P, referring to MIPI-style packed
>   Y10 format. So I changed Y10_LE32 fourcc to YPA4. If logic has any
>   relevance here, P means packed, A means 10, 4 means "in 4 bytes".
> - Added tags to "Fix max dma segment size" patch
> - Updated description for "Add warning for bad bpp"
> - Link to v1: https://lore.kernel.org/r/20241204-xilinx-formats-v1-0-0bf2c5147db1@ideasonboard.com
> 
> ---
> Tomi Valkeinen (10):
>       drm/fourcc: Add warning for bad bpp
>       drm/fourcc: Add DRM_FORMAT_XV15/XV20
>       drm/fourcc: Add DRM_FORMAT_Y8
>       drm/fourcc: Add DRM_FORMAT_Y10_LE32
>       drm/fourcc: Add DRM_FORMAT_X403
>       drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizes
>       drm: xlnx: zynqmp: Add support for XV15 & XV20
>       drm: xlnx: zynqmp: Add support for Y8 and Y10_LE32
>       drm: xlnx: zynqmp: Add support for X403
>       drm: xlnx: zynqmp: Fix max dma segment size
> 
>  drivers/gpu/drm/drm_fourcc.c        | 24 ++++++++++++++++++
>  drivers/gpu/drm/xlnx/zynqmp_disp.c  | 49 ++++++++++++++++++++++++++++++++++---
>  drivers/gpu/drm/xlnx/zynqmp_dpsub.c |  2 ++
>  include/uapi/drm/drm_fourcc.h       | 20 +++++++++++++++
>  4 files changed, 91 insertions(+), 4 deletions(-)
> ---
> base-commit: adc218676eef25575469234709c2d87185ca223a
> change-id: 20241120-xilinx-formats-f71901621833
> 
> Best regards,
> -- 
> Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 00/10] drm: Add new pixel formats for Xilinx Zynqmp

[Tomi Valkeinen]

Hi,

On 15/01/2025 13:13, Dmitry Baryshkov wrote:
> On Wed, Jan 15, 2025 at 11:03:29AM +0200, Tomi Valkeinen wrote:
>> Add new DRM pixel formats and add support for those in the Xilinx zynqmp
>> display driver.
>>
>> All of these formats are already supported in upstream gstreamer, except
>> in the gstreamer kmssink, which obviously cannot support the formats
>> without kernel having the formats.
>>
>> Xilinx has support for these formats in their BSP kernel, and Xilinx has
>> a branch here, adding the support to gstreamer kmssink:
>>
>> https://github.com/Xilinx/gst-plugins-bad.git xlnx-rebase-v1.18.5
>>
>> New formats added:
>>
>> DRM_FORMAT_Y8
>> - 8-bit Y-only
>> - fourcc: "GREY"
>> - gstreamer: GRAY8
>>
>> DRM_FORMAT_Y10_LE32
>> - 10-bit Y-only
>> - fourcc: "YPA4"
>> - gstreamer: GRAY10_LE32
>>
>> DRM_FORMAT_XV15
>> - Like NV12, but with 10-bit components
>> - fourcc: "XV15"
>> - gstreamer: NV12_10LE32
>>
>> DRM_FORMAT_XV20
>> - Like NV16, but with 10-bit components
>> - fourcc: "XV20"
>> - gstreamer: NV16_10LE32
>>
>> DRM_FORMAT_X403
>> - 10-bit 4:4:4
>> - fourcc: "X403"
>> - gstreamer: Y444_10LE32
> 
> Could you possibly add support for those formats to the modetest util?

Yes, I can do that.

I was mainly using https://github.com/tomba/pykms for testing, and 
sometimes gstreamer. Adding support to modetest is (hopefully) not too 
complex (the XV15 and XV20 are a bit annoying formats).

  Tomi

Re: [PATCH v2 00/10] drm: Add new pixel formats for Xilinx Zynqmp

[Tomi Valkeinen]

Hi Dmitry,

On 15/01/2025 13:13, Dmitry Baryshkov wrote:
> On Wed, Jan 15, 2025 at 11:03:29AM +0200, Tomi Valkeinen wrote:
>> Add new DRM pixel formats and add support for those in the Xilinx zynqmp
>> display driver.
>>
>> All of these formats are already supported in upstream gstreamer, except
>> in the gstreamer kmssink, which obviously cannot support the formats
>> without kernel having the formats.
>>
>> Xilinx has support for these formats in their BSP kernel, and Xilinx has
>> a branch here, adding the support to gstreamer kmssink:
>>
>> https://github.com/Xilinx/gst-plugins-bad.git xlnx-rebase-v1.18.5
>>
>> New formats added:
>>
>> DRM_FORMAT_Y8
>> - 8-bit Y-only
>> - fourcc: "GREY"
>> - gstreamer: GRAY8
>>
>> DRM_FORMAT_Y10_LE32
>> - 10-bit Y-only
>> - fourcc: "YPA4"
>> - gstreamer: GRAY10_LE32
>>
>> DRM_FORMAT_XV15
>> - Like NV12, but with 10-bit components
>> - fourcc: "XV15"
>> - gstreamer: NV12_10LE32
>>
>> DRM_FORMAT_XV20
>> - Like NV16, but with 10-bit components
>> - fourcc: "XV20"
>> - gstreamer: NV16_10LE32
>>
>> DRM_FORMAT_X403
>> - 10-bit 4:4:4
>> - fourcc: "X403"
>> - gstreamer: Y444_10LE32
> 
> Could you possibly add support for those formats to the modetest util?

I sent a new version for this:

https://lore.kernel.org/all/20250212-xilinx-formats-v3-0-90d0fe106995%40ideasonboard.com/

But I missed adding you to cc. Sorry about that.

  Tomi