kernel/linux.git/drivers/gpu/drm/drm_fourcc.c, branch v5.1.10

drm/fourcc: Add new P010, P016 video format

2019-02-08T21:17:08+00:00

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. P012 is a planar 4:2:0 YUV 12 bits per channel P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per channel video format. V3: Added P012 and fixed cpp for P010. V4: format definition refined per review. V5: Format comment block for each new pixel format. V6: reversed Cb/Cr order in comments. v7: reversed Cb/Cr order in comments of header files, remove the wrong part of commit message. V8: reversed V7 changes except commit message and rebased. v9: used the new properties to describe those format and rebased. Cc: Daniel Stone Cc: Ville Syrjälä Signed-off-by: Randy Li Signed-off-by: Clint Taylor Reviewed-by: Ayan Kumar Halder Reviewed-by: Neil Armstrong Reviewed-by: Daniel Vetter Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20190109195710.28501-2-ayaka@soulik.info

drm: Introduce new DRM_FORMAT_XYUV

2018-11-20T14:20:13+00:00

v5: This is YUV444 packed format same as AYUV, but without alpha, as supported by i915. v6: Removed unneeded initializer for new XYUV format. v7: Added is_yuv field initialization according to latest drm_fourcc format structure initialization changes. v8: Edited commit message to be more clear about skl+, renamed PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format doesn't support per-pixel alpha. Fixed minor code issues. v9: Moved DRM format check to proper place in intel_framebuffer_init. v10: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV8888 v11: Fixed rebase conflict, caused by added new formats to drm-tip meanwhile. Reviewed-by: Alexandru Gheorghe Signed-off-by: Stanislav Lisovskiy [vsyrjala: Removed stray tab and sorted the formats differently] Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20181109093916.25858-2-stanislav.lisovskiy@intel.com

drm/fourcc: Add fourcc for Mali linear tiled formats

2018-11-02T09:55:44+00:00

Mali-DP implements a number of tiled yuv formats which are not currently described in drm_fourcc.h. This adds those definitions and describes their memory layout by using the newly added char_per_block, block_w, block_h. Reviewed-by: Brian Starkey Reviewed-by: Daniel Vetter Signed-off-by: Alexandru Gheorghe Link: https://patchwork.freedesktop.org/patch/msgid/20181101151051.1509-3-alexandru-cosmin.gheorghe@arm.com

drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info

2018-11-02T09:55:27+00:00

For some pixel formats .cpp structure in drm_format info it's not enough to describe the peculiarities of the pixel layout, for example tiled formats or packed formats at bit level. What's implemented here is to add three new members to drm_format_info that could describe such formats: - char_per_block[3] - block_w[3] - block_h[3] char_per_block will be put in a union alongside cpp, for transparent compatibility with the existing format descriptions. Regarding, block_w and block_h they are intended to be used through their equivalent getters drm_format_info_block_width / drm_format_info_block_height, the reason of the getters is to abstract the fact that for normal formats block_w and block_h will be unset/0, but the methods will be returning 1. Additionally, convenience function drm_format_info_min_pitch had been added that computes the minimum required pitch for a given pixel format and buffer width. Using that the following drm core functions had been updated to generically handle both block and non-block formats: - drm_fb_cma_get_gem_addr: for block formats it will just return the beginning of the block. - framebuffer_check: Use the newly added drm_format_info_min_pitch. - drm_gem_fb_create_with_funcs: Use the newly added drm_format_info_min_pitch. - In places where is not expecting to handle block formats, like fbdev helpers I just added some warnings in case the block width/height are greater than 1. Changes since v3: - Add helper function for computing the minimum required pitch. - Improve/cleanup documentation Changes since v8: - Fixed build on 32bits arm architectures, with: - return DIV_ROUND_UP((u64)buffer_width * info->char_per_block[plane], + return DIV_ROUND_UP_ULL((u64)buffer_width * info->char_per_block[plane], Reviewed-by: Brian Starkey Reviewed-by: Daniel Vetter Signed-off-by: Alexandru Gheorghe Link: https://patchwork.freedesktop.org/patch/msgid/20181101170055.5433-1-alexandru-cosmin.gheorghe@arm.com

drm/doc: fix drm_driver_legacy_fb_format

2018-10-05T16:05:32+00:00

Didn't get updated in a rework of the original patch. Fixes: 059b5eb5d955 ("drm: move native byte order quirk to new drm_driver_legacy_fb_format function") Cc: Gerd Hoffmann Reviewed-by: Gerd Hoffmann Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181004202446.22905-20-daniel.vetter@ffwll.ch

drm: move quirk_addfb_prefer_xbgr_30bpp handling to drm_driver_legacy_fb_format too

2018-09-25T12:49:50+00:00

Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-7-kraxel@redhat.com

drm: move native byte order quirk to new drm_driver_legacy_fb_format function

2018-09-25T12:49:49+00:00

Turns out we need the pixel format fixup not only for the addfb ioctl, but also for fbdev emulation code. Ideally we would place it in drm_mode_legacy_fb_format(). That would create alot of churn though, and most drivers don't care because they never ever run on a big endian platform. So add a new drm_driver_legacy_fb_format() function instead which looks at the mode_config->quirk_addfb_prefer_host_byte_order flag. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-2-kraxel@redhat.com

drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl

2018-09-06T07:07:41+00:00

Since this is handling user provided bpp and depth, we need to sanity check and propagate the EINVAL back rather than assume what the insane client intended and fill the logs with DRM_ERROR. v2: Check both bpp and depth match the builtin pixel format, and introduce a canonical DRM_FORMAT_INVALID to reserve 0 against any future fourcc. v3: Mark up DRM_FORMAT_C8 as being {bpp:8, depth:8} Testcase: igt/kms_addfb_basic/legacy-format Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Ville Syrjälä Cc: Michel Dänzer Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180905153116.28924-1-chris@chris-wilson.co.uk

drm/fourcc: Add is_yuv field to drm_format_info to denote if the format is yuv

2018-07-18T15:56:45+00:00

A lot of drivers duplicate the function to check if a format is yuv or not. If we add a field (to denote whether the format is yuv or not) in the drm_format_info table, all the drivers can use this field and it will prevent duplication of similar logic. Signed-off-by: Ayan Kumar halder Reviewed-by: Ville Syrjala Link: https://patchwork.freedesktop.org/patch/msgid/1531847626-22248-1-git-send-email-ayan.halder@arm.com

drm/fourcc: Add a alpha field to drm_format_info

2018-01-29T11:07:47+00:00

There's a bunch of drivers that duplicate the same function to know if a particular format embeds an alpha component or not. Let's create a field in the drm_format_info to avoid duplicating that logic and looking up formats all the time. Cc: Eric Anholt Cc: Inki Dae Cc: Joonyoung Shim Cc: Kyungmin Park Cc: Laurent Pinchart Cc: Mark Yao Cc: Seung-Woo Kim Reviewed-by: Boris Brezillon Reviewed-by: Daniel Vetter Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/9cd9951d147ff810c1f6f68d79e7983361ed6b68.1516617243.git-series.maxime.ripard@free-electrons.com