On 8/8/26 7:13 PM, Jesse Casco wrote: > msm_dp_display_atomic_enable() returns early when link training fails, > leaving ->power_on false and the main link down. > msm_dp_display_atomic_disable() nevertheless writes DP_STATE_CTRL_PUSH_IDLE > and waits for an idle-pattern completion that cannot arrive, so every failed > enable is followed by "PUSH_IDLE pattern timedout". > > Every other step of the teardown is already gated on that flag: > msm_dp_display_disable(), called from .atomic_post_disable(), returns early > on !power_on. The PUSH_IDLE write is the only one that is not, so the > controller's runtime-PM reference is then dropped without the link having > been taken down. > > On glymur (Snapdragon X2 Elite) the consequence is not a warning. The SoC > does not survive it: TrustZone force-stops the SOCCP and ADSP remote > processors and the machine resets silently about 50 ms later, with no oops > and no panic. On an ASUS Zenbook A16 (UX3607OA), whose eDP panel does not > currently train, this reproduces without any compositor or GPU involvement: > > # eDP enable has already failed with "Failed link training (rc=-104)" > echo 1 > /sys/class/graphics/fb0/blank > > [535.645455] === marker === > [535.694833] qcom_q6v5_pas d00000.remoteproc: fatal error received: \ > sys_m_smsm.c:512:TZ force stop > [535.694875] remoteproc remoteproc0: crash detected in soccp: type fatal > error > [535.728857] qcom_q6v5_pas 6800000.remoteproc: fatal error received: \ > sys_m_smsm.c:783:err fatal notification received from TZ > <SoC reset>
FWIW the rproc crashes are only a symptom - if the system is going down due to (among other causes) unclocked access, all remote processors will be forced to go down and this is what Linux sees [...] > + /* > + * If .atomic_enable() bailed out - link training failure is the common > + * case - the mainlink was never brought up and ->power_on stayed false. > + * Driving the PUSH_IDLE pattern into a controller that was never > + * enabled times out, and .atomic_post_disable() then drops the > + * controller's runtime-PM reference without tearing the PHY back down, > + * because msm_dp_display_disable() returns early on !power_on. On > + * glymur (Snapdragon X2 Elite) that combination is answered by a > + * TrustZone-level SOCCP/ADSP force-stop and a silent SoC reset. > + * There is nothing to push idle, so leave it alone. > + */ > + if (!dp->power_on) > + return; Dmitry, should we even be reaching atomic_disable if lt fails before? Konrad
