* [PATCH 0/3] Adding new drm formats needed by Xilinx IPs @ 2017-11-28 2:27 Hyun Kwon 2017-11-28 2:27 ` [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info Hyun Kwon ` (3 more replies) 0 siblings, 4 replies; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 2:27 UTC (permalink / raw) To: Daniel Vetter, Jani Nikula, Sean Paul, David Airlie, dri-devel Cc: Michal Simek, Hyun Kwon, Laurent Pinchart, Satish Kumar Nagireddy, Jeffrey Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info 2017-11-28 2:27 [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Hyun Kwon @ 2017-11-28 2:27 ` Hyun Kwon 2017-12-11 14:02 ` Laurent Pinchart 2017-11-28 2:27 ` [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP Hyun Kwon ` (2 subsequent siblings) 3 siblings, 1 reply; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 2:27 UTC (permalink / raw) To: Daniel Vetter, Jani Nikula, Sean Paul, David Airlie, dri-devel Cc: Michal Simek, Hyun Kwon, Laurent Pinchart, Satish Kumar Nagireddy, Satish Kumar Nagireddy, Jeffrey Mouroux 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info 2017-11-28 2:27 ` [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info Hyun Kwon @ 2017-12-11 14:02 ` Laurent Pinchart 2017-12-13 1:48 ` Hyun Kwon 0 siblings, 1 reply; 19+ messages in thread From: Laurent Pinchart @ 2017-12-11 14:02 UTC (permalink / raw) To: Hyun Kwon Cc: Michal Simek, David Airlie, dri-devel, Daniel Vetter, Satish Kumar Nagireddy, Satish Kumar Nagireddy, Jeffrey Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info 2017-12-11 14:02 ` Laurent Pinchart @ 2017-12-13 1:48 ` Hyun Kwon 2017-12-13 13:33 ` Ville Syrjälä 0 siblings, 1 reply; 19+ messages in thread From: Hyun Kwon @ 2017-12-13 1:48 UTC (permalink / raw) To: Laurent Pinchart Cc: monstr, David Airlie, dri-devel, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info 2017-12-13 1:48 ` Hyun Kwon @ 2017-12-13 13:33 ` Ville Syrjälä 0 siblings, 0 replies; 19+ messages in thread From: Ville Syrjälä @ 2017-12-13 13:33 UTC (permalink / raw) To: Hyun Kwon Cc: monstr, David Airlie, dri-devel, Laurent Pinchart, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-11-28 2:27 [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Hyun Kwon 2017-11-28 2:27 ` [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info Hyun Kwon @ 2017-11-28 2:27 ` Hyun Kwon 2017-11-28 14:43 ` Ville Syrjälä 2017-11-28 2:27 ` [PATCH 3/3] drm: fourcc: Update DRM Framework with new fourcc codes Hyun Kwon 2017-11-28 11:09 ` [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Daniel Vetter 3 siblings, 1 reply; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 2:27 UTC (permalink / raw) To: Daniel Vetter, Jani Nikula, Sean Paul, David Airlie, dri-devel Cc: Michal Simek, Hyun Kwon, Laurent Pinchart, Satish Kumar Nagireddy, Jeffrey Mouroux 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-11-28 2:27 ` [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP Hyun Kwon @ 2017-11-28 14:43 ` Ville Syrjälä 2017-11-28 17:25 ` Hyun Kwon 0 siblings, 1 reply; 19+ messages in thread From: Ville Syrjälä @ 2017-11-28 14:43 UTC (permalink / raw) To: Hyun Kwon Cc: Michal Simek, David Airlie, dri-devel, Daniel Vetter, Jeffrey Mouroux, Satish Kumar Nagireddy, Laurent Pinchart 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-11-28 14:43 ` Ville Syrjälä @ 2017-11-28 17:25 ` Hyun Kwon 2017-11-28 18:11 ` Ville Syrjälä 0 siblings, 1 reply; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 17:25 UTC (permalink / raw) To: Ville Syrjälä Cc: monstr, David Airlie, dri-devel, Daniel Vetter, Jeff Mouroux, Satish Kumar Nagireddy, Laurent Pinchart > -----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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-11-28 17:25 ` Hyun Kwon @ 2017-11-28 18:11 ` Ville Syrjälä 2017-11-28 18:33 ` Hyun Kwon 2017-12-11 14:08 ` Laurent Pinchart 0 siblings, 2 replies; 19+ messages in thread From: Ville Syrjälä @ 2017-11-28 18:11 UTC (permalink / raw) To: Hyun Kwon Cc: monstr, David Airlie, dri-devel, Daniel Vetter, Jeff Mouroux, Satish Kumar Nagireddy, Laurent Pinchart 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-11-28 18:11 ` Ville Syrjälä @ 2017-11-28 18:33 ` Hyun Kwon 2017-12-11 14:08 ` Laurent Pinchart 1 sibling, 0 replies; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 18:33 UTC (permalink / raw) To: Ville Syrjälä Cc: monstr, David Airlie, dri-devel, Daniel Vetter, Jeff Mouroux, Satish Kumar Nagireddy, Laurent Pinchart > -----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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-11-28 18:11 ` Ville Syrjälä 2017-11-28 18:33 ` Hyun Kwon @ 2017-12-11 14:08 ` Laurent Pinchart 2017-12-11 14:24 ` Ville Syrjälä 1 sibling, 1 reply; 19+ messages in thread From: Laurent Pinchart @ 2017-12-11 14:08 UTC (permalink / raw) To: Ville Syrjälä Cc: monstr, David Airlie, dri-devel, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-12-11 14:08 ` Laurent Pinchart @ 2017-12-11 14:24 ` Ville Syrjälä 2017-12-11 14:58 ` Laurent Pinchart 0 siblings, 1 reply; 19+ messages in thread From: Ville Syrjälä @ 2017-12-11 14:24 UTC (permalink / raw) To: Laurent Pinchart Cc: monstr, David Airlie, dri-devel, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP 2017-12-11 14:24 ` Ville Syrjälä @ 2017-12-11 14:58 ` Laurent Pinchart 0 siblings, 0 replies; 19+ messages in thread From: Laurent Pinchart @ 2017-12-11 14:58 UTC (permalink / raw) To: Ville Syrjälä Cc: monstr, David Airlie, dri-devel, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 3/3] drm: fourcc: Update DRM Framework with new fourcc codes 2017-11-28 2:27 [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Hyun Kwon 2017-11-28 2:27 ` [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info Hyun Kwon 2017-11-28 2:27 ` [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP Hyun Kwon @ 2017-11-28 2:27 ` Hyun Kwon 2017-11-28 11:09 ` [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Daniel Vetter 3 siblings, 0 replies; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 2:27 UTC (permalink / raw) To: Daniel Vetter, Jani Nikula, Sean Paul, David Airlie, dri-devel Cc: Michal Simek, Hyun Kwon, Laurent Pinchart, Satish Kumar Nagireddy, Jeffrey Mouroux 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs 2017-11-28 2:27 [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Hyun Kwon ` (2 preceding siblings ...) 2017-11-28 2:27 ` [PATCH 3/3] drm: fourcc: Update DRM Framework with new fourcc codes Hyun Kwon @ 2017-11-28 11:09 ` Daniel Vetter 2017-11-28 15:02 ` Emil Velikov 3 siblings, 1 reply; 19+ messages in thread From: Daniel Vetter @ 2017-11-28 11:09 UTC (permalink / raw) To: Hyun Kwon Cc: Michal Simek, David Airlie, dri-devel, Daniel Vetter, Jeffrey Mouroux, Satish Kumar Nagireddy, Laurent Pinchart 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs 2017-11-28 11:09 ` [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Daniel Vetter @ 2017-11-28 15:02 ` Emil Velikov 2017-11-28 17:26 ` Hyun Kwon 0 siblings, 1 reply; 19+ messages in thread From: Emil Velikov @ 2017-11-28 15:02 UTC (permalink / raw) To: Daniel Vetter Cc: Michal Simek, Hyun Kwon, David Airlie, ML dri-devel, Laurent Pinchart, Daniel Vetter, Satish Kumar Nagireddy, Jeffrey Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs 2017-11-28 15:02 ` Emil Velikov @ 2017-11-28 17:26 ` Hyun Kwon 2017-11-28 17:38 ` Emil Velikov 0 siblings, 1 reply; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 17:26 UTC (permalink / raw) To: Emil Velikov, Daniel Vetter Cc: monstr, David Airlie, ML dri-devel, Laurent Pinchart, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux > -----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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs 2017-11-28 17:26 ` Hyun Kwon @ 2017-11-28 17:38 ` Emil Velikov 2017-11-28 18:09 ` Hyun Kwon 0 siblings, 1 reply; 19+ messages in thread From: Emil Velikov @ 2017-11-28 17:38 UTC (permalink / raw) To: Hyun Kwon Cc: monstr, David Airlie, ML dri-devel, Laurent Pinchart, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 0/3] Adding new drm formats needed by Xilinx IPs 2017-11-28 17:38 ` Emil Velikov @ 2017-11-28 18:09 ` Hyun Kwon 0 siblings, 0 replies; 19+ messages in thread From: Hyun Kwon @ 2017-11-28 18:09 UTC (permalink / raw) To: Emil Velikov Cc: monstr, David Airlie, ML dri-devel, Laurent Pinchart, Daniel Vetter, Satish Kumar Nagireddy, Jeff Mouroux > -----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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-12-13 13:33 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-28 2:27 [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Hyun Kwon 2017-11-28 2:27 ` [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info Hyun Kwon 2017-12-11 14:02 ` Laurent Pinchart 2017-12-13 1:48 ` Hyun Kwon 2017-12-13 13:33 ` Ville Syrjälä 2017-11-28 2:27 ` [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP Hyun Kwon 2017-11-28 14:43 ` Ville Syrjälä 2017-11-28 17:25 ` Hyun Kwon 2017-11-28 18:11 ` Ville Syrjälä 2017-11-28 18:33 ` Hyun Kwon 2017-12-11 14:08 ` Laurent Pinchart 2017-12-11 14:24 ` Ville Syrjälä 2017-12-11 14:58 ` Laurent Pinchart 2017-11-28 2:27 ` [PATCH 3/3] drm: fourcc: Update DRM Framework with new fourcc codes Hyun Kwon 2017-11-28 11:09 ` [PATCH 0/3] Adding new drm formats needed by Xilinx IPs Daniel Vetter 2017-11-28 15:02 ` Emil Velikov 2017-11-28 17:26 ` Hyun Kwon 2017-11-28 17:38 ` Emil Velikov 2017-11-28 18:09 ` Hyun Kwon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.