Repository navigation
PM: Link DMA fails to resume after system suspend #489
Description
This issue only happens with aplay, no such issue if use browser player to play audio via HDMI or I2S.
Plus, we only observe this issue on HDMI with 0.55 recipe.
But with PV recipe, both hdmi and i2s can reproduce this issue.
How to reproduce:
- open one terminal and play audio via hdmi monitor.
aplay -Dhw:0,5 -f dat -c 2 audio.wav - open another terminal and run suspend/resume test
suspend_stress_test - then system will reboot
No log is available.
PV recipe:
kernel: cros-sof-v4.14-rebase
sof/tplg: glk-005-drop-stable
Activity
plbossart commentedon Jan 2, 2019
Good test!
IIRC correctly all streams are stopped by CRAS before suspend and explicitly restarted so the different behavior is "normal" since the flows are different.
I believe you can force the same behavior with CRAS if you use the traditional method of suspending (echo mem > /sys/power/state), with CRAS using the RESUME_TRIGGER just like aplay.
@ranj063 @cujomalainey can you double-check if my understanding is correct?
mengdonglin commentedon Jan 14, 2019
@keqiaozhang Please help check if this is the the same issue of thesofproject/sof#788 reported on APL.
keqiaozhang commentedon Jan 14, 2019
@mengdonglin
I tried to disable system reboot when kernel panic on GLK, but system just died after running the test, still no useful log or trace available.
keyonjie commentedon Jan 14, 2019
I believe so, this is known issue.
cujomalainey commentedon Jan 14, 2019
Following up with the CRAS team.
[-]GLK: doing HDMI playback in shell and suspend/resume at same time will cause system to reboot [/-][+]GLK: run aplay in shell and suspend/resume at same time will cause system to reboot [/+][-]GLK: run aplay in shell and suspend/resume at same time will cause system to reboot [/-][+]PM: Link DMA fails to resume after system suspend[/+]ranj063 commentedon Jan 26, 2019
@mengdonglin @keqiaozhang I've edited the title of this issue to be more indicative of what the problem is and I'm elevating its status to P1 because this needs to be fixed ASAP.
Basically we can resume host dma after system suspend but link DMA fails to resume.
@RanderWang @libinyang are both looking to fix it.
14 remaining items
mengdonglin commentedon Feb 25, 2019
@ranj063 ,
You will continue working on this issue ?I
You commented that "I will submit a separate PR for the link DMA resuming part" in #582 (comment)
I've checked with @RanderWang and he has not been working on this.
ranj063 commentedon Feb 26, 2019
@mengdonglin yes but this is not a P1 issue. Could you please downgrade it to P2?
lgirdwood commentedon Apr 2, 2019
@mengdonglin this is still showing in daily test. Do we have an ETA for fixing ?This is P1 for me sine aplay is gold standard for Linux userspace API usage.
libinyang commentedon Apr 2, 2019
@lgirdwood
#725
is submitted. Ranjani suggestion we should implement the trigger order in FE link. As you know, if we implement in FE link, this will touch the ABI, alsa-lib, m4 topology file. It will take a longer time. I'm now implement it in FE link.
Another patch in hdmi codec is submitted in alsa mail list. I proposed 2 solutions, but Takashi's doesn't like it. Takashi proposed 4 solutions. I'm now submitting the patch for his 4th solution and wait for his review. And as per Pierre's suggestion, I will test the patch on cAVS tomorrow.
kv2019i commentedon Apr 29, 2019
@libinyang Can you update on the status? This was discussed in the bugscrub today, but it's hard to understand the status from this list. PR824 is closed, what remains?
libinyang commentedon Apr 29, 2019
@kv2019i Patch hw_params for BE is merged. However, we still need Ranjani's patch: #880
So the bug still exists. After #880 is merged, this bug can be closed.
libinyang commentedon Apr 30, 2019
Patch #880 is merged yesterday. I think we can close this bug now.
PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove()
selftests/bpf: Rename ARG_PTR_TO_LONG test description
selftests/bpf: Fix selftest verifier_arena_large failure