linux/drivers/gpu/drm/drm_framebuffer.c, branch v4.20

drm: move quirk_addfb_prefer_xbgr_30bpp handling to drm_driver_legacy_fb_format too

2018-09-25T12:49:50Z

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: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: Differentiate the lack of an interface from invalid parameter

2018-09-14T16:29:47Z

If the ioctl is not supported on a particular piece of HW/driver combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily distinguished from both the lack of the ioctl and from a regular invalid parameter. v2: Across all the kms ioctls we had a mixture of reporting EINVAL, ENODEV and a few ENOTSUPP (most where EINVAL) for a failed drm_core_check_feature(). Update everybody to report ENOTSUPP. v3: ENOTSUPP is an internal errno! It's value (524) does not correspond to a POSIX errno, the one we want is ENOTSUP. However, uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says "ENOTSUP and EOPNOTSUPP have the same value on Linux, but according to POSIX.1 these error values should be distinct." so use EOPNOTSUPP as its equivalent. Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Ville Syrjälä Reviewed-by: Daniel Vetter #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20180913192050.24812-1-chris@chris-wilson.co.uk

drm: refuse ADDFB2 ioctl for broken bigendian drivers

2018-09-10T05:10:36Z

Drivers must set the quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() compat code work correctly on bigendian machines. If they don't they interpret pixel_format values incorrectly for bug compatibility, which in turn implies the ADDFB2 ioctl does not work correctly then. So block it to make userspace fallback to ADDFB. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20180907073213.20410-1-kraxel@redhat.com

drm: extract drm_atomic_uapi.c

2018-09-09T12:19:18Z

This leaves all the commit/check and state handling in drm_atomic.c, while pulling all the uapi glue and the huge ioctl itself into a seprate file. This seems to almost perfectly split the rather big drm_atomic.c file into 2 equal sizes. Also adjust the kerneldoc and type a very terse overview text. v2: Rebase. v3: Fix tiny typo. v4: - Fixup armada, newly converted atomic driver hooray! - Fixup msm/dpu1, newly added too. Signed-off-by: Daniel Vetter Cc: David Airlie Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Rob Clark Cc: Eric Anholt Cc: intel-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Acked-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20180905135711.28370-7-daniel.vetter@ffwll.ch

drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl

2018-09-06T07:07:41Z

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: fix drm_mode_addfb() on big endian machines.

2018-09-06T06:40:19Z

Userspace on big endian machhines typically expects the ADDFB ioctl returns a big endian framebuffer. drm_mode_addfb() will call drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_* values though, which is wrong. This patch fixes that. Drivers (both kernel and xorg) have quirks in place to deal with the broken drm_mode_addfb() behavior. Because of this we can't just change drm_mode_addfb() behavior for everybody without breaking things. Add the quirk_addfb_prefer_host_byte_order field to mode_config, so drivers can opt-in. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20180905060445.15008-5-kraxel@redhat.com

drm: do not mask out DRM_FORMAT_BIG_ENDIAN

2018-09-06T06:40:18Z

framebuffer_check() expects that drm_get_format_info() will not fail if the __drm_format_info() call was successful. That'll work only in case both are called with the same pixel_format value, so masking out the DRM_FORMAT_BIG_ENDIAN flag isn't a good idea. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20180905060445.15008-4-kraxel@redhat.com

drm: replace DRIVER_PREFER_XBGR_30BPP driver flag with mode_config quirk

2018-09-06T06:40:17Z

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

drm: Add drm_plane_mask()

2018-07-02T15:45:55Z

Add drm_plane_mask() which returns the 1< Link: https://patchwork.freedesktop.org/patch/msgid/20180626194716.12522-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi