kernel/linux.git/drivers/gpu/drm/drm_fourcc.c, branch v4.20.17

drm: Fix htmldocs warnings in drm_fourcc.c

2018-11-07T21:16:27+00:00

Add a description for dev and remove the excess one for native. Fixes the following warnings: ../drivers/gpu/drm/drm_fourcc.c:112: warning: Function parameter or member 'dev' not described in 'drm_driver_legacy_fb_format' ../drivers/gpu/drm/drm_fourcc.c:112: warning: Excess function parameter 'native' description in 'drm_driver_legacy_fb_format' Fixes: 059b5eb5d955 ("drm: move native byte order quirk to new drm_driver_legacy_fb_format function") Cc: Gerd Hoffmann Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20181107205546.216088-1-sean@poorly.run

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

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux into drm-misc-next

2017-03-23T07:15:55+00:00

Resync with drm-next, I have a patch which currently can't be applied because drm-misc-next lacked the latest drm/i915 code. Signed-off-by: Daniel Vetter

drm: Add mode_config .get_format_info() hook

2017-03-22T17:45:00+00:00

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: add RGB formats with separate alpha plane

2017-03-15T14:42:30+00:00

Some hardware can read the alpha components separately and then conditionally fetch color components only for non-zero alpha values. This patch adds fourcc definitions for two-plane RGB formats with an 8-bit alpha channel on a second plane. Signed-off-by: Philipp Zabel

drm: move allocation out of drm_get_format_name()

2016-11-12T13:19:38+00:00

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