Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx> writes:
There is no need to add the 100ms delay back yet.
thanks for posting this but NAK on this patch till we post the fix this
week.
Appreciate a bit of patience till then.
This regression is already part of the 6.3 stable release series. Will
the new patch qualify for inclusion in 6.3.y? Or will it be part of 6.4
and this revert should go into 6.3.y?
This is a tough situation, as landing a revert will break x13s, as noted
by Bjorn. Given that the workaround is known at this moment, I would
like to wait for the patch from Abhinav to appear, then we can decide
which of the fixes should go to the stable kernel.
I wasn't able to find new patches, though may have missed them. Is there
a decision yet how to proceed with this regression? 6.2 now being EOL
may make this a good moment to decide on the next steps.
[ 275.025497] [drm:dpu_encoder_phys_vid_wait_for_commit_done:488]
[dpu error]vblank timeout
[ 275.025514] [drm:dpu_kms_wait_for_commit_done:510] [dpu error]wait
for commit done returned -110
[ 275.064141] [drm:dpu_encoder_frame_done_timeout:2382] [dpu
error]enc33 frame done timeout
This is a different crash but the root-cause of both the issues is the
bridge hpd_enable/disable series.
https://patchwork.freedesktop.org/patch/514414/
This is breaking the sequence and logic of internal hpd as per my
discussion with kuogee.
We are analyzing the issue and the fix internally first and once we
figure out all the details will post it.
Thank you!