kernel/linux.git/include/drm/drm_mode_config.h, branch v6.3

drm/connector: Add TV standard property

2022-11-24T11:42:39+00:00

The TV mode property has been around for a while now to select and get the current TV mode output on an analog TV connector. Despite that property name being generic, its content isn't and has been driver-specific which makes it hard to build any generic behaviour on top of it, both in kernel and user-space. Let's create a new enum tv norm property, that can contain any of the analog TV standards currently supported by kernel drivers. Each driver can then pass in a bitmask of the modes it supports, and the property creation function will filter out the modes not supported. We'll then be able to phase out the older tv mode property. Tested-by: Mateusz Kwiatkowski Acked-in-principle-or-something-like-that-by: Daniel Vetter Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-5-256dad125326@cerno.tech Signed-off-by: Maxime Ripard

drm/connector: Rename legacy TV property

2022-11-24T11:42:39+00:00

The current tv_mode has driver-specific values that don't allow to easily share code using it, either at the userspace or kernel level. Since we're going to introduce a new, generic, property that fit the same purpose, let's rename this one to legacy_tv_mode to make it obvious we should move away from it. Acked-by: Thomas Zimmermann Reviewed-by: Lyude Paul # nouveau Reviewed-by: Noralf Trønnes Tested-by: Mateusz Kwiatkowski Acked-in-principle-or-something-like-that-by: Daniel Vetter Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-2-256dad125326@cerno.tech Signed-off-by: Maxime Ripard

drm: Remove drm_mode_config::fb_base

2022-10-20T01:46:16+00:00

The fb_base in struct drm_mode_config has been unused for a long time. Some drivers set it and some don't leading to a very confusing state where the variable can't be relied upon, because there's no indication as to which driver sets it and which doesn't. The only usage of fb_base is internal to two drivers so instead of trying to force it into all the drivers to get it into a coherent state completely remove it. Signed-off-by: Zack Rusin Reviewed-by: Laurent Pinchart Reviewed-by: Thomas Zimmermann Acked-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20221019024401.394617-1-zack@kde.org

drm: remove allow_fb_modifiers

2022-01-31T20:45:24+00:00

The allow_fb_modifiers flag is unnecessary since it has been replaced with fb_modifiers_not_supported flag. v3: - change the order as follows: 1. add fb_modifiers_not_supported flag 2. add default modifiers 3. remove allow_fb_modifiers flag v5: - keep a sanity check in plane init func Signed-off-by: Tomohito Esaki Reviewed-by: Andy Shevchenko Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220128060836.11216-4-etom@igel.co.jp

drm: introduce fb_modifiers_not_supported flag in mode_config

2022-01-31T20:45:23+00:00

If only linear modifier is advertised, since there are many drivers that only linear supported, the DRM core should handle this rather than open-coding in every driver. However, there are legacy drivers such as radeon that do not support modifiers but infer the actual layout of the underlying buffer. Therefore, a new flag fb_modifiers_not_supported is introduced for these legacy drivers, and allow_fb_modifiers is replaced with this new flag. v3: - change the order as follows: 1. add fb_modifiers_not_supported flag 2. add default modifiers 3. remove allow_fb_modifiers flag - add a conditional disable in amdgpu_dm_plane_init() v4: - modify kernel docs v5: - modify kernel docs Signed-off-by: Tomohito Esaki Acked-by: Harry Wentland Reviewed-by: Andy Shevchenko Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220128060836.11216-2-etom@igel.co.jp

drm: Clarify semantics of struct drm_mode_config.{min, max}_{width, height}

2021-11-11T11:06:58+00:00

Add additional information on the semantics of the size fields in struct drm_mode_config. Also add a TODO to review all driver for correct usage of these fields. Signed-off-by: Thomas Zimmermann Acked-by: Noralf Trønnes Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-10-tzimmermann@suse.de

drm: Improve the output_poll_changed description

2021-09-03T09:45:45+00:00

this callback was used by drm_kms_helper_hotplug_event() V2: (Thanks for Daniel's suggestions) - remove the FIXME below.since with the drm_client - infrastructure and the generic fbdev emulation we've - resolved this all very neatly now. V3: Add comments that This hook is deprecated - new implementation methods instead of this hook v4: used by drm_kms_helper_hotplug_event() - drm_fb_helper_hotplug_changed() is not found instead by drm_kms_helper_hotplug_event() Signed-off-by: ZhiJie.Zhang Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210903032402.11935-1-zhangzhijie@loongson.cn

drm/modifiers: Enforce consistency between the cap an IN_FORMATS

2021-05-12T09:31:29+00:00

It's very confusing for userspace to have to deal with inconsistencies here, and some drivers screwed this up a bit. Most just ommitted the format list when they meant to say that only linear modifier is allowed, but some also meant that only implied modifiers are acceptable (because actually none of the planes registered supported modifiers). Now that this is all done consistently across all drivers, document the rules and enforce it in the drm core. v2: - Make the capability a link (Simon) - Note that all is lost before 5.1. v3: - Use drm_WARN_ON (Lyude) Acked-by: Pekka Paalanen Reviewed-by: Emil Velikov Reviewed-by: Lyude Paul Acked-by: Maxime Ripard Cc: Simon Ser Reviewed-by: Lucas Stach Cc: Pekka Paalanen Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210506132343.2873699-1-daniel.vetter@ffwll.ch

drm/fb_helper: Support framebuffers in I/O memory

2020-11-09T08:20:00+00:00

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. Read and write operations are implemented internally by DRM's fbdev helper. For drivers that employ a shadow buffer, fbdev's blit function retrieves the framebuffer address as struct dma_buf_map, and uses dma_buf_map interfaces to access the buffer. The bochs driver on sparc64 uses a workaround to flag the framebuffer as I/O memory and avoid a HW exception. With the introduction of struct dma_buf_map, this is not required any longer. The patch removes the rsp code from both, bochs and fbdev. v7: * use min_t(size_t,) (kernel test robot) * return the number of bytes read/written, if any (fbdev testcase) v5: * implement fb_read/fb_write internally (Daniel, Sam) v4: * move dma_buf_map changes into separate patch (Daniel) * TODO list: comment on fbdev updates (Daniel) Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Reviewed-by: Sam Ravnborg Tested-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-11-tzimmermann@suse.de

drm/doc: Document that modifiers are always required for fb

2020-09-23T15:54:03+00:00

Even for legacy userspace, since otherwise GETFB2 is broken and if you switch between modifier-less and modifier-aware compositors, smooth transitions break. Also it's just best practice to make sure modifiers are invariant for a given drm_fb, and that a modifier-aware kms drivers only has one place to store them, ignoring any old implicit bo flags or whatever else might float around. Motivated by some irc discussion with Bas about amdgpu modifier support. Acked-by: Bas Nieuwenhuizen Acked-by: Simon Ser Acked-by: Daniel Stone Acked-by: Pekka Paalanen Fixes: 455e00f1412f ("drm: Add getfb2 ioctl") Cc: Daniel Stone Cc: Juston Li Cc: Daniel Vetter Cc: Ville Syrjälä Cc: Bas Nieuwenhuizen Cc: Marek Olšák Cc: "Wentland, Harry" Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200917164721.2038541-1-daniel.vetter@ffwll.ch