kernel/include/drm/drm_fourcc.h, branch linux-5.1.y

drm/fourcc: Add format info helpers for checking YUV sub-sampling

2019-01-18T18:00:18Z

Display engine drivers often need to distinguish between different types of YUV sub-sampling. This introduces helpers to check for common sub-sampling ratios in their commonly-used denomination from the DRM format info. Signed-off-by: Paul Kocialkowski Reviewed-by: Maxime Ripard Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20190118145133.21281-3-paul.kocialkowski@bootlin.com

drm/fourcc: Add format info helpers for checking YUV planes disposition

2019-01-18T18:00:06Z

It is often useful to check whether the DRM format info retrieved from the DRM framebuffer matches a specific YUV planes disposition. This introduces helpers to quickly check that a provided format info matches a YUV format with a specific disposition, in commonly-used terminology. The intent of providing helpers taking the format info instead of the fourcc alone is to avoid the overhead of iterating through all formats when the whole format info structure is available. As a result, these helpers are very simple so they are made inline. Signed-off-by: Paul Kocialkowski Reviewed-by: Maxime Ripard Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20190118145133.21281-2-paul.kocialkowski@bootlin.com

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

2018-11-02T09:55:27Z

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: fourcc: Convert drm_format_info kerneldoc to in-line member documentation

2018-10-22T09:30:26Z

In-line member documentation seems to be desired way of documenting structure members. This change had been suggested by Daniel Vetter here: https://lists.freedesktop.org/archives/dri-devel/2018-October/192176.html Signed-off-by: Alexandru Gheorghe Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20181019105752.17741-2-alexandru-cosmin.gheorghe@arm.com

drm: move native byte order quirk to new drm_driver_legacy_fb_format function

2018-09-25T12:49:49Z

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: byteorder: add DRM_FORMAT_HOST_*

2018-09-06T06:40:18Z

Add fourcc variants in host byte order. With these at hand we don't need #ifdefs in drivers which support framebuffers in cpu endianess. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20180905060445.15008-3-kraxel@redhat.com

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

2018-07-18T15:56:45Z

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:47Z

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

drm: Add mode_config .get_format_info() hook

2017-03-22T17:45:00Z

Allow drivers to return a custom drm_format_info structure for special fb layouts. We'll use this for the compression control surface in i915. v2: Fix drm_get_format_info() kernel doc (Laurent) Don't pass 'dev' to the new hook (Laurent) v3: s/compresssion/compression/ (Ben) Cc: Laurent Pinchart Cc: Ben Widawsky Cc: Jason Ekstrand Signed-off-by: Ville Syrjälä Reviewed-by: Ben Widawsky Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-4-ville.syrjala@linux.intel.com

drm: move allocation out of drm_get_format_name()

2016-11-12T13:19:38Z

The function's behaviour was changed in 90844f00049e, without changing its signature, causing people to keep using it the old way without realising they were now leaking memory. Rob Clark also noticed it was also allocating GFP_KERNEL memory in atomic contexts, breaking them. Instead of having to allocate GFP_ATOMIC memory and fixing the callers to make them cleanup the memory afterwards, let's change the function's signature by having the caller take care of the memory and passing it to the function. The new parameter is a single-field struct in order to enforce the size of its buffer and help callers to correctly manage their memory. Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe") Cc: Rob Clark Cc: Christian König Acked-by: Christian König Acked-by: Rob Clark Acked-by: Sinclair Yeh (vmwgfx) Reviewed-by: Jani Nikula Suggested-by: Ville Syrjälä Signed-off-by: Eric Engestrom Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161112011309.9799-1-eric@engestrom.ch