kernel/linux.git/drivers/gpu/drm/drm_mode_object.c, branch v6.12.80

drm/mode_object: Export drm_mode_obj_find_prop_id for tests

2024-05-28T07:57:28+00:00

We'll need to use drm_mode_obj_find_prop_id() for kunit tests to make sure a given property has been properly created. Let's export it for tests only. Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-5-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard

drm: Refuse to async flip with atomic prop changes

2023-11-23T16:12:38+00:00

Given that prop changes may lead to modesetting, which would defeat the fast path of the async flip, refuse any atomic prop change for async flips in atomic API. The only exception is the framebuffer ID to flip to. Currently the only plane type supported is the primary one. Signed-off-by: André Almeida Reviewed-by: Simon Ser Signed-off-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20231122161941.320564-2-andrealmeid@igalia.com

drm/kms: log when querying an object not included in lease

2023-06-23T14:38:00+00:00

User-space may query an existing object not included in a lease. Make it easier to debug such situations by logging a debug message. Signed-off-by: Simon Ser Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20230623143514.38707-1-contact@emersion.fr

drm/object: Add drm_object_property_get_default_value() function

2022-02-25T16:55:42+00:00

Some functions to create properties (drm_plane_create_zpos_property or drm_plane_create_color_properties for example) will ask for a range of acceptable value and an initial one. This initial value is then stored in the values array for that property. Let's provide an helper to access this property. Acked-by: Daniel Vetter Reviewed-by: Laurent Pinchart Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-7-maxime@cerno.tech

drm: Fix typo in comments

2021-08-02T08:19:43+00:00

fix typo for drm v1->v2: respin with the change "iff ==> implies that" Signed-off-by: Cai Huoqing Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com

drm: fix some kernel-doc markups

2020-11-16T19:48:20+00:00

Some identifiers have different names between their prototypes and the kernel-doc markup. Others need to be fixed, as kernel-doc markups should use this format: identifier - description Signed-off-by: Mauro Carvalho Chehab Acked-by: Jani Nikula Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/12d4ca26f6843618200529ce5445063734d38c04.1605521731.git.mchehab+huawei@kernel.org

drm/modeset-lock: Take the modeset BKL for legacy drivers

2020-08-17T17:41:50+00:00

This fell off in the conversion in commit 9bcaa3fe58ab7559e71df798bcff6e0795158695 Author: Michal Orzel Date: Tue Apr 28 19:10:04 2020 +0200 drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers but it's caught by the drm_warn_on_modeset_not_all_locked() that the legacy modeset code uses. Since this is the bkl and it's unclear what's all protected, play it safe and grab it again for legacy drivers. Unfortunately this means we need to sprinkle a few more #includes around. Also we need to add the drm_device as a parameter to the _END macro. Finally remove the mute_lock() from setcrtc, since that's now done by the macro. Cc: Alex Deucher References: https://gitlab.freedesktop.org/drm/amd/-/issues/1224 Fixes: 9bcaa3fe58ab ("drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers") Cc: Michal Orzel Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.8+ Signed-off-by: Daniel Vetter Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20200814093842.3048472-1-daniel.vetter@ffwll.ch

drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers

2020-05-05T08:51:56+00:00

As suggested by the TODO list for the kernel DRM subsystem, replace the deprecated functions that take/drop modeset locks with new helpers. Signed-off-by: Michal Orzel Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1588093804-30446-1-git-send-email-michalorzel.eng@gmail.com

drm/property: Enforce more lifetime rules

2019-11-04T17:17:36+00:00

Properties can't be attached after registering, userspace would get confused (no one bothers to reprobe really). - Add kerneldoc - Enforce this with some checks. This needs a somewhat ugly check since connectors can be added later on, but we still need to attach all properties before they go public. Note that we already enforce that properties themselves are created before the entire device is registered. Unfortunately this doesn't work for drivers which have a ->load callback, see commit e0f32f78e51b9989ee89f608fd0dd10e9c230652 (tag: drm-misc-next-fixes-2019-09-18) Author: Daniel Vetter Date: Tue Sep 17 14:09:35 2019 +0200 drm/kms: Duct-tape for mode object lifetime checks for the full story. v2: Fix the superflous newline (Jani) and add commit citation to explain why we need to check for dev->registered (Thierry). Cc: Jani Nikula Cc: Rajat Jain Reviewed-by: Thierry Reding Reviewed-by: Jani Nikula Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20191023144953.28190-1-daniel.vetter@ffwll.ch

drm/kms: Duct-tape for mode object lifetime checks

2019-09-18T09:27:18+00:00

commit 4f5368b5541a902f6596558b05f5c21a9770dd32 Author: Daniel Vetter Date: Fri Jun 14 08:17:23 2019 +0200 drm/kms: Catch mode_object lifetime errors uncovered a bit a mess in dp drivers. Most drivers (from a quick look, all except i915) register all the dp stuff in their init code, which is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up, because drm_dp_aux_register tries to add a child to a device in sysfs (the connector) which doesn't even exist yet. No one seems to have cared thus far. But with the above change I also moved the setting of dev->registered after the ->load callback, in an attempt to keep old drivers from hitting any WARN_ON backtraces. But that moved radeon.ko from the "working, by accident" to "now also broken" category. Since this is a huge mess I figured a revert would be simplest. But this check has already caught issues in i915: commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0 Author: Ville Syrjälä Date: Tue Aug 20 19:16:57 2019 +0300 drm/i915: Do not create a new max_bpc prop for MST connectors Hence I'd like to retain it. Fix the radeon regression by moving the setting of dev->registered back to were it was, and stop the backtraces with an explicit check for dev->driver->load. Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The next patch will improve the kerneldoc and add a todo entry for this. Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors") Cc: Sean Paul Cc: Maarten Lankhorst Reported-by: Michel Dänzer Reviewed-by: Michel Dänzer Tested-by: Michel Dänzer Cc: Michel Dänzer Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190917120936.7501-1-daniel.vetter@ffwll.ch