[PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Hyun Kwon]

Hi,

This series is to add new drm formats needed by some Xilinx IPs.
Some formats have unique characteristics such as pixels not being
byte-aligned. For instance, some 10bit formats have 2bit padding
after every 3-10bit components:

	32b[0]:	10b comp0 - 10b comp1 - 10b comp2 - 2b padding
	32b[1]:	10b comp3 - 10b comp4 - 10b comp5 - 2b padding
	...

To model this, additional information is added to struct drm_format_info.
The patch has been tested with downstream drivers as well as the downstream
user space component (ex, modified modetest).

Thanks,
hyun

Jeffrey Mouroux (2):
  uapi: drm: New fourcc codes needed by Xilinx Video IP
  drm: fourcc: Update DRM Framework with new fourcc codes

Satish Kumar Nagireddy (1):
  drm: drm_fourcc: Add scaling and padding factor to drm_format_info

 drivers/gpu/drm/drm_fourcc.c  | 143 ++++++++++++++++++++++--------------------
 include/drm/drm_fourcc.h      |   9 +++
 include/uapi/drm/drm_fourcc.h |   9 +++
 3 files changed, 93 insertions(+), 68 deletions(-)

-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info

[Hyun Kwon]

From: Satish Kumar Nagireddy <satish.nagireddy.nagireddy@xilinx.com>

'cpp_scale' can be used as a multiplying factor to calculate
bytes per component based on color format.
For eg. scaling factor of YUV420 8 bit format is 1
        so multiplying factor is 1 (8/8)
        scaling factor of YUV420 10 bit format is 1.25 (10/8)

'padding_scale' can be used as a multiplying factor to calculate
actual width of video according to color format.
For eg. padding factor of YUV420 8 bit format: 8 bits per 1 component
        no padding bits here, so multiplying factor is 1
        padding factor of YUV422 10 bit format: 32 bits per 3 components
        each component is 10 bit and the factor is 32/30

Signed-off-by: Satish Kumar Nagireddy <satishna@xilinx.com>
Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
---
 drivers/gpu/drm/drm_fourcc.c | 136 +++++++++++++++++++++----------------------
 include/drm/drm_fourcc.h     |   9 +++
 2 files changed, 77 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152d..52afb5e 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
 const struct drm_format_info *__drm_format_info(u32 format)
 {
 	static const struct drm_format_info formats[] = {
-		{ .format = DRM_FORMAT_C8,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGB332,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGR233,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XRGB4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XBGR4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBX4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRX4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ARGB4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ABGR4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBA4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRA4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XRGB1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XBGR1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBX5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRX5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ARGB1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ABGR1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBA5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRA5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGB565,		.depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGR565,		.depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGB888,		.depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGR888,		.depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XRGB8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XBGR8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBX8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRX8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGB565_A8,	.depth = 24, .num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGR565_A8,	.depth = 24, .num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XRGB2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XBGR2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBX1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRX1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ARGB2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ABGR2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBA1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRA1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ARGB8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_ABGR8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBA8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRA8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGB888_A8,	.depth = 32, .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGR888_A8,	.depth = 32, .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XRGB8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_XBGR8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_RGBX8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_BGRX8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_YUV410,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
-		{ .format = DRM_FORMAT_YVU410,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
-		{ .format = DRM_FORMAT_YUV411,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
-		{ .format = DRM_FORMAT_YVU411,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
-		{ .format = DRM_FORMAT_YUV420,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 2 },
-		{ .format = DRM_FORMAT_YVU420,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 2 },
-		{ .format = DRM_FORMAT_YUV422,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_YVU422,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_YUV444,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_YVU444,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_NV12,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
-		{ .format = DRM_FORMAT_NV21,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
-		{ .format = DRM_FORMAT_NV16,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_NV61,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_NV24,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_NV42,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 1, .vsub = 1 },
-		{ .format = DRM_FORMAT_YUYV,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_YVYU,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_UYVY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_VYUY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
-		{ .format = DRM_FORMAT_AYUV,		.depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+		{ .format = DRM_FORMAT_C8,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGB332,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGR233,		.depth = 8,  .num_planes = 1, .cpp = { 1, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XRGB4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XBGR4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBX4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRX4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ARGB4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ABGR4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBA4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRA4444,	.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XRGB1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XBGR1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBX5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRX5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ARGB1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ABGR1555,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBA5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRA5551,	.depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGB565,		.depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGR565,		.depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGB888,		.depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGR888,		.depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XRGB8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XBGR8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBX8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRX8888,	.depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGB565_A8,	.depth = 24, .num_planes = 2, .cpp = { 2, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGR565_A8,	.depth = 24, .num_planes = 2, .cpp = { 2, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XRGB2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XBGR2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBX1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRX1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ARGB2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ABGR2101010,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBA1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRA1010102,	.depth = 30, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ARGB8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_ABGR8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBA8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRA8888,	.depth = 32, .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGB888_A8,	.depth = 32, .num_planes = 2, .cpp = { 3, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGR888_A8,	.depth = 32, .num_planes = 2, .cpp = { 3, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XRGB8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XBGR8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_RGBX8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_BGRX8888_A8,	.depth = 32, .num_planes = 2, .cpp = { 4, 1, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YUV410,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 4, .vsub = 4, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YVU410,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 4, .vsub = 4, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YUV411,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 4, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YVU411,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 4, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YUV420,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 2, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YVU420,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 2, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YUV422,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YVU422,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YUV444,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YVU444,		.depth = 0,  .num_planes = 3, .cpp = { 1, 1, 1 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_NV12,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 2, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_NV21,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 2, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_NV16,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_NV61,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_NV24,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_NV42,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YUYV,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_YVYU,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_UYVY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_VYUY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_AYUV,		.depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
 	};
 
 	unsigned int i;
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 6942e84..0202d19 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -36,16 +36,25 @@ struct drm_mode_fb_cmd2;
  *	use in new code and set to 0 for new formats.
  * @num_planes: Number of color planes (1 to 3)
  * @cpp: Number of bytes per pixel (per plane)
+ * @cpp_scale: { numerator, denominator }. Scaling factor for
+ *	non 8bit aligned formats. For instance, { 10, 8 } can be used for
+ *	10 bit component / pixel formats.
  * @hsub: Horizontal chroma subsampling factor
  * @vsub: Vertical chroma subsampling factor
+ * @padding_scale: { numerator, denominator }. Scaling factor for
+ *	padding. This can be used for formats with padding bits after
+ *	multiple pixels / components. For instance, if there are 2 bit
+ *	padding after 3 10bit components, the value should be { 32, 30 }.
  */
 struct drm_format_info {
 	u32 format;
 	u8 depth;
 	u8 num_planes;
 	u8 cpp[3];
+	u8 cpp_scale[2];
 	u8 hsub;
 	u8 vsub;
+	u8 padding_scale[2];
 };
 
 /**
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Hyun Kwon]

From: Jeffrey Mouroux <jmouroux@xilinx.com>

The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
support video memory formats that are not represented in the
current DRM fourcc library.  This patch adds those missing
fourcc codes.

Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
---
 include/uapi/drm/drm_fourcc.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3ad838d..83806d5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -112,6 +112,13 @@ extern "C" {
 #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
 
 #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0] Cr:Cb:Y little endian */
+#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /* [31:0] x:Cr:Cb:Y 8:8:8:8 little endian */
+#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0') /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
+
+/* Grey scale */
+#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit packed greyscale Y:Y:Y:Y 8:8:8:8 */
+#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /* 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
 
 /*
  * 2 plane RGB + A
@@ -140,6 +147,8 @@ extern "C" {
 #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
 #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
+#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 */
 
 /*
  * 3 plane YCbCr
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm: fourcc: Update DRM Framework with new fourcc codes

[Hyun Kwon]

From: Jeffrey Mouroux <jmouroux@xilinx.com>

New fourcc codes have been added to support new YUV semi-planar
and packed formats (including greyscale) needed by new Xilinx
Video IP.  This patch includes recognition of these new formats
in the DRM framework library functions.

Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.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 52afb5e..70342b3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -168,11 +168,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
 		{ .format = DRM_FORMAT_NV61,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
 		{ .format = DRM_FORMAT_NV24,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
 		{ .format = DRM_FORMAT_NV42,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XV15,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 10, 8 }, .hsub = 2, .vsub = 2,  .padding_scale = { 32, 30 } },
+		{ .format = DRM_FORMAT_XV20,		.depth = 0,  .num_planes = 2, .cpp = { 1, 2, 0 }, .cpp_scale = { 10, 8 }, .hsub = 2, .vsub = 1,  .padding_scale = { 32, 30 } },
 		{ .format = DRM_FORMAT_YUYV,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
 		{ .format = DRM_FORMAT_YVYU,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
 		{ .format = DRM_FORMAT_UYVY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
 		{ .format = DRM_FORMAT_VYUY,		.depth = 0,  .num_planes = 1, .cpp = { 2, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 2, .vsub = 1, .padding_scale = { 1, 1 } },
 		{ .format = DRM_FORMAT_AYUV,		.depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1, .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_VUY888,		.depth = 0,  .num_planes = 1, .cpp = { 3, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1,  .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XVUY8888,	.depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1,  .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_XVUY2101010,	.depth = 0,  .num_planes = 1, .cpp = { 4, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1,  .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_Y8,		.depth = 0,  .num_planes = 1, .cpp = { 1, 0, 0 }, .cpp_scale = { 1, 1 }, .hsub = 1, .vsub = 1,  .padding_scale = { 1, 1 } },
+		{ .format = DRM_FORMAT_Y10,		.depth = 0,  .num_planes = 1, .cpp = { 1, 0, 0 }, .cpp_scale = { 10, 8 }, .hsub = 1, .vsub = 1,  .padding_scale = { 32, 30 } },
 	};
 
 	unsigned int i;
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Daniel Vetter]

On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
> Hi,
> 
> This series is to add new drm formats needed by some Xilinx IPs.
> Some formats have unique characteristics such as pixels not being
> byte-aligned. For instance, some 10bit formats have 2bit padding
> after every 3-10bit components:
> 
> 	32b[0]:	10b comp0 - 10b comp1 - 10b comp2 - 2b padding
> 	32b[1]:	10b comp3 - 10b comp4 - 10b comp5 - 2b padding
> 	...
> 
> To model this, additional information is added to struct drm_format_info.
> The patch has been tested with downstream drivers as well as the downstream
> user space component (ex, modified modetest).
> 
> Thanks,
> hyun
> 
> Jeffrey Mouroux (2):
>   uapi: drm: New fourcc codes needed by Xilinx Video IP
>   drm: fourcc: Update DRM Framework with new fourcc codes
> 
> Satish Kumar Nagireddy (1):
>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info

We need the driver for this.
-Daniel

> 
>  drivers/gpu/drm/drm_fourcc.c  | 143 ++++++++++++++++++++++--------------------
>  include/drm/drm_fourcc.h      |   9 +++
>  include/uapi/drm/drm_fourcc.h |   9 +++
>  3 files changed, 93 insertions(+), 68 deletions(-)
> 
> -- 
> 2.7.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Ville Syrjälä]

On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> From: Jeffrey Mouroux <jmouroux@xilinx.com>
> 
> The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> support video memory formats that are not represented in the
> current DRM fourcc library.  This patch adds those missing
> fourcc codes.
> 
> Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
> Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3ad838d..83806d5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -112,6 +112,13 @@ extern "C" {
>  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>  
>  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0] Cr:Cb:Y little endian */
> +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /* [31:0] x:Cr:Cb:Y 8:8:8:8 little endian */
> +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0') /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> +
> +/* Grey scale */
> +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit packed greyscale Y:Y:Y:Y 8:8:8:8 */
> +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /* 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */

These don't make sense to me. What does it even mean to have Y
replicated three or four times for each pixel?

>  
>  /*
>   * 2 plane RGB + A
> @@ -140,6 +147,8 @@ extern "C" {
>  #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> +#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 */

Huh. Where are the Cb:Cr in that 2:10:10:10 layout?

Better docs please.

>  
>  /*
>   * 3 plane YCbCr
> -- 
> 2.7.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Emil Velikov]

On 28 November 2017 at 11:09, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
>> Hi,
>>
>> This series is to add new drm formats needed by some Xilinx IPs.
>> Some formats have unique characteristics such as pixels not being
>> byte-aligned. For instance, some 10bit formats have 2bit padding
>> after every 3-10bit components:
>>
>>       32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
>>       32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
>>       ...
>>
>> To model this, additional information is added to struct drm_format_info.
>> The patch has been tested with downstream drivers as well as the downstream
>> user space component (ex, modified modetest).
>>
>> Thanks,
>> hyun
>>
>> Jeffrey Mouroux (2):
>>   uapi: drm: New fourcc codes needed by Xilinx Video IP
>>   drm: fourcc: Update DRM Framework with new fourcc codes
>>
>> Satish Kumar Nagireddy (1):
>>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
>
> We need the driver for this.

To elaborate this in different light:
Without an upstream user (both kernel and userspace) this will be in a
perpetual broken state.
If the Xilinx DRM driver is still far off, one could update any of the
existing drivers - say i915 :-P

HTH
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Hyun Kwon]

> -----Original Message-----
> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> Sent: Tuesday, November 28, 2017 6:44 AM
> To: Hyun Kwon <hyunk@xilinx.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>; Jani Nikula
> <jani.nikula@linux.intel.com>; Sean Paul <seanpaul@chromium.org>; David
> Airlie <airlied@linux.ie>; dri-devel@lists.freedesktop.org;
> monstr@monstr.eu; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Satish Kumar Nagireddy
> <SATISHNA@xilinx.com>; Jeff Mouroux <jmouroux@xilinx.com>
> Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx
> Video IP
> 
> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > From: Jeffrey Mouroux <jmouroux@xilinx.com>
> >
> > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > support video memory formats that are not represented in the
> > current DRM fourcc library.  This patch adds those missing
> > fourcc codes.
> >
> > Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
> > Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > ---
> >  include/uapi/drm/drm_fourcc.h | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > index 3ad838d..83806d5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -112,6 +112,13 @@ extern "C" {
> >  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y')
> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >
> >  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V')
> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0]
> Cr:Cb:Y little endian */
> > +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /* [31:0]
> x:Cr:Cb:Y 8:8:8:8 little endian */
> > +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0')
> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > +
> > +/* Grey scale */
> > +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /*
> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> 
> These don't make sense to me. What does it even mean to have Y
> replicated three or four times for each pixel?

Each pixel has one Y component. The comment is to describe how components are stored in 32bit, but I agree it's confusing. Will describe better.

> 
> >
> >  /*
> >   * 2 plane RGB + A
> > @@ -140,6 +147,8 @@ extern "C" {
> >  #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1')
> /* 2x1 subsampled Cb:Cr plane */
> >  #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4')
> /* non-subsampled Cr:Cb plane */
> >  #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2')
> /* non-subsampled Cb:Cr plane */
> > +#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 */
> 
> Huh. Where are the Cb:Cr in that 2:10:10:10 layout?
> 
> Better docs please.

Sure. Will add more details on how components are laid out.

Thanks,
-hyun

> 
> >
> >  /*
> >   * 3 plane YCbCr
> > --
> > 2.7.4
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Ville Syrjälä
> Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Hyun Kwon]

> -----Original Message-----
> From: Emil Velikov [mailto:emil.l.velikov@gmail.com]
> Sent: Tuesday, November 28, 2017 7:02 AM
> To: Daniel Vetter <daniel@ffwll.ch>
> Cc: Hyun Kwon <hyunk@xilinx.com>; monstr@monstr.eu; David Airlie
> <airlied@linux.ie>; ML dri-devel <dri-devel@lists.freedesktop.org>; Daniel
> Vetter <daniel.vetter@intel.com>; Jeff Mouroux <jmouroux@xilinx.com>;
> Satish Kumar Nagireddy <SATISHNA@xilinx.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>
> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
> 
> On 28 November 2017 at 11:09, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
> >> Hi,
> >>
> >> This series is to add new drm formats needed by some Xilinx IPs.
> >> Some formats have unique characteristics such as pixels not being
> >> byte-aligned. For instance, some 10bit formats have 2bit padding
> >> after every 3-10bit components:
> >>
> >>       32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
> >>       32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
> >>       ...
> >>
> >> To model this, additional information is added to struct
> drm_format_info.
> >> The patch has been tested with downstream drivers as well as the
> downstream
> >> user space component (ex, modified modetest).
> >>
> >> Thanks,
> >> hyun
> >>
> >> Jeffrey Mouroux (2):
> >>   uapi: drm: New fourcc codes needed by Xilinx Video IP
> >>   drm: fourcc: Update DRM Framework with new fourcc codes
> >>
> >> Satish Kumar Nagireddy (1):
> >>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
> >
> > We need the driver for this.
> 
> To elaborate this in different light:
> Without an upstream user (both kernel and userspace) this will be in a
> perpetual broken state.
> If the Xilinx DRM driver is still far off, one could update any of the
> existing drivers - say i915 :-P

Fair enough. This patch will have to wait until any client code can be upstreamed along with.

Thanks,
-hyun

> 
> HTH
> Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Emil Velikov]

On 28 November 2017 at 17:26, Hyun Kwon <hyunk@xilinx.com> wrote:
>
>
>> -----Original Message-----
>> From: Emil Velikov [mailto:emil.l.velikov@gmail.com]
>> Sent: Tuesday, November 28, 2017 7:02 AM
>> To: Daniel Vetter <daniel@ffwll.ch>
>> Cc: Hyun Kwon <hyunk@xilinx.com>; monstr@monstr.eu; David Airlie
>> <airlied@linux.ie>; ML dri-devel <dri-devel@lists.freedesktop.org>; Daniel
>> Vetter <daniel.vetter@intel.com>; Jeff Mouroux <jmouroux@xilinx.com>;
>> Satish Kumar Nagireddy <SATISHNA@xilinx.com>; Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com>
>> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
>>
>> On 28 November 2017 at 11:09, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
>> >> Hi,
>> >>
>> >> This series is to add new drm formats needed by some Xilinx IPs.
>> >> Some formats have unique characteristics such as pixels not being
>> >> byte-aligned. For instance, some 10bit formats have 2bit padding
>> >> after every 3-10bit components:
>> >>
>> >>       32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
>> >>       32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
>> >>       ...
>> >>
>> >> To model this, additional information is added to struct
>> drm_format_info.
>> >> The patch has been tested with downstream drivers as well as the
>> downstream
>> >> user space component (ex, modified modetest).
>> >>
>> >> Thanks,
>> >> hyun
>> >>
>> >> Jeffrey Mouroux (2):
>> >>   uapi: drm: New fourcc codes needed by Xilinx Video IP
>> >>   drm: fourcc: Update DRM Framework with new fourcc codes
>> >>
>> >> Satish Kumar Nagireddy (1):
>> >>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
>> >
>> > We need the driver for this.
>>
>> To elaborate this in different light:
>> Without an upstream user (both kernel and userspace) this will be in a
>> perpetual broken state.
>> If the Xilinx DRM driver is still far off, one could update any of the
>> existing drivers - say i915 :-P
>
> Fair enough. This patch will have to wait until any client code can be upstreamed along with.
>
Humble suggestion: try to upstream the basic functionality of your
driver as early as possible.
DRM evolves rapidly, so any lingering work will require serious work
to rebase and ensure it works.

Quick skim at the Xilinx repository shows that initial work was done
as back as 2013 [2] :-\

-Emil
[1] https://github.com/Xilinx/linux-xlnx
[2] https://github.com/Xilinx/linux-xlnx/commit/aa76be1358005c42fadb2c7e9ac58a71a141dd7b
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs

[Hyun Kwon]

> -----Original Message-----
> From: Emil Velikov [mailto:emil.l.velikov@gmail.com]
> Sent: Tuesday, November 28, 2017 9:38 AM
> To: Hyun Kwon <hyunk@xilinx.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>; monstr@monstr.eu; David Airlie
> <airlied@linux.ie>; ML dri-devel <dri-devel@lists.freedesktop.org>; Daniel
> Vetter <daniel.vetter@intel.com>; Jeff Mouroux <jmouroux@xilinx.com>; Satish
> Kumar Nagireddy <SATISHNA@xilinx.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>
> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
> 
> On 28 November 2017 at 17:26, Hyun Kwon <hyunk@xilinx.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Emil Velikov [mailto:emil.l.velikov@gmail.com]
> >> Sent: Tuesday, November 28, 2017 7:02 AM
> >> To: Daniel Vetter <daniel@ffwll.ch>
> >> Cc: Hyun Kwon <hyunk@xilinx.com>; monstr@monstr.eu; David Airlie
> >> <airlied@linux.ie>; ML dri-devel <dri-devel@lists.freedesktop.org>; Daniel
> >> Vetter <daniel.vetter@intel.com>; Jeff Mouroux <jmouroux@xilinx.com>;
> >> Satish Kumar Nagireddy <SATISHNA@xilinx.com>; Laurent Pinchart
> >> <laurent.pinchart@ideasonboard.com>
> >> Subject: Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs
> >>
> >> On 28 November 2017 at 11:09, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> > On Mon, Nov 27, 2017 at 06:27:30PM -0800, Hyun Kwon wrote:
> >> >> Hi,
> >> >>
> >> >> This series is to add new drm formats needed by some Xilinx IPs.
> >> >> Some formats have unique characteristics such as pixels not being
> >> >> byte-aligned. For instance, some 10bit formats have 2bit padding
> >> >> after every 3-10bit components:
> >> >>
> >> >>       32b[0]: 10b comp0 - 10b comp1 - 10b comp2 - 2b padding
> >> >>       32b[1]: 10b comp3 - 10b comp4 - 10b comp5 - 2b padding
> >> >>       ...
> >> >>
> >> >> To model this, additional information is added to struct
> >> drm_format_info.
> >> >> The patch has been tested with downstream drivers as well as the
> >> downstream
> >> >> user space component (ex, modified modetest).
> >> >>
> >> >> Thanks,
> >> >> hyun
> >> >>
> >> >> Jeffrey Mouroux (2):
> >> >>   uapi: drm: New fourcc codes needed by Xilinx Video IP
> >> >>   drm: fourcc: Update DRM Framework with new fourcc codes
> >> >>
> >> >> Satish Kumar Nagireddy (1):
> >> >>   drm: drm_fourcc: Add scaling and padding factor to drm_format_info
> >> >
> >> > We need the driver for this.
> >>
> >> To elaborate this in different light:
> >> Without an upstream user (both kernel and userspace) this will be in a
> >> perpetual broken state.
> >> If the Xilinx DRM driver is still far off, one could update any of the
> >> existing drivers - say i915 :-P
> >
> > Fair enough. This patch will have to wait until any client code can be
> upstreamed along with.
> >
> Humble suggestion: try to upstream the basic functionality of your
> driver as early as possible.
> DRM evolves rapidly, so any lingering work will require serious work
> to rebase and ensure it works.
> 
> Quick skim at the Xilinx repository shows that initial work was done
> as back as 2013 [2] :-\

Thanks for the suggestion, and I agree. Xilinx has more downstream stuff than what you can see from that repo.

Thanks,
-hyun

> 
> -Emil
> [1] https://github.com/Xilinx/linux-xlnx
> [2] https://github.com/Xilinx/linux-
> xlnx/commit/aa76be1358005c42fadb2c7e9ac58a71a141dd7b
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Ville Syrjälä]

On Tue, Nov 28, 2017 at 05:25:46PM +0000, Hyun Kwon wrote:
> 
> 
> > -----Original Message-----
> > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> > Sent: Tuesday, November 28, 2017 6:44 AM
> > To: Hyun Kwon <hyunk@xilinx.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>; Jani Nikula
> > <jani.nikula@linux.intel.com>; Sean Paul <seanpaul@chromium.org>; David
> > Airlie <airlied@linux.ie>; dri-devel@lists.freedesktop.org;
> > monstr@monstr.eu; Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com>; Satish Kumar Nagireddy
> > <SATISHNA@xilinx.com>; Jeff Mouroux <jmouroux@xilinx.com>
> > Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx
> > Video IP
> > 
> > On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > > From: Jeffrey Mouroux <jmouroux@xilinx.com>
> > >
> > > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > > support video memory formats that are not represented in the
> > > current DRM fourcc library.  This patch adds those missing
> > > fourcc codes.
> > >
> > > Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
> > > Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > > ---
> > >  include/uapi/drm/drm_fourcc.h | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> > b/include/uapi/drm/drm_fourcc.h
> > > index 3ad838d..83806d5 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -112,6 +112,13 @@ extern "C" {
> > >  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y')
> > /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > >
> > >  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V')
> > /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0]
> > Cr:Cb:Y little endian */
> > > +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /* [31:0]
> > x:Cr:Cb:Y 8:8:8:8 little endian */
> > > +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0')
> > /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > > +
> > > +/* Grey scale */
> > > +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> > packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > > +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /*
> > 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> > 
> > These don't make sense to me. What does it even mean to have Y
> > replicated three or four times for each pixel?
> 
> Each pixel has one Y component. The comment is to describe how components are stored in 32bit, but I agree it's confusing. Will describe better.

For the 8 bit Y format you should then define it as 8 bits. Unless of
course it really is defined as a 32bit word containing 4 pixels. The
10 bit case would be even funky since there would have to be two
bits of padding after every 3 pixels.

So are these really defined as 32 bit wits 3 or 4 pixels and potentially
a few bits of extra padding packed into each word? That seems rather
nuts to me because you can't even byte address each pixel.

I think such crazyness has no business living right next to the
sane formats, hence we should put all these into their own little
section of the header, and the names should somehow reflect that
they are in fact "special".

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Hyun Kwon]

> -----Original Message-----
> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> Sent: Tuesday, November 28, 2017 10:12 AM
> To: Hyun Kwon <hyunk@xilinx.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>; Jani Nikula
> <jani.nikula@linux.intel.com>; Sean Paul <seanpaul@chromium.org>; David
> Airlie <airlied@linux.ie>; dri-devel@lists.freedesktop.org; monstr@monstr.eu;
> Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Satish Kumar
> Nagireddy <SATISHNA@xilinx.com>; Jeff Mouroux <jmouroux@xilinx.com>
> Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP
> 
> On Tue, Nov 28, 2017 at 05:25:46PM +0000, Hyun Kwon wrote:
> >
> >
> > > -----Original Message-----
> > > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> > > Sent: Tuesday, November 28, 2017 6:44 AM
> > > To: Hyun Kwon <hyunk@xilinx.com>
> > > Cc: Daniel Vetter <daniel.vetter@intel.com>; Jani Nikula
> > > <jani.nikula@linux.intel.com>; Sean Paul <seanpaul@chromium.org>; David
> > > Airlie <airlied@linux.ie>; dri-devel@lists.freedesktop.org;
> > > monstr@monstr.eu; Laurent Pinchart
> > > <laurent.pinchart@ideasonboard.com>; Satish Kumar Nagireddy
> > > <SATISHNA@xilinx.com>; Jeff Mouroux <jmouroux@xilinx.com>
> > > Subject: Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx
> > > Video IP
> > >
> > > On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > > > From: Jeffrey Mouroux <jmouroux@xilinx.com>
> > > >
> > > > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > > > support video memory formats that are not represented in the
> > > > current DRM fourcc library.  This patch adds those missing
> > > > fourcc codes.
> > > >
> > > > Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
> > > > Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > > > ---
> > > >  include/uapi/drm/drm_fourcc.h | 9 +++++++++
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > b/include/uapi/drm/drm_fourcc.h
> > > > index 3ad838d..83806d5 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -112,6 +112,13 @@ extern "C" {
> > > >  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y')
> > > /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > > >
> > > >  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V')
> > > /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > > +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0]
> > > Cr:Cb:Y little endian */
> > > > +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /*
> [31:0]
> > > x:Cr:Cb:Y 8:8:8:8 little endian */
> > > > +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0')
> > > /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > > > +
> > > > +/* Grey scale */
> > > > +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /*
> 8-bit
> > > packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > > > +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /*
> > > 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> > >
> > > These don't make sense to me. What does it even mean to have Y
> > > replicated three or four times for each pixel?
> >
> > Each pixel has one Y component. The comment is to describe how
> components are stored in 32bit, but I agree it's confusing. Will describe better.
> 
> For the 8 bit Y format you should then define it as 8 bits. Unless of
> course it really is defined as a 32bit word containing 4 pixels. The
> 10 bit case would be even funky since there would have to be two
> bits of padding after every 3 pixels.
> 
> So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> a few bits of extra padding packed into each word? That seems rather
> nuts to me because you can't even byte address each pixel.
> 
> I think such crazyness has no business living right next to the
> sane formats, hence we should put all these into their own little
> section of the header, and the names should somehow reflect that
> they are in fact "special".

Make sense to have a separate section for this kind of formats. Repeating the cover letter message for more details:

---
This series is to add new drm formats needed by some Xilinx IPs.
Some formats have unique characteristics such as pixels not being
byte-aligned. For instance, some 10bit formats have 2bit padding
after every 3-10bit components:

	32b[0]:	10b comp0 - 10b comp1 - 10b comp2 - 2b padding
	32b[1]:	10b comp3 - 10b comp4 - 10b comp5 - 2b padding
	...

To model this, additional information is added to struct drm_format_info.
The patch has been tested with downstream drivers as well as the downstream
user space component (ex, modified modetest).
---

Thanks,
-hyun

> 
> --
> Ville Syrjälä
> Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info

[Laurent Pinchart]

Hi Hyun,

Thank you for the patch.

On Tuesday, 28 November 2017 04:27:31 EET Hyun Kwon wrote:
> From: Satish Kumar Nagireddy <satish.nagireddy.nagireddy@xilinx.com>
> 
> 'cpp_scale' can be used as a multiplying factor to calculate
> bytes per component based on color format.
> For eg. scaling factor of YUV420 8 bit format is 1
>         so multiplying factor is 1 (8/8)
>         scaling factor of YUV420 10 bit format is 1.25 (10/8)
> 
> 'padding_scale' can be used as a multiplying factor to calculate
> actual width of video according to color format.
> For eg. padding factor of YUV420 8 bit format: 8 bits per 1 component
>         no padding bits here, so multiplying factor is 1
>         padding factor of YUV422 10 bit format: 32 bits per 3 components
>         each component is 10 bit and the factor is 32/30
> 
> Signed-off-by: Satish Kumar Nagireddy <satishna@xilinx.com>
> Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> ---
>  drivers/gpu/drm/drm_fourcc.c | 136 ++++++++++++++++++----------------------
>  include/drm/drm_fourcc.h     |   9 +++
>  2 files changed, 77 insertions(+), 68 deletions(-)

[snip]

> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 6942e84..0202d19 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -36,16 +36,25 @@ struct drm_mode_fb_cmd2;
>   *	use in new code and set to 0 for new formats.
>   * @num_planes: Number of color planes (1 to 3)
>   * @cpp: Number of bytes per pixel (per plane)
> + * @cpp_scale: { numerator, denominator }. Scaling factor for
> + *	non 8bit aligned formats. For instance, { 10, 8 } can be used for
> + *	10 bit component / pixel formats.

Stupid question, wouldn't it be better to replace cpp with a number of bits 
per pixel then ? Or possibly supplement it if we need both. A scaling factor 
seems difficult to use.

>   * @hsub: Horizontal chroma subsampling factor
>   * @vsub: Vertical chroma subsampling factor
> + * @padding_scale: { numerator, denominator }. Scaling factor for
> + *	padding. This can be used for formats with padding bits after
> + *	multiple pixels / components. For instance, if there are 2 bit
> + *	padding after 3 10bit components, the value should be { 32, 30 }.

Similarly, why don't you instead specify the number of padding bits directly ?

>   */
>  struct drm_format_info {
>  	u32 format;
>  	u8 depth;
>  	u8 num_planes;
>  	u8 cpp[3];
> +	u8 cpp_scale[2];
>  	u8 hsub;
>  	u8 vsub;
> +	u8 padding_scale[2];
>  };
> 
>  /**


-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Laurent Pinchart]

Hi Ville,

On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> On Tue, Nov 28, 2017 at 05:25:46PM +0000, Hyun Kwon wrote:
> > On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
> >> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> >>> From: Jeffrey Mouroux <jmouroux@xilinx.com>
> >>> 
> >>> The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> >>> support video memory formats that are not represented in the
> >>> current DRM fourcc library.  This patch adds those missing
> >>> fourcc codes.
> >>> 
> >>> Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
> >>> Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> >>> ---
> >>> 
> >>>  include/uapi/drm/drm_fourcc.h | 9 +++++++++
> >>>  1 file changed, 9 insertions(+)
> >>> 
> >>> diff --git a/include/uapi/drm/drm_fourcc.h
> >>> b/include/uapi/drm/drm_fourcc.h
> >>> index 3ad838d..83806d5 100644
> >>> --- a/include/uapi/drm/drm_fourcc.h
> >>> +++ b/include/uapi/drm/drm_fourcc.h
> >>> @@ -112,6 +112,13 @@ extern "C" {
> >>> 
> >>>  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y')
> >>> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >>>  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V')
> >>> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> >>> +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0]
> >>> Cr:Cb:Y little endian */
> >>> +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /* [31:0]
> >>> x:Cr:Cb:Y 8:8:8:8 little endian */
> >>> +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0')
> >>> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> >>> +
> >>> +/* Grey scale */
> >>> +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> >>> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> >>> +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /*
> >>> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> >> 
> >> These don't make sense to me. What does it even mean to have Y
> >> replicated three or four times for each pixel?
> > 
> > Each pixel has one Y component. The comment is to describe how components
> > are stored in 32bit, but I agree it's confusing. Will describe better.
> For the 8 bit Y format you should then define it as 8 bits. Unless of
> course it really is defined as a 32bit word containing 4 pixels. The
> 10 bit case would be even funky since there would have to be two
> bits of padding after every 3 pixels.
> 
> So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> a few bits of extra padding packed into each word? That seems rather
> nuts to me because you can't even byte address each pixel.
> 
> I think such crazyness has no business living right next to the
> sane formats, hence we should put all these into their own little
> section of the header, and the names should somehow reflect that
> they are in fact "special".

Thee Y8 format isn't special as it's just a plain 8-bit format. The Y10 format 
is indeed not byte-addressable, but don't be too fast to dismiss it as crazy, 
this kind of format is pretty common outside of the desktop graphics world. 
There are even 10-bit formats with 3 components where the 8 LSBs of each 
component are stored in three bytes, and the 2 MSBs are grouped in a fourth 
byte with 2 bits of padding (or possibly with LSB and MSB switched, I can't 
remember right now).

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Ville Syrjälä]

On Mon, Dec 11, 2017 at 04:08:07PM +0200, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> > On Tue, Nov 28, 2017 at 05:25:46PM +0000, Hyun Kwon wrote:
> > > On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
> > >> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > >>> From: Jeffrey Mouroux <jmouroux@xilinx.com>
> > >>> 
> > >>> The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > >>> support video memory formats that are not represented in the
> > >>> current DRM fourcc library.  This patch adds those missing
> > >>> fourcc codes.
> > >>> 
> > >>> Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
> > >>> Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > >>> ---
> > >>> 
> > >>>  include/uapi/drm/drm_fourcc.h | 9 +++++++++
> > >>>  1 file changed, 9 insertions(+)
> > >>> 
> > >>> diff --git a/include/uapi/drm/drm_fourcc.h
> > >>> b/include/uapi/drm/drm_fourcc.h
> > >>> index 3ad838d..83806d5 100644
> > >>> --- a/include/uapi/drm/drm_fourcc.h
> > >>> +++ b/include/uapi/drm/drm_fourcc.h
> > >>> @@ -112,6 +112,13 @@ extern "C" {
> > >>> 
> > >>>  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y')
> > >>> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > >>>  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V')
> > >>> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > >>> +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0]
> > >>> Cr:Cb:Y little endian */
> > >>> +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /* [31:0]
> > >>> x:Cr:Cb:Y 8:8:8:8 little endian */
> > >>> +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0')
> > >>> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > >>> +
> > >>> +/* Grey scale */
> > >>> +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> > >>> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > >>> +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /*
> > >>> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> > >> 
> > >> These don't make sense to me. What does it even mean to have Y
> > >> replicated three or four times for each pixel?
> > > 
> > > Each pixel has one Y component. The comment is to describe how components
> > > are stored in 32bit, but I agree it's confusing. Will describe better.
> > For the 8 bit Y format you should then define it as 8 bits. Unless of
> > course it really is defined as a 32bit word containing 4 pixels. The
> > 10 bit case would be even funky since there would have to be two
> > bits of padding after every 3 pixels.
> > 
> > So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> > a few bits of extra padding packed into each word? That seems rather
> > nuts to me because you can't even byte address each pixel.
> > 
> > I think such crazyness has no business living right next to the
> > sane formats, hence we should put all these into their own little
> > section of the header, and the names should somehow reflect that
> > they are in fact "special".
> 
> Thee Y8 format isn't special as it's just a plain 8-bit format.

Is it? The patch made it out to be something else perhaps. Impossible
to judge without reading the relevant xilinx docs I suppose.

> The Y10 format 
> is indeed not byte-addressable, but don't be too fast to dismiss it as crazy, 
> this kind of format is pretty common outside of the desktop graphics world. 
> There are even 10-bit formats with 3 components where the 8 LSBs of each 
> component are stored in three bytes, and the 2 MSBs are grouped in a fourth 
> byte with 2 bits of padding (or possibly with LSB and MSB switched, I can't 
> remember right now).

So you're saying the formats in this patch aren't quite as crazy as some
other formats out there? ;)

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Laurent Pinchart]

Hi Ville,

On Monday, 11 December 2017 16:24:32 EET Ville Syrjälä wrote:
> On Mon, Dec 11, 2017 at 04:08:07PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> >> On Tue, Nov 28, 2017 at 05:25:46PM +0000, Hyun Kwon wrote:
> >>> On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
> >>>> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> >>>>> From: Jeffrey Mouroux <jmouroux@xilinx.com>
> >>>>> 
> >>>>> The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> >>>>> support video memory formats that are not represented in the
> >>>>> current DRM fourcc library.  This patch adds those missing
> >>>>> fourcc codes.
> >>>>> 
> >>>>> Signed-off-by: Jeffrey Mouroux <jmouroux@xilinx.com>
> >>>>> Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> >>>>> ---
> >>>>> 
> >>>>>  include/uapi/drm/drm_fourcc.h | 9 +++++++++
> >>>>>  1 file changed, 9 insertions(+)
> >>>>> 
> >>>>> diff --git a/include/uapi/drm/drm_fourcc.h
> >>>>> b/include/uapi/drm/drm_fourcc.h
> >>>>> index 3ad838d..83806d5 100644
> >>>>> --- a/include/uapi/drm/drm_fourcc.h
> >>>>> +++ b/include/uapi/drm/drm_fourcc.h
> >>>>> @@ -112,6 +112,13 @@ extern "C" {
> >>>>> 
> >>>>>  #define DRM_FORMAT_VYUY		fourcc_code('V', 'Y', 'U', 'Y')
> >>>>> 
> >>>>> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >>>>> 
> >>>>>  #define DRM_FORMAT_AYUV		fourcc_code('A', 'Y', 'U', 'V')
> >>>>> 
> >>>>> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> >>>>> +#define DRM_FORMAT_VUY888	fourcc_code('V', 'U', '2', '4') /* [23:0]
> >>>>> Cr:Cb:Y little endian */
> >>>>> +#define DRM_FORMAT_XVUY8888	fourcc_code('X', 'V', '2', '4') /*
> >>>>> [31:0]
> >>>>> x:Cr:Cb:Y 8:8:8:8 little endian */
> >>>>> +#define DRM_FORMAT_XVUY2101010	fourcc_code('X', 'V', '3', '0')
> >>>>> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> >>>>> +
> >>>>> +/* Grey scale */
> >>>>> +#define DRM_FORMAT_Y8		fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> >>>>> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> >>>>> +#define DRM_FORMAT_Y10		fourcc_code('Y', '1', '0', ' ') /*
> >>>>> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> >>>> 
> >>>> These don't make sense to me. What does it even mean to have Y
> >>>> replicated three or four times for each pixel?
> >>> 
> >>> Each pixel has one Y component. The comment is to describe how
> >>> components are stored in 32bit, but I agree it's confusing. Will
> >>> describe better.
> >> 
> >> For the 8 bit Y format you should then define it as 8 bits. Unless of
> >> course it really is defined as a 32bit word containing 4 pixels. The
> >> 10 bit case would be even funky since there would have to be two
> >> bits of padding after every 3 pixels.
> >> 
> >> So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> >> a few bits of extra padding packed into each word? That seems rather
> >> nuts to me because you can't even byte address each pixel.
> >> 
> >> I think such crazyness has no business living right next to the
> >> sane formats, hence we should put all these into their own little
> >> section of the header, and the names should somehow reflect that
> >> they are in fact "special".
> > 
> > Thee Y8 format isn't special as it's just a plain 8-bit format.
> 
> Is it? The patch made it out to be something else perhaps. Impossible
> to judge without reading the relevant xilinx docs I suppose.

What I meant is that despite the presentation of this 8-bit greyscale format 
as storing 4 pixels in 32 bits, it's really an 8-bit greyscale format without 
anything special.

> > The Y10 format is indeed not byte-addressable, but don't be too fast to
> > dismiss it as crazy, this kind of format is pretty common outside of the
> > desktop graphics world. There are even 10-bit formats with 3 components
> > where the 8 LSBs of each component are stored in three bytes, and the 2
> > MSBs are grouped in a fourth byte with 2 bits of padding (or possibly with
> > LSB and MSB switched, I can't remember right now).
> 
> So you're saying the formats in this patch aren't quite as crazy as some
> other formats out there? ;)

Don't get me started about some of the GPU tiled formats ;-) The graphics and 
camera industries have taken different paths because they have different 
needs, but both have invented their share of convoluted formats that are not 
always easy to support.

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info

[Hyun Kwon]

Hi Laurent,

Thanks for the comment.

> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
> Sent: Monday, December 11, 2017 6:02 AM
> To: Hyun Kwon <hyunk@xilinx.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>; Jani Nikula
> <jani.nikula@linux.intel.com>; Sean Paul <seanpaul@chromium.org>; David
> Airlie <airlied@linux.ie>; dri-devel@lists.freedesktop.org;
> monstr@monstr.eu; Jeff Mouroux <jmouroux@xilinx.com>; Satish Kumar
> Nagireddy <SATISHNA@xilinx.com>; Satish Kumar Nagireddy
> <SATISHNA@xilinx.com>
> Subject: Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor
> to drm_format_info
> 
> Hi Hyun,
> 
> Thank you for the patch.
> 
> On Tuesday, 28 November 2017 04:27:31 EET Hyun Kwon wrote:
> > From: Satish Kumar Nagireddy <satish.nagireddy.nagireddy@xilinx.com>
> >
> > 'cpp_scale' can be used as a multiplying factor to calculate
> > bytes per component based on color format.
> > For eg. scaling factor of YUV420 8 bit format is 1
> >         so multiplying factor is 1 (8/8)
> >         scaling factor of YUV420 10 bit format is 1.25 (10/8)
> >
> > 'padding_scale' can be used as a multiplying factor to calculate
> > actual width of video according to color format.
> > For eg. padding factor of YUV420 8 bit format: 8 bits per 1 component
> >         no padding bits here, so multiplying factor is 1
> >         padding factor of YUV422 10 bit format: 32 bits per 3 components
> >         each component is 10 bit and the factor is 32/30
> >
> > Signed-off-by: Satish Kumar Nagireddy <satishna@xilinx.com>
> > Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 136 ++++++++++++++++++-----------------
> -----
> >  include/drm/drm_fourcc.h     |   9 +++
> >  2 files changed, 77 insertions(+), 68 deletions(-)
> 
> [snip]
> 
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index 6942e84..0202d19 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -36,16 +36,25 @@ struct drm_mode_fb_cmd2;
> >   *	use in new code and set to 0 for new formats.
> >   * @num_planes: Number of color planes (1 to 3)
> >   * @cpp: Number of bytes per pixel (per plane)
> > + * @cpp_scale: { numerator, denominator }. Scaling factor for
> > + *	non 8bit aligned formats. For instance, { 10, 8 } can be used for
> > + *	10 bit component / pixel formats.
> 
> Stupid question, wouldn't it be better to replace cpp with a number of bits
> per pixel then ? Or possibly supplement it if we need both. A scaling factor
> seems difficult to use.

Bits per pixel would work. I was hesitant to modify other drivers, but I can still make it that way.

> 
> >   * @hsub: Horizontal chroma subsampling factor
> >   * @vsub: Vertical chroma subsampling factor
> > + * @padding_scale: { numerator, denominator }. Scaling factor for
> > + *	padding. This can be used for formats with padding bits after
> > + *	multiple pixels / components. For instance, if there are 2 bit
> > + *	padding after 3 10bit components, the value should be { 32, 30 }.
> 
> Similarly, why don't you instead specify the number of padding bits directly ?

I don't see how to model this with the number of padding bits. There can be arbitrary number of padding bits in every arbitrary number of components with arbitrary bpp. Just for example, 2 bits padding after 3 - 10bit components or 8 bit padding after 4 - 14bit components.

The currently expected usage is:

	bytes_per_line = width * info->cpp[i] * info->cpp_scale[0] / info->cpp_scale[1] * info->padding_scale[0] / info->padding_scale[1];

cpp_scale[] can be replaced with bpp / 8 per your suggestion. Let me know if you see any better way.

Thanks,
-hyun

> 
> >   */
> >  struct drm_format_info {
> >  	u32 format;
> >  	u8 depth;
> >  	u8 num_planes;
> >  	u8 cpp[3];
> > +	u8 cpp_scale[2];
> >  	u8 hsub;
> >  	u8 vsub;
> > +	u8 padding_scale[2];
> >  };
> >
> >  /**
> 
> 
> --
> Regards,
> 
> Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info

[Ville Syrjälä]

On Wed, Dec 13, 2017 at 01:48:28AM +0000, Hyun Kwon wrote:
> Hi Laurent,
> 
> Thanks for the comment.
> 
> > -----Original Message-----
> > From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
> > Sent: Monday, December 11, 2017 6:02 AM
> > To: Hyun Kwon <hyunk@xilinx.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>; Jani Nikula
> > <jani.nikula@linux.intel.com>; Sean Paul <seanpaul@chromium.org>; David
> > Airlie <airlied@linux.ie>; dri-devel@lists.freedesktop.org;
> > monstr@monstr.eu; Jeff Mouroux <jmouroux@xilinx.com>; Satish Kumar
> > Nagireddy <SATISHNA@xilinx.com>; Satish Kumar Nagireddy
> > <SATISHNA@xilinx.com>
> > Subject: Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor
> > to drm_format_info
> > 
> > Hi Hyun,
> > 
> > Thank you for the patch.
> > 
> > On Tuesday, 28 November 2017 04:27:31 EET Hyun Kwon wrote:
> > > From: Satish Kumar Nagireddy <satish.nagireddy.nagireddy@xilinx.com>
> > >
> > > 'cpp_scale' can be used as a multiplying factor to calculate
> > > bytes per component based on color format.
> > > For eg. scaling factor of YUV420 8 bit format is 1
> > >         so multiplying factor is 1 (8/8)
> > >         scaling factor of YUV420 10 bit format is 1.25 (10/8)
> > >
> > > 'padding_scale' can be used as a multiplying factor to calculate
> > > actual width of video according to color format.
> > > For eg. padding factor of YUV420 8 bit format: 8 bits per 1 component
> > >         no padding bits here, so multiplying factor is 1
> > >         padding factor of YUV422 10 bit format: 32 bits per 3 components
> > >         each component is 10 bit and the factor is 32/30
> > >
> > > Signed-off-by: Satish Kumar Nagireddy <satishna@xilinx.com>
> > > Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > > ---
> > >  drivers/gpu/drm/drm_fourcc.c | 136 ++++++++++++++++++-----------------
> > -----
> > >  include/drm/drm_fourcc.h     |   9 +++
> > >  2 files changed, 77 insertions(+), 68 deletions(-)
> > 
> > [snip]
> > 
> > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > index 6942e84..0202d19 100644
> > > --- a/include/drm/drm_fourcc.h
> > > +++ b/include/drm/drm_fourcc.h
> > > @@ -36,16 +36,25 @@ struct drm_mode_fb_cmd2;
> > >   *	use in new code and set to 0 for new formats.
> > >   * @num_planes: Number of color planes (1 to 3)
> > >   * @cpp: Number of bytes per pixel (per plane)
> > > + * @cpp_scale: { numerator, denominator }. Scaling factor for
> > > + *	non 8bit aligned formats. For instance, { 10, 8 } can be used for
> > > + *	10 bit component / pixel formats.
> > 
> > Stupid question, wouldn't it be better to replace cpp with a number of bits
> > per pixel then ? Or possibly supplement it if we need both. A scaling factor
> > seems difficult to use.
> 
> Bits per pixel would work. I was hesitant to modify other drivers, but I can still make it that way.
> 
> > 
> > >   * @hsub: Horizontal chroma subsampling factor
> > >   * @vsub: Vertical chroma subsampling factor
> > > + * @padding_scale: { numerator, denominator }. Scaling factor for
> > > + *	padding. This can be used for formats with padding bits after
> > > + *	multiple pixels / components. For instance, if there are 2 bit
> > > + *	padding after 3 10bit components, the value should be { 32, 30 }.
> > 
> > Similarly, why don't you instead specify the number of padding bits directly ?
> 
> I don't see how to model this with the number of padding bits. There can be arbitrary number of padding bits in every arbitrary number of components with arbitrary bpp. Just for example, 2 bits padding after 3 - 10bit components or 8 bit padding after 4 - 14bit components.

These formats seem to have quite a bit in common with the packed YUV
formats. So I'm thinking we probably want some kind of "bytes per
macropixel" thing, and something that tells us how many pixels are
in each macropixel.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel