On Tue, Nov 19, 2024 at 09:33:26AM -0500, Leonard Lausen wrote:
I'm seeing the same issue as György on the x1e80100 CRD and Lenovo ThinkPad T14s. Without this patch, the internal display fails to resume properly (switching VT brings it back) and the following errors are logged:
[dpu error]connector not connected 3 [drm:drm_mode_config_helper_resume [drm_kms_helper]] *ERROR* Failed to resume (-22)
I see the same symptoms with Xorg as well as sway.
The issue of "internal display fails to resume properly (switching VT brings it back)" also affects sc7180 platform during some resumes. Do you see the issue consistently during every resume?
Yes, it happens on every suspend cycle here.
I didn't notice the issue initially as fbdev does not seem to be affected, and I've been running with this patch applied to suppress the resume errors since it was posted.
Can we please get this fixed and backported as soon as possible?
Even if there are further issues with some "Night Light" functionality on one machine, keeping this bug as workaround does not seem warranted given that it breaks basic functionality for users.
I suspect this is not about "further issues with some 'Night Light' functionality on one machine", but rather a more fundamental issue or race condition in the qcom DRM devices stack, that is exposed when applying this patch. With this patch applied DRM device state is lost after resume and setting the state is no longer possible. Lots of kernel errors are printed if attempting to set DRM state such as the Color Transform Matrix, when running a kernel with this patch applied. Back in July 2024 I tested this patch on top of 6.9.8 and next-20240709, observing below snippet being logged tens of times:
[drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu error]failed to get dspp on lm 0 [drm:_dpu_rm_make_reservation] [dpu error]unable to find appropriate mixers [drm:dpu_rm_reserve] [dpu error]failed to reserve hw resources: -119
Full logs are attached at https://gitlab.freedesktop.org/drm/msm/-/issues/58.
I would not be surprised if there are further issues here, but we can't just leave things completely broken as they currently are.
The x1e80100 is the only platform I have access to with a writeback connector, but this regression potentially affects a whole host of older platforms as well.
Have you attempted setting CTM or other DRM state when running with this patch?
Nope, I just want basic suspend to work.
Johan