[BUG] CHT suspend resume causes bogus firmware oops

[cujomalainey]

Describe the bug
Firmware fails to both stay stable after a resume and crash properly. On cml-drop-007 this causes a kernel panic due to the fact that the driver does not detect the bogus panic and ends up reading unavailable memory.

To Reproduce
Suspend then resume a device, then attempt playback

Reproduction Rate
everytime

Expected behavior
audio would continue working after suspend resume

Impact
showstopper

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: 2cb73a9
   • SOF: c4c42d3
2. Name of the topology file
   • Topology: sof-cht-max98090.tplg
3. Name of the platform(s) on which the bug is observed.
   • Platform: Cherrytrail

Screenshots or console output

[   50.200024] PM: suspend exit
...
[   65.366575] sof-audio-acpi 808622A8:00: pcm: open stream 0 dir 0
[   65.366584] sof-audio-acpi 808622A8:00: period min 192 max 16384 bytes
[   65.366589] sof-audio-acpi 808622A8:00: period count 2 max 16
[   65.366592] sof-audio-acpi 808622A8:00: buffer max 65536 bytes
[   65.367286] sof-audio-acpi 808622A8:00: rate_min: 48000 rate_max: 48000
[   65.367292] sof-audio-acpi 808622A8:00: channels_min: 2 channels_max: 2
[   65.369016] sof-audio-acpi 808622A8:00: rate_min: 48000 rate_max: 48000
[   65.369022] sof-audio-acpi 808622A8:00: channels_min: 2 channels_max: 2
[   65.369302] sof-audio-acpi 808622A8:00: rate_min: 48000 rate_max: 48000
[   65.369306] sof-audio-acpi 808622A8:00: channels_min: 2 channels_max: 2
[   65.369314] sof-audio-acpi 808622A8:00: pcm: hw params stream 0 dir 0
[   65.369320] sof-audio-acpi 808622A8:00: generating page table for 00000000a5267d66 size 0xffc0 pages 16
[   65.369325] sof-audio-acpi 808622A8:00: stream_tag 0
[   65.369334] sof-audio-acpi 808622A8:00: ipc tx: 0x60010000
[   65.877054] sof-audio-acpi 808622A8:00: error: ipc timed out for 0x60010000 size 108
[   65.877110] sof-audio-acpi 808622A8:00: invalid header size 0x11a0cb4. FW oops is bogus
[   65.877121] sof-audio-acpi 808622A8:00: error: unexpected fault 0x00000000 trace 0x00000000
[   65.877133] sof-audio-acpi 808622A8:00: error: ipc host -> DSP: pending no complete no raw 0x00000000
[   65.877144] sof-audio-acpi 808622A8:00: error: mask host: pending no complete no raw 0x00000000
[   65.877152] sof-audio-acpi 808622A8:00: error: ipc DSP -> host: pending no complete no raw 0x00000000
[   65.877160] sof-audio-acpi 808622A8:00: error: mask DSP: pending no complete no raw 0x00000000
[   65.877168] sof-audio-acpi 808622A8:00: error: waking up any trace sleepers
[   65.877177] sof-audio-acpi 808622A8:00: error: hw params ipc failed for stream 0
[   65.877188] sof-audio-acpi 808622A8:00: ASoC: 808622A8:00 hw params failed: -110
[   65.877197]  Low Latency: ASoC: hw_params FE failed -110
[   65.877741] sof-audio-acpi 808622A8:00: pcm: free stream 0 dir 0
[   65.877968] sof-audio-acpi 808622A8:00: pcm: close stream 0 dir 0

sof-logger produces no output after the crash

[cujomalainey]

It looks like the topology is simply not being pushed to the DSP after the suspend/resume cycle (assuming it is not saved in ram). This is based on the observing the ipc patterns in glk vs cht. Therefore the hw_params message is causing some indeterminate behaviour as a result which likely suggests we are missing a check somewhere in the firmware for when objects are missing. Also we should probably be pushing the topology...

[ranj063]

@cujomalainey BYT/CHT do not support suspend/resume. If you look into pcm_probe() we deliberately hold the ref_count so as to prevent the device from runtime suspending.

[cujomalainey]

@ranj063 thanks for the clarification, so they should be able to preserve their topology through a suspend resume cycle?

[ranj063]

@cujomalainey no topology will be lost if the audio power domain is powered off during system suspend. Basically the SOF driver does not power off the DSP on ACPI platforms and so when the system resumes, it does not set up the topology either.

[plbossart]

On 10/3/19 5:30 PM, Ranjani Sridharan wrote: @cujomalainey <https://github.com/cujomalainey> BYT/CHT do not support suspend/resume. If you look into pcm_probe() we deliberately hold the ref_count so as to prevent the device from runtime suspending.

that's a bug. suspend/resume is not supported on the MinnowBoard,but it works well on all other boards. we should definitively add this, and there's a old feature request for this.

[cujomalainey]

@ranj063 and I got suspend/resume working on cht in a semi hacky fashion. I have both a cht and byt device at my desk that we can use to get this implemented. We will continue Monday and hopefully get this working and submitted.

[tlauda]

@cujomalainey It's still a problem or working now?

[cujomalainey]

@tlauda yes this is still a bug as this is fixed by this PR #1523
which has not merged yet

[tlauda]

@cujomalainey Since the fix is done on the kernel side I'm not sure whether this bug should be here. As I understand we can't do anything about it on firmware side?

[cujomalainey]

Agreed, this was filed before the fix, I can file a new bug and cross link it if you want so the dashboard can be cleaned up.

[tlauda]

@cujomalainey That would be nice.

[cujomalainey]

actually apparently github has a transfer feature now