On 2020-03-30 23:39, Hans de Goede wrote:
Hi,
On 3/19/20 11:14 PM, Pierre-Louis Bossart wrote:
we should ask Ben and Curtis @ Google if the changes related to
suspend interfere with the wake-on-voice support?
Btw the .ignore_suspend is also set in bytcr_rt5640/51 drivers, so
wondering if additional devices are broken, or if there's something
off about Broadwell in general. Hans, have you heard of any
regressions on Baytrail devices?
I've just tested 5.6.0 on Bay Trail + a rt5651 codec,
using the bytcr_rt5651 machine driver which sets
ignore_suspend, as well as on a Cherry Trail + rt5645
device using the chtrt5645 machine driver which does
_not_ set ignore suspend.
Suspend/resume work fine on both and music playing
before suspend continues playing after suspend.
Note that the bytcr_rt5651 machine driver also does:
snd_soc_dapm_ignore_suspend(&card->dapm, "Headphone");
snd_soc_dapm_ignore_suspend(&card->dapm, "Speaker");
Which the bdw-rt5677 seems to not do...
Regards,
Hans
Thanks for your report Hans!
As all streams (whether that's playback routed through Headphones or
Speaker, or capture) were connected to SSP0 dai link, there is a
question to be raised: Is Capture path needed to be up during suspend
for broadwell solutions?
Guess these two lines you mentioned above have the exact same impact on
playback as complete .ignore_suspend flag removal from SSP0 dai link.
Don't believe WoV for WPT has been added for SST linux so
.ignore_suspend=1 achieves nothing. The offload part is probably just
limited to bigger buffer size compared to system pin than anything else.
So, nothing prevents from removing .ignore_suspend for SST solutions
until WoV is verified. Don't know about SOF side.
Pierre, what's your take on this?
Czarek
