kernel/linux.git/drivers/gpu/drm/drm_atomic_helper.c, branch v5.10.264

drm: Add valid clones check

2025-06-04T12:37:06+00:00

[ Upstream commit 41b4b11da02157c7474caf41d56baae0e941d01a ] Check that all encoders attached to a given CRTC are valid possible_clones of each other. Signed-off-by: Jessica Zhang Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20241216-concurrent-wb-v4-3-fe220297a7f0@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin

drm: allow encoder mode_set even when connectors change for crtc

2025-05-02T05:40:50+00:00

[ Upstream commit 7e182cb4f5567f53417b762ec0d679f0b6f0039d ] In certain use-cases, a CRTC could switch between two encoders and because the mode being programmed on the CRTC remains the same during this switch, the CRTC's mode_changed remains false. In such cases, the encoder's mode_set also gets skipped. Skipping mode_set on the encoder for such cases could cause an issue because even though the same CRTC mode was being used, the encoder type could have changed like the CRTC could have switched from a real time encoder to a writeback encoder OR vice-versa. Allow encoder's mode_set to happen even when connectors changed on a CRTC and not just when the mode changed. Signed-off-by: Abhinav Kumar Signed-off-by: Jessica Zhang Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20241211-abhinavk-modeset-fix-v3-1-0de4bf3e7c32@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin

drm/atomic: Allow vblank-enabled + self-refresh "disable"

2023-07-27T06:44:29+00:00

commit 9d0e3cac3517942a6e00eeecfe583a98715edb16 upstream. The self-refresh helper framework overloads "disable" to sometimes mean "go into self-refresh mode," and this mode activates automatically (e.g., after some period of unchanging display output). In such cases, the display pipe is still considered "on", and user-space is not aware that we went into self-refresh mode. Thus, users may expect that vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work properly. However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave vblank enabled. Add a different expectation: that CRTCs *should* leave vblank enabled when going into self-refresh. This patch is preparation for another patch -- "drm/rockchip: vop: Leave vblank enabled in self-refresh" -- which resolves conflicts between the above self-refresh behavior and the API tests in IGT's kms_vblank test module. == Some alternatives discussed: == It's likely that on many display controllers, vblank interrupts will turn off when the CRTC is disabled, and so in some cases, self-refresh may not support vblank. To support such cases, we might consider additions to the generic helpers such that we fire vblank events based on a timer. However, there is currently only one driver using the common self-refresh helpers (i.e., rockchip), and at least as of commit bed030a49f3e ("drm/rockchip: Don't fully disable vop on self refresh"), the CRTC hardware is powered enough to continue to generate vblank interrupts. So we chose the simpler option of leaving vblank interrupts enabled. We can reevaluate this decision and perhaps augment the helpers if/when we gain a second driver that has different requirements. v3: * include discussion summary v2: * add 'ret != 0' warning case for self-refresh * describe failing test case and relation to drm/rockchip patch better Cc: # dependency for "drm/rockchip: vop: Leave # vblank enabled in self-refresh" Signed-off-by: Brian Norris Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20230109171809.v3.1.I3904f697863649eb1be540ecca147a66e42bfad7@changeid Signed-off-by: Greg Kroah-Hartman

drm/atomic: Force bridge self-refresh-exit on CRTC switch

2022-06-14T16:32:46+00:00

commit e54a4424925a27ed94dff046db3ce5caf4b1e748 upstream. It's possible to change which CRTC is in use for a given connector/encoder/bridge while we're in self-refresh without fully disabling the connector/encoder/bridge along the way. This can confuse the bridge encoder/bridge, because (a) it needs to track the SR state (trying to perform "active" operations while the panel is still in SR can be Bad(TM)); and (b) it tracks the SR state via the CRTC state (and after the switch, the previous SR state is lost). Thus, we need to either somehow carry the self-refresh state over to the new CRTC, or else force an encoder/bridge self-refresh transition during such a switch. I choose the latter, so we disable the encoder (and exit PSR) before attaching it to the new CRTC (where we can continue to assume a clean (non-self-refresh) state). This fixes PSR issues seen on Rockchip RK3399 systems with drivers/gpu/drm/bridge/analogix/analogix_dp_core.c. Change in v2: - Drop "->enable" condition; this could possibly be "->active" to reflect the intended hardware state, but it also is a little over-specific. We want to make a transition through "disabled" any time we're exiting PSR at the same time as a CRTC switch. (Thanks Liu Ying) Cc: Liu Ying Cc: Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in drivers") Signed-off-by: Brian Norris Reviewed-by: Sean Paul Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.2.Ic15a2ef69c540aee8732703103e2cff51fb9c399@changeid Signed-off-by: Greg Kroah-Hartman

drm/atomic: put state on error path

2021-01-27T10:54:55+00:00

commit 43b67309b6b2a3c08396cc9b3f83f21aa529d273 upstream. Put the state before returning error code. Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.") Signed-off-by: Pan Bian Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210119121127.84127-1-bianpan2016@163.com Signed-off-by: Greg Kroah-Hartman

drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()

2020-09-14T19:37:31+00:00

The timestamping constants have nothing to do with any legacy state so should not be updated from drm_atomic_helper_update_legacy_modeset_state(). Let's make everyone call drm_atomic_helper_calc_timestamping_constants() directly instead of relying on drm_atomic_helper_update_legacy_modeset_state() to call it. @@ expression S; @@ - drm_atomic_helper_calc_timestamping_constants(S); @@ expression D, S; @@ drm_atomic_helper_update_legacy_modeset_state(D, S); + drm_atomic_helper_calc_timestamping_constants(S); v2: Update drm_crtc_vblank_helper_get_vblank_timestamp{,_internal}() docs (Daniel) Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200907120026.6360-2-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter

drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

2020-09-14T19:36:44+00:00

Put the vblank timestamping constants update loop into its own function. It has no business living inside drm_atomic_helper_update_legacy_modeset_state() so we'll be wanting to move it out entirely. As a first step we'll still call it from drm_atomic_helper_update_legacy_modeset_state(). v2: Drop comment about 'legacy state' in the new function Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200907120026.6360-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter

Merge tag 'v5.9-rc2' into drm-misc-fixes

2020-08-25T09:00:02+00:00

Backmerge requested by Tomi for a fix to omap inconsistent locking state issue, and because we need at least v5.9-rc2 now. Signed-off-by: Maarten Lankhorst

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: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()

2020-06-23T17:53:27+00:00

When validating a mode, bridges may need to do so in the context of a display, as specified by drm_display_info. An example is the meson dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to perform clock calculations. Bridges that need the display info currently retrieve it from the drm_connector created by the bridge. This gets in the way of moving connector creation out of bridge drivers. To make this possible, pass the drm_display_info to drm_bridge_funcs .mode_valid(). Changes to the bridge drivers have been performed with the following coccinelle semantic patch and have been compile-tested. @ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .mode_valid = fn }; @ depends on rule1 @ identifier rule1.fn; identifier bridge; identifier mode; @@ enum drm_mode_status fn( struct drm_bridge *bridge, + const struct drm_display_info *info, const struct drm_display_mode *mode ) { ... } Signed-off-by: Laurent Pinchart Reviewed-by: Neil Armstrong Reviewed-by: Boris Brezillon Reviewed-by: Guido Günther # for the nwl-dsi part: Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200526011505.31884-11-laurent.pinchart+renesas@ideasonboard.com