You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bug happens after resume from S3 when HDMI playback is running. It is obviously detected in 5.0 kernel. In 4.20 kernel, I didn't reproduce this bug. This bug is a general issue from the root cause. It should be reproduced on all platforms.
Reproduce step:
aplay -Dhw:0,n file.wav
call rtcwake to suspend/resume
Run several times of step 1 and step 2, and this bug will be reproduced.
This bug is because of the contest.
When resume, audio will try to get the lock to power on i915 audio domain. But if i915's lock is occupied, it will sleep. This will cause the contest and make something (register reading and writing on HDMI) which should not happen at that monent happens at that time.
Activity
libinyang commentedon Mar 21, 2019
This bug only can be reproduced after applying #725
Without patch #725, playback will be crashed after S3 and never arrive at this bug step.
libinyang commentedon Mar 21, 2019
This bug is because of the contest.
When resume, audio will try to get the lock to power on i915 audio domain. But if i915's lock is occupied, it will sleep. This will cause the contest and make something (register reading and writing on HDMI) which should not happen at that monent happens at that time.
libinyang commentedon Mar 22, 2019
Patch is ready: #744
wenqingfu commentedon Apr 19, 2019
Is this still valid? or it's fixed with upstream code merged in after #851? @libinyang
libinyang commentedon Apr 20, 2019
This bug is fixed. Mark has merged the patch yesterday.
wenqingfu commentedon Apr 20, 2019
You should have closed it in last reply, and save one conversation cycle. thanks.
libinyang commentedon Apr 20, 2019
I planed to close it after QA has verified on the latest kernel. OK. I will close it.
wenqingfu commentedon Apr 20, 2019
thanks