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
{{ message }}
Repository navigation
[BUG] [TGL]HDMI/DP aplay failed and can not be released after wake up from s2idle #1651
Describe the bug
HDMI aplay failed and can not be released after wake up from s2idle
Error not seen when doing HDMI aplay after "Suspeand & Resume with playback_HDMI"
Wait about 10min,HDMI aplay successfully and can be released with “ctrl+c”,but aplay again, it
still failed and can not be released, Only unplug/plugin power supply to reboot can recover
To Reproduce
1.sudo reboot
2."sudo rtcwake -m mem -s 10 " from idle
3.aplay -Dhw:0,3 -r48000 -c2 -fs16_le wav/48California_Dreaming.wav -vv -i
Reproduction Rate
10/10
Expected behavior
Aplay via HDMI normally
Actual result
HDMI aplay failed and can not be released
There is no error dmesg message and sof error trace
Issue can also be reproduced when aplay HDMI after Suspend & Resume with analog playback, so I will change the title:delete(entered from idle)
1.sudo reboot
2.Suspend & Resume with analog playback
3.Ctrl+c to stop analog playback
4.aplay -Dhw:0,3 -r48000 -c2 -fs16_le wav/48California_Dreaming.wav -vv -i
changed the title [-][BUG] [TGL]HDMI aplay failed and can not be released after wake up from s2idle (entered from idle)[/-][+][BUG] [TGL]HDMI aplay failed and can not be released after wake up from s2idle [/+]on Dec 27, 2019
@keyonjie It's a bit odd though that aplay works once after resume, but only then hangs. If the rootcause is gaps in PMC support, I'd assume playback to immediately fail after. OTOH, log has errors from other drivers that do inditate issues with resuming, so indeed this looks like most plausible explanation. Tagging with P2 in any case as this is rather severe case.
changed the title [-][BUG] [TGL]HDMI aplay failed and can not be released after wake up from s2idle [/-][+][BUG] [TGL]HDMI/DP aplay failed and can not be released after wake up from s2idle [/+]on Jan 9, 2020
Error not seen on TGL-U on 20200214,but PR #1767 has not been merged,and there is a regression issue #1792 ,I am not sure if there is relationship between them
Ack @Liviali155 , this is excellent news! The fixes were merged via upstream merge #1782 and first part of the fix was already merged to sof-dev via #1764 earlier. So it's ok #1767 was not merged.
I guess we can close this?
Seems #1782 caused a regression #1792 ,are you sure we can closed it?
Activity
Liviali155 commentedon Dec 27, 2019
Issue can also be reproduced when aplay HDMI after Suspend & Resume with analog playback, so I will change the title:delete(entered from idle)
1.sudo reboot
2.Suspend & Resume with analog playback
3.Ctrl+c to stop analog playback
4.aplay -Dhw:0,3 -r48000 -c2 -fs16_le wav/48California_Dreaming.wav -vv -i
[-][BUG] [TGL]HDMI aplay failed and can not be released after wake up from s2idle (entered from idle)[/-][+][BUG] [TGL]HDMI aplay failed and can not be released after wake up from s2idle [/+]Liviali155 commentedon Dec 27, 2019
Error not seen in deep mode
Liviali155 commentedon Dec 30, 2019
Tried with PR #1631 ,issue can also be reproduced
keyonjie commentedon Dec 30, 2019
We are still missing PMC support for TGL with mainline kernel.
keyonjie commentedon Dec 30, 2019
So I would say Power Management support on TGL with mainline kernel is not mature yet.
kv2019i commentedon Jan 8, 2020
@keyonjie It's a bit odd though that aplay works once after resume, but only then hangs. If the rootcause is gaps in PMC support, I'd assume playback to immediately fail after. OTOH, log has errors from other drivers that do inditate issues with resuming, so indeed this looks like most plausible explanation. Tagging with P2 in any case as this is rather severe case.
sinahuang commentedon Jan 9, 2020
Issue also can be reproduce on TGL-U RVP with soundwire-latest (commit: 121c751) when aplay DP after wake up from s2idle.
Test recipe
Kernel:https://github.com/thesofproject/linux/tree/integration/soundwire-latest commit: 121c751
FW: https://github.com/thesofproject/sof/commits/master commit: f587993
Tplg: Same with TGL FW branch : sof-tgl-rt711-rt1308.tplg
Platform:TGL-U RVP with codec ALC711 in SDW mode and RT1308 in I2S mode
dmesg.log
sof_trace.log
[-][BUG] [TGL]HDMI aplay failed and can not be released after wake up from s2idle [/-][+][BUG] [TGL]HDMI/DP aplay failed and can not be released after wake up from s2idle [/+]kv2019i commentedon Feb 6, 2020
@sinahuang Please try with patches #1763 and #1767 -- I believe these fix the problem.
Liviali155 commentedon Feb 11, 2020
Tried with PR #1767,error not seen
Platform: TGL-U RVP with onboard codec ALC711 in HDA mode
Firmware: a573a2c https://github.com/thesofproject/sof/commits/master
Kernel: 0c7dcfe https://github.com/thesofproject/linux/commits/topic/sof-dev
Topology file: tools/topology/sof-hda-generic-4ch.tplg same as firmware
sinahuang commentedon Feb 11, 2020
Issue can't be reproduce on TGL-U RVP with soundwire-latest (commit: 0c7dcfe) when aplay DP/HDMI after wake up from s2idle.
Test recipe
Kernel:https://github.com/thesofproject/linux/commits/topic/sof-dev commit:0c7dcfe
FW: https://github.com/thesofproject/sof/commits/master commit: a573a2c
Tplg: Same with FW branch, rename sof-tgl-rt711-i2s-rt1308.tplg to sof-tgl-rt711-rt1308.tplg
Platform:TGL-U RVP with codec ALC711 in SDW mode and RT1308 in I2S mode
Liviali155 commentedon Feb 14, 2020
Error not seen on TGL-U on 20200214,but PR #1767 has not been merged,and there is a regression issue #1792 ,I am not sure if there is relationship between them
Platform: TGL-U RVP with onboard codec ALC711 in HDA mode
Firmware: 4d17d0d https://github.com/thesofproject/sof/commits/master
Kernel: daf71dc https://github.com/thesofproject/linux/commits/topic/sof-dev
Topology file: tools/topology/sof-hda-generic-4ch.tplg same as firmware
kv2019i commentedon Feb 14, 2020
Ack @Liviali155 , this is excellent news! The fixes were merged via upstream merge #1782 and first part of the fix was already merged to sof-dev via #1764 earlier. So it's ok #1767 was not merged.
I guess we can close this?
Seems #1782 caused a regression #1792 ,are you sure we can closed it?
Liviali155 commentedon Feb 17, 2020
Close this issue since fix of PR #1767 was actually merged via upstream rebase