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
[PM] playback on HDMI can't continue after suspend/resume #788
Have a timeout clause that will break. I have a suspicion we probably have one ion the HDA logic since the stream appears to start (but then ALSA stops it as it's position is not updating).
@lgirdwood Is it even supported scenario to have a playback/transfer and simutaniously signal to power down without stoping playback/transfer? Or did i misunderstand the issue ?
@dabekjakub your understanding is the same as mine, I would expect streams to be stopped prior to power down. But in this case I think the driver is automatically power down since the stream failed.
@dabekjakub do you have any logs from FW side as my understanding is that this should work on Chrome as @plbossart says since Chrome will send a TRIGGER_STOP and TRIGGER_START.
@lgirdwood in theory the IP can support suspend and restart from where the DMA position was, so your assertion is only true because we don't support what the hardware could do :-)
We have no logs from this since on our platforms we have reproduction of thesofproject/linux#489
I was just throwing logical assumption out in the open that if we have tests that confirm working scenario of TRIGGER_STOP > SUSPEND > RESUME > TRIGGER_START (and we do). Then only issue possible would be kernel side.
@dabekjakub as we talked in the meeting, I believe FW error first happen at trigger start before this trigger stop, here we see the trigger stop IPC timeout as FW can't respond to IPC anymore.
Activity
lgirdwood commentedon Jan 8, 2019
@keyonjie logs please.
markyang commentedon Jan 14, 2019
Summary:
This issue can be reproduced on APL with PCM512x using the latest build.
sof-logger is empty. sof-logger -t log is attached below.
dmesg:
Test steps:
Test env:
sof master: 872cefe
kernel sof-dev: 2ac82ee
tplg: sof-apl-pcm512x.tplg
Log:
dmesg-apl.txt
logger-t.txt
lgirdwood commentedon Jan 14, 2019
@keyonjie can you check that all the
Have a timeout clause that will break. I have a suspicion we probably have one ion the HDA logic since the stream appears to start (but then ALSA stops it as it's position is not updating).
keyonjie commentedon Jan 15, 2019
@lgirdwood I believe we have some HDA DMA logic issue here, I will take looking into it after Xrun cleanup finished.
lgirdwood commentedon Jan 15, 2019
@keyonjie ok, thanks, I have a feeling there maybe a few remaining.
dabekjakub commentedon Jan 16, 2019
@lgirdwood Is it even supported scenario to have a playback/transfer and simutaniously signal to power down without stoping playback/transfer? Or did i misunderstand the issue ?
lgirdwood commentedon Jan 16, 2019
@dabekjakub your understanding is the same as mine, I would expect streams to be stopped prior to power down. But in this case I think the driver is automatically power down since the stream failed.
3 remaining items
lgirdwood commentedon Jan 17, 2019
@dabekjakub do you have any logs from FW side as my understanding is that this should work on Chrome as @plbossart says since Chrome will send a TRIGGER_STOP and TRIGGER_START.
plbossart commentedon Jan 17, 2019
@lgirdwood in theory the IP can support suspend and restart from where the DMA position was, so your assertion is only true because we don't support what the hardware could do :-)
dabekjakub commentedon Jan 18, 2019
We have no logs from this since on our platforms we have reproduction of
thesofproject/linux#489
I was just throwing logical assumption out in the open that if we have tests that confirm working scenario of TRIGGER_STOP > SUSPEND > RESUME > TRIGGER_START (and we do). Then only issue possible would be kernel side.
However I looked into provided logs
This part should catch our attention. Issue here is that stream stopping ipc is getting timed out.
and that is not all since in provided FW logs we have stop and free ipcs handled but they are reported as timed out on kernel side.
@keyonjie Could You confirm that on the kernel side You have no answer when ipc timeouts here ? Because I can see ipcs handled in logs.
keyonjie commentedon Jan 21, 2019
@dabekjakub as we talked in the meeting, I believe FW error first happen at trigger start before this trigger stop, here we see the trigger stop IPC timeout as FW can't respond to IPC anymore.
keyonjie commentedon Jan 21, 2019
BTW, please use generic hda tplg and machine driver on UP2, it's very easy(100%) to reproduce this issue.
mengdonglin commentedon Jan 28, 2019
This seems to be a duplicate of the generic issue thesofproject/linux#489 on multiple platforms.
michalgrodzicki commentedon Feb 13, 2019
@mengdonglin - if it's a duplicate who should be owner of this issue? @RanderWang ?
mengdonglin commentedon Feb 25, 2019
@dabekjakub @michalgrodzicki I think @ranj063 has between working on this before her vacation. And this is a duplicate of thesofproject/linux#489
mengdonglin commentedon Mar 4, 2019
Closing because it seems a driver issue, will follow up by thesofproject/linux#489