linux-toradex.git/include/drm/drm_mode_config.h, branch v5.19-rc1

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

Merge drm/drm-next into drm-misc-next

2020-08-12T18:42:08+00:00

Backmerging drm-next into drm-misc-next for nouveau and panel updates.
Resolves a conflict between ttm and nouveau, where struct ttm_mem_res got
renamed to struct ttm_resource.

Signed-off-by: Thomas Zimmermann

drm: report dp downstream port type as a subconnector property

2020-08-11T12:06:04+00:00

Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.

The 'subconnector' property is already utilized for DVI-I and TV-out for
reporting connector subtype.

The initial motivation for this feature came from i2c test [1].
It is supposed to be skipped on VGA connectors, but it cannot
detect VGA over DP and fails instead.

v2:
 - Ville: utilized drm_dp_is_branch()
 - Ville: implement DP 1.0 downstream type info
 - Replaced create_dp_properties with add_dp_subconnector_property
 - Added dp_set_subconnector_property helper

v4:
 - Ville: add DP1.0 best assumption about subconnector
 - Ville: assume DVI is DVI-D
 - Ville: reuse Writeback enum value for Virtual subconnector
 - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort

v5: rebase

v6:
 - Jani Nikula: renamed a function name
 - Jani Nikula: addressed the issues with documentation

[1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097

Cc: Ville Syrjälä 
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jeevan B 
Signed-off-by: Oleg Vasilev 
Reviewed-by: Emil Velikov 
Signed-off-by: Maarten Lankhorst 
Link: https://patchwork.freedesktop.org/patch/msgid/1587732655-17544-1-git-send-email-jeevan.b@intel.com

Merge tag 'v5.8' into drm-next

2020-08-11T01:58:31+00:00

I need to backmerge 5.8 as I've got a bunch of fixes sitting
on an rc7 base that I want to land.

Signed-off-by: Dave Airlie