On 03/12/2022 01:47, Laurent Pinchart wrote:
On Fri, Dec 02, 2022 at 06:06:01PM +0200, Tomi Valkeinen wrote:
On 02/12/2022 17:56, Geert Uytterhoeven wrote:
On Fri, Dec 2, 2022 at 4:32 PM Tomi Valkeinen wrote:
On 02/12/2022 15:16, Tomi Valkeinen wrote:
These kms++ patches add support for Y210 format.
I didn't find a super clear description of the byte order for Y210
anywhere. If someone knows what it is supposed to be, I'd appreciate
verifying the code =).
Actually, this:
https://learn.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overview
indicates that the 10-bit values should be shifted by 6. So the drawing
code in this series is probably not right.
https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L212
seems to confirm that?
Hmm, indeed. I've looked at that before but I couldn't decipher it, but
now the text makes sense. Although afaics, it doesn't say that each
component is a 16-bit little endian. And I don't get the "little endian
per 2 Y pixels".
So if I get this right...
The first byte in memory is the two lowest bits of Y0 in bits 6 and 7.
The rest of the first byte is zero padding.
The second byte is the 8 highest bits of Y0.
Then following the same method, Cb, Y1, Cr.
I would have said in bits 7 and 6 for the first byte, but I assume we
mean the same. Apart from that, your interpretation is the same as mind.
However, if your aim is to support the 10bpp YUV 4:2:2 format of the
VSP, I'm not sure this is correct. Assuming you plan to set F2B=1 to
align bits towards the MSB, it's not clear if the endianness can be
configured. The four permutations of the packed YUYV components are
achievable as far as I can tell (see figure 60.12 in the documentation),
but I didn't immediately find a place where the endianness of each
16-bit value could be configured. Figure 60.15 mentions "example in case
of big endian", I don't know if it's an example, or the only possible
option. You may want to try both.
The pixel format can be set using F2B and swap options in VI6_RPFn_DSWAP
(Table 60.14). I have Y210 working (and I have had multiple other
variations working too). And by "working" I mean that it looks good to
me, but I can only see it via a web meeting as the board is at Kieran's.
The HW seems to be very versatile, and a lot of different variations can
be supported, especially for RGB formats. So this has been a bit
difficult as I didn't have any ready and validated test tool to draw
Y210, but I hope I got it working now correctly in kms++.
I don't know what format for 10-bit YUV Renesas really needs, but the
BSP commits said Y210, so that's what I added. Although afaik, the DU
only handles 8-bits per component, so I'm not sure what's the benefit of
10-bit formats (especially for RGB).
Tomi
