2014-07-25 21:30:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-25 12:09:48 +01:00
|
|
|
|
2018-09-05 15:57:05 +02:00
|
|
|
|
2014-11-25 12:09:48 +01:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-06 14:53:35 +01:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-04 11:00:11 +01:00
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 09:44:01 +01:00
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-04 11:00:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-14 22:23:43 -07:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-04 11:00:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-04 11:00:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-25 07:26:45 +01:00
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-17 12:51:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-12 09:34:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-17 12:51:08 +01:00
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
2025-11-14 17:01:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
2025-09-30 12:59:24 +02:00
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:24 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:24 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:24 +02:00
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-30 12:59:51 +02:00
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:51 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:51 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:51 +02:00
|
|
|
|
|
|
|
|
|
2018-10-15 09:46:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-13 12:22:09 -02:00
|
|
|
|
2018-02-02 21:12:59 -08:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-30 12:59:18 +02:00
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:18 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:18 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-29 17:42:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-01 17:23:26 -08:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-28 13:43:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
2022-03-28 14:43:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2017-12-14 21:30:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-22 14:31:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-04 16:11:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-14 21:30:53 +01:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2025-10-14 11:31:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-22 14:31:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-14 21:30:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
2017-12-14 21:30:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-22 14:31:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-14 21:30:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-28 14:43:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-14 21:30:53 +01:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2022-03-28 14:43:02 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2022-03-28 14:43:02 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2022-03-28 14:43:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2025-09-30 12:59:54 +02:00
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:54 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:54 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-09-30 12:59:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-08 15:11:42 +02:00
|
|
|
|
2025-09-30 12:59:54 +02:00
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2023-12-14 11:09:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-14 21:30:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-02-13 15:43:20 +01:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2018-10-04 22:24:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-08 18:24:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-04 22:24:31 +02:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2020-10-23 14:39:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-30 15:03:17 -03:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
drm/atomic: Add drm_atomic_state->duplicated
Since
commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")
We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a connector is
unregistered before we attempt to restore the atomic state, something we
end up failing the atomic check that happens when trying to restore the
state during resume.
Normally this would be OK: we try our best to make sure that the atomic
state pre-suspend can be restored post-suspend, but failures at that
point usually don't cause problems. That is of course, until we
introduced the new atomic MST VCPI helpers:
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] active changed
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:123:DP-5]
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling [CONNECTOR:123:DP-5]
[drm:drm_atomic_get_private_obj_state [drm]] Added new private object 0000000025844636 state 000000009fd2899a to 000000003a13d7b8
WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O) crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video tpm acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci nvme_core xhci_hcd
CPU: 6 PID: 1070 Comm: gnome-shell Tainted: G W O 5.0.0-rc2Lyude-Test+ #1
Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f 85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 b3 a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
RSP: 0018:ffff88841235f268 EFLAGS: 00010246
RAX: ffff88841bf12ab0 RBX: ffff88841bf12aa8 RCX: 1ffff110837e2557
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffffed108246bde0
RBP: ffff88841bf12ab8 R08: ffffed1083db3c93 R09: ffffed1083db3c92
R10: ffffed1083db3c92 R11: ffff88841ed9e497 R12: ffff888419555d80
R13: ffff8883bc499100 R14: ffff88841bf12ab8 R15: 0000000000000000
FS: 00007f16fbd4cd00(0000) GS:ffff88841ed80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1687c9f000 CR3: 00000003ba3cc003 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
? __printk_safe_exit+0x10/0x10
? save_stack+0x8c/0xb0
? vprintk_func+0x96/0x1bf
? __printk_safe_exit+0x10/0x10
intel_atomic_check+0x234/0x4750 [i915]
? printk+0x9f/0xc5
? kmsg_dump_rewind_nolock+0xd9/0xd9
? _raw_spin_lock_irqsave+0xa4/0x140
? drm_atomic_check_only+0xb1/0x28b0 [drm]
? drm_dbg+0x186/0x1b0 [drm]
? drm_dev_dbg+0x200/0x200 [drm]
? intel_link_compute_m_n+0xb0/0xb0 [i915]
? drm_mode_put_tile_group+0x20/0x20 [drm]
? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
? drm_plane_check_pixel_format+0x14a/0x310 [drm]
drm_atomic_check_only+0x13c4/0x28b0 [drm]
? drm_state_info+0x220/0x220 [drm]
? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
? kasan_unpoison_shadow+0x35/0x40
drm_atomic_commit+0x3b/0x100 [drm]
drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
drm_mode_setcrtc+0x636/0x1660 [drm]
? vprintk_func+0x96/0x1bf
? drm_dev_dbg+0x200/0x200 [drm]
? drm_mode_getcrtc+0x790/0x790 [drm]
? printk+0x9f/0xc5
? mutex_unlock+0x1d/0x40
? drm_mode_addfb2+0x2e9/0x3a0 [drm]
? rcu_sync_dtor+0x2e0/0x2e0
? drm_dbg+0x186/0x1b0 [drm]
? set_page_dirty+0x271/0x4d0
drm_ioctl_kernel+0x203/0x290 [drm]
? drm_mode_getcrtc+0x790/0x790 [drm]
? drm_setversion+0x7f0/0x7f0 [drm]
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x34/0x70
drm_ioctl+0x445/0x950 [drm]
? drm_mode_getcrtc+0x790/0x790 [drm]
? drm_getunique+0x220/0x220 [drm]
? expand_files.part.10+0x920/0x920
do_vfs_ioctl+0x1a1/0x13d0
? ioctl_preallocate+0x2b0/0x2b0
? __fget_light+0x2d6/0x390
? schedule+0xd7/0x2e0
? fget_raw+0x10/0x10
? apic_timer_interrupt+0xa/0x20
? apic_timer_interrupt+0xa/0x20
? rcu_cleanup_dead_rnp+0x2c0/0x2c0
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x6f/0xb0
do_syscall_64+0x136/0x440
? syscall_return_slowpath+0x2d0/0x2d0
? do_page_fault+0x89/0x330
? __do_page_fault+0x9c0/0x9c0
? prepare_exit_to_usermode+0x188/0x200
? perf_trace_sys_enter+0x1090/0x1090
? __x64_sys_sigaltstack+0x280/0x280
? __put_user_4+0x1c/0x30
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f16ff89a09b
Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48
RSP: 002b:00007fff001232b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fff001232f0 RCX: 00007f16ff89a09b
RDX: 00007fff001232f0 RSI: 00000000c06864a2 RDI: 000000000000000b
RBP: 00007fff001232f0 R08: 0000000000000000 R09: 000055a79d484460
R10: 000055a79d44e770 R11: 0000000000000246 R12: 00000000c06864a2
R13: 000000000000000b R14: 0000000000000000 R15: 000055a79d44e770
WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
---[ end trace d536c05c13c83be2 ]---
[drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for [MST PORT:00000000f9e2b143] found in mst state 000000009fd2899a
This appears to be happening because we destroy the VCPI allocations
when disabling all connected displays while suspending, and those VCPI
allocations don't get restored on resume due to failing to restore the
atomic state.
So, fix this by introducing the suspending option to
drm_atomic_helper_duplicate_state() and use that to indicate in the
atomic state that it's being used for suspending or resuming the system,
and thus needs to be fixed up by the driver. We can then use the new
state->duplicated hook to tell update_connector_routing() in
drm_atomic_check_modeset() to allow for modesets on unregistered
connectors, which allows us to restore atomic states that contain MST
topologies that were removed after the state was duplicated and thus:
mostly fixing suspend and resume. This just leaves some issues that were
introduced with nouveau, that will be addressed next.
Changes since v3:
* Remove ->duplicated hunks that I left in the VCPI helpers by accident.
These don't need to be here, that was the supposed to be the purpose
of the last revision
Changes since v2:
* Remove the changes in this patch to the VCPI helpers, they aren't
needed anymore
Changes since v1:
* Rename suspend_or_resume to duplicated
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190202002023.29665-4-lyude@redhat.com
2019-02-01 19:20:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
2025-10-17 19:33:27 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-14 17:01:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-14 17:01:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
2023-12-14 11:09:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:13 +01:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
2023-12-14 11:09:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
2017-09-04 12:48:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-24 16:20:14 +08:00
|
|
|
|
2017-09-04 12:48:37 +02:00
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
2017-09-04 12:48:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-21 10:59:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-21 14:03:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-04 12:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-21 14:03:35 +01:00
|
|
|
|
2017-09-04 12:48:36 +02:00
|
|
|
|
2016-06-08 14:19:00 +02:00
|
|
|
|
|
|
|
|
|
2017-09-04 12:48:36 +02:00
|
|
|
|
2016-06-08 14:19:00 +02:00
|
|
|
|
|
|
|
|
|
2016-12-21 14:03:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 09:44:01 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
|
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2016-10-14 13:18:18 +01:00
|
|
|
|
2015-05-18 10:06:40 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
2025-11-14 17:01:29 -07:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-11-14 17:01:29 -07:00
|
|
|
|
2025-12-19 13:49:39 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-12-19 13:49:39 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-12-19 13:49:39 +02:00
|
|
|
|
|
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
2014-12-18 16:01:50 -05:00
|
|
|
|
2026-01-28 13:43:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2019-01-22 11:05:41 +00:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2019-01-22 11:05:41 +00:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2019-01-22 11:05:41 +00:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2019-06-11 16:51:43 -04:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2019-06-11 16:51:43 -04:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2019-06-11 16:51:43 -04:00
|
|
|
|
2025-03-13 12:59:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-11 16:51:43 -04:00
|
|
|
|
2023-03-02 22:03:04 +05:30
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2023-03-02 22:03:04 +05:30
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2023-03-02 22:03:04 +05:30
|
|
|
|
|
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
|
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
|
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-02-16 15:47:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-02 16:21:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drm/atomic: Convert __drm_atomic_get_current_plane_state() to modern accessor
The __drm_atomic_get_current_plane_state() function tries to get and
return the existing plane state, and if it doesn't exist returns the one
stored in the drm_plane->state field.
Using the current nomenclature, it tries to get the existing plane state
with an ad-hoc implementation of drm_atomic_get_existing_plane_state(),
and falls back to either the old or new plane state, depending on
whether it is called before or after drm_atomic_helper_swap_state().
The existing plane state itself is deprecated, because it also changes
when swapping states from the new state to the old state.
Fortunately for us, we can simplify things. Indeed,
__drm_atomic_get_current_plane_state() is only used in two macros:
intel_atomic_crtc_state_for_each_plane_state and
drm_atomic_crtc_state_for_each_plane_state().
The intel variant is only used through the intel_wm_compute() function
that is only ever called in intel_crtc_atomic_check().
The generic variant is more widely used, and can be found in the malidp,
msm, tegra and vc4 drivers. All of these call sites though are during
atomic_check(), so we end up in the same situation than Intel's.
Thus, we only ever use the existing state as the new state, and
plane->state is always going to be the old state. Any plane isn't
guaranteed to be part of the state though, so we can't rely on
drm_atomic_get_old_plane_state() and we still need to use plane->state.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250930-drm-no-more-existing-state-v5-4-eeb9e1287907@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-09-30 12:59:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-02 16:21:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-02 17:39:14 +02:00
|
|
|
|
2016-06-02 16:21:44 +02:00
|
|
|
|
2016-06-02 17:39:14 +02:00
|
|
|
|
2016-06-02 16:21:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2016-06-02 16:21:44 +02:00
|
|
|
|
|
|
|
|
|
drm/atomic: Convert __drm_atomic_get_current_plane_state() to modern accessor
The __drm_atomic_get_current_plane_state() function tries to get and
return the existing plane state, and if it doesn't exist returns the one
stored in the drm_plane->state field.
Using the current nomenclature, it tries to get the existing plane state
with an ad-hoc implementation of drm_atomic_get_existing_plane_state(),
and falls back to either the old or new plane state, depending on
whether it is called before or after drm_atomic_helper_swap_state().
The existing plane state itself is deprecated, because it also changes
when swapping states from the new state to the old state.
Fortunately for us, we can simplify things. Indeed,
__drm_atomic_get_current_plane_state() is only used in two macros:
intel_atomic_crtc_state_for_each_plane_state and
drm_atomic_crtc_state_for_each_plane_state().
The intel variant is only used through the intel_wm_compute() function
that is only ever called in intel_crtc_atomic_check().
The generic variant is more widely used, and can be found in the malidp,
msm, tegra and vc4 drivers. All of these call sites though are during
atomic_check(), so we end up in the same situation than Intel's.
Thus, we only ever use the existing state as the new state, and
plane->state is always going to be the old state. Any plane isn't
guaranteed to be part of the state though, so we can't rely on
drm_atomic_get_old_plane_state() and we still need to use plane->state.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250930-drm-no-more-existing-state-v5-4-eeb9e1287907@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-09-30 12:59:19 +02:00
|
|
|
|
2016-06-02 16:21:44 +02:00
|
|
|
|
drm/atomic: Convert __drm_atomic_get_current_plane_state() to modern accessor
The __drm_atomic_get_current_plane_state() function tries to get and
return the existing plane state, and if it doesn't exist returns the one
stored in the drm_plane->state field.
Using the current nomenclature, it tries to get the existing plane state
with an ad-hoc implementation of drm_atomic_get_existing_plane_state(),
and falls back to either the old or new plane state, depending on
whether it is called before or after drm_atomic_helper_swap_state().
The existing plane state itself is deprecated, because it also changes
when swapping states from the new state to the old state.
Fortunately for us, we can simplify things. Indeed,
__drm_atomic_get_current_plane_state() is only used in two macros:
intel_atomic_crtc_state_for_each_plane_state and
drm_atomic_crtc_state_for_each_plane_state().
The intel variant is only used through the intel_wm_compute() function
that is only ever called in intel_crtc_atomic_check().
The generic variant is more widely used, and can be found in the malidp,
msm, tegra and vc4 drivers. All of these call sites though are during
atomic_check(), so we end up in the same situation than Intel's.
Thus, we only ever use the existing state as the new state, and
plane->state is always going to be the old state. Any plane isn't
guaranteed to be part of the state though, so we can't rely on
drm_atomic_get_old_plane_state() and we still need to use plane->state.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250930-drm-no-more-existing-state-v5-4-eeb9e1287907@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-09-30 12:59:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-02 16:21:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-28 14:55:03 +01:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2020-01-28 14:55:03 +01:00
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
2015-05-19 16:41:02 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2015-05-19 16:41:02 +02:00
|
|
|
|
2025-11-14 17:01:35 -07:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-11-14 17:01:35 -07:00
|
|
|
|
2015-05-19 16:41:02 +02:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
2016-11-05 11:08:10 -04:00
|
|
|
|
|
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
2020-11-16 17:41:12 +00:00
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
2020-11-12 19:00:11 +00:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2025-11-14 17:01:29 -07:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-11-14 17:01:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-14 17:01:49 -07:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2025-11-14 17:01:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-18 13:27:11 -03:00
|
|
|
|
|
|
|
|
|
2025-11-14 17:01:49 -07:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2018-03-07 08:40:03 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2018-03-07 08:40:03 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-29 17:28:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2021-06-03 19:30:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-29 17:28:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-03-28 17:53:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-09-27 10:35:32 +02:00
|
|
|
|
|
|
|
|
|
2019-10-08 14:42:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-16 10:37:38 +01:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:31 +02:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
|
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-27 10:35:31 +02:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-07 19:08:48 +08:00
|
|
|
|
2017-07-12 18:51:02 +03:00
|
|
|
|
2017-09-27 10:35:31 +02:00
|
|
|
|
2017-04-20 22:51:30 -07:00
|
|
|
|
2016-06-08 14:18:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-29 21:48:26 +01:00
|
|
|
|
2016-06-08 14:18:59 +02:00
|
|
|
|
2017-07-31 11:13:43 +02:00
|
|
|
|
2016-06-08 14:18:59 +02:00
|
|
|
|
2016-10-13 10:47:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-25 07:26:45 +01:00
|
|
|
|
|
|
|
|
|
2016-06-08 14:18:59 +02:00
|
|
|
|
2015-06-18 09:58:55 +02:00
|
|
|
|
2016-11-24 19:47:02 +02:00
|
|
|
|
2015-06-18 09:58:55 +02:00
|
|
|
|
2015-07-21 13:28:57 +02:00
|
|
|
|
|
|
|
|
|
2015-06-18 09:58:55 +02:00
|
|
|
|
|
|
|
|
|
2019-06-12 10:50:19 -04:00
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
2019-06-12 10:50:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-06 14:53:36 +01:00
|
|
|
|
2019-06-12 10:50:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 14:55:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-18 16:15:03 +01:00
|
|
|
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 14:55:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-28 14:55:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 14:55:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-17 09:48:09 -07:00
|
|
|
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 14:55:08 +01:00
|
|
|
|
|
|
|
|
|
2020-01-28 14:55:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2020-01-28 14:55:03 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2020-01-28 14:55:03 +01:00
|
|
|
|
|
|
|
|
|
2026-04-27 09:02:57 +02:00
|
|
|
|
2020-01-28 14:55:03 +01:00
|
|
|
|
|
|
|
|
|
2014-07-25 21:30:38 +02:00
|
|
|
|
