linux-kernel - Re: [v2,1/2] drm/msm/dpu1: don't choke on disabling the writeback connector

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4f145884-2c91-4e32-a7bc-b439746c6adb@lausen.nl>
Date: Tue, 19 Nov 2024 22:02:33 -0500
From: Leonard Lausen <leonard@...sen.nl>
To: Johan Hovold <johan@...nel.org>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: György Kurucz <me@...uczgy.com>,
 Rob Clark <robdclark@...il.com>, Abhinav Kumar <quic_abhinavk@...cinc.com>,
 Sean Paul <sean@...rly.run>, Marijn Suijten <marijn.suijten@...ainline.org>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 Jeykumar Sankaran <jsanka@...eaurora.org>, stable@...r.kernel.org,
 Abel Vesa <abel.vesa@...aro.org>
Subject: Re: [v2,1/2] drm/msm/dpu1: don't choke on disabling the writeback
 connector

>> 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.

Ok. Then situation is worse on x1e80100 than sc7180, where the issue only
occurs sporadically.

>>> 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.

Ok.

Given my previous testing and finding of this patch causing unexplained CRTC
CTM regression was back in July on 6.9.8 and next-20240709, I went ahead and
tested on 6.10.14, 6.11.9 and 6.12 as well. To recall, the problematic behavior
observed with this patch before was that CRTC CTM state would be lost after
suspend with external display attached and re-setting the state was no longer
possible after resume. (The "failed to get dspp on lm 0" etc. errors mentioned
in my earlier email today were not associated with CRTC state issue, but
actually occur with and without this patch. Apologies for misstating, given the
elapsed time):

The finding is that while 6.10.14 with this patch applied still suffers from
that regression, 6.11.9 and 6.12 do not face the CRTC state regression.
Therefore, whatever issue the patch uncovered in older kernels and which
justified not merging it before due to regressing basic CTM functionality, is
now fixed. The patch should be good to merge and backport to 6.11, but from my
perspective should not be backported to older kernels unless the interaction
with the DRM CRTC state issue is understood and an associated fix backported as
well.

I also confirmed that the patch (still) fixes the
"[drm:drm_mode_config_helper_resume] *ERROR* Failed to resume (-22)"
error upon resume.

Tested-by: Leonard Lausen <leonard@...sen.nl> # on sc7180 lazor

Thank you
Leonard